Selecting the Right Encryption Module is Critical to a Successful CMMC ML3 Assessment
Authored by Jim Goepel and Levi Kapilevich of NeQter Labs
Background
The Cybersecurity Maturity Model Certification (“CMMC”) program created by the US Department of Defense (“DoD”) is undergoing internal reviews that may reshape portions of the CMMC Model, CMMC Assessment Guides, and even the CMMC Ecosystem. At the same time, the Whitehouse’s recent Executive Order on Improving the Nation’s Cybersecurity may see CMMC adopted throughout the entire federal government on a timescale previously not anticipated.
Many contractors are watching closely to see what will happen. For some, typically organizations for which service both the government and corporate sectors, a “wait and see” approach may be the most prudent. These contractors are willing to make the appropriate investment, including lost productivity due to executives and employees having to be refocused on cybersecurity training and decisions, tool acquisition, and even consulting services, but it is difficult to determine what is “appropriate” when the standard is uncertain. So they are setting aside funds and accelerating certain work now so that, when things settle some, the organization will be ready to move.
While that approach can work for some organizations, there are many contractors out there who depend heavily on their government contracts. For them, anticipating the government’s requirements or needs is critical to ensuring their organizations can compete for those contracts that are the organization’s life blood. They have already analyzed their environments and determined whether they will need to be certified at CMMC Maturity Level 1 or Maturity Level 3, and they are conducting a gap analysis of their cybersecurity programs against NIST SP 800-171 using SP 800-171A.
As these organizations conduct their gap analysis, they are bumping into a variety of issues and they, naturally, seek feedback from various sources on the Internet. Unfortunately, not all the information they find is accurate.
Encryption
One area where there is a lot of confusion is encryption, and specifically what types of encryption will be acceptable under CMMC. Before we address this, let’s take a quick look at encryption and why not all forms of encryption are the same.
Encryption is the process of encoding information such that it is only readable by the intended recipient. Some encryption techniques, or cyphers, use simple letter substitution. For example, in a ROT13 cipher, the letter A is replaced by N, B by O, C by P, etc. If you used ROT13 to encrypt the word “hello”, the resulting ciphertext, or encrypted message, becomes “uryyb”. As you can see, encryption makes it harder for an unintended recipient, like a courier or someone intercepting messages on the Internet, to decrypt the message unless they know or can guess the “key” to decipher the text.
As a practical matter, while ciphers like ROT13 are useful in some contexts, they aren’t very secure. The keys are easily identified by today’s cryptography analysts and computers. That means that many more people than just the recipient can decrypt the ciphertext. Thus, we need more advanced techniques for ensuring that highly sensitive information is properly encrypted.
Mathematicians and other researchers have recognized the need for enhanced encryption and have created some techniques that make it exceptionally difficult for most computers to guess the decryption key. For example, the odds of guessing a 256-bit Advanced Encryption Standard (“AES”) encryption key is approximately one in one billion billion times the number of atoms that make up the earth (i.e. roughly 1 in 1.1 x 1077). However, much like ROT13, not all encryption techniques are created equal. Some have fundamental mathematical errors that reduce what would otherwise be essentially infinitesimally low odds of guessing the key to something that could be guessed in a matter of days to years of computing time. While that may still sound like a long time, some information is valuable enough that entrusting it to a weak encryption technique doesn’t make sense.
FIPS-Approved Encryption Techniques
The US government has a lot of information that they want to protect, and they regularly review existing encryption techniques to see whether there are flaws in those techniques. As a result, they, through the National Institute for Standards and Technology (“NIST”, part of the Department of Commerce), have selected certain encryption techniques that they are confident can withstand most decryption attempts. These are defined in a NIST publication referred to as the Federal Information Processing Standards (“FIPS”) 140-2 and its successor, FIPS 140-3. The approved encryption techniques vary depending on the use case, and include AES, Triple-DES, and the Digital Signature Standard (“DSS”).
FIPS-Validated Encryption Modules
AES, Triple-DES, DSS, and the other encryption techniques each specify algorithms and other techniques that must be implemented by any software or hardware developer that wants to adopt those techniques. Historically, different developers would write their own code that implemented the encryption technique. Unfortunately, this led to many implementations with flaws, or bugs, that allowed attackers to more easily decrypt the information. As a result, NIST also created a government-sponsored process for testing the software “modules” containing those different implementations. These “FIPS-validated encryption modules” are the backbone of a secure, encrypted information storage and communication system. NIST runs a program called the Cryptographic Module Validation Program (“CMVP”) which publishes a list of FIPS-validated encryption modules at https://csrc.nist.gov/projects/cryptographic-module-validation-program/validated-modules.
Although some software and hardware developers still develop their own encryption modules, many reuse encryption modules that are already validated by NIST. For example, some developers will use the opensource BC-FJA module published by the “Legion of the Bouncy Castle Inc.” or the Microsoft Cryptographic Primitives Library. Using these publicly available modules streamlines the developers’ time to market and helps ensure the product meets the developers’ clients’ needs.
When organizations enter into a contract with, and again when they request payment from, the US Department of Defense, they attest that they do/will meet all contractual requirements. For those organizations handling Controlled Unclassified Information, this includes meeting the requirements defined in DFARS 252.204-7012 (the “-7012 clause”). The -7012 clause requires organizations to assess their cybersecurity programs against NIST Special Publication 800-171 (“SP 800-171”) using the techniques defined in NIST SP 800-171A. SP 800-171, in turn, includes requirements that all cryptographic modules used in the organization’s environment be FIPS-validated (see, e.g., 3.1.13 and 3.13.11). CMMC also adopts FIPS-validated encryption requirements for CMMC Maturity Level 3 certification (see, e.g., AC.3.014, SC.3.177). So, all organizations handling CUI must use FIPS-validated encryption modules when encrypting information.
Applying the FIPS-validated Encryption Requirements
Clearly, it is important to know whether the encryption module(s) your organization is relying upon to safeguard CUI meet the FIPS 140-2 requirements. So, how do you do this?
Start by Understanding how CUI Moves in your Environment
If you are following the CMMC Assessment Lifecycle, your first step was to create an inventory of all of your organization’s systems and information. This includes how the information flows into, within, and out of your organization. This information is critical to determining which systems and equipment (e.g., WiFi, hubs, routers, switches, etc.) are required to use FIPS-validated encryption; any systems or equipment that handle CUI must meet these requirements.
As an example, imagine that Brenda runs a five-person surveying company. The employees all collect detailed surveying information that their government customers consider to be CUI. When the employees are in the field, they use Microsoft Windows 10-powered laptops to acquire and process the survey data from the survey equipment. When they aren’t in the field, the employees all work from the office. The survey information is uploaded to a Microsoft Windows Server 2016 file server in the office for storage, sharing, and backups. Brenda is working her way through a self-assessment against NIST SP 800-171 and saw that she is supposed to use FIPS-validated encryption to protect the information as it is stored and as it moves in the office environment.
Cryptographic Modules, not Cryptographic Devices
While she is conducting her gap analysis, Brenda is visited by Rob, a salesperson for a computer hardware vendor. Rob tells Brenda that since her laptops aren’t FIPS-validated, they won’t meet the NIST SP 800-171 assessment requirements and her company won’t be certified at Maturity Level 3. Is Rob right? Not according to NIST. As they mention:
It is important to note that validation certificates are issued for cryptographic modules. A module may either be an embedded component of a product or application, or a complete product in and of itself. If the cryptographic module is a component of a larger product or application, one should contact the product or application vendor in order to determine what products utilize an embedded validated cryptographic module. There are inevitably a larger number of security products available which use a validated cryptographic module than the number of modules which are found in this list. In addition, it is possible that other vendors, who are not found in this list, might incorporate a validated cryptographic module from this list into their own products.
As NIST describes it, Brenda needs to validate that the encryption modules, not the devices themselves, need to be FIPS-validated. As long as all of the CUI is encrypted using only FIPS-validated modules, then FIPS validation is not necessary at the device level.
Reviewing the Modules
Once Brenda throws Rob out of her office, she should examine how her employees’ files are transferred to the server. If Brenda’s company uses a tool that automates the file transfer, she should reach out to the tool vendor to determine what “protocol,” or method, is used during the transfer, whether encryption is enabled in the protocol, and whether the encryption module used in that protocol is FIPS-validated. Assuming the answer is that the encryption module is FIPS-validated, it would be wise for Brenda to ask for a letter certifying this fact, including a description of the specific FIPS-validated module that is used.
Maintenance vs. Module Approval
What if the tool developer says that they are using a newer version of a previously-validated encryption module, but that the new version hasn’t been validated? Does that mean the tool cannot be used? The DoD CUI FAQs address this:
The requirement at DFARS clause 252.204‐7012 (b)(2)(i) to implement, at a minimum, the security requirements in NIST SP 800‐171, is not intended to imply that there will not be situations where elements of the NIST SP 800‐171 requirements cannot practically be applied, or when events result in short- or long-term issues that have to be addressed by [] assessing risk and applying mitigations. The rule allows a contractor to identify situations in which a required control might not be necessary or an alternative but equally effective control can be used, and the DoD CIO will determine whether the identified variance is permitted, in accordance with DFARS provision 252.204‐7008(c)(2)(i) and (ii) and DFARS clause 252.204-7012(b)(2)(ii).
In addition, the dynamic nature of cybersecurity threats and vulnerabilities is recognized within the NIST SP 800‐171. The contractor should address situations such as those listed above in accordance with the NIST SP 800‐171 security requirements…”
In short, DoD recognizes that there are times where the practicalities of life, such as needing to upgrade to a newer version of software that fixes a known vulnerability, will outweigh the specific requirements defined in NIST SP 800-171. What is important is that contractors like Brenda include in their System Security Plans and other documents mechanisms for tracking any variations and ensuring they are closed within timeframes set forth in the documents once appropriate fixes are available. If fixes aren’t available within a predefined period of time, the contractor should begin evaluating alternative tools.
Doing it Yourself
While some contractors may use a tool to synchronize/move files from one location to another, many contractors will do this manually. In such cases, the contractor will need to ensure that their systems have appropriate encryption enabled. In Brenda’s case, files transferred between employee laptops and the Windows Server use the SMB protocol by default. Brenda can follow the steps described by Microsoft to ensure encryption is enabled by default. According to Microsoft, SMB3 (the latest version of SMB) must be enabled, and both the workstations and servers must be operating in FIPS mode, for the data in transit to be properly encrypted.
As we discussed above, it is important to understand how CUI flows into, within, and out of your organization so you can ensure that FIPS-validated encryption is utilized at all steps along the path. If, for example, Brenda used a combination of both automated file synchronization tools and manual processes but only analyzed the manual processes, her organization may not pass a CMMC assessment.
Summary
Some vendors are suggesting that the only way to comply with NIST SP 800-171 is to throw out your old equipment or software and to buy theirs. They will point to the fact that your existing equipment or software is not listed on the NIST CMVP list as evidence that your equipment won’t meet the CMMC/NIST SP 800-171 requirements. In some cases, such as where your equipment does not use a FIPS-validated encryption module, they may be right. But in many cases, since compliance is determined at the encryption module level rather than at the device or software level, the fact that the device or software isn’t listed on the CMVP list is not, on its own, enough to prove that your current equipment or software will not meet the NIST SP 800-171/CMMC requirements. You can save yourself significant time, money, and effort by contacting the vendor who makes your current equipment or software to determine whether a FIPS-validated encryption module is in use, or can be activated, and that all information will flow through that module. So, don’t throw out your equipment or software until you have done some diligence.