Top 10 Myths about FIPS 140-2 Validation

Top 10

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.

Today I thought I’d dispel those myths. Here we go.

1.    We can get our validation in a few months.

Not true. There are many steps you have to go through, technical requirements that must be met, that you cannot skip or accelerate. In fact, if you don’t plan ahead and know what to expect up front, the validation process could take longer than the average nine to twelve month timeframe. We’ve had clients tell us it took 18 to 24 months for their validation. When that happens, not only do your development costs skyrocket, but you’re losing revenue you could be generating with a validated product.

2.    We need to budget millions for our validation.

Yes, there are considerable costs associated with FIPS 140-2 validation; such as the lab, consultant, government fees, and of course your own internal team and development costs. No, it should not cost you millions, and if someone told you that, it’s because they were not prepared for the process. It’s important that you scope the timeline and deliverables so you don’t incur additional costs.

3.    Custom hardware makes validation prohibitive.

Careful planning will help you make the right decisions from both a technical and business perspective regarding what custom hardware you need. There are well-designed, highly secure hardware solutions that are not complex or expensive; even commercially available solutions that can be modified to the standard without a lot of R&D cost.

4.    FIPS 140-3 is almost here, why bother with FIPS 140-2?

FIPS 140-3 has been in draft mode for six years. When FIPS 140-3 is finally signed (and we’re not sure when that will be), there will be a one-year rollover period during which you can begin validation efforts for FIPS 140-2 or FIPS 140-3.  We recommend that our customers pursue FIPS 140-2 now rather than wait for FIPS 140-3 to be published. A FIPS 140-2 validation should be grandfathered under 140-3, meaning you won’t be required to revalidate under 140-3 for the same product version.

Still not convinced you shouldn’t wait? FIPS 140-3 will probably be more expensive to attain. What’s more, if you’re one of the first to go through FIPS 140-3 validation, you’re blazing new trails in a sense because you can’t benefit from the experience of others who’ve gone before you. This could mean more time, more expense.

Bottom line is, if you achieve a FIPS 140-2 validation now you can sell into additional markets while FIPS 140-3 is still being transitioned in. If you wait, you’re passing up revenue opportunities and incurring additional cost.

5.    You must get Level 4 validation, which is next to impossible. 

Yes, there are four Levels of FIPS 140-2. But the law only requires you to attain Level 1. Level 4 is impractical and therefore not commercially feasible, and Levels 1-3 are relatively easy to achieve. Corsec works with our clients to determine the best ROI at each level, so they don’t “overachieve”.  For example, we’ll do market research to determine the level your competitors have attained.

6.    If you have Common Criteria certifications you don’t need FIPS.

Maybe you have JTIC or TIC certification, but Common Criteria certification can also require FIPS 140-2. Validation requirements should be driven by customer demand; if your customers don’t require you to have it, then you don’t need it. If not having FIPS 140-2 is holding you back from making sales to government customers then yes, you do need FIPS.

7.    With Open SSL, you’ve got “FIPS inside.”

OpenSSL validation only covers the cryptographic primitives and not the protocols and interfaces; therefore if you are offering services beyond that which is offered directly by the library, those additional services are not covered by the OpenSSL validation. FIPS requires all cryptographic services to be documented, tested, and validated. If this discrepancy is discovered late in the sales process it could cause a loss of time and loss of the sale.

Never rely on someone else’s validation.

8.    I will have to rewrite my code for validation.

There are many changes required for validation, and some will require code changes. But we’re typically talking dozens – maybe hundreds of lines of code.  If your developers were not informed up front that the product would require validation, then they haven’t built in all the FIPS requirements. Part of our FIPS 140-2 validation analysis and planning workshop involves the identification, implementation and QA of these changes.

9.    If product development occurred outside the US, it doesn’t qualify.

Unlike Common Criteria, which has a scheme for each country, FIPS requires no onsite visits, nor does it have a country of origin restriction. There are independent validation labs in six countries, all of which have to work with the US and Canada to achieve accreditation. Once they’ve done that, it doesn’t matter where their lab is located, where the company they’re working with is located, or where development took place.

10.  We would have to purchase someone else’s library since our product isn’t actually certified.

Third party libraries are not required for FIPS validation but they do speed up development.  One benefit Corsec customers have is that we work with existing crypto code to help them make the minimum required changes to satisfy FIPS requirements. We often validate products using the right combination of existing code, custom code and third party libraries. This saves time and cost.

For more information on debunking these myths and overcoming the challenges associated with FIPS 140-2 validation, view our accompanying webinar, Top 10 Myths about FIPS 140-2 Validation.

 

Image Source

John Morris

As Co-Founder and President of Corsec, John Morris works with Corsec clients to deliver exceptional consulting and project management service. Before co-founding Corsec, John was a manager of an NVLAP-accredited testing laboratory, where he recognized the need for an impartial third party that could work with the lab and their customers to simplify and streamline the process for everyone involved. For the last decade, John has worked in cryptography, public key infrastructure, communications, and security engineering.

More Posts - Website

LinkedInShare