For Department of Defense (DoD) contractors and subcontractors pursuing compliance with the Cybersecurity Maturity Model Certification (CMMC), few controls have been as challenging (and costly) to address as those concerning FIPS 140-2 validated cryptography. In this post, we dissect the FIPS-validated cryptography (“FIPS validation”) requirements under NIST SP 800-171, and we discuss strategies for small businesses to consider as they build their CMMC-compliant cybersecurity programs.
Be sure to grab a copy of our FIPS-validated cryptography scoping template, which you can download for free at the end of this post.
An overview of FIPS-validated cryptography
If you are just beginning to wade through CMMC waters, it’s helpful to first understand the purpose of cryptography before diving into the deep end of FIPS validation. Cryptography, derived from the Greek word kryptós (hidden; secret), refers to the practice of using mathematical algorithms to create secure communication among authorized parties. Cryptography is a necessary component of any defense-in-depth cybersecurity program, as it helps preserve the confidentiality of sensitive information such as Controlled Unclassified Information (CUI). Whether your sensitive data is stored at rest or is in transit across the Internet, cryptography reduces the risk of an adversary gaining unauthorized access to your data by making it very difficult to read.
Encryption is the process of applying a cryptographic algorithm on data (the “plaintext”) to transform it into a form (the “ciphertext”) discernible only by authorized parties. The most widely used and trusted symmetric cryptographic algorithm available today is the Advanced Encryption Standard (AES). Encryption algorithms such as AES determine how data is transformed from its plaintext to its ciphertext form, and can be configured with varying key lengths (e.g., 256 bits) for increased security.
For example, using AES to encrypt the phrase (plaintext) “This text is super secret Controlled Unclassified Information (CUI).” with a password (key) of “Oh geez CMMC is the bee’s knees!” gives the indecipherable output (ciphertext): “39197A48246A21C918EA18822A465AC68A9A8EF9DA9EE3FC722EBE25B63BB6BB2ADF9482849 55E1C80A3A364E73CC1CD7B70C93187006A61BA64E6711C227358E86A5FCDDDABC01A5E9B9 3EA495C5B53”
And anyone who possesses the ciphertext and key can run the AES algorithm in reverse to reveal the plaintext. The “key” to encryption is the key. Keys are by their nature plaintext, so it is vitally important to protect the key and only share it with authorized parties.
As computer processing power increases, however, the easier it becomes to crack any given encryption algorithm, i.e. discover the key without foreknowledge. Hence, it is necessary that the complexity and reliability of encryption algorithms stay a step ahead of modern-day processing power capabilities, especially keeping an eye on the rise of quantum computing (NIST recently announced four quantum-resistant cryptographic algorithms). While this is outside the scope of CMMC and FIPS validation right now, Defense Industrial Base (DIB) members should expect that encryption requirements will likely change over time in order to meet emerging risks, especially those presented by quantum computing.
Having established a baseline understanding of cryptography, encryption algorithms, and cybersecurity risks surrounding cryptography, we can turn our attention to FIPS validation. A common point of confusion with respect to FIPS validation is that many confound cryptographic algorithms with cryptographic modules. The CMMC requirements for FIPS-validated cryptography pertain to the modules, not just the algorithms. NIST defines a cryptographic module in the following manner:
"The set of hardware, software, and/or firmware that implements security functions (including cryptographic algorithms), holds plaintext keys and uses them for performing cryptographic operations, and is contained within a cryptographic module boundary. This Profile requires the use of a validated cryptographic module as specified in [FIPS 140]."
So, a cryptographic “module” is the hardware or software implementation in a technology product that executes a cryptographic algorithm. The module is more than just the algorithm itself. We will flesh this out further in the coming sections, but some examples of cryptographic modules include:
- Standalone encryption software, such as WinZip, used to encrypt files resident on a workstation
- Hardware circuitry built into a router or firewall used to establish a VPN
- Software services engaged by a cloud-based web server to encrypt information transiting the internet
A FIPS-validated cryptographic module is one that has been tested and approved by a NIST-approved laboratory per the Federal Information Processing Standard (FIPS) 140-2 U.S. Government standard. (While the FIPS 140-2 standard was initially released in 2001, it actually has been superseded by a newer FIPS 140-3 standard, though 140-2 remains the DoD’s requirement for protecting CUI. While still uncertain right now, the FIPS 140-3 standard may appear in the upcoming NIST 800-171 Revision 3.)
Encryption technology vendors that wish their product to receive FIPS validation must request a NIST approved lab to test the cryptographic module embedded in its technology product. The lab performs tests essentially to ensure the product’s hardware or software has effectively implemented the encryption algorithm and does not inadvertently allow an attacker to recover the encryption key or bypass the key altogether and glean plaintext from ciphertext. As you can imagine, this testing is both time consuming and expensive — we’re talking months and hundreds of thousands of dollars typically. Thus, a vendor must be seriously committed to providing a product in a specific market where FIPS validation is required, such as protecting government information. “Fly-by-night” tech vendors (e.g. makers of cheap WiFi routers) typically don’t pursue FIPS validation for their products.
When a module successfully passes the testing, NIST assigns it a certificate under the Cryptographic Module Validation Program (CMVP). Therefore, when a vendor claims to have FIPS-validated cryptography, they should be able to point an inquirer to the specific CMVP certificate. More on this below.
Now you know what FIPS validation is. If you’re interested in learning more about how this requirement affects small business DoD contractors, read on!
Which NIST 800-171 controls address FIPS-validated cryptography?
In this section, we will look at the NIST 800-171 controls that deal with FIPS validation. We must preface this by stating that the requirements for FIPS-validated cryptography can be implemented 100 different ways for 100 different organizations. There is no one-size-fits-all approach. If you read through these requirements and are uncertain where to start, we recommend you grab a seat in our CMMC/NIST 800-171 Workshop, where we can help you interpret the FIPS validation requirement in your unique environment.
SC.L2-3.13.11
The chief requirement for FIPS validation in NIST 800-171 comes from System & Communications Protection safeguard 3.13.11:
Employ FIPS-validated cryptography when used to protect the confidentiality of CUI.
SC.L2-3.13.11
This is the only control in 800-171 to explicitly have the word “FIPS” in the control text. While at first glance it appears somewhat vague, this safeguard underlines a crucial aspect of implementing FIPS validation. FIPS-validated cryptography is required for protecting only CUI; for less sensitive information types (such as Federal Contract Information — FCI), it is not required. This should have significant implications for how you consider building out your CMMC-compliant cybersecurity program. If only a very small subset of your organization handles CUI, you may be able to isolate the CUI (likely through an enclave) such that FIPS-validated cryptography is only necessary within that isolated environment. Understanding that it is not a viable option for all DIB members, CUI isolation could keep your organization from having to implement FIPS-validated cryptography across your enterprise where it may not be needed. This is important since meeting the FIPS-validated requirement often means rearchitecting and/or upgrading technology–both of which are typically very expensive.
Employing FIPS-validated cryptography to protect CUI makes two very large assumptions, both of which many contractors have yet to do:
- The organization has identified the specific CUI elements they handle and characterized the lifecycle of the CUI throughout their environment
- The organization has identified the assets (hardware, software, people) facilitating the flow of CUI
This process of identifying sensitive information flow and the assets to be protected is known as “scoping”, and it is a necessary first step to CMMC compliance. To help contractors with their CUI scoping, the DoD released the CMMC Scoping Guide in 2021. This is a worthwhile and surprisingly easy-to-read document which ultimately may influence how you approach the SC.L2-3.13.11 requirement. Ensure that your CUI scope is complete before addressing FIPS validation.
SC.L2-3.13.8
If SC.L2-3.13.11 was the only control for implementing FIPS-validated cryptography, this would be concerning. We would ultimately conclude that wherever CUI is being stored or transmitted, those assets must be FIPS-validated, regardless of other protections that may be in place. Thankfully, we are given some context in another requirement, SC.L2-3.13.8:
Implement cryptographic mechanisms to prevent unauthorized disclosure of CUI during transmission unless otherwise protected by alternative physical safeguards.
SC.L2-3.13.8
Translation: when protection of the confidentiality of CUI cannot be adequately guaranteed, particularly through physical security safeguards — such as locks on doors and windows at a corporate headquarters facility — FIPS-validated cryptography is required. However, even in such a “brick and mortar” facility, in cases where remote access (such as Wi-Fi; see next control description) is permitted, confidentiality of CUI cannot be adequately guaranteed, so FIPS-validated cryptography is necessary. Additionally, when CUI is stored or transmitted outside the “protected environment”, such as when CUI is sent to a cloud-based file server, FIPS-validated cryptography is required. See the example diagram below, where CUI flows throughout a brick-and-mortar organization that does not permit remote access to its corporate network:
Given that the mobile devices/workstations store CUI and can be transported outside of the facility, the encryption used to protect the data at rest (e.g. files) on those devices needs to be FIPS-validated. Because the corporate facility creates a protected environment, and remote access is not permitted, this is the only asset or connection within that needs to be FIPS-validated. Note, however, that any transmissions of CUI outside the protected environment, such as between a remote user and secure file server, should also be protected by FIPS-validated encryption.
AC.L2-3.1.13
Most contractors we work with permit remote access as a necessary aspect of normal business operations. For these contractors, Access Control safeguard 3.1.13 would apply:
Employ cryptographic mechanisms to protect the confidentiality of remote access sessions.
AC.L2-3.1.13
Remote access includes any connections to an organization’s corporate network that could be initiated from outside the facility. This could include a remote user connecting via a Virtual Private Network (VPN), and it could also include providing wireless network access (Wi-Fi) to the corporate network. In either case, given the risk for an adversary to access the CUI outside the facility, FIPS-validated cryptography is needed:
In some cases, an organization may decide to disallow corporate Wi-Fi but still permit remote access via a VPN. Their FIPS validation scope would then look like the following:
These examples do not encompass all scenarios that DIB members may encounter when addressing FIPS validation. However, seeing a graphical representation may help you with scoping in necessary components and building a custom data flow diagram for your organization. Additionally, while this post has discussed the most noteworthy FIPS-related controls, there are other requirements within NIST 800-171 that may mandate implementing FIPS-validated cryptography, such as when storing CUI system credentials within a password manager.
We have created a free downloadable template to assist you with your FIPS-validated cryptography scoping, which you can download for free at the end of this post. You’ll receive access to the template version of the diagrams shown above, and you can customize one or multiple of them into your own CUI data flow diagrams.
Download free template
How do I know if an asset is FIPS-validated?
Once your CUI and system asset scope is in order, you can determine which, if any, of those assets have been FIPS-validated. To do this, head over to NIST’s Cryptographic Module Validation Program (CMVP) Search page. Here you can find FIPS-validated modules by their vendor, certificate number, or module name. For example, if an organization has a SonicWall TZ670 firewall, they can search for any SonicWall products which incorporate FIPS-validated modules. They would then see that their firewall is indeed FIPS-validated:
Seeing that their SonicWall is FIPS-validated, the organization should then look to ensure that the device is running with the FIPS-validated cryptography configuration enabled. This could be enabled by default, a box may need to be checked (something such as “FIPS mode”), or a more in-depth configuration may be required. Ultimately, it will depend on the module. If the vendor has achieved FIPS validation for a module, given the effort required to do so, it is very likely that they provide an explanation or guide on enabling FIPS mode.
Because the FIPS validation process is both lengthy and costly for hardware and software vendors, few choose to send their products through the validation program. While more FIPS-validated modules are being added every month, DIB members will still be limited in their selection of FIPS-validated modules. The CMVP essentially will tell you if you need to procure new hardware or software, or if you should consider alternate strategies to meet FIPS validation requirements. In some cases, frustratingly, configuring a product to operate in “FIPS mode” is confusing, or means using non-mainstream or older firmware versions.
NOTE: There are vendors who claim that their solutions are “FIPS-approved”, “FIPS-compliant” or even “FIPS-certified”. This is not the same as FIPS-validated, and it will not suffice to meet the NIST 800-171 controls or pass a CMMC assessment. As you investigate solutions for meeting CMMC requirements, ensure that you are only using the CMVP as the source of truth for FIPS-validated modules. You can even ask the vendor for their certificate number (they won’t have one if not FIPS-validated), which you can check against the CMVP using the search described above. Again, given the effort required to achieve FIPS validation, it’s usually easy to tell if a module has actually been FIPS-validated. The vendor will be throwing their certificate number at you so fast you won’t have time to react. (For example, see the “Overview” section of Cocoon Data’s compliance page.)
NOTE #2: We’ve seen that, in certain cases on Windows modules, enabling FIPS mode may degrade or even “break” other applications or functions. This certainly can be a nuisance, which is why we are tracking this on our KnowledgeBase. Some applications we’ve seen break include QuickBooks, MasterCAM2022, and SolidWorks Inspection. If you enable FIPS mode and notice other applications or functions breaking, let us know.
How Totem can help you meet FIPS validation requirements
The FIPS validation requirements in NIST 800-171 are, to say the least, burdensome (and questionable in terms of security provided…). Many contractors are having to re-architect their entire environment just to meet these requirements. Others are turning to very expensive solutions such as Microsoft’s M365 GCC High, simply because they don’t see any other options. At Totem Technologies, we are continuously looking for ways to make CMMC compliance easier, especially for small- and micro-sized businesses.
For instance, for the smallest of the small micro-businesses, we recently launched our Zero Client as a Service (ZCaaS™) offering. ZCaaS™ allows micro-businesses to securely handle (process, store, and share) CUI in accordance with CMMC requirements for FIPS validation at a fraction of the cost of GCC High. Micro-businesses can use ZCaaS™ to transfer sensitive information from one cloud service to another without “contaminating” workstations. We call it a “zero client” because the organization’s on-premise or employee-owned (BYOD) workstations (desktop, laptops, mobile devices) simply act as clients to the cloud service and zero information is ever stored, processed, or transmitted on the workstations. You can read more about ZCaaS™ in our recent post. If ZCaaS™ interests you, please let us know.
We stand ready to help you identify your CUI scope, establish a path forward for meeting the FIPS validation requirements, and prepare to receive a CMMC certification. Consider grabbing a seat in our quarterly DFARS/CMMC Workshop, where we discuss the FIPS-validated cryptography requirements in detail. Or, drop us a line; we love talking about all this stuff!
Keep fighting the good fight!
–Nathan
Download Totem's free FIPS-Validated Cryptography Scoping template!
