Security Evaluation Laboratory (SEL)

Common Criteria

1. Common Criteria Overview
2. Protection Profile Sources
3. Security Target Development Requirements
4. References

1. Common Criteria Overview

The Common Criteria was established by an international team to replace the security criteria and processes used in the various participating countries with a common criteria and process, with the goal that product evaluations conducted in one country would be accepted in the other countries. This has been successfully accomplished and the number of countries that now recognize each other's evaluations has grown from the initial five to 14, and more are planning to join. This recognition has been formally established as the Mutual Recognition Agreement (MRA). The US participant in the MRA is the National Information Assurance Partnership (NIAP), a partnership between the National Institute of Standards and Technology (NIST) and the National Security Agency (NSA).

The Common Criteria (CC) specifies meta-criteria (i.e. criteria for creating security criteria) and provides procedures for evaluating products against security criteria. It does not specify security criteria, as its predecessor in the US, the TCSEC (Orange Book) did. In the CC process, security criteria are embodied in Protection Profiles (PPs) and Security Targets (STs). This allows the creation of custom security criteria to meet specific needs and applications.

The CC process also uncouples security features from security assurances, which were tightly bound in the TCSEC. It is now possible to have simple security features evaluated to a high level of assurance or sophisticated security features to a low level of assurance. The CC thus demands a greater degree of insight into the security problem on the part of both the developer and the users of CC evaluated products.

Examples of the types of computing products for which CC Protection Profiles (security criteria) are being developed are operating systems, firewalls, smart cards, applications, security servers, and cryptographic modules. Products have traditionally been evaluated to meet contractual requirements for the federal market, but the commercial market is starting to drive more and more of the evaluation activity. If a contract requires CC conformance, the only way to meet the requirement is with a CC evaluation.

Products are directly evaluated against a custom subset of the CC security functional requirements (SFRs) and security assurance requirements (SARs) that are collected into a document called a Security Target (ST). In addition to the list of the targeted security features, the ST demonstrates how a particular version of the product meets each functional and assurance requirement.

An example of a CC security functional requirement is FPT_SEP, which requires that the part of the product that enforces security rules be tamper resistant. An example of a CC security assurance requirement is ACM_CAP, which requires that configuration management be effectively applied during product development. Functional requirements are levied on the product; assurance requirements are levied on the developer. The evaluator verifies that requirements of both types are met.

Hierarchical sets of assurance requirements have been selected and named in the Common Criteria. These sets are called Evaluation Assurance Levels. Seven of them have been defined and named EAL1 through EAL7, with EAL1 representing the least amount of assurance and EAL7 representing the most.

A Security Target contains a security criteria specification for a product, which can be derived from the security criteria in a Protection Profile or it can be self-defined. In the former case, part of the evaluation process verifies conformance between the criteria in the ST and the PP. Usually, IT users or groups of users write PPs to capture the security criteria for products they wish to purchase.

The Common Criteria requires that PPs and STs be evaluated for internal consistency, completeness, and conformance to CC dependency rules before they may be used in product evaluations. The CygnaCom Solutions SEL is certified by NIAP to perform these PP and ST evaluations, and to evaluate products against the criteria in an evaluated ST.

The Common Evaluation Methodology (CEM) specifies a set of steps for validating the assurance requirements in a Security Target. It is a vital component in establishing mutual trust in foreign evaluations and a key to the success of the Mutual Recognition Agreement. The CEM addresses only assurance levels EAL1 through EAL4 - and these are the only assurance levels that are mutually recognized. Higher assurance levels may be obtained, but are only accepted within a single country. Work is underway to add EAL5 to the CEM and promote mutual recognition for it.

See also: NIAP CCEVS Scheme Publication #5 Guidance to Sponsors of IT Security Evaluations

2. Protection Profile Sources (top)

Protection profiles are being written in many places for many kinds of products. There are many in development and some that have been evaluated.

The most commonly used TCSEC security criteria have been rewritten by NSA as CC Protection Profiles.

• The Controlled Access PP (CAPP) is similar to the TCSEC C2 criteria
• The Labeled Security PP (LSPP) is similar to the TCSEC B1 criteria
• TCSEC PPs similar to B2 and B3 are under development

Additional Protection Profiles can be found in the following repositories.

• NSA PPs for firewalls and a peripheral sharing switch
• IETF PPs for firewalls, VPNs, peripheral sharing switch, remote access, multiple domain solutions, mobile code, operating systems, tokens, secured messaging, PKI and KMI, and IDS
• NIAP PPs. Duplicates the above but also includes some international contributions
• NIST PPs for smart cards, an operating system, Role Based Access Control, and firewalls
• CESG (UK) PPs for computers, firewalls, smart cards, DBMSs, crypto and network components

3. Security Target Development Requirements (top)

The following documentation (or the equivalent) is required for CygnaCom Solutions to write a Security Target, regardless of Evaluation Assurance Level.

• Administrator guidance
• Functional specification
• High level design
• User guidance

4. References (top)

1. Common Criteria for Information Technology Security Evaluation. ISO/IEC 15408-1:1999(E), August 1999.
2. Common Criteria Evaluation and Validation Scheme for Information Technology Security Scheme Publication #1: Organization, Management, and Concept of Operations, version 2.0, jointly published by the National Institute of Standards and Technology and the National Security Agency, US Government, May 1999.
3. Common Evaluation Methodology Documents.