By Greg Kent, Senior Vice President, CTO
CMMC requirements for multifactor authentication (MFA) seems to stump many SMBs. CMMC control IA.L2-3.5.3 requires Federal contractors to “Use multifactor authentication for local and network access to privileged accounts and for network access to non-privileged accounts.” But what exactly does this mean?
Understanding some NIST terminology is essential to understanding what this practice is all about. In NIST-speak, there are three types of logons: local access is a direct connection to the console that doesn’t require any networks, network access is a connection that passes over a network, and remote access is special type of network access that passes of untrusted external networks. This means that practice 083 requires MFA for all logins by administrators (e.g., local at the console, on-prem over a network, and remote from off-site) and also requires MFA for all general users for all network logons whether on-prem or remote from off-site. Essentially, the only type of login that doesn’t require MFA is a local login by a regular user, which is pretty much limited to a user’s workstation. All other logins (including if a regular user is using their workstation to access LAN resources) require MFA.
Furthermore, the definition of multifactor is important. MFA requires the use of two or more different factors, where the factors are something you know (password or PIN), something you have (a physical or soft token to produce one-time-passwords or smartcard), or something you are (fingerprint or retina scan). Using two passwords does not meet the definition of MFA because it uses one factor (something you know) twice. MFA must use two different factors. In addition, logging on from a company computer isn’t a second factor. Although a company-owned computer is something you have, it is not restricted to a particular user and therefore doesn’t authenticate that user. A source IP address doesn’t count as a second factor either. For most organizations, MFA consists of a secret password known by the user and one-time-password produced by a physical or soft token like Duo that the user possesses.
The MFA requirement applies to access to the information system, and therefore MFA does not necessarily need to be implemented on every single device or component in the environment if MFA is used properly to manage entry into restricted subnets of the in-scope system. For example, if backend infrastructure (such as servers, routers, etc.) is all stored in a restricted subnet that is reachable only through a jump server that is provisioned only to authorized administrators, and the jump server enforces MFA, then this would be sufficient for network logons. However, it is critical to apply MFA protection to all possible access paths into the system. For example, if a system is usually accessed internally but also has an external interface over the web, then it is essential to protect both the internal and external interfaces with MFA.
Selecting the right MFA solution is important for achieving compliance. The National Security Agency recently released a helpful guide for Selecting Secure Multi-factor Authentication Solutions. Pages 5-9 list various MFA solutions that are commonly used.
If organizations are looking for a cloud-based Identity as a Service (IDaaS) solution, it may be preferable to use only services that are FedRAMP authorized or at least meet the FedRAMP moderate baseline in order to comply with a risk-averse reading of the DFARS Safeguarding clause. DFARS clause 252.204-7012 expressly requires meeting requirements equivalent to the FedRAMP moderate baseline only for cloud providers that store, process, or transmit CUI. On its face, this requirement would not seem to apply to IDaaS services like cloud-based MFA providers. However, the CMMC program generally treats services that provide security services to protect CUI components as needing to comply with the same set of requirements as components directly handling CUI. The CMMC scoping guidance, for example, treats Security Protection Assets that provide security services for protecting CUI exactly the same as assets that handle CUI directly. Therefore, the most conservative approach is to prefer cloud-based IDaaS MFA solutions that meet the FedRAMP moderate baseline requirements. There are several products that have a FedRAMP moderate authorization, including Duo, Google, Microsoft Authenticator and Azure Multifactor, and Okta. Other products that don’t have a formal FedRAMP authorization may comply with the FedRAMP moderate baseline and therefore be acceptable as well. To re-iterate, equivalence to the FedRAMP moderate baseline is not expressly required by the DFARS clause for MFA cloud services, but this may be appropriate for very conservative, risk-averse organizations.
The NSA guide also identifies if the underlying cryptography used for authentication has been FIPS validated. For some use cases (including FedRAMPed cloud systems), this may matter, but FIPS validation of the cryptography underlying authentication technologies is not a requirement for CMMC. CMMC only requires FIPS validated cryptography for encryption that directly protects the confidentiality of CUI, as practice SC.L2-3.13.11 makes clear. Therefore, organizations subject to CMMC level 3 control practices are permitted to use MFA services like Microsoft Authenticator that are FedRAMP authorized (or equivalent to FedRAMP moderate) but are not FIPS validated. This is a less rigorous standard than is required for Federal cloud systems. The FedRAMP moderate baseline for control NIST SP 900-53 IA-2(11) specifically requires that the cryptography underlying MFA technology be FIPS validated. Fortunately, when the original 800-171 control set was defined, NIST determined that this control was uniquely Federal and therefore would not apply to contractor systems. Therefore, contractors do not need to worry about whether authentication services use FIPS-validate cryptography.