Action 1: “Agencies must employ centralized identity management systems for agency users that can be integrated into applications and common platforms.”
Identity Silos Stand in the Way of Risk-Based Access
The first action targets a foundational issue of Federal Government IT environments: identity silos.
Today, many agencies are faced with decentralized and fragmented identity databases and administration processes due to traditional identity, credential, and access management (ICAM) approaches that required agencies to build distinct identity systems to support different “levels of assurance.” As a result, many of today’s government IT environments look like this:
In addition to being visually unappealing, fragmented identity environments prevent agencies from establishing:
Holistic visibility into user activities and permissions.
Consistent authentication practices to verify users attempting to access government resources.
Reliable accountability into what accounts have been provisioned and where they may still be active.
And as the memo notes, these must be in place for agencies to implement risk-based (i.e., Zero Trust) access.
One example that demonstrates the repercussions of identity silos (simply beyond the extra administrative burden) is the Colonial Pipeline ransomware attack. If you aren’t able to reliably manage and track provisioned accounts, they could accidentally remain active beyond their intended purpose. Such was the case in the Colonial Pipeline attack, where a deprecated administrative account was still in an active state on a legacy system.
Break Down Silos With a Single Identity Control Plane
Employing a centralized identity management system allows you to consolidate identity data storage and authentication systems and bring them all into one identity control plane. This unifies the previously fragmented systems so that you can:
Extend the use of existing authenticators to all resources.
Create and maintain master user records that store all metadata.
Establish and manage agency-wide single sign-on (SSO).
Simplify administration, and more quickly respond to emerging threats.
This enables the visibility, interoperability and consistency needed to apply risk-based access across your environment. And keep in mind: the OMB is specifically looking for agencies to implement standards-based identity management systems. Technologies built on open standards are even easier to integrate so that you’re better equipped to break down identity silos, improve interoperability, and adapt to future IT security needs.
Action 2: “Agencies must use strong MFA throughout the enterprise.”
It’s Time for Phishing-Susceptible MFA to Go
The OMB clarifies that by “strong MFA,” they mean “phishing-resistant MFA.” The OMB also specifically highlights PKI-based authenticators as not only a phishing-resistant form of MFA, but also “the simplest way” for many agencies to satisfy this action.
This is partially because PKI authenticators should already be the principal form of authentication in use as required by M-19-17: “Enabling Mission Delivery through Improved Identity, Credential, and Access Management.” Afterall, the primary PKI-based authenticators in use—PIV and CAC smart cards—already have more than two decades worth of innovation and investment, so why not take advantage of all of that enterprise security goodness?
The reality is although PIV/CAC smart cards may be the simplest option for government agencies, that doesn’t necessarily make it an easy option. Remember those silos we talked about before? They’re preventing a lot of agencies from integrating their smart cards across their entire environment.
This is particularly important as Action 2 emphasizes the need to integrate MFA directly at the application levels accessed by Federal staff, contractors, and partners, as opposed to relying on more traditional network-based authentication approaches (i.e., VPNs). This move away from network-based authentication is necessary to establish a Zero Trust environment, and it allows agencies to tighten up security perimeters around applications. This has become increasingly important as more and more sensitive applications are moved to the cloud.
So what’s standing in the way of broader smart card use? Decentralized identity management. Many of the applications found in Federal IT environments lack support for the X. 509 certificates that smart cards use to help verify user identities. This means that before the application is able to accept a smart card, it must be enabled to support these certificates. However, without a way to centralize identity management, developers must enable support on an individual level—manually re-configuring every single application before it can accept a smart card.
This is not only an incredible administrative burden, but also an unrealistic goal for Federal agencies to accomplish. Therefore, it shouldn’t be a surprise to learn that many applications in Federal environments still cannot accept smart cards. So agencies’ authentication flows looks like this:
Extend the Use of Phishing-Resistant MFA with an Authentication Hub
To overcome this challenge, you can employ a modern authentication (or federation) hub that:
This allows you to:
Remove the need for individual applications to support X. 509 certificates
Enable PKI authentication to legacy applications (that may only support simple username and password authentication) and SaaS applications
Reduce the number of times an individual is prompted to authenticate with their smart card
The result is modern single sign-on (SSO), in which the authentication hub extends its certificate support to all applications the agency has integrated into the system. With this, you can establish a new, more efficient authentication process.
For example, instead of logging directly into an application, the user can log into the authentication hub with their smart card. The hub uses its support for X. 509 certificates to verify the identity associated with the user’s smart card on behalf of the app. The app accepts this verification and grants access to the user. So now, your authentication flow looks like this:
And voilà! You can now use phishing-resistant PKI-based authenticators to log into any application, whether or not the application itself supports X. 509 certificates. With this, you get the best of both worlds: you can leverage one of the strongest enterprise-grade authenticators in a way that’s easy for administrators to manage.
Action 3: “When authorizing users to access resources, agencies must consider at least one device-level signal alongside identity information about the authenticated user.”
Role-Based Access Control is No Longer Enough
This last action is about facilitating the transition from coarse-grained, role-based access control (RBAC) to fine-grained, attribute-based access control (ABAC).
Historically, authorization has been a very inflexible process. A user either received access or not based on their role in the organization, hence the phrase RBAC. The problem with this approach is that it doesn’t leave any room for taking into consideration the nuances of individual authorization requests.
For example, just because somebody works in the HR department, that doesn’t mean you’d 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 you can only grant access based on an individual’s role, that’s what will usually happen.
