History
From time immemorial, it seems like that anyway, the National Institute of Standards and Technology (NIST) issued the Federal Information Processing Standards (FIPS) 140 which outlines the various standards for encryption that are to be used for processing federal information.
There are four levels to this standard.
Level 1: The lowest level of security requiring only the most basic cryptographic modules. It doesn’t require physical security mechanisms either.
Level 2: Takes level one and adds a physical security mechanism such as tamper-evident seals and pick resistant locks.
Level 3: Takes level two and adds more of the same. Harder to get into and compromise without obvious and immediate evidence to indicate the fact. Also can incorporate auto-destruct mechanisms.
Level 4: This is where the book is thrown at cryptography. The highest level requiring physical and logical protections as well as the strongest algorithms.
Fortunately, the job of deciphering whether your systems are FIPS compliant doesn’t involve a mathematics degree but it does require a bit of work.
Where do we start?
Cryptographic Module Validation Program
NIST has provided a resource for all things FIPS 140. Provided below is a great link to bone up on the requirements and standards that are dictated by FIPS. If you were to peruse the website you’ll learn very quickly that theory and practice are not the same animals. An algorithm itself may be validated as sound, but that does not mean the way a device or piece of software utilizes that algorithm is certified. You could, and when an algorithm is first certified you do, have a certified algorithm that you can’t use because no product or software using the algorithm has been certified.
Every device, module, or software your company employs to handle Controlled Unclassified Information (CUI) must be FIPS certified. There are three methods to handling this:
- Assume: This is the most popular method of dealing with FIPS compliance. It involves assuming all your devices are compliant or simply remaining ignorant of the very need for them to be compliant. Sufficed to say, this is not our recommended course of action.
- Vendor Validation: What are support and salespeople for other than answering mundane questions you can’t be bothered to find out? There is one caveat to this. How much do you trust your vendor? This is an important question because regardless of what your vendor tells you, you are ultimately responsible for utilizing a non-compliant device.
- Self Validation: Go to the NIST website provided below and check for yourself. Does this mean you have to go find every piece of software, hardware, COTS, etcetera that you use for encryption that’s within scope? In theory yes, in practice, not always as we will see below.
Enforcing FIPS
Fortunately, most vendors are cognizant of the need for FIPS validation. As such many provide easy to implement configurations to ensure only FIPS certified technologies are used. For example, Microsoft has a handy dandy registry edit that enforces FIPS-certified algorithms across an entire domain or on a per-machine basis. (Links provided below). Use these options. This would be something to ask all your vendors to ensure updates do not auto-deploy the latest encryption technology which may not be FIPS certified as of yet.
Conclusion
Any time you’re going to be using encryption within scope for CMMC you must use a FIPS validated method. Fortunately, that’s not all that hard to do. Unfortunately, it still requires some effort on your part. Here are a few things that will make your life easier:
- Check with your vendor if there’s a “FIPS compliant switch”
- On those without said switch go to the website below to find your product and make a note of what specific settings and configurations are FIPS compliant. Use those.
It’s another checkmark to address, but I hope it’s not mysterious anymore.
https://csrc.nist.gov/projects/cryptographic-module-validation-program
CMMC Reference: SC.3.177