Certification Security Blanket

Not all product certifications are equal, however. Their usefulness depends on the purpose of the certification. You need to understand whether the testing was for functional or implementation purposes, the context of the test and the scope of the results. Most product certifications focus on functional testing--not a feature-by-feature comparison scoring one product over another. The functional tests determine whether a product meets the certification criteria.

The main certifications for security products are the Common Criteria, Federal Information Processing Standard 140-2 (FIPS-140-2) Security Requirements for Cryptographic Modules, and ICSA Labs. Security consultancy Neohapsis--and a Network Computing lab partner--sponsors the Open Security Evaluation Criteria (OSEC), which takes a community-peer-review approach to certification with input from vendors and users.

These certifications complement one another, but if you're a government agency or contractor, you should use the CC and FIPS-140-2 certifications.

Know Your Needs

To get the most out of certifications, you must know your organization's security requirements. These should be stated in a security policy or request for proposal. With such a document in hand, you can easily compare the certification's functionality tests against your needs. It also helps to understand the certification terminology. Common Criteria provides language for building a protection profile (PP), which states your requirements.To determine whether a certification will help in your product analysis, look at how the certification defines a particular security function, like whether a stateful packet-filtering firewall is tracking the state of a TCP session properly. Knowing that, for instance, TCP state is defined and tested in the certification lab as just TCP session setup and tear-down and doesn't include TCP sequence numbering and error-control mechanisms can help you decide if that particular certification is appropriate for your requirements.

Certification tests typically are restricted to a subset of a product's features. Although most firewalls support IPsec (IP security), just because a firewall passes ICSA Labs Firewall Certification doesn't mean it passes the IPsec VPN Certification. And these functional certifications merely confirm that a security feature works--they don't shed any light on the importance of the feature.Common Criteria is the culmination of work between several countries, including the United States, Canada, Germany and the United Kingdom, to develop a set of universal requirements, test methodologies and structure for evaluating security products worldwide ("CC Glossary"). CC 2.1 and ISO (International Organization for Standardization) standard 15408 are the same. Although the CC was developed with government evaluation and purchasing in mind, its testing and certifications apply to the enterprise as well.

The CC comprises three parts. Part 1 is an overview. Part 2 defines the security components being tested. Vendors can use Part 2 to specify functions required for their product or subsystem, such as a firewall or encryption processor. The tested device is known as the "target of evaluation" (TOE) in CC parlance. Part 3 defines the security-assurance requirements. It's used to develop PP and security target (ST) documents. The ST document defines the functional capabilities of the product. Each evaluated product has an ST document. The PP defines a set of security requirements needed to achieve a security goal. CC doesn't require a PP for every product tested, but if it has one, the product has to satisfy that profile as well as the ST. CC also provides a certification report that summarizes the test, explains the testing environment and configuration, and describes any PPs used. The report includes special exceptions or issues, if any, surrounding the certification testing.

The CC's Evaluated Assurance Level (EAL) is an assessment that says the product meets the functional requirements stated in the ST and in the PP (see "CC EALs,"). EAL levels range from EAL1, which means a product was functionally tested and met the basic requirements, to EAL7, which signifies the product meets requirements for exceptionally secure environments.

Most products receive CC certification of EAL4 and below because EAL5, 6 and 7 certifications are extremely stringent--the CC evaluates the development process and theoretical framework behind the product along with the functional tests.But out of context, an EAL rating is meaningless. Many firewalls, for instance, have an EAL4 rating, but that doesn't tell you much unless you read the ST, PP and Certification Report. Cross-reference the claims in the ST and PP, too, using CC Parts 2 and 3 so you'll be sure to know what was tested.

Cryptic Certification

FIPS-140-2 is a certification for cryptographic modules sponsored by the National Institute of Standards and Technology (NIST). It makes FIPS-140-1 obsolete, though version 1 is still valid for existing products.

NIST-approved labs test new products to FIPS-140-2, which ensures that cryptographic subsystems are implemented correctly and provide an adequate level of protection for stored, sensitive data.

FIPS-140-2 defines four levels of security assurance, from lowest to highest, with each building on the previous one. Level 1 means the product properly implements the NIST standardized cryptographic algorithms, including DES (Data Encryption Standard), 3DES (Triple DES) and AES (Advanced Encryption Standard).Level 2 means the product has tamper-evident coatings to ensure that any corruption of the device would be noticeable.

Level 3 is for cryptographic modules that delete stored keys if they detect a physical attack on, say, circuit components. At Level 3, the product must require authenticated access.

Level 4 requires that a product provide protection from attacks that attempt to thwart physical access controls, such as supercooling.

Most security products receive FIPS-140-2 Level 2 or Level 3 certification, which is sufficient as long as the modules are contained in a controlled environment such as a machine room.

Another Puzzle PieceUnfortunately, there's no organization analogous to the Underwriters Laboratory for network security products. Only a few industry certifications address how a product functions. Probably the oldest and most well-known is ICSA Labs, an independent division of security-services company TruSecure Corp. ICSA Labs tests and certifies cryptographic systems, firewalls, antivirus software and IPsec VPN software and appliances against published documents and other products. Like Common Criteria and FIPS-140-2, ICSA Labs' certifications are functional tests with pass and fail components.

The certification criteria is compiled from security vendors and experts. It evolves, too, as product features mature and testing methods are identified. Unlike CC, ICSA Labs' industry certification doesn't include implementation guidelines and environmental constraints. These tests don't take into account architectural differences of a product or its internal protection enhancements. An ICSA Labs firewall certification, for instance, doesn't differentiate between stateful packet-filtering firewalls and application-proxy firewalls.

Is Certification Enough?

How important is certification in the real world of exposed networks and security patches? A certified security device or package isn't immune to attack. It's one piece, albeit major, of the puzzle. The IBM 4578 Cryptographic processor, for example, a FIPS-140-1 Level 4-certified device, once had a vulnerability in its Common Cryptographic Architecture support software that let a would-be attacker bypass the security layers and recover the keys. IBM fixed the problem early last year, but it drives home the fact that certifications don't replace sound security practices.

And a certified product isn't necessarily more secure than an uncertified one. It may be that the vendor of the uncertified product has not yet submitted it for testing or that testing is still under way. Rest assured that the prices vendors pay for certification, often starting at $25,000 per product and upwards to hundreds of thousands for a Common Criteria certification, motivate them to build products that are likely to get certified.But don't take any certification as gospel. Certifications are good at capturing a common set of requirements, but you'll still have your own unique ones.

Mike Fratto is a senior technology editor based in Network Computing's Syracuse University Real-World Labs®; he covers all security-related topics. Write to him at [email protected].

Post a comment or question on this story.

Certification Report: Summary of the Common Criteria testing results

EAL (Evaluation Assurance Level): A ratinggiven to products that meet a minimum set of CC requirements defined for a specific level

PP (Protection Profile): This document defines the required security functions for a set of security needs. CC-certified PPs are evaluated just as thoroughly as STs and TOEs. You can define your own PP using the Common Criteria Part 2 document.ST (Security Target): This document provides the environmental context and protection expectations that a TOE supports for an EAL. The ST is written by the vendor and reviewed by the CC evaluator. The ST helps you understand the vendor's claims of what the product features should do and how they should be used. It also gives you some context when you read the Certification Report.

TOE (Target of Evaluation): The product orsubsystem being tested, such as a firewall or encryption processor. The TOE is described in the ST.• EAL1: The TOE is tested to ensure it does what the vendor claims.

• EAL2: The TOE is tested as in EAL1 and existing vendor documentations of development are examined.

• EAL3: The vendor must show evidence that it has looked for vulnerabilities; the evaluator confirms the vendor results. This level requires more stringent development processes.

• EAL4: In-depth examination of the individual TOE components and product life-cycle management. Evaluator also looks for vulnerabilities.• EAL5: The formal model describing the TOE and the functional specification are examined, as well as moderate resistance to attack, convert channel analysis and a required modular design.

• EAL6: Analysis of the design and the implementation of the TOE. More in-depth convert channelanalysis and stronger development controls. Testing of the product for high resistance to attack.

• EAL7: Formalized testing of the TOE designand functional specification. All vendor tests areindependently verified.Security white papers & research reports

Security books

Weekly vulnerability and patch newsletterCurrent Internet Threat Report

The Common Criteria

ICSA Labs

The National Institute of Standards' FIPS-140-2

OSEC