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.
Your customers are asking for your product to go through a security validation. You have begun evaluating your options, have started to develop a strategy, and have decided that this is not a task you can handle on your own. Your first step will be to talk to an expert consultant.
But how do you choose one?
We have completed another marathon week in San Francisco at the annual RSA Data Security Conference. For many in our industry, Corsec included, this conference continues to be an important place to gain new insights, visit with customers and partners, and attend meaningful talks.
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
Congratulations! You’ve decided to pursue Common Criteria certification for your information technology security product. Now what? The single most important factor that will influence whether your product is certified on schedule is not the product itself; it’s how you manage the certification process. So before you embark…
Your certification or validation was a significant investment of both time and money for your company. While a certification or validation can be a substantial revenue generator for your company, it will only be so if it keeps up with any changes added to your product. Over time your product will undoubtedly be enhanced, whether by new features or by bug fixes. Given the care and effort you have invested in your product development strategy, it is critical to also have a product revalidation strategy in order to maintain a validation or certification on your currently available products.
If you’ve heard of DoDIN APL, you probably have a list of questions. DoDIN APL (which stands for The Department of Defense Information Network Approved Products List) is a directory of IT security products that have completed both Information Assurance (IA) and Interoperability (IO) testing and certification. Attaining inclusion in the APL can be an avenue to new revenue opportunities, but like anything involving federal approval, it’s not an easy road.