Blog posts by Martin Kuppinger
Today, the German Federal Government announced its Blockchain Strategy. What might sound as a great thing, falls short, for a number of reasons.
One is that it is late: after the first hype and somewhere in the phase of disillusion. This should have happened much earlier, specifically with the intent of getting or keeping a leading position. And, notably, more important would be to foster innovation by supporting start-ups with simplified regulations and administration for that type of businesses, and a far better ecosystem for venture and growth finance.
A second objection: It is too much about technology, and not enough about use cases. Blockchain technology for itself is not what we should look at. We need to understand the specific benefits, as outlined in our brand-new report “Demystifying the Blockchain”. These are e.g. the need for a distributed (in contrast to central) ledger, immutability, sequenced data, and time-stamped data. Only then, Blockchain technology can deliver benefits by enabling better business solutions. Thus, this should be a strategy for fostering use cases (with some being listed in the document), not a certain technology.
The document also falls short when it comes to Blockchain ID. It focuses only on authentication, does not reflect the current state of Blockchain ID, and ignores the immense potential for fostering data protection and control over individual data, commonly referred to as Self-Sovereign Identity (SSI). And honestly: A German-only Blockchain ID stands in stark contrast to the concepts of Blockchain ID.
Talking about a state-powered Blockchain infrastructure appears strange to me. There are many variants of Blockchains and other Distributed Ledgers with different consensus mechanisms and other specifics. One Blockchain doesn’t serve all use cases.
Also, when reading through the appendix and all the actions the German Government intends to take, it is mainly about research, which should have happened some years ago. To summarize, it is good that the Federal Government is funding new technologies, but that is too late, not focused and too technology-oriented. However, the focus should be rather on promoting the economy (and if the blockchain technology helps, that's great), not on endorsing a particular set of technologies.“
For many companies, Microsoft Azure Active Directory (Azure AD) was the basis for a coordinated step into the cloud, by extending the reach of their existing on-premises Active Directory to the cloud. For others, Azure AD was at the beginning just something that came with Microsoft Office 365 – just another target system when it comes to IAM (Identity and Access Management). However, we are talking to more and more corporate executives who are considering whether Azure AD's role should become a more strategic element within their IAM infrastructure.
There is no simple answer to this question as it depends on a variety of aspects. This starts with your overall strategy for IAM and the way you intend to deploy IAM in the future. It depends on the breadth of applications and services you have in place and on how to best integrate these. It depends on your existing IAM tooling and other factors. For the future IAM strategy, it is worth re-thinking your approach – the concept of an Identity Fabric might be a great starting point for re-visiting your strategy.
Azure AD is, without any doubt, one of the leading offerings in the IDaaS (Identity as a Service) market, serving far more than just the Microsoft environment. There is a huge range of pre-integrated SaaS applications available, thus allowing Azure AD to become a central element in the Access Management strategy to SaaS services.
Notably, discussing a strategy role does not equal “should Azure AD become the one and only tool for IAM?”. Given the breadth of requirements in IAM, ranging from Identity Provisioning and Access Governance to Web Access Management, Identity Federation, Privileged Access Management and several other topics. For some scenarios, even the answer to that question could become a “yes”, but for many, it won’t, due to the breadth and depth of requirements, the existing infrastructure, and other factors.
Obviously, cloud-based IAM solutions (IDaaS) are gaining momentum and will continue to do so, with an ever-increasing share of the critical workloads moving to as-a-service models. When these workloads are run from the cloud, running IAM from the cloud as well is just logical.
While there is not a simple answer, I want to give four recommendations:
Carefully follow what Microsoft is doing around Azure AD to understand which of your requirements are met and which aren’t, and which might be met soon.
Review your IAM landscape and revisit your IAM “architectural blueprint” for having a clear strategy on how to evolve (or even modernize) your IAM.
Reconsider ownership of Azure Active Directory – regardless of how you use it, it is part of the IAM landscape. Ownership should not be with the Office 365 team or an infrastructure/client management team, but with IAM.
If you already integrate the on-premises Active Directory and Azure AD, consider reverting the order of integration – with Azure AD being the lead.
We are about to release the update of the first of two KuppingerCole Leadership Compass documents on IDaaS (Identity as a Service). We have segmented this market into two categories:
- Access Management (AM)
- Identity Governance and Administration (IGA)
A fast-growing market, IDaaS AM is largely characterized by cloud-based delivery of access management capabilities for business irrespective of the application and service delivery models. Improved time-to-value proposition prioritizes adoption of IDaaS for B2B, B2E and B2C access management use-cases, helping IDaaS AM to dominate new IAM purchases globally. This Leadership Compass discusses the market direction and provides a detailed evaluation of market players to offer necessary guidance for IAM and security leaders to make informed decisions.
The IDaaS market has registered significant growth over the last few years primarily driven by the need of organizations to:
- Achieve better time-to-value proposition over on-premises IAM deployments
- Extend IAM capabilities to meet the security requirements of growing SaaS portfolio
- Adopt global IAM standards and practices with access to industry expertise
- Reduce internal IAM costs and efforts to keep up with the market trends
- Limit internal IAM failures in project delivery and ongoing operations
IDaaS vendors have originated from distinct backgrounds and therefore their abilities to support the primary IDaaS use-cases vary significantly. Most of the IDaaS vendors come from different backgrounds including:
- Access Management vendors that offered broader IAM capabilities required for large IAM implementations but could not easily extend these functions to support rapidly emerging cloud and consumer access use-cases.
- IGA (Identity Governance and Administration) vendors that traditionally offered support for identity administration and access governance on-premises, but neither could extend these capabilities to applications in the cloud, nor could support access management beyond basic authentication and authorization
- Traditional SSO vendors that have evolved over time to support web and cloud access use-cases but are deficient on common Identity Governance and Administration (IGA) functions required by most organizations for basic IAM implementation
IDaaS market consolidates access management functions with few IGA and Access Governance capabilities thrown in – all delivered and managed as a service. Today, all IDaaS vendors predominantly deliver a cloud-based service in a multitenant or dedicatedly hosted fashion to serve the common IAM requirements of an organization’s hybrid IT environment. The common IAM capabilities served by most IDaaS vendors can be grouped largely in three categories:
Figure1: IDaaS Capability Matrix
Identity Administration: This represents the group of capabilities required by organizations to administer identity lifecycle events maintaining identity repository, managing access entitlements and synchronization of user attributes across the heterogeneous IT environment. A self-service user interface allows for requesting access, profile management, password reset, and synchronization. Other common identity administration capabilities include administrative web interface, batch import interface, delegated administration, SPML, and SCIM support.
Access Management: This refers to the group of capabilities targeted at supporting access management requirements of organizations ranging from authentication, authorization, single sign-on and identity federation for both on-premises and SaaS applications delivered as a cloud service. The underlying support for industry standards such as SAML, OAuth and OpenID Connect can vary but are largely present in most IDaaS offerings. API security and web access management gateways are fast becoming a differentiator for IDaaS vendors looking to offer competitive access management capabilities and so is social identity integration – which now represents a basic qualifier for consumer access use-cases.
Access Governance: Access governance represents the group of capabilities that are least mature and largely absent from the portfolio of most IDaaS vendors, partly due to architectural limitations and partly due to ownership issues. While many organizations still prefer to keep access governance on-premises for better control and auditing purposes, several others are moving it to the cloud for ease of integration and better time to value as their SaaS portfolio continues to grow. IDaaS vendors may have some serious limitations in how they could support integration with legacy on-prem systems for common access governance capabilities such as auditing and reporting, and so it is important for IAM leaders to ensure they assess their access governance requirements aligned with their IAM vision before starting to evaluate IDaaS vendors for their access governance capabilities.
Depending on the key focus, architectural type and product origin, which affect their overall ability to support IDaaS functions, most IDaaS vendors can be classified in two major categories - either as Access Management or IGA focussed IDaaS vendors:
IDaaS Access Management (IDaaS AM)
There are primarily 2 types of AM focussed IDaaS vendors:
The first type is the traditional SSO vendors that progressed overtime as WAM vendors to mostly address web-centric use-cases along with identity federation but originally lacked the ability to address IAM requirements for cloud-based infrastructure and applications. Over the last few years, these vendors have made significant changes to their product architecture to make them cloud-ready, however, there remain certain limitations in addressing cloud AM requirements.
The second category of IDaaS AM vendors are born in the cloud to primarily manage access management requirements of SaaS and IaaS applications but have architectural limitations in how these could be easily extended to address access management for on-prem applications.
IDaaS Identity Governance and Administration (IDaaS IGA)
The IGA focussed IDaaS vendors are the ones that have traditionally been offering identity administration capabilities including identity provisioning, lifecycle management and access governance across on-premises IT applications and systems. The key focus of these vendors on managing user identities in an increasingly complex IT environment combined with the demand and adoption trends of identity-centric solutions in the market has led these vendors to focus lesser and lesser on building access management capabilities. The move to the cloud, however, required them to support basic access management functions, in addition, to be able to support the delivery of all IGA capabilities to compete with the new IDaaS entrants. The depth of IGA functions delivered by these vendors in a cloud-based delivery model to support a hybrid IT environment not only remains questionable due to the technological limitations but also due to the consumption archetypes of on-premises IT applications and systems.
In the first of the two upcoming KuppingerCole Leadership Compass documents, we will focus on IDaaS AM and provide our insights and ratings on the leading vendors in this market segment. Soon after, we will publish the LC IDaaS IGA for the offerings that are targeted on IGA specifically.
Healthcare organizations must use IAM as an integral part of their IT infrastructure in order to cope with challenges in various fields, such as compliance, regulations, cybersecurity, and Digital Transformation. In this respect, IAM not only serves as a security technology but also as a mechanism that helps responding to new business challenges and drivers.
While every industry currently has to deal with the disruptive nature of the Digital Transformation and ever-increasing cyberattacks, some of the developments are endemic to healthcare organizations. For instance, complying with new regulations such as Electronic Prescribing for Controlled Substances (EPCS) or the well-known Health Insurance Portability and Accountability Act (HIPAA).
Due to their sensitivity, patient data are a highly valuable target for hackers, which is why the healthcare industry is among the most regulated ones.
In order to protect sensitive patient data, it is inevitable for any given healthcare organization to implement a strong Identity and Access Management as a central pillar of the IT infrastructure. Control and restriction of access with the help of a sophisticated IAM is a prerequisite to the protection of information that network firewalls and single sign-on (SSO) cannot deliver.
Altogether, there are five areas a strong IAM infrastructure will bolster:
- Compliance & Regulations
- Organizational & Financial Challenges
- M&A Activity
- Digital Transformation
Compliance & Regulations: In recent years, the regulatory bar that healthcare organizations have to comply with has been raised. HIPAA, ECPS and state-level regulations, like the California Consumer Privacy Act (CCPA) are just a few. The regulations have strong authentication and refined access control at their core. They are complemented by a detailed registration of user activities. In stark contrast to other industries, healthcare providers may find themselves in emergency situations, when data must be accessed quickly. IAM delivers the infrastructure for such regulation-compliant emergency access processes.
Security: As cyberattacks rise in number and intensity, organizations have to take precautions more than ever. IT security teams in healthcare organizations must prioritize this kind of risk, especially regarding incidences of ransomware attacks against hospitals.
Most healthcare organizations still focus too little on detection while being caught up in prevention. Despite external prevention being necessary, it does not protect against internal attacks. Therefore, it is unavoidable to restrict access to sensitive data and critical infrastructure, particularly when the attacker is already in the system. IAM does not replace firewalls and other preventive measures but should always go hand in hand with them.
Organizational & Financial Challenges: Apart from having to care for their patients’ wellbeing, healthcare organizations, ultimately, are also businesses and should keep an eye on profits. Here, IAM helps increasing efficiency and convenience for user experience, for instance with an SSO portal.
The number of user types accessing systems and data within healthcare organizations is sheer incalculable: Doctors, nurses, students, patients are just a few and the number is growing. The careful distribution of user rights has its litmus test when emergency situations arise and EMR data must be accessed quickly.
Like any other kind of business, healthcare businesses often lack the resources and ownership for IAM. The latter must be clearly defined, and projects need support from sponsors within the organization.
M&A Activity: Healthcare is not exempt from M&A activity and IAM infrastructures should be designed to make a merger go as smoothly as possible. The merging organizations must federate identities and give employees, patients, and contractors adequate levels of access.
Digital Transformation: Telemedicine, EMR, and Patient Access Management result in an increase in identities as well as in complexity in access entitlements which must be controlled. The role of IAM is to support these processes in working together seamlessly. Where SSO is not enough, IAM gains center stage: Provisioning and deprovisioning of accounts, management of access entitlements, audit and governance, and granular access control.
As healthcare services become more digitalized and “consumerized”, it is IAM that must support these hybrid environments and multi-cloud infrastructures. Different types of users have different types of devices, all of which has to be considered when setting up an IAM solution, especially one that goes beyond SSO. This is the only way to address the challenges of digitization and provide secure access at the same time. Ultimately, IAM is the foundation for supporting the consumerization of healthcare businesses.
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.
Smart Manufacturing or, as the Germans tend to say, Industry 4.0, has already become a reality for virtually any business in manufacturing. However, as just recently demonstrated by the attack on Norsk Hydro, this evolution comes at a price: There are doors created and opened for attackers that are not easy to close again.
These new challenges are not a surprise when looking at what the quintessence of Smart Manufacturing is from a security perspective. Smart Manufacturing is about connecting business processes to manufacturing processes or, in other words, the (business) value chain to the physical processes (or process chains) on the factory floor.
The factory floor has seen some cyber-attacks even before Smart Manufacturing became popular. However, these were rare attacks, some of them being highly targeted on specific industries. Stuxnet, while having been created in the age of Smart Manufacturing, is a sample of such an attack targeted at non-connected environments, in that case, nuclear plants.
In contrast, cyber-attacks on business IT environments are common, with numerous established attack vectors, but also a high degree of “innovation” in the attacks. There are many attacks. Smart Manufacturing, by connecting these two environments, opens these new doors – at the network level as well as at the application layer. The quintessence of Smart Manufacturing, from the IT perspective, is thus “connecting everything = everything is under attack”. Smart Manufacturing extends the reach of cybercriminals.
But how to lock these doors again? It all starts with communication, and communication starts with a common language. The most important words here are not SCADA or ICS or the likes, but “safety” and “security”. Manufacturing is driven by safety. IT is driven by security. Both can align, but both also need to understand the differences and how one affects the other. Machines that are under attack due to security issues might cause safety issues. Besides that, there are other aspects such as availability and others that differ in their relevance and other characteristics between the OT (Operational Technology) and the IT world. If an HR system is down for a day, that is annoying, but most people will not notice. If a production line is down for a day, that might cause massive costs.
Thus, as always, it begins with people – knowing, understanding, and respecting each other – and processes. The latter includes risk management, incident handling, etc. But, also common, there is a need for technology (or tools). Basically, this involves a combination of two groups of tools: Specific solutions for OT networks such as unidirectional gateways for SCADA environments, and the well-thought-out use of standard security technologies. This includes Patch Management, which is more complex in OT environments due to the restrictions regarding availability and planned downtimes. This includes the use of Security Intelligence Platforms and Threat Intelligence to monitor and analyze what is happening in such environments and identify anomalies and potential attacks. It also includes various IAM (Identity & Access Management) capabilities. Enterprise Single Sign-On, while no longer being a hyped technology, might help in moving from open terminals to individual access, using fast user switching such as in healthcare environments. Privileged Access Management might help in restricting privileged user access to critical systems. Identity Provisioning can be used to manage users and their access to such environments.
There are many technologies from IT Security that can help in locking the doors in OT environments again. It is the about time for people from OT and IT to start working together, by communicating and learning from each other. Smart Manufacturing is here to stay – now it is time to do it right not only from a business but from a security perspective.
Figure: Connecting Everything = Everything is Under Attack
One of the slides I use most frequently these days is about Identity Brokers or Identity Fabrics, that manage the access of everyone to every service. This slide is based on recent experience from several customer advisories, with these customers needing to connect an ever-increasing number of users to an ever-increasing number (and complexity) of services, applications, and systems.
This reflects the complex reality of most businesses. Aside of the few “cloud born” businesses that don’t have factory floors, large businesses commonly have a history in their IT. Calling this “legacy” ignores that many of these platforms deliver essential capabilities to run the business. They neither can be replaced easily, nor are there always simple “cloud born” alternatives that deliver even the essential capabilities. Businesses must check whether all capabilities of existing tools are essential. Simple answer: They are not. Complex answer: Not all; but identifying and deciding on the essentials is not that easy. Thus, businesses today just can’t do all they need with the shiny, bright cloud services that are hyped.
There are two aspects to consider: One is the positive side of maturity (yes, there is a downside, by being overloaded with features, monolithic, hard to maintain,…), the other is the need to support an existing environment of services, applications, and systems ranging from the public cloud service to on-premises applications that even might rely on a mainframe.
When looking at the hyped cloud services, they always start lean – in the positive sense of being not overly complex, overloaded with features, hard to maintain, etc. Unfortunately, these services also start lean in the sense of focusing on some key features, but frequently falling short in support for the more complex challenges such as connecting to on-premises systems or coming with strong security capabilities.
Does that mean you shouldn’t look for innovative cloud services? No, on the contrary, they can be good options in many areas. But keep in mind that there might be a price to pay for capabilities. If these are not essential, that’s fine. If you consider them essential, you best first check whether they really are. If they remain essential after that check, think about how to deal with that. Can you integrate with existing tools? Will these capabilities come soon, anyway? Or will you finally end up with a shiny, bright point solution or, even worse, a zoo of such shiny, bright tools?
I’m an advocate of the shift to the cloud. And I believe in the need to get rid of many of the perceived essential capabilities that aren’t essential. But we should not be naïve regarding the hybrid reality of businesses that we need to support. That is the complex part when building services–integrating and supporting the hybrid IT. Just know of the price and do it right (which equals “well-thought-out” here).
Figure: Identity Fabrics: Connecting every user to every service
Blockchain - Just a Hype?
What AI is and what not
Where to put your focus on in 2019
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 [...]