In our recent blog post, we talked about the cost and timing you can expect if you pursue FIPS 140-2 revalidation for your product or system. We also touched on five change scenarios that necessitate revalidation. These scenarios were created by the Cryptographic Module Validation Program (CMVP), the same body that published the FIPS standard, which covers requirements for cryptographic module changes to FIPS validated products.
Again, the FIPS standard is a U.S. and Canadian co-sponsored security standard for hardware and software products using cryptography. Products must comply with FIPS 140-2 if they are to be used in a security system that processes sensitive but unclassified information.
Now let’s take a deeper dive into those five change scenarios to understand how to determine which one applies to you and how to complete the evaluation process once you know.
Revalidation or new validation: How do I know?
Products that contain cryptography, and are used for sensitive but unclassified information, must abide by the FIPS standard and must be validated by law. When you make changes to a FIPS-validated module, you must determine whether you have to revalidate your product or whether other action is required. Making that determination depends on just one thing: whether or not you have made changes to your product that affect the FIPS security posture for the module to meet the FIPS standard. If the answer is yes, you must revalidate. If the answer is no, there are still other steps you must take, which I’ll get into below.
Once you have achieved your first FIPS validation, it’s important that you maintain it to insure it remains current. That’s where the following five scenarios, or SUBs, come in to play.
1SUB: Changes have been made that do not affect any FIPS-relevant security items. You may have updated product documentation, exterior components or packaging. In this scenario, you would have the lab submit a letter of rationale to the CMVP detailing the changes. A new Security Policy may be required, and your lab or validation consultant can advise you; but in either case, your original certification date will be annotated but you’re not issued a new certificate.
2SUB: Here, you haven’t made any changes, but you would like to have additional testing performed. The lab will then tell you what documents you must provide, and they will test any changed or added assertions. Again, your original certification date is annotated but a new certificate is not issued.
3SUB: In this scenario, you’ve made changes that affect less than 30% of the FIPS-relevant security items. The number of vendor-evidenced items that require updates from the previous validation will determine this. 3SUB requires that you submit a full submission package. The lab must test all changed or added assertions, and perform a regression test suite to make sure that no other items were inadvertently changed. Once successfully completed, you will be issued a new certificate.
4SUB: If you made changes to the module’s physical enclosure only, your change is considered as a new module. This typically applies to hardware modules, because a change would affect the physical security mechanisms required. You will need to provide a description of the changes, and also submit supporting documentation. Be prepared, as the lab will fully test all physical security mechanisms, which in turn may necessitate that you attain a new Security Policy. As with scenarios one and two above (1SUB and 2SUB), your original certification date is annotated but a new certificate is not issued.
5SUB: When you make changes to either the module embodiment or the overall security level that affects more than 30% of FIPS-relevant security items, your product is now considered by the CMVP to contain a new module, which means a new FIPS validation is required as you are no longer compliant to the FIPS standard, and new documentation must accompany the new submission.
The FIPS Standard and the Impact of these changes
In the case of Scenarios 1, 2 and 4, the module must continue to meet the FIPS standard, implementation guidance (IG) and algorithm testing requirements that were in place at the time of your original validation. If any new requirements have been issued since your product was originally validated, your product does not have to meet these new requirements. The new modules will not be placed in the Modules in Process list that includes modules currently undergoing FIPS validation.
For Scenarios 3 and 5, all modules must meet the FIPS standard, IG and algorithm testing requirements that are in place at the time of your new validation. You are then placed on the Modules in Process list.
You may want to pursue FIPS revalidation for reasons not related to the product itself. For example, your client may request that a module you changed be recognized as a validated module for his or her own edification, or revalidation may be a true requirement of your client’s end-customer − that could be the DoD or other government agency. In these two situations, the decision to revalidate is based on your client’s need, rather than on a FIPS requirement; which is still a perfectly legitimate, business-focused reason to revalidate.
In many cases, making the determination as to which scenario you fall into is fairly simple, however it’s not always cut and dry; it may be a good idea to talk to a validation consultant. It is a good best practice to stay up to date on the FIPS standard and contact Corsec if you need help to evaluate product and potential impact. Let us know how we can help you.