Common Criteria (CC)

United States TCSEC (Trusted Computer Security Evaluation Criteria) and FC (Federal Criteria): – the TCSEC, also called the Orange Book- was developed in the United States in the early 1980s. In the subsequent decade, various countries began initiatives to develop evaluation criteria that built upon the concepts of the TCSEC but were more flexible and adaptable to the evolving nature of IT in general.

In 1993, the draft FC (Federal Criteria) for Information Technology Security version 1.0 was also published as a second approach to combining North American and European concepts for evaluation criteria.

United Kingdom CESG (Communications-Electronics Security Group): – in 1985 in the UK, CESG published Computer Security Manual No.3.These criteria were developed to evaluate computer systems (as opposed to products) and made no assumptions about where security functions lay. Testing was carried out to one of 6 levels of confidence (UK Levels or UKL1-UKL6, with UKL1 being the lowest). This concept was broadly equating to the Orange Book’s levels of trust.

Europe’s ITSEC (Information Technology Security Evaluation Criteria): in 1991, under the EC’s auspices, version 1.2 of the Information Technology Security Evaluation Criteria (ITSEC). This was complemented in 1993 by an agreed methodology for evaluation, the Information Technology Security Evaluation Manual (ITSEM). ITSEC has 6 assurance levels, E1-E6, with E6 representing the highest level of assurance. In the UK, E1-E6 was deemed to offer equivalent assurance to UKL1-UKL6 under the predecessor CESG criteria. In 1998 an agreement was signed by the UK, France, Finland, Germany, Greece, the Netherlands, Norway, Portugal, Spain, Sweden, and Switzerland, whereby ITSEC certificates issued by any of the Qualifying Certification Bodies(initially the UK, France, and Germany) would be recognized in all other countries. Even without formal mutual recognition, other countries have often been willing to accept ITSEC certificates. Schemes based on the ITSEC criteria have been initiated or developed in countries worldwide (Korea and Australia, for example).

However, the ITSEC criteria have always been the lack of formal recognition in North America, particularly in the USA. In America, despite the development of Federal Criteria in the early 1990s, the TCSEC or Orange Book remained the criteria of choice for evaluating products and systems for the US Government. However, this had not been adopted on a commercial basis, as the ITSEC has in the UK, for example. While US authorities have grudgingly recognized ITSEC certificates, this has only been in cases where there has not already been a TCSEC evaluated product that could be used instead. This has caused headaches for IT developers to ‘prove’ the security of their products. They have had to sponsor separate testing programs on different sides of the Atlantic.

Canada CTCPEC (Canadian Trusted Computer Product Evaluation Criteria) version 3.0 was published in early 1993 as a combination of the ITSEC and TCSEC approaches. In the United States, the draft Federal Criteria for Information Technology Security (FC) version 1.0 was also published in early 1993 as a second approach to combining North American and European concepts for evaluation criteria.

CC takes all of the above criteria and combines them together into one coherent security evaluation process.

• Canada: Communications Security Establishment.
• France: Service Central de la Sécurité des Systèmes d’Information.
• Germany: Bundesamt für Sicherheit in der Informationstechnik.
• Netherlands: Netherlands National Communications Security Agency.
• United Kingdom: Communications-Electronics Security Group.
• United States: National Institute of Standards and Technology.
• United States: National Security Agency.

The seven governmental organizations The Common Criteria Project Sponsoring Organizations

Common Criteria (CC) is meant to evaluate the security properties of IT products and systems. The CC applies to IT security measures implemented in hardware, firmware, or software.

An IT product or system is known as a Target of Evaluation (TOE) during the evaluation. Such TOEs include, for example, operating systems, computer networks, distributed systems, and applications.

ISO WG3 (Working Group 3) – Work had begun in 1990 in the International Organization for Standardization (ISO) to develop an international standard evaluation criterion for general use. The new criteria were responsive to the need for mutual recognition of standardized security evaluation results in a global IT market. This task was assigned to Working Group 3 (WG 3) of subcommittee 27 (SC 27) of the Joint Technical Committee 1 (JTC 1). Initially, progress was slow within WG3 because of the extensive amount of work and intensive multilateral negotiations required.

The CC Project – in June 1993, the CTCPEC, FC, TCSEC, and ITSEC pooled their efforts and began a joint activity to align their different criteria into a single set of IT security criteria that could be widely used. This activity was named the CC Project.

ISO-CC Collaboration – the CC Project’s purpose was to deliver the results to ISO to contribute to their development standards. Representatives of the sponsoring organizations formed CC Editorial Board (CCEB) to develop the CC. A liaison was then established between the CCEB and WG 3.The CCEB contributed several early versions of the CC to WG 3 via the liaison channel. As a result of the interaction between WG 3 and the CCEB, these versions were adopted as successive working drafts of various parts of the ISO criteria beginning in 1994.

Version 1.0 of the CC was completed by the CCEB in January 1996 and was approved by ISO in April 1996 for distribution as a Committee Draft (CD). The CC Project then performed several trial evaluations using CC Version 1.0.An extensive public review of the document was conducted. The CC Project subsequently undertook an extensive revision of the CC based on the comments received from trial use, public review, and interaction with ISO. The successor’s revision work has been carried out to the CCEB, now called the CC Implementation Board (CCIB).

The CCIB completed CC version 2.0 “Beta” in October 1997 and presented it to WG 3, which approved it as a Second Committee Draft. Subsequent intermediate draft versions were provided informally to WG 3 experts for feedback as they were produced by the CCIB. The CCIB received and responded to a series of comments that came both directly from WG 3 experts and from ISO National Bodies via the CD balloting. The culmination of this process is CC Version 2.0.

For historical and continuity purposes, ISO/IEC JTC 1/SC 27/WG 3 has accepted the continued use of the term “Common Criteria” (CC) within the document while recognizing that its official name in the ISO context is “Evaluation Criteria for Information Technology Security“.

Part 1, Introduction and general model, is the introduction to the CC. It defines general concepts and principles of IT security evaluation and presents a general model of evaluation. Part 1 also presents constructs for expressing IT security objectives, selecting and defining IT security requirements, and writing high-level specifications for products and systems. Also, each part of the CC’s usefulness is described in terms of each target audience.

Part 2, Security functional requirements, establish a set of functional components as a standard way of expressing the functional requirements for TOEs. Part 2 catalogs the set of functional components, families, and classes.

Part 3, Security assurance requirements, establishes a set of assurance components as a standard way of expressing the assurance requirements for TOEs. Part 3 catalogs the set of assurance components, families, and classes. Part 3 also defines PPs and STs’ evaluation criteria and presents evaluation assurance levels that define the predefined CC scale for rating assurance for TOEs, called the Evaluation Assurance Levels (EALs).

Protection Profiles (PP): These define implementation-independent sets of security requirements and objectives for categories of products or systems that meet similar users’ IT security needs. The PP concept has been developed to support functional standards and as an aid to procurement specifications. PPs are already being developed for firewalls, relational databases, and other categories.

Security Target (ST): Contains the IT security objectives and requirements of a specific Target of Evaluation (TOE) and defines the functional and assurance measures offered by that TOE to meet stated requirements. The ST may claim conformance to one or more PPs and forms the basis for an evaluation.

Components: they are the smallest self-contained security requirements.

Families: They are groups of components that share security objectives.

Classes: Classes are groups of families which share a common intent. There are ten of these (Audit, Communications, Cryptographic Services, User Data Protection, Identification and Authentication, Privacy, Protection of the Trusted Functions, Resource Utilization, TOE Access and Trusted Path/Channels), which are defined in Part 2 of CC – which also contains the Component Catalogue.

Packages: Are intermediate combinations of components, which permit the expression of a set of requirements meeting an identifiable subset of the security objectives. Intended to be reusable and define requirements known to effectively meet identified objectives, packages can be used to construct PPs and STs.

The first product to be certified under Common Criteria was Milkyway Networks Corporation’s Black Hole (SecurIT) Firewall version 3.01E2 (to EAL3) by the Canadians in 1997.Since the UK ITSEC scheme opened its doors for Common Criteria testing in 1997, three sponsors have put products forward for testing under the new criteria. MIS Europe Ltd and the Knowledge Group are taking advantage of the new EAL1 assurance level, submitting the SeNTry 2020 (PC access control product) and VCS FIREWALL, respectively. Meanwhile, from the United States, the Oracle Corporation has put forward release 7.2 of its Oracle7 database and release 8.0.1 of Oracle8 for testing to EAL4.-CH2.

ITSEC (Europe) and TCSEC (U. S.) came first, then the global CC levels.

There are now seven assurance levels under CC, EAL1 to EAL7, where EAL2 – EAL7 is designed to be equivalent to the ITSEC assurance levels E1 – E6, respectively. A new ‘entry’ assurance level, EAL1, has been introduced below the previous lower limit of ITSEC E1/TCSEC C1.This is a part of the greater flexibility offered by the new criteria.

NOTE: as of June 2004, no device or system has been certified at a higher level than EAL5.

It should be noted that while comparisons can be made between the criteria, there is no exact equivalence because assurance or trust is derived differently.

CCEVS (Common Criteria Evaluation and Validation Scheme)

To get a product certified for a CC assurance level, companies can turn to a commercial go-between vendor, who does the legwork. Or they can go directly to the NIST group that performs the evaluations. ..the CCEVS.

CCEVS Description

The National Information Assurance Partnership’s evaluation body is called the CCEVS – often referred to simply as the “Validation Body“. This group is jointly managed by the NIST (National Institute of Standards and Technology) and the NSA (National Security Agency).

The Validation Body:

• approves the participation of security testing laboratories.
• provides technical guidance to those testing laboratories.
• validates the results of IT security evaluations for conformance to the Common Criteria.
• serves as an interface to other nations for the recognition of such evaluations.

The Accredited Test Labs – IT security evaluations are conducted by commercial testing laboratories accredited by the NIST’s NVLAP (National Voluntary Laboratory Accreditation Program) and approved by the Validation Body. These are called CCTL‘s (Common Criteria Testing Labs). The labs themselves must be accredited by the NVLAP to meet:

• the requirements of ISO/IEC Guide 25.
• General Requirement for the Competence of Calibration and Testing Laboratories.
• the specific scheme requirements for IT security evaluation.

Other requirements for CCTL approval are CCEVS-specific and are outlined in scheme policies and scheme publications.

Method of CC Evaluation – the CCEVS (Validation Body) assesses the results of a security evaluation conducted by a CCTL within the scheme and, when appropriate, and issues a Common Criteria certificate. Together with its associated validation report, the certificate confirms that an IT product or protection profile has been evaluated at an accredited laboratory using the Common Evaluation Methodology for conformance to the Common Criteria.

List of CC Certified Products – the CCEVS Validation Body, maintains a NIAP Validated Products List (VPL) containing all IT products and protection profiles that have successfully completed evaluation and validation under the scheme. The VPL includes those products and profiles successfully completing similar processes under the schemes of authorized signatories to the Arrangement on the Mutual Recognition of Common Criteria Certificates in the field of Information Technology Security.

Assets — Information or resources to be protected by the countermeasures of a TOE.

Assignment — The specification of an identified parameter in a component.

Assurance — Grounds for confidence that an entity meets its security objectives.

Attack potential — The perceived potential for success of an attack, should an attack be launched, expressed in terms of an attacker’s expertise, resources and motivation.

Augmentation — The addition of one or more assurance component(s) from Part 3 to an EAL or assurance package.

Authentication data — Information used to verify the claimed identity of a user.

Authorized user — A user who may, in accordance with the TSP, perform an operation.

Class — A grouping of families that share a common focus.

Component — The smallest selectable set of elements that may be included in a PP, an ST, or a package.

Connectivity — The property of the TOE which allows interaction with IT entities external to the TOE. This includes the exchange of data by wire or by wireless means over any distance in any environment or configuration.

Dependency — A relationship between requirements such that the requirement that is depended upon must normally be satisfied for the other requirements to meet their objectives.

Element — An indivisible security requirement.

Evaluation — Assessment of a PP, an ST, or a TOE, against defined criteria.

Evaluation Assurance Level (EAL) — A package consisting of assurance components from Part 3 representing a point on the CC predefined assurance scale.

Evaluation authority — A body that implements the CC for a specific community by means of an evaluation scheme and thereby sets the standards and monitors the quality of evaluations conducted by bodies within that community.

Evaluation scheme — The administrative and regulatory framework under which the CC is applied by an evaluation authority within a specific community.

Extension — The addition to an ST or PP of functional requirements not contained in Part 2 and/or assurance requirements not contained in Part 3 of the CC.

External IT entity — Any IT product or system, untrusted or trusted, outside of the TOE that interacts with the TOE.

Family — A grouping of components that share security objectives but may differ in emphasis or rigor.

Formal — Expressed in a restricted syntax language with defined semantics based on well-established mathematical concepts.

Human user — Any person who interacts with the TOE.

Identity — A representation (e. g., a string) uniquely identifying an authorized user can either be the full or abbreviated name of that user or a pseudonym.

Informal — Expressed in natural language.

Internal communication channel — A communication channel between separated parts of the TOE.

Internal TOE transfer — Communicating data between separate parts of the TOE.

Inter-TSF transfers — Communicating data between the TOE and the security functions of other trusted IT products.

Iteration — The use of a component more than once with varying operations.

Object — An entity within the TSC that contains or receives information and upon which subjects perform operations.

Organizational security policies — One or more security rules, procedures, practices, or guidelines imposed by an organization upon its operations.

Package — A reusable set of either functional or assurance components (e.g., an EAL) combined to satisfy a set of identified security objectives.

Product — A package of IT software, firmware, and/or hardware, providing functionality designed for use or incorporation within a multiplicity of systems.

Protection Profile (PP) — An implementation-independent set of security requirements for a category of TOEs that meet specific consumer needs.

Reference monitor — The concept of an abstract machine that enforces TOE access control policies.

Reference validation mechanism — An implementation of the reference monitor concept that possesses the following properties: it is tamperproof, always invoked, and simple enough to be subjected to thorough analysis and testing.

Refinement — The addition of details to a component.

Role — A predefined set of rules establishing the allowed interactions between a user and the TOE.

Secret — Information that must be known only to authorized users and/or the TSF to enforce a specific SFP.

Security attribute — Information associated with subjects, users, and/or objects used for the enforcement of the TSP.

Security Function (SF) — A part or parts of the TOE that have to be relied upon to enforce a closely related subset of the TSP rules.

Security Function Policy (SFP) — The security policy enforced by an SF.

Security objective — A statement of intent to counter identified threats and/or satisfy identified organization security policies and assumptions.

Security Target (ST) — A set of security requirements and specifications to be used as the basis for evaluation of an identified TOE.

Selection — The specification of one or more items from a list in a component.

Semiformal — Expressed in a restricted syntax language with defined semantics.

Strength of Function (SOF) — A TOE security function’s qualification expressing the minimum efforts assumed necessary to defeat its expected security behavior by directly attacking its underlying security mechanisms.

SOF-basic — A level of the TOE strength of function where analysis shows that the function provides adequate protection against casual breach of TOE security by attackers possessing a low attack potential.

SOF-medium — A level of the TOE strength of function where analysis shows that the function provides adequate protection against straightforward or intentional breach of TOE security by attackers possessing a moderate attack potential.

SOF-high — A level of the TOE strength of function where analysis shows that the function provides adequate protection against deliberately planned or organized breach of TOE security by attackers possessing a high attack potential.

Subject — An entity within the TSC that causes operations to be performed.

System — A specific IT installation with a particular purpose and operational environment.

Target of Evaluation (TOE) — An IT product or system and its associated administrator and user guidance documentation that is the subject of an evaluation.

TOE resource — Anything useable or consumable in the TOE.

TOE Security Functions (TSF) — A set consisting of all hardware, software, and firmware of the TOE that must be relied upon for the correct enforcement of the TSP.

TOE Security Functions Interface (TSFI) — A set of interfaces, whether interactive (man-machine interface) or programmatic (application programming interface), through which TOE resources are accessed, mediated by the TSF, or information is obtained from the TSF.

TOE Security Policy (TSP) — A set of rules that regulate how assets are managed, protected, and distributed within a TOE.

TOE security policy model — A structured representation of the security policy to be enforced by the TOE.

Transfers outside TSF control — Communicating data to entities not under the control of the TSF.

Trusted channel — A means by which a TSF and a remote trusted IT product can communicate with the necessary confidence to support the TSP.

Trusted path — A means by which a user and a TSF can communicate with the necessary confidence to support the TSP.

TSF data — Data created by and for the TOE might affect the TOE’s operation.

TSF Scope of Control (TSC) — The set of interactions that can occur with or within a TOE and are subject to the TSP rules.

User — Any entity (human user or external IT entity) outside the TOE interacts with the TOE.

User data — Data created by and for the user that does not affect the operation of the TSF.