CC Security Certificate Documents

In this section, we present the various documents that result from the CC certification scheme. The CC certification prescribes a common struc-ture for security certificates to facilitate comparison between certified products. Common Criteria is, infact, a multidocument certification scheme -i.e., the CC certification results in several certification documents. The CC certification results in the following documents:

• Protection Profile

• Security Target

• Evaluation Report

• Certification Report

Among these documents, the Protection Profile is required only when the product claims conformance to a protection profile. All the documents, except the evaluation report are publicly available documents. These docu-ments are intended for human consumption and are represented in natural language and stored asPDF documents.

Security Target

The Security Target (ST) is the most important and informative among the certification documents. The structure of the ST is defined by the CC scheme and its overview is shown in Figure 3.1.

1. The Security Target Identification describes the Target of Evaluation (TOE) at three levels of abstraction:

• Security Target Reference identifies the security target, it consists of the following elements: ST Title, ST version and ST date.

37

Figure 3.1: Security Target Structure Overview

• TOE Reference provides identification material for the TOE and it consists of the TOE title, TOE version, TOE Build number, TOE developer, Evaluation Sponser.

• TOE Overview describes in natural language the TOE, its archi-tecture, the physical and logical boundaries for the TOE.

2. An ST has the following conformance claims:

• CC conformance specifies the CC version based on which the ST is written, this is essential since each CC version has a certain set of criteria and products that have been certified based on different CC versions cannot be compared in a straightforward manner. It further describes the version of CC standard that the ST conforms to - which implies that the SFRs and SARs in the ST are based only upon the components described in the CC version. While CC extended implies that at least one SFR or SAR in the ST is not based upon the components described in the CC version.

3.2. CC CERTIFICATION SCHEME

• PP Conformance: If the ST conforms to any protection profiles, the PPs should be identified clearly.

• In case the ST conforms to additional CC packages, these must be stated as well. In addition, the conformance rationale for all the different elements must be provided.

3. The Security Problem Definition specifies the security problem that is addressed by the TOE. The actual process of defining the security problem is outside the scope of the CC certification scheme.

• A security problem can be due to some threats that were identi-fied for the TOE or the Operational Environment.

• The security problem can also arise due to organizational secu-rity policies that require certain assets to be secured.

• Any assumptions that are made for the OE are also specified in this section. These assumptions are considered to be true during evaluation and not tested in any way.

4. Security Objectives are basically a concise and abstract statement of the solution that is intended to be implemented in the TOE that will counter the problem identified by a security problem definition. The high level security objectives are divided into two part wise solutions:

• Security Objectives for the TOE: The TOE provides certain secu-rity functionality that solves a certain part of a secusecu-rity problem definition.

• Security Objectives for the OE: the OE of the TOE provides tech-nical and procedural measures to assist the TOE in correctly pro-viding its security functionality (defined by the Security objec-tives for the TOE).

• The ST contains a tracing between the security objectives and the security problem definitions that they solve (completely or partially) and in addition, there should be a set of justifications provided that show how each security objective addresses a (part of ) security problem definition such as threats, OSPs and as-sumptions.

5. Security Requirements basically consist of two kinds of requirements:

• Security Functional Requirements that translate the security ob-jectives that are described on an ad-hoc basis to a standardized 39

language. They are more detailed than the security objectives but refrain from being implementation specific. A rationale and tracing must be provided between each SFRs and the Security objectives that they map to.

• Security Assurance Requirements describe how the TOE must be evaluated using the standardized language that is specified in the CC scheme. It facilitates comparison between two STs. In addition, the ST should also contain the rational for choosing the appropriate SARs.

6. The TOE Summary specification informs how the SFRs are satisfied by the TOE implementation. It should provide general technical mecha-nisms that the TOE uses to provide the SFR.

Protection Profile

Protection profiles are typically written by users or user communities, regulatory bodies, or a group of developers that define a common set of se-curity needs for a certain kind of products. The protection profiles structure is similar to the security target structure as shown in Figure 3.2, the key dif-ference is that while a security target is specific to an implementation of the product, the protection profile is described in an implementation indepen-dent manner in order to cater a range of similar products. In addition, the PP clearly states how security targets should conform to it:

• Strict conformance requires that security targets must meet all the requirements that are mentioned in the PP, such as threats, security objectives, SFRs, SARs among others.

• Demonstrable conformance requires that STs must offer a solution to the generic security problem described in the PP, but it can be done in a manner that is equivalent or more restrictive than what is described in the PP.