Identity and Access Management (IAM) in healthcare is designed to achieve the balance of strengthening security measures and enhancing clinical workflows through efficient access to digital tools and records— all the while meeting HIPAA and HITECH compliance.
While IAM encompasses a number of distinct tenets, at Identity Automation, we believe there are four key areas of IAM in healthcare: identity lifecycle management, authentication, access management, and governance. Each of these key areas is comprised of many individual capabilities and interact with one another to provide a comprehensive IAM program.
For example, your healthcare organization can put capabilities in place to govern by policy in order to minimize risk and verify users are who they claim to be. In addition, IAM allows healthcare to control what applications and systems users access as well as to what degree their privileges extend.
Then, there's table stakes: provisioning of accounts and access entitlements with lifecycle automation and access control engines that keep all identity data up-to-date and secure. Healthcare organizations can also leverage analytics, artificial intelligence, and machine learning to enable IAM to automatically adapt to changes and anomalous behaviors in real-time.
This vast array of capabilities may seem overwhelming at first, but understand no healthcare organizations implement all of these capabilities at once. Rather, most organizations will focus on one or two tenets of IAM at any given time, mature capabilities as necessary for their needs, and then move on to the next tenet of IAM.
So, in order to establish future priorities to mature IAM capabilities, it’s crucial to first determine where your healthcare organization currently stands in terms of IAM functionality. To help simplify this process, we created the Identity and Access Management Capability Maturity Model.
Simply put, a maturity model is a tool that can be used to identify where you are at in terms of functionality and the necessary steps to get to the next level. Our Identity and Access Management Capability Maturity Model is not representative of the order in which you have to implement an IAM program, rather, each tenet is presented by level of complexity, from least to most complex to implement. It is also important to grasp that although there are different tenets, there is overlap in terms of functionality.
In this blog, we will take a granular look at IAM and drill into the details of each tenet to define the maturity levels within each for healthcare. As we look at each maturity level, understand that not all healthcare organizations necessarily have to reach the highest level, Level 4. The maturity level goal is an organizational decision depending on your unique needs.
Let’s walk step-by-step through the first tenet on the Identity and Access Management Capability Maturity Model, federation.
Federation
At its core, federation is a mechanism through which your users can dynamically authenticate to an application as the result of their authentication to another application.
Without federation, or Level 0 on the maturity model, each application is responsible for providing its own user authentication. So, users authenticate to each application with separate user credentials that are uniquely stored and maintained in each individual application.
In Level 1, a healthcare organization has an identity provider (IdP) that’s integrated with one or more applications using a single sign-on (SSO) federation method, such as the Security Assertion Markup Language (SAML). The integrated applications are typically referred to as service providers (SPs) or relying parties, for example Salesforce and ServiceNow. SPs can form a trust with an IdP and offload user authentication and potentially authorization to that IdP as well.
In this scenario, users don't need to have unique credentials stored to each individual application, instead, their credentials are stored with the IdP. Then, the IdP authenticates the user to those applications when they log on in a seamless, frictionless manner.
Level 2 simply kicks that functionality up a notch by adding other federation methods to the mix, such as OAuth, OpenID Connect, and WS-Federation. Each time an organization adds support for any one of these federation methods, this enables users to leverage SSO to a broader range of applications, all with enhanced authentication and authorization capabilities.
Further increasing security, healthcare organizations in Level 3 have implemented just-in-time (JIT) provisioning and multiple authentication methods, which can each have separate granular and adaptive authentication policies. JIT provisioning occurs when the IdP sends the information necessary to the SP application during a user's authentication. The IdP refers to that information as it searches, so that the SP application can dynamically create the user account if it doesn't already exist.
Organizations in the highest maturity level, Level 4, have multiple IdPs in the mix. While these identity providers could be internal, there are certainly external IdPs as third parties, and the organization is tasked with managing these IdPs and all of their sessions. This can be a daunting undertaking, but the exciting factor here is that an organization's users can access SP applications through virtual user accounts, rather than static user accounts. It is important to note that meshing adds additional risk with the inclusion of these third-party services, so make sure your healthcare organization is diligent when selecting external IdPs.
Multi-Factor Authentication (MFA)
Next, let's take a dive into the maturity levels of Multi-Factor Authentication (MFA). Simply put, authentication is proving you are who you say you are. By definition, MFA combines three authentication factors to limit risk: something you know, something you have, and something you are. In Level 0, organizations focus on just a single factor, such as a password (something you know).
As we move to Level 1, this is a basic level where we look at using at least two factors. These two factors are a combination of something you know, like a password, and something you have, such as a one time password (OTP) or a contactless card, like a proximity badge.
In Level 2, healthcare organizations enable true MFA that utilizes all three factors. For instance, something you know could be a password, something that you have may be an RFID card, and something you are, such as facial recognition or fingerprint biometrics. All three of these factors combined makes for robust authentication.
As we look at a more advanced level and move to Level 3, this is where healthcare organizations start to define risk mitigation and adapt authentication policies to include specific elements and contextual factors. These contextual factors could include the location the user is authenticating from, if the device used to authenticate is trusted, and time of day. In Level 3, healthcare organizations also introduce step up authentication for high-risk access. Essentially, when a user is trying to access a high-risk or privileged application, the system can “step up” or require more stringent authentication.
In Level 4, healthcare organizations introduce artificial intelligence (AI) into the mix to identify patterns and keystrokes, or the user’s interaction with keyboards, to define normal behavior patterns and compare against those. For example, if you had a user that always logs in during normal business hours from a specific location, and then the system identifies the user logging in with a separate device past business hours or from a different geographic location. From there, the system can present the user with additional authentication factors to protect the environment.
In Level 4, healthcare organizations also expand their library of authentication methods to accommodate various scenarios. This is especially pertinent in healthcare because a clinical workflow can be a completely different experience than a non-clinical workflow. At this level, healthcare organizations examine those workflows and determine if different policies should apply.
Single Sign-On (SSO)
The term single sign-on (SSO) is used a lot, but at Identity Automation we like to think about SSO as the ability for a user to authenticate to one system one time and then, access or log on to multiple applications without having to reauthenticate. Level 0 in this case means your users are logging on to each application with unique credentials that are specific to each application.
Many healthcare organizations have surpassed Level 0 to Level 1, which we refer to as reduced sign-on. Reduced sign-on leverages an authoritative password source, like Active Directory (AD), to ensure that users credentials are the same across applications. The user still has to log on to each application, but they can use the credentials that they've set up in the authoritative source, instead of needing unique credentials in each account. So, Level 1 is not true SSO, but it does reduce the number of individual user credentials that have to be managed.
At Identity Automation, we're seeing more and more healthcare organizations advance to Level 2, what we refer to as web single sign-on. Web SSO uses federation with federation methods described earlier, such as SAML, OAuth, and OpenID Connect. However, Level 2 also includes web SSO to applications that don't necessarily support federation. There are other techniques available to dynamically and securely pass user credentials from the authoritative source to an application during the login process.
Level 3 extends this capability to non-web applications, typically traditional Windows client applications or virtual desktops.
Last, in Level 4, healthcare organizations take SSO capabilities even further to non-Windows platforms, like Mac OS and Linux, as well as mobile platforms, such as iOS and Android. This level also automates the creation of the single sign-on application definition, rather than requiring administrators to create them by hand.
Delegated Administration
We're about halfway through the IAM capability maturity model with this particular tenet, delegated administration, which is the concept of giving business users or organizational users the ability to perform self-service or IT functions without the permissions tied to having a privileged role. There are still boundaries and control around what your users can do, but delegated administration allows them to be more autonomous and self-sufficient, rather than continuously having to go to a strapped technology department that has limited resources.
As we look at maturity in delegated administration, Level 0 indicates the healthcare organization has no self-service capabilities, meaning there's nothing that a user can do for themselves, including resetting their password. Instead, these administrative tasks have to be addressed through a technology group or department.
As we move to Level 1, healthcare organizations start to bring in self-service capabilities, in the form of delegation over a person's own account. Users can reset their password, retrieve a forgotten username, and manage their profile and information stored. In addition, healthcare organizations at Level 1 also include the ability for business users to reset others’ passwords. For example, let’s say you have a departmental coordinator that can reset passwords for their department and a site administrator that can reset passwords for people at that site. Healthcare organizations can actually delegate that capability without requiring the organizational entitlement to reset passwords.
Next, in Level 2 healthcare organizations expand capabilities to allow business users to perform lifecycle management of external, sponsored accounts, such as vendors, contractors, or consultants. This is important because sponsored accounts don't necessarily come through the normal channels, like an HR system for identity or lifecycle provisioning. For instance, consider the vendors that service the equipment or work on the technology inside your healthcare organization. These vendors typically do not have the ability to get into the systems, but often require an account to enable them with the proper access. So, this capability in Level 2 allows someone in the healthcare organization to sponsor the vendor.
Also in Level 2, healthcare organizations can introduce a capability called claiming an account. To claim an account, users identify themselves with information only they know, then that information is verified against the IAM system. Claiming an account allows the user to set their own password and make other selections, such as their MFA methods or answer challenge questions that they might be prompted with in the future, in the event they forget their password.
As we move to Level 3, delegated administrative capabilities evolve into a distributed model and healthcare organizations can have users assist others on a peer-to-peer basis based on the relationship. This capability allows users to become a second level of support in addition to self-service, or helping themselves. While users can assist others, there are still boundaries in place to contain what actions users are allowed to perform. Level 3 also empowers business application owners to manage access to the applications they own, as well as to manage roles for that application for granting access.
Last but not least, healthcare organizations in Level 3 introduce the concept of fine-grained policies, which means they are increasing granularity in how access and applications are administered, as well as what users can access.
In Level 4, healthcare organizations become more independent, allowing business application owners to approve initial access and then certify continued access to applications. Governance also overlaps at this level and becomes part of the delegated administration, which we will discuss as our last tenet. Furthermore, healthcare organizations in Level 4 can allow for proxy policies, meaning business users can delegate administration capabilities to their peers to approve or certify on behalf of them, in the event they're out on vacation or sick leave.
Identity Lifecycle Management (ILM)
Identity Lifecycle Management (ILM) is the workhorse where all the heavy lifting is done. ILM encompasses the creation, updates, and the removal of all of the identities, their roles, and their attributes across all of the applications and services that they use, and the ultimate goal is to automate it all.
Level 1 refers to healthcare organizations that have scripts technical staff have created over the years to at least partially automate some of the identity lifecycle management effort. An example of this would be power shell scripts created by the AD team. The AD team would take data from an HR system, typically via flat file, and automatically create and possibly update Active Directory. However, healthcare organizations in Level 1 also have other teams performing similar actions with other applications, but through separate methods and to different levels of completeness.
In Level 2, healthcare organizations begin the first actions to implement an identity lifecycle and set up new accesses, referred to as provisioning. This level is typically the starting point because it’s normally in response to users requesting accesses to systems they cannot currently access.
Level 3 adds an identity logic engine that centralizes all of the identity lifecycle management functions in the healthcare organization to manage the entire lifecycle, which is made up of numerous events, not just the onboarding aspect. The engine keeps the data updated, and synced as individuals change positions, their roles and attributes change accordingly. This is especially important in healthcare with the challenge of frequent staff position changes: students become residents, residents transition to full-time employees, employees are assigned and re-assigned to departments, and promotions and demotions happen throughout the organization. So, this engine not only makes sure new accesses are granted, but also removes privileges that are no longer needed.
Finally, Level 4 is somewhat of a future concept at this point, but there are many standards being published today that indicate the industry is headed towards an Application Programming Interface (API)-driven direction in order to reduce the complexity of a complete identity lifecycle implementation. API-driven ILM refers to the target or the downstream system pulling the identity information, rather than the organization having to design ways to push that data into it.
Access Management (AM)
Next up on the IAM capability maturity model is Access Management (AM), which is the concept of ensuring that proper access is granted to valid users and preventing access for invalid users through policies. Level 0 in AM is explicitly adding or denying access on a resource by resource, person by person, or account by account basis. This means there's no logic involved, rather, each of these areas are addressed statically.
As we move to Level 1, this level assumes that there's an identity logic engine as we discussed in Level 3 of the previous tenet, ILM, which supports lifecycle management across the ecosystem. Level 1 also assumes that there's a basic level of governance in place with an inventory of entitlements defined, which we will discuss in more detail next. The primary focus in Level 1 is on using Attribute-Based Access Controls (ABAC) and Role-Based Access Controls (RBAC) to determine birthright access. This answers the question: When an identity is born into an organization, what access do they get on day zero? Of course, there are always exceptions, and exception handling in Level 1 is typically handled on a manual basis.
As we move to Level 2, this is where healthcare organizations become more robust and streamline exception handling through a process or automation workflow. Additionally, AM is refined to associate identities with entitlements, and then those requests and approval mechanisms are used to grant that access.
This process helps to limit the duration of the access through the concept of least privilege, or ensuring the right people have the right access to the right resources for the right amount of time to do their job. So, healthcare organizations in Level 2 can limit that duration to reduce risk, especially for privileged accounts, but they also have to have the capability to extend that duration, or certify continued access. Sometimes, a user will have access for a long period of time or in perpetuity, as long as their identity is in the system. However it’s important to re-certify that the access is still valid, and some compliance requirements dictate certifications must be managed on a particular basis, such as annually or quarterly.
In Level 3, healthcare organizations move beyond standard access and focus on privileged access management (PAM). This is where high risk accounts, systems, and applications come into play to ensure the organization is tightly controlling access around those applications. In addition, password vaulting for accessing certain systems where only certain individuals need access to that password, becomes a commonality.
Healthcare organizations in Level 3 can also dynamically assign identities to roles, which are in turn associated with entitlements, and then the entitlements grant access to the resources. So, an individual goes into a role, a role is associated with an entitlement, and the entitlement grants the access to the resource. Another primary capability of Level 3 is centralized policies, so one centralized policy can make decisions across the healthcare organization and the IAM policies.
Furthermore, Level 3 also introduces the concept of what we call an authorization engine, using an API, which are sometimes referred to as microservices. This means other applications can draw upon an IAM system to perform the authorization on behalf of that application. As such, application developers don't have to build authorization into their system, but rather, they can rely on a robust IAM system to determine what a user is authorized to access.
In Level 4, healthcare organizations mature to an even more centralized focus of AM, where the goal is to fully adopt the principle of least privilege everywhere. This means essentially every action, including requests, grants, and revokes, are all audited.
Finally, Level 4 incorporates the use of AI to recognize patterns and make access management decisions. Healthcare organizations in Level 4 can also utilize integration with Security Information and Event Management (SIEM) tools, like LogRhythm or Splunk. SIEM tools can share identity, access, and governance information to correlate with events occurring across the healthcare organization to find anomalies through event correlation engines, which are passed back to the IAM system for action. From there, the IAM system can confirm the event doesn't match the policy, revoke that access, and notify a user for review to make a decision.
Identity Governance and Administration (IGA)
The final tenet on the maturity capability scale, governance, also referred to as Identity Governance and Administration (IGA), aims to improve an organization’s transparency and manageability through greater visibility and control over the identities and their access, or entitlements.
Level 0 on the governance maturity model indicates the healthcare organization has no entitlement repository or central certification, and business owners do not have any visibility into, or control over, who has access to their business applications. Typically when a healthcare organization is at Level 0, that means processes are handled through phone calls, emails, help desk tickets, etc., but the business owners are entirely out of the loop.
In Level 1, a healthcare organization has implemented an entitlement repository, which is capable of presenting a user's accesses throughout the organization. Reporting is a key capability and in Level 1, healthcare organizations have the ability to pull a report from the entitlement repository to view all of the accesses that a user has throughout all systems. This report will also include a paper trail that tells your healthcare organization who approved those accesses, any comments added when granting, as well as recertifications to ensure entitlements are continuously reviewed on a set cycle.
In Level 2, healthcare organizations have the ability to verify that what's in the entitlement repository matches what's actually been provisioned by programmatically looking at the accesses defined in the applications themselves. Level 2 is achieved when an organization can reconcile that entitlement repository to the applications. For example, if you can reconcile an Active Directory account entitlement that’s in the repository to an active user account in AD, then that's a pass. However, if you don't have an AD account entitlement, and there’s an active AD account, then that's an orphaned AD account, which is a significant fail.
Level 3 can be considered a hybrid approach, where healthcare organizations advance to reconcile in real-time, at least for the high-risk resources with access to sensitive data, while still performing full reconciliations. For example, a healthcare organization might look at AD in real-time and reconcile the memberships being changed in the domain administrator group, since that's a high-risk area. At the same time, the healthcare organization should perform a full reconciliation, at a set schedule— perhaps nightly, weekly, or even monthly, where all of the group information from AD is reconciled against the entitlement repository.
For real-time reconciliation, the governance system needs to be able to monitor the resources for change, as they change and have the ability to detect those changes, such as when a user is created, an attribute is changed, or a user is added to a group. Then, the IGA system must be able to automatically reconcile that change to the entitlement repository. If drift is detected, the IGA system can automatically take action and notify a user to minimally remediate if possible.
The primary pain for most healthcare organizations regarding governance is certification fatigue. Keeping up with all of the requests and certifications can be a daunting task, but this is where the governance system itself can help.
In Level 4, healthcare organizations add analytics and AI with good historical data and proper training. The IGA system can leverage patterns and trends from AI to determine, within acceptable probability, that an entitlement request or recertification can be automatically approved, while also highlighting outliers that need additional attention and vetting.
Evaluate Your Healthcare Organization with the IAM Maturity Assessment Tool
Advancing your IAM capabilities is important for increasing your security posture, improving clinician usability, and maintaining compliance. While some tenets of IAM are less complex than others, remember you don't want to try to attack all the capabilities at one time. Instead, as you’re competing with other priorities, take each tenet in manageable pieces and plan a realistic timeline to mature your IAM capabilities.
One aspect of leveraging a maturity model is to understand your target or end goal, and part of your IAM strategy is to identify what should be addressed first. By self-evaluating your healthcare organization, you can identify and understand what areas are your strengths and what tenets need improvements. From there, you can make an organizational determination on how advanced your healthcare organization needs to go within that particular tenet.
To help get you started we created the IAM Maturity Assessment, a simple tool that takes you straight to that first step to evaluate your healthcare organization. By filling out this quick assessment, you will not only gain an understanding of your healthcare organization’s overall position on the IAM maturity capability scale, but also within each tenet of IAM. In addition, this tool provides you with actionable steps to take your IAM strategy to the next level, and a visual representation of your healthcare organization’s strengths and weaknesses in terms of IAM.
Take the first step in improving your healthcare organization’s security and usability and complete the IAM Maturity Assessment here.
Comments