ICAM and Zero Trust
Zero Trust remains one of the key buzzwords in cybersecurity, and virtually every article, briefing, or marketing slick about zero trust talks about the importance of implementing multi-factor authentication (MFA). Single factor passwords have been asserted to be “broken” for years, with documented proof that attackers are able to successfully hack passwords regardless of complexity, length, and change frequency. Furthermore, passwords have become increasingly difficult for both users and organizations to manage. Well-designed MFA technologies, especially when paired with a mobile device or other token, address both the security risks and usability concerns without adding the complexity that limited the deployment of end user public key infrastructure (PKI) digital certificates.
Unlike passwords and digital certificates, most applications do not directly support MFA. Instead, users authenticate to the credential service provider (CSP), which then provides a digitally signed assertion to the application containing information about the user. This two-step architecture simplifies the integration of MFA across applications, and works well for both on-premise and cloud hosted systems. It has also led to the proliferation of cloud-based CSPs that manage credentials on behalf of organizations and can provide virtual landing pages for organizations to manage their Software as a Service (SaaS) partnerships.
But this design itself introduces a new security risk. By performing authentication on behalf of the application, the CSP in the middle, and has become the target of man-in-the-middle attacks. NSA recently published a Security Advisoryhighlighting the danger of an attacker gaining access to the private signing key and using it to impersonate legitimate users (https://media.defense.gov/2020/Dec/17/2002554125/-1/-1/0/AUTHENTICATION_MECHANISMS_CSA_U_OO_198854_20.PDF). While the security advisory focuses on on-premise CSPs, the same vulnerability could also apply to third party cloud-based CSPs.
Preventing successful attacks on the CSP requires protection of the private key used to sign assertions, so that assertions can only be generated when a legitimate user authenticates to the CSP. However, there are no commonly accepted security best practices for MFA CSPs. Standards including OIDC, SAML, and NIST SP 800-63 define protections for the assertions themselves, but do not detail operational controls for the system generating those assertions. Nor is there a compliance framework that commercial CSP operators can use to demonstrate that they are meeting minimum requirements.
Although well-designed MFA technologies are resistant to brute force attacks, failure to implement appropriate procedural and technical controls can result in the following:
Creating a copy of the private signing key which can then be used to generate assertions claiming to be any registered user of the CSP
- Causing the private signing key to be used to generate an assertion claiming to be a user without first completing MFA authentication
- Issuing an MFA credential without completing identity proofing actions, which can then be used to impersonate the legitimate user
Organizations should identify minimum operational requirements, and use these requirements both when developing their own on-premise CSPs or when selecting commercial CSP solutions.
Share on Facebook