This article can also be found in the Premium Editorial Download "Information Security magazine: Captive to SOX compliance? A compliance guide for managers."
Download it now to read this article plus other related content.
Don't bank on Common Criteria and FIPS 140 certifications to ensure information systems' security.
Security certifications such as FIPS 140 and Common Criteria are required for the sale of information assurance (IA) and IA-enabled products to the U.S. government, various foreign governments and some private industry verticals. But, while vendors tout these certifications, don't be fooled into thinking that these products will be any more secure than non-certified products once they're deployed.
The certification processes for both FIPS 140 and Common Criteria include a hefty documentation effort by the vendor, thorough testing of security features by an independent testing lab and validation review by a governing entity. When completed, a product's certification is tied to a single version of software running on a specific version of hardware--it's a snapshot in time of that product and its security functions. This makes sense from a certification perspective, but loses its luster from the standpoint of practicality and deployment.
In my experience, organizations do not typically deploy certified products in the configurations in which they were tested. While your procurement policies may limit purchases of IA or IA-enabled products to those that have been certified under FIPS 140 or Common Criteria, you probably have mandatory systems security policies that conflict with the administrative guidance policies of the certified products. That's
A certified product may make certain assumptions about your operating environment that conflict with your security objectives. Or it may not counter specific threats to or in your environment. FIPS 140 and Common Criteria focus on specific security functions within a product, and vulnerabilities certainly can exist for functionalities that were not part of the certification. And once a product is certified, any feature additions, patches or bug fixes must be recertified to claim these as compliant. Given vendors' aggressive development cycles and frequent release of features and bug fixes, it's more likely they can't certify the latest version of code.
FIPS 140 and Common Criteria do not provide unconditional security for information or systems--that's not their goal or intent. Building a system of certified point products provides no assurance of the security of that system, let alone the interoperability, performance and isolation of multi-level information classification and separation. Your systems' owners should have explicit instructions for configuring point products to meet the overall security and assurance level of the system.
Still, products certified under FIPS 140 and Common Criteria do offer value: You have some reasonable amount of assurance that the security features/functions included in the certification effort are implemented according to a set of formal requirements specifications, industry standards and best practices. Plus, you have a level of assurance that these implementations perform correctly, either by broad specification or to address specific threats to the product. Furthermore, you are purchasing a product with security functions that were thoroughly reviewed and tested by an independent entity; you don't have to accept only a vendor's claim that their cryptographic algorithms are implemented correctly or that their security functions were tested adequately.
So, by all means, continue to purchase and use certified products--just not at the expense of compromising system security.
This was first published in March 2006