Microservice-based architectures allow businesses to develop and deploy their applications in a much more flexible, scalable and convenient way – across multiple programming languages, frameworks and IT environments. Like with any other new technology that DevOps and security teams started to explore in the recent years, there is still quite a lot of confusion about the capabilities of new platforms, misconceptions about new attack vectors and renewed discussions about balancing security with the pace of innovation. And perhaps the biggest myth of microservices is that their security somehow takes care of itself.
Let’s get this thing out of the way first: microservices on their own are nothing more than a method of designing applications as an interconnected system of loosely coupled business-focused components. There is nothing inherent to microservices that would make them more resilient against cyber threats or prevent sensitive data from being stolen. On the contrary, microservice-based architectures rely on new tools and technologies, and those bring in new security challenges and new skills needed to mitigate them efficiently.
In fact, even if we disregard the “architectural” risks of microservices, like cascading failures or service discovery abuse, we have to agree that a modern loosely coupled application is subjected to the same risks as a traditional monolithic one – ranging from the low-level infrastructure exploits to the communication layer and all the way up to attacks targeting the application users. And perhaps no other attack vector is more critical than APIs.
As we have discussed in a recent KuppingerCole webinar, even for more traditional scenarios, API security is still something that many businesses tend to underestimate and neglect, hoping that existing tools like web application firewalls will be sufficient to secure their business APIs. Unfortunately, this could not be further from truth – APIs are subject to numerous risks that can only be successfully mitigated with a properly designed strategy that covers the whole API lifecycle – even before any code is written, let alone deployed to a backend.
In microservice-based applications, where hundreds of individual microservices are communicating with each other and with the outside world exclusively through APIs, the difficulty of securing all those interactions increases exponentially. Due to the nature of these applications, individual API endpoints become ephemeral, appearing as new containers are spun up, migrating between environments and disappearing again. And yet each of them must be secured by proper access control, threat protection, input validation, bot mitigation, and activity monitoring solutions – all those jobs which are typically performed by an API gateway. How many API gateways would you need for that?
Another challenge of microservice-based architectures is their diversity – when individual microservices are written using different development frameworks and deployed to different platforms, providing consistent authentication and authorization becomes a problem – ensuring that all components agree on a common access rights model, that they understand the same access token format, that this token exchange scales properly, and that sensitive attributes flowing between services are not exposed to the outside world. The same considerations apply to network-level communications: isolation, segmentation, traffic encryption - these are just some issues developers have to think about. Preferably, in advance.
Does all this mean that making microservices secure is too much of a hassle that undoes all the speed and convenience of the architecture? Not at all, but the key point here is that you need to do it the right way from the very beginning of your microservice journey. And luckily, you do not have to walk alone – everyone had faced the same challenges, and many have already figured them out. Others have even come up with convenient tools and frameworks that will take care of some of these problems for you.
Consider modern API security solutions that do not just focus on static infrastructure, but cover everything from proactive risk assessment of your API contracts to ensuring that each of your microservices is secured by a tiny centrally managed API microgateway. Or the protocols and standards designed specifically for microservices like Secure Production Identity Framework for Everyone (SPIFFE) – essentially the “next-gen PKI” for dynamic heterogeneous software systems. Or even full-featured service mesh implementations that provide a control and security foundation for your microservices – reinventing the wheel is the last thing you need to think about.
In fact, the only thing you absolutely must do yourself is to keep an open mind and never stop learning – about the recent technologies and tools, about the newest design patterns and best practices, and, of course, about the latest cyber threats and other risks. Needless to say, we are here to support you on this journey. See you at one of our upcoming events!
It seems almost every week in cybersecurity and IAM we read of a large company buying a smaller one. Many times, it is a big stack vendor adding something that may be missing to their catalog, or buying a regional competitor. Sometimes it’s a medium-sized technology vendor picking up a promising start-up. In the olden days (15+ years ago), start-ups hoped for going IPO. IPOs are far less common today. Why? Mostly because it’s an expensive, time-consuming process that doesn’t achieve the returns it once did. Many times, going IPO was an interim step to getting acquired by a large vendor, so why not just skip ahead?
Mergers are not common for a few reasons. Merger implies a coming together of near-equals, and executives and boards of directors don’t usually see it this way. So even when mergers happen, they’re often spun as simply acquisitions, and one brand survives while the other fades away. Mergers also mean de-duplication of products, services, and downsizing of the workforces. Mergers can be difficult for customers of both former brands to endure as well.
In the last few years, we’ve increasingly seen equity firms purchase mature start-ups and assemble portfolios of tech vendors. I say “mature start-up” because, instead of the “3 years and out” that occasionally worked in the early 2000s, now vendors are often taking investment (Series A, B, C, D, etc.) 5-7 years or more after founding. When equity firms pick up such companies, the purchased vendor generally retains their brand in the marketplace. The equity firms typically have 3-5 year plans to streamline the operations of the components in their portfolios, make each company profitable, build value, and then sell again.
Other times large companies spin off divisions that are “not part of their core competencies”. Maybe those divisions are not doing well under current management and might fare better in the market where they can have some brand separation and autonomy.
What motivates acquisitions? There are four major reasons companies merge with or buy others:
- To acquire technology
- To acquire customers
- To acquire territory
Getting a new technology to integrate into an existing suite is very straightforward. Picking up a smaller competitor to access their customer base is also a common strategy, provided it doesn’t run afoul of anti-trust laws. Large regional vendors will sometimes buy or merge with similar companies in other regions to gain overall market share. These can often be smart strategies toward building a global footprint in the market.
Every now and then, however, we read about deals that don’t make sense in the industry. This is the unknown category. Sometimes big companies do acquire smaller competition, but do not integrate, extend, or service the purchased product. Dissatisfied customers leave. Overall brand reputation suffers. These deals turn out to be mistakes in the long run, only benefitting the owners of the purchased company. A better plan is to out-compete rather than buy-out the competition.
Customers of vendors that are being bought or divested have questions: what will happen to the product I use? Will it be supported? Will it go away? Will I have to migrate to combined offering? If so, is now the time to do an RFP to replace it?
IT executives in end-user organizations may hold conflicting views about M&A activities. On the one hand, consolidation in the market can make vendor and service management easier: fewer products to support and fewer support contracts to administer. On the other hand, innovation in large companies tends to be slower than in smaller companies. It’s a momentum thing. As an IT manager, you need your vendor to support your use cases. Use cases evolve. New technical capabilities are needed. Depending on your business requirements and risk tolerance, you may occasionally have to look for new vendors to meet those needs, which means more products to support and more contracts to manage. Beware the shiny, bright thing!
Recommendation: executives in companies that are acquiring others or are being divested need to
- Quickly develop, or at least sketch, roadmaps of the product/services that are being acquired or divested. Sometimes plans change months or years after the event. When they do, let customers know.
- Communicate those roadmaps as well as known at the time of acquisition or divestiture. Explain the expected benefits of the M&A activity and the new value proposition. This will help reduce uncertainty in the market and perhaps prevent premature customer attrition.
In summary: there will always be mergers, acquisitions, and divestitures in the security and identity market. Consolidation happens, but new startups emerge every quarter in every year with new products and services to address unmet business requirements. IT managers and personnel in end-user organizations need to be aware of the changes in the market and how it may impact their businesses.
Likewise, executives in vendor companies, investors, VCs, and equity firms need to be cognizant of current market trends as well as make predictions about the impact and success of proposed ventures. This can help to avoid those deals that leave everyone scratching their heads wondering why did they do that? At KuppingerCole, we understand the cyber and IAM markets, and know the products and services in those fields. Stay on top of the latest security and identity product evaluations at www.kuppingercole.com.
Like many people with a long career in IT, I have numerous small computer-related side duties I’m supposed to perform for my less skilled friends and relatives. Among those, I’m helping manage a G Suite account for a small business a friend of mine has. Needless to say, I was a bit surprised to receive an urgent e-mail alert from Google yesterday, telling me that several users in that G Suite domain were impacted by a password storage problem.
Turns out, Google has just discovered that they’ve accidentally stored some of those passwords unencrypted, in plain text. Apparently, this problem can be traced back to a bug in the G Suite admin console, which has been around since 2005 (which, if I remember correctly, predates not just the “G Suite” brand, but the whole idea of offering Google services for businesses).
Google is certainly not the first large technology vendor caught violating one of the most basic security hygiene principles – just a couple months earlier we’ve heard the same story about Facebook. I’m pretty sure they won’t be the last as well – with the ever-growing complexity of modern IT infrastructures and the abundance of legacy IAM systems and applications, how can you be sure you don’t have a similar problem somewhere?
In Google’s case, the problem wasn’t even in their primary user management and authentication frameworks – it only affected the management console where admins typically create new accounts and then distribute credentials to their users. Including the passwords in plain text. In theory, this means that a rogue account admin could have access to other users’ accounts without their knowledge, but that’s a problem that goes way beyond just e-mail…
So, what can normal users do to protect themselves from this bug? Not much, actually – according to the mail from the G Suite team, they will be forcing a password reset for every affected user as well as terminating all active user sessions starting today. Combined with fixing the vulnerability in the console, this should prevent further potential exploits.
However, considering the number of similar incidents with other companies, this should be another compelling reason for everyone to finally activate Multi-Factor Authentication for each service that supports it, including Google. Anyone who is already using any reliable MFA authentication method – ranging from smartphone apps like Google Authenticator to FIDO2-based Google Security Keys – is automatically protected from any kind of credential abuse. Just don’t use SMS-based one-time passwords, ok? They’ve been compromised years ago and should not be considered secure anymore.
As for service providers themselves – how do you even start protecting sensitive information under your control if you do not know about all places it can be stored? Comprehensive data discovery and classification strategy should be the first step towards knowing what needs to be protected. Without it, both large companies like Google and smaller like the one that just leaked 50 million Instagram account details, will remain not just subjects of sensationalized publications in press, but constant targets for lawsuits and massive fines for compliance violations.
Remember, the rumors of password’s death are greatly exaggerated – and protecting these highly insecure but so utterly convenient bits of sensitive data is still everyone’s responsibility.
Digital Transformation is one of those buzzwords (technically a buzzphrase, but buzzphrase isn’t a buzzword yet) that gets used a lot in all sorts of contexts. You hear it from IT vendors, at conferences, and in the general media. But Digital Transformation, or DT as we like to abbreviate it, is much more than that. DT is commonly regarded as a step or process that businesses go through to make better use of technology to deliver products and services to customers, consumers, and citizens. This is true for established businesses, but DT is enabling and creating entirely new businesses as well.
When we hear about DT, we think of smart home products, wearable technologies, connected cars, autonomous vehicles, etc. These are of course mostly consumer products, and most have digital device identity of some type built in. Manufacturers use device identity for a variety of reasons, to track deployed devices and utilization, to push firmware and software updates, and to associate devices with consumers.
To facilitate secure, privacy-respecting, and useful interactions with consumer of DT technologies, many companies have turned to Consumer Identity and Access Management (CIAM) solutions. CIAM solutions can provide standards-based mechanisms for registering, authenticating, authorizing, and storing consumer identities. CIAM solutions usually offer identity and marketing analytics or APIs to extract more value from consumer business. CIAM is foundational and an absolutely necessary component of the DT.
CIAM solutions differ from traditional IAM solutions in that they take an “outside-in” as opposed to the “inside-out” approach. IAM stacks were designed from the point of view that an enterprise provisions and manages all the identities of employees. HR is responsible for populating most basic attributes and then managers add other attributes for employee access controls. This model was extended to business partners and B2B customers throughout the 1990s and early 2000s, and in some cases, to consumers. Traditional IAM was often found lacking by consumer-driven businesses in terms of managing their end-user identities. HR and company management doesn’t provision and manage consumer identities. Moreover, the types of attributes and data about consumers needed by businesses today was not well-suited to be serviced by enterprise IAM systems.
Thus, CIAM systems began appearing in the 2010s. CIAM solutions are built to allow consumers to register with their email addresses, phone numbers, or social network credentials. CIAM solutions progressively profile consumers so as not to overburden users at registration time. Most CIAM services provide user dashboards for data usage consent, review, and revocation, which aids in compliance with regulations such as EU GDPR and CCPA.
CIAM services generally accept a variety of authenticators that can be used to match identity and authentication assurance levels with risk levels. CIAM solutions can provide better – more usable and more secure – authentication methods than old password-based systems. Consumers are tired of the seemingly endless trap of creating new usernames and passwords, answering “security questions” that are inherently insecure, and getting notified when their passwords and personal data are breached and published on the dark web. Companies with poor implementations of consumer identity miss out on marketing opportunities and sales revenue; they also can lose business altogether when they inconvenience users with registration and password authentication, and they suffer reputation damage after PII and payment card breaches.
In addition to common features, such as registration and authentication options, consider the following functional selection criterion from our newly published Buyer’s Guide to CIAM. Compromised credential intelligence can lower the risks of fraud. Millions of username/password combinations, illegally acquired through data breaches, are available on the dark web for use by fraudsters and other malefactors. Compromised credentials intelligence services alert subscribers to the attempted use of known bad credentials. All organizations deploying CIAM should require and use this feature. Some CIAM solutions, primarily the SaaS vendors, detect and aggregate compromised credential intelligence from across all tenants on their networks. The effectiveness of this approach depends on the size of their combined customer base. On-premises CIAM products should allow for consumption of third-party compromised credential intelligence.
Lastly, CIAM solutions can scale much better than traditional IAM systems. Whereas IAM stacks were architected to handle hundreds of thousands of users with often complex access control use cases, some CIAM services can store billions of consumer identities and process millions to hundreds of millions of login events and transactions.
Over the last few years, enterprise IAM vendors have gotten in on the CIAM market. In many cases they have extended or modified their “inside-out” model to be more accommodating of the “outside-in” reality of consumer use cases. Additionally, though traditional IAM was usually run on-premises, pure-play CIAM started out in the cloud as SaaS. Today almost all CIAM, including those with an enterprise IAM history, offer CIAM as SaaS.
Thus, CIAM is a real differentiator that can help businesses grow through the process of DT by providing better consumer experiences, enhanced privacy, and more security. Without CIAM, in the age of DT, businesses face stagnation, lost revenues, and declining customer bases. To learn more about CIAM, see the newly updated KuppingerCole Buyer’s Guide to CIAM.
Figure: The key to success in Digital Business: Stop thinking inside-out – think outside-in. Focus on the consumer and deliver services the way the consumer wants
Getting competitive advantage from data is not a new idea however, the volume of data now available and the way in which it is being collected and analysed has led to increasing concerns. As a result, there are a growing number of regulations over its collection, processing and use. Organization need to take care to ensure compliance with these regulations as well as to secure the data they use. This is increasing the costs and organizations need a more sustainable approach.
In the past organizations could be confident that their data was held internally and was under their own control. Today this is no longer true, as well as internally generated data being held in cloud services, the Internet of Things and Social Media provide rich external sources of valuable data. These innovations have increased the opportunities for organizations to use this data to create new products, get closer to their customers and to improve efficiency. However, this data needs to be controlled to ensure security and to comply with regulatory obligations.
The recent EU GDPR (General Data Protection Regulation) provides a good example of the challenges organizations face. Under GDPR the definition of data processing is very broad, it covers any operation that is performed on personal data or on sets of personal data. It includes everything from the initial collection of personal data through to its final deletion. Processing covers every operation on personal data including storage, alteration, retrieval, use, transmission, dissemination or otherwise making available. The sanctions for non-compliance are very severe and critically, the burden of proof to demonstrate compliance with these principles lies with the Data Controller.
There are several important challenges that need to be addressed – these include:
- Governance – externally sources and unstructured data may be poorly governed, with no clear objectives for its use;
- Ownership – external and unstructured data may have no clear owner to classify its sensitivity and control its lifecycle;
- Sharing - Individuals can easily share unstructured data using email, SharePoint and cloud services;
- Development use - developers can use and share regulated data for development and test purposes in ways that may breach the regulatory obligations;
- Data Analytics - the permissions to use externally acquired data may be unclear and data scientists may use legitimately acquired data in ways that may breach obligations.
To meet these challenges in a sustainable way, organizations need to adopt Good Information Stewardship. This is a subject that KuppingerCole have written about in the past. Good Information Stewardship takes an information centric, rather than technology centric, approach to security and Information centric security starts with good data governance.
Figure: Sustainable Data Management
Access controls are fundamental to ensuring that data is only accessed and used in ways that are authorized. However, additional kinds of controls are needed to protect against illegitimate access, cyber adversaries now routinely target access credentials. Further controls are also needed to ensure the privacy of personal data when it is processed, shared or held in cloud services. Encryption, tokenization, anonymization and pseudonymization technologies provide such “data centric” controls.
Encryption protects data against unauthorized access but is only as strong as the control over the encryption keys. Rights Management using public / private key encryption is an important control that allows controlled sharing of unstructured data. DLP (Data Leak Prevention) technology and CASBs (Cloud Access Security Brokers) are also useful to help to control the movement of regulated data outside of the organization.
Pseudonymisation is especially important because it is accepted by GDPR as an approach to data protection by design and default. GDPR accepts that properly pseudonymized personal data is outside the scope of its obligations. Pseudonymization also allows operational data to be processed while it is still protected. This is very useful since pseudonymized personal data can therefore be used for development and test purposes, as well as for data analytics. Indeed, according to the UK Information Commissioner’s Office “To protect privacy it is better to use or disclose anonymized data than personal data”.
In summary, organizations need to take a sustainable approach to managing the potential risks both to the organization and to those outside (for example to the data subjects) from their use of data. Good information stewardship based on a data centric approach, where security controls follow the data, is best. This provides a sustainable approach that is independent of the infrastructure, tools and technologies used to store, analyse and process data.
For more details see: Advisory Note: Big Data Security, Governance, Stewardship - 72565
Don’t Run into Security Risks by Managing Robot Accounts the Wrong Way
Robotic Process Automation (RPA) is one of the hot IT topics these days. By using robots that automatically perform tasks that humans executed before, companies unlock a significant potential for cost savings. AI (Artificial Intelligence) helps in realizing RPA solutions. However, if done wrong, the use of RPA can cause severe security challenges.
It starts with the definition of the accounts used by the robots. There appears being a tendency of creating sort of “super-robot” accounts – accounts, that are used by various robots and that accumulate entitlements for multiple robots. Obviously, such approaches stand in stark contrast to the Least Privilege principle. They are the direct opposite of what IAM and specifically Access Governance are focusing on: Mitigating access-related risks.
The only argument for such solution is that management of the robot accounts appears being easier, because accounts can be re-used across robots. But that is just a consequence of doing the management of RPA wrong.
RPA accounts are factually technical (functional) user accounts, which are anyway heavily used in IT. In contrast to common approaches for such technical accounts, there is an individual “user” available: The robot. Each robot can run in the context of its own account, that has exactly the entitlements required for the (commonly very narrow) tasks that robot is executing.
Using standard functions of IGA, robots can be managed as a specific type of user. Each robot needs to be onboarded, which is a process that is very similar to onboarding (and changing and offboarding) an external user. There is nothing fundamentally new or different, compared to existing IAM processes. The robot should have a responsible manager, and changes in management can be handled via well-defined mover processes – as they should be for every technical account and every external user.
The entitlements can be granted based on common entitlement structures such as roles and groups, or – in sophisticated IAM infrastructures – be based on runtime authorization, i.e. Dynamic Authorization Management.
As for technical accounts, in the rare case that someone else needs access to that account, Privileged Access Management (PAM) comes into play. Access to that in some sense shared account can be handled via Shared Account Password Management. Behavior of the accounts can be tracked via the UBA (User Behavior Analytics) capabilities found in several of the PAM solutions in the market, in specific UBA products, or in other solutions.
There are no identity and access related functionalities specific to RPA that can’t be managed well by relying on standard IAM capabilities of IGA (Identity Governance & Administration) and PAM. And if the accounts are managed and associated per robot, instead of creating the “super-robot” accounts, RPA is not an IAM challenge, but IAM helps in managing RPA well, without growing security risks.
Data, a massive amount of data, seems to be the holy grail in building more sophisticated AI’s, creating human-like chatbots and selling more products. But is more data actually better? With GDPR significantly limiting the way we generate intelligence through collecting personally identifiable data, what is next? How can we create a specific understanding of our customers to exceed their expectations and needs with less data?
Many of us collect anything we can get our hands on from personal information, behavioral data, to “soft” data that one might run through a natural language processing (NLP) program to examine interactions between devices and humans to pull meaning from conversations to drive sales. We believe the more we collect, the more we know. But is that belief true or merely a belief?
Today, there are an estimated 2.7 Zettabytes of data that exists in the digital world, but only 0.5% of this data is analyzed. With all of this data being collected and only a fraction of it being analyzed, it is no wonder that 85% of data science projects fail, according to a recent analysis by Gartner.
Data science is utterly complex. If you are familiar with the data science hierarchy of needs, AI and machine learning, you know that for a machine to process data and learn on its own, without our constant supervision, it needs massive amounts of quality data. And within that lies a primary question — even if you have an enormous amount of quality data, is it the right data to drive the insights we need to know our customers?
A client of ours shared their dilemma, which might sound familiar to you. They collected all possible data points about their customers, data that was bias-free and clean.
“We know where the user came from, what they bought, how often they used our product, how much was paid, when they returned. Etc. We created clusters within our database, segmented them, overlaid with additional identifiable data about the user, and built our own ML algorithm so we could push the right marketing message and price point to existing and new customers to increase sales volume.”
All this effort and all this data did not lead to increased sales, they still struggled to convert customers. Was their data actionable? Our client assumed that the data available was directly correlated to driving the purchases. And here lies the dilemma with our assumptions and datasets — we believe the data we collect has something to do with the purchase when in reality the answer is, not always.
Humans are “wired up” to use multiple factors to form a buying decision. Those decision are not made in a vacuum. They don’t just happen online, or offline. Each product, service or brand is surrounded by a set of factors or needs by the customer that play a vital role in their decision-making process, which in most cases has nothing or little to do with one’s demographics, lifestyle, price of the product, etc.
This idea is based on the principle of behavioral economics, which explains that multiple factors - cognitive, social, environmental and economic — play a role in one’s decision process and directly correlates to how we decide what to spend our money on and how we choose between competing products/experiences.
All these factors combined allow customers to individually determine if a brand can fulfill their expectations or why they may prefer one brand over another.
Product preference is directly linked to market share in sales volume. An analysis by MASB found a direct linkage between brand preference and market share across 120 brands and 12 categories. So, if the data that is collected does not directly link to preference how can any data model, ML algorithm, or AI be useful in stimulating sales?
Stephen Diorio, from Forbes, argues, “if more executives understood the economics of customer behavior and the financial power of brand preference they would be better armed to work with CMOs to generate better financial performance.” To remain competitive and stop the rat race for more data, many urge that “companies must apply the latest advances in decision science and behavioral economics to ensure that investment in market research and measurement will yield metrics that isolate the most critical drivers of brand preference.”
In the future, collecting data will become more complicated and in some senses, limited by GDPR, CCPA, and other privacy laws worldwide. To get ahead of the curve companies should quickly shift their perspective from gathering data about who, where, when, what and how, to a broader understanding as to why customers prefer what they prefer and what drives those preferences. Understanding your customers from a behavioral economics point of view will deliver superiority over the competition, how to exceed your shoppers’ expectations and how lean their preference in your favor.
Shooting from the hip is easy, because it is fast and sound like you’re making an impact. But do you hit the mark? When you study the ‘art of shooting’ a bit there is a whole lot of practice to it, it takes time and every shot is highly contextual. No soldier goes into battle without a thorough preparation and training. The target, the terrain, the road in and the road out, weather, it all plays a role in hitting the mark. Becoming really good is hard, takes a long time, and ultimately also depends on context. Yet it always beats shooting from the hip.
Every so often I talk to people in the field of Identity and Access Management and within a minute I’m feeling like I’m talking to the trigger happy hip-shooter. I can’t help to think that they’ve never seen a line of code of an IAM solution, never talked to the end-user, never were first responder to an incident or a breach. Because IAM is hard, complex and highly contextual. Yet it seems so simple to the outsider. Because it’s about logging in, and how hard can that be, right? Everyone logs in, sometimes hundreds of times per day. Sometimes without even realizing it (through SSO solutions for example).
For Identity and Access Management you need to be able to combine competencies and skills that you rarely need to combine in another area of expertise.
- The conversation with the business and executives needs to be simple yet clear. The complexities of IAM need to be hidden because these will not be understood and will obfuscate any real question to business or decision by business. In these conversations the IAM expert needs to put himself in the shoes of either the user (logging in, how hard can it be) or in the shoes of the stakeholder (the project manager of a large IT project, requiring proper access and changes to authorizations, in time). One can mention technology, but always from a use or management perspective.
- Talking to the CISO and the security team it’s about risks, threats and vulnerabilities. And how IAM can aide in reducing the attack surface, reducing the issued permissions to a need-to-have, preventing segregation of duty conflicts and also monitoring actual use through user behaviour analytics. Often this conversation also includes audit and audit-ability of the IAM processes and solutions that are in place. These conversations involve the risk managers and internal auditors. Technical detail can be part of the conversation, but always from a risk and security angle.
- Engaging with architects and policy makers can be a challenge since it requires a more conceptual approach to technology and IAM services. One should not immediately look at the applicability of what is discussed here, but much more on a longer term of what is required and desirable. Since these discussions are also about the guidelines and architectural boundaries that are defined it can feel a bit restrictive. Yet when understood properly as an IAM expert you can influence the architectural conditions in a way that benefits the service now and in the future. In addition architects require a broad approach and (should) see IAM in the context of enterprise or IT architecture as well.
- The conversations with colleagues in the IAM department itself are more detailed. Be it with operational support processing requests and providing customer support, product owners, engineers (devops), service owners, customer representatives or managers. These are the internal conversations where the functional conversation and the technical conversation merge with the customer perspective on IAM and the management perspective on IAM. Here the IAM experts do not only need to understand what services they deliver and how technological solutions enable them, but especially how the people work together and what the ‘dot on the horizon’ is for everyone. Since most colleagues in an IAM department have deep expertise and knowledge it is essential to engage with them from a single starting point that combines all perspectives on IAM. (for this we’ve created in Rabobank four perspectives on employee IAM that are leading for everything we do)
- Talking to vendors of IAM solutions it’s about technology, integration and benefits for the organization. Not all vendors are open to discussing a functional perspective on IAM first, but the good ones are. They understand that their technology serves a functional and business purpose and that without it the technology itself is just expensive and not usefull. As an IAM expert you need to know your technology but also be skilled in vendor management, discussing potential solutions not only based on a successful POC but also based on long term maintenance effort, integration with legacy environments, efforts of upgrades and the (always lurking) risk of takeovers. Some products ceased to exist after the vendor was taken over by another vendor with a different focus.
And I can imagine that I’m forgetting some of the conversations that are taking place with Identity and Access Management as a topic.
Is it possible that this is one person? It is highly likely that it is not. When dealing with IAM the range and spread of skills and competencies is so wide that you need a team. Therefore for IAM I come back to the same statement that was also made for digital: digital success depends on peole (not on technology). It’s almost as if I hear Richard Branson speaking ‘take care of your employees, they will take care of your …’. With a solid team that has the right skills combined and is able to work together you can fire the perfect shot. A team takes time to built, and the temptation is present to quickly shoot from the hip. But I would urge you to start slow in order to go fast later. Focus on the people and the team, and they will move IAM forward.
Artificial Intelligence (along with Machine Learning) seems to be the hottest buzzword in just about every segment of the IT industry nowadays, and not without reason. The very idea of teaching a machine to mimic the way humans think (but much, much quicker) without the need to develop millions of complex rules sounds amazing: instead, machine learning models are simply trained by feeding them with large amounts of carefully selected data.
There is however a subtle but crucial distinction between “thinking like a human” (which in academic circles is usually referred as “Strong AI” and to this day remains largely a philosophical concept) and “performing intellectual tasks like a human”, which is the gist of Artificial General Intelligence (AGI). The latter is an active research field with dozens of companies and academic institutions working on various practical applications of general AI. Much more prevalent, however, are the applications of Weak Artificial Intelligence or “Narrow AI”, which can only be trained to solve a single and rather narrow task – like language processing or image recognition.
Although the theoretical foundations of machine learning go back to the 1940s, only recently a massive surge in available computing power thanks to cloud services and specialized hardware has made it accessible to everyone. Thousands of startups are developing their AI-powered solutions for various problems. Some of those, like intelligent classification of photos or virtual voice assistants, are already an integral part of our daily lives; others, like driverless cars, are expected to become reality in a few years.
AIs are already beating humans at games and even in public debates – surely they will soon replace us in other important fields, like cybersecurity? Well, this is exactly where reality often fails to match customer expectations fueled by the intense hype wave that still surrounds AI and machine learning. Looking at various truly amazing AI applications developed by companies like Google, IBM or Tesla, some customers tend to believe that sooner or later AIs are going to replace humans completely, at least in some less creative jobs.
When it comes to cybersecurity, it’s hard to blame them, really… As companies go through the digital transformation, they are facing new challenges: growing complexity of their IT infrastructures, massive amounts of sensitive data spread across multiple clouds, and the increasing shortage of skilled people to deal with them. Even large businesses with strong security teams cannot keep up with the latest cybersecurity risks.
Having AI as potential replacement for overworked humans to ensure that threats and breaches are detected and mitigated in real time without any manual forensic analysis and decision-making – that would be awesome, wouldn’t it? Alas, people waiting for solutions like that need a reality check.
First, artificial intelligence, at least in its practical definition, was never intended to replace humans, but rather to augment their powers by automating the most tedious and boring parts of their jobs and leaving more time for creative and productive tasks. Upgrading to AI-powered tools from traditional “not-so-smart” software products may feel like switching from pen and paper to a computer, but both just provide humans with better, more convenient tools to do their job faster and with less effort.
Second, even leaving all potential ethical consequences aside, there are several technological challenges that need to be addressed specifically for the field of cybersecurity.
- Availability and quality of training data that are required for training cybersecurity-related ML models. This data almost always contains massive amounts of sensitive information – intellectual property, PII or otherwise strictly regulated data – which companies aren’t willing to share with security vendors.
- Formal verification and testing of machine learning models is a massive challenge of its own. Making sure that an AI-based cybersecurity product does not misbehave under real-world conditions (or indeed under adversarial examples specifically crafted to deceive ML models) is something that vendors are still figuring out, and in many cases, this is only possible through a collaboration with customers.
- While in many applications it’s perfectly fine to train a model once and then use it for years, the field of cybersecurity is constantly evolving, and threat models must be continuously updated, expanded and retrained on newly discovered threats.
Does it mean that AI cannot be used in cybersecurity? Not at all, and in fact, the market is already booming, with numerous AI/ML-powered cybersecurity solutions available right now – the solutions that aim to offer deeper, more holistic real-time visibility into the security posture of an organization across multiple IT environments; to provide intelligent assistance for human forensic analysts by making their job more productive; to help identify previously unknown threats. In other words, to augment but definitely not to replace humans!
Perhaps the most popular approach is applying Big Data Analytics methods to raw security data for detecting patterns or anomalies in network traffic flows, application activities or user behavior. This method has led to the creation of whole new market segments variously referred to as security intelligence platforms or next-generation SIEM. These tools manage to reduce the number of false positives and other noise generated by traditional SIEMs and provide a forensic analyst with a low number of context-enriched alerts ranked by risk scores and often accompanied by actionable mitigation recommendations.
Another class of AI solutions for cybersecurity is based around true cognitive technologies – such as language processing and semantic reasoning. Potential applications include generating structured threat intelligence from unstructured textual and multimedia data (ranging from academic research papers to criminal communications on the Dark Web), proactive protection against phishing attacks or, again, intelligent decision support for human experts. Alas, we are yet to see sufficiently mature products of this kind on the market.
It’s also worth noting that some vendors are already offering products bearing the “autonomous” label. However, customers should take such claims with a pinch of salt. Yes, products like the Oracle Autonomous Database or Darktrace’s autonomous cyber-defense platform are based on AI and are, to a degree, capable of automated mitigation of various security problems, but they are still dependent on their respective teams of experts ready to intervene if something does not go as planned. That’s why such solutions are only offered as a part of a managed service package – even the best “autonomous AIs” still need humans from time to time…
So, is Artificial Intelligence the solution for all current and future cybersecurity challenges? Perhaps, but please do not let over-expectations or fears affect your purchase decisions. Thanks to the ongoing developments both in narrow and general AI, we already have much better security tools than just several years before. Yet, when planning your future security strategy, you still must think in terms of risks and the capabilities needed to mitigate them, not in terms of technologies.
Also, don’t forget that cybercriminals can use AI to create better malware, too. In fact, things are just starting to get interesting!
Today, organizations are capturing trillions of bytes of data every day on their employees, consumers, services and operations through multiple sources and data streams. As organizations explore new ways to collect more data, the increased use of a variety of consumer devices and embedded sensors continue to fuel this exponential data growth. Large pools of data, often referred to as data lakes, are created as a result of this massive data aggregation, collection and storage – which remains the easiest of all processes in a Big Data and BI value chain.
What’s concerning is the complete ignorance of data owners, data privacy officers as well as security leaders towards a defined scope for collection and use of this data. Very frequently, not only the scope for use of this data is poorly defined but the legal implications that might arise from the incompliant use of this data remain unknown or are ignored in broad daylight.
An example that recently made it to the news was the storage of the millions of user passwords by Facebook in clear text. There was no data breach involved, nor the passwords were abused but ignoring the fundamentals of data encryption outrightly puts Facebook in an undeniable defiant position against cybersecurity basics. The absence of controls for restricting users’ access to sensitive customer data further violates the data privacy and security norms by allowing the user passwords to be freely accessed for potential abuse by 20,000 Facebook employees.
It is important for data owners, privacy officers and security leaders to know what data they have in order to classify, analyze and protect it. Obviously, you can’t protect what you don’t know you have in your possession. Therefore, it's necessary for data leaders to have a continually updated catalogue of data assets, data sources and the data privacy and residency regulations that the data elements in your possession directly attract.
Most Big Data environments comprise of massive data sets of structured, unstructured and semi-structured data that can’t be processed through traditional database and software techniques. This distributed processing of data across unsecured processing nodes put the data as the interactions between the distributed nodes are not secured. A lack of visibility into the information flows, particularly the unstructured data leads to inconsistent access policies.
Business Intelligence platforms, on the other hand, are increasingly offering capabilities such as self-service data modeling, data mining and dynamic data content sharing – all of which only exaggerates the problem of understanding the data flows and complying with data privacy and residency regulations.
Most data security tools, including database security and IAM tools, only cater to the part of the problem and have their own limitations. With the massive collection of data through multiple data sources including third-party data streams, it becomes increasingly important for CIOs, CISOs and CDOs to implement effective data security and governance (DSG) for the Big Data and BI platforms to gain the required visibility and appropriate level of control over the data flowing through the enterprise systems, applications and databases.
Some security tools and technologies that are commonly in use and can be extended to certain components within a Big Data or BI platform are:
- Database Security
- Data Discovery & Classification
- Database & Data Encryption
- UBA (User Behaviour Analytics)
- Data Masking & Tokenization
- Data Virtualization
- IGA (Identity Governance & Administration)
- PAM (Privileged Access Management)
- Dynamic Authorization Management
- DLP (Data Leakage Prevention)
- API (Application Programming Interface) Security
There remain specific limitations of each of these technologies in addressing the broader security requirements of a Big Data and BI platform. However, using them wisely and selectively for the right Big Data and BI component potentially reduces the risks of data espionage and misuse arising from these components and thereby contributing to the overall security state of the environment.
Data governance for Big Data and BI is fast becoming an urgent requirement and has largely been absent from the existing IGA tools. Existing IGA tools provide basic access governance, mostly for structured data but lack in-built capabilities to support the complex access governance requirements of the massive unstructured data as well as do not support the multitude of data dimensions required for driving authorizations and access control including access requests and approvals at a granular level.
It is therefore recommended that security leaders work with application and data owners to understand the data flows and authorization requirements of the Big Data and BI environments. Besides practicing standard data sanitization and encryption, security leaders are advised to evaluate the right set of existing data security technologies to meet the urgent Big Data and BI security requirements and build on additional security capabilities in the long term.
We, at KuppingerCole, deliver our standardized Strategy Compass and Portfolio Compass methodology to help security leaders assess their Big Data and BI security requirements and identify the priorities. The methodology also helps leaders provide ratings to available security technologies based on these priorities – eventually providing strong and justifiable recommendations for use of the right set of technologies. Please get in touch with our sales team for more information on relevant research and how we can help you in your plans to secure your Big Data and BI environment.
Get access to the whole body of KC PLUS research including Leadership Compass documents for only €800 a year
Register now for KuppingerCole Select and get your free 30-day access to a great selection of KuppingerCole research materials and to live trainings.
AI for the Future of your Business: Effective, Safe, Secure & Ethical Everything we admire, love, need to survive, and that brings us further in creating a better future with a human face is and will be a result of intelligence. Synthesizing and amplifying our human intelligence have therefore the potential of leading us into a new era of prosperity like we have not seen before, if we succeed keeping AI Safe, Secure and Ethical. Since the very beginning of industrialization, and even before, we have been striving at structuring our work in a way that it becomes accessible for [...]