Common Criteria

From Wikipedia, the free encyclopedia

The Common Criteria (CC) is an international standard (ISO/IEC 15408) for computer security. Unlike standards such as FIPS 140, Common Criteria does not provide a list of product security requirements or features that products must contain. Instead, it describes a framework in which computer system users can specify their security requirements, vendors can then implement and/or make claims about the security attributes of their products, and testing laboratories can evaluate the products to determine if they actually meet the claims. In other words, Common Criteria provides assurance that the process of specification, implementation and evaluation of a computer security product has been conducted in a rigorous and standard manner.

1 Key Concepts
2 History
3 Common Criteria Testing Laboratories
4 Mutual Recognition Arrangement
5 Some Thoughts
6 External links

[edit] Key Concepts

Common Criteria evaluations are performed on computer security products and systems.

Target Of Evaluation (TOE) - the product or system that is the subject of the evaluation.

The evaluation serves to validate claims made about the target. To be of practical use, the evaluation must verify the target's security features. This is done through the following:

Protection Profile (PP) - a document, typically created by a user or user community, which identifies security requirements relevant to that user for a particular purpose. A PP effectively defines a class of security devices (for example, smart cards used to provide digital signatures, or network firewalls). Product vendors can choose to implement products that comply with one or more PPs, and have their products evaluated against those PPs. In such a case, a PP may serve as a template for the product's ST, or the authors of the ST will at least ensure that all requirements in relevant PPs also appear in the target's ST document. Customers looking for particular types of products can focus on those certified against the PP that meets their requirements.

Security Functional Requirements (SFRs) - specify individual security functions which may be provided by a product. The Common Criteria presents a standard catalogue of such functions. For example, an SFR may state how a user acting a particular role might be authenticated. The list of SFRs can vary from one evaluation to the next, even if two targets are the same type of product. Although Common Criteria does not prescribe any SFRs to be included in an ST, it identifies dependencies where the correct operation of one function (such as the ability to limit access according to roles) is dependent on another (such as the ability to identify individual roles).

Security Target (ST) - the document that identifies the security properties of the target of evaluation. Each target is evaluated against the SFRs established in its ST, no more and no less. This allows vendors to tailor the evaluation to accurately match the intended capabilities of their product. This means that a network firewall does not have to meet the same functional requirements as a database management system, and that different firewalls may in fact be evaluated against completely different lists of requirements. The ST is usually published so that potential customers may determine the specific security features that have been certified by the evaluation.

The evaluation process also tries to establish the level of confidence that may be placed in the product's security features through quality assurance processes:

Security Assurance Requirements - descriptions of the measures taken during development and evaluation of the product to assure compliance with the claimed security functionality. For example, an evaluation may require that all source code is kept in a change management system, or that full functional testing is performed. The Common Criteria provides a catalogue of these, and the requirements may vary from one evaluation to the next. The requirements for particular targets or types of products are documented in the ST and PP, respectively.

Evaluation Assurance Level (EAL) - the numerical rating assigned to the target to reflect the assurance requirements fulfilled during the evaluation. Each EAL corresponds to a package of assurance requirements which covers the complete development of a product, with a given level of strictness. Common Criteria lists seven levels, with EAL1 being the most basic (and therefore cheapest to implement and evaluate) and EAL7 being the most stringent (and most expensive). Normally, an ST or PP author will not select Assurance requirements individually but choose one of these packages, possibly 'augmenting' requirements in a few areas with requirements from a higher level. Higher EAL levels do not necessarily imply "better security", they only mean that the claimed security assurance of the TOE has been more extensively validated.

So far, most PPs and most evaluated STs/certified products have been for IT components (e.g., firewalls, operating systems, smart cards). Common Criteria certification is sometimes specified for IT procurement. Other standards containing, e.g, interoperation, system management, user training, supplement CC and other product standards. Examples include the ISO 17799 (Or more properly BS 7799-2, which is now ISO/IEC 27001) or the German IT-Grundschutzhandbuch.

Details of cryptographic implementation within the TOE are outside the scope of the CC. Instead, national standards, like FIPS 140-2 give the specifications for cryptographic modules, and various standards specify the cryptographic algorithms in use.

[edit] History

The CC originated out of three standards:

ITSEC - The European standard, developed in the early 1990s by France, Germany, the Netherlands, the UK and also used by some other countries, e.g. Australia
CTCPEC - The Canadian standard
TCSEC - The United States Department of Defense standard, called the Orange Book and part of the Rainbow Series

CC was produced by unifying these pre-existing standards, so that companies selling computer products for defence or intelligence use would only need to have them evaluated against one set of standards. The CC was developed by the governments of Canada, France, Germany, the Netherlands, the UK, and the U.S.

[edit] Common Criteria Testing Laboratories

In the U.S. the National Institute of Standards and Technology (NIST) National Voluntary Laboratory Accreditation Program (NVLAP) accredits Common Criteria Testing Laboratories (CCTL).

[edit] Mutual Recognition Arrangement

As well as the Common Criteria standard, there is also a sub-treaty level Common Criteria MRA (Mutual Recognition Arrangement), whereby each party thereto recognizes evaluations against the Common Criteria standard done by other parties. Originally signed in 1998 by Canada, France, Germany, the United Kingdom and the United States, Australia and New Zealand joined 1999, followed by Finland, Greece, Israel, Italy, the Netherlands, Norway and Spain in 2000. The Arrangement has since been renamed Common Criteria Recognition Arrangement (CCRA) and membership continues to expand. Within the CCRA only evaluations up to EAL 4 are mutually recognized (Including augmentation with flaw remediation). The European countries within the former ITSEC agreement typically recognize higher EALs as well. Evaluations at EAL5 and above tend to involve the security requirements of the host nation's government.

[edit] Some Thoughts

So, if a product is Common Criteria certified, does that mean it is very secure? Let's look at an example.

Microsoft Windows 2000 is certified product at EAL4+, but regular security patches for security vulnerabilities are still published by Microsoft for Windows 2000. This is possible because the process of getting an Common Criteria certification allows a vendor to make certain assumptions about the operating environment and the strength of threats, if any, faced by the product in that environment. Based on these assumptions, the claimed security functions of the product are evaluated. Since Microsoft Windows 2000 has been EAL4+ certified, it should only be considered secure in the assumed, specified circumstances, also known as the evaluated configuration, specified by Microsoft.

Whether you run Microsoft Windows 2000 in the precise evaluated configuration or not, you should apply Microsoft's security patches for the vulnerabilities in Windows 2000 as they continue to appear. If any of these security vulnerabilities are exploitable in the product's evaluated configuration, the product's Common Criteria certification should be voluntarily withdrawn by the vendor. Alternatively, the vendor should re-evaluate the product to include application of the patches to fix the security vulnerabilities within the evaluated configuration. Failure by the vendor to take either of these steps would result in involuntary withdrawal of the product's certification by the certification body of the country in which the product was evaluated.

Microsoft Windows 2000 remains at EAL4+ without including the application of any Microsoft security vulnerability patches in its evaluated configuration. This shows both the limitation and strength of an evaluated configuration.