The CC combines the best aspects of existing criteria for the security evaluation of information and communication technology systems and products.

An overview of the key CC concepts

Background

The Common Criteria represents the outcome of efforts to develop criteria for evaluation of IT security that are widely useful within the international community. It is an alignment and development of a number of source criteria: the existing European, US and Canadian criteria (ITSEC, TCSEC and CTCPEC respectively). The Common Criteria resolves the conceptual and technical differences between the source criteria. It is a contribution to the development of an international standard and opens the way to worldwide mutual recognition of evaluation results.

Criteria developments in Canada and European ITSEC countries followed the original US TCSEC work (Orange Book). The US Federal Criteria devel- opment was an early attempt to com- bine these other criteria with the TCSEC, and eventually led to the cur- rent pooling of resources towards pro- duction of the Common Criteria.

A great strength in the CC development is the close involvement of all the parties with experience of creating the original national Criteria documents. The CC benefits from their accumulated wisdom, and their intent for a fully flexible approach to the standardization of security functionality and evaluation assurance. The CC has been made sufficiently flexible to permit its evolutionary convergence with the numerous existing national schemes for IT security evaluation, certification, and accreditation.

The CC structure also provides great flexibility in the specification of secure products. Consumers and other parties can specify the security functionality of a product in terms of standard protection profiles, and independently select the evaluation assurance level from a defined set of seven increasing Evaluation Assurance Levels, from EAL1 up to EAL7.

Version 1.0 of the CC was published for comment in January 1996. 

Version 2.0 takes account of extensive review and trials and was published in May 1998.

Version 2.0 has been adopted by the International Organisation for Standards (ISO) as a Final Committee Draft (FCD) and is expected to become an International Standard (ISO 15408) in 1999.

General Model

The CC presents requirements for the IT security of a product or system under the distinct categories of functional requirements (CC Part 2) and assurance requirements (CC Part 3). 

The CC functional requirements define desired security behavior. Assurance requirements are the basis for gaining confidence that the claimed security measures are effective and implemented correctly.

	Consumers	Developers	Evaluators
Part 1: Introduction and General Model	For background information and reference purposes	For background information and reference for the development of requirements and formulating security specifications for TOEs	For background information and reference purposes. Guidance structure for PPs and STs
Part 2: Security Functional Requirements	For guidance and reference when formulating statements of requirements for security functions	For reference when interpreting statements of requirements and formulating functional specifications of TOEs	Mandatory statement of evaluation criteria when determining whether TOE effectively meets claimed security functions
Part 3: Security Assurance Requirements	For guidance when determining required levels of assurance	For reference when interpreting statements of assurance requirements and determining assurance approaches of TOEs	Mandatory statement of evaluation criteria when determining the assurance of TOEs and when evaluating PPs and STs

Approach

Confidence in IT security can be gained through actions that may be taken during the process of development, evaluation and operation

Development

The CC defines a set of IT requirements of known validity that can be used in establishing security requirements for prospective products and systems. The CC also defines the Protection Profile (PP) construct which allows prospective consumers or developers to create standardized sets of security requirements that will meet their needs.

The Target of Evaluation (TOE) is that part of the product or system which is subject to evaluation. The TOE security threats, objectives, requirements, and summary specification of security functions and assurance measures together form the primary inputs to the Security Target (ST), which is used by the evaluators as the basis for evaluation.

Evaluation 

The principal inputs to evaluation are the Security Target, the set of evidence about the TOE, and the TOE itself. The expected result of the evaluation process is a confirmation that the ST is satisfied with the TOE, with one or more reports documenting the evaluation findings.

Operation

Once a TOE is in operation vulnerabilities may surface, or environmental assumptions may require revision. Reports may then be made to the developer requiring changes to the TOE. Following such changes reevaluation may be required.

Security framework

The CC discusses security using a hierarchical framework of security concepts and terminology:

Security environment: Laws, organisational security policies etc, which define the context in which the TOE is to be used. Threats present in the environment are also included.
	Security objectives: A statement of intent to counter the identified threats and/or satisfy intended organisational security policies and assumptions.
		TOE security requirements: The refinement of the IT security objectives into a set of technical requirements for security functions and assurance, covering the TOE and its IT environment.
			TOE security specifications: Define an actual or proposed implementation for the TOE.
				TOE implementation: The realisation of a TOE in accordance with its specification.

Key concepts

Protection Profile (PP)

A protection profile defines an implementation-independent set of security requirements and objectives for a category of products or systems which meet similar consumer needs for IT security. A PP is intended to be reusable and to define requirements that are known to be useful and effective in meeting the identified objectives.

Protection Profile (PP)	A protection profile defines an implementation-independent set of security requirements and objectives for a category of products or systems which meet similar consumer needs for IT security. A PP is intended to be reusable and to define requirements that are known to be useful and effective in meeting the identified objectives. The PP concept has been developed to support the definition of functional standards and as an aid to formulating procurement specifications. PPs have been developed for firewalls, relational databases, etc.
Security Target (ST)	A security target contains the IT security objectives and requirements of a specific identified 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	The CC defines a set of constructs that classify security requirements into related sets called components.
	Component Operations CC components may be used exactly as defined in the CC, or they may be tailored through the use of permitted operations in order to meet a specific security policy or counter a specific threat. Each component identifies and defines any permitted operations, the circumstances under which it may be applied and the results of the application. Permitted operations are:  Iteration; Assignment;  Selection; and  Refinement.
	Component Dependencies Dependencies may exist between components. Dependencies arise when a component is not self-sufficient and relies upon the presence of another component. Dependencies may exist between functional components, between assurance components and (rarely) between functional and assurance components. Each component identifies the dependencies which should be satisfied.
	Component Naming Convention Requirements for a TOE can be constructed from the hierarchy of specifications. The class name is three characters in length (e.g. FMT). Families within each class are named by the addition of an underscore and a further 3 characters (e.g. FMT_SMR). Components within families are numbered (e.g. FMT_SMR.2), as are any elements within the components (e.g. FMT_SMR.2.1). The diagram shows an example family taxonomy for the FMT_SMR (Security Management Roles) family. It contains three components, with a hierarchy between components 1 and 2.

an overview of security functionality and the CC component catalog

In defining the security requirements for a trusted product or system the user/developer needs to consider the threats to the IT environment. The CC contains a catalog of components that the developers of PPs and STs can collate to form the security requirements definition. The organization of these components into a hierarchy helps the user to locate the right components to combat threats. The user then presents the security requirements in the PPs and the ST of the TOE.

Component Catalogue

Part 2 of the CC contains the catalog of functional components. A high-level overview of the eleven functionality classes in CC Version 2.0 is provided here.

There are some inter-class dependencies, such as the reliance the Data Protection class has upon the correct Identification and Authentication of users in order to be effective.

Security Functional Components	Sumamry
Audit (FAU)	Security auditing involves recognising, recording, storing and analysing information related to security activities. Audit records are produced by these activities and can be examined to determine their security relevance. The class is made up of families, which define, amongst other things, requirements for the selection of auditable events, the analysis of audit records, their protection and their storage.
Cryptographic Support (FCS)	This class is used when the TOE implements cryptographic functions. These may be used, for example, to support communications, identification and authentication, or data separation. The two families cover the operational use and management of cryptographic keys.
Communications (FCO)	The communications class provides two families concerned with assuring the identity of a party participating in data exchange. The families are concerned with non-repudiation by the originator and by the recipient of data.
User Data Protection (FDP)	This class contains families specifying requirements relating to the protection of user data. These families address user data within the TOE during import, export and storage, in addition to security attributes related to user data.
Identification and Authentication (FIA)	The requirements for identification and authentication ensure the unambiguous identification of authorized users and the correct association of security attributes with users and subjects. Families in this class deal with determining and verifying user identity, determining their authority to interact with the TOE, and with the correct association of security attributes with the authorized user.
Security Management (FMT)	This class is used to specify the management of TSF security attributes, data and functions. Different management roles and their interaction, such as separation of capability, can be defined. The class is used to cover the management aspects of other functional classes.
Privacy (FPR)	Privacy requirements provide a user with protection against discovery and misuse of his identity by other users. The families in this class are concerned with anonymity, pseudonymity, unlinkability and unobservability.
Protection of the TOE Security Functions (FPT)	This class is focused on the protection of TSF (TOE security functions) data, rather than of user data. The class relates to the integrity and management of the TSF mechanisms and data.
Resource Utilisation (FRU)	Resource utilization provides three families that support the availability of required resources, such as processing capability and storage capacity. The families detail requirements for fault tolerance, the priority of service and resource allocation.
TOE Access (FTA)	This class specifies functional requirements, in addition to those specified for identification and authentication, for controlling the establishment of a user’s session. The requirements for TOE access govern such things as limiting the number and scope of user sessions, displaying the access history and the modification of access parameters.
Trusted Path/Channels (FTP)	This class is concerned with trusted communications paths between the users and the TSF, and between TSFs. Trusted paths are constructed from trusted channels, which exist for inter-TSF communications; this provides a means for users to perform functions through a direct interaction with the TSF. The user or TSF can initiate the exchange, which is guaranteed to be protected from modification by untrusted applications.

an overview of security assurance and CC evaluation assurance levels

The assurance requirements for the CC are defined in Part 3 of the CC. The taxonomy for assurance requirements is similar to that for functional requirements. Part 3 contains two classes containing the assurance requirements for PP and ST evaluations, seven classes from which the evaluation assurance requirements can be chosen, and a class dealing with assurance maintenance. These ten classes are summarised below.

Evaluation of PPs and STs

Assurance classes are provided for the evaluation of PPs (Class APE) and STs (Class ASE). All of the requirements in the relevant class need to be applied for a PP or ST valuation. The criteria need to be applied in order to find out whether the PP or ST is a meaningful basis for a TOE evaluation.

Protection Profile Evaluation (APE)

The goal here is to demonstrate that the PP is complete, consistent and technically sound. Further, the PP needs to be a statement of the requirements for an evaluatable TOE. The families in this class are concerned with the TOE Description, the Security Environment, the Security Objectives and the TOE Security Requirements.

Security Target Evaluation (ASE)

The goal here is to demonstrate that the ST is complete, consistent and technically sound, and is a suitable basis for the TOE evaluation. The requirements for the fami- lies of this class are concerned with the TOE Description, the Security Environment, the Security Objectives, any PP Claims, the TOE Security Requirements and the TOE Summary Specification.

Evaluation Assurance Classes

Configuration Management (ACM) 

Configuration management requires that the integrity of the TOE is adequately preserved. Specifically, configuration management pro- vides confidence that the TOE and documentation used for evaluation are the ones prepared for distribution. The families in this class are concerned with the capabilities of the CM, its scope and automation.

Delivery and Operation (ADO)

This class provides families concerned with the measures, procedures and standards for secure delivery, installation and operational use of the TOE, to ensure that the security protection offered by the TOE is not compromised during these events.

Development (ADV)

The families of this class are concerned with the refinement of the TSF from the specification defined in the ST to the implementation, and a mapping from the security requirements to the lowest level representation.

Guidance Documents (AGD)

Guidance documents are concerned with the secure operational use of the TOE, by the users and administrators.

Life Cycle Support (ALC)

The requirements of the families concerned with the life-cycle of the TOE include lifecycle definition, tools and techniques, the security of the development environment and the remediation of flaws found by TOE consumers.

Tests (ATE)

This class is concerned with demonstrating that the TOE meets its functional requirements. The families address coverage and depth of developer testing and requirements for independent testing.

Vulnerability Assessment (AVA)

This class defines requirements directed at the identification of exploitable vulnerabilities, which could be introduced by construction, operation, misuse or incorrect configuration of the TOE. The families identified here are concerned with identifying vulnerabilities through covert channel analysis, analysis of the configuration of the TOE, examining the strength of mechanisms of the security functions, and identifying flaws introduced during the development of the TOE.

Assurance Maintenance Class

Maintenance of Assurance (AMA)

This class provides requirements that are intended to be applied after a TOE has been certified against the CC. These requirements are aimed at assuring that the TOE will continue to meet its security target as changes are made to the TOE or its environment. The class contains four families. 

• The first covers the content of the assurance maintenance plan, which covers the nature of proposed changes and the controls which govern them. 
• The second family covers the security categorization of TOE components. 
• The third and fourth cover the analysis of changes for security impact, and the provision of evidence that procedures are being followed. This class provides building blocks for the establishment of assurance maintenance schemes.

Security assurance

Evaluation Assurance Levels

The CC contains a set of defined assurance levels constructed using components from the assurance families. These levels are intended partly to provide backward compatibility to source criteria and to provide internally consistent general-purpose assurance packages. Other groupings of components are not excluded. To meet specific objectives an assurance level can be augmented by one or more additional components.

Assurance levels define a scale for measuring the criteria for the evaluation of PPs and STs. Evaluation Assurance Levels (EALs) are constructed from the assurance components detailed opposite. Every assurance family contributes to the assurance that a TOE meets its security claims. EALs provide a uniformly increasing scale which balances the level of assurance obtained with the cost and feasibility of acquiring that degree of assurance. There are seven hierarchically ordered EALs. The increase in assurance across the levels is accomplished by substituting hierarchically higher assurance components from the same assurance family, and by the addition of assurance components from other assurance families.

The seven EALs are as follows:

EALs		Technical implication	Business implication
EAL 1	functionally tested	EAL l is applicable where some confidence in the correct operation is required, but the threats to security are not viewed as serious. It will be of value where independent assurance is required to support the contention that due care has been exercised with respect to the protection of personal or similar information.	This level provides an evaluation of the TOE as made available to the customer, including independent testing against a specification, and an examination of the guidance documentation provided. It is intended that an EAL1 evaluation could be successfully conducted without assistance from the developer of the TOE, and for minimum outlay. An evaluation at this level should provide evidence that the TOE functions in a manner consistent with its documentation, and it provides useful protection against identified threats.
EAL 2	structurally tested	EAL 2 requires the co-operation of the developer in terms of the delivery of design information and test results, but should not demand more effort on the part of the developer than is consistent with good commercial practice. As such it should not require a substantially increased investment of cost or time.	EAL 2 is applicable in those circumstances where developers or users require a low to moderate level of independently assured security in the absence of ready availability of the complete development record. Such a situation may arise when securing legacy systems, or where access to the developer may be limited.
EAL 3	methodically tested and checked	EAL 3 permits a conscientious developer to gain maximum assurance from positive security engineering at the design stage, without substantial alteration of existing sound development practices. It is applicable where the requirement is for a moderate level of independently assured security, with a thorough investigation of the TOE and its development without incurring substantial re-engineering costs.	An EAL 3 evaluation provides an analysis supported by testing based on “grey box” testing, selective independent confirmation of the developer test results, and evidence of a developer search for obvious vulnerabilities. Development environment controls and TOE configuration management are also required.
EAL 4	methodically designed, tested and reviewed	EAL 4 permits a developer to maximize assurance gained from positive security engineering based on good commercial development practices. Although rigorous, these practices do not require substantial specialist knowledge, skills and other resources. EAL4 is the highest level at which it is likely to be economically feasible to retrofit to an existing product line. It is applicable in those circumstances where developers or users require a moderate to high-level of independently assured security in conventional commodity TOEs, and there is willingness to incur some additional security-specific engineering costs.	An EAL 4 evaluation provides an analysis supported by the low-level design of the modules of the TOE, and a subset of the implementation. Testing is supported by an independent search for obvious vulnerabilities. Development controls are supported by a life-cycle model, identification of tools, and automated configuration management.
EAL 5	semiformally designed and tested	EAL 5 permits a developer to gain maximum assurance from security engineering based on rigorous commercial development practices, supported by the moderate application of specialized security engineering techniques. Such a TOE will probably be designed and developed with the intent of achieving EAL5 assurance. It is likely that the additional costs attributable to EAL5 requirements, relative to rigorous development without application of specialist techniques, will not be large. EAL5 is applicable where the requirement is for a high level of independently assured security in a planned development, with a rigorous development approach, but without incurring unreasonable costs for specialized security engineering techniques.	An EAL 5 evaluation provides an analysis that includes all of the implementations. Assurance is supplemented by a formal model and a semiformal presentation of the functional specification and high-level design, and a semiformal demonstration of correspondence. The search for vulnerabilities must ensure resistance to penetration attackers with a moderate attack potential. Covert channel analysis and modular design are also required.
EAL 6	semiformally verified design and tested	EAL 6 permits a developer to gain high assurance from the application of specialized security engineering techniques in a rigorous development environment and to produce a premium TOE for protecting high-value assets against significant risks. EAL6 is applicable to the development of specialized security TOEs, for application in high-risk situations where the value of the protected assets justifies the additional costs.	An EAL 6 evaluation provides an analysis that is supported by a modular and layered approach to design, and a structured presentation of the implementation. The independent search for vulnerabilities must ensure resistance to penetration attackers with a high attack potential. The search for covert channels must be systematic. The development environment and configuration management controls are further strengthened.
EAL 7	formally verified design and tested	EAL 7 is applicable to the development of security TOEs for application in extremely high-risk situations, and/or where the high value of the assets justifies the higher costs. The practical application of EAL7 is currently limited to TOEs with tightly focused security functionality that is amenable to extensive formal analysis.	For an EAL 7 evaluation, the formal model is supplemented by a formal presentation of the functional specification and high-level design, showing correspondence. Evidence of developer “white box” testing and complete independent confirmation of developer test results are required. The complexity of the design must be minimized.

Each of the seven CC Evaluation Assurance Levels is summarised below. EAL1 is the entry-level. Up to EAL4 increasing rigor and detail are introduced, but without introducing significantly specialized security engineering techniques. EAL1-4 can generally be retrofitted to pre-existing products and systems.

Above EAL4 increasing application of specialized security engineering techniques is required. TOEs meeting the requirements of these levels of assurance will have been designed and developed with the intent of meeting those requirements. At the top level (EAL7) there are significant limitations on the practicability of meeting the requirements, partly due to substantial cost impact on the developer and evaluator activities, and also because anything other than the simplest of products is likely to be too complex to submit to current state-of-the-art techniques for formal analysis.

Evaluation Package Summary (acc. to CC v3.x)

Assurance Class	Assurance  Family	EAL1	EAL2	EAL3	EAL4	EAL5	EAL6	EAL7
Security Target (ST) Evaluation	ASE_CCL	1	1	1	1	1	1	1
	ASE_ECD	1	1	1	1	1	1	1
	ASE_INT	1	1	1	1	1	1	1
	ASE_OBJ	1	2	2	2	2	2	2
	ASE_REQ	1	2	2	2	2	2	2
	ASE_SPD	1	1	1	1	1	1	1
	ASE_TSS	1	1	1	1	1	1	1
Development	ADV_ARC		1	1	1	1	1	1
	ADV_FSP	1	2	3	4	5	5	6
	ADV_IMP				1	1	2	2
	ADV_INT					2	3	3
	ADV_SPM						1	1
	ADV_TDS		1	2	3	4	5	6
Guidance documents	AGD_OPE	1	1	1	1	1	1	1
	AGD_PRE	1	1	1	1	1	1	1
Life-cycle support	ALC_CMC	1	2	3	4	4	5	5
	ALC_CMS	1	2	3	4	5	5	5
	ALC_DEL		1	1	1	1	1	1
	ALC_DVS			1	1	1	2	2
	ALC_FLR
	ALC_LCD			1	1	1	1	2
	ALC_TAT				1	2	3	3
Tests	ATE_COV		1	2	2	2	3	3
	ATE_DPT			1	2	3	3	4
	ATE_FUN		1	1	1	1	2	2
	ATE_IND	1	2	2	2	2	2	3
Vulnerability assessment	AVA_VAN	1	2	2	3	4	5	5