“The CMMC practices (or NIST 800-171 controls, as the majority of CMMC practices in version 1 of the model flow directly from NIST 800-171 controls) are clearly stated, so they are easy to implement.” This might be one of the biggest misconceptions within the CMMC ecosystem. In fact, the CMMC practices can read as deceptively simple if you don’t know how to interpret them. This can lead organizations to falsely believe that they are prepared to meet the practices when they may not be. I think this confusion stems from a few causes—the practices and objectives are very concise, they rely on other references, they assume knowledge of information system assessment (and more specifically, federal information system assessment), and they assume knowledge of maturity models. Disclaimer: CMMC is in the process of streamlining the maturity levels from a system with 5 levels numbered 1 through 5 to a system of 3 levels, numbered 1 through 3. In the examples below, we are pulling from the CMMC 1.10 documentation which contained 5 levels. When we reference ML 3 below, that is what will become Level 2 in the CMMC 2.0 framework once it is published. At this time, there is no equivalent document for CMMC 2.0 available. In an effort to demystify a practice derived from NIST 800-171, let’s walk through a practice mandating multi-factor authentication, IA.3.083. This is a practice that is required in Maturity Level (ML) 3. The “3” after the practice family “IA” quickly informs us that it is a “Level 3” practice. Let’s dive in to the CMMC Assessment Guide, Level 3. What is the control? On page 178 of the PDF (labeled page 166), we read the statement “Use multifactor authentication for local and network access to privileged accounts and for network access to non-privileged accounts.” Is this the same “multifactor” I’m used to from commercial websites? Before we address the assessment objectives, let’s dive into “multifactor.” Many readers may think they know exactly what “multifactor” means because many websites offer multifactor authentication. Multifactor authentication is defined in the discussion as “something you know, something you have, or something you are in the case of biometric.” The simple example for “something you know” is a password, and this is acceptable (of course, following appropriate password complexity and password change requirements not covered in this article). Many consumer websites send you an SMS message or telephone you with an automated voice code.” to satisfy the “something you have” component. What if you built your whole information system around SMS messages or codes provided via telephone? This path is likely to cause concerns for your assessment because the SMS codes or automated telephone calls are not protected from eavesdropping or redirection. They have never been the most secure method of something you have (since the one-time code can be taken by others through a variety of attacks). As an alternative to phone or SMS tokens, a separate hardware-based token is a reliable and relatively inexpensive option that removes the possibility of eavesdropping and code interception. The CMMC practice doesn’t directly state this though, so you need to derive this from the requirements. At the end of the Discussion section, there is a reference to NIST 800-63-3 (which in turn references NIST 800-63b), and these are not silent on the use of SMS codes or telephone-based automated calls. When you read Section 4.3.1 of NIST 800-63-3, you will notice that NIST 800-63-3 mirrors the text in the Discussion very closely, with the exception of the addition of the text, “token.” How do I select an Authenticator Assurance Level? NIST 800-63-3 references NIST 800-63b for the details of Authenticator Selection. Section 6 discusses risk assessment to determine the minimum “Assurance Level” that is acceptable for that impact. Since organizations with CUI are trying to prevent the release of sensitive data, this implies that the minimum Authenticator Assurance Level (“AAL”) is 2 (Table 6-1 of NIST 800-63-3) and the flowchart in Figure 6-2 (“Selecting AAL”) depicts this graphically. For the risk of “unauthorized release of sensitive information”, AAL2 is appropriate for low or moderate risk, and AAL3 is appropriate for a high risk. Other combinations of risks may result in AAL3, even if the risk of “unauthorized release of sensitive information” is only moderate. A misclassification of risks will result in too low of an Authenticator Assurance level being selected. This decision should be reached with the organization’s risk management and legal counsel, and this article is not attempting to provide risk classification guidance. Under AAL2, “Out-of-band” secondary factors (e.g., SMS one-time codes or automated telephone calls with code) are appropriate as the second factor to a memorized secret (a password would be an example of a memorized secret). However, SMS or automated calls are listed as “Restricted Authenticators” (NIST 800-63b Section 126.96.36.199 and Section 5.2.10). Restricted Authenticators have several requirements, including, but not limited to, offering subscribers an alternative authentication method, providing them notice of the security risks of using the Restricted Authenticator (SMS or voice), and developing a migration plan away from the Restricted Authenticator. Since using a “Restricted Authenticator” subjects you to offer a more secure alternative, there are few scenarios that suggest that offering a Restricted Authenticator is a logical choice; rather, cost, training, and documentation efficiency suggest offering more secure authenticators instead of a Restricted Authenticator and a more secure alternative, thus simplifying your environment. To summarize Authenticator Assurance Level selection, if you are attempting to architect an information system that will best position you to meet compliance objectives, irrespective of the risk characterization of your sensitive data, selecting an AAL 3 authenticator will result in less risk to your information security program. The cost-savings are realized because, ideally, you can train your staff on a solution that will be usable for some time into the future, rather than changing authenticators after a year or two, and you will not replace AL2 authenticators prematurely. Objectives Moving to the objectives sets the scope of the practice. Objective “a” requires you to define your privileged accounts for every component of your information system—your cloud provider, your directory (Active Directory, openLDAP, etc.), and in scope applications like SharePoint Online, etc. This seemingly simple request can touch a number of components in your environment. Obviously, using a centralized directory service and minimizing the number of local accounts will simplify part a and even make other practices easier to meet. You might define your privileged accounts by roles for each component, further simplifying the task of maintaining this documentation. Moving to objective b, you need to document and be able to demonstrate that multifactor authentication is implemented for local access to privileged accounts, such as an Administrator account on an endpoint that contains CUI. Again, this requirement applies to all in-scope components in your information system. Objective c requires documentation and implementation of multifactor implementation for network access to privileged accounts, such as an Administrator account for an endpoint with CUI, over the network. Objective d requires documentation and implementation of multifactor authentication for network access to a non-privileged, or traditional user account via the network, such as login to a VPN or an endpoint with CUI. Like the other objectives, this needs to be implemented for all of the components within the scope of your information system. Hopefully, this article helps you interpret CMMC practices, use the Discussion section and references, and apply the practices to the components within your information system(s) that are in-scope. Reach out to the team at Regola Cyber for help tailoring an MFA solution to your organization’s needs. Nathan Regola, Ph.D. J.D is the President and Principal Consultant of C3PAO candidate Regola Consulting, Inc. dba Regola Cyber.