In continuation of our “What the heck?” series, we explore another NIST 800-171 control that has resulted in confusion for DoD contractors pursuing CMMC compliance. This time, we look at “replay-resistant authentication mechanisms”, found in Identification and Authentication control 3.5.4. In this post, we’ll interpret this requirement in lay terms, and we will provide examples for implementation as you look to protect your Controlled Unclassified Information (CUI). If you are looking for additional help with meeting the DFARS 252.204-7012/NIST 800-171/CMMC requirements, grab a seat in our next Workshop!
Overview of identification and authentication
Identification and authentication not only comprise an entire control family within NIST 800-171, but they are also fundamental building blocks of a sound cybersecurity posture, regardless of industry or regulatory requirements. Identification refers to the process of discovering the identity of a user or item (the “subject”) attempting to access an asset (system, device, information, facility, etc. — the “object”). The simplest example of an identity in IT is a username, e.g. “[email protected]”. But there are other examples of identities. For instance, a router identifies a mobile device attempting to connect to a wireless network. Or, a domain controller identifies a user attempting to access a file server. In either case, identification occurs when the subject presents themselves in order to access an object.
Authentication refers to the process of verifying the identity of the subject attempting to access the object. Does the user/device/process have the credentials to access the object? Or, rather, are the credentials supplied legitimate? Authentication ensures that only identities that are permitted to access an object can do so. To continue with our simple example, Jane Doe provides both her username “[email protected]” as well as her password at a login prompt to access her computer.
Given the evolving cybersecurity threat landscape, gone are the days where just one authentication factor is needed to verify one’s identity. Now, requiring multiple factors (hence “multi-factor authentication” — MFA) is the gold standard, and one of the easiest ways to protect your information.
This post is about replay-resistant authentication, not multi-factor authentication, though there is some overlap between the two, as we explain later on. Either way, you’ll need both to pass a CMMC Level 2 assessment. For more information on the former, read on!
Replay resistance requirements and scoping
Now that we understand the fundamentals of identification and authentication, we can explore the specifics of replay resistance. First, a look at the only NIST 800-171 control that mentions replay-resistant authentication:
Employ replay-resistant authentication mechanisms for network access to privileged and non-privileged accounts.
Followed by the single corresponding assessment objective for this control:
Replay-resistant authentication mechanisms are implemented for network account access to privileged and non-privileged accounts.
The driver behind this control is a type of Man-in-the-Middle cyberattack known as a replay attack, and hence why the objective is replay resistance. The mechanism of a replay attack is simply to capture information sent between two parties, then, upon capturing this information, to store or alter the information before later “replaying” it. The goal of a replay attack may be to disrupt legitimate communication or to gain unauthorized access to a system. In the case of a replay-resistant authentication mechanism, it’s exactly as it sounds: establish an authentication method for a user/process that can withstand a replay attack.
For example, say a user wants to access their cloud-based CUI file storage platform. They browse to the platform’s URL, insert their credentials, and login. However, while this was taking place, an adversary has been — using freely-available tools — spying on this user’s session and sniffing (capturing) all network traffic between the user’s device and the storage platform’s server. From the captured traffic, the adversary discovers the user’s password hash (a hash is most commonly used to verify correct passwords, as opposed to transmitting the password itself) and stores it. At a later time, the attacker uses (replays) the password hash to authenticate into the CUI file storage platform as though they were the user.
This is not the only way that a replay attack could be carried out. For instance, an attacker may look to capture factors other than a password hash to gain unauthorized access, including:
- One-time passcodes
- Radio-frequency identification (RFID) signals where RFID technology is used
- Payment card information
As it relates to CMMC compliance, the purpose of IA.L2-3.5.4 is to reduce the risk of a successful replay attack and prevent CUI from being compromised. NIST 800-171 is not strict in terms of which replay-resistant authentication mechanisms are to be used, only that they must be applied for all network access to privileged (administrative) and non-privileged accounts. Because this is a Level 2 control (as indicated by the “L2” in the control ID), it only applies to protecting CUI, not all Federal Contract Information (FCI). So, while using replay-resistant tactics is a good idea from a cybersecurity risk management perspective, it’s only required for network access where CUI is being processed, stored, or transmitted.
Given this, the scope of where you need to apply replay-resistant authentication mechanisms will depend upon how and where CUI is flowing throughout your environment. If you have yet to scope your environment and determine your CUI lifecycle, we recommend you pause here and go do that. It will save you a lot of time (and likely money) in the end.
If you are confident in your CUI scope, you should have a good idea where replay-resistant authentication mechanisms will be needed. For some small businesses we’ve engaged with for a Gap Assessment, this has been across nearly their entire network, as CUI is/was allowed to pass without much restriction (whether intentionally or by accident). For others, especially those leveraging a CUI enclave, replay-resistant authentication was only needed when authenticating into the enclave and any other web applications where CUI was being stored/manipulated.
Replay-resistant authentication mechanisms
In some cases, enabling replay-resistant authentication mechanisms is as simple as the flip of a switch; in others, more robust tech may be needed. It will depend on your CUI scope. In general, the more you permit CUI to flow throughout your environment, the greater the level of effort required to protect the CUI. Sticking with the two examples presented in the previous section, one where a small business permits CUI to flow more freely across their network and another where a CUI enclave is leveraged, we’ll demonstrate where replay-resistant authentication mechanisms will be needed, and which mechanisms could be used.
For the former, we’ll assume that this organization utilizes a centralized domain management tool such as Windows Active Directory. The organization has a few remote users that use a remote access VPN to access the organization’s file server and the CUI stored within. The rest of the staff work at the organization’s corporate headquarters, and all workstations are enrolled in the domain. A rudimentary data flow diagram could look something like this:
In this example, “network access”, as called out in IA.L2-3.5.4, would include the users (in-person and remote — privileged and non-privileged) that connect to the corporate network AND have access to CUI. A mechanism must be used that grants replay resistance when these users authenticate to the network. In this case, since the organization uses centralized domain management through Active Directory (AD), the simplest solution to achieve replay resistance would likely be to leverage Kerberos, an authentication protocol that uses a key distribution center (KDC) to verify and authenticate users, across the entire domain. Kerberos is not strictly a Windows authentication protocol; it can be used on Linux and Unix systems as well. However, it is the default authentication protocol used in AD domains.
Kerberos, by design, provides replay resistance. This is because it uses authentication “tickets” that expire after use, preventing an attacker from sniffing and replaying later, as shown in the initial replay attack diagram. However, for whatever reason, occasionally Active Directory won’t properly negotiate an authentication through the Kerberos protocol, and it may default to another authentication protocol such as LM, NTLM, or NTLMv2. None of these protocols provide replay resistance, which is why we recommend that if you utilize Kerberos, you also audit for the use of LM, NTLM, or NTLMv2 when users authenticate. An assessor will likely ask to see this objective evidence as part of your CMMC assessment.
If your approach to protecting CUI in accordance with CMMC requirements involves the use of an enclave, your data flow diagram is likely much more simple. For example, those using Totem’s Zero Client as a Service™ (ZCaaS) would flow CUI in the following manner:
Using this model, implementing replay resistance becomes much simpler, given the limited flow of CUI. Users only authenticate at two points: into the ZCaaS™ Browser and into ZCaaS™ SafeShare. To ensure that this session (or any other enclave solutions that rely on the use of web applications) is replay resistant, the app must be configured to require Transport Layer Security (TLS) version 1.2 or higher via HTTPS. Previous versions do not provide replay resistance and have long been deprecated.
To further strengthen replay resistance, in addition to engaging TLS, any web applications where CUI is being handled must also enforce the use of multi-factor authentication. Two separate NIST/CMMC requirements (IA.L2-3.5.3 and MA.L2-3.7.5) govern this already, but MFA is crucial to ensuring replay-resistant authentication. For example, if an adversary is able to sniff a user’s password, but doesn’t know the one-time MFA passcode, they won’t be able to successfully authenticate. However, MFA doesn’t completely eliminate the risk of a replay attack; it only lowers it. An MFA token, like a password, can still be sniffed. Using TLS 1.2 (or higher) + MFA is a great defense-in-depth approach that satisfies multiple NIST 800-171 safeguards, including replay resistance.
As we have assisted hundreds of small businesses on their CMMC compliance journey, these two methods for ensuring replay resistance are the most common. However, these are not the only options. Some other methods for consideration include:
- A challenge-response mechanism such as CAPTCHA
- A nonce (number used once)
- Digitally signing authentication messages
In the end, your organization’s approach to replay resistance should be whichever option fits best into your CUI scope and enables the organization to achieve its strategic initiatives.
Wrapping up
In this post, we dissected the NIST 800-171 requirement for implementing replay-resistant authentication. Additionally, we provided examples for implementation in the typical small business environment.
If you are a small business DoD contractor that would like additional help in your pursuit of a CMMC certification, we invite you to grab a seat in our next Workshop! Or, consider engaging us for a Gap Assessment, where we can do the heavy lifting interpreting the requirements to fit into your unique environment. If you have any questions about this blog, CMMC, or cybersecurity in general, drop us a line!
Keep fighting the good fight!
–Nathan
