What's tougher than completing a FIPS 140-2 validation? How about completing TWO validations?
Please compose yourself and return to your seats. This is hypothetical, but you should know that sometimes lightning does strike twice, if your strategy and execution do not factor in these potential situations. NIST's Implementation Guidance publication for FIPS 140 and the CMVP offers five main scenarios in which re-validation becomes a concern.
Scenario 1: Modifications are made to hardware, software or firmware components that do not affect any FIPS 140-1 or FIPS 140-2 security relevant items.
Impact: While this may not seem like a big deal, there is time and cost involved. A laboratory will need to vouch for the fact that no changes are required. Not only does that take money, but it will take time for your development team to spin up a list of diffs... Or time and money if you hire a consultant to facilitate the effort.
Scenario 2: No modifications are made to any hardware, software or firmware components of the cryptographic module. All version information is unchanged. Post validation, approved security relevant functions or services for which testing was not available at the time of validation, or security relevant functions or services that were not tested during the original validation, are now tested and are being submitted for inclusion as a FIPS Approved function or service.
Impact: Adding new functions and/or services will require testing and incur costs. Think of this as a mini-validation, as only the new features will be processed. It will cost money and take time from development, just like taking a full validation through the traditional process.
Scenario 3: Modifications are made to hardware, software or firmware components that affect some of the FIPS 140-2 security relevant items. An updated cryptographic module can be considered in this scenario if it is similar to the original module with only minor changes in the security policy and FSM, and less than 30% of the modules security relevant features.
Impact: This is quite similar to Scenario 1, except with more cost, more time, more testing, and more development involvement. All modifications must be catalogued and tested. And watch out for that 30% threshold, otherwise you'll be stuck in Scenario 5.
Scenario 4: Modifications are made only to the physical enclosure of the cryptographic module that provides its protection and involves no operational changes to the module.
Impact: At Level 1, the physical enclosure is irrelevant. However, additional physical testing is required at Level 2. You know what that means - more time, more money, and more aggravation.
Scenario 5: If modifications are made to hardware, software, or firmware components that do not meet the above criteria, then the cryptographic module shall be considered a new module and shall undergo a full validation testing by a CST laboratory.
Impact: This is like hitting Bankrupt in Wheel of Fortune. You're basically starting over. Whether you barely exceeded the 30% threshold in Scenario 3, or you revamped your entire product, your FIPS 140-2 validation is no longer in effect and you are starting from scratch... and at the back of the queue.
One key note to remember - in each of these scenarios, if you require re-validation, your product will not be in full compliance during the waiting period. Re-validation queues are not as impacted as they are for new validations, but it will definitely be in the magnitude of months, not days. Can you afford to be out of compliance for that long?
If you're already familiar with CryptoComply products, you're probably smiling right now. For the rest of you, read on. I promise it gets better.
By implementing CryptoComply for Mobile or CryptoComply for Server, you leverage our expertise and strategy, so that your product never falls out of validation.
One of the key features of CryptoComply is the strict boundary drawn around the cryptographic module itself. Inexperienced certification managers and overzealous consultants will often embark on a quest to have a product validated from end-to-end. Not only is this unnecessary, it's a fool's errand. Drawing a deliberate and accurate boundary for validation provides excellent protection against re-validations. CryptoComply, for example, contains only the core cryptographic functions, ensuring that only the most critical, security-relevant changes will necessitate re-validation. In addition, SafeLogic keeps CryptoComply updated and fully validated, insuring that any changes will be reflected immediately and provided to our customers.
So if you are just embarking on your first FIPS 140-2 validation, don't waste your time on the traditional path. Not only will it cost you more and take longer initially, it puts you in danger of needing to re-validate. And if you are facing re-validation, reach out to SafeLogic immediately. We can save you time and money, and more importantly, we can ensure that this is your last re-validation.
Because really, you just need a lightning rod. Call SafeLogic.