Multi-Factor Authentication (MFA) for NIST 800-171 Compliance (#3.5.3)

Updated: Feb 18, 2018

A common question is about how to best implement Multi-Factor Authentication (MFA) as part of NIST 800-171 compliance (requirement #3.5.3Use multifactor authentication for local and network access to privileged accounts and for network access to non-privileged accounts).


When you cut through the hype for MFA products, there are generally two ways to incorporate MFA:

  • Out-of-Band (OAB) (e.g., accept an alert on an app on your phone, receive a call or text message with a One-Time Password (OTP))

  • Cryptographic Token (e.g., digital certificate, keyfob, USB)

When it comes down to it, a company may have to incorporate more than one type of MFA to comply with NIST 800-171, since many businesses operate in a hybrid environment where some of their data is stored locally and some is hosted in the cloud. 


For companies with everything on-site and an Active Directory (AD) domain, using digital certificates is most likely the most painless and seamless way to incorporate MFA. However, that is generally not an option with most cloud providers, so OAB MFA solutions have to be considered for those environments. With hybrid models, it is likely going to be a mix of MFA solutions. However, determining the correct MFA technology comes down to two things:

  1. Know what your Controlled Unclassified Information (CUI) is!

  2. Once you know where your CUI is, know where your CUI is stored, transmitted and processed so you can segment it off from non-CUI data to minimize compliance scope!

If you are looking for a good, vendor-neutral place to start learning about MFA, a good reference is from the PCI Security Standards Council - information supplement on MFA from February 2017 - https://www.pcisecuritystandards.org/pdfs/Multi-Factor-Authentication-Guidance-v1.pdf  Since there are many similarities between protecting the Cardholder Data Environment (CDE) in PCI DSS compliance and protecting CUI with DFARS/NIST 800-171, it is worth taking a look at what the PCI Security Standards Council recommends for possible compliance solutions. After all, why reinvent the wheel?



Secure Controls Framework Council, LLC (SCF Council) disclaims any liability whatsoever for the use of this website or the Secure Controls Framework™ (SCF). Use at your own risk.

 

If you have compliance questions, you should consult a cybersecurity or privacy professional to discuss your specific needs. This website is for educational purposes only and does not render professional services advice - it is not a substitute for dedicated professional services. There is no endorsement of any kind in the company listing of SCF Solution Providers - It is entirely your responsibility to conduct appropriate due care and due diligence in selecting and engaging with a consultant to assist in your implementation of the SCF.

SCF Council does not warrant or guarantee that the information will not be offensive to any user. User is hereby put on notice that by accessing and using the website, user assumes the risk that the information and documentation contained in the web site may be offensive and/or may not meet the needs and requirements of the user. The entire risk as to the use of this website, or its contents, is assumed by the user. ​

 

SCF Council reserves the right to refuse service, in accordance with applicable statutory and regulatory parameters.

© 2019. Secure Controls Framework Council, LLC

TM

  • White LinkedIn Icon
  • White Facebook Icon
  • White Twitter Icon
  • White Google+ Icon