These Are Not The LOAs (1+,2+,3+) You Are Looking For. Move Along

Requiring assurance commensurate with application or transaction risk has been a fundamental tenet when it comes to Levels of Assurance. In this blog post, I look at options to consider when there is a mismatch between assurance(s) available from token/identity/credential providers and the assurance needed by a relying party.

As I explore ways to separate token and attribute management functions, I find myself encountering situations where there is a mismatch between the assurances available and assurances needed, and a lack of clarity around what compensating controls could be used to manage the resulting risk.

Take as an example the situation below where the assurance available is Level 2, but the risk/impact evaluation that was done by the relying party (RP) resulted in a need for an assurance of Level 2+ (not quite Level 3). Which in turn leaves a risk that needs to be addressed if the RP wants to accept a Level 2 credential.

There are some who would like to address this mismatch from the token/credential side, but I believe that approach can fragment and muddle what standardized levels mean, and could result in proprietary definitions of Level 2+ or 2.5 or 2.75 etc.  Going down this path could dilute and potentially confuse the commonly used and accepted definition of LOA.

Looking for guidance in NIST SP 800-63-1 led me to the following paragraph:

Agencies may adjust the level of assurance using additional risk mitigation measures. Easing credential assurance level requirements may increase the size of the enabled customer pool, but agencies shall ensure that this does not corrupt the system's choice of the appropriate assurance level. Alternatively, agencies may consider partitioning the functionality of an e-authentication enabled application to allow less sensitive functions to be available at a lower level of authentication and attribute assurance, while mor sensitive functions are available only at a higher level of assurance.

While this provides a good opening, the lack of further details is profoundly unsatisfying.

I believe that when such situations arise, this should be addressed by the relying party as risk that needs to be managed and/or accepted. As a starting point, some valid mechanisms for addressing this risk include:

• Requiring compensating controls such as assurance level escalation multi-token e-authentication schemes
• Implementing a layered security program which uses different controls at different points in a transaction process
• Having clarity on risk tolerance, such that decisions can be made on whether to accept or reject a given level of risk

While further research and clearer guidance is needed, I have found the approaches and the language used in the FFIEC Authentication Guidance to Financial Institutions (PDF) and the Mitigation of Residual Risks section of the Government of Canada Guideline on Defining Authentication Requirements to be very helpful resources.

RELATED INFO

• HOW-TO Incorporate Risk Management into Assurance Level Determination
• NIST Electronic Authentication Guideline (NIST SP-800-63-1) (PDF)
• HOW-TO Conduct a Risk Assessment to Determine Acceptable Credentials
• NIST SP-800-63-1 Multi-Token Assurance Level Matrix
• Supplement to Authentication in an Internet Banking Environment (PDF)
• Gov of Canada Guideline on Defining Authentication Requirements - Mitigation of Residual Risks