Zero Trust Architecture Starts with Modern ICAM

If you ask people to define “identity,” everyone is going to have a different answer. That’s why it’s important to have a framework that puts all of this into context. For the Federal Government, that framework is ICAM.

ICAM guides the Federal Government’s approach to identity in order to enable the operations of government employees, contractors and authorized partners. As defined by the General Services Administration (GSA):

Therefore, ICAM is a good place to start when considering how to implement ZTA, since ICAM is what guides the Federal Government’s implementation of identity. It’s by modernizing ICAM components that we’re able to accomplish a Zero Trust approach to resource access—the best path forward to enable the secure operations of the government’s workforce.

Before modernizing, it’s essential to understand the history of ICAM. The Federal Government has long been working to enhance, standardize and secure the identities of its employees, contractors and partners.

ICAM’s history includes the tragic events of 9/11 and Hurricane Katrina. We learned hard lessons around how gaps in digital identity hindered cross-agency collaboration and the government’s ability to adequately respond to both incidents. These gaps made it impossible for one agency to validate the digital identity of a worker from another agency. This meant there was no way to establish the digital trust necessary to share critical information and resources gathered from the field across agencies in order to respond quickly.

But what caused these gaps? Two key factors include:

1. A lack of interoperability frameworks

Authentication systems did not share a common framework, so authenticators from one agency were incompatible with authentication systems from another. 

2. Inconsistent management of sensitive information

The permissions dictating what level of sensitive data a certain employee could access did not match the types of permissions implemented by another agency.

In an effort to fill these gaps, the government issued guidance designed to specifically improve interoperability and communication between Federal agencies.

The primary guidance issued was NIST Special Publication (SP) 800-63: Digital Identity Guidelines, originally published in January 2004. And while it received a major revision in 2017 (two years before Memorandum M-19-7 required agencies to use 800-63 as the foundation for their ICAM programs), by that point, many agencies had already developed their programs on the earlier versions.

Those earlier versions unfortunately lacked some of the nuance needed to avoid the establishment of various identity silos.

While LOAs may not have worked out exactly as the government would have liked, the intention was valid. Different identity systems and use cases appeared for a reason: to avoid applying a blanket approach to access security. We just need a better way to do that, and that’s where Zero Trust comes into play.

By employing Zero Trust, agencies put identity at the center of security to foster a granular, dynamic, and risk-based approach to access. It brings the appropriate level of security controls to every access request, ensuring each use case is addressed just as it should be.

The new version of NIST’s Digital Identity Guidelines published in 2017—giving us SP 800-63-3—deprecated the LOAs found in the original version of the guidelines. But, it didn’t get rid of assurance levels entirely. Instead, it introduced different types of assurance levels, broken out into three groups:

• Identity Assurance Levels (IALs)

• Authenticator Assurance Levels (AALs)

• Federation Assurance Levels (FALs).

Each group is composed of three different assurance levels (e.g., IAL1, IAL2, and IAL3), meaning that we now have 9 total levels of assurance.

These assurance levels are far more flexible than their predecessors. NIST’s updated guidance essentially breaks out a use case into its component pieces, so just because one component may need to meet a higher assurance level, that doesn’t automatically mean every other component has to as well. 

For instance, maybe the needs of your authenticator system align with AAL2, but the needs of your identity system aren’t as complicated. You can now choose to align your authenticator system with AAL2, while your identity system can instead align with IAL1. This reduces the burden of excess assurance that the original system implemented. 

With this new flexibility, agencies could begin implementing more risk-based security systems and processes. This paved the way for an identity-centric security approach. With the challenges brought on by the original LOAs now addressed, NIST could take the next step in helping agencies make that shift: publishing its new guidance, NIST SP 800-207: Zero Trust Architecture.

The Zero Trust framework is supported by five underlying principles, which O’Reilly Media’s Zero Trust Networks summarizes as follows:

1. The network is always assumed to be hostile.

2. External and internal threats exist on the network at all times.

3. Network locality is not sufficient for deciding trust in a network.

4. Every device, user and network flow is authenticated and authorized.

5. Policies must be dynamic and calculated from as many sources of data as possible.

These principles determine that users cannot be inherently trusted and they can only receive access to resources if they are able to continuously verify that they are who they say they are. This runs counter to the traditional security approach that grants access based on where the request is coming from and generally considers anything within the network perimeter to be secure.

This traditional approach worked when the majority of users and resources actually did operate within the network perimeter; however, with the rise of technologies like cloud, BYOD and APIs—along with the sudden explosion of remote work—that’s no longer the case.

In fact, many of today’s agency users, devices and resources often interact entirely outside the agency’s network perimeter. And, even those that reside within the perimeter likely interact with entities outside of the perimeter at some point. This is why Zero Trust advocates for shifting away the traditional security approach, with NIST emphasizing that:

With these developments, we now have an identity-centric security framework at our disposal that operates by constantly verifying user identities in order to protect resources. Additionally, we have a modern ICAM framework that gives agencies more flexibility in how they issue and use identities to access resources going forward.

This is a far cry from where we began, in which security and identity served as opposing forces that hindered operational efficiency, agility and productivity. Now, we have two complementary frameworks that allow agencies to break down identity silos for improved operation while simultaneously strengthening the agency’s security posture.

And although Zero Trust wasn’t a Federal requirement at the time of SP 800-207’s initial publication, within less than a year, three policies were introduced that mandate ZTA implementation: 

• Executive Order 14028: “Improving the Nation’s Cybersecurity”

• National Security Memorandum-8: “Improving the Cybersecurity of National Security, Department of Defense, and Intelligence Community Systems”

• Memorandum M-22-09: “Moving the U.S. Government Toward Zero Trust Cybersecurity Principles.”

With this, enhancing ICAM simply isn’t an option anymore; it’s a necessity.

Today, it’s possible to break down the silos that exist between authentication systems so that those authenticators can be used to access any resource in any location. To do this, agencies need to uplevel their authentication component so that it serves as a centralized authentication authority.

You can accomplish this by implementing a federation hub. A robust, standards-based federation hub can bridge older authentication sources and multiple standards, including the X. 509 standard that powers the certificates at the heart of PKI authenticators. A federation hub can also integrate with legacy and modern applications, third-party authentication sources, diverse user directories and existing IAM systems.

The result is secure, consistent access that serves as the foundation for modern identity capabilities that legacy, siloed authentication components simply can’t support, including:

Single Sign-On (SSO) for Your Employees

Because the federation hub is able to integrate with any user directory, it can be used to verify any identity within the agency no matter what directory is used to store and manage that identity data. Similarly, its ability to integrate with any application means that all applications across the environment can go directly to that one federation hub to confirm the user’s identity in order to grant access. 

The result is agency-wide SSO, in which any user can access any resource by logging in once with a single set of credentials.

Multi-factor Authentication (MFA) for Your Sensitive Assets

Support for X. 509 certificates allows the federation hub to break down silos and extend the use of PIV and CAC cards across the agency’s entire environment. This means your users don’t need to adopt yet another new authentication factor to enable MFA and you can use existing PKI-based, phishing-resistant authenticators to apply MFA to all of your sensitive assets.

Interoperability for Your Mission-Partners

To securely and easily manage mission partners’ access to your agency’s resources, your applications need to connect to each of those partners’ authentication methods, which often differ from your agency’s authentication methods. By employing a federation hub, you can enable federated identity management, which allows partners to share identities and authenticate users across their different domains.

This means that a partner can authenticate to their organization’s domain and then access resources within your agency’s domain without having to perform a separate login process, enabling easy, secure interoperability for collaborating on joint initiatives.

Historically, authorization has been a very inflexible process. A user either received access or not based on their role in the organization, giving us role-based access control (RBAC). While this type of coarse-grained access control may satisfy very general access needs, there are many situations in which this approach is not sufficient. 

For example, just because somebody works in the HR department, that doesn’t mean you want them to automatically be authorized for full access under every condition to every HR-related system. This applies to any department, but especially those dealing with sensitive data and systems. But, if your authorization component can only grant access based on an individual’s role, that’s generally what will happen.

To uplevel this component, you need to enhance it so that it can employ dynamic authorization as opposed to only this static type of authorization. Dynamic authorization takes additional information (or attributes) into consideration to determine whether a user should receive initial access to a resource. This includes answers to questions like:

• Does the individual usually access the type of information they’re trying to access now? 

• Is the user making this request from a trustworthy device?

• Is the user making this request from their normal location?

If the answer to any of these questions is “no,” then you may not want to grant the individual access at all until they are able to provide another factor of authentication to verify their identity. Answering “no” indicates that this may be a dangerous access situation—even though nothing has changed about the individual’s role.

By making use of dynamic attributes other than an individual’s role, you uplevel your authentication component, allowing your agency to:

Enable Fine-grained Access Control

These dynamic attributes allow you to shift from RBAC to attribute-based access control (ABAC), enabling your authorization component to be much more flexible and adaptable. As a result, you can employ fine-grained access control so that users are granted access not just based on their roles but also on real-time context.

Consider Risk When Making Initial Authorization Decisions

In addition to a more flexible authorization approach, implementing dynamic ABAC also enables you to take risk into consideration when making initial authorization decisions. Answering “no” to the questions above indicates that this access attempt might come with a higher level of risk and you’re then able to make access decisions based on that risk. With a standards-based authorization component, you can easily integrate that component into other solutions in your environment—such as user and entity behavior analytics (UEBA) platforms—to take into consideration other dynamic data and risk signals as well.

Supplement Existing MFA

Shifting from a static authorization approach to a dynamic ABAC approach also supplements existing MFA capabilities. As in the examples above, a user’s attributes might warrant denying a specific transaction or requiring them to perform step-up authentication before the transaction can continue—even if they’re already authenticated.

After a user is authenticated and authorized, they are granted initial access to the requested resource. However, this doesn’t mean you want them to have uninterrupted access to that resource without ever needing to re-verify their identity. That’s because users’ situations change, and it’s not guaranteed that those changes will be benign. 

For example, perhaps when a user initially requested access to a resource, they answered “yes” to all of the questions we posed in the authorization section above. But, after you granted them that initial access, the answer to one of those questions changed (E.g., while they’re still using the application they were authorized to use, they’re now attempting to access data through it that they don’t have a history of accessing).

Legacy monitoring components are not equipped to support post-authorization use cases like this. They rely upon static policies, human intervention and manual processes. These are not flexible enough to take into consideration the sophisticated circumstances and information required to monitor post-authorization activity and make quick, educated decisions. This introduces unnecessary risk to the agency.

To mitigate this risk, you need to uplevel your monitoring component to support adaptive access security. This modern approach leverages intelligence, context, and dynamic policies to continuously monitor post-authorization access attempts and automatically flag suspicious behavior and activity. What that means is after receiving initial access, something about that user’s behavior or activity changes. A monitoring component employing adaptive access security can instantly recognize that change and automatically make the decision to revoke some or all of the user’s access (if necessary) until they re-verify their identity.

By upleveling your monitoring component to support adaptive access security, you enable your agency to:

Gain Visibility into Post-Authorization Activity

If your monitoring component only takes into consideration initial access, all of the activity that occurs within your environment post-authorization is going unwatched. A modern monitoring component brings a whole new level of visibility to your agency, including SSO and post-authorization activity. This puts you in a far better position to provide long-term protection to your users, resources, and systems and identify abnormal behaviors potentially indicative of a compromise.

Employ a Comprehensive Risk-Based Access Approach

We already discussed that taking risk into consideration can help your agency make more secure authorization decisions to grant initial access to resources. Upleveling your monitoring component extends that ability to post-authorization activity by determining a situation’s current risk level by comparing it to the user’s previous behavior and activity. This type of ongoing self-learning allows you to apply a comprehensive risk-based approach to all access attempts, not just initial attempts.

Extend Security to Every Corporate Resource, Including APIs

Legacy monitoring components are often limited in the types of resources they can support, and many were not designed to support modern resources like APIs. However, given the extensive amount of sensitive data APIs deliver, they cannot be overlooked. Modern, standards-based monitoring components were designed to support sophisticated resources like APIs and can help recognize and respond to rapidly changing, dynamic attacks unique to them—without requiring your team to write new policies, rules or code.