FIPS 140-3
The Brown M&M's of NIST 800-53
A Quick Note
This article is written from my point of view and is trying to skirt the line between horribly boring compliance and things that folks might care about. While I do my best to be factually accurate, if there is a mistake, please put in a PR to get things corrected! I’m also not trying to be pedantic about every term except where necessary for clarity.
No part of this article should be taken as legal or contractual advice.
Intro
Federal systems requiring adherence to NIST 800-53, CNSSI 1253, CUI protection, or any other policy that requires cryptography for the protection of sensitive information, must adhere with the requirements in NIST FIPS 140-3.
Where FIPS 140-2 left a bit of ambiguity to the full tracing and applicability of the standard, FIPS 140-3 clearly nails it down in point 6 of the introduction material which states (emphasis theirs):
Applicability. This standard is applicable to all Federal agencies that use cryptography-based security systems to protect sensitive information in computer and telecommunication systems (including voice systems) as defined in Section 5131 of the Information Technology Management Reform Act of 1996, Public Law 104-106. This standard shall be used in designing and implementing cryptographic modules that Federal departments and agencies operate or are operated for them under contract. Cryptographic modules that have been approved for classified use may be used in lieu of modules that have been validated against this standard. The adoption and use of this standard is available to private and commercial organizations.
For the remainder of this article, FIPS 140-3 and FIPS 140-2 will be referred to
simply as FIPS.
Why do I care?
Having a focused interest in compliance automation and federal systems in particular, I’ve come to think of FIPS as the “Brown M&M’s Clause” of federal information protection policies.
For those of you that aren’t familiar, in the 1908s, Van Halen would add a clause insisting that there be a bowl of M&M’s in their dressing room and that no brown M&M’s be present1. This wasn’t the band being excessively picky, it was to ensure that the contract was read and followed completely for the protection of the band, the crew, and the audience.
When working with both public and private sector teams on compliance automation, I find that there can be a lot of interpretation as to what particular clauses of policies and directive actually mean.
My approach is to take the most strict (but practical) interpretation since that should be the more secure and/or correct interpretation. In practice, I have found that this ends up being relatively straightforward for all documented baselines as long as the selected technology has been reviewed to meet the core requirements and complementary solutions have been identified to address any deficits.
Using publicly available NIST 800-53 and NIST 800-53b as an example, we dig through 800-53 looking for the word validated and find a few hits. Cross-referencing these with 800-53b (the baselines), we find that the one that stands out is SC-13 - Cryptographic Protection since it applies to all baselines.
SC-13 - Cryptographic Protection
Control: a. Determine the [Assignment: organization-defined cryptographic uses]; and
b. Implement the following types of cryptography required for each specified cryptographic use: [Assignment: organization-defined types of cryptography for each specified cryptographic use].
Discussion: Cryptography can be employed to support a variety of security solutions, including the protection of classified information and controlled unclassified information, the provision and implementation of digital signatures, and the enforcement of information separation when authorized individuals have the necessary clearances but lack the necessary formal access approvals. Cryptography can also be used to support random number and hash generation. Generally applicable cryptographic standards include FIPS-validated cryptography and NSA- approved cryptography. For example, organizations that need to protect classified information may specify the use of NSA-approved cryptography. Organizations that need to provision and implement digital signatures may specify the use of FIPS-validated cryptography. Cryptography is implemented in accordance with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines.
Reading through the control text, there are quite a few may statements in there that make you think that FIPS-validated cryptography is not a hard requirement. But, if you jump back to FIPS 140-3 itself, those shall statements jump out that cite the relevant implementing law.
OK, going full circle now…
The “Brown M&M’s Clause” was a legal canary for the safety of everyone at a Van Halen show. It was a perfect technical specification in that it:
- Had a well defined purpose
- Was concretely testable
FIPS also has a well defined purpose, the protection of sensitive information,
and is concretely testable. In fact, that testing is part of getting FIPS validated!.
And just like the “Brown M&M’s Clause”, if this fully testable requirement is
not met then there can be no assurance that any part of the policy was
correctly met. This makes is a gloriously pass/fail situation out of the box
.
Other Thoughts
This section has been added to address some things that I’ve heard over time.
Isn’t FIPS less secure than newer encryption?
This question comes up a lot but, fundamentally, it doesn’t matter.
Compliance is about meeting requirements that must be met, not about second guessing the folks that made the requirement. Should you raise your concerns? ABSOLUTELY. Then get on with meeting the requirement.
A good physical analogy is propane tanks for gas grills. If you purchase a new propane tank, then it has been certified by the Department of Transportation. Now, you could go out and buy a cheap used tank but, by doing that, you risk a gas leak or explosion near yourself, friends, or family. This trickles down to pretty much everything we use on a daily basis:
- How your car was certified
- Tests for bus drivers
- Building materials for your home
- The list is pretty much endless…
The point to remember is that NIST considers cryptography that is not backed by a FIPS-validated cryptographic engine to provide no protection per the following statement on the FIPS Validation Program site:
Use of Non-validated Cryptographic Modules by Federal Agencies and Departments
Non-validated cryptography is viewed by NIST as providing no protection to the information or data — in effect the data would be considered unprotected plaintext. If the agency specifies that the information or data be cryptographically protected, then FIPS 140-2 or FIPS 140-3 is applicable. In essence, if cryptography is required, then it must be validated. Should the cryptographic module be revoked, use of that module is no longer permitted.
This means that, if you choose to not meet this requirement because you want to use “awesome tool X” then, from a policy point of view, you are effectively passing sensitive data in the clear. If you are responsible for the protection this information, you are now liable for the loss of the data (this is bad).
NIST 800-53 is just a guide isn’t it?
While is started out that way, the way various policies came together, it is no longer. Starting from pretty much any federal data protection policy, you end up either at NIST 800-53 or CNSSI 1253 (which itself points back to NIST 800-53).
It’s OK if I just use a FIPS-compatible algorithm, isn’t it?
NO! The policy clearly states that you must use a FIPS-validated cryptographic engine. If it isn’t FIPS-validated, it isn’t protected.
Unfortunately, this is a term that I’ve seen used by many vendors to try and skate around the issue. If a vendor is claiming FIPS, then they must be able to provide the FIPS validation certificate number(s) that they are using.
Now, some software relies on the implementation of the underlying operating system. In this approach, the vendor may not have a validation number but they should be extremely clear about how you must set up the system in order to meet the requirement.
Do I have to use FIPS everywhere?
NO! You only have to use it for the protection of sensitive data. If you take
a look at your environment and would happily run telnet or http everywhere,
then you don’t need FIPS.
In these cases, if you decide to run the more secure versions as best
practice, you aren’t using cryptography for protection, you’re effectively
using it as security through obscurity.
However, if you want to try and make this argument stick, make sure you get
written approval to run telnet to all of your systems.
Isn’t this impossible, how do I know that something meets the FIPS requirement?
It’s not impossible and, while perfection is always desired, mistakes may be made at times. When looking at any large set of requirements a good faith effort should be made to meet the requirements. When a mistake is made, it needs to be raised to the relevant customer and addressed.
Solutions may include wrapping services in other technology that provides appropriate protection in a manner that is approved by whoever is authorized to approve the system for use.
That said, some technologies, and technology stacks, make it easier than others. The following examples are provided based on familiarity and with no particular endorsement for the technology stack.
Also, go search! It turns out that a lot of folks are asking the question, and you should as well. Some quick hits on common technologies:
Language Support
Node JS, Python, and Ruby have the ability to link into underlying FIPS-validated cryptographic libraries if you choose to do so (and you should).
Here’s a great article from CyberArk that covers the technical aspects for Golang. However, there are a couple of caveats.
- Per BoringCrypto validation certificate 4407, there is no assurance of the minimum strength of generated keys. If this matters (and it probably does) use one of the other underlying libraries.
- You need to compile the library using the exact instructions in the BoringCrypto FIPS 140-2 Security Policy. And NO, this might not 100% count. You’ll need to talk to your internal team to determine that. Again, if in doubt, use one of the other underlying libraries.
Rust, unfortunately, is having a bit of an issue with achieving a straightforward method to use FIPS-validated cryptography. rustls is working towards a promising solution and AWS has a library but, at this time, there are a TON of crypto libraries floating around and every library that you use must be closely evaluated to ensure that it is using the correct implementation. This almost makes Rust a non-starter without additional wrapper services (which is a shame, I like Rust).
Unfortunately, in all of these cases, alternate cryptographic libraries exist that may be used by one or more dependencies. To be able to truly answer the question as to whether or not you meet the FIPS requirement, you must identify all paths for the protection of sensitive information in your code and ensure that they are using the correct libraries. If they are not, then alternate protection measures must be put in place to remediate the issue.
Operating System Support
Most of the major operating systems have been FIPS validated, but it is important to check the FIPS Validated product list to ensure that you are actually meeting the requirement!
I have heard anecdotally that a newer version of the same operating system that is currently going through evaluation is “probably fine” but, should it fail validation, you must cease use of it immediately. This is definitely something that you should get in writing if you pursue that path!
As a caveat, some systems also require NIAP certification (such as systems beholden to CNSSI 1253) so you’ll want to cross-reference the NIAP Product List as well!
What about non-federal systems, should regular people care?
In my opinion, yes! A lot of sites these days have statements like Protected by
military-grade AES-256 encryption plastered somewhere in there.
That’s awesome, because now we know that it means something real. As such, I would like to have these same organizations start telling me that they are using ISO/IEC 24759 or FIPS Validated cryptography. I mean, we have standards for a reason, start making them better, and expect better from the industry as a whole!
So, when a site says that they use military-grade encryption, hold them to it!
Ask for the certification reference! I mean, don’t you want to know that your
personal and/or sensitive data is being protected by something that was tested
and not some random code that I wrote in my basement one day?
Conclusion
While this article went on for a bit, hopefully it helps clarify some of the reasons that FIPS is important when talking about highly-regulated systems. This is –in no way– comprehensive, so I encourage everyone to dig into the policies for themselves and understand some of the requirements. NIST 800-53, as daunting as it seems, is really a security-focused refinement of basic systems engineering best practices and highly recommended reading even if you just focus on the less-procedural parts.