The SafeLogic Blog

Inspired by conversations with customers, I'll try to disambiguate a common misunderstanding: FIPS Inside. There is still a lot of FUD circulating in the industry, so let's break that down. A good place to start is our short whitepaper on the strategic advantages (read it here, no registration required) but there are some key deployment issues that should be clarified here.

FIPS Inside refers to the deployment of a FIPS 140-2 validated encryption module within a larger product. If that sounds familiar, it's because it is the most common use of a validated module. Nothing tricky, just specificity as defined by NIST to be clear about what has or has not been validated. As addressed in our whitepaper, it is a common mistake to pursue a larger validation boundary than absolutely necessary, so the most common use of a validated module is integrated within a larger solution. Hence, FIPS Inside.

Then what's the difference between FIPS Inside and FIPS Compliant?

When you are leveraging FIPS Inside, it is your own validated module, and you carry a FIPS 140-2 certificate in your name. Maybe you did a RapidCert or maybe you took another path, but your module is shown on the NIST website.

By comparison, FIPS Compliant means that you don't have a certificate. You have installed a module that could be validated, meaning that it is believed to meet the standard, but has not been tested in your use case. Maybe you are implementing an open source toolkit or maybe you're using a really cool implementation of AES 256 that your CTO hacked together. There's no way to know, because it hasn't been reviewed by NIST and you don't have a certificate. "We are FIPS Compliant" could be paraphrased as "We are aware of the FIPS 140-2 standard and we think this would pass testing".

This brings us to a gray area - the encryption module that has been validated for someone else. Often, this is either an open source module or crypto that is built into the operating system. Both pose threats to sales activities and future certification, and for good reason. Whether it's a federal procurement officer or a 3PAO for FedRAMP, industry professionals recognize that unless you are holding a validation, you are not in control of the situation. Approved operating environments may vary, maintenance issues crop up, and in the case of OS-level cryptography, there are security assurance concerns about increasing attack surfaces when you make crypto API calls outside of your software. iOS, for example, has been certified by NIST, but nobody would claim that every and any app running on iOS is FIPS 140-2 validated. Certainly, it is possible to survive in the competitive marketplace and under the scrutiny of acquisition agencies and testing bodies without holding your own FIPS 140-2 validation, but you should be prepared to advocate convincingly for that choice. Many of our customers have taken that route in the past and came to the conclusion that training their sales team to argue about FIPS 140-2 wasn't as cost effective as simply getting validated.

Meanwhile, some consultants will lead you to believe that all of those options are terrible. They will tell you that a true validation will encompass the entire product. This is plain wrong.

First of all, it's not factual. FIPS 140-2 is a cryptographic standard and the certification process is administered by the Cryptographic Module Validation Program (CMVP). Unless your product itself actually is a cryptographic module, then the standard would be irrelevant to the product, except for the encryption inside. Here at SafeLogic, the vast majority of our customers are in software. They all need encryption, but it is a feature of the product, certainly not the product itself.

Second, expanding the validation boundary beyond the core crypto functions is just a bad idea. You practically guarantee yourself a future revalidation effort (good for the consultant, bad for you) without gaining any additional security assurance, since the labs only test the core crypto functions. There is only downside, no upside.

If you're still considering expanding that validation boundary, check out our strategy guide whitepaper before you make any decisions. I can't stress enough how much additional work you would be taking on, for no additional value. Please don't hesitate to reach out and ask questions. We're here to help.