Changes in store for Common Criteria

The Common Criteria for Information Technology Security Evaluation, commonly referred to as Common Criteria, has been in effect since the mid-1990s. Basically, it is a framework for evaluating the security properties of information technology products against an established Protection Profile and rating them on a scale of one to seven, with seven being certified as having the highest degree of assurance.

The CC framework also represents an international agreement to harmonize into a single scheme the various national product security certification regimes established in the 1980s and 1990s by the United States, Canada and various European nations.

Common Criteria provides a common set of requirements to measure the security properties implemented in IT products to protect assets from unauthorized disclosure, modification or loss of use. The evaluation process, performed by an independent third-party testing laboratory, establishes a level of confidence that the security functionality of these IT products performs as claimed by the vendor.
 
The CC process is not without its critics, many of whom focus on the fact that at the lower assurance levels there is virtually no functional testing of the product, leading to the assertion that CC is merely a testing process on paper. Others focus on the length, expense and complexity of the evaluation process. Some critics point out that the CC evaluation cycle does not conform to the 18-month product life cycle. Many observers criticize the CC process for its lack of frequent, dynamic testing, similar to what is used by a commercial testing company called ICSA Labs.

Related stories:

NIST testing guide targets common source of software bugs

How a process model can help bring security into software development

At the recent International Common Criteria Conference in Turkey, Steven Lipner, senior director of security engineering strategy for Microsoft, delivered a insightful critique of the current CC regime. He characterized mutual recognition as the “jewel in the crown” for the vendor community.  Lipner suggested that, although users will continue to demand security testing of commercial IT products, there is a need for the security community to focus attention on what elements of the CC will provide the greatest benefits to the user. 

He characterized these as: 

1. The development of relevant protection profiles.
2. Basic feature validation.
3. Use of operating system services.
4. The ability of the product to mitigate common attacks.      

Adopting the risk management concept envisioned in the National Institute of Standards and Technology’s Special Publication 800-53 appears to provide a much broader context for integrating CC-evaluated products into a “secure” system. Viewed in this framework, CC-evaluated products allow IT security managers to make informed risk-based decisions in the technology component of the system.

Throughout the U.S. government, CC has had mixed success. The Defense Department and the national security community adopted CC as a mandatory requirement for identifying the assurance level of products used to process classified national security information.

In the early 1990s, NIST resisted overtures from the National Security Agency to have CC adopted as a Federal Information Processing Standard. Without such a mandate from NIST, the civil side of the government has shown little interest in inserting CC requirements into procurements for technology products. However, civil agencies have benefited indirectly, as most vendors produce only one version of their product — the CC-evaluated one — for sale to government agencies.

Future of CC

The CC concept is currently undergoing re-examination within the U.S. government, the IT vendor community and the international membership of the CC consortium. Some have suggested that the U.S. government work to form a consortium of various product vendors — such as the makers of firewalls, intrusion-detection systems, anti-malware software, and so on — to develop product security standards that can be tested on a dynamic basis. 

It is also interesting to note that in early 2010, the National Information Assurance Partnership Program Office at NSA announced that it will only accept products into the evaluation process that claim compliance with a U.S.-developed Protection Profile. If a U.S.-developed profile does not exist, the product may be considered for evaluation, but only at the very lowest CC level, Evaluation Assurance Level 2. This change in policy is a step back from the mutual recognition principle of the initial common criteria movement.  

The trusted systems concept, as embodied in the Orange Book and Common Criteria documents, has been a significant part of the IT security lexicon for more than 25 years. The ultimate impact of this concept is the subject of continuing debate. 

Common Criteria is essentially a procurement-based strategy that falls heavily on the national security community to specify in solicitations their requirements for evaluated products. However, there is anecdotal evidence that CC-based requirements are ignored in many procurement actions. Additionally, civil agencies are free to ignore the requirement for evaluated products in their procurements. 

An effort is now underway to develop Version 4 of CC, which will also address these implementation shortcomings. It is interesting to note that the International CC website now posts the following message: “The Common Criteria Portal is under transition to a new management team.”  As Lipner suggested, change may be coming to the CC regime.