Blog posts by Martin Kuppinger

Benefits of IAM in Healthcare: Compliance, Security, Profits and More

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
  • Security
  • 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.

Robotic Process Automation – an IAM Challenge

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: Locking the Doors You've Left Open When Connecting Your Factory Floor

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.

 Connecting Everything = Everything is Under AttackFigure: Connecting Everything = Everything is Under Attack

There Is a Price to Pay for Using the Shiny, Bright Cloud Service

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 1: Identity Fabrics: Connecting every user to every serviceFigure: Identity Fabrics: Connecting every user to every service

Blockchain Just a Hype?

Blockchain - Just a Hype?

AI in a Nutshell

What AI is and what not

Top 5 CISO Topics for 2019

Where to put your focus on in 2019

Martin Kuppinger's Top 5 IAM Topics for 2019

Where to put your focus on in 2019

IBM & Red Hat – And Now?

On October 28th IBM announced its intention to acquire Red Hat. At $34 Billion, this is the largest software acquisition ever. So why would IBM pay such a large amount of money for Red Hat? Not surprising, there were quite a few negative comments from parts of the Open Source community. However, there is logic behind that intended acquisition.

Aside of the potential it holds for some of the strategic fields of IBM such as AI (Artificial Intelligence) and even security (which is amongst the divisions of IBM showing the biggest growth), there is an obvious potential in the field of Hybrid Cloud as well as for DevOps.

Red Hat has for a long time been a company that is much bigger than just a Linux company. When you look at their portfolio, Red Hat is strong in middleware and technologies supporting hybrid cloud environments. Technology stacks like JBoss, Ansible, OpenShift or OpenStack are well-established.

Red Hat has also been a longstanding supplier preferred by enterprises. They have a strong position in growth markets that play an important role for businesses, Cloud Service Providers (CSPs), and obviously for IBM itself. Red Hat empowers IBM to deliver better and broader services to its customers and strengthen its role as a provider for Hybrid Cloud and DevOps and thus its competitive position in the battle with companies such as AWS, Microsoft, or Oracle. On the other hand, IBM allows Red Hat scaling its business, by delivering both the organizational structure to grow and a global services team and infrastructure.

From our perspective, there is little risk that Red Hat will lose a significant share of its current business – they are already an enterprise player and selling to enterprise customers, and IBM will strengthen not weaken them.

As with every acquisition, this one also brings some risk for customers. There is some overlap in certain parts of the portfolio, particularly around managing hybrid cloud environments, i.e. Cloud Foundry and OpenShift. While this might affect some customers, the overall risk for customers appears to be limited. On the other hand, the joint potential to support business in their Digital Transformation is significant. IBM can increase its offerings and attractiveness for Hybrid Cloud and DevOps, fostered by strong security and with interesting potential for new fields such as AI.

The only question will be whether the price tag of Red Hat is too high. While there is huge potential, the combined IBM and Red Hat will still need to monetize on this.

Read as well: IBM Acquires Red Hat: The AI potential

IAM for a Microservices World: Securing Agile IT

Ten years ago, for the second EIC, we published a report and survey on the intersection of IAM and SOA (in German language). The main finding back then was that most businesses don’t secure their SOA approaches adequately, if at all.

Ten years later, we are talking Microservices. Everything is DevOps, a small but growing part of it is DevSecOps. And again, the question is, whether we have appropriate approaches in place to protect a distributed architecture. This question is even more important in an age where deployment models are agile and hybrid.

So how to do IAM for this microservices world? Basically, there are two challenges: supporting the environments and supporting the services and applications.

The former are about securing containers. That includes privileged access to the environments the containers run in as well as the containers itself, but also the fine-grained access management and governance of such environments. It also includes the interesting challenge of segregating access to development, test, and production in the DevOps world, which is an even more demanding task than in traditional IT.

The second challenge is about how to secure communication between microservices. One of the technologies that inevitably comes into play here is API Management & Security. Beyond that, we will have to rethink authorization for services, but also how to manage and govern identities and their access at both the level of individual microservices and the orchestrated services and applications provided to the business.

Reasonably defined microservices, fully encapsulated and providing their functionality to connected services and applications exclusively via secure, authenticated and auditable APIs, are an important step towards secure architectures “by design”.

Notably, we must also start thinking about deploying security components as services, externalizing and standardizing them. I discussed this topic a while ago in a webinar – you might want to watch the webcast. With moving to a more agile approach of IT, where changes are quickly deployed to production environments, identity and security must become adequately agile. Automation becomes key to success. We see some interesting trends and offerings arriving, however most of them currently are focused on privileged users – which is a good start, but by far not the end of our journey towards secure microservices architectures.

It’s about time to make our IAM services ready to support the new way IT is done: agile and modular. Otherwise we will end up in a security nightmare.

Discover KuppingerCole

KuppingerCole Select

Register now for KuppingerCole Select and get your free 30-day access to a great selection of KuppingerCole research materials and to live trainings.

Stay Connected

Blog

Spotlight

AI for the Future of your Business Learn more

AI for the Future of your Business

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 [...]

Latest Insights

How can we help you

Send an inquiry

Call Us +49 211 2370770

Mo – Fr 8:00 – 17:00