CISA, NSA release report on Identity and Access Management (IAM) challenges

Oct 15, 2023 · 8 mins read

Earlier this month, CISA and NSA released a report titled Identity and Access Management: Developer and Vendor Challenges. The report, authored by a panel of public-private cross-ector partnerships, expands on prior guidance (Identity and Access Management: Recommended Best Practices for Administrators) and identifies challenges faced by organizations trying to choose a vendor.

Multi-Factor Authentication

Despite the importance and efficacy of using Multi-Factor Authentication (MFA), many organizations find it notoriously difficult to deploy. Multi-factor authentication helps to prevent two distinct classes of threat: those related to reuse of compromised passwords and phishing. The NSA and CISA have identified three types of challenges to MFA adoption in this report:

Definitional and policy challenges in the vendor community
Deployment and adoption-related challenges
Governance-related challenges

Definitional and Policy Challenges

Chief among the issues identified is the lack of consistent naming across vendors. Some call it “two-factor authentication” (2FA) while others call it “multi-factor authentication” (MFA), and two “MFA” implementations may be functionally different and offer differing levels of security (e.g., SMS vs TOTP). Additionally, certain features, like “push notifications”, don’t cleanly map to technical security requirements like those found in NIST SP 800-63.

Deployment and Adoption Challenges

SMS-based MFA is vulnerable to a number of attacks, like SIM-swapping, and is considered among the least-secure MFA options. In the middle are Time-based One-Time Passwords (TOTP), known to most users by the use of an authenticator app. The most secure MFA implementations involve two features: a hardware device that prevents extraction of the secret key, and the use of public-key cryptography to bind the authentication code to the current session or system (FIDO2). (Indeed, the new trend of passkeys relies in part on these high-security modes.)

While many applications support at least one form of MFA, enterprise adoption can be hindered by a lack of advanced features, like SSO and PKI support. This is further exacerbated by differing capabilities on mobile devices.

Finally, the authors point to the “often-bewildering list of options” available to SSO and IAM administrators which can be combined to support a seemingly-infinite number of possible configurations. The report recommends vendors offer “pre-defined default configurations” that are pre-validated end-to-end for various use cases.

The final MFA adoption challenge involves auditing requirements and credential lifecycle management. While password-reset flows are fairly standard and directly associated with a user account, this is less true for MFA devices.

FIDO standards, designed primarily for consumers on the public internet, have a number of privacy-preserving features in place. While useful and perhaps even necessary on the public internet, the lack of positive identification to a specific user can hinder adoption, particularly in highly-regulated industries like finance. (Indeed, KYC regulations preclude the use of public-key cryptography in some situations because they cannot be positively associated with a specific individual.) Additionally, the ability to determine that an authenticator device was issued to a particular organization or person is not a first-class feature among most providers.

Single Sign-On (SSO) and Identity Federation

Already widely-adopted in the enterprise, Single Sign-On (SSO) refers to the use of a single Identity Provider (IdP) that communicates authentication and authorization information to other systems or applications. This is accomplished with protocols like Security Assertion Markup Language (SAML) or OpenID Connect (OIDC), which support numerous configurations. SSO platforms are an ideal location to implement MFA, since they can serve as a centralized, single point of entry into the system.

CISA and the NSA have identified three classes of challenges in this area:

Complexity and Usability Challenges
Standards Improvement Opportunities
Ecosystem Challenges

Complexity and Usability Challenges

This first class of challenges refers to the tradeoff between functionality and complexity: organizations generally have a choice between a simple IdP that can’t handle complex enterprise requirements, and complex IdPs that can require teams of specially-trained employees to operate effectively.

Additionally, secure deployments may require specialized skills or hardware, like the use of Hardware Security Modules (HSMs). Organizations without the resources for such a deployment may rely on cloud-based Software-as-a-Service (SaaS) solutions; however, these are not supported on all systems, especially Operational Technology (OT), like industrial control systems (ICS) and Supervisory Control and Data Acquisition (SCADA) systems.

Finally, integrating a system with an SSO IdP typically involves the use of a non-federated administrator account. These accounts are especially attractive to threat actors and should be secured with strong passwords, MFA, and ideally a means of alerting - or at least logging - access to these accounts.

Standards Improvement Opportunities

A number of standards exist for communicating the strength of an MFA between IdPs and SP/RPs, from RFC 8176, competing NIST SP 800-63 implementations, and a number of proprietary standards.

Secondly, the report encourages continued development and adoption of configuration standards like OpenID’s FastFed. (Not named in the report is SAML’s metadata.xml, which serves a similar function in simplifying the connection process between an SP and the IdP that serves the metadata.)

Finally, the report notes the lack of standardization concerning the strength or security of IdP assertions. When a user authenticates to a service or application (SP/RP) using their Single Sign-On identity, the IdP returns information about the user, like their display name, email address, and authorization level.

JWT Assertions

The image above shows an example of claims encoded in a JSON Web Token (JWT). In contrast, OAuth 2 uses opaque tokens, which do not have any meaning encoded in them. This necessitates the need for other mechanisms of transmitting and verifying authorization (user profile and permissions) data.

Often, these take the form of Bearer tokens, which can be vulnerable to replay attacks. To mitigate the risks associated with replay attacks, bearer tokens often have a short lifetime to limit the usefulness of stolen tokens. Instead of requiring the user to log in every few minutes, refresh tokens are typically employed; however, these are not without their own set of security considerations).

One such example are JSON Web Tokens (JWTs), widely used in Single-Page Apps (SPAs), which have seen a rise in popularity in recent years. JWTs are stored in the browser and presented to the server with each request, with the server simply verifing that the JWT was signed by a key that it trusts. In contrast, OAuth 2’s DPoP (Demonstrating Proof-of-Possession) requires the client application to prove that it has the same private key used to request the token.

The app notes that using protocols like OAuth 2, which transmit this information server-to-server, increase security somewhat because credentials are not exposed to the browser.

Ecosystem Challenges

The final class of problem revolves around the astronomical number of configuration permutations, especially in large enterprises with legacy infrastructure. Where the opportunity for turnkey architecure deployments exist, they’re often limited by vendor-specific integration points.

While these myriad configuration options are necessary to support a wide variety of architectures and use-cases, they introduce an even larger number of possible misconfigurations.

The report also laments the classification of SSO-related features with expensive “enterprise” packages, depriving smaller and medium-sized businesses of the security benefits of SSO, MFA and other features. These features are increasingly important given the prevalence of phishing-related threats and increased scrutiny of B2B vendors and supply chain partners.

Finally, the report looks at the lack of standardized credential lifecycle management. That is, the ability of applications (SP/RP) to keep their user information in sync with the Identity Provider. While the System for Cross-domain Identity Management specification address these concerns, SP/RP vendors who develop apps with SSO integration typically use their own custom logic to determine when to update user information based on assertions or claims made by the IdP.

Conclusion

Identity and Access Management (IAM) is a critical pillar of modern cybersecurity. As underscored by the joint report from CISA and the NSA, while there are numerous advanced technologies available to secure digital identities and access, their deployment and effective use are not without challenges. The variety in naming conventions and varying levels of security provided by different MFA implementations underscores a pressing need for standardization and clarity.

As cybersecurity threats continue to evolve, especially phishing-related ones, it is paramount for both large enterprises and SMBs to have access to robust IAM features, like phishing-resistant MFA.

Simplification of configurations, standardization across the board, and inclusive access to advanced features irrespective of business size should be the guiding principles for future IAM solutions. Effective IAM is not just about advanced technology but also about usability, clarity, and ensuring that best practices are both achievable and sustainable for organizations of all sizes.

If you’d like to discuss your organization’s Identity and Access Management (IAM), Single Sign-On (SSO), Multi-Factor Authentication (MFA), or Privileged Access Management (PAM) implementations, get in touch with us today!