Common Criteria Certification Rigorous, Comprehensive, Objective

The Common Criteria, the accepted international standard for IT product security evaluations, is mutually recognized by 24 countries under the CC Mutual Recognition Agreement (CC MRA). Product certification is immediately recognized by industry experts as proof that a product has been subject to a rigorous, comprehensive examination by independent third party security experts, and certified by national authorities.

Originally published in 1996, v1.0 of the CC was an initiative between Canada, France, Germany, Netherlands, UK, and the USA to develop criteria for evaluation of IT security useful within the international community. An alignment and development of a number of source criteria, the existing European ITSEC, the US TCSEC, and Canadian CTCPEC, the Common Criteria resolved the conceptual and technical differences between these sources. It is a contribution to the development of an international standard with v2.0 adopted as ISO/IEC 15408 in 1999, opening the way to worldwide mutual recognition of evaluation results. An evolving standard, v3.1 was published in September 2006 and was required for all NIAP evaluations beginning after March 21, 2008.

Organizationally, the CC consists of the CC IMB, or International Management Board, that oversees the 24 national schemes. Each national scheme can choose to be a certificate producer or user. Certificate producing schemes must establish the infrastructure to accredit and oversee laboratories that perform the evaluation; i.e. establish national standards for laboratory accreditation, establish the scheme to monitor the evaluation, review evaluation reports, and ultimately certify the evaluation results. National schemes that choose not to develop the infrastructure necessary to certify evaluations use the evaluation results of the producing schemes.

The laboratories that perform evaluations are independent commercial entities accredited and monitored by the national scheme. These labs are responsible for performing appropriate, impartial, objective, repeatable evaluations that are complete and correct.

The CC standard consists of Part 1, 2, 3 and the CEM:

  • Part 1: Introduction and general model
  • Part 2: Catalog of Security Functional Requirements
  • Part 3: Catalog of Security Assurance Requirements
  • CEM: Common Evaluation Methodology

Part 2 and 3 form the basis of a standardized language used to describe product security functionality; the CEM defines the required methodology used to perform evaluations that ensures objective, consistent evaluations by competent, accredited evaluation laboratories as well as certification by the national schemes.

The CC contains seven predefined levels constructed using components from Part 3 that define a hierarchical scale measuring the level of assurance for the evaluation. These levels, called EAL, or Evaluation Assurance Levels, are:

  • EAL1: Functionally Tested
  • EAL2: Structurally Tested
  • EAL3: Methodically Tested and Checked
  • EAL4: Methodically Designed, Tested, and Reviewed
  • EAL5: Semi-Formally Designed and Tested.
  • EAL6: Semi-Formally Verified Design and Tested.
  • EAL7: Formally Verified Design and Tested

Evaluation levels may be "augmented" by adding components from a higher EAL, denoted using a postfix +, e.g. EAL3+ denotes an EAL3 evaluation that has drawn additional requirements from Part 3. The most common augmentation is flaw remediation, which requires that discovered security flaws be tracked and corrected by the developer.

Rigorous, comprehensive and objective, CC evaluations require considerable documentation be produced and evaluated by the laboratory using the standards imposed by the CEM, e.g. at EAL3+ the following are the required documents produced and evaluated.

  • Security Target
  • Functional Specification
  • Security Architecture Description
  • Security Architecture Design
  • Operational User Guidance
  • Preparative Procedures
  • Configuration Management Documentation
  • Delivery Procedures
  • Identification of security measures
  • Developer defined life-cycle model
  • Developer Test Coverage Analysis
  • Developer Test Depth Analysis
  • Developer Test Plans and Procedures
  • Developer Test Results
  • Vulnerability Analysis
  • Flaw Remediation Guidance