This page offers a brief overview of the Common Criteria. Rycombe offers a number of services to companies undertaking secure product evaluations. See our Certification Support page for details, or Contact Us for more information.
In the past, the cost benefit analysis of Common Criteria certification has deterred many vendors and developers. This is now being addressed by various Common Criteria schemes, including the CCEVS in the United States. CCEVS have worked with industry to develop a number of Protection Profiles for the more common product classes. These Protection Profiles are targeted at lower evaluation levels, so reduce the cost of evaluation for vendors and developers whilst at the same time making it easier for customers to compare competitor products.
|
Table of Contents |
|
Overview |
The Common Criteria (CC) are international criteria. (Once agreements are in place, mutual recognition of certificates across national boundaries will be possible). The purpose of the criteria is to allow organisations to demonstrate conformance of a product to its Security Target.
As can be seen from the summary requirements described here, achieving CC certification can be a complex and time consuming process, so why bother? Well, in certain sensitive application areas, some customers will not buy a product unless it carries a CC certificate. So, certain markets may be closed to your product unless it is certified. In addition, as a CC evaluation is carried out by a third party (a commercial licensed evaluation facility or CLEF), and as it is designed to demonstrate conformance to a set of security claims made about a product, it is an independent quality mark. Also, in some quarters, CC certification is an effective marketing technique.
The process of an CC evaluation is straightforward. The sponsor (typically the developer) of a product first appoints a CLEF, and once a certifier is appointed by the local certification body, the evaluation can commence. The CLEF then evaluates the Security Target. If this passes, then the product itself can be evaluated. The sponsor provides the evaluator with a complete set of deliverables and the evaluation assesses whether these satisfy the requirements of the criteria in terms of providing a complete, consistent and accurate realisation of the security target. If the evaluator is satisfied, a report is produced and this is submitted to the certifier for approval. If the certifier is satisfied, a certification report is produced and a CC certificate is awarded.
The responsibilities of a Sponsor are several. The sponsor must fund the evaluation, paying for both the CLEF effort and that of the certifier. The sponsor must produce an appropriate set of deliverables and must provide the evaluator and certifier with any reasonable support that they require in the course of the evaluation.
|
Security Target |
The Security Target document is key to any evaluation. This document describes the security functionality offered by the product, along with a description of the environment that the product is intended to operate in.
A security target contains a set of security requirements that may be made by reference to a protection profile, directly by reference to common criteria functional or assurance components, or stated explicitly. A security target permits the expression of security requirements for a specific product that are shown, by evaluation, to be useful and effective in meeting the identified objectives.
A security target contains the product summary specification, together with the security requirements and objectives, and the rationale for each. A security target is the basis for agreement between all parties as to what security the product offers.
|
Protection Profiles |
A Protection Profile contains a set of security requirements taken either from the Common Criteria themselves, or stated explicitly. A protection profile permits the implementation independent expression of security requirements for a set of products that will comply fully with a set of security objectives. A protection profile is intended to be reusable and to define product requirements that are known to be useful and effective in meeting the identified objectives, both for functions and assurance.
A protection profile should include an Evaluation Assurance Level (EAL).A protection profile could be developed by user communities, IT product developers, or other parties interested in defining such a common set of requirements. A protection profile gives consumers a means of referring to a specific set of security needs and facilitates future evaluation against those needs.
|
Evaluation Assurance Levels |
The Evaluation Assurance Level defines the rigour that must be applied to the development and presentation of teh product to evaluation. There are seven possible levels that can result from a successful evaluation, and one, EAL0 that indicates failure.
EAL1 - functionally tested
EAL2 - structurally tested
EAL3 - methodically tested and checked
EAL4 - methodically designed, tested, and reviewed
EAL5 - semiformally designed and tested
EAL6 - semiformally verified design and tested
EAL7 - formally verified design and tested
The documentation required falls into a number of categories: Configuration management, delivery and operation, development (functional specification, design, and source code), guidance documents (user manuals), life cycle support (adherance to a well defined development methodology), tests, and vulnerability assessment.
|
Links |
There is a comprehensive Common Criteria site at www.commoncriteria.org. Part one of the Common Criteria (Introduction and general model) provides a more comprehensive introduction to the criteria than is given here.