FFIEC and NIST Authentication Guidance. Does a Token Venn Diagram Exist?

The two sets of authentication guidance created by the US Government that are widely used in the private sector are the Federal Financial Institutions Examination Council (FFIEC) authentication guidance to financial institutions, and the NIST Electronic Authentication Guideline. This blog post takes a look at a sub-set of the guidance that is focused on what each deems acceptable for authentication controls and tokens.

The FFIEC guidance, while less prescriptive, provides a higher level view when it comes to protecting the end to end transaction using a combination of risk assessment, governance processes and technical controls which encompass areas such as device authentication and privilege management. The NIST guidance is much more explicit when it comes to requirements around identity proofing, authentication controls and tokens.

The thought that kept running through my mind when I was re-reading both documents was that if they were combined, and certain aspects were highlighted and if needed reconciled, it would provide an excellent and holistic approach to risk assessment, authentication, authorization and compensating controls.

But that is a substantial piece of work for another time, so without wanting to boil the ocean, I thought I would explore a potential area of overlap, which is the guidance regarding authentication tokens:

FFIEC	NIST
Authentication techniques should be commensurate with risk On going risk assessment that includes tracking and documenting changing threats, compensating controls to address those threats, and the determination of how likely the threats are is a requirement High risk transactions are those involving access to customer information or the movement of funds to other parties Since virtually every authentication technique can be compromised, FIs should not rely on any single control Layered security must be implemented which uses different controls at different points in a transaction process Dual customer authorization through different access devices is acceptable as part of a layered security program Anomaly detection and response to initial login and authentication is required as part of a layered security program Simple device identification using challenge questions are no longer effective	Based on traditional, widely implemented remote authentication methods based on secrets Defines technical controls for 4 levels of assurance taking into account consequence of authentication errors and consequence of misuse of credentials Approved token types are: Memorized Secret Token Pre-Registered Knowledge Token Look-up Secret Token Out of Band Token Single Factor (SF) One-Time Password (OTP) Device Single Factor (SF) Cryptographic Device Multi-Factor (MF) Software Cryptographic Token Multi-Factor (MF) One-Time Password (OTP) Device Multi-Factor (MF) Cryptographic Device

FFIEC

NIST

Authentication techniques should be commensurate with risk
On going risk assessment that includes tracking and documenting changing threats, compensating controls to address those threats, and the determination of how likely the threats are is a requirement
High risk transactions are those involving access to customer information or the movement of funds to other parties
Since virtually every authentication technique can be compromised, FIs should not rely on any single control
Layered security must be implemented which uses different controls at different points in a transaction process
Dual customer authorization through different access devices is acceptable as part of a layered security program
Anomaly detection and response to initial login and authentication is required as part of a layered security program
Simple device identification using challenge questions are no longer effective

Based on traditional, widely implemented remote authentication methods based on secrets
Defines technical controls for 4 levels of assurance taking into account consequence of authentication errors and consequence of misuse of credentials
Approved token types are:

Memorized Secret Token
Pre-Registered Knowledge Token
Look-up Secret Token
Out of Band Token
Single Factor (SF) One-Time Password (OTP) Device
Single Factor (SF) Cryptographic Device
Multi-Factor (MF) Software Cryptographic Token
Multi-Factor (MF) One-Time Password (OTP) Device
Multi-Factor (MF) Cryptographic Device

</div>

The one theme that is common across both is that single factor authentication is no longer sufficient for any type of high risk or higher LOA transactions, and the notion that using a combination of authentication factors (something a person knows, something a person has, something a person is) is stronger than use of one. The FFIEC Guidance Appendix from 2005 provides some concrete examples of acceptable tokens that overlap with token guidance in the NIST document.

I would be interested in any pointers to work that show a formal cross-walk between the two documents on this topic. Just as important, I am rather interested in which of the FIs (or their service providers) currently implement techniques that utilize multiple authentication factors.

RELATED INFO

This blog post first appeared on Anil John | Blog (https://blog.aniljohn.com). The opinions expressed here are my own and do not represent my employer’s view in any way.

Topic(s): Authentication.

By Anil John on February 16, 2013 06:00 PM | Permalink

FFIEC and NIST Authentication Guidance. Does a Token Venn Diagram Exist?

About

Organizations I Support

Continue The Conversation ...

About

Organizations I Support