All About Common Criteria: Certification, Concepts, Evaluation Assurance Levels

Ibrahim Akdağ| Ph.D.
7 min readMar 18, 2022

Common Criterion is a framework in which computer system users can specify their security functional requirements (SFRs) and security functional assurance requirements (SARs) using Protection Profiles (PPs). Technology vendors can then implement and/or make claims about the security attributes of their products, and hire testing laboratories to evaluate their products to determine if they meet these claims. In short, Common Criteria assures that the process of specification, implementation and evaluation of a computer security product has been conducted in a rigorous, standard, and repeatable manner at a level that corresponds with its target use environment. Once this process is completed successfully, a vendor achieves Common Criteria certification.

Common Criteria (CC) is an international certification program accepted by many countries as a common standard for commercial off-the-shelf (COTS) IT products. CC certification is typically required by government customers, but public sector customers are increasingly using it as a purchasing requirement.

The history of Common Criteria

The Common Criteria is a descendant of the US Department of Defense Trusted Security Evaluation Criteria (TCSEC) originally in the 1970s. TCSEC was informally known as the “Orange Book.” Several years later Germany issued their version, the Green Book, as did the British and the Canadians. A consolidated European standard for security evaluations, known as ITSEC, soon followed. The United States joined the Europeans to develop the first version of the international Common Criteria in 1994. The current version of the Common Criteria, 2.1, was issued in August, 199.

The Common Criteria is also known as ISO 15408. The international community has embraced the Common Criteria through the Common Criteria Recognition Arrangement (CCRA) whereby the signers have agreed to accept the results of Common Criteria evaluations performed by other CCRA members. The National Information Assurance Partnership (NIAP) was formed to administer a security evaluation program in the United States that utilizes the Common Criteria as the standard for evaluation.

Certification Process

There are two paths to Common Criteria certification: Evaluation Assurance Levels (EAL) and Protection Profiles (PP). Each is achieved through an accredited third-party commercial testing laboratory, which tests products against standardized security requirements.

Evaluation Assurance Levels (EAL) are ratings based on how the product satisfies various functional and assurance security requirements. Seven levels describe the rigor and depth of the assessment, with EAL1 being the most basic and EAL7 the most stringent. The CCRA has agreed that EAL1 and EAL2 evaluations are to be recognized by all participating countries regardless of where the evaluation was completed.

A Protection Profile is a set of Common Criteria technical standards or configurations developed for specific technology types, such as mobile devices or firewalls. The Protection Profile specifies security criteria for that type of product, against which the product is evaluated for conformance.

There are two types of Protection Profiles:

  • Country-specific Protection Profile (PP) requirements, for which there is no guarantee of mutual recognition;
  • and Collaborative Protection Profiles (cPP), recognized by all participating CCRA countries. As of March 2020,

The Common Criteria Collaborative Protection Profiles listed versions of four basic cPPs: Stateful Traffic Filter Firewalls; Full Disk Encryption — Encryption Engine; Full Disk Encryption — Authorization Acquisition; and Network Device.

When a certifying body awards a Common Criteria certificate, it asserts that the product meets the company’s security requirements specified iin therelated security target. (A security target is a set of requirements that specifies the scope of the evaluation.) Purchasers of certified products must review the security target to understand the assumptions made as part of the evaluation, the product’s intended environment, and the assessed security functionality.

Key CC Concepts & Definitions

Here are some key terms and concepts to know when trying to understand the Common Criteria certification.

  • The target of evaluation(TOE) — is the product or system that is the subject of the evaluation.
  • Protection Profile (PP) — a document created by a user or user community that identifies security requirements for a class of security devices (examples include firewalls and digital signatures) relevant to that user for a specific purpose. Product vendors can choose to implement products that comply with one or several PPs and have their products evaluated against them. In this situation, a PP may serve as a template for the product’s Security Target (ST), or the authors of the ST will ensure that all requirements in relevant Protection Profiles also appear in the target’s ST document. Customers looking for certain types of products can focus on those certified against these PPs. The United States currently only allows PP-based evaluations.
  • Security Target (ST) — a document that identifies the security properties of the target of evaluation. The ST may claim compliance with one or more PPs. The Target of Evaluation is assessed against the SFRs (Security Functional Requirements) established in its Security Target. This allows vendors to accurately tailor the evaluation to match the intended capabilities of their product. The ST is typically published so that potential customers may determine the specific security features that have been certified by the evaluation.
  • Security Functional Requirements (SFRs) — requirements that layout the individual security functions provided by a product. The Common Criteria presents a standard catalog of such functions. The list of SFRs can vary across evaluations, even if two targets are the same type of product. Although CC does not propose any SFRs to be included in a Security Target, it recognizes dependencies where the correct operation of one function is dependent on another.
  • Security Assurance Requirements (SARs), a quality assurance process that describes the steps taken during the development and evaluation process to ensure compliance with the claimed security functionality
  • Evaluation Assurance Level (EAL) –the numerical rating that describes the rigor and depth of an evaluation. Each EAL corresponds with a package of SARs, which covers the full development of a product across a certain level of strictness. Common Criteria lists seven levels of EAL, with EAL 1 being the most basic and EAL 7 being the most stringent; however, the levels only mean more testing was done — not that the product itself is more secure. The United States currently only allows PP-based evaluations — not EALs. Other national evaluation schemes, such as those in Canada, are phasing out EAL-based evaluations and only accept products for evaluation that claim strict conformance with an approved PP.

Common Criteria Evaluation Assurance Levels

Functional and assurance security requirements are the basis for the Common Criteria. There are seven Evaluation Assurance Levels (EALs). The higher the level, the more confidence you can have that the security functional requirements have been met. The levels are as follows:

EAL1: Functionally Tested. Applies when you require confidence in a product’s correct operation, but do not view threats to security as serious. An evaluation at this level should provide evidence that the target of evaluation functions in a manner consistent with its documentation and that it provides useful protection against identified threats.

EAL2: Structurally Tested. Applies when developers or users require low to moderate independently assured security but the complete development record is not readily available. This situation may arise when there is limited developer access or when there is an effort to secure legacy systems.

EAL3: Methodically Tested and Checked. Applies when developers or users require a moderate level of independently assured security and require a thorough investigation of the target of evaluation and its development, without substantial reengineering.

EAL4: Methodically Designed, Tested and Reviewed. Applies when developers or users require moderate to high independently assured security in conventional commodity products and are prepared to incur additional security-specific engineering costs.

EAL5: Semi-Formally Designed and Tested. Applies when developers or users require high, independently assured security in a planned development and require a rigorous development approach that does not incur unreasonable costs from specialist security engineering techniques.

EAL6: Semi-Formally Verified Design and Tested. Applies when developing security targets of evaluation for application in high-risk situations where the value of the protected assets justifies the additional costs.

EAL7: Formally Verified Design and Tested. Applies to the development of security targets of evaluation for application in extremely high-risk situations, as well as when the high value of the assets justifies the higher costs.

The TOE

The CC is flexible in what to evaluate and is therefore not tied to the boundaries of IT products as commonly understood. Therefore in the context of evaluation, the CC uses the term “TOE” (Target of Evaluation).

A TOE is defined as a set of software, firmware, and/or hardware possibly accompanied by guidance. While there are cases where a TOE consists of an IT product, this need not be the case. The TOE may be an IT product, a part of an IT product, a set of IT products, a unique technology that may never be made into a product, or a combination of these. As far as the CC is concerned, the precise relation between the TOE and any IT products is only important in one aspect: the evaluation of a TOE containing only part of an IT product should not be misrepresented as the evaluation of the entire IT product.

Examples of TOEs include  A software application; An operating system; A software application in combination with an operating system; A software application in combination with an operating system and a workstation; An operating system in combination with a workstation; A smart card integrated circuit; The cryptographic co-processor of a smart card integrated circuit; A Local Area Network including all terminals, servers, network equipment, and software; A database application excluding the remote client software normally associated with that database application.

--

--