Transition Guide Summary of changes in the CC/CEM from v2.3 to v3.1

Technical Editor: NIAP / Common Criteria Evaluation and Validation Scheme

Version 1, September 2008

General purpose:

The intention of this document is to help people involved in Common Criteria (CC) evaluations using the version 2.3 of the standard to provide a summary of changes in the CC/CEM from version 2.3 to version 3.1.

Field of special use: vendors that have performed previously an evaluation of a product using CC v2.3 and are now planning to perform a re-evaluation using CC v3.1

1. Overview of Common Criteria Changes

1.1. Part 1- Introduction and general model

1.2. Part 2- Security functional components

1.3. Part 3- Security assurance components

a. ASE/APE - Security Target evaluation / Protection Profile evaluation

b. ACM/ADO/AGD/ALC - Life Cycle Support / Guidance Documentation

c. ADV - Development

d. ATE - Test

e. AVA - Vulnerability Assessment

1.4. CEM - Evaluation methodology

2 Mapping of Changes to Assurance Components

2.1. Mapping of ASE/APE requirements

2.2. Mapping of ACM/ADO/ALC/AGD requirements

2.3. Mapping of ADV requirements

2.4. Mapping of ATE requirements

2.5. Mapping of AVA requirements

1. Overview of Common Criteria Changes

1.1.Part 1- Introduction and general model

Part 1 was made clearer, better reflecting the whole CC. This primarily consists of establishing and using a more consistent terminology, and to reflect the changes that were made to ASE/APE.

1.2.Part 2- Security functional components

Part 2 has had little changes from v2.3 to v3.1. The only notable change is the deletion of FPT_SEP and FPT_RVM. These were deleted as optional SFRs on the grounds that they describe attributes of any but the lowest assurance TSFs, and have been replaced by the ADV_ARC assurance requirement family. The descriptions of how the TSF cannot be bypassed and how it protects itself (FPT_RVM and FPT_SEP, respectively) should be sufficient for the description of how the TSF is of a sound architecture (ADV_ARC). Past evaluations have suffered from the lack of a comprehensive approach to addressing this critical principle, so the ADV_ARC requirements were crafted to mandate specific evidence be provided for analysis.

1.3.Part 3- Security assurance components

The changes to part 3, and their causes, are so varied that it would not be useful to attempt a consolidated global summary. Instead, the classes, or groups thereof, are discussed.

a. ASE/APE - Security Target evaluation / Protection Profile evaluation

ASE and APE contained numerous instances where elements were stated such that work was repeated. In addition, there was insufficient guidance on determining the adequacy of Assumption, Threat, OSP, or Security Objectives statements; consequently, this text could be determined to pass, yet prove to be useless for end users (i.e. potential customers).

The approach taken in rewriting these families was to organize the descriptions to yield a useful resulting ST/PP, while streamline the work in evaluating it. Included in this reorganization was providing descriptions of good Assumption, Threat, OSP, and Security Objectives statements, as well as focusing on the fact that the purpose of the TOE Summary Specification is to explain how the TOE meets its requirements.

A summary mapping of the PP contents as specified in versions 2.3 and 3.1 can be found in Annex 1. In this table, the contents as defined in Figure 11 (v2.3) and Figure 9 (v3.1) of Part 1 have been put into outline format, and then mapped.

b. ACM/ADO/AGD/ALC - Life Cycle Support / Guidance Documentation

ACM/ADO/AGD/ALC were, for the most part, just rearranging the contents. The primary problem with v2.3 was that there was no clear delineation among them. For example, the configuration management requirements addressed in ACM should be in place over the entire lifecycle of the TOE, which is in fact the subject of ALC; and the actions required by the administrator (which are described in AGD) might also include actions associated with the start-up of the TOE, which is part of ADO.

These four classes were therefore rearranged into two: ALC which addresses the requirements associated with the developer’s site, and AGD which addresses all of the requirements associated with the user’s/ customer’s site.

A summary mapping of the ACM/ADO/AGD/ALC requirements of versions 2.3 and 3.1 can be found in Annex 3.

c. ADV - Development

The problems with v2.3 of ADV were varied. In some cases it called for added work that was inefficient (RCR calling for a separate correspondence that would be much more straightforward if incorporated into the other families, à la v1.0). In some cases, it reflected a technology bias that the CC purported not to have (the two levels of abstraction approach in HLD/LLD is infeasible for very complex TOEs and unnecessary for very simple TOEs). In some cases, the components were not granular enough to allow the assurance to track along with the EAL scale (FSP remained unchanged from EAL1 through EAL3). Some basic IT security principles were completely missing (the absence of an architecture argument meant that that all of the claimed security functions could be corrupted or bypassed, making them meaningless). And in all cases, there was no acknowledgement that some parts of the TSF are more critical and security-interesting than others, the result of which was that the analysis had to be performed -- even on parts that no security professional would bother with - thereby expending vast amount of unnecessary effort.

The 3.1 version of ADV reflects a reasonable scale of increasing assurance with a corresponding amount of work. Although version 3.1 has more text (elements in the components and, hence, more work units in the methodology), this does not mean more work for evaluators/developers/certifiers; in fact, a considerable amount of the text describes both the principles underlying security analysis as well as how to save effort in performing it.

A summary mapping of the ADV requirements of versions 2.3 and 3.1 can be found in Annex 4.

d. ATE - Test

ATE was updated to reflect the fact that COV is tied to the testing of TSFI (and is therefore tied to the functional specification), while DPT was updated to reflect the levels of TDS.

A summary mapping of the ATE requirements of versions 2.3 and 3.1 can be found in Annex 5.

e. AVA - Vulnerability Assessment

The AVA class consists of only one family in v3.1 - AVA_VAN. AVA has removed the explicit notion of SOF (to reflect there is no longer a separate SOF claim made in PPs/STs). However, the evaluator should consider the resistance to attack of security functions in AVA_VAN. Most of the MSU analysis has been merged into the AGD family (because it simply extends the requirements of the quality of those documents). Finally, it created a new lowest level of vulnerability analysis, based upon the public domain and removed the requirements that the developer performs a vulnerability assessment; note that vulnerability analysis now bears the trigraph "VAN".

A summary mapping of the AVA requirements of versions 2.3 and 3.1 can be found in Annex 2.

1.4.CEM - Evaluation methodology

The CEM was rearranged into class/family/component, echoing the structure of Part 3, rather than being arranged by EAL as the previous version had been. It also was not limited to the components that make up EALs 1-4: if methodology for any higher-level component was available, it is included. However, mutual recognition is still limited to EAL4.