A security validation is a substantial process—getting it started can be daunting. But you don’t need to decide everything up front—in fact, you shouldn’t. There are definitely some important considerations to work through, but there are some decisions you should put off until you are well into the process.
Once you have spent the time and money to pursue a security validation, you’re all done, right? Well, not exactly. However, the good news is that it isn’t hard or expensive to maintain your validation.
For most security validations, the validation applies to a specific version of hardware and software. At the beginning of your evaluation you must choose which versions of your product you are taking through the validation process.
You may have heard about the new interpretation of the mandatory requirement in Section 9.5 of the Implementation Guidance (IG) document, a key component of FIPS 140-2 documentation issued by the Cryptographic Module Validation Program (CMVP). This interpretation is causing conflicts with the architecture of the OpenSSL validations and how OpenSSL’s validation applies to customers using their software.
If you’re thinking about pursuing FIPS 140-2 validation for your system or component, you know the benefits that validation provides. But along with the considerable perks you’ve heard about, there is lots of erroneous information floating around. Unless you do your homework, you may fall into a minefield or two that could result in major setbacks in time and cost.
This is a very frequently asked question, and we have been fielding questions from clients on how to deal with FIPS 140-3 for years now. But, for years the advice has uniformly been: “Don’t worry about FIPS 140-3; you only need to deal with FIPS 140-2 right now.” But that’s a very unsatisfying answer, especially when there have been folks actively proclaiming “Woe betide ye