Anil John
Making Digital Services Secure and Trustworthy

Anil John

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

 Tweet  Share  Share  Comment  Print  Email

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:

FFIECNIST
  • 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

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


Did you find this interesting? Don't miss any new posts. Sign up to automatically receive them now!

I will never share, rent, or sell your information to anyone. Cancel anytime.

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):
By on |

Continue The Conversation ...

I would love to know your thoughts on this blog post. Please leave a comment below!

I am a digital security coach. I help technical leaders make digital services secure and trustworthy. Learn more »

Free Updates

I will never share, rent, or sell your information to anyone