Breaking Down the Identity and Access Management Capability Maturity Model, Part One

Recently, we discussed the four key areas of comprehensive identity and access management (IAM) as well as the common misconception that IAM is a technology that’s confined to select areas. As we transition away from this perception to one of a robust and mature IAM system with a wide array of tenets, it’s critical to determine an action plan to improve your organization’s IAM capabilities.

That’s where the Identity and Access Management Capability Maturity Model comes into play: by identifying gaps, setting benchmarks, and establishing priorities for your IAM program. Simply put, a maturity model is a tool you can use to identify where you are at in terms of functionality and what it takes to get to that next level.

Our IAM Capability Maturity Model is comprised of seven distinct IAM tenets presented in order from least to most complex to implement— federation, multi-factor authentication, single sign-on, delegated administration, identity lifecycle management, access management, and governance. Each tenet has an individual maturity model defined from Level 0 to Level 4, with Level 4 consisting of the most mature capabilities. Not all organizations have to reach Level 4 in each tenet; rather, it’s an organizational decision to determine what level of maturity is needed. 

In this two-part blog, we’ll provide an overview of the Identity and Access Management Capability Maturity Model by focusing on each tenet’s maturity levels at a high level. At the end of each tenet’s section, we’ll provide our recommended steps for how your organization can get started with increasing maturity in each tenet.

Let’s kick part one of this series off by diving into the first four tenets, starting with federation.

Federation

Federation is a mechanism through which a user can be dynamically authenticated to an application as a result of a previous authentication to another application. This enables organizations to integrate with applications without exposing critical systems or data as a trusted party is leveraged to identify and authenticate constituents.

• Level 0 - An organization has not implemented federation capabilities, so a user must individually log into each application and system. While the credentials used to authenticate could be the same, the credentials are uniquely stored and maintained in each application.
  
  
• Level 1 - An organization has an Identity Provider (IdP) with one or more applications (Service Providers or SPs) that are integrated using a Single Sign-On (SSO) federation method, such as Security Assertion Markup Language (SAML). If any of those applications have SP capabilities, such as SalesForce, they can form a trust with an IdP and offload user authentication and potentially authorization to that IdP. In this scenario, a user would only need credentials for the IdP, and the IdP would authenticate the user to the applications in a seamless fashion.
  
  
• Level 2 - This level adds additional federation methods, such as OAuth, OpenID Connect, and WS-Federation into the mix. Due to the variety of federation methods that exist, each time an organization adds support for an additional method, they’ve enabled their users to SSO to a broader range of applications— all with enhanced authentication and authorization capabilities to boot.
  
  
• Level 3 - Security is increased by implementing multiple types of authentication methods with different types of granular and adaptive authentication policies. In addition, organizations at this level have implemented just-in-time (JIT) provisioning, which is where the IdP sends all of the necessary information to the SP application during user authentication, so that the SP application can dynamically create a user account if it doesn’t already exist.
  
  
• Level 4 - At this level, an organization has multiple IdPs, which could be internal, but certainly includes external third-parties. While managing all of these IdPs and the sessions they support can be a daunting task, Level 4 adds the ability for users to access SP applications with a virtual user account. So, rather than requiring a static user account, the application accepts the user according to the assertions with a unique session, and when that session closes, the user no longer physically exists in the application.
  

Our Recommended Steps: First, take inventory of all the SPs and IdPs in your organization. It’s also important to note that if your organization elects to mature to Level 4, the inclusion of multiple third-party services adds a significant amount of risk, so, your organization needs to be diligent with its selections.

Multi-Factor Authentication (MFA)

Authentication is simply proving you are who you say you are, and with MFA, multiple factors are used to verify authentication. In the event that a user’s credentials are stolen, using a second or third form of verification can render a cyberattack harmless. However, once your organization has implemented MFA, that’s only the beginning—MFA capabilities vary greatly from organization to organization—and there’s always room for improvement.

• Level 0 - An organization is only utilizing a single authentication factor, such as a password, pin, or something you know.
  
  
• Level 1 - An organization has introduced at least two authentication factors. For example, something you know, like a password and something you have, such as a phone, token, RFID card.
  
  
• Level 2 - Here we start to look at true multi-factor for the authentication policy. This includes something you know, such as password or pin; something you have, like a RFID card or token; and something you are, such as biometric authentication, which includes facial recognition and fingerprint authentication.
  
  
• Level 3 - In Level 3, an organization starts to look at risk mitigation and adaptive policies. For example, we can identify contextual factors, such as time of day or the user’s location, and trusted devices to define authentication policies. In addition, organizations at this level support step-up authentication for high-risk access.
  
  
• Level 4 - Artificial Intelligence (AI) is introduced to look for patterns, such as observing keystrokes and interaction with the keyboard. Behavior patterns are identified by AI and defined as normal, and these patterns are compared against abnormal activity. For example, if logging in during business hours from a specific location is a user’s normal routine, when a user or device logs in after hours from a remote location, a red flag is raised. At this level, an organization also expands its library of authentication methods to accommodate specific scenarios.

Our Recommended Steps: As an organization moves through the levels of MFA maturity, the goal is to build out risk profiles and high-risk authentication access needs. Ultimately, the authentication policies defined can be used to build AI algorithms to respond to authentication requests based on patterns.

Single Sign-On (SSO)

SSO is the ability for a user to authenticate to one system, one time and then access multiple applications without having to reauthenticate. SSO helps organizations address important access challenges and also offers clear productivity and user experience benefits. However, SSO is not a one-size-fits-all-solution— and once implemented, there are varying levels of SSO capabilities.

• Level 0 - Users are logging into each application with credentials specific to each application.
  
  
• Level 1 - Known as Reduced Sign-On, this level leverages an authoritative password source, such as Active Directory (AD), to ensure a user’s credentials are the same across applications. The user still needs to log into each application, but they can use the credentials they set in the authoritative source instead of having unique credentials for each account.
  
  
• Level 2 - An organization leverages federation methods, like SAML, OAuth, and OpenID Connect— but this level also includes web SSO to applications that don't necessarily support federation. An organization can also use form fill methods to handle exceptions if applications do not support federation protocols.
  
  
• Level 3 - Extends SSO support to non-web applications, typically Windows client applications and virtual desktops.
  
  
• Level 4 - This level extends SSO support even further to non-Windows platforms, like Mac and Linux, as well as mobile platforms, like iOS and Android. In addition, Level 4 takes the SSO set-up to a higher level by automating the creation of SSO application definitions, rather than having administrators create those definitions by hand.

Our Recommended Steps: Look for technologies that increase usability, while decreasing risk and find a vendor with strong mobile OS options with SSO beyond Windows.

Delegated Administration

The concept behind delegated administration is giving business users the ability to perform self-service or limited IT functions without having permissions that are tied to a privileged role. As we go through the maturity levels in delegated administration, we’re trying to remove routine, day-to-day administrative tasks from IT and put those tasks into the hands of individuals and business application owners. On a broader level, delegated administration makes full identity lifecycle management possible by ultimately, allowing for automated and streamlined business processes.

• Level 0 - At Level 0, no self-service capabilities are available, including self-service password resets or the ability for users to manage their own profiles. Rather, these tasks are all managed by IT or a technology group.
  
  
• Level 1 - This is the first level of self-service that empowers users to have basic delegation over their own account. Users can perform limited self-service functions, such as resetting their password, retrieving a forgotten username, and managing profile attributes. Sometimes, users have the ability to reset other users’ passwords based on relationships. For example, a teacher could reset their students’ passwords, or a departmental coordinator could reset departmental employee passwords.
  
  
• Level 2 - An organization expands their capabilities to allow business users to perform lifecycle management of external accounts, known as sponsored accounts, and enables these sponsored accounts to claim their credentials. This is a way to quickly get a contractor, consultant, or other visitor who needs temporary access up and running without having to introduce a separate workflow that goes through a technology department. This level also introduces the capability of claiming accounts, which refers to a person identifying themselves with information only they know that can then be verified against an IAM system. This allows a user to perform functions, such as setting their own password, making selections, like their MFA method, or answering challenge questions that can be answered if they need to do a password reset.
  
  
• Level 3 - This is where we get to a distributed model where end users can help their peers based on their relationships, becoming a second level of support in addition to self-service. For example, if an individual cannot reset their own password, the user can go to their supervisor who can quickly reset the user’s password, so the user doesn’t have to go to the technology or IT department and put in a ticket. At Level 3, business application owners are also empowered to manage access to the applications they own. Through a set of workflows, business application owners can approve access to the particular application they manage. This enables business application owners to maintain roles by managing role definitions and memberships around granting access to their applications. Lastly, in Level 3, an organization starts to introduce fine-grained policies, focusing on the minute details around granting access and determining how to grant access based on particular attributes or information about an identity.
  
  
• Level 4 - At this level, an organization becomes more independent, and governance becomes a part of delegated administration. In addition, business application owners can approve initial access and certify continued access to applications. An organization also puts proxy policies in place to delegate rights and allow peers to approve or certify access on behalf of someone in their absence.

Our Recommended Steps: Focus on allowing users to manage their own profiles and reset their own passwords, as well as providing the capability for administrators to reset user passwords. In addition, an organization should look to managing accounts for users who aren't documented by Human Resources, which is a struggle for many organizations. Such a tool must be user-friendly for non-technical staff, while also enabling constraints that prevent orphan accounts.

Gain Expert Insight with our Identity and Access Management Capability Maturity Model Overview Webinar

In the second installment of this blog series, we’ll dive into the remaining three levels of the Identity and Access Management Capability Maturity Model: identity lifecycle management, access management, and governance. In the meantime, make sure to check out our on-demand webinar, IAM Maturity Model Overview: Understanding the 7 Tenets of Identity and Access Management.

In this webinar, we discuss best practice strategies for implementing the seven IAM tenets and how to assess your organization’s current status on the maturity and capability scale. Whether your organization is considering implementing or maturing your existing IAM capabilities, this webinar provides steps for increasing these capabilities across the individual tenets to take your IAM strategy to the next level.

Access the on-demand webinar here.