transition guide for alc, acm, ado and agd

Transition guide for ALC, ACM, ADO and AGD

Version 2.0, 22.01.2008

Transition guide for ALC, ACM, ADO and AGD Version 2.0, 22.01.2008

2 Bundesamt für Sicherheit in der Informationstechnik

Bundesamt für Sicherheit in der Informationstechnik Postfach 20 03 63 53133 Bonn Tel.: +49 228 99 9582-111 E-Mail: [email protected] Internet: http://www.bsi.bund.de

© Bundesamt für Sicherheit in der Informationstechnik 2007

Transition guide for ALC, ACM, ADO and AGD Contents Version 2.0, 22.01.2008

Bundesamt für Sicherheit in der Informationstechnik 3

Contents Contents 3

List of Tables 7

List of Figures 9

List of Abbreviations 10

1. Introduction 11 1.1 Overview of the restructuring 11 1.2 Graphical representation of the restructuring 13 1.3 Effects on evaluation assurance levels 14

2. New aspects 15 2.1 Integration (RI #183) 15 2.2 Production 15 2.3 Handling of standards in ALC_TAT (RI #71) 16 2.4 Refinement of CM access control 16 2.5 Delivery (RI #128, RI #210) 16 2.6 Developer IGS 17

3. Discussion on terminology in ACM-ALC-ADO-AGD 18 3.1 Overview 18 3.2 Configuration Management 20 3.3 Life-cycle 21 3.3.1 Life-cycle model 21 3.3.2 Acceptance 23

4. ALC_DVS 24 4.1 ALC_DVS.1 (Identification of security measures) 24 4.2 ALC_DVS.2 (Sufficiency of security measures) 24 4.3 Overview of element and work unit coverage 25

5. ALC_FLR 26 5.1 ALC_FLR.1 (Identification of security measures) 26 5.2 ALC_FLR.2 (Flaw reporting procedures) 26 5.3 ALC_FLR.3 (Systematic flaw remediation) 26

6. ALC_LCD 27 6.1 ALC_LCD.1 (Developer defined life-cycle model) 27 6.2 ALC_LCD.2 (Standardised life-cycle model) 27

Contents Transition guide for ALC, ACM, ADO and AGD Version 2.0, 22.01.2008


6.3 ALC_LCD.3 (Measurable life-cycle model) 27 6.3.1 Comments on CC 3.0 Revision 2 (July 2005) 27 6.3.2 Discussion 28 6.3.3 Proposed specific changes in CC and CEM 31 6.3.4 Documents 36

7. ALC_TAT 38 7.1 ALC_TAT.1 (Well-defined development tools) 38 7.2 ALC_TAT.2/3 (Compliance with implementation standards/ – all parts) 38

8. ACM_SCP 39 8.1 Strict separation of CM capability and scope 39 8.2 Components 39 8.3 Elements 40 8.3.1 Overview 40 8.3.2 Wording and numbering of the new ALC_CMS elements 41 8.3.3 Verification that the ACM_SCP elements are covered in the new structure 41

8.4 Work units 42

9. ACM_CAP 43 9.1 Basic considerations 43 9.2 Components 43 9.3 Elements 44 9.3.1 Preliminary remarks 44 9.3.2 Overview 44 9.3.3 Wording and numbering of the new ALC_CMC elements 45 9.3.4 Verification that the ACM_CAP elements are covered in the new structure 47

9.4 Work units 48

10. ACM_AUT 50 10.1 Merging of CM capability and automation 50 10.2 Components 50 10.3 Elements 51 10.3.1 Overview 51 10.3.2 Verification that the ACM_AUT elements are covered in the new structure 51

10.4 Work units 52

11. AGD 53 11.1 Basic considerations 53 11.2 Components 53

Transition guide for ALC, ACM, ADO and AGDContents Contents Version 2.0, 22.01.2008


11.3 Elements 53 11.4 Work units 56

12. AVA_MSU 58 12.1 Basic considerations 58 12.2 Components 58 12.3 Elements 59 12.4 Work units 61

13. ADO_DEL / developer’s procedures 63 13.1 Basic considerations 63 13.2 Components 63 13.3 Elements 64 13.4 Work units 64

14. ADO_DEL / user’s procedures 65 14.1 Basic considerations 65 14.2 Components 65 14.3 Elements 65 14.4 Work units 66

15. ADO_IGS / user’s procedures 67 15.1 Basic considerations 67 15.2 Components 67 15.3 Elements 67 15.4 Work units 68

16. ADO_IGS / developer’s procedures 69 16.1 Basic considerations 69 16.2 Components 69 16.3 Elements 70 16.4 Work units 71

17. Interactions with ADV_IMP 72 17.1 Elements 72 17.1.1 The element ADV_IMP.1.3C 72 17.1.2 The element ADV_IMP.2.2E 72

18. Concept for a Guideline on Site Visits 73 18.1 Motivation 73 18.1.1 Reasons for the Need for a Guidance on Site Visits 73

Contents Transition guide for ALC, ACM, ADO and AGD Version 2.0, 22.01.2008


18.2 Proposal for Annex A.4 in CC 3.x (was Annex B.5 in CC 2.x) 73 18.2.1 Introduction 73 18.2.2 General Approach 74 18.2.3 Orientation Guide for the Preparation of the Check List 75

18.3 Example of a checklist 76

19. Further ideas 79 19.1 EAL 1 evaluation 79 19.2 Redundancy between ALC_FLR and ACM_SCP.2 79 19.3 Redundancy between the ALC families DVS and LCD 79

20. Processing of RIs 80 20.1 Overview 80 20.2 Draft interpretation for RI #26 84 20.3 Draft interpretation for RI #71 86 20.4 Draft interpretation for RI #99 88 20.5 Draft interpretation for RI #179 90 20.6 Draft interpretation for RI # 183 92 20.7 Draft interpretation for RI # 196 93 20.8 Draft interpretation for RI #210 95

Transition guide for ALC, ACM, ADO and AGDList of Tables List of Tables Version 2.0, 22.01.2008


List of Tables Table 1: Cross reference of EALs and AGD/ALC components...................................................................... 14 Table 2: Development Security: Correspondence of elements and work units ............................................... 25 Table 3: Comment on ALC_LCD.2 ................................................................................................................ 27 Table 4: Comment 1 on ALC_LCD.3 ............................................................................................................. 28 Table 5: Comment 2 on ALC_LCD.3 ............................................................................................................. 28 Table 6: Comment 3 on ALC_LCD.3 ............................................................................................................. 28 Table 7: CM Scope: Correspondence of components ..................................................................................... 39 Table 8: CM Scope: Correspondence of elements .......................................................................................... 40 Table 9: CM Scope: The new elements........................................................................................................... 41 Table 10: CM Scope: Coverage of elements ................................................................................................... 41 Table 11: CM Scope: Correspondence of elements and work units................................................................ 42 Table 12: CM Capability: Correspondence of components ............................................................................ 43 Table 13: CM Capability: Correspondence of elements (levels 1 to 4) .......................................................... 44 Table 14: CM Capability: Correspondence of elements (level 5) ................................................................... 45 Table 15: CM Capability: The new elements .................................................................................................. 46 Table 16: CM Capability: Coverage of elements ............................................................................................ 48 Table 17: CM Capability: Correspondence of elements and work units......................................................... 49 Table 18: CM Automation: Mapping of components ..................................................................................... 50 Table 19: CM Automation: Mapping of elements........................................................................................... 51 Table 20: CM Automation: Coverage of elements.......................................................................................... 52 Table 21: CM Automation: Mapping of work units........................................................................................ 52 Table 22: Guidance Documents: Mapping of components ............................................................................. 53 Table 23: Guidance Documents: Coverage of elements.................................................................................. 56 Table 24: Guidance Documents: Coverage of work units............................................................................... 57 Table 25: Misuse: Mapping of components .................................................................................................... 58 Table 26: Misuse: Coverage of elements ........................................................................................................ 61 Table 27: Misuse: Coverage of work units...................................................................................................... 62 Table 28: Delivery (developer’s procedures): Mapping of components ......................................................... 63 Table 29: Delivery (developer’s procedures): Mapping of elements .............................................................. 64 Table 30: Delivery (user’s procedures): Mapping of components .................................................................. 65 Table 31: Delivery (user’s procedures): Mapping of elements ....................................................................... 66 Table 32: IGS (user’s procedures): Mapping of components.......................................................................... 67 Table 33: IGS (user’s procedures): Coverage of elements.............................................................................. 67 Table 34: IGS (developer’s procedures): Mapping of components................................................................. 69 Table 35: IGS (developer’s procedures): Coverage of elements..................................................................... 70 Table 36: IGS (developer’s procedures): Coverage of work units .................................................................. 71 Table 37: Checklist part A: Examination of the CM system........................................................................... 77 Table 38: Checklist part B: Examination of the delivery procedures.............................................................. 77 Table 39: Checklist part C: Examination of the developer security ................................................................ 78 Table 40: Consideration of RIs........................................................................................................................ 83 Table 41: RI #26: Identifying (and controlling) CIs for ACM_CAP.2 ........................................................... 84

List of Tables Transition guide for ALC, ACM, ADO and AGD Version 2.0, 22.01.2008


Table 42: RI #71: No quality measures for development tools and implementation standards ...................... 86 Table 43: RI #99: Configuration Items in the Absence of Explicit Scope ...................................................... 89 Table 44: RI #179: When to meet ALC_DVS and ALC_LCD....................................................................... 90 Table 45: RI #183: Life-cycle Specification ................................................................................................... 92 Table 46: RI #196: Splitting CM into separate parts....................................................................................... 94 Table 47: RI #210: Security and "Confidentiality" ......................................................................................... 96

Transition guide for ALC, ACM, ADO and AGD List of Figures Version 2.0, 22.01.2008


List of Figures Figure 1: Mapping of the CC 2.3 classes and families considered here to CC 3.1 classes and families 13 Figure 2: Graphical overview of the terminology in CM and in the Product Life Cycle 19 Figure 3: Guidance Documents: Mapping of elements 54 Figure 4: Misuse: Mapping of elements 59

List of Abbreviations Transition guide for ALC, ACM, ADO and AGD Version 2.0, 22.01.2008


List of Abbreviations Apart from the abbreviations commonly used in the CC and CEM, the following abbreviations are used throughout this document:

AIS Application Notes and Interpretation of the Scheme (used in the German Certification Sche-me)

BSI Bundesamt für Sicherheit in der Informationstechnik (German Certification Overseer)

CCMB Common Criteria Maintenance Board

CCIMB Common Criteria International Maintenance Board (former denotation of the CCMB)

CI Configuration item

CM Configuration management

ISO International Organization for Standardization

ITSEC Information Technology Security Evaluation Criteria

QM Quality management

RI Request for Interpretation

URL Uniform Resource Locator

v Version

WU Work unit

Transition guide for ALC, ACM, ADO and AGD Introduction Version 2.0, 22.01.2008 Overview of the restructuring


1. Introduction

1.1 Overview of the restructuring This document describes and justifies the modifications made in the “new structure” (i.e. version 3.1 of the Common Criteria and CEM) relative to the last official version 2.3 (“previous criteria”) insofar the classes ALC, ACM, ADO, AGD and the component AVA_MSU.1 are concerned.

Changes suggested by the version 2.4 and by open RIs are not treated as “previous criteria” here, though they have also been taken into account and, if incorporated into the new structure, are treated as modifications of the previous criteria. The processing of RIs in the new concept is described in detail in chapter 20.

The objectives of the reorganisation have primarily been to eliminate redundancies and to enhance clarifica-tion of the evaluation work, not to modify the contents of the concerned classes. (However, minor changes of the contents have been made here and there if sensible and helpful for the objectives.)

A graphical representation of the restructuring is given in section 1.2.

In order to clarify the structure, we have tried to set up the minimal life-cycle model that is implicitly as-sumed by the CC (see chapter 3.3.1), and to bring the CC classes and families in line with the life-cycle phases.

The main part of this document (chapters 4 to 16) explains how the considered parts of the previous criteria are embedded into the new structure. Most assurance families are treated in one chapter, some families are split up, the two AGD families are treated conjointly in one chapter.

The families DVS, FLR, LCD, and TAT of the present ALC class are taken over in the new ALC class re-taining their denotations. Their modifications in the new structure are described in the chapters 4 to 7.

Configuration management is an essential part of those measures implemented in order to guarantee a well-defined life-cycle process for a product. So it seems reasonable (and is done in the new structure) to deal with the overlapping between ACM and ALC by consolidating these two classes into one new class. Since ALC (“Life-cycle support”) is the more general term, this one is chosen as name of the new class.

The ACM families SCP and CAP are transferred into the new ALC class. Since they are reorganised (strict separation of capability and scope), they get the new denotations CMS resp. CMC (cf. chapters 8.1 and 9.1). The ACM family AUT is integrated into CMC (cf. chapter 10.1).

The present AGD class deals with the operational phase of the TOE (cf. chapter 11.1). The two families USR and ADM have many similar requirements and belong to the same life-cycle phase, so they are combined to a single new family denoted by AGD_OPE (“Operational user guidance”). The distinction of user types is managed by the introduction of a role concept.

The family AVA_MSU overlaps strongly with AGD and is dissolved in the new structure. The non-redundant MSU requirements are moved to AGD and to AVA_VAN (cf. chapter 0; the description of AVA_VAN, which replaces the previous AVA_VLA, is outside of the scope of this document).

The ADO class is dissolved in the new structure. Presently it consists of the two families DEL (“Delivery”) and IGS (“Installation, generation and start-up”) which are treated as follows:

DEL concerns mainly the developer. The developer delivery activities are shifted into ALC as a new family ALC_DEL (cf. chapter 13). The user delivery activities (i.e. acceptance procedures of the delivered TOE) are merged into the new family AGD_PRE mentioned below (cf. chapter 14),

IGS concerns mainly the user. The user IGS activities are shifted into AGD as a new family AGD_PRE (“Preparative procedures”) (cf. chapter 15). The developer IGS activities are essentially covered by CMC requirements (cf. chapter 16).

Introduction Transition guide for ALC, ACM, ADO and AGD Overview of the restructuring Version 2.0, 22.01.2008


Thus the AGD class in the new structure consists of the two families OPE and PRE and assembles all the user procedures. The two AGD families might even be merged into a single one, but because of the corre-spondence to life-cycle phases, we have preferred the separate treatment.

Chapter 17 discusses some interdependencies with ADV_IMP.

Chapter 18 contains a concept for a guideline on site visits.

A guideline on delivery procedures is in preparation. There are not necessarily impacts on elements and work units.

Some new aspects and their consideration in the new criteria are discussed in chapter 2, some further ideas in chapter 19.

Note: When the old and new denotation of a family/component/element/work unit differ, they are sometimes indicated both consecutively, the old one crossed out, for instance AVA_VLAVAN or ALC_LCD.32.

Transition guide for ALC, ACM, ADO and AGD Introduction Version 2.0, 22.01.2008 Graphical representation of the restructuring


1.2 Graphical representation of the restructuring

ConfigurationManagement

ALC

InfrastructuralManagement

Quality & ProjectManagement

CMSScope

CMCCapa-bility

DVSDevelo-per Se-curity

FLRFlawreme-

diation

LCDLife

CycleDef.

TATTools

&Tech-niques

DELDeli-very

ACM

AUTAuto-

mation

SCPScope

CAPCapa-bility

ALC

DVSDevelo-per Se-curity

FLRFlawreme-

diation

LCDLife

CycleDef.

TATTools

&Tech-niques

ADO

DELDeli-very

IGSInstall.Gener.Startup

AGD

Dev

elop

er

Use

rDeveloper

CC 2.3 structure

CC 3.1 structure

AGD

ADMAdmin.

Gui-dance

USRUserGui-

dance

PREPrepa-ration

OPEOpe-

ration

User

MSU.1MisuseExam.Guid.

AVA

MSU.2/3MisuseAnalys.Testing

AVA

VANVuln.

Analy-sis

VLAVuln.

Analy-sis

Figure 1: Mapping of the CC 2.3 classes and families considered here to CC 3.1 classes and families

Introduction Transition guide for ALC, ACM, ADO and AGD Effects on evaluation assurance levels Version 2.0, 22.01.2008


1.3 Effects on evaluation assurance levels The following table describes the relationship between the evaluation assurance levels and the assurance families and components in the new assurance classes considered here:

Assurance Components by Evaluation Assurance Level Assurance

Class Assurance

Family EAL1 EAL2 EAL3 EAL4 EAL5 EAL6 EAL7

AGD_OPE 1 1 1 1 1 1 1 Guidance documents AGD_PRE 1 1 1 1 1 1 1

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

Life-cycle support

ALC_TAT - - - 1 2 3 3 Table 1: Cross reference of EALs and AGD/ALC components

Transition guide for ALC, ACM, ADO and AGD New aspects Version 2.0, 22.01.2008 Integration (RI #183)


2. New aspects

2.1 Integration (RI #183) Here “integration” means the inclusion of parts into the TOE which have been produced by other manufac-turers. (The instance joining the parts together is called the “integrator”.) The question is how these parts have to be taken into account by the evaluation.

Two subcases can be distinguished:

1. If all of the integrated parts have already been certified on at least the assurance level of the actual evaluation, this is the situation of a composition evaluation (in the sense of the CC supporting document “ETR-lite for composition”). Then the evaluation of the integration procedure consists of verifying the composition requirements.

An issue arises when the ETR of an integrated certified part contains proprietary information that cannot be made available to the integrator. For this case it has been suggested to compile the needed informa-tion in an additional document, the so-called “ETR-lite for composition”. This should be a subset of the ETR and must be usable for the specific needs of the composition evaluation.

“ETR-lite issue”: Is it possible to substitute the ETR of a certified integrated part of the TOE by a document that contains less information on the integrated product?

The treatment of this issue is left to the UK working group on composition evaluation.

2. If parts are integrated in the TOE which have not yet been evaluated, or have only been evaluated on a lower level, then it arises the

“Integration issue”: Is it possible to substitute lacking or unknown adherence of ALC requirements at subcontractors’ sites by acceptance procedures?

The previous criteria didn’t make an explicit statement on this. That meant implicitly, the ALC require-ments had to be adhered from the beginning of the life-cycle, in particular at subcontractors’ sites. So the answer to the issue was “No”.

(However, no additional requirements were imposed for integrated parts that were not security-relevant.)

In order to reduce evaluation work, one might consider two levels to relax this strict requirement:

1. It is sufficient that the integrator gives a statement that ALC has been adhered by the subcontractors.

2. The lowest possible requirement is that the evidence needed for the further evaluation (e.g. the iden-tifiers and the low level design of the integrated parts) has to be present at the integrator’s site.

However, it should be taken into consideration, that each form of attenuation would influence the com-petition, since it advantages developers who outsource parts of the production to subcontractors. The ETR-lite issue (see the preceding section) suggests a comparatively marginal weakening (the integrated parts are actually certified, only it is not possible to give the complete ETR to the evaluator of the inte-grator product), and even that is not generally accepted. So we suggest to continue adhering rigidly to the general validity of the ALC requirements also in the integration situation.

2.2 Production The previous criteria dealt quite extensively with the term “development” of the TOE, whereas “production” appeared only marginally. In our understanding “develop” and derived terms were meant to comprise devel-opment and production. The new criteria shall generally keep this practice.

New aspects Transition guide for ALC, ACM, ADO and AGD Handling of standards in ALC_TAT (RI #71) Version 2.0, 22.01.2008


There are some terms in the configuration management requirements (“manufacturing”, “generation”, “inte-gration”) specifically related to production. We see it the way that these terms all mean production under a certain aspect. In the new structure, they are all replaced by “production”, since the particular aspect be-comes clear from the context. Thereby we think to enhance comprehensibility of the criteria.

This is discussed in more detail in chapter 3.3.1.

2.3 Handling of standards in ALC_TAT (RI #71) ALC_TAT.2 requires the developer to describe the implementation standards to be applied, and the evaluator to confirm that these standards have been applied. However, the component includes no measures of quality or coverage for the implementation standards. This issue is discussed in chapter 20.3.

2.4 Refinement of CM access control The present criteria at CAP.3 require the CM system to provide measures such that only authorised changes are made to the configuration items (ACM_CAP.3.10C). It has been annotated that this requirement leaves a wide scope of interpretation and implementation. For instance, user authentication might open access to the complete server, or the other way round only grants access to files that are needed to fulfil a concrete task assigned to a concrete member of the development staff.

So minimum preconditions for the granting of access might be required subject to the chosen CAP compo-nent, for instance:

ACM_CAP.3 Ownership

ACM_CAP.4 Ownership and need to change

Alternatively this could be managed by security policies defined in the ST.

2.5 Delivery (RI #128, RI #210) The ADO class is dissolved in the new structure. Since the family DEL describes developer procedures, it is located within ALC in the new concept (cf. chapter 13).

Indeed, delivery includes also activities to be performed by the user (acceptance of the received TOE on the basis of the identifiers and procedures defined by the developer). These user acceptance procedures were not explicitly articulated in the previous CC version, and are placed within AGD in the new structure. This is presented in more detail in chapter 14.

By RI #128, the evaluation methodology shall state explicitly, that the delivery documentation should cover the entire TOE, but may contain different procedures for different parts of the TOE. The indicated change in the guidance text belonging to the first work unit of DEL is adopted in the new structure.

From version 2.1 to version 2.2 of the criteria, the scope of ADO_DEL has been broadened beyond integrity to all aspects of security (confidentiality, availability). However (as RI #210 annotates, cf. chapter 20.8), only ADO_DEL.1 actually takes into account all aspects of security, whereas ADO_DEL.2 and ADO_DEL.3 only deal with integrity. Should the higher DEL components 2 and 3 be expanded to confiden-tiality and availability as well? And should “confidentiality” be concerned with the act of the delivery and/or with the contents of the delivery? But these security aspects are only to be considered if required by the PP/ST for the actual TOE (whereas integrity is relevant for all kinds of TOEs). Further, the reasonability of the DEL.3 requirement “prevention of modification” has recently been put into question.

To avoid unnecessary regulations in these areas, in the new concept the three DEL components are merged into a single one which requires the developer to take into account all those security aspects required by the PP/ST for the actual TOE, and to commensurate the level of protection with the chosen level of AVA_VLAVAN.

Transition guide for ALC, ACM, ADO and AGD New aspects Version 2.0, 22.01.2008 Developer IGS


2.6 Developer IGS Whereas IGS mainly deals with user activities, procedures at the development site have also to be taken into account as is pointed out in the CEM. Since developer and user activities belong to different life-cycle phases, they are assigned to different CC families. User IGS procedures, as all user activities, are assembled in families of the AGD class in the new structure (cf. chapter 15). Developer IGS activities are covered by CM capability requirements, cf. the discussion in chapter 16.

Discussion on terminology in ACM-ALC-ADO-AGD Transition guide for ALC, ACM, ADO and AGD Overview Version 2.0, 22.01.2008


3. Discussion on terminology in ACM-ALC-ADO-AGD

3.1 Overview This chapter discusses definitions for the terms identified as needing a common understanding in CCMB discussions on the ACM, ALC, ADO, AGD classes.

These definitions are compiled in a glossary in Part 1 of the new criteria, and are resumed in Part 3 where they are needed.

Meanwhile, a general point arises:

Many terms and passages of the CC reveal their origin from the software world and are often not suitable when evaluating hardware TOEs or TOEs with hardware components.

(For instance: The production phase is dealt with only marginally.)

So it would be a useful long-term objective to free the CC from the software specific terms (or to convert these passages into examples) and to find generally applicable formulations.

As a first step, some examples relating to hardware TOEs have been introduced into the CEM.

On the following page, we present a graphical description of many of the terms used in configuration man-agement and in the product life-cycle with their relations, that is also contained in Part 1 of the new criteria.

Transition guide for ALC, ACM, ADO and AGD Discussion on terminology in ACM-ALC-ADO-AGD Version 2.0, 22.01.2008 Overview


CM System

CM Usage Doc.

CM Procedures

Proc.-Doc.

Productspecific

CM System

Tool-Doc.

CM Output Actions

manualCM controlmeasures

CM Tools

defines

use

produce

enforces

use

CM Output Doc.

CM items

Config.List

cont ains

controls

produce

CMPlan

CMSystemRecords

*CM Documentation = CM Usage Doc. + CM Output Doc.

User‘s Responsibility

Development

Testing

Production

Developer‘s Responsibility

Product Life Cycle

Dispatch

Delivery ProcessAcceptance

Installation

Operation

Operational Environment

(e.g. Manufacturing, Integration, Generation, Storage, Labelling)

Development Environment Preparation

send

Figure 2: Graphical overview of the terminology in CM and in the Product Life Cycle

Discussion on terminology in ACM-ALC-ADO-AGD Transition guide for ALC, ACM, ADO and AGD Configuration Management Version 2.0, 22.01.2008


3.2 Configuration Management The following definitions for all “CM related” terms seem to make most sense (and are compatible to the CC and CEM requirements). These definitions can be found by interpreting a CM system as a specific “man-agement system”.

According to ISO Guide 72 (2001) “Guidelines for the justification and development of management system standards” the following definition holds:

Management system: system to establish policy and objectives and to achieve those objectives.

The policy and objectives for a configuration management system are not explicitly stated, but the following is probably consensus:

• The task of a CM system is to manage certain objects, called “configuration items”, typically source code files, hardware drawings, documents, hardware parts and so on.

• The main objective is to manage the configuration items in such a way, that it can be determined, which configuration items belong together in order to contribute to a specific product (e. g. a software built from certain source files or a hardware built from certain parts).

• One objective (from the security point of view) is to prevent unauthorised modification of configuration items or more generally to prevent unauthorised access.

Using these considerations, the following definitions can be given.

Note: This interpretation for the CM terms can also be found by replacing the “CM” with “QM” in the terms and looking, what the terms would mean in the QM context.

• “CM system” is the overall term for the set of all procedures and tools (including their documentation) used by a developer to maintain configurations of his products during their life-cycles.

[This fits to the meaning of “QM system”.]

All following objects can be considered to be a part of the system. From this definition, terms like “CM pro-cedures” are also clear.

• The “CM usage documentation” is a part of the CM system, which consists of the documents describ-ing, how the CM system is defined and used (this encloses handbooks, regulations, documentation of tools used for CM, if tools are used, and so on).

• The “CM output” are CM related results produced or enforced by the CM system. These CM related results occur as documents (e.g. filled paper forms, CM system records, logging data, hardcopies and electronic output data) as well as actions (e.g. manual measures to fulfil CM instructions). Examples of such CM outputs are configuration lists, CM plans and/or behaviours during the product life-cycle.

• The “CM documentation” consists of the CM usage documentation and the CM output documentation. (“Documentation of the CM system” is the same as “CM documentation”.)

[“CM documentation” corresponds to the meaning of QM documentation.]

• The “CM plan” is a part of the CM documentation. It gives the description, how the CM system is used for a specific project or product.

[This fits to the meaning of QM plan.]

From the point of view of the overall CM system this can be seen as an output document (because it may be produced as part of the application of the CM system). From the point of view of the concrete project it is a usage document because members of the project team use it in order to understand, which steps they have to do during the project.

Transition guide for ALC, ACM, ADO and AGD Discussion on terminology in ACM-ALC-ADO-AGD Version 2.0, 22.01.2008 Life-cycle


For example the CM plan defines the scope of the system for the specific product, because the same system may be used with different scope for different products.

• A “CM item” or “configuration item” is an object managed by the CM system, i.e. which is stored in the CM system directly (e. g. for files) or by reference (e. g. by hardware parts) together with its version.

• The “CM list” or “configuration list” is a CM output document listing all configuration items for a spe-cific product together with the exact version of each CM item relevant for a specific version of the com-plete product (in the CC context this will be the evaluated version).

[Here the comparison to QM systems doesn’t work as it does for the other terms, because “QM list” is not a term used for QM systems with a comparable meaning].

This list allows distinguishing the items belonging to the evaluated version of the product from other ver-sions of these items belonging to other versions of the product.

The final CM list is a specific document for a specific version of a specific product. (Of course the list can be an electronic document inside of a CM tool. In that case it can be seen as a specific view into the system or a part of the system rather than an output of the system. However, for the practical use in an evaluation the configuration list will probably be delivered as a part of the evaluation documentation.)

Some further terms are clear from this:

• “CM access control” is the set of mechanisms and procedures guaranteeing that only authorised access is granted to configuration items.

• “CM system records” are those output documents, which are produced during the operation of the CM documenting important activities. (E.g. the list of modifications of a configuration item together with the ID of the person, who made the changes may be a typical part of these data.)

• “CM tools”: If a CM system is realised or supported by a tool, this tool will be a CM tool (e. g. the stan-dard UNIX tool “CVS” or “Perforce" as a commercial tool).

• “CM evidence” is everything that may be used to establish confidence in the correct operation of the CM system, e.g. CM output, demonstrations provided by the developer, observations, experiments or in-terviews made by the evaluator during a site visit.

3.3 Life-cycle Life-cycle management can be seen as the “highest” level of management for a product or system, since quality management, configuration management, project management and so on can all be seen as part of the life-cycle management. However, this depends on the point of view. A quality manager may see QM as the highest level, because all other management activities contribute to quality.

As CM systems, also “life-cycle management systems” can be discussed. Though the CC doesn’t require such a system, some of the terms used in the CC can be discussed in this context.

The life-cycle of a certain object (e. g. a product or a system) is a sequence of stages of existence of this ob-ject in time. Which stages one uses depends on the object, but usual stages for IT products are development, testing, operation and so on.

3.3.1 Life-cycle model The “life-cycle model” defines, which stages are used in the management of the life-cycle of a certain object, how the sequence of stages looks like and which high level characteristics the stages have. The definition of the Life-Cycle Model is the “Life-Cycle Definition”.

A “measurable life-cycle model” (as required in ALC_LCD.32) is a life-cycle model using some quantitative valuation of the managed product (a “metric”) in order to measure some quality aspects of the object. Typi-

Discussion on terminology in ACM-ALC-ADO-AGD Transition guide for ALC, ACM, ADO and AGD Life-cycle Version 2.0, 22.01.2008


cal metrics are software complexity metrics. The use of such metrics may add assurance in the overall qual-ity of the development process. More details are given in section 6.3.

As indicated in the introduction (1.1), we will try to set up the life-cycle model which is implicitly assumed by the CC. At least four life-cycle phases were clearly distinguishable in the previous criteria that had to be taken into account by the evaluation:

1. Development

2. Delivery

3. IGS (Installation, generation and start-up)

4. Operation (end-usage)

Production did not explicitly appear in the previous criteria; development was meant to comprise develop-ment and production. In the life-cycle model below, production is displayed as a separate life-cycle phase, but in the new requirements the practice is kept to use “development” and related terms (“developer”, “de-velop”) in the more general sense to comprise development and production.

In the requirements of the family ACM_CAP there were used several terms with a meaning similar to pro-duction: Manufacturing, generation, integration. These seem to be closely related to each other:

ACM_CAP.5.13C:

“The integration procedures shall describe how the CM system is applied in the TOE manufacturing process.”

ACM_CAP.5.19C:

“... the use of the integration procedures ensures that the generation of the TOE is correctly per-formed ...”.

We see it the way that the aforementioned terms all meant production under a certain aspect. Since the aspect becomes clear from the context, we think to enhance comprehensibility of the criteria by replacing them all with “production”.

In the case of a software-only TOE, the production phase may be trivial; other phases may be trivial too, for instance IGS in the case of a smart card.

IGS: The CC does not explicitly define the difference between “installation” and “generation”. For instance, it is not really clear if running a setup routine for the TOE has to be regarded as generation or installation. On an abstract level, the ambiguity is even greater. Also, there may be a division of responsibility for the IGS procedures between the user and the developer.

In the new structure, a pragmatic approach as follows is taken: The IGS activities at the development site are dealt with in the context of the production, and the IGS activities at the user’s site (referred to as “installa-tion” of the TOE) in the guidance documentation. “Preparation” comprises user’s acceptance and installation procedures of the received TOE.

So the new structure orientates itself to a life-cycle model consisting of the following five phases:

1. Development

2. Production

3. Delivery

4. Preparation (acceptance and installation)

5. Operation (end-usage)

In the following, we will discuss the boundaries between the subsequent life-cycle phases.

Transition guide for ALC, ACM, ADO and AGD Discussion on terminology in ACM-ALC-ADO-AGD Version 2.0, 22.01.2008 Life-cycle


Development → Production:

The development phase consists of creating the implementation representation (the least abstract representa-tion) of the TOE. Based on the implementation representation, no further design decisions have to be made to produce the TOE.

Production → Delivery:

The production phase consists of transforming the implementation representation into the implementation of the TOE.

The following examples show the type of questions that arise here:

• Transports of parts of the TOE or the unfinished TOE between different development sites is classified here definitely as production, not as delivery.

• Storage of the TOE after its completion might be assigned to either phase. (The CEM supports the view to see it as part of the delivery, cf. paragraph 1263.)

• Production of personalised smart cards, the classification of the developer’s personalisation process being the question.

Delivery → Preparation:

The delivery phase consists of the transfer of the finished TOE into the responsibility of the user. This does not necessarily coincide with the arrival of the TOE at the user’s location.

How should user’s acceptance of the delivered TOE be classified? Since this is a user activity, it has to be described in the user guidance anyway. In order to accommodate CC families and life-cycle phases, in the new structure user’s acceptance procedures are classified as preparation.

Preparation → Operation:

Preparation comprises all the processes that have to be performed (normally) only once after receipt of the TOE at the user’s site to progress the TOE and its environment into the evaluated configuration as described in the ST (this may include such things as booting, initialisation, start-up), whereas “operation” covers those processes which have to be carried out during the continuous end-usage of the TOE.

Hereby all processes at the user’s site are covered. Thus an explicit start-up phase is dispensable, its proc-esses might be assigned either to preparation or to operation, as the case may be.

The preparation phase ends, when the TOE is in its evaluated configuration.

3.3.2 Acceptance A specific part of the life-cycle management is the decision, when managed objects move on to the next step of the life-cycle. This is called “Acceptance”, if it is an explicit decision, which for example depends on a certain quality or maturity of the object. For example the release of an IT product for production or for op-eration after sufficient testing is a typical acceptance step.

“Acceptance procedures” are the procedures followed in order to make such an acceptance step (e. g. it may be defined, that a project manager documents the acceptance of a newly developed product for production by signing a certain paper form).

In the new structure, acceptance procedures during development and production in order to accept a configu-ration item as part of the TOE are described in the CM plan. Acceptance procedures followed by the recipi-ent of the delivered TOE in order to verify its integrity should be described in the user guidance.

ALC_DVS Transition guide for ALC, ACM, ADO and AGD ALC_DVS.1 (Identification of security measures) Version 2.0, 22.01.2008


4. ALC_DVS The two components of ALC_DVS and their denotations have been retained, modifications have been per-formed only within the components.

4.1 ALC_DVS.1 (Identification of security measures) In this component the following redundancy in version 2.3 has been identified:

ALC_DVS.1.2C:

“The development security documentation shall provide evidence that these security measures are followed during the development and maintenance of the TOE.”

with belonging work unit

ALC_DVS.1-3:

“The evaluator shall check the development security documentation to determine that documentary evidence that would be produced as a result of application of the procedures has been generated.”

are covered by

ALC_DVS.1.2E:

“The evaluator shall confirm that the security measures are being applied.”

with belonging work unit

ALC_DVS.1-4:

“The evaluator shall examine the development security documentation and associated evidence to determine that the security measures are being applied.”

Therefore the element ALC_DVS.1.2C with belonging work unit ALC_DVS.1-3 are deleted in version 3.1. The only effect on numbering regards work unit 1-4, which becomes work unit 1-3.

4.2 ALC_DVS.2 (Sufficiency of security measures) First this component contains the same redundancy as ALC_DVS.1 Accordingly the element ALC_DVS.2.2C with belonging work unit ALC_DVS.2-3 are deleted in version 3.1. (To keep the explana-tions in this section traceable, the numbers of the elements and work units are those from version 2.3; the mapping to the new numbers is given in the following section 4.3.)

The title of ALC_DVS.2 is at first glance puzzling since already in ALC_DVS.1 the evaluator is required to determine the sufficiency of the security measures employed, namely by the work unit

ALC_DVS.1-2:

“The evaluator shall examine the development confidentiality and integrity policies in order to de-termine the sufficiency of the security measures employed.”

belonging to the element

ALC_DVS.1.1C:

“The development security documentation shall describe all the physical, procedural, personnel, and other security measures that are necessary to protect the confidentiality and integrity of the TOE de-sign and implementation in its development environment.”

The new feature in ALC_DVS.2 is that now the developer has to justify the sufficiency by the requirement

Transition guide for ALC, ACM, ADO and AGD ALC_DVS Version 2.0, 22.01.2008 Overview of element and work unit coverage


ALC_DVS.2.3C:

“The evidence development security documentation shall justify that the security measures provide the necessary level of protection to maintain the confidentiality and integrity of the TOE.”

(In version 3.1, “evidence” is specified as “development security documentation” since there is no developer action element for “evidence”.)

A work unit for this element has been taken from the German national interpretation AIS 34, version 1.00, 01.06.04:

ALC_DVS.2-4:

“The evaluator shall examine the development security documentation to determine that an appropri-ate justification is given why the security measures provide the necessary level of protection to main-tain the confidentiality and integrity of the TOE.”

The evaluator’s determination of the sufficiency of the security measures required by work unit ALC_DVS.2-2 (belonging to ALC_DVS.2.1C) is more naturally placed behind all the other work units of ALC_DVS.2, thus in version 3.1 is shifted to the end of ALC_DVS.2 as the second work unit belonging to ALC_DVS.2.3C

4.3 Overview of element and work unit coverage CC/CEM version 2.3 AIS 34 CC/CEM version 3.1

DVS.1 DVS.2 DVS.1 DVS.2

Elem. WU Elem. WU Elem. WU Elem. WU -1 -1 -1 1C -1 1C -2

1C -2

1C -2 -3

3C -4 2C -2 2C -3 2C -3 2E -4 2E -5 2E -3 2E -4

Table 2: Development Security: Correspondence of elements and work units

Examples for reading the table:

Element DVS.2.3C from CC version 2.3 corresponds to element DVS.2.2C from CC version 3.1. They have no correspondence in DVS.1 in either version. The corresponding work unit DVS.2-4 comes from the Ger-man AIS 34 and is adopted in CEM version 3.1 as work unit DVS.2-2.

Element DVS.*.2C and work unit DVS.*-3 from version 2.3 have no direct correspondence in version 3.1, but are covered by element DVS.*.2E with corresponding work units DVS.1-3 and DVS.2-4 respectively.

In CC version 2.3, work units DVS.1-2 and DVS.2-2 are identical and belong to identical elements DVS.1.1C and DVS.2.1C respectively. These elements and work unit DVS.1-2 are unchanged in version 3.1, but work unit DVS.2-2 becomes work unit DVS.2-3 which belongs to element DVS.2.2C and not to DVS.2.1C in version 3.1.

ALC_FLR Transition guide for ALC, ACM, ADO and AGD ALC_FLR.1 (Identification of security measures) Version 2.0, 22.01.2008


5. ALC_FLR The three components of ALC_FLR and their denotations have been retained, modifications have been per-formed only within the components. The elements have been grouped by subject, hence the sequence of some elements and work units has changed.

Work units for all ALC_FLR components have basically been taken from CEM version 2.4 of March 2004, and adapted to the performed modifications.

5.1 ALC_FLR.1 (Identification of security measures) The first developer action element is modified as follows:

ALC_FLR.1.1D:

“The developer shall provide document flaw remediation procedures addressed to TOE developers.”

in order to ensure the existence of the flaw remediation procedures documentation referenced in 1C and 4C.

5.2 ALC_FLR.2 (Flaw reporting procedures) Beyond the change in ALC_FLR.1, there is one further modification:

ALC_FLR.2.6C:

“The procedures for processing reported security flaws shall ensure that any reported flaws are cor-rected and the corrections remediated, and the remediation procedures issued to TOE users.”

Fixes cannot be legislated. Some problems may have no solution and can be “remedied” only by “work-arounds” wherein the user is instructed as to how to avoid executing code containing the problem.

The work units –7 and –8 belonging to ALC_FLR.2.6C are modified accordingly.

5.3 ALC_FLR.3 (Systematic flaw remediation) There are no changes in ALC_FLR.3 beyond the changes in ALC_FLR.1 and .2 described in the previous sections.

Transition guide for ALC, ACM, ADO and AGD ALC_LCD Version 2.0, 22.01.2008 ALC_LCD.1 (Developer defined life-cycle model)


6. ALC_LCD The first and last component of ALC_LCD and their denotations have been retained, the second component dealing with standardised life-cycle models has been deleted from the criteria.

For the evaluation of the development environment (to choose the right sites and to ensure that they and also the different life-cycle phases work together correctly), the evaluator has to get an understanding of the life-cycle model used by the developer. Then it is reasonable that the developer provides his life-cycle model to the evaluator. Since evaluation of the development environment starts at EAL 3, the first component of the life-cycle definition family ALC_LCD.1 is shifted from EAL 4 to EAL 3.

This is in line with the previous criteria since although no explicit analysis of LCD was required at the "old" EAL3 both the developer and the evaluator must have an understanding of the TOE’s life-cycle in order to understand all other ALC requirements. In a regular TOE evaluation both get that understanding at EAL3 implicitly since the entire development environment is subject to analysis. That means LCD.1 for EAL3 provide assurance that the life-cycle phases (e.g. represented by different sites) fit together.

6.1 ALC_LCD.1 (Developer defined life-cycle model) The requirements and work units of this component have been left unchanged. The guidance text to work unit 1 has been structured more clearly and supplemented regarding information about subcontractors.

6.2 ALC_LCD.2 (Standardised life-cycle model) From the commenting phase for CC 3.0 (which ended 01.11.2005), the following comment related to ALC_LCD.2 has been received:

Comment on ALC_LCD.2

§17.6 ALC_LCD.2.1D (p170) Standardized Life-Cycle Model

There is nothing in using a standardized model that guarantees good results. Applies to 2.4C as well.

Substitute “well-defined” for “standardized”.

Table 3: Comment on ALC_LCD.2

It is agreed that standardised models do not guarantee good results (particularly since developer defined models may also qualify as standardised). The dim increase in assurance does not justify a separate compo-nent. Consequently the component “Standardised life-cycle models” is deleted in the new criteria; ALC_LCD.3 (“Measurable life-cycle model”) becomes ALC.LCD.2.

6.3 ALC_LCD.3 (Measurable life-cycle model)

6.3.1 Comments on CC 3.0 Revision 2 (July 2005) This section contains the comments related to ALC_LCD.3 from the commenting phase for CC 3.0 (which ended 01.11.2005).

Comment 1 on ALC_LCD.3

§17.6 ALC_LCD.3.1E (p172) Measurements

The whole idea of having measurements is good but nowhere do we describe their usefulness. What is lacking is the idea of standards against which the measurements are compared. The success or failure of the comparison then determines what actions the developer is to take.

ALC_LCD Transition guide for ALC, ACM, ADO and AGD ALC_LCD.3 (Measurable life-cycle model) Version 2.0, 22.01.2008


Table 4: Comment 1 on ALC_LCD.3


Part 3, 17.6, ALC_LCD.3

te There is no definition of what a measurable life cycle actually is. There is no information about what is supposed to be measu-red, except for the mention of “source code complexity” in paragraph 540. Requests for clarification of this requirement in CC v2 were never answered by the NSA. BSI proposed an interpretation based on software development costs (COCO-MO), but could not explain what that had to do with security.

Add some details on what is supposed to be measured and how measuring it would enhance the security of the TOE. If this can’t be done, then consider removing the requirement entire-ly. Note: Source code complexity metrics is a good idea, but the CC needs to say a lot more about them. COCOMO is clearly NOT relevant here. (Not that COCOMO is a bad thing it just isn’t relevant to security ) – it just isn’t relevant to security.)


Note: The following was no official comment, but a question by e-mail. However, it is also a good example of the comments addressed here and therefore included.


In looking over the new ALC, I am unable to find a clear difference between LCD.2 and LCD.3. The text in the element changes, but there is no explanation of what those changes mean, nor is there any change in the methodology. The biggest question that needs to be answered is: what is a *measurable* standardised devel-opment model? [CC v2 para 398 says “A measurable lifecycle model is a model with arithmetic parameters and/or metrics that measure TOE development properties (e.g. source code complexity metrics)” but this isn’t helpful: source code complexity is measured with tools, which makes such things more appropriate for TAT, not LCD.]1

Do any of the popular development models (rapid-prototyping, spiral, waterfall -- none of which is given as examples for LCD.2, which also needs to be corrected) qualify as "measurable"? If so, which ones? If not, why not?


6.3.2 Discussion As a preparation for a disposition of the comments and suggested changes to the CC, we first discuss the nature of the problem and possible approaches to the solution.

6.3.2.1 Nature of the problem

The component ALC_LCD.3 requires the use of “measurable life cycle models”. As example “source code complexity metrics” are mentioned. According to the comments this information is not sufficient to tell de-velopers and evaluators, what to do.

6.3.2.2 Discussion of the goals

First observation

The title “measurable Life Cycle model” used in LCD.3 is a little bit misleading, because one might think of a measure for life cycle models. Of course, what is meant is a Life Cycle model, which includes the use of metrics for properties of the product or of the development processes. So a more correct term would be

1 We do not think, that this side remark on ALC_TAT really is an argument against tool-based measurement in the context of ALC_LCD.3. The following parallel situation shows this: A configuration management system can also be tool based, which doesn’t have the effect that the work from ALC_CMC or ALC_CMS shifts to ALC_TAT.

Transition guide for ALC, ACM, ADO and AGD ALC_LCD Version 2.0, 22.01.2008 ALC_LCD.3 (Measurable life-cycle model)


“measurement-based Life Cycle model2” or “a life cycle model using quality measures”. However, the term “measurable Life Cycle model” is used also elsewhere for the same thing, so we will not propose to change the term.

Second observation

There are no standardised metrics directly measuring the security of a product or of the processes used to develop the product. Therefore we propose that measures are meant, which increase assurance in the product (resp. its development) by measuring its quality. Note, that the quality of a product can be defined as the grade of conformance of the product to the requirements. See for example the book by H. Kan on “Metrics and Models in Software Quality Engineering” [1], chapter 1 “What is software quality?”. We used this book also as a source for much of the following discussion.

If one asks the question: “What does this help for security?”, the answer is: It helps in the same way a good configuration management does: Better processes for development give more assurance in good quality of the results and this in turn gives more insurance that the probability of security flaws, which result from im-plementation errors is smaller. Note that the configuration management requirements of the CC (in ALC_CMS and ALC_CMC) are no direct security requirements (these are in ALC_DVS). Similarly the ALC_LCD-requirements are not immediate security requirements, but quality requirements.

A study done by DFKI (Deutsches Forschungzentrum für Künstliche Intelligenz GmbH) for BSI comes to the same conclusions.

This study (see [2]) gives a good discussion showing, that the measures required by ALC_LCD.3 should be understood as measures giving assurance, that the number of faults in the TOE is as small as possible or in other words, that the quality of the TOE is as high as possible:

“Therefore satisfactory evidence must be provided that shows how the measure will contribute to the minimisation of danger. This can be viewed as the main aim for measurement in a CC context. As a consequence, the measures must be selected based on the validity especially with respect to this main aim or subgoals supporting it. In the first place a measure is suitable with respect to the CC if a cor-relation between the measure and the number of faults to be expected can be stated with a minimum degree of reliability. But also a measure useful for management purposes as for planning and re-scheduling are helpful as badly managed projects are endangered to produce bad quality.“ ([2], page 4)

However the study [2] doesn’t describe, how to decide, which measures are suitable for increasing quality of the product (and therefore assurance in its security) and it doesn’t explicitly draw the conclusion that quality measures are exactly the measures suitable for this. The examples given by the study are no specific quality measures (for example “Lines of Code”, short LOC, is described, but not the “Error density”, which is errors per LOC.).

Examples of quality measures

The book on quality metrics by H. Kan gives several examples of quality measures (see [1], chapter 4). We give these measures in the most simplified form in order to allow a basic understanding:

• defect density: “number of errors found” divided by “size of code”3

• mean time to failure (MTTF): The average time until a flaw in the product leads to a failure during operational use.

2 compare for a similar term: Paul R Croll, “IEEE 1540 - Software Engineering Risk Management: Meas-urement-Based Life Cycle Risk Management”, Proceedings of the 2001 Practical Software Measurement Conference (PSM 2001), 2001;

3 This “size of code” can be measured by different methods, e. g. “lines of code – LOC” or the “function point” method.



• customer problems metric: Number of problems reported by customers in a specified time frame (e. g. half a year after shipping).

Kan distinguishes between measures relevant for a specific product, for a project or for a process. All of these however, can be used to increase the quality of products and therefore the assurance in minimisation of errors in the product.

Intermediate summary

None of the well known life cycle models (like waterfall etc.) is defined as “measurable” as such. There are some standardised or quasi-standardised process models (like CMM, Capability Maturity Model), however, we do not propose to re-commend them in the CC right now until a more thorough study was made (in order to avoid a bias based on knowing some models and not knowing others). See sections 6.3.4.2 and 6.3.4.3 for some quasi-standards and standards related to our topic.

So a short formula for a measurable life cycle model in the sense of ALC_LCD.3 can be given in CC 3.x as follows:

measurable Life Cycle model = developer defined Life Cycle model + the appropriate use of one or more standardised quality metrics

Some further remarks

• One type of measurement is the measurement of “coupling” and “cohesion” of software modules using the “modularity metrics” . These measures show, how well-structured a software was developed, resp. how much unnecessary complexity was avoided. This shows that the complete ADV_INT component in the current CC 3.1 can be seen as a kind of specialised case of LCD.3.

• On tool-based versus non-tool-based measurement methods: We suggest that the CC doesn’t mandate tool based measurement methods. Of course in practice some methods are only feasible when tool based (e. g. counting lines of code).

• Note that quality management standards often include requirements or at least recommendations to use quality measures (e. g. ISO 9000 refers to measurement of customer satisfaction, which is a quality measure).

• Note that the same type of measures as given as examples earlier are also possible for hardware devel-opment, though this is not so well-discussed in literature. So essentially there is no software bias in this interpretation of ALC_LCD.3.

• It may be possible to use metrics for quality improvement, for which this use is not obvious. For exam-ple a metric to estimate the expected cost of a product development may help for quality, if the devel-oper can show that this is used to provide an adequate budget for development projects and that this helps to avoids quality problems coming from resource shortages.

6.3.2.3 Suggested approach

We suggest to

• enhance the relevant text in the CC to make clear that the goal for ALC_LCD.3 is as follows: To gain assurance that the developer uses metrics/measurements in order to increase the quality of his product(s) and/or development process, which in turn increases assurance in the security of the product.

• give some guidance in the corresponding work unit(s), how the evaluator may come to the conclusion that the metrics/measures used by the developer in fact help to this goal.

The main idea of requirements for the developer are as follows:

The developer shall document the use of (one or more) quality metrics in the TOE Life Cycle. Of course “use of a metric” not only means to make measurements and to calculate values but also to define conse-



quences, if the resulting values do not conform to some defined thresholds. E. g. if to many errors are found during testing, this may have the consequence of a new design and implementation cycle. If many errors are measured during the operational phase of a product, this may have impact on the development and testing efforts for new products.

The developer needs to provide an argument, why the use of the measure is suitable. If a metric is well known/well documented and if it is obvious that the use of the metric is suitable to increase quality, the ar-gument may be short. A longer argument may be necessary if the metric is not well known or if it is not ob-vious how it contributes to quality. It may also be necessary to give additional arguments that the metrics is suitable, if it only covers parts of the product or parts of the life cycle.

6.3.3 Proposed specific changes in CC and CEM This chapter shows some draft modifications to the CC and CEM resulting from the preceding considera-tions. Resulting from the deletion of LCD.2, LCD.3 has become LCD.2 in the current criteria.

6.3.3.1 Part 3 (Objectives for ALC_LCD.32)

The following text describing the overall context should be fitted into the section “objectives for ALC_LCD.32”:

ALC_LCD.32 requires a “measurable Life Cycle model”. This means a Life Cycle model, which in-cludes the use of metrics for properties of the product or of the development processes. So a more correct term would be “measurement-based Life Cycle model ” or “a life cycle model using quality measures”. However, the term “measurable Life Cycle model” is common in the discussion of qual-ity metrics.

There are no standardised metrics directly measuring the security of a product or of the processes used to develop the product. Therefore ALC_LCD.32 proposes that measures are used, which in-crease assurance in the product (resp. its development) by measuring its quality. Note, that the qual-ity of a product can be defined as the grade of conformance of the product to the requirements, which includes security requirements.

This approach supports assurance in the security of a product in the same way a good configuration management does: Better processes for development give more assurance in good quality of the re-sults and this in turn gives more insurance that the probability of security flaws, which result from implementation errors is smaller. Note that the configuration management requirements of the CC (in ALC_CMS and ALC_CMC) are no direct security requirements (these are in ALC_DVS). Simi-larly the ALC_LCD-requirements are not immediate security requirements, but quality requirements.

Examples of quality measures

The literature on quality metrics provides several examples of quality measures. The following is a list of some measures in the most simplified form in order to allow a basic understanding:

• defect density: “number of errors found” divided by “size of code”

• mean time to failure (MTTF): The average time until a flaw in the product leads to a failure during operational use.

• customer problems metric: Number of problems reported by customers in a specified time frame (e. g. half a year after shipping).

It is possible to distinguish between measures relevant for a specific product, for a project or for a process. All of these however, can be used to increase the quality of products and therefore the as-surance in minimisation of errors in the product.

None of the well known life cycle models (like the waterfall model etc.) is defined as “measurable” by default. There are some standardised or quasi-standardised process models including measurabil-



ity (like CMM). In order to avoid a restriction to a small number of existing models, the use of one of these models is not mandatory. Instead the following formula for a measurable life cycle model in the sense of ALC_LCD.32 is assumed:

measurable Life Cycle Model = developer defined Life Cycle model + the appropriate use of one or more standardised quality metrics

Therefore the evaluator should expect that the developer uses a life cycle model and additionally documents quality measures, which he integrates into the model.

It is not mandatory that measurement methods are tool based. On the other hand in practice some methods are only feasible when tool based (e. g. counting lines of code).

Note that quality management standards often include requirements or at least recommendations to use quality measures (e. g. ISO 9000 refers to measurement of customer satisfaction, which is a qual-ity measure).

Note that the same type of measures as given as examples earlier are also possible for hardware de-velopment, though this is not so well-discussed in literature. Therefore the whole discussion applies to hardware and software development in the same way.

It may be possible to use metrics for quality improvement, for which this use is not obvious. For ex-ample a metric to estimate the expected cost of a product development may help to improve quality, if the developer can show that it is used to provide an adequate budget for development projects and that this helps to avoid quality problems coming from resource shortages.

The requirements in ALC_LCD.32 are designed to gain assurance that the developer uses met-rics/measurements in order to increase the quality of his product(s) and/or development process, which in turn increases assurance in the security of the product.

The main idea of requirements for the developer is as follows:

The developer shall document the use of (one or more) quality metrics in the TOE Life Cycle. Of course “use of a metric” not only means to make measurements and to calculate values but also to define consequences, if the resulting values do not conform to some defined thresholds. E. g. if to many errors are found during testing, this may have the consequence of a new design and implemen-tation cycle. If many errors are measured during the operational phase of a product, this may have impact on the development and testing efforts for new products.

The developer needs to provide an argument, why the use of the measure is appropriate. If a metric is well known/well documented and if it is obvious that the use of the metric is suitable to increase quality, the argument may be short. A longer argument may be necessary if the metric is not well known or if it is not obvious how it contributes to quality. It may also be necessary to give additional arguments that the metric is suitable, if it only covers parts of the product or parts of the life cycle.

6.3.3.2 Part 3, detailed changes (based on Version 3.0, as of July 2005)

Section “4.3 Terms ... related to ALC” (para. 68):

measurable life-cycle model a life-cycle model using some quantitative valuation (arithmetic para-meters and/or metrics) of the managed product in order to measure development properties of the product. - Typical metrics are source code complexity metrics, defect density (errors per size of co-de) or mean time to failure.

Section “17.6 ... ALC_LCD”, application notes, last para. (para. 540):

A measurable life-cycle model is a model using some quantitative valuation (arithmetic parameters and/or metrics) of the managed product in order to measure development properties of the product. - Typical metrics are source code complexity metrics, defect density (errors per size of code) or mean time to failure. For the security evaluation all those metrics are of relevance, which are used to inc-



rease quality by decreasing the probability of faults and thereby in turn increasing assurance in the security of the TOE.

One should take into account that there exist standardised life cycle models on the one hand (like the waterfall model) and standardised metrics on the other hand (like error density), which may be com-bined. The CC do not require the life cycle to follow exactly one standard defining both aspects.

6.3.3.3 CC and CEM (13.7.3.3 Action ALC_LCD.32.1E)

ALC_LCD.32.1C

The life-cycle definition documentation shall describe the model used to develop and maintain the TOE, including the details of its arithmetic parameters and/or metrics used to measure the quality of the TOE and/or its development against the model.

ALC_LCD.32-1

The evaluator shall examine the documented description of the life-cycle model used to determine that it covers the development and maintenance process, including the details of its arithmetic para-meters and/or metrics used to measure the TOE development against the model.

para.1490

The description of the life-cycle model should include:

a) information on the life-cycle phases of the TOE and the boundaries between the subsequent pha-ses;

b) information on the procedures, tools and techniques used by the developer (e.g. for design, co-ding, testing, bug-fixing);

c) overall management structure governing the application of the procedures (e.g. an identification and description of the individual responsibilities for each of the procedures required by the develop-ment and maintenance process covered by the life-cycle model);

d) information which parts of the TOE are delivered by subcontractors, if subcontractors are invol-ved;

e) information on the parameters/metrics that are used to measure the TOE development against the model. Metrics standards typically include guides for measuring and producing reliable products and cover the aspects reliability, quality, performance, complexity and cost. For the evaluation all those metrics are of relevance, which are used to increase quality by decreasing the probability of faults and thereby in turn increasing assurance in the security of the TOE.

ALC_LCD.3.2C

The life-cycle definition documentation shall explain how the model is used to develop and main-tain the TOE.

ALC_LCD.3-2

The evaluator shall examine the life-cycle definition documentation to determine that it explains how the model has been applied to the development and maintenance of the TOE.

para. 1491

Whereas the requirements of the Evaluation of sub-activity (ALC_LCD.1) are confined to a descrip-tion of the model used, this component requires the developer to explain how the model has been ap-plied to the TOE under evaluation. This explanation should cover using the life-cycle model for de-velopment and maintenance of the TOE as well as compliance of the model with the configuration management (family ALC_CMC).



ALC_LCD.3.3C

The life-cycle definition documentation shall demonstrate that the life-cycle model used by the de-veloper is compliant with the standardised and measurable life-cycle model.

ALC_LCD.3-3

The evaluator shall examine the life-cycle definition documentation to determine that it demonstra-tes that the life-cycle model used by the developer corresponds to the standardised and measurable model.

para. 1492

The life-cycle definition documentation should relate aspects of the standardised model to the speci-fic development and maintenance procedures in place for the TOE, such that conformance to the standardised model can be easily confirmed by the evaluator. The correspondence evidence may, for example, take the form of a mapping from detailed steps and organisation roles in the standardised model to individual development procedures and roles or personnel from the development environ-ment.

The evaluator should take into account that there exist standardised life cycle models on the one hand (like waterfall model) and standardised metrics on the other hand (like error density), which may be combined. He should not require the life cycle to follow one standard defining both aspects.

para. 1493

The life-cycle definition documentation should describe adaptations of the standardised model to meet specific TOE or organisational requirements.

para. 1494

Through completion of this work unit, the evaluator should gain a clear understanding of how the standardised model has been applied, and that it has been applied correctly.

ALC_LCD.3.4C

The life-cycle definition documentation shall explain why the model was chosen.

ALC_LCD.3-4

The evaluator shall examine the life-cycle definition documentation to determine that it explains why the model was chosen.

para. 1495

The life-cycle definition documentation should provide reasons for adoption of the chosen life-cycle model. Such reasons may include, for example, conformance to an organisational policy or to a secu-rity policy (also in the form of the Security Target), or may be in the form of benefits perceived to be attainable through use of the life-cycle model.

ALC_LCD.32.52C

The life-cycle model shall provide for the necessary control over the development and maintenan-ce of the TOE.

ALC_LCD.32-52

The evaluator shall examine the life-cycle model to determine that use of the procedures, tools and techniques described by the life-cycle model will make the necessary positive contribution to the de-velopment and maintenance of the TOE.



para. 1496

The information provided in the life-cycle model gives the evaluator assurance that the development and maintenance procedures adopted would minimise the likelihood of security flaws. For example, if the life-cycle model described the review process, but did not make provision for recording chan-ges to components, then the evaluator may be less confident that errors will not be introduced into the TOE. The evaluator may gain further assurance by comparing the description of the model against an understanding of the development process gleaned from performing other evaluator ac-tions relating to the TOE development (e.g. those covered under the CM capabilities (ALC_CMC)). Identified deficiencies in the life-cycle model will be of concern if they might reasonably be expec-ted to give rise to the introduction of flaws into the TOE, either accidentally or deliberately.

para. 1497

The CC does not mandate any particular development approach, and each should be judged on merit. For example, spiral, rapid-prototyping and waterfall approaches to design can all be used to produce a quality TOE if applied in a controlled environment.

For the metrics/measures used satisfactory evidence must be provided that shows how the measure will contribute adequately to the minimization of danger. This can be viewed as the main aim for measurement in a CC context. As a consequence, the measures must be selected based on the valid-ity especially with respect to this main aim or subgoals supporting it. In the first place a measure is suitable with respect to the CC if a correlation between the measure and the number of faults to be expected can be stated with a minimum degree of reliability. But also a measure useful for manage-ment purposes as for planning and rescheduling are helpful as badly managed projects are endan-gered to produce bad quality.

It may be possible to use metrics for quality improvement, for which this use is not obvious. For ex-ample a metric to estimate the expected cost of a product development may help for quality, if the developer can show that this is used to provide an adequate budget for development projects and that this helps to avoid quality problems coming from resource shortages.

It is not required that every single step in the life cycle of the TOE is measurable. However the evaluator should see from the description of the measures and procedures that the metrics are appro-priate to control the overall quality of the TOE and to minimize possible security flaws by this.

ALC_LCD.32.63C

The life-cycle output documentation shall provide the results of the measurements of the TOE de-velopment using the standardised and measurable life-cycle model.

ALC_LCD.32-63

The evaluator shall examine the life-cycle output documentation to determine that it provides the re-sults of the measurements of the TOE development using the standardised and measurable life-cycle model.

para. 1498

The results of the measurements and the life-cycle progress of the TOE should be in accordance with the life-cycle model.

The output documentation should not only include numeric values of the metrics but should also document actions taken as a result of the measurements and in accordance with the model. For ex-ample there may be a requirement that a certain design phase needs to be repeated, if some error rates measured during testing are outside of a defined threshold. In this case the documentation should show that such action was taken, if indeed the thresholds were not met.

If the evaluation is conducted in parallel to the development of the TOE it may be possible that qual-ity measurements have not been used in the past. In this case the evaluator should use the documen-



tation of the planned procedures in order to gain confidence that corrective actions are defined if re-sults of quality measurements deviate from some threshold.

6.3.4 Documents

6.3.4.1 Books and texts

There are many textbooks on (software) quality measurement. For this discussion we used the following one by Kan. In addition a study by BSI and DFKI was used.

[1] Kan, S. H., Metrics and models in software quality engineering, Reading, Mass.: Addison Wesley, 1995

[2] Measurable Life-Cycle Models for Common Criteria, Study by BSI and DFKI, 2002

6.3.4.2 Some URLs with related topics

A university laboratory for software management can be found under the following URL: http://www.smlab.de/ .

A well known process improvement method (capability maturity model - CMM) , which uses quality meas-urement, might be a candidate for a quasi-standard for measurable models (however, we should not mention such examples in the CC as long as we did not examine them in more detail): http://www.sei.cmu.edu/cmmi/general/general.html .

6.3.4.3 ISO Standards related to measurement in (software) life cycles

The following ISO standards or technical reports were all developed in the committee ISO/ IEC/ JTC 1/ SC 7 “Software and system engineering”. They are only listed here as a demonstration of the amount of standards existing in this context. We did not examine, which of these standards might be especially useful for a devel-oper to fulfil LCD.2.

ISO/IEC TR 9126-2:2003 Software engineering -- Product quality -- Part 2: External metrics

ISO/IEC TR 9126-3:2003 Software engineering -- Product quality -- Part 3: Internal metrics

ISO/IEC TR 9126-4:2004 Software engineering -- Product quality -- Part 4: Quality in use metrics

ISO/IEC 12207:1995 Information technology -- Software life cycle processes

ISO/IEC 14143-1:1998 Information technology -- Software measurement -- Functional size measurement -- Part 1: Definition of concepts

ISO/IEC AWI 14143-1 Information technology -- Software measurement -- Functional size measurement -- Part 1: Definition of concepts

ISO/IEC 14143-2:2002 Information technology -- Software measurement -- Functional size measurement -- Part 2: Conformity evaluation of software size measurement methods to ISO/IEC 14143-1:1998

ISO/IEC TR 14143-3:2003 Information technology -- Software measurement -- Functional size meas-urement -- Part 3: Verification of functional size measurement methods

ISO/IEC TR 14143-4:2002 Information technology -- Software measurement -- Functional size meas-urement -- Part 4: Reference model

ISO/IEC TR 14143-5:2004 Information technology -- Software measurement -- Functional size meas-urement -- Part 5: Determination of functional domains for use with functional size measurement

ISO/IEC FCD 14143-6 Information technology -- Software measurement -- Functional size measurement -- Part 6: Guide for use of ISO/IEC 14143 series and related international standards

http://www.smlab.de/

http://www.sei.cmu.edu/cmmi/general/general.html



ISO/IEC 14756:1999 Information technology -- Measurement and rating of performance of computer-based software systems

ISO/IEC 15504-1:2004 Information technology -- Process assessment -- Part 1: Concepts and vocabulary

ISO/IEC 15504-2:2003 Information technology -- Process assessment -- Part 2: Performing an assessment

ISO/IEC 15504-3:2004 Information technology -- Process assessment -- Part 3: Guidance on performing an assessment

ISO/IEC 15504-4:2004 Information technology -- Process assessment -- Part 4: Guidance on use for process improvement and process capability determination

ISO/IEC TR 15504-5:1999 Information technology -- Software Process Assessment -- Part 5: An as-sessment model and indicator guidance

ISO/IEC FDIS 15504-5 Information technology -- Process Assessment -- Part 5: An exemplar Process As-sessment Model

ISO/IEC TR 15846:1998 Information technology -- Software life cycle processes -- Configuration Management

ISO/IEC 15939:2002 Software engineering -- Software measurement process

ISO/IEC 19761:2003 Software engineering -- COSMIC-FFP -- A functional size measurement method

ISO/IEC 20926:2003 Software engineering -- IFPUG 4.1 Unadjusted functional size measurement method -- Counting practices manual

ISO/IEC 20968:2002 Software engineering -- Mk II Function Point Analysis -- Counting Practices Manual

ISO/IEC 24570:2005 Software engineering -- NESMA functional size measurement method version 2.1 -- Definitions and counting guidelines for the application of Function Point Analysis

ISO/IEC FCD 25020 Software and System Engineering -- Software quality requirements and evaluation (SQuaRE) -- Quality measurement -- Measurement reference model and guide

ISO/IEC DTR 25021 Software engineering -- Software product Quality Requirements and Evaluation (SQuaRE) -- Quality measure elements

ALC_TAT Transition guide for ALC, ACM, ADO and AGD ALC_TAT.1 (Well-defined development tools) Version 2.0, 22.01.2008


7. ALC_TAT The three components of ALC_TAT and their denotations have been retained, modifications have been per-formed only within the components.

7.1 ALC_TAT.1 (Well-defined development tools) In order to clarify that the ALC_TAT requirements apply to each tool that the developer uses and not to the aggregate set of tools, and that the “documentation of the development tools” does not refer to the TOE de-veloper’s identification/listing (cf. ALC_TAT.*.1D), summary, or description of the tools but to the tool developer/seller’s guidance, the following changes are performed, the phrases „the development tools“ and „all development tools“ are replaced with „each development tool“ through all ALC_TAT requirements.

In order to contribute to the coverage of the element ADV_IMP.1.3C from CC version 2.3 (which has been deleted in version 3.1), the element 2C and its work unit -2 have been supplemented with “… as well as all conventions and directives …”, see section 17.1.1 for more details.

7.2 ALC_TAT.2/3 (Compliance with implementation standards/ – all parts) The difference between TAT.2 and TAT.3 is specified in version 3.1 (by a para in the guidance text of work unit 4) in the way, that TAT.2 regards those parts of the implementation representation of the TSF provided by the TOE developer, whereas TAT.3 regards also the parts provided by third parties. Which parts of the implementation representation are provided by third parties has in version 3.1 to be declared in the configu-ration list (element ALC_CMS.*.3C, see section 8.3.2).

In ALC_TAT.*.3D, „implementation standards to be applied“ is replaced with „implementation standards that are being applied“, since only the latter can be evaluated (2E).

Work units for ALC_TAT.2 have basically been taken from the German national interpretation AIS 34, ver-sion 1.00, 01.06.04, and adapted to the performed modifications. Work units for ALC_TAT.3 have been constructed analogously.

Transition guide for ALC, ACM, ADO and AGD ACM_SCP Version 2.0, 22.01.2008 Strict separation of CM capability and scope


8. ACM_SCP

8.1 Strict separation of CM capability and scope In the previous ACM concept the CM capability family CAP contained also requirements on scope, and vice versa the CM scope family SCP contained also requirements on capability (although the mixture had already been reduced by RI # 4 and RI # 95). The new concept intends to separate these two families in the following way:

• The scope family shall describe a minimum contents of the configuration list (the configuration list de-fines the configuration items that are placed under CM), and shall not impose any requirements regard-ing capability of the CM system.

• The capability family shall describe the minimum capability of the CM system (the CM requirements to be imposed on the items of the configuration list), and shall not make any assumptions regarding scope of the CM system.

This separation increases

• clarity (and, as a result, less effort for developers and evaluators and a higher degree of transparency for interested parties),

• flexibility, since the requirements on capability and on scope may be chosen independently of each other.

The new families are named ALC_CMS (“CM scope”) and ALC_CMC (“CM capability”).

The dependencies of ACM_CAP.* on ACM_SCP.1 and of ACM_SCP.* on ACM_CAP.3 are not mapped to dependencies between classes of ALC_CMC.* and ALC_CMS.*.

The previous ACM_CAP level 2 was a mixture of requirements concerning CM capability (namely use of a CM system) and requirements concerning scope (namely “the components that comprise the TOE”). In line with the aimed separation, the implicit scope requirement in CAP.2 is realised in the new structure by an additional scope component (“Parts of TOE CM coverage”), and in CMC the requirements are restated more abstractly saying “the configuration items” instead of “the components that comprise the TOE”. Further, a very first scope component is added which requires the configuration list solely to include the TOE and the evaluation evidence. This brings about that the numbers of the old scope components are increased by two.

8.2 Components

ACM_SCP components Corresponding new ALC_CMS components

ALC_CMS.1 CM coverage of the TOE and the evaluation evi-dence.

ALC_CMS.2 CM coverage of the parts of the TOE ACM_SCP.1

TOE CM coverage (implementation rep-resentation and evaluation evidence)

ALC_CMS.3 Implementation representation CM coverage

ACM_SCP.2 Problem tracking CM coverage

ALC_CMS.4 Problem tracking CM coverage

ACM_SCP.3 Development tools CM coverage

ALC_CMS.5 Development tools CM coverage

Table 7: CM Scope: Correspondence of components

ACM_SCP Transition guide for ALC, ACM, ADO and AGD Elements Version 2.0, 22.01.2008


8.3 Elements

8.3.1 Overview

CC/CEM version 2.3 CC/CEM version 3.1: ALC_CMS Components EAL Elements Elements EAL Components

1: Version numbers 1 1C: TOE is uniquely

referenced 1.1C: TOE, evalu-

tion evidence

2.3C: CM list exists

1D: CM list exists 1

1: TOE CM coverage

4C: CM list uniquely identifies CIs

that comprise the TOE AC

M_C

AP

2: Configuration items 2

5C: CM list describes CIs that comprise the TOE

2.1C: Parts that comprise the TOE 2

2: Parts of the TOE CM coverage

1: TOE CM coverage 3

1.1C: Implementation representation,

evaluation evidence

3.1C: Implementa-tion representation 3

3: Implem. repres.CM coverage

2: Problem tracking

CM coverage 4 2.1C: Security flaws 4.1C: Security flaws 4 4: Problem tracking

CM coverage

AC

M_S

CP

3: Development tools

CM coverage 5 3.1C: Development tools

and related information

2C: C

M li

st u

niqu

ely

iden

tifie

s the

CIs

3C: C

M li

st in

dica

tes d

evel

oper

of e

ach

CI

5.1C: Development tools and related

information 5

5: Development tools CM coverage

Table 8: CM Scope: Correspondence of elements

Transition guide for ALC, ACM, ADO and AGD ACM_SCP Version 2.0, 22.01.2008 Elements


8.3.2 Wording and numbering of the new ALC_CMS elements # at each Comp. Level The new ALC_CMS elements

1 2 3 4 5 Origin in ACM

The developer shall provide a configuration list for the TOE.

1.1D 2.1D 3.1D 4.1D 5.1D SCP.*.1D

The configuration list shall include the following: The TOE; and the evaluation evidence required by the assurance components in the ST.

1.1C Basic assumption in the previous criteria (cf. the first application note for

The configuration list shall include the following: The TOE; the evaluation evidence required by the SARs; and the parts that comprise the TOE.

2.1C SCP.1.1C CAP.2.4C

The configuration list shall include the following: The TOE; the evaluation evidence required by the SARs.; the parts that comprise the TOE; and the implemen-tation representation.

3.1C SCP.1.1C

The configuration list shall include the following: The TOE; the evaluation evidence required by the SARs; the parts that comprise the TOE; the implementation representation; and security flaw reports and resolu-

4.1C SCP.2.1C

The configuration list shall include the following: The TOE; the evaluation evidence required by the SARs; the parts that comprise the TOE; the implementation representation; security flaw reports; and develop-ment tools and related information.

5.1C SCP.3.1C

The configuration list shall uniquely identify the configura-tion items.

1.2C 2.2C 3.2C 4.2C 5.2C CAP.*.4C

For each TSF relevant configuration item, the configuration list shall indicate the developer of the item.

2.3C 3.3C 4.3C 5.3C The evaluator needs this information with respect to the imple-mentation represent-tation when dealing with work unit ALC_TAT.2-4.

The evaluator shall confirm that the information provided meets all requirements for content and presentation of evi-dence.

1.1E 2.1E 3.1E 4.1E 4.1E SCP.*.1E

Table 9: CM Scope: The new elements

8.3.3 Verification that the ACM_SCP elements are covered in the new structure ACM_SCP elements Coverage by elements of ALC_CMS

ACM_SCP.*.1D ALC_CMS.*.1D (same wording) ACM_SCP.1.1C ACM_SCP.2.1C ACM_SCP.3.1C

ALC_CMS.3.1C ALC_CMS.4.1C ALC_CMS.5.1C

(same wording plus supplementation; “security flaws” is replaced with “security flaw reports”)

ACM_SCP.*.1E ALC_CMS.*.1E (same wording) Table 10: CM Scope: Coverage of elements

ACM_SCP Transition guide for ALC, ACM, ADO and AGD Work units Version 2.0, 22.01.2008


8.4 Work units The following Table 11 defines the new organisation of the scope work units.

The work unit 5-1 has the following wording (for the lower work units *-1, the unconcerned items are omit-ted):

“The evaluator shall check that the configuration list includes the following set of items:

1. the TOE itself;

2. the parts that comprise the TOE (the top-level hardware and software components);

3. the TOE implementation representation;

4. the evaluation evidence required by the SARs;

5. the documentation used to record details of reported security flaws associated with the implemen-tation (e.g., problem status reports derived from a developer’s problem database):

6. all tools (incl. test software, if applicable) involved in the development and production of the TOE including the names, versions, configurations and roles of each development tool, and related infor-mation. E. g. for a software TOE: ‘development tools’ are usually programming languages and com-piler, and ‘related information’ comprises compiler and linker options. For a hardware TOE, ‘devel-opment tools’ might be hardware design languages, simulation and synthesis tools, compilers, and ‘related documentation’ might again comprise compiler options.”

The work units *-2 have the following wording:

“The evaluator shall examine that the configuration list uniquely identifies each configuration item.”

The work units *-3 have the following wording:

“The evaluator shall check that the configuration list indicates the developer of each TSF relevant configuration item.”

CC/CEM version 2.3

ACM_SCP

CC/CEM version 3.1

ALC_CMS

Corresponding work units Corresponding work units

EAL1 EAL 2 EAL 3 EAL 4 EAL 1 EAL 2 EAL 3 EAL 4Element

--- --- SCP.1 SCP.2

Element

CMS.1 CMS.2 CMS.3 CMS.4 1.1C 1-1

2.1C 2-1

1.1C 1-1 3.1C 3-1

2.1C 2-1 4.1C 4-1

3.1C 5.1C

CAP.*.4C CAP.2-5 CAP.3-6 CAP.4-7

CAP.*.5C CAP.2-6 CAP.3-7 CAP.4-8 *.2C 1-2 2-2 3-2 4-2

*.3C 2-3 3-3 4-3

Table 11: CM Scope: Correspondence of elements and work units

Transition guide for ALC, ACM, ADO and AGD ACM_CAP Version 2.0, 22.01.2008 Basic considerations


9. ACM_CAP

9.1 Basic considerations RI #99 addresses the issue that ACM_CAP.2 elements are unclear if no CM scope components are included in the PP/ST. Since the TOE and the evaluation evidence have to be maintained by CM anyway, the issue is solved in the new structure by introducing a dependency of the second capability component on a new first scope component requiring the TOE and the evaluation evidence to be covered by CM.

In the previous criteria, the second CM capability component introduced CM coverage of the configuration items that comprise the TOE. This aspect of ACM_CAP.2 is seen here as a matter of CM scope and hence transferred in a new scope component “CM coverage of the parts of the TOE” (cf. chapter 8.1). As a conse-quence, some elements of ACM_CAP can be removed, since they are covered by scope requirements (namely .1C requiring the uniqueness of the TOE reference, and .4C, and the element introduced by RI #3 making requirements for the configuration list). The remainder of the second capability component is re-named here as “Use of a CM system”.

In the new criteria, a dependency from ALC_CMC.3 on ALC_LCD.1 is introduced. This has become possi-ble, since ALC_LCD.1 has been shifted from EAL 4 down to EAL 3 (see ch. 6).

9.2 Components

ACM_CAP components Corresponding new ALC_CMC and ALC_CMS compo-nents

ALC_CMC.1 Labelling of the TOE ACM_CAP.1 Version numbers

ALC_CMS.1 CM coverage of the TOE

ALC_CMC.2 Use of a CM system ACM_CAP.2 Configuration items

ALC_CMS.2 CM coverage of the parts of the TOE

ALC_CMC.3 Authorisation controls ACM_CAP.3 Authorisation controls


ALC_CMC.4 Generation support and acceptance proce-dures

ACM_CAP.4 Generation support and acceptance procedures


ALC_CMC.5 Advanced support ACM_CAP.5 Advanced support


Table 12: CM Capability: Correspondence of components

ACM_CAP Transition guide for ALC, ACM, ADO and AGD Elements Version 2.0, 22.01.2008


9.3 Elements

9.3.1 Preliminary remarks Usage of “development” and related terms: These terms “development”, “developer”, “develop” are used throughout the CMC requirements and work units in the more general sense to comprise development and production.

Numbering of the (new) ALC_CMC elements: In the new structure, the CMC elements are ordered by subject. As a consequence, the number of an element depends on the component level. For the identification of an element, element number and component number have to be indicated.

An overview of the new CMC elements and their numbers at each level is given in chapter 0 below.

9.3.2 Overview

CC/CEM version 2.3: ACM_CAP CC/CEM version 3.1: ALC_CMC Components EAL Elements Elements EAL Components

1: Version numbers 1 2C: TOE is labelled with its

reference 1.1C: TOE is labelled with its

unique reference 1 1: Labelling of the TOE

6C: Description of unique iden-tification method

2.2C: Description of unique identification method 2: Configura-

tion items 2 7C: CM sytem uniquely

identifies the CIs 2.3C: CM sytem uniquely

identifies the CIs

2 2: Use of a CM system

11C: CM system allows only authorised changes to CIs

3.4C: CM system allows only authorised changes to CIs

3.3C: CM plan exists 3.5C: CM plan exists

8C: CM plan describes use of the CM system

3.6C: CM plan describes use of the CM system

10C: Evidence => CM system maintains effectively the CIs

3. 7C: Evidence => CM system maintains effectively the CIs

3: Authorisa-tion Controls 3

9C: Evidence => CM system operates according to CM plan

3.8C: Evidence => CM system operates according to CM plan

3 3: Authorisation Controls

12C: CM system supports gen-eration of the TOE

4.5C: CM system supports production of the TOE by automated means

4: Generation support and acceptance procedures

4 13C: Acceptance plan describes

acceptance procedures 4.8C: CM plan describes acceptance procedures

4

4: Production support and acceptance procedures

Table 13: CM Capability: Correspondence of elements (levels 1 to 4)

Transition guide for ALC, ACM, ADO and AGD ACM_CAP Version 2.0, 22.01.2008 Elements


CC/CEM version 2.3: ACM_CAP.5 CC/CEM version 3.1: ALC_CMC.5 EAL Elements Elements EAL

15C: CM system requires: Acceptor ≠ developer of a CI

5.7C: CM system requires: Acceptor ≠ developer of a CI

16C: CM system identifies TSF-CIs 5.8C: CM system identifies TSF-CIs 17C: CM system supports audit of all modifica-

tions to the TOE 5.9C: CM system supports audit of all

changes to the TOE 18C: CM system identifies master copy of all

generation material 5.11C: CM system identifies master copy of all

production material 14C: Integration procedures describe use of CM

system in the TOE manufacturing (covered by the combination of 5.6C and 5.13C)

The CM doc. demonstrates/justifies that the use of ensures that

19C: CM system & DVS

only authorised changes to TOE can be made (covered by the combination of 5.5C and 5.15C)

20C: integration procedures

generation of TOE is correctly performed in auth. manner

(covered by the combination of 5.6C, 5.13C and 5.16C)

21C: CM system Acceptor ≠ developer of a CI (covered by the combination of 5.7C and 5.15C)

6

22C: acceptance procedures

changes to CIs are appropri-ately reviewed 5.3C: CM plan changes to CIs are appropri-

ately reviewed

6

Table 14: CM Capability: Correspondence of elements (level 5)

9.3.3 Wording and numbering of the new ALC_CMC elements

# at each Component Level The new ALC_CMC elements 1 2 3 4 5

Origin in ACM

General requirements The developer shall provide the TOE and a reference for the TOE.

1.1D 2.1D 3.1D 4.1D 5.1D CAP.*.1D

The developer shall provide CM documentation. --- 2.2D 3.2D 4.2D 5.2D CAP.*.2DThe developer shall use a CM system. --- 2.3D 3.3D 4.3D 5.3D CAP.*.3DThe TOE shall be labelled with its unique reference. 1.1C 2.1C 3.1C 4.1C 5.1C CAP.*.2CThe CM documentation shall describe the method used to uniquely identify the configuration items that comprise the TOE.

--- 2.2C 3.2C 4.2C 5.2C CAP.*.6C

The CM documentation shall justify that the acceptance proce-dures provide for an adequate and appropriate review of changes to all configuration items.

--- --- --- --- 5.3C CAP.5.22C

The evaluator shall confirm that the information provided meets all requirements for content and presentation of evi- 1.1E 2.1E 3.1E 4.1E 5.1E CAP.*.1E

The evaluator shall determine that the application of the pro-duction support procedures results in a TOE as provided by the developer for testing activities.

--- --- --- --- 5.2E

ADO_ IGS.1.2E

(developer’s part)

Requirements on the CM system

ACM_CAP Transition guide for ALC, ACM, ADO and AGD Elements Version 2.0, 22.01.2008


# at each Component Level The new ALC_CMC elements 1 2 3 4 5

Origin in ACM

The CM system shall uniquely identify all configuration items that comprise the TOE.

--- 2.3C 3.3C 4.3C 5.4C CAP.*.7C

The CM system shall provide measures such that only author-ised changes are made to the configuration items.

--- --- 3.4C CAP.3.11C

The CM system shall provide automated measures such that only authorised changes are made to the configuration items.

4.4C 5.5C CAP.*.11C AUT 1.1C

The CM system shall support the production of the TOE by automated means. --- --- --- 4.5C 5.6C CAP.*.12C

AUT 1.2C

The CM system shall require that the person responsible for accepting a configuration item is not the person who developed it.

--- --- --- --- 5.7C CAP.5.15C

The CM system shall clearly identify the configuration items that comprise the TSF.

--- --- --- --- 5.8C CAP.5.16C

The CM system shall support the audit of all changes to the TOE, including as a minimum the originator, date, and time in the audit trail, by automated means.

--- --- --- --- 5.9C CAP.5.17C AUT 2.5C

The CM system shall provide an automated means to identify all other configuration items that are affected by the change of a given configuration item.

--- --- --- --- 5.10C AUT.2.6C

The CM system shall be able to identify the version of the im-plementation representation from which the TOE is generated. --- --- --- --- 5.11

C CAP.5.18C

Requirements on the CM plan The CM documentation shall include a CM plan. --- --- 3.5C 4.6C 5.12 CAP.*.3CThe CM plan shall describe how the CM system is used for the development of the TOE. --- --- 3.6C 4.7C 5.13

C CAP.*.8C

The CM plan shall describe the procedures used to accept modified or newly created configuration items as part of the TOE.

--- --- --- 4.8C 5.14C CAP.*.13C

Requirements on the evidence The evidence shall demonstrate that all configuration items are being maintained under the CM system. --- --- 3.

7C 4. 9C

5.15C CAP.*.10C

The evidence shall demonstrate that the CM system is being operated in accordance with the CM plan. --- --- 3.

8C 4.10

C 5.16

C CAP.*.9C

Table 15: CM Capability: The new elements

Transition guide for ALC, ACM, ADO and AGD ACM_CAP Version 2.0, 22.01.2008 Elements


9.3.4 Verification that the ACM_CAP elements are covered in the new structure ACM_CAP elements Verification of coverage by elements of ALC_CMC and ALC_CMS

ACM_CAP.*.1D ”The developer shall provide a reference for the TOE.”

ALC_CMC.1.1D: “The developer shall provide the TOE and a reference for the TOE.”

ACM_CAP.*.1C ”The reference for the TOE shall be unique to each ver-sion of the TOE.”

ALC_CMC.* has a dependency on ALC_CMS.1.

ALC_CMS.1.1D: “The developer shall provide a configuration list for the TOE.”

ALC_CMS.1.1C: “The configuration list shall include the following: The TOE.”

ALC_CMS.1.2C: “The configuration list shall uniquely identify the configuration items.”

ACM_CAP.*.2D ALC_CMC.*.2D (same wording) ACM_CAP.2.3D ACM_CAP.2.3C

ALC_CMS.1.1D (ALC_CMC.2 has a dependency on ALC_CMS.1).

ACM_CAP.*.3D (CAP.3 and above)

ALC_CMC.*.3D (same wording)

ACM_CAP.*.2C ALC_CMC.*.1C (same wording, “unique” added) ACM_CAP.*.3C (CAP.3 and above)

ALC_CMC.3.5C and ALC_CMS.1.1D (ALC_CMC.* has a dependency on ALC_CMS.1).

ACM_CAP.*.4C ”The configuration list shall uniquely identify all configu-ration items that comprise the TOE.”

ACM_CAP.*.5C ”The configuration list shall describe the configuration items that comprise the TOE.”

ACM_CAP.*.5C appears at the level CAP.2. CAP.2 is covered by CMC:2 in con-junction with ALC_CMS.2.

ALC_CMS.2.2C: “The configuration list shall uniquely identify the configuration items.”

ALC_CMS.2.1.C: “The configuration list shall include the following: ...; the parts of the TOE.”

Justification of EAL compatibility: CAP.2, CMC.2, CMS.2 all appear at the level EAL 2.

Justification of coverage: By ALC_CMS.2.2C, the configuration list uniquely identifies its configuration items, which is stronger than describing the configura-tion items. By ALC_CMS.2.1C, the configuration list contains the parts of the TOE, i.e. the configuration items that comprise the TOE.

ACM_CAP.*.6C ALC_CMC.*.2C (same wording as in CC v2.2; the CC v2.3 addition “… that comprise the TOE” has not been adopted in CC v3.1)

ACM_CAP.*.7C ALC_CMC.2.3C (same wording as in CC v2.2; the CC v2.3 addition “… that comprise the TOE” has not been adopted in CC v3.1)

ACM_CAP.*.8C ALC_CMC.3.6C (same wording) ACM_CAP.*.9C ALC_CMC.3.8C: “The evidence shall demonstrate that the CM system is operat-

ing in accordance with the CM plan.”

ACM_CAP.*.10C ALC_CMC.3.7C: “The evidence shall demonstrate that all configuration items are being maintained by the CM system.”

ACM_CAP.*.11C ALC_CMC.3.4C (same wording)

ACM_CAP.4.12C ALC_CMC.4.5C: “The CM system shall support the production of the TOE.” ACM_CAP.4.13C ALC_CMC.4.8C: “The CM plan shall describe the procedures used to accept

modified or newly created configuration items as part of the TOE.”

ACM_CAP Transition guide for ALC, ACM, ADO and AGD Work units Version 2.0, 22.01.2008


ACM_CAP elements Verification of coverage by elements of ALC_CMC and ALC_CMS

ACM_CAP.5.14C: “The integration pro-cedures shall describe how the CM system is applied in the TOE manu-facturing process.”

ALC_CMC.5.6C: “The CM system shall support the production of the TOE.” (Manufacturing is part of the production.)

ALC_CMC.5.13C: “The CM plan shall describe how the CM system is used for the development of the TOE.” (Integration procedures become part of the CM plan.)

ACM_CAP.5.15C ALC_CMC.5.7C (same wording) ACM_CAP.5.16C ALC_CMC.5.9C (same wording) ACM_CAP.5.17C ALC_CMC.5.8C (same wording) ACM_CAP.5.18C: “The CM system shall be able to identify the version of the imple-mentation representa-tion from which the TOE is generated.”

ALC_CMC.5.11C: “The CM system shall be able to identify the master copy of all material used to produce the TOE.”

(The implementation representation specifies the parts and source code files used to generate the TOE.)

ACM_CAP.5.19C: “The CM documentation shall demonstrate that the use of the CM system, together with the DVS measures, allow only authorised changes to be made to the TOE.”

ALC_CMC.5.5C: “The CM system shall provide automated measures that only authorised changes are made to the configuration items.”

ALC_CMC.5.15C: “The evidence shall demonstrate that all configuration items are being maintained by the CM system.”

ACM_CAP.5.20C: “The CM documentation shall demonstrate that the use of the integration procedures ensures that the generation of the TOE is correctly per-formed in an authorised man-ner.”

ALC_CMC.5.13C: “The CM plan shall describe how the CM system is used for the development of the TOE.” (Integration procedures become part of the CM plan.)

ALC_CMC.5.6C: “The CM system shall support the production of the TOE.” (Manufacturing is part of the production.)

ALC_CMC.5.16C: “The evidence shall demonstrate that the CM system is being operated in accordance with the CM plan.”

ACM_CAP.5.21C: “The CM documentation shall demonstrate that the person responsible for accepting a configuration item into CM is not the person who developed it.”

ALC_CMC.5.7C: “The CM system shall require that the person responsible for accepting a configuration item is not the person who developed it.”

ALC_CMC.5.15C: “The evidence shall demonstrate that all configuration items are being maintained by the CM system.”

ACM_CAP.5.22C ALC_CMC.5.3C (same wording) ACM_CAP.*.1E ALC_CMC.*.1E (same wording)

Table 16: CM Capability: Coverage of elements

9.4 Work units The following Table 17 defines the new organisation of the capability work units:

• The left-hand side of the table shows the previous situation. The first column contains the elements, the next four columns the corresponding work units at the four EA levels. They are covered in the new ver-sion by the elements resp. work units that are indicated in the right-hand side of the table in the same row.

• In an analogous manner, the right-hand side of the table shows the situation in the new concept.

Transition guide for ALC, ACM, ADO and AGD ACM_CAP Version 2.0, 22.01.2008 Work units


• The elements/work units of the new concept essentially form a subset of the elements/work units de-fined in the previous version; some formulations have been slightly changed. The ordering of the new elements may be seen from the table.

CC/CEM version 2.3

ACM_CAP

Coverage in CC/CEM version 3.1

ALC_CMC

Corresponding work units Corresponding elements/work units

EAL 1 EAL 2 EAL 3 EAL 4 EAL 1 EAL 2 EAL 3 EAL 4 Ele-

ment CAP.1 CAP.2 CAP.3 CAP.4 CMC.1 CMC.2 CMC.3 CMC.4

1C 1-1 2-1 3-1 4-1 CMS CMS CMS CMS 1-2 2-2 3-2 4-2 1.1C / 1-1 2.1C / 2-1 3.1C / 3-1 4.1C / 4-1 2C 1-3 2-3 3-3 4-3 1.1C / 1-2 2.1C / 2-2 3.1C / 3-2 4.1C / 4-2

2-4 3-4 4-4 CMS.*.1D CMS.*.1D CMS.*.1D

3-5 4-53Cx 4-6

3.5C / 3-6 4.6C / 4-8

4C 2-5 3-6 4-7

5C 2-6 3-7 4-8 CMS.*.2C

/ CMS.*-2 CMS.*.2C / CMS.*-2

CMS.*.2C / CMS.*-2

6C 2-7 3-8 4-9 2.2C / 2-3 3.2C / 3-3 4.2C / 4-3

7C 2-8 3-9 4-10 2.3C / 2-4 3.3C / 3-4 4.3C / 4-4

8C 3-10 4-11 3.6C / 3-7 4.7C / 4-9

3-11 4-12 3.8C / 3-9 4.10C / 4-129C 3-12 4-13 3.8C / 3-10 4.10C / 4-13

10C 3-13 4-14 3.7C / 3-8 4.9C / 4-11

11C 3-14 4-15 3.4C / 3-5 4.4C / 4-5

4-16 4.5C / 4-612C 4-17 4.5C / 4-7

13C 4-18 4.8C / 4-10

Table 17: CM Capability: Correspondence of elements and work units

Annotations: x: The content of the element depends on the component level.

CMS The coverage is realised by elements resp. work units of ALC_CMS.

Verification of coverage

Formally, the reorganisation leads to a strengthening of the requirements at EAL 1, since the new EAL 1 requires a CM list. However, at EAL 1 this list needs to contain solely the TOE itself and the evaluation evi-dence (ALC_CMS.1.1C), and the unique identification of the TOE is required by the actual EAL 1 level too (ALC_CAP.1.1C).

The CAP elements.1D, .1C and the first CAP work unit are considered to be covered by the ALC_CMS elements/work units (note, that ACM_CMC.1 has a dependency on ALC_CMS.1). These require already at the lowest level that a configuration list exists which includes the TOE as item. This implies that the TOE has a reference, and that this reference is unique to each version of the TOE.

ACM_AUT Transition guide for ALC, ACM, ADO and AGD Merging of CM capability and automation Version 2.0, 22.01.2008


10. ACM_AUT

10.1 Merging of CM capability and automation Since “automation” is a special form of capability of the CM system, the family ACM_AUT is integrated into the new CM capability family ALC_CMC.

ACM_AUT consists of the two components AUT.1 (“Partial CM automation”) and AUT.2 (“Complete CM automation”). The denotations of these components already suggest, that they don’t only introduce require-ments on automated CM measures, but also on the scope of the concerned configuration items. Concretely, AUT.1 refers to the TOE implementation representation, and AUT.2 to all configuration items.

The new concept tends towards shifting all scope requirements into the scope family CMS, and to refer in CMC generally to the configuration items (as is done in AUT.2). For AUT.1 (EAL 4), this means an exten-sion of the requirement 1C for automatic change control to all configuration items. But since change control for all configuration items is required for the CM system by CAP.3.11C (EAL 3) anyway, it is sensible and done in the new structure to merge these two requirements to one new capability requirement in CMC.4 (EAL 4).

AUT.1 deals further with automatic support of the generation of the TOE (requirement 2C). Since generation support as CM capability appears at EAL 4 (CAP.4.12C), these two requirements are also merged to one new capability requirement in CMC.4. AUT.2 deals additionally with the automation of the control of changes between versions of the TOE. An element related to AUT.2.5C is CAP.5.16C, so AUT.2 is integrated into CMC.5, and the element is extended by an automation requirement. AUT.2.6C is introduced as new CMC.5 element.

The integrations of AUT.1 and AUT.2 into CMC.4 resp. CMC.5 correspond to the EAL structure and fulfil the dependency of AUT.1 upon CAP.3. The implied changes to the CMC families are not very large and are discussed in more detail in section 0. However, there is a little loss of flexibility, since high requirements regarding capability then always include automation requirements.

10.2 Components

ACM_AUT components Corresponding new ALC_CMC components

ACM_AUT.1 Partial CM automation Integrated into ALC_CMC.4

Generation support and acceptance proce-dures

ACM_AUT.2 Complete CM automation Integrated into ALC_CMC.5

Advanced support

Table 18: CM Automation: Mapping of components

Transition guide for ALC, ACM, ADO and AGD ACM_AUT Version 2.0, 22.01.2008 Elements


10.3 Elements

10.3.1 Overview CC/CEM version 2.3: ACM_AUT CC/CEM version 3.1: ALC_CMC

EAL Elements Elements EAL

*.1C: CM system allows only authorised changes to TOE implementation representation by automated means

4.4C: CM system allows only authorised changes to CIs by automated means

*.2C: CM system supports generation of the TOE by automated means

4.5C: CM system supports production of the TOE by automated means

*.3C: CM plan describes automated CM tools

4

*.4C: CM plan describes use of automated CM tools

4.6C: CM plan exists 4.7C: CM plan describes use of the CM

system

4

2.5C: CM system provides automated means to ascertain changes between TOE and preceding versions

5.9C: CM system supports audit of all changes to the TOE by automated means

6 2.6C: CM system provides automated means to identify

all CIs affected by the change of a CI

5.10C: CM system provides an automated means to identify all CIs affected by the

change of a CI

6

Table 19: CM Automation: Mapping of elements

10.3.2 Verification that the ACM_AUT elements are covered in the new structure ACM_AUT.1 elements (in CC version 2.3)

Verification of coverage by elements of ALC_CMC.4 (in CC version 3.1)

ACM_AUT.1.1D ”The developer shall use a CM system.”

ALC_CMC.4.2D (same wording)

ACM_AUT.1.2D ”The developer shall provide a CM plan.”

ALC_CMC.4.3D: “The developer shall provide CM documentation.” ALC_CMC.4.6C: “The CM documentation shall include a CM plan.”

ACM_AUT.1.1C ”The CM system shall provide an automated means by which only authorised changes are made to the TOE implementa-tion representation.”

ALC_CMC.4.4C: ”The CM system shall provide automated measures such that only authorised changes are made to the configuration items.”

Justification of EAL compatibility: ACM_AUT.1 is required at assurance level EAL 4. The implementation representation is required to be included in the configu-ration list by the scope component ALC_CMS.3, i.e. already at EAL 3.

ACM_AUT.1.2C ”The CM system shall provide an automated means to sup-port the generation of the TOE.”

ALC_CMC.4.5C (same wording, only “generation” is replaced by “production”).

ACM_AUT.1.3C ”The CM plan shall describe the automated tools used in the CM system.”

ALC_CMC.4.6C: “The CM documentation shall include a CM plan.” ALC_CMC.4.7C: “The CM plan shall describe how the CM system is used in the development of the TOE.”

ACM_AUT Transition guide for ALC, ACM, ADO and AGD Work units Version 2.0, 22.01.2008


ACM_AUT.1 elements (in CC version 2.3)

Verification of coverage by elements of ALC_CMC.4 (in CC version 3.1)

ACM_AUT.1.4C ”The CM plan shall describe how the automated tools are used in the CM system.”

ACM_AUT.2 Verification of coverage by elements of ALC_CMC.5 ACM_AUT.2.5C ”The CM system shall provide an automated means to ascer-tain the changes between the TOE and its preceding ver-sions.”

ALC_CMC.5.9C: “The CM system shall provide an automated means to support the audit of all modifications to the TOE, including as a minimum the origi-nator, date, and time in the audit trail.”

ACM_AUT.2.6C ”The CM system shall provide an automated means to iden-tify all other configuration items that are affected by the modification of a given con-figuration item.”

ALC_CMC.5.10C (same wording).

Table 20: CM Automation: Coverage of elements

10.4 Work units The following Table 21 shows how the work units of ACM_AUT.1 are covered by work units of ALC_CMC.4 in the new concept. The work units of ALC_CMC.4 are defined to be the work units of ACM_CAP.4 indicated in the same row and supplemented by the word “automated” where applicable. Then the coverage is quite straightforward.

Work unit in ACM_AUT.1

(CEM version 2.3)

Covered by work unit in ALC_CMC.4

(CEM version 3.1)

Corresponding work unitin ACM_CAP.4

(CEM version 2.3)

1-1: redundant (covered by 1-5) --- ---

1-2 4-5 4-15 1-3 4-6 4-16 1-4 4-7 4-17 1-5 1-6

4-9 4-11

1-7 4-13 4-13 Table 21: CM Automation: Mapping of work units

Transition guide for ALC, ACM, ADO and AGD AGD Version 2.0, 22.01.2008 Basic considerations


11. AGD

11.1 Basic considerations The previous AGD consisted of the families AGD_ADM and AGD_USR. Since many of the elements and work units between these two families were similar, merely addressed different types of users, these two families are merged into a single family in the new concept. Since this family assembles all requirements concerning the use of the TOE in its operational state, it is denoted as AGD_OPE (“Operation”).

The different types of users are dealt with by introducing a role concept. In most of the evaluations, the two roles “end user” and “administrative user” will occur. These might be specified further, if appropriate.

In the previous criteria, AGD apparently was related to the operational phase of the TOE, and ADO_IGS to the preparative procedures. Thus the dependency of ADO_IGS.1 on AGD_ADM.1 was not quite clear. It is conceivable that a TOE needs instruction for installation but not for the maintenance in the end-usage phase. Thus in the new concept, there is no dependency of AGD_OPE (guidance for the operational phase) on AGD_PRE (preparative phase).

11.2 Components

AGD_ADM and AGD_USR components Corresponding new AGD components

AGD_ADM.1 Administrator guidance

AGD_USR.1 User guidance AGD_OPE.1 Operational user guidance

Table 22: Guidance Documents: Mapping of components

11.3 Elements In order to come to formulations of OPE elements that cover the ADM and USR elements, first correspond-ing ADM and USR elements have been associated. Then OPE elements have been formulated that cover these associated ADM and USR elements (resp. only an ADM element, if there is no corresponding USR element). These OPE elements do no longer refer specifically to either administrators or users, but are in-stead provided with a statement that all user roles are concerned, such that the ADM elements are covered too.

Impact on the wording of the new OPE elements comes also from changes in ASE in the new structure: Firstly, requirements shall no longer refer to assumptions, but instead to security objectives in the ST. Sec-ondly, the IT and non-IT environment shall no longer be distinguished.

The elements and work units concerning consistency can be omitted in OPE since there is a superordinate consistency requirement in the new structure (CEM, §56a)3)).

AGD Transition guide for ALC, ACM, ADO and AGD Elements Version 2.0, 22.01.2008


The concrete mapping on element level is described in the following figure and table. The table gives addi-tionally the wording of the new elements.

ADM1C

1E

7C

5C

8C

4C

2C

OPE

7C

1E

5C

4C

3C

2C

6C

3C

6C

1C

GeneralConsistency

USR1C

1E

5C

4C

2C

6C

3C

Figure 3: Guidance Documents: Mapping of elements

Note that OPE.1.5C and OPE.1.7C which are not target of any arrow in this figure come from AVA_MSU, cf. chapter 12.

AGD_ADM and AGD_USR elements Coverage by elements of AGD_OPE

AGD_ADM.1.1D ”The developer shall provide administrative guidance addressed to system administrative personnel.”

AGD_USR.1.1D ”The developer shall provide user guidance.”

AGD_OPE.1.1D ”The developer shall provide operational user guidance.”

Transition guide for ALC, ACM, ADO and AGD AGD Version 2.0, 22.01.2008 Elements



AGD_ADM.1.3C ”The administrator guidance shall contain warnings about functions and privileges that should be controlled in a secure processing envi-ronment.”

AGD_USR.1.3C ”The user guidance shall contain warnings about user-accessible func-tions and privileges that should be controlled in a secure processing environment.”

AGD_OPE.1.1C “The operational user guidance shall describe, for each user role, the user-accessible functions and privileges that should be controlled in a secure processing environment, including ap-propriate warnings.”

AGD_USR.1.2C ”The user guidance shall describe the use of user-accessible security functions provided by the TOE.”

AGD_ADM.1.2C ”The administrator guidance shall describe how to administer the TOE in a secure manner.”

AGD_OPE.1.2C “The operational user guidance shall describe, for each user role, how to use the available inter-faces provided by the TOE in a secure manner.”

AGD_USR.1.4C ”The user guidance shall clearly present all user responsibilities neces-sary for secure operation of the TOE, including those related to assumptions regarding user behaviour found in the statement of TOE security environment.”

AGD_ADM.1.4C ”The administrator guidance shall describe all assumptions regarding user behaviour that are relevant to secure operation of the TOE.”

AGD_USR.1.6C ”The user guidance shall describe all security requirements for the IT environment that are relevant to the user.”

AGD_ADM.1.8C ”The administrator guidance shall describe all security requirements for the IT environment that are relevant to the administrator.”

AGD_OPE.1.6C “The operational user guidance shall describe, for each user role, the security measures to be followed in order to fulfil the security objectives for the operational environment as described in the ST.” Note: In the new structure, the requirements shall no longer refer to assumptions, but to the security objec-tives provided by the ST. - The distinction between IT and non-IT environment shall not be continued.

AGD_ADM.1.1C ”The administrator guidance shall describe the administrative functions and interfaces available to the administrator of the TOE.”

AGD_USR.1.1C ”The user guidance shall describe the functions and interfaces available to the non-administrative users of the TOE.”

AGD_ADM.1.5C ”The administrator guidance shall describe all security parameters under the control of the administrator, indicating secure values as appropriate.”

AGD_OPE.1.3C “The operational user guidance shall describe, for each user role, the available functions and interfaces, in particular all security parameters under the control of the user, indicating secure values as appropriate.”

AGD Transition guide for ALC, ACM, ADO and AGD Work units Version 2.0, 22.01.2008



AGD_ADM.1.6C ”The administrator guidance shall describe each type of security-relevant event relative to the administrative functions that need to be performed, including changing the security characteristics of entities under the control of the TSF.

AGD_OPE.1.4C “The operational user guidance shall, for each user role, clearly present each type of security-relevant event relative to the user-accessible functions that need to be performed, including changing the security characteristics of entities under the control of the TSF.”

AGD_ADM.1.7C ”The administrator guidance shall be consistent with all other docu-mentation supplied for evaluation.”

AGD_USR.1.5C ”The user guidance shall be consistent with all other documentation supplied for evaluation.”

The new structure contains a superordinate re-quirement that all evaluation evidence is consis-tent (CEM §56a)3)).

AGD_ADM.1.1E ”The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.”

AGD_USR.1.1E ”The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.”

AGD_OPE.1.1E ”The evaluator shall confirm that the informa-tion provided meets all requirements for content and presentation of evidence.”

Table 23: Guidance Documents: Coverage of elements

11.4 Work units Within AGD_ADM, AGD_USR, and within the new family AGD_OPE, there is a one-to-one correspon-dence of work units and content and presentation elements. Hence the work unit table is quite similar to the element table in the preceding chapter:

AGD_ADM and AGD_USR work units Coverage by work units of AGD_OPE

AGD_ADM.1-3 ”The evaluator shall examine the administrator guidance to determine that it contains warnings about functions and privileges that should be controlled in a secure processing environment.”

AGD_USR.1-3 ”The evaluator shall examine the user guidance to determine that it contains warnings about user-accessible functions and privileges that should be controlled in a secure processing environment..”

AGD_OPE.1-1 “The evaluator shall examine the operational user guidance to determine that it describes, for each user role, the user-accessible functions and privileges that should be controlled in a secure processing environment, including appropriate warnings.”

AGD_USR.1-2 ”The evaluator shall examine the user guidance to determine that it describes the use of user-accessible security functions provided by the TOE.”

AGD_ADM.1-2 ”The evaluator shall examine the administrator guidance to determine that it describes how to administer the TOE in a secure manner.”

AGD_USR.1-4 ”The evaluator shall examine the user guidance to determine that it presents all user responsibilities necessary for secure operation of the

AGD_OPE.1-2 “The evaluator shall examine the operational user guidance to determine that it describes, for each user role, the secure use of the available interfaces provided by the TOE.”

Transition guide for ALC, ACM, ADO and AGD AGD Version 2.0, 22.01.2008 Work units


AGD_ADM and AGD_USR work units Coverage by work units of AGD_OPE

AGD_ADM.1-4 ”The evaluator shall examine the administrator guidance to determine that it describes all assumptions regarding user behaviour that are relevant to the secure operation of the TOE.”

AGD_USR.1-6 ”The evaluator shall examine the user guidance to determine that it describes all security requirements for the IT environment of the TOE that are relevant to the user.”

AGD_ADM.1-8 ”The evaluator shall examine the adminstrator guidance to determine that it describes all security requirements for the IT environment of the TOE that are relevant to the administrator.”

AGD_OPE.1-6 “The evaluator shall examine the operational user guidance to determine that it describes, for each user role, the security measures to be fol-lowed in order to fulfil the security objectives for the operational environment as described in the ST.”

AGD_ADM.1-1 ”The evaluator shall examine the administrator guidance to determine that it describes the administrative security interfaces available to the administrator of the TOE.”

AGD_USR.1-1 ”The evaluator shall examine the user guidance to determine that it describes the security functions and interfaces available to the non-administrative users of the TOE.”

AGD_ADM.1-5 ”The evaluator shall examine the administrator guidance to determine that it describes all security parameters under the control of the admin-istrator, indicating secure values as appropriate.”

AGD_OPE.1-3 “The evaluator shall examine the operational user guidance to determine that it describes, for each user role, the available security functional-ity and interfaces, in particular all security pa-rameters under the control of the user, indicating secure values as appropriate.”

AGD_ADM.1-6 ”The evaluator shall examine the administrator guidance to determine that it describes each type of security-relevant event relative to the administrative functions that need to be performed, including changing the security characteristics of entities under the control of the TSF.”

AGD_OPE.1-4 “The evaluator shall examine the operational user guidance to determine that it describes, for each user role, each type of security-relevant event relative to the user functions that need to be performed, including changing the security characteristics of entities under the control of the TSF and operation following failure or opera-tional error.”

AGD_ADM.1-7 ”The evaluator shall examine the administrator guidance to determine that it is consistent with all other documents supplied for evaluation.”

AGD_USR.1-5 ”The evaluator shall examine the user guidance to determine that it is consistent with all other documentation supplied for evaluation.”

The new structure contains a superordinate re-quirement that all evaluation evidence is consis-tent (CEM §56a)3)).

Table 24: Guidance Documents: Coverage of work units

AVA_MSU Transition guide for ALC, ACM, ADO and AGD Basic considerations Version 2.0, 22.01.2008


12. AVA_MSU

12.1 Basic considerations Since there is a considerable amount of redundancy between AVA_MSU and AGD_OPE, AVA_MSU is dissolved in the new structure, and the non-redundant parts of AVA_MSU are moved to other families.

The first MSU component (“Examination of guidance”) is strongly related to AGD, particularly to AGD_OPE. Most of the requirements are covered by existing requirements of AGD, the remaining ones are supplemented.

The higher MSU components (MSU.2 = “Validation of analysis”, MSU.3 = “Analysis and testing for inse-cure states”) don’t fit into AGD since they require a developer analysis of the guidance documentation. This analysis might be seen as a special case of developer’s overall vulnerability analysis, hence the right new place for the higher MSU components seems to be the family AVA_VAN (“Vulnerability Analysis”) which in particular includes independent evaluator testing. This matter is not followed up here, since AVA_VAN is outside of the scope of this document.

12.2 Components

AVA_MSU components Corresponding new components

AGD_OPE.1 Operational user guidance AVA_MSU.1 Examination of guidance

AGD_PRE.1 Preparative procedures

AVA_MSU.2 Validation of analysis

AVA_MSU.3 Analysis and testing for inse-cure states

AVA_VAN.* Vulnerability analysis

Table 25: Misuse: Mapping of components

Transition guide for ALC, ACM, ADO and AGD AVA_MSU Version 2.0, 22.01.2008 Elements


12.3 Elements The concrete mapping on element level is described in the following figure and table. The table gives addi-tionally the wording of the new elements.

MSU1C

5E

4E

3E

1E

5C

4C

2C

OPE

7C

1E

5C

4C

3C

2C

VAN

PRE2E

2E(exten-sion)

.1

.2

.3

2E

3C

6C

1C

GeneralConsistency

Figure 4: Misuse: Mapping of elements

The redundant elements of MSU.1 are mapped to those elements of AGD_OPE.1 which have already been defined in chapter 11.3; the non-redundant elements to new elements of AGD_OPE.1 resp. AGD_PRE.1 which are defined in the following table. The additional requirements of MSU.2 and MSU.3 are moved to AVA_VAN, cf. chapter 12.1.

Note: The shift of the MSU elements 2C and 2E to OPE resp. PRE brings about a shift from EAL 3 to EAL 1. But MSU.1.2C seems to fit well into EAL 1, and MSU.1.2E is similar to the previous IGS.1.2E which was also required by EAL 1 (cf. 15.3).

AVA_MSU Transition guide for ALC, ACM, ADO and AGD Elements Version 2.0, 22.01.2008


AVA_MSU elements Coverage by AGD elements resp. by AVA_VAN AVA_MSU.1.1C ”The guidance documentation shall identify all possible modes of operation of the TOE (includ-ing operation following failure or operational error), their consequences and implications for maintaining secure operation.”

AGD_OPE.1.5C “The operational user guidance shall identify all possible modes of operation of the TOE (including operation following failure or opera-tional error), their consequences and implications for maintaining secure operation.”

AGD_OPE.1.2C “The operational user guidance shall describe, for each user role, how to use the available interfaces provided by the TOE in a secure man-ner.” AGD_OPE.1.3C “The user guidance shall describe, for each user role, the available functions and interfaces, in particular all security parameters under the control of the user, indicating secure values as appropriate.”

AVA_MSU.1.2C ”The guidance documentation shall be com-plete, clear, consistent and reasonable.”

AGD_OPE.1.7C “The user guidance shall be clear and reasonable.” Note: Consistency is covered in the new structure by the superordi-nate requirement CEM §56a)3).

AVA_MSU.1.3C ”The guidance documentation shall list all as-sumptions about the intended environment.”

AVA_MSU.1.4C ”The guidance documentation shall list all re-quirements for external security measures (in-cluding external procedural, physical and per-sonnel controls).”

Measures regarding installation: AGD_PRE.1.2C “The documentation of the preparative procedures shall describe all the steps necessary for secure installation of the TOE and for the secure preparation of the operational environment in accordance with the security objectives for the operational environment as described in the ST.” Measures regarding user behaviour: AGD_OPE.1.6C “The operational user guidance shall, for each user role, describe the security measures to be followed in order to fulfil the security objec-tives for the operational environment as described in the ST.” Note: In the new structure, the requirements shall no longer refer to assumptions, but to the security objectives provided by the ST.

AVA_MSU.1.1E ”The evaluator shall confirm that the informa-tion provided meets all requirements for content and presentation of evidence.”

AGD_OPE.1.1E ”The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.”

AVA_MSU.1.2E ”The evaluator shall repeat all configuration and installation procedures to confirm that the TOE can be configured and used securely using only the supplied guidance documentation.”

AGD_PRE.1.2E ”The evaluator shall apply the preparative procedures to confirm that the TOE can be prepared securely for operation.”

AGD_OPE.1.4C “The operational user guidance shall, for each user role, clearly pre-sent each type of security-relevant event relative to the user-accessible functions that need to be performed, including changing the security characteristics of entities under the control of the TSF.”

AVA_MSU.1.3E ”The evaluator shall determine that the use of the guidance documentation allows all insecure states to be detected.”

AGD_OPE.1.1E ”The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.”

Transition guide for ALC, ACM, ADO and AGD AVA_MSU Version 2.0, 22.01.2008 Work units


AVA_MSU elements Coverage by AGD elements resp. by AVA_VAN AVA_MSU.2.5C ”The analysis documentation shall demonstrate that the guidance documentation is complete.” AVA_MSU.2.2E/AVA_MSU.3.2E ”... , and other procedures selectively, ...” AVA_MSU.2.4E ”The evaluator shall confirm that the analysis documentation shows that guidance is provided for secure operation in all modes of operation of the TOE.” AVA_MSU.3.5E ”The evaluator shall perform independent test-ing to determine that an administrator or user, with an understanding of the guidance docu-mentation, would reasonably be able to deter-mine if the TOE is configured and operating in a manner that is insecure.”

AVA_VAN: Annex B.2.1.5 of the CEM 3.1 (Misuse) explains, how incomplete guidance as well as insufficient TOE’s support to maintain a secure state, for example because of absence of appropriate alarms, may lead to potential vulnerabilities. These potential vulnerabilities have to be examined by the evaluator in AVA_VAN. So their testing, which is no longer described as a separate evaluator activity, has become part of the Penetration Testing in CC v3.1. Thus MSU.2 and .3 of the previous criteria are not explicitly covered in the new version, but implicitly by the analysis of potential vulner-abilities in AVA_VAN.

Table 26: Misuse: Coverage of elements

12.4 Work units The structure of the new work units results in a straightforward manner from the new element structure:

AVA_MSU work units Coverage by AGD work units resp. by AVA_VAN

AGD_OPE.1-3 “The evaluator shall examine the operational user guidance to deter-mine that it describes, for each user role, the available security func-tionality and interfaces, in particular all security parameters under the control of the user, indicating secure values as appropriate.”

AVA_MSU.1-1 ”The evaluator shall examine the guidance and other evaluation evidence to determine that the guidance identifies all possible modes of operation of the TOE (including, if applicable, operation following failure or operational error), their conse-quences and implications for maintaining secure operation.”

AGD_OPE.1-4 “The evaluator shall examine the operational user guidance to deter-mine that it describes, for each user role, each type of security-relevant event relative to the user functions that need to be per-formed, including changing the security characteristics of entities under the control of the TSF and operation following failure or opera-i l ”AVA_MSU.1-2

”The evaluator shall examine the guidance to de-termine that it is clear and internally consistent.”

AGD_OPE.1-7 “The evaluator shall examine the operational user guidance to deter-mine that it is clear.”

AGD_OPE.1-2 “The evaluator shall examine the operational user guidance to deter-mine that it describes, for each user role, the secure use of the avail-able interfaces provided by the TOE.” AGD_OPE.1-3 “The evaluator shall examine the operational user guidance to deter-mine that it describes, for each user role, the available security func-tionality and interfaces, in particular all security parameters under the control of the user, indicating secure values as appropriate.”

AVA_MSU.1-3 ”The evaluator shall examine the guidance and other evaluation evidence to determine that the guidance is complete and reasonable.”

AGD_OPE.1-8 “The evaluator shall examine the operational user guidance to deter-mine that it is reasonable.”

AVA_MSU Transition guide for ALC, ACM, ADO and AGD Work units Version 2.0, 22.01.2008


AVA_MSU work units Coverage by AGD work units resp. by AVA_VAN

AVA_MSU.1-4 ”The evaluator shall examine the guidance to de-termine that all assumptions about the intended environment are articulated.”

AVA_MSU.1-5 ”The evaluator shall examine the guidance to de-termine that all requirements for external security measures are articulated.”

Measures regarding installation: AGD_PRE.1-2 “The evaluator shall examine the provided installation procedures to determine that they describe the steps necessary for secure installa-tion of the TOE and the secure preparation of the operational envi-ronment in accordance with the security objectives in the ST.” Measures regarding user behaviour: AGD_OPE.1-6 “The user guidance shall for each user role describe the security measures to be followed in order to fulfil the security objectives in the ST for the operational environment.”

AVA_MSU.2-6 ”The evaluator shall examine the developer's analysis to determine that the developer has taken adequate measures to ensure that the guidance is complete.”

Covered implicitly by AVA_VAN, see above the explanation belong-ing to AVA_MSU.2.5C, AVA_MSU.*.2E, .4E and .5E.

AVA_MSU.1-6 / 2-7 ”The evaluator shall perform all administrator and user (if applicable) procedures necessary to con-figure and install the TOE to determine that the TOE can be configured and used securely using only the supplied guidance.”

AGD_PRE.1-3 ”The evaluator shall perform all user procedures necessary to prepare the TOE to determine that the TOE and its operational environment can be prepared securely using only the supplied preparative user guidance.”

AVA_MSU.2-8 ”The evaluator shall perform other security rele-vant procedures specified in the guidance to de-termine that the TOE can be configured and used securely using only supplied guidance.”

Covered implicitly by AVA_VAN, see above the explanation belong-ing to AVA_MSU.2.5C, AVA_MSU.*.2E, .4E and .5E.

AVA_MSU.1-7 / 2-9 ”The evaluator shall examine the guidance to de-termine that sufficient guidance is provided for the consumer to effectively administer and use the TSF, and to detect insecure states.”

AGD_OPE.1-4 “The evaluator shall examine the operational user guidance to deter-mine that it describes, for each user role, each type of security-relevant event relative to the user functions that need to be per-formed, including changing the security characteristics of entities under the control of the TSF and operation following failure or opera-tional error.”

AVA_MSU.2-10 ”The evaluator shall examine the developer's analysis of the guidance to determine that guidance is provided for secure operation in all modes of operation of the TOE.”

AVA_VAN, see above the explanation belonging to AVA_MSU.2.5C, AVA_MSU.*.2E, .4E and .5E.

Table 27: Misuse: Coverage of work units

Transition guide for ALC, ACM, ADO and AGD ADO_DEL / developer’s procedures Version 2.0, 22.01.2008 Basic considerations


13. ADO_DEL / developer’s procedures

13.1 Basic considerations The present family ADO_DEL (“Delivery”) deals mainly if not exclusively with developer delivery proce-dures. The new structure moves these into ALC as a separate family ALC_DEL.

ALC_DEL is concerned with the process of securely transferring the finished TOE from the development environment into the hands of the user, not with transports between different development sites. The end of the delivery phase is marked by the transfer of the TOE into the responsibility of the user. This does not nec-essarily coincide with the arrival of the TOE at the user's location.

RI #210 observes that the first component of ADO_DEL deals with all security aspects, the higher compo-nents only with integrity and suggests to extend also the higher components to confidentiality and further security aspects. But security properties as confidentiality and availability are not needed for all kinds of TOEs, even not on high assurance levels.

DEL.3 deals with prevention of modifications. The American scheme has recently advanced the opinion that prevention of modifications during delivery is virtually impossible, so this requirement would not make sense.

To avoid unnecessary regulations in this area, in the new concept the three DEL components are merged into a single one which requires the developer to take into account all those security aspects required by the PP/ST for the actual TOE, and to commensurate the level of protection with the chosen level of AVA_VLAVAN.

13.2 Components

ADO_DEL components Corresponding new ALC_DEL components

ADO_DEL.1 Delivery procedures

ADO_DEL.2 Detection of modification

ADO_DEL.3 Prevention of modification

ALC_DEL.1 Delivery procedures

Table 28: Delivery (developer’s procedures): Mapping of components

ADO_DEL / developer’s procedures Transition guide for ALC, ACM, ADO and AGD Elements Version 2.0, 22.01.2008


13.3 Elements

CC/CEM version 2.3 Coverage of developer responsibility in CC/CEM version 3.1

Components EAL Elements Elements EA

L Components

1: Delivery procedures 2 1C: Delivery

procedures 2C: Detection of

modification 2: Detection of modification 4

3C: Detection of masquerading

2C: Prevention of modification

AD

O_D

EL

3: Prevention of modification 7

3C: Detection of masquerading

1C: Delivery procedures 2 1: Delivery

procedures

AL

C_D

EL

Table 29: Delivery (developer’s procedures): Mapping of elements

The wording of the new element is as follows:

ALC_DEL.1.1C:

”The delivery procedures shall describe all procedures that are necessary to maintain security when distributing versions of the TOE to the consumer.”

13.4 Work units The new element ALC_DEL.1.1C is provided with the following work unit:

ALC_DEL.1-1:

“The evaluator shall examine the delivery documentation to determine that it describes all proce-dures that are necessary to maintain security when distributing versions of the TOE or parts of it to the consumer.”

The guidance text should amplify that the term “necessary to maintain security” will need to consider the nature of the TOE and information contained in the ST. The level of protection provided should be commen-surate with the chosen component of AVA_VLAVAN. The security aspects (integrity, confidentiality, avail-ability) relevant for the actual TOE should be derived from the security objectives defined in the ST.

Transition guide for ALC, ACM, ADO and AGD ADO_DEL / user’s procedures Version 2.0, 22.01.2008 Basic considerations


14. ADO_DEL / user’s procedures

14.1 Basic considerations There are user activities in the context of delivery (though they were not explicitly articulated in the previous criteria), namely the acceptance procedures of the delivered TOE. As user activities, they should naturally be treated in AGD. More specific, since they are preparative with regard to the operation of the TOE, they are included into the family AGD_PRE.

Two levels of acceptance procedures may be distinguished:

• Basic acceptance procedure: The user has to determine that the delivered TOE is indeed the evaluated instance. This is presumably based on a verification of the TOE’s label against the certificate.

• Advanced acceptance procedures: If detection of modifications/masquerading is required by the deliv-ery procedures, the user has to perform the appropriate acceptance procedures with the delivered TOE to accomplish the developer’s measures.

14.2 Components

ADO_DEL components Corresponding AGD_PRE components

ADO_DEL.1 Delivery procedures (user’s part)

ADO_DEL.2 Detection of modification (user’s part)


ADO_DEL.3 Prevention of modification (solely developer’s part)

--- ---

Table 30: Delivery (user’s procedures): Mapping of components

14.3 Elements The straightforward approach would be to map each ADO_DEL requirement to an AGD_PRE requirement that defines the corresponding user responsibility. Since the ADO_DEL requirements come in at EAL 2 and EAL 4, but AGD_PRE.1 is required by EAL1, this would mean to split AGD_PRE into at least three com-ponents. In order to avoid this we define only one (flexible) AGD_PRE requirement that defines the user responsibilities in dependency on developer’s delivery procedures, then only one new AGD_PRE require-ment is necessary to cover the ADO_DEL requirements (as regards the user side). This element is already introduced with AGD_PRE.1 at EAL 1.

ADO_DEL / user’s procedures Transition guide for ALC, ACM, ADO and AGD Work units Version 2.0, 22.01.2008


CC/CEM version 2.3 Coverage of user responsibility in CC/CEM version 3.1

Components EAL Elements Elements EA

L Components

1: Delivery pro-cedures 2 1C: Delivery

procedures

2C: Detection of modification 2: Detection of

modification 4 3C: Detection of mas-

querading

1C: Acceptance pro-cedures 1 1: Preparative

procedures

AD

O_D

EL

3: Prevention of modification 7 2C: Prevention of

modification --- --- ---

AG

D_P

RE

Table 31: Delivery (user’s procedures): Mapping of elements

The wording of the new element is as follows:

AGD_PRE.1.1C:

”The preparative procedures shall describe all the steps necessary for secure acceptance of the deliv-ered TOE in accordance with the developer’s delivery procedures.”

14.4 Work units The new element AGD_PRE.1.1C is provided with the following work unit:

AGD_PRE.1-2:

“The evaluator shall examine the provided acceptance procedures to determine that they describe the steps necessary for secure acceptance of the TOE in accordance with the developer’s delivery proce-dures.”

Transition guide for ALC, ACM, ADO and AGD ADO_IGS / user’s procedures Version 2.0, 22.01.2008 Basic considerations


15. ADO_IGS / user’s procedures

15.1 Basic considerations User installation, generation, and start-up procedures are the main concern of the present ADO_IGS family. As user activities, they are naturally be treated in AGD in the new structure. More specific, since they are preparatory with regard to the operation of the TOE, they are included into the family AGD_PRE. The first component ADO_IGS.1 (“Installation, generation, and start-up procedures”) is mapped to the component AGD_PRE.1 (“Preparative procedures”). The second component ADO_IGS.2 (“Generation log”) was not required by any EA level in the previous structure, and is set aside in the new structure.

Remark: The former idea to merge ADO_IGS with AGD_ADM is no longer followed up here. Though the CC sees a close relationship between these two families (cf. the last application note of ADO_IGS; obviously here the CC regards only user IGS = installation), they belong to different life-cycle phases and are kept separate in the new structure. The dependency of ADO_IGS.1 on AGD_ADM.1 is omitted anyway (cf. 11.1).

15.2 Components

ADO_IGS components Corresponding new AGD components

ADO_IGS.1 Installation, generation and start-up procedures


ADO_IGS.2 Generation log --- ---

Table 32: IGS (user’s procedures): Mapping of components

15.3 Elements ADO_IGS elements Coverage by AGD_PRE elements

ADO_IGS.1.1D ”The developer shall document procedures necessa-ry for the secure installation, generation, and start-up of the TOE.”

AGD_PRE.1.1D ”The developer shall provide the TOE including its preparative procedures.”

ADO_IGS.1.1C ”The IGS documentation shall describe the steps necessary for secure installation, generation, and start-up of the TOE.”

AGD_PRE.1.2C ”The preparative procedures shall describe all the steps necessary for secure installation of the TOE and for the secure preparation of the operational environ-ment in accordance with the security objectives for the operational environment as described in the ST.”

ADO_IGS.1.1E ”The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.”

AGD_PRE.1.1E (same wording)

ADO_IGS.1.2E ”The evaluator shall determine that the installation, generation, and start-up procedures result in a se-cure configuration.”

AGD_PRE.1.2E ”The evaluator shall apply the preparative procedures to confirm that the TOE can be prepared securely for operation.”

Table 33: IGS (user’s procedures): Coverage of elements

ADO_IGS / user’s procedures Transition guide for ALC, ACM, ADO and AGD Work units Version 2.0, 22.01.2008


Note that AGD_PRE.1.1C which does not occur in this table comes from ADO_DEL, cf. chapter 0.

15.4 Work units The element AGD_PRE.1.2C is provided with the following work unit:

AGD_PRE.1-2:

“The evaluator shall examine the provided installation procedures to determine that they describe the steps necessary for secure installation of the TOE and the secure preparation of the operational environment in accordance with the security objectives in the ST.”

The element AGD_PRE.1.2E is provided with the following work unit:

AGD_PRE.1-3:

“The evaluator shall perform all user procedures necessary to prepare the TOE to determine that the TOE and its operational environment can be prepared securely using only the supplied preparative user guidance.”

Transition guide for ALC, ACM, ADO and AGD ADO_IGS / developer’s procedures Version 2.0, 22.01.2008 Basic considerations


16. ADO_IGS / developer’s procedures

16.1 Basic considerations By the application notes in the previous criteria, there may also be IGS procedures that have to be carried out by the developer. The application notes in the CEM (paragraph 1274) stated more explicitly, that all IGS procedures have to be taken into account, regardless of whether they are performed at the user’s site or at the development site.

However, there was a little inconsistency with paragraphs 1276 and 1277 in the CEM: According to these, the IGS work units are not applicable, if the TOE is delivered in an operational state. This disregards, that there may be IGS activities that have to be performed before the delivery at the development site.

Here we assume, that the activities at the user’s site and at the development site have both to be taken into account by ADO_IGS.

However, developer IGS activities are seen here as part of the production, and production procedures have to be described in the context of the configuration management anyway. A comparison of the requirements shows that ADO_IGS.1 restricted to procedures at the development site is covered by ALC_CMC.5. This is fine apart from the gap in the EAL levels: ADO_IGS.1 is required at EAL 1, ALC_CMC.5 only at EAL 6.

As we see it, the previous criteria required ADO_IGS.1 at EAL 1 only with respect to user’s IGS procedures that were mainly in the focus of IGS. Requiring the description of developer’s IGS procedures at EAL 1 is inconsistent with the objective that an EAL 1 evaluation should be accomplishable without internal informa-tion of the developer. Anyway, we don’t see a reason why the description of those IGS procedures to be per-formed at the development site should be required at a lower level than the description of any other produc-tion procedures.

The second IGS component (generation log) is mainly specified to the user. However, there is a similar re-quirement for the developer in ALC_CMC.5, namely the element ALC_CMC.5.9C.

So the new structure does not contain explicit requirements for the description of IGS procedures at the de-velopment site.

Automatic IGS procedures

Beyond this, the evaluator has to take into account information about the procedures, which the TOE itself carries out automatically in the IGS process to determine that the IGS procedures result in a secure configu-ration. These aspects are covered in the new structure in ADV: In IMP.2, insofar set up procedures are con-cerned, and in the new ADV families INT and ARC which examine the TSF internals and the architectural design, including aspects of bypass or corruption of security mechanisms.

16.2 Components

ADO_IGS components Corresponding ALC_CMC components

ADO_IGS.1 Installation, generation and start-up procedures

ADO_IGS.2 Generation log

ALC_CMC.5 CM capability

Table 34: IGS (developer’s procedures): Mapping of components

ADO_IGS / developer’s procedures Transition guide for ALC, ACM, ADO and AGD Elements Version 2.0, 22.01.2008


16.3 Elements

ADO_IGS elements Coverage by ALC_CMC.5 elements

ADO_IGS.*.1D ”The developer shall document proce-dures necessary for the secure installa-tion, generation, and start-up of the TOE.”

ALC_CMC.5.3D: “The developer shall provide CM documentation.”

ADO_IGS.*.1C ”The IGS documentation shall describe the steps necessary for secure installa-tion, generation, and start-up of the TOE.”

IGS at the development site is part of the production, hence it has to be described here the steps for secure production.

ALC_CMC.5.6C: “The CM system shall support the production of the TOE by automated means.”

ALC_CMC.5.13C: “The CM plan shall describe how the CM system is used in the development of the TOE.”

ADO_IGS.*.1E ”The evaluator shall confirm that the information provided meets all require-ments for content and presentation of evidence.”

ALC_CMC.5.1E (same wording)

ADO_IGS.*.2E ”The evaluator shall determine that the installation, generation, and start-up procedures result in a secure configura-tion.”

IGS at the development site is the closing part of the production, hence it has to be determined here that the TOE after completion of the production is in a secure configuration.

ALC_CMC.5.2E: “The evaluator shall determine that the application of the produc-tion procedures results in a TOE as provided by the developer for testing activities.”

ADO_IGS.2.2C ”The IGS documentation shall describe procedures capable of creating a log containing the generation options used to generate the TOE in such a way that it is possible to determine exactly how and when the TOE was generated.”

ALC_CMC.5.9C: “The CM system shall support the audit of all changes to the TOE by automated means,...”

Table 35: IGS (developer’s procedures): Coverage of elements

Transition guide for ALC, ACM, ADO and AGD ADO_IGS / developer’s procedures Version 2.0, 22.01.2008 Work units


16.4 Work units

ADO_IGS work units Coverage by ALC_CMC.5 work units

ADO_IGS.1-1 ”The evaluator shall check that the pro-cedures necessary for the secure installa-tion, generation and start-up of the TOE have been provided.”

IGS at the development site is part of the production, hence it has to be checked here that the procedures for secure production have been provided.

ALC_CMC.5-7: “The evaluator shall check the CM plan for automated procedures for supporting the production of the TOE.”

ALC_CMC.5-8: “The evaluator shall examine the TOE production support procedures to determine that they are effective in ensuring that a TOE is generated that reflects its implementation representation.”

ALC_CMC.5-15: “The evaluator shall examine the CM plan to determine that it describes how the CM system is used for the development of the TOE.”

ADO_IGS.1-2 ”The evaluator shall examine the pro-vided installation, generation and start-up procedures to determine that they describe the steps necessary for secure installation, generation and start-up of the TOE.”

IGS at the development site is the closing part of the production, hence it has to be determined here that the TOE after completion of the production is in a secure configuration.

ALC_CMC.5-20: “The evaluator shall examine the production support procedures, to determine that by following these procedures a TOE would be produced like that one provided by the developer for testing activities.”

Table 36: IGS (developer’s procedures): Coverage of work units

Interactions with ADV_IMP Transition guide for ALC, ACM, ADO and AGD Elements Version 2.0, 22.01.2008


17. Interactions with ADV_IMP

17.1 Elements

17.1.1 The element ADV_IMP.1.3C ADV_IMP.1.2D:

”The developer shall make available any additional information necessary to interpret the implemen-tation representation supplied.”

ADV_IMP.1.3C:

”The additional information shall describe any conventions, directives or other constructs necessary to determine the portions of the implementation representation that will be used when the implemen-tation representation is transformed into the implementation itself.”

The element ADV_IMP.1.3C is considered to be covered by ALC_TAT.1.2C when supplemented in the following way:

ALC_TAT.1.2C:

”The documentation of the development tools shall unambiguously define the meaning of all state-ments as well as all conventions and directives used in the implementation.”

The work unit is supplemented accordingly. Its guidance text is supplemented with the following para: “The development tool documentation should define all conventions and directives used in the implementation.”

This has been agreed in the consistency review meeting in may 2005.

17.1.2 The element ADV_IMP.2.2E ADV_IMP.2.2E:

”The evaluator shall determine that the implementation representation when transformed to the im-plementation using the developer-provided tools and instructions, is identical to the implementation used in testing activities.”

This element is considered to be covered by the ALC_CMC element (new in version 3.1)

ALC_CMC.5.2E:

”The evaluator shall determine that the application of the production support procedures results in a TOE as provided by the developer for testing activities.”

The coverage is supported by ALC_TAT as regards development tools, and by ALC_CMC.4-7 with the guidance text “The production support procedures should describe the tools to be used, and any conventions, directives, or other constructs necessary to produce the final TOE from the implementation representation in a clearly defined way.”

Thus IMP.2.2E is removed in CC version 3.1.

Transition guide for ALC, ACM, ADO and AGD Concept for a Guideline on Site Visits Version 2.0, 22.01.2008 Motivation


18. Concept for a Guideline on Site Visits

18.1 Motivation

18.1.1 Reasons for the Need for a Guidance on Site Visits The main motivation for providing a guidance for site visits is to increase comparability between certificates regarding the scope and depth of the on-site examinations. Beyond this, a guidance would facilitate and clar-ify the task of evaluators and so save time. It would even be helpful for developers, who are often unsure about how much they must do in order to pass the site visit.

Actual situation

Several work units of the CEM strongly suggest to visit the development site in order to perform the required examinations. Annex A.4 of the CEM v3.1 resumes the concerned CC families and gives a short overview on site visits: Reasons for doing site visits, scheduling of site visits, preparing them by generating a checklist, applicable methods, considerations when it is possible to do the evaluation without a site visit.

Beyond this, the BSI has issued a guidance on site visits (AIS 1, Version 7, 1997). It is more detailed than the CEM Annex and deals with objectives, regulations and scheduling of site visits, and it contains a list with aspects to be taken into account when compiling a checklist in preparation of a site visit.

Reasons, why this situation is unsatisfactory

While traditionally the main focus was on the security functionality of the TOE itself, now there is coming up an increasing interest in the security at the developer’s site. This is reflected in activities of the standardi-sation boards (ISO, CC) and calls for a more precise and concrete representation of the requirements regard-ing the development environment. This concerns particularly site visits. A parallel process is going on in the field of Information Security Management Systems (ISMS), where also the creation and standardisation of criteria is being in the progress.

The CEM overview is much too short and too general to achieve comparability on an acceptable level. The actual requirements have to be tediously brought together from various work units.

The AIS 1 had been compiled particularly with regard to the ITSEC criteria, and uses ITSEC specific terms and references. Nevertheless, it may also be used in the context of a CC evaluation, but appropriate adapta-tions have to be performed then.

Furthermore, the AIS 1 is valid only in Germany. Other nations may have different guidance documents for site visits or none at all.

18.2 Proposal for Annex A.4 in CC 3.x (was Annex B.5 in CC 2.x)

18.2.1 Introduction The assurance class ALC includes requirements for

1. the application of configuration management, ensuring that the integrity of the TOE is preserved;

2. measures, procedures, and standards concerned with secure delivery of the TOE, ensuring that the secu-rity protection offered by the TOE is not compromised during the transfer to the user,

3. security measures, used to protect the development environment.

A development site visit is a useful means whereby the evaluator determines whether procedures are being followed in a manner consistent with that described in the documentation.

Concept for a Guideline on Site Visits Transition guide for ALC, ACM, ADO and AGD Proposal for Annex A.4 in CC 3.x (was Annex B.5 in CC 2.x) Version 2.0, 22.01.2008


Reasons for visiting sites include:

1. to observe the use of the CM system4 as described in the CM plan;

2. to observe the practical application of delivery procedures as described in the delivery documentation;

3. to observe the application of security measures during development and maintenance of the TOE as de-scribed in the development security documentation.

4. Specific and detailed information is given in work units5 for those activities where site visits are per-formed:

5. CM capabilities (ALC_CMC).n (with n>=3);

6. Delivery (ALC_DEL);

7. Development security (ALC_DVS).

18.2.2 General Approach During an evaluation it is often necessary that the evaluator will meet the developer more than once and it is a question of good planning to combine the site visit with another meeting to reduce costs. For example one might combine the site visits for configuration management, for the developer's security and for delivery. It may also be necessary to perform more than one site visit to the same site to allow the checking of all devel-opment phases. It should be considered that development could occur at multiple facilities within a single building, multiple buildings at the same site, or at multiple sites.

The first site visit should be scheduled early during the evaluation. In the case of an evaluation which starts during the development phase of the TOE, this will allow corrective actions to be taken, if necessary. In the case of an evaluation which starts after the development of the TOE, an early site visit could allow corrective measures to be put in place if serious deficiencies in the applied procedures emerge. This avoids unnecessary evaluation effort.

Interviews are also a useful means of determining whether the written procedures reflect what is done. In conducting such interviews, the evaluator should aim to gain a deeper understanding of the analysed proce-dures at the development site, how they are used in practise and whether they are being applied as described in the provided evaluation evidence. Such interviews complement but do not replace the examination of evaluation evidence.

As a first step preparing the site visits the evaluators should perform the evaluator work units concerning the assurance class ALC excluding the aspects describing the results of the site visit. Based on the information provided by the relevant developer documentation and the remaining open questions which were not an-swered by the documentation the evaluators compile a check list of the questions which are to be resolved by the site visits.

The first version of the evaluation report concerning the ALC class and the check list serves as input for the consultation with the evaluation authority concerning the site visits.

The check list serve as a guide line for the site visits, which questions are to be answered by inspection of the relevant measures, their application and results, and by interviews. Where appropriate, sampling is used for gaining the required level of confidence (see section A.2).

The results of the site visits are recorded and serve as input for the final version of the evaluation report con-cerning the assurance class ALC.

4 For terms and definitions related to the ALC class like CM system see CC Part3 section 4.3.

5 Especially work units ALC_CMC.3-10 (= ALC_CMC.4-13 = ALC_CMC.5-19), ALC_DEL.1-2 and ALC_DVS.1-3.

Transition guide for ALC, ACM, ADO and AGD Concept for a Guideline on Site Visits Version 2.0, 22.01.2008 Proposal for Annex A.4 in CC 3.x (was Annex B.5 in CC 2.x)


Other approaches to gain confidence should be considered that provide an equivalent level of assurance (e.g. to analyse evaluation evidence). Any decision not to make a visit should be determined in consultation with the evaluation authority. Appropriate security criteria and a methodology should be based on other standards of the Information Security Management Systems area (e.g. ISO/IEC 17799, ISO/IEC 13335, German IT Baseline Protection Manual).

18.2.3 Orientation Guide for the Preparation of the Check List In the following some keywords are provided, which topics should be checked during an audit.

18.2.3.1 Aspects of configuration management

Basic

• Items of the configuration list, including TOE, source code, run time libraries, design documentation, development tools. (ALC_CMC.3-8)

• Tracking of design documentation, source code, user guidance to different versions of the TOE

• Integration of the configuration system in the design and development process, test planning, test analy-sis and quality management procedures.

Test analysis

• Tracking of test plans and results to specific configurations and versions of the TOE

Access control to development systems

• policies for access control and logging

• policies for project specific assignment and changing of access rights

Clearance

• policies for clearance of the TOE and user guidance to the customer

• policies for testing and approving of components and the TOE before deployment

18.2.3.2 Aspects of development security

Infrastructure

• security measures for physical access control to the development site and rationale for the effectiveness of these measures

Organisational measures

• organisational structure of the company in respect of the security of the development environment

• organisational separation between development, production, testing and quality assurance

Personal measures

• measures for education of the personnel in respect of development security

• measures and legal agreements of non disclosure of internal information

Access control

• assignment of secured objects (for instance TOE, source code, run time libraries, design documentation, development tools, user guidance) and security policies

• policies and responsibilities concerning the access control and the handling of authentication informa-tion

Concept for a Guideline on Site Visits Transition guide for ALC, ACM, ADO and AGD Example of a checklist Version 2.0, 22.01.2008


• policies for logging of any kind access to the development site and protection of the logging data

Input, processing and output of data

• security measures for protection of output and output devices (printer, plotter and displays)

• securing of local networks and communication connections

Storage, transfer and destruction of documents and data media

• policies for handling of documents and data media

• policies and responsibilities for destruction of sorted out documents and logging of these events

Data protection

• policies and responsibilities for data and information protection (e.g. for performing backups)

Contingency plan

• practices in case of emergency and responsibilities

• documentation of the contingency measures concerning access control

• information of the personnel about applicable practises in extreme cases

18.3 Example of a checklist The examples of checklists for site visits consist in tables for the preparation of an audit and for the presenta-tion of the results of an audit.

The checklist structure given in the following is preliminary. Dependent on the concrete contents of the new guideline, changes might become necessary.

The checklist is divided into three sections according to the subjects indicated in the introduction (see chap-ter 18.2.1):

1. Configuration management system.

2. Delivery procedures.

3. Security measures during development.

These sections correspond to the actual CC class ALC, especially the families CM capabilities (ALC_CMC).n with n>=3, Delivery (ALC_DEL) and Development security (ALC_DVS).

The sections are subdivided further into rows corresponding to the relevant work units of the CEM.

The columns of the checklist contain in turn

• a consecutive number,

• the referenced work unit,

• the references to the corresponding developer documentation,

• the explicit reproduction of the developer measures,

• special remarks and questions to be clarified on the visit (beyond the standard evaluator task to verify the application of the indicated measures),

• the result of the examinations during the visit.

Transition guide for ALC, ACM, ADO and AGD Concept for a Guideline on Site Visits Version 2.0, 22.01.2008 Example of a checklist


If it is decided to have separate checklists for preparation and reporting of the audit, the result column is omitted in the preparation list and the remarks and questions column is omitted in the reporting list. The re-maining columns should be identical in both lists.

Example of a checklist at EAL 4 (extract) A. Examination of the CM system (ALC_CMC.4 and ACM_CMS.4)

No. Work unit Developer docu-mentation

Measures Questions and remarks

Result

A.1 CMC.4-11 CMC.4-12

“Configuration Management Sys-tem”, ch. ...

The system auto-matically managing the source code files is capable of admin-istering user profiles and graded access rights, and of check-ing identification and authentication of users.

Does reading or updating of a source code file require a user authentication?

If a user has not the right to access a con-fidential document, it is not even displayed to him in the file list.

... ... ... ... ... ... Table 37: Checklist part A: Examination of the CM system

B. Examination of the delivery procedures (ALC_DEL.1)

No. Work unit Developer documentation


Result

B.1 DEL.1-1 DEL.1-2

“Delivery of the TOE”, ch. ...

The software is trans-mitted PGP-signed and -encrypted to the cus-tomer.

--- The evaluators have checked the process and found it as de-scribed, additionally a checksum is transmit-ted.

... ... ... ... ... ... Table 38: Checklist part B: Examination of the delivery procedures

C. Examination of the organisational and infrastructural developer security (ALC_DVS.1, ALC_LCD.1 and ALC_TAT.1)



Result

C.1 DVS.1-1 DVS.1-2

"Security of the development environment", ch. ...: Premises

The premises are pro-tected by a security fencing.

Is the fencing suf-ficiently strong and high to pre-vent an easy intru-sion into the prem-ises?

The evaluators con-sidered the fencing to be sufficiently strong and high.

Concept for a Guideline on Site Visits Transition guide for ALC, ACM, ADO and AGD Example of a checklist Version 2.0, 22.01.2008


C. Examination of the organisational and infrastructural developer security (ALC_DVS.1, ALC_LCD.1 and ALC_TAT.1)



Result

C.2 “ "Security of the development environment", ch. ...: Building

The building has the following access possi-bilities: • The main entrance.

This door is sur-veyed by the recep-tion and is closed if the reception is not manned.

• An access in the goods reception which is secured by two roller shutters.

Is the listing of the access possibilities complete?

There is an emer-gency exit that cannot be opened from the outside. The roller shutters can be operated only from inside the building; they are closed off the work-hours.

... ... ... ... ... ...

Table 39: Checklist part C: Examination of the developer security

Transition guide for ALC, ACM, ADO and AGD Further ideas Version 2.0, 22.01.2008 EAL 1 evaluation


19. Further ideas

19.1 EAL 1 evaluation By an idea originating from the American environment, an EAL 1 evaluation should be accomplishable by the sponsor without falling back on confidential information from the developer.

In the new concept, EAL 1 requires the components AGD_OPE.1, AGD_PRE.1, ALC_CMC.1, and ALC_CMS.1. The items required by the AGD components are part of the delivery and hence available for the sponsor. ALC_CMS.1 requires a configuration list and uniquely identified configuration items. But the only mandatory configuration item is the TOE itself, which again is available for the sponsor.

Conclusion: In the new structure, an EAL 1 evaluation seems to be accomplishable without developer’s aid.

19.2 Redundancy between ALC_FLR and ACM_SCP.2 There is some overlap of ALC_FLR with the component 2 of ACM_SCP (“Problem tracking CM cover-age”), since both deal with the tracking of detected security flaws. However, since ACM_SCP is used in the definition of EALs, it would have far-reaching effects to modify ACM_SCP. On the other hand, ALC_FLR is much more detailed than ACM_SCP.2, and it would be difficult to extract the overlap from ALC_FLR. Also, ACM_SCP.2 deals with security flaws detected in the development environment, ALC_FLR with se-curity flaws reported by users of the TOE.

Conclusion: We suggest leaving the overlap in the new concept.

19.3 Redundancy between the ALC families DVS and LCD ALC_DVS: „Development security is concerned with physical, procedural, personnel, and other security measures that may be used in the development environment to protect the TOE. It includes the physical secu-rity of the development location and any procedures used to select development staff.”

ALC_LCD: „A life-cycle model encompasses the procedures, tools and techniques used to develop and maintain the TOE. Aspects of the process that may be covered by such a model include design methods, review procedures, project management controls, change control procedures, test methods and acceptance procedures.”

At first glance, redundancy seems to be present in the context of procedural measures. However, procedural measures in the development security deal with (cf. the examples given in the CEM) granting and revocation of access rights, transport of protected material, admitting and escorting visitors, roles and responsibilities concerning security measures, which might be characterised as infrastructural measures. On the other hand, procedures in the life-cycle model deal with (again by the CEM) design, coding, testing, bug fixing, which might be characterised as quality-oriented.

Conclusion: In our view, the redundancy between ALC_DVS and ALC_LCD is quite small, a merging seems not to be profitable.

There might be other approaches. Also there are questions of terminology (measurability, what metric can be used? Cf. the suggestion in chapter 3.3.1).

Processing of RIs Transition guide for ALC, ACM, ADO and AGD Overview Version 2.0, 22.01.2008


20. Processing of RIs

20.1 Overview For this document, all RIs up to #254 were considered that are relevant to ALC/ACM/ADO/AGD (#1, #2, #3, #4, #16, #24, #25, #26, #27, #37, #38, #51, #59, #60, #61, #62, #71, #92, #94, #95, #99, #113, #116, #120, #128, #140, #179, #183, #196, #210, #211, #238).

These RIs may be grouped into three categories:

1. RIs which are Final Interpretations and don’t modify any of ALC/ACM/ADO/AGD (#24, #25, #120, #140).

2. RIs which have already been incorporated in the CC v2.3 (#1, #2, #3, #4, #16, #27, #37, #38, #51, #62, #92, #94, #95, #116).

3. RIs which have not yet been incorporated in the CC v2.3 and which might affect the contents of ALC/ACM/ADO/AGD (#26, #59, #60, #61, #71, #99, #113, #128, #179, #183, #196, #210, #211, #238).

The first two categories need not to be considered here.

The third category is treated in the following table. For each RI it is roughly explained, what it is about, and how it is taken into account by the new structure. For the RIs #26, #71, #99, #179, #183, #196, and #210, the table gives only preliminary considerations and refers to more detailed suggestions presented in the follow-ing subchapters.

Note: The considerations in the following table and subchapters have originally been based on CC v2.2. Since CC v2.3 differs from CC v2.2 only by including the RIs #86, #137, #146, #175, #180, #192, #220, #227, #228, #232, #243, #254, which have no relevance for ALC/ACM/ADO/AGD, the considerations in the following table and subchapters are also valid with respect to CC v2.3.

RI Concerned sub-ject / Issue

Contents of the RI Realisation in the new concept

#26 (draft)

Identifying (and controlling) con-figuration items for ACM_CAP.2 Does ACM_CAP.2 require that the draft documents given to the evaluation team need to be under configuration con-trol?

Only the final versions need to be under configuration control.

In the new concept, the requirement is man-aged by scope, not by capability elements. Concretely, the CM coverage of evaluation evidence (hence also draft versions, cf. RI #3) is introduced at the CMS level 1.

A more detailed suggestion to solve this RI is given in chapter 20.2.

#59 (clo-sed)

ALC_FLR/ AMA_AMP de-pendency unneces-sary

The dependency shall be deleted in the next revision of the CC.

AMA is not in the focus of this document.

#60 (clo-sed)

Missing developer actions in ALC_FLR.2 and ALC_FLR.3

The requirement to document the han-dling of user reports and the specific points of contact shall be inserted in the next revision of the CC.

Covered by RI #94.

Transition guide for ALC, ACM, ADO and AGD Processing of RIs Version 2.0, 22.01.2008 Overview




#61 (clo-sed)

Missing content and presentation requirement in ALC_FLR.3

A content and presentation requirement for the point of contact designation shall be added in the next revision of the CC.

Covered by RI #94.

#71 (discus-sion)

No quality meas-ures for develop-ment tools and implementation standards in ALC_TAT.2

ALC_TAT.2 requires the developer to describe the implementation standards to be applied, and the evaluator to con-firm that these standards have been applied. However, the current compo-nent includes no measures of quality or coverage for the implementation stan-dards.

The evaluator should satisfy himself that the used implementation standards are qualified for secure development. This does not mean that he has to evaluate these standards, but he has only to justify that they are acceptable based on the state of the art (e.g. ISO norms, industrial standards, etc.). In case of doubt, the certification body has to make the decision.

(This fits with the guidance of the present work unit ALC_TAT.1-1.)


#99 (draft)

Configuration items in the ab-sence of explicit scope The ACM_CAP.2 elements are un-clear for contexts where no SCP components are included in the PP/ST

At first, it is suggested to replace in the elements of ACM_CAP.2 the terms “CM system” and “CM documentation” by “configuration list”. But this does not really help, since it is just the contents of the configuration list, which should be defined by the SCP components.

Further it is drawn the conclusion that the goal of ACM_CAP in the absence of ACM_SCP is to ensure that an unambi-guous list of configuration items that comprise the TOE be maintained. This contains an implicit requirement on scope, namely the items that comprise the TOE, which should rather be man-aged by scope components.

In the new concept, the second and higher ALC_CMC components have a dependency on ALC_CMS.1, which makes sure that there is at least one configuration item, namely the TOE itself. (Cf. chapter 9.1).


#113 (discus-sion)

How to require user/admin docu-mentation for func-tional components

There needs to be a clear mechanism to allow a functional component to indi-cate information that must be present in user or administrator guidance.

We do not see, why there is a need for this. The evaluator has to assess generally, whether the information in the guidance is sufficient to use the TOE securely (AGD and MSU). So he will find out anyway if the use of a security function is documented insufficiently. There is no need to require explicitly some guidance in SFRs.

#128 (revi-sed final)

It is not clear whether the deliv-ery procedures cover all the TOE or just parts of the TOE.

The delivery documentation should cover the entire TOE, but it may contain different procedures for different parts of the TOE.

The changes by RI #128 shall be incorporated in the new structure, cf. chapter 2.5.

Processing of RIs Transition guide for ALC, ACM, ADO and AGD Overview Version 2.0, 22.01.2008




#179 (assig-ned)

When to meet ALC_DVS and ALC_LCD

Does the line of reasoning of RI # 37 apply to ALC_DVS and ALC_LCD requirements as well? If not, when, during the development process should these requirements be met?

The requirements of ALC_DVS and ALC_LCD shall be met at the time of evalua-tion. There is no requirement for future (non certified) versions of the TOE, if no mainte-nance is in place. During the site visit the evaluator has to satisfy himself that the meas-ures are defined and followed in a way, that he can expect that they are still followed in future (e. g. for production) for the evaluated TOE.

ALC_LCD contains already an appropriate application note. As regards ALC_DVS, a clarifying application note according to RI #37 is inserted.

This is exhibited in more detail in chapter 20.5.

#183 (discus-sion)

Life-cycle specifi-cation

Two issues are raised in this RI. First, a process or requirements have to be defined to allow for composition of a TOE. Second, guidance is needed for the reuse of evaluation results in a composite product.

We are not sure whether the task to define composite evaluation (as done for smart cards in a JIL-document) can be solved in the new version. It might be too big a task.

Surely several cases have to be distinguished: Have single components already been evalu-ated? In this case the way to include the exist-ing results into the new evaluation of the com-posite TOE has to be defined.

If no component has been evaluated before, then all requirements of ALC/ACM etc. hold for all components, so we see no need for modifications in this case.


Cf. also the discussion in chapter 2.1.

#196 (discus-sion)

Splitting CM into separate parts

The requirements for a CM system don’t require different plans and proce-dures for the development stage and the final TOE. Therefore if a developer decides to use different CM processes and procedures for each stage (as indi-cated by ISO 9000), he should make this clear in his CM documentation by de-scribing the different processes and procedures and their applicability during each stage. The evaluator must verify compliance of the separate CM proc-esses and procedures to each of the requirements.

It is often the case that different CM tools are used for different phases of the life-cycle. E. g. there may be different tools for develop-ment and for production (e. g. for smart cards), or for software and hardware parts of the TOE. The CM system addressed by the requirements is to be regarded as the composi-tion of all these tools and the methods of use. A clarifying application note is added in the new version.

This is exhibited in more detail in chapter 20.7.

Transition guide for ALC, ACM, ADO and AGD Processing of RIs Version 2.0, 22.01.2008 Overview




#210 (recei-ved)

Security and "con-fidentiality" in ADO

RI #16 introduces an application note to ADO_DEL. The examples of confiden-tiality cited there deal only with the act of delivery, not with the contents of delivery.

The concerns of this RI will be considered in the new version of CC and CEM , cf. the dis-cussion in 2.5.


#211 (recei-ved)

Are integrity tests part of the TSF? (ACM, ALC, ...)

Must the tests themselves be considered part of the TSF? If not, but portions of the "test harness" need policy exemption privileges, do those portions of the test harness have to be part of the TSF? There is an advantage to have the flexi-bility to use tests and recovery tools that are third-party or non-TSF. This would reduce the required documentation and CM burdens.

We do not see the problem discussed in this RI. Tests defined in an SFR are of course internal tests of the TOE (like start-up or run-time testing). They are completely different from functional tests as defined in ATE. So the functionality realising these run-time tests in the TOE are of course part of the TSF and are evaluated like any TSF functionality. We see no need for modifications of CC and CEM.

#238 (draft)

The elements in-troduced at ACM_CAP.2 deal with unique identi-fication and de-scription of items in the configura-tion list; require-ments on formal configuration man-agement are missed.

CM systems may have varying degrees of rigor and function.

The new concept sees uniquely identifying configuration items as a CM capability, which might very well be seen as basic function of a CM system.

The sentence “At the lowest level, a CM sys-tem may be a simple configuration list” is replaced by “At the lowest level, a CM system uniquely identifies the configuration items.”, since a CM system is seen as an asset belong-ing to the developer which he uses for many of his products (possibly to different extents), whereas the configuration list belongs to a special product of the developer and defines the items of this product which are subject to the CM system.

Table 40: Consideration of RIs

Processing of RIs Transition guide for ALC, ACM, ADO and AGD Draft interpretation for RI #26 Version 2.0, 22.01.2008


20.2 Draft interpretation for RI #26 RI #26: Identifying (and controlling) CIs for ACM_CAP.2

Type: Explanation/Clarification Source: US CB Date: 03/05/1999

Status: Discussion Source #: ttap-od-007

CC Part #1 Reference:



CEM Reference: CEM, Section 6.4.1 (ACM_CAP.2)

Reason: Identifying (and controlling) CIs for ACM_CAP.2

Problem: The vendor asked if the draft documents or any documents given to the team need to be under configuration control. This is in reference to the CM requirement ACM-CAP.2. After investigation of the requirement, it is concluded that final versions of the documentation provided do need to be under configuration control. The CC doesn't really say definitely that documentation is required to be under CM however, I did find these cou-ple of lines that say " CM requires that the integrity of the TOE is adequately preserved. Specifically, con-figuration management provides confidence that the TOE and documentation used for evaluation are the ones prepared for distribution."

Proposed Solution: The documentation accepted by the team in satisfaction of the requirements must be under configuration con-trol. Working copies during the course of the evaluation do not need to be controlled, although it may be beneficial to the team and vendor to control such drafts. US TEF Proposed Resolution: This means the docu-mentation that the evaluation team accepts as satisfying the assurance requirements must be identified as a CI and placed under CM control so that the documents are preserved as the evaluated baseline copy. The draft things the vendor provides do not have to be. It is when the evaluation team gets the last acceptable final ver-sion, does the vendor place it under a CM system. Placing it under a CM system means that the vendor will be able to retrieve a copy of the documentation that the evaluation team used to evaluate the PIX. Basically,verson control. This will allow a baseline to be defined such that chances to the evaluated product including documentation can be properly traced.

Table 41: RI #26: Identifying (and controlling) CIs for ACM_CAP.2

Discussion:

In order to provide a draft interpretation, we first discuss the nature of the problem and possible approaches to the solution. In the end we will recommend one of the approaches and provide a draft solution based on this approach.

Nature of the problem: The RI addresses two connected issues as follows:

1. Which parts of the documentation (or more generally the evaluation deliverables) provided to the evalua-tors by the developer have to be in the scope of the CM system?

According to RI #4 ACM_SCP.1.1C requires that the list of configuration items includes the evaluation evidence required by the assurance components in the ST. So for all EAL-Levels including ACM_SCP.1 or higher it is clear that all evaluation evidence (including documents) provided to the evaluators is in the scope of the CM system.

Transition guide for ALC, ACM, ADO and AGD Processing of RIs Version 2.0, 22.01.2008 Draft interpretation for RI #26


For EAL-Levels not including an ACM_SCP component (i. e. EAL1 and EAL2) the scope of the CM system includes only the TOE (as required implicitly by ACM_CAP.1). So evaluation deliverables (ex-cept the TOE itself) need not be covered by the developer’s CM system.

Note: This situation for low EALs is not considered acceptable in future, because repeatability of evaluations is not guaranteed, if for example the version of an evaluation deliverable cannot be deter-mined. Therefore in the future Version 3.0 of the CC all evaluation deliverables will be included in the scope of the CM system already for EAL1.

2. If a document, which is provided to the evaluators by the developer, is under the scope of the CM sys-tem, does this mean that draft versions handed to the evaluators also have to be under CM?

The answer to this is clear from RI #3, which adds the following guidance text to ACM_CAP.2-7: “....For both configuration items that comprise the TOE, and drafts of configuration items that are sub-mitted by the developer as evaluation evidence, the evaluator confirms that each configuration item pos-sesses a unique identifier in a manner consistent with the unique identification method that is described in the CM documentation." This implies that drafts delivered to the evaluators are subject to the devel-oper’s CM system, if the final item is subject to the CM system.

Note: The question, whether documents or their drafts need to be under control of the evaluator’s configura-tion control system, is different from the one asked in the RI. However, in order to allow repeatability of the evaluation, it is obvious that the evaluator needs to maintain configuration control of all input, which is used during the execution of CEM work units. This includes drafts if (parts of) the work units are executed using the drafts.

Given this situation we see only the following approach:

Draft interpretation:

The RI addresses two connected issues as follows:

1. Which parts of the documentation (or more generally the evaluation deliverables) provided to the evalua-tors by the developer have to be in the scope of the developer’s CM system?

According to RI #4 ACM_SCP.1.1C requires that the list of configuration items includes the evaluation evidence required by the assurance components in the ST. So for all EAL-Levels including ACM_SCP.1 or higher it is clear that all evaluation evidence (including documents) provided to the evaluators is in the scope of the CM system.

For EAL-Levels not including an ACM_SCP component (i. e. EAL1 and EAL2) the scope of the CM system includes only the TOE (as required implicitly by ACM_CAP.1). So evaluation deliverables (ex-cept the TOE itself) need not be covered by the developer’s CM system.

Note: This situation for low EALs is not considered acceptable in future, because repeatability of evaluations is not guaranteed, if for example the version of an evaluation deliverable cannot be deter-mined. Therefore it is planned that in the future Version 3.0 of the CC all evaluation deliverables will be included in the scope of the CM system already for EAL1.

2. If a document, which is provided to the evaluators by the developer, is under the scope of the CM sys-tem, does this mean that draft versions handed to the evaluators also have to be under CM?

The answer to this is clear from RI #3, which adds the following guidance text to ACM_CAP.2-7: “....For both configuration items that comprise the TOE, and drafts of configuration items that are sub-mitted by the developer as evaluation evidence, the evaluator confirms that each configuration item pos-sesses a unique identifier in a manner consistent with the unique identification method that is described in the CM documentation." This implies that drafts delivered to the evaluators are subject to the devel-oper’s CM system, if the final item is subject of the CM system.

Note: The question, whether documents or their drafts need to be under control of the evaluator’s configura-tion control system, is different from the one asked in the RI. However, in order to allow repeatability of the



evaluation, it is obvious that the evaluator needs to maintain configuration control of all input, which is used during the execution of CEM work units. This includes drafts if (parts of) the CEM work units are executed using the drafts.

Specific changes:

No changes in CC or CEM are considered necessary.

Rationale:

Contained in the interpretation.

20.3 Draft interpretation for RI #71 RI #71: No quality measures for development tools and implementation standards

Type: Perceived Errors Source: CEMEB Date: 12/06/1999

Status: Discussion Source #: CEMEB (2000.003)



CC Part #3 Reference: CC Part 3, Section 12.4 (ALC_TAT)

CEM Reference:

Reason: No quality measures for development tools and implementation standards

Problem:

The CEMEB is considering methodology for sub-activities used in EAL5. ALC_TAT.2 requires the devel-oper to describe the implementation standards to be applied, and the evaluator to confirm that these standards have been applied. However, the current component includes no measures of quality or coverage for the im-plementation standards.

Proposed Solution:

The CCIMB is requested either a) to confirm that a nil, trivial or even dangerous set of standards will be suit-able to meet this component; or b) to include content and presentation requirements setting coverage and quality requirements.

Table 42: RI #71: No quality measures for development tools and implementation standards

Discussion:

In order to provide a draft interpretation, we first discuss the nature of the problem and possible approaches to the solution following the discussion. In the end we will recommend one of the approaches and provide a draft solution based on this approach.

The nature of the problem consists in the question to what extent the requirements of the components ALC_TAT.2 and ALC_TAT.3 are suitable to meet the objectives of ALC_TAT.

Requirements:

ALC_TAT.2 and ALC_TAT.3 require the developer to describe the implementation standards to be applied, and the evaluator to confirm that these standards have been applied. However, the current components in-clude no measures of quality or coverage for the implementation standards.



Objectives:

The objectives statement for ALC_TAT refers to a desire to "prevent ill-defined, inconsistent or incorrect [implementation standards] ... from being used to develop the TOE". The reference to "incorrect" is not cur-rently represented in the content and presentation requirements.

The problem consists in the fact that it may be possible to fulfil the requirements by the application of improper implementation standards which do not support the objectives for the assurance family.

Given this situation we see two practically possible approaches and a third, more theoretical approach:

Approach 1: “Pure Nomination of applied standards.”

The developer describes the implementation standards to be applied, and the evaluator confirms that these standards have been applied. It is not evaluated if these standards themselves can be ill-defined, inconsistent or incorrect, because this would go too far.

However, the term “standard” suggests, that the implementation standard itself was developed by experts and is widely used. So, in this case, the application of those standards should generate some more confidence in the implementation of the TOE.

Approach 2: “Implicit evaluation of the applied standards.”

This approach refines approach 1. The developer action ALC_TAT.2.3D “The developer shall de-scribe the implementation standards to be applied.” is interpreted that it should make plausible to the evaluator that the implementation standards are well-defined, internally consistent and adequate for the purpose for which they are used. The evaluator action ALC_TAT.2.2E, where the evaluator has to confirm that the standards have been applied, is only applicable in a sensible way in this case.

Otherwise, during this evaluation task it turns out whether they are ill-defined, inconsistent respec-tively incorrect. As it is described in the draft for a work unit 5:ALC_TAT.2-4 for this evaluator ac-tion in the German national interpretation AIS 34, section 1.8.3.4.2 “Action ALC_TAT.2.2E”, the evaluator has to compare the provided implementation representation with the description of the ap-plied implementation standards and has to verify their use. So, if the implementation standards are ill-defined, inconsistent or incomplete, either the work unit cannot be completed successfully and fails or the evaluator will at least identify a potential vulnerability and has to investigate during the vulnerability analysis which consequences such an are ill-defined, inconsistent or incorrect standard has concerning the development of the TOE.

Approach 3: “Evaluation of the applied standards.”

The implementation standards (and possibly other development tools) are examined concerning their appropriateness for the development of the TOE. A list of acceptable tools and standards could be provided in order to minimise the supplementary work for the developer.

However, here is the problem whether the assurance in the product is improved corresponding to the extra work which has to be done by all concerned parties in the evaluation. In other comparable situations like the use of cryptographic algorithms and protocols the adherence to renowned stan-dards suffices to establish assurance in the product.

Given this situation we prefer approach 2 because it addresses the stated problem in a practicable way with-out sharpening of the requirements. Approach 1 is insufficient because there is the possibility that the re-quirements can be misinterpreted contrary to the objectives of the assurance family. In contrast approach 3 resolves the situation but requires in practice an inadequate amount of work.

Approach 2 is recommended for the draft interpretation.


The developer action ALC_TAT.2.3D “The developer shall describe the implementation standards to be applied.” is interpreted that it should make plausible to the evaluator that the implementation standards are



well-defined, internally consistent and adequate for the purpose for which they are used. The evaluator action ALC_TAT.2.2E, where the evaluator has to confirm that the standards have been applied, detects as a side effect also that the standards are applicable in a sensible way in this case.

Specific changes:

No specific changes are required.

Rationale:

The objectives statement for ALC_TAT refers to a desire to "prevent ill-defined, inconsistent or incorrect [implementation standards] from being used to develop the TOE". The reference to "incorrect" is not cur-rently represented in the content and presentation requirements. ALC_TAT.2 includes a developer action to provide information standards, but this is not supported by any content and presentation requirements. As the sole requirement is for the evaluator to check that the documented standards are applied, there seems to be no incentive for a developer to provide substantive documentation. But in practice this evaluator action leads to a “INCONCLUSIVE” or “FAIL” verdict, if the implementation standards are ill-defined, inconsistent or incorrect, because otherwise this evaluator action cannot be completed in a sensible way.

20.4 Draft interpretation for RI #99 RI #99: Configuration Items in the Absence of Explicit Scope

Type: Explanation/Clarification Source: US NI 338 Date: 06/02/2000

Status: Statement Source #: IWG #0338



CC Part #3 Reference: CC Part 3, Section 8.2 (ACM_CAP)

CEM Reference:

Reason: National Interpretation

Problem:

The ACM_CAP.2 elements are unclear for contexts where no Configuration Management Scope (ACM_SCP Family) components are included in the PP/ST.

Proposed Solution:

The following interprets the ACM_CAP.2 Component Developer Action Elements in contexts where no Con-figuration Management Scope (ACM_SCP Family) components are included in the PP/ST: In environments where a protection profile or security target does not explicitly have a statement of the items to be under con-figuration management, the ACM_CAP.2.2D element does not apply.

This problem could be corrected in the following fashion: 1.Delete ACM_CAP.2.2D. 2.Change ACM_CAP.2.3D to refer to a "configuration list" instead of "CM documentation". 3.Delete ACM_CAP.2.3C. 4.Change ACM_CAP.2.5C to refer to the "configuration list" instead of "CM documentation". 5.Change ACM_CAP.2.6C to refer to the "configuration list" instead of "the CM System". Alternatively, ACM_CAP.2.D could be deleted, and ACM_CAP.2.6C could be changed to refer to "The CM documenta-tion" instead of "The CM system". If these changes are not made, an application note should be added to clar-ify the interpretation of ACM_CAP.2.2D when ACM_SCP is not included. The CEM should also be re-viewed to determine any impact on the ACM_CAP work units for EAL2.



RI #99: Configuration Items in the Absence of Explicit Scope

The new contents elements introduced for the ACM_CAP.2 component all deal with uniquely identifying all items that make up the TOE and having their descriptions in a configuration list. This configuration list is contained in the CM documentation, which is required by ACM_CAP.2.3D. However, in the absence of ex-plicit scope, there are no requirements that configuration management be performed on any of these items. This viewpoint is supported by the Common Evaluation Methodology v1.0, which in the methodology for EAL2, ACM_CAP.2, does not impose any evaluator actions with respect to verifying use or presence of a CM system. In fact, the EAL2 work unit for ACM_CAP.2.6C (the only content and presentation element to refer to a CM system) requires a check only on the configuration list, not the CM system. The requirements of the CEM lead to the conclusion that the goal of ACM_CAP in the absence of ACM_SCP is to ensure that an unambiguous list of all configuration items that comprise the TOE be maintained, but not that there necessar-ily be a full blown CM system in place to manage changes to those components.

Table 43: RI #99: Configuration Items in the Absence of Explicit Scope

Discussion:


The discussion in the RI falsely assumes that the absence of a Scope-Component implies that no CM System is required. This is incorrect, because the CEM, Versions 1.0 and 2.2 state in section .6.4.1.2 “Application notes”:

“This component [i. e. ACM_CAP.2] contains an implicit evaluator action to determine that the CM system is being used.”

This shows that a CM system is to be used independently of the use of an ACM_SCP component.

Moreover, the discussion in the CEM, Version 2.2, for ACM_CAP.2 (for EAL2) shows that the configura-tion list identifies the items being maintained under configuration control (Paragraph 631 belonging to 2:ACM_CAP.2-4). ACM_CAP.2.4C (inserted by RI #3) states that the configuration list (and therefore the configuration control) shall at least include all configuration items that comprise the TOE. Even more explic-itly ACM_CAP.2.7C requires the CM system to uniquely identify all configuration items. This shows that ACM_CAP.2 (and higher) implicitly defines a minimal scope for the CM system, even if no ACM_SCP component is chosen.

Note: In version 3.0 of the CC (and CEM) the implicit definition of a scope will be removed from ACM_CAP (which will get a different name) and moved to ACM_SCP (which will also be renamed). The requirement for a minimal scope will then be explicitly taken care of by a dependency of all new “ACM_CAP” components to the new “ACM_SCP.1”. Note that this component will define weaker require-ments than the old ACM_SCP.1, so this approach will not contradict to RI #95, which removed a depend-ency of ACM_CAP components to ACM_SCP.1.


The assurance components ACM_CAP.2 and higher define an implicit minimal scope of the CM system even in absence of ACM_SCP. Therefore all elements and work units for ACM_CAP.2 are clear even in absence of ACM_SCP.

Specific changes:

None.



Rationale:

The discussion in the RI falsely assumes that the absence of a Scope-Component implies that no CM System is required. This is incorrect, because the CEM, Versions 1.0 and 2.2 state in section .6.4.1.2 “Application notes”:

“This component [i. e. ACM_CAP.2] contains an implicit evaluator action to determine that the CM system is being used.”

This shows that a CM system is to be used independently of the use of an ACM_SCP component.

Moreover, the discussion in the CEM, Version 2.2, for ACM_CAP.2 (for EAL2) shows that the configura-tion list identifies the items being maintained under configuration control (Paragraph 631 belonging to 2:ACM_CAP.2-4). ACM_CAP.2.4C (inserted by RI #3) states that the configuration list (and therefore the configuration control) shall at least include all configuration items that comprise the TOE. Even more explic-itly ACM_CAP.2.7C requires the CM system to uniquely identify all configuration items. This shows that ACM_CAP.2 (and higher) implicitly defines a minimal scope for the CM system, even if no ACM_SCP component is chosen.

20.5 Draft interpretation for RI #179 RI #179: When to meet ALC_DVS and ALC_LCD

Type: Explanation/Clarification Source: TNO Date: 07/10/2001

Status: Assigned Source #: TNO



CC Part #3 Reference: CC Part 3, Section 2.6.5 ALC

CEM Reference:

Reason: When to meet ALC_DVS and ALC_LCD

Problem:

RI#37 defines the timing of ACM in the evaluation: "While configuration management (CM) should ensure the integrity of the TOE from the early design stages through all subsequent maintenance actions” (CC, Part 3, paragraph 249), the ACM requirements specify only that CM is in place at the time of evaluation. Further-more, ACM does not contain any requirements related to the sponsor’s intention to apply CM in the future, after completion of evaluation."

Does this line of reasoning apply to ALC_DVS and ALC_LCD requirements as well? If not, when, during the development process should these requirements be met?

Proposed Solution:

Table 44: RI #179: When to meet ALC_DVS and ALC_LCD

Discussion:




The nature of the problem consists in the fact that the timing of ALC_DVS and ALC_LCD remains unclear in the CC. This problem is similar to the one for the family ACM which was solved by the final interpreta-tion for RI #37 as explained above.

The developer is required to give evidence that the security measures for protection of the TOE during de-velopment as well as the life-cycle model are in use not only during development but also for the mainte-nance of the TOE.

See for this following C&P elements:

ALC_DVS.1.2C

“The development security documentation shall provide evidence that these security measures are followed during the development and maintenance of the TOE.”

ALC_LCD.1.2C

“The life-cycle model shall provide for the necessary control over the development and maintenance of the TOE.”

As this can tested only by the site visit prior to the end of the evaluation, there is no practical measure for guaranteeing the fulfilment by independent parties.

Regarding the life-cycle model there is already the following application note (paragraph 385 in part 3 of CC version 2.2):

“Although life-cycle definition deals with the maintenance of the TOE and hence with aspects be-coming relevant after the completion of the evaluation, its evaluation adds assurance through an analysis of the life-cycle information for the TOE provided at the time of the evaluation.”

Therefore no additional new text is necessary with respect to ALC_LCD.

As regards development security, we see two possible approaches, the first one which inserts a clarification as for ACM by the final interpretation RI # 37 and a second one which leaves the CC and CEM unchanged.

Approach 1:“Clarification according to RI #37”

A clarification according to RI #37 is inserted in the CC which states that the security measures “be in place at the time of the evaluation”.

Approach 2: “No change”

With respect to ALC_DVS it is beyond the scope of the CC to define whether and how it is verified after the evaluation, that security measures are still in place. This is up to the national scheme.



Regarding the life-cycle model there is already the following application note (paragraph 385 in part 3 of CC version 2.2):

“Although life-cycle definition deals with the maintenance of the TOE and hence with aspects be-coming relevant after the completion of the evaluation, its evaluation adds assurance through an analysis of the life-cycle information for the TOE provided at the time of the evaluation.”

Therefore no additional new text is necessary with respect to ALC_LCD.

With respect to ALC_DVS, a clarification according to RI # 37 is inserted in the CC.

Specific changes:

The following application note is added (between the paragraphs 371 and 372 in part 3 of CC version 2.2):

Processing of RIs Transition guide for ALC, ACM, ADO and AGD Draft interpretation for RI # 183 Version 2.0, 22.01.2008


“Although development security deals with the maintenance of the TOE and hence with aspects be-coming relevant after the completion of the evaluation, the ALC_DVS requirements specify only that the development security measures be in place at the time of evaluation. Furthermore, ALC_DVS does not contain any requirements related to the sponsor’s intention to apply the development secu-rity measures in the future, after completion of the evaluation.”

Rationale:

The rationale is already contained in the interpretation.

20.6 Draft interpretation for RI # 183 RI #183: Life-cycle Specification

Type: Explanation/Clarification Source: Web Form Date: 07/26/2001

Status: Discussion Source #: Web Form




CEM Reference:

Reason: PP Development

Problem:

Various concerns have been raised regarding the need to specify the development life-cycle in a smart card product. The smart card product is a composite of a silicon integrated circuit, software, plastic card stock, personalization information, etc. Each of these components may be developed and supplied by different or-ganizations. The consequent evaluation of the final product depends on input from all of them. The related interpretations cited below emphasize that representative information from all phases of the development is necessary to perform the final evaluation. The concern is how to ensure this input without imposing an unre-alistically rigid life cycle definition nor an undue and impractical burden on the various manufacturers and providers to provide information for every evaluation.

As a further concern, various components of the final product may be subject to independent CC evaluations based on the design and capabiltiies represented up to that point in the development. That is, the basic silicon integrated circuit may undergo a CC evaluation based on compliance to an integrated circuit PP, the operating platform may be evaluated for compliance to a platform PP (which requires conformance to the integrated circuit PP). Finally, an application PP may be used as the basis for an evaluation of a complete product, again dependent on the preceeding PPs. It is not clear how to reuse theese evaluations in subsequent CC evaluations of the final product. This RI was discussed and agreed at a joint meeting of the SSVG, Eurosmart, eEurope TB3, SCSUG, and ECSEC on 17 July and is being submitted jointly by us all.

Proposed Solution:

Provide guidance on how to address life cycle issue in a composite smart card product.

Table 45: RI #183: Life-cycle Specification

Transition guide for ALC, ACM, ADO and AGD Processing of RIs Version 2.0, 22.01.2008 Draft interpretation for RI # 196


Discussion:


The nature of the problem consists in an adequate definition of a life-cycle model for composite evaluations concerning smart cards.

However, this problem seems to be too special to be treated in a general form by the CC / CEM. This issue should be handled by CC supporting documents. There are already several documents existing which are related to composite evaluations of smart card products.


The nature of the problem consists in an adequate definition of a life-cycle model for composite evaluations concerning smart cards.

However, this problem seems to be too special to be treated in a general form by the CC / CEM. This issue should be handled by CC supporting documents. There are already several documents existing which are related to composite evaluations of smart card products.

These documents can be downloaded from the URL

http://www.commoncriteriaportal.org/public/expert/

or

http://www.commoncriteriaportal.org/public/developer/

under the menu item “Supporting documents”.

Specific changes:


Rationale:

Contained in the interpretation.

20.7 Draft interpretation for RI # 196 RI #196: Splitting CM into separate parts

Type: Missing Material Source: CSE Date: 10/05/2001

Status: Discussion Source #: CSE



CC Part #3 Reference: CC Part 3, Section 8.2 (ACM_CAP)

CEM Reference:

Reason: Splitting CM into separate parts

Problem:

It has been recently suggested by vendors that the Configuration Management requirements for ACM_CAP ought to be split into two separate parts. One would be for the development stage of the TOE and one would

http://www.commoncriteriaportal.org/public/expert/

http://www.commoncriteriaportal.org/public/developer/

Processing of RIs Transition guide for ALC, ACM, ADO and AGD Draft interpretation for RI # 196 Version 2.0, 22.01.2008


RI #196: Splitting CM into separate parts

be for the completed product and delivery stage of the TOE. ISO 9000 practices indicate that this is a re-quirement for good business practice. The CM process for the development stage of a product is usually dif-ferent than the CM at the end of the product development which may use a Bill of Materials type of CM sys-tem or some other equally useful system to track the finished product. This is not sufficiently covered in Life Cycle (ALC) or Delivery Procedures (ADO) requirements.

Proposed Solution:

For those vendors who have separate CM systems for development and final product, it would be useful to document both. The evaluation priority should be on the finalized version since the finalized TOE is under evaluation. However, since an evaluation may impact both types of CM systems, development CM and final-ized version CM processes should be separately evaluated. A revision to the CEM would be required for this since the components should not be the same as the CM address completely different aspects of CM.

Table 46: RI #196: Splitting CM into separate parts

Discussion:


The nature of the problem consists in the fact that a developer could have separate CM systems for develop-ment and final product, a situation which seems to be good practice but which is not adequately addressed by the CC and CEM.

Given this situation we see two possible approaches, the first one which combines all existing CM processes to a whole CM system and a second one which separates the requirements in those which address the devel-opment and others which refer to the finalised product.

Approach 1: “Documentation of all existing CM processes as parts of a whole CM system”

For those developers who have separate CM systems for development and the final product, it would be useful to document both. For evaluation purposes, the separate CM systems should be regarded as parts of a comprehensive CM system which is addressed in the criteria. The evaluation priority should be on the finalised version since the finalised TOE is under evaluation.

This clarification could be in the form of an application note.

Approach 2: “Separation of requirements on two different CM systems referring to TOE development and TOE generation”

Since an evaluation may impact both types of CM systems, development CM and finalised version CM processes should be separately evaluated. A revision to the CEM would be required for this since the components should not be the same as the CM address completely different aspects of CM.

Approach 1 is the more flexible one since there are no two distinct CM systems required.



A developer who has separate CM systems for development and final product, should document both. For evaluation purposes these two CM systems are treated as separate parts of a whole CM system.

Specific changes:

The following application note is added (prior to the paragraph 232 in part 3 of CC version 2.2):



“For those developers who have separate CM systems for development and the final product, it would be useful to document both. For evaluation purposes, the separate CM systems should be re-garded as parts of a comprehensive CM system which is addressed in the criteria. The evaluation priority should be on the finalised version since the finalised TOE is under evaluation.”

Rationale:

Contained in the discussion.

20.8 Draft interpretation for RI #210 RI #210: Security and "Confidentiality"

Type: Missing Material Source: US Date: 03/25/2002

Status: Received Source #: US



CC Part #3 Reference: CC Part 3, Section 2.6.2 ADO

CEM Reference:

Reason: CCIMB-INTERP-016 incomplete

Problem:

After reading the CCIMB final interpretation, CCIMB-016 (Objective for ADO-DEL), a question arises with respect to the definition of the term "confidentiality." Given the modification to ADO_DEL, specifically, the addition of an application note following paragraph 290 in CC part 3, it appears the family is now concerned with broadening of the scope of ADO_DEL beyond just integrity. It now cites examples of technical meas-ures of security that incorporate not only integrity, but availability and confidentiality, as well.

With the introduction of this expanded security definition, it appears an ambiguity now exists with respect to confidentiality. Closer examination of the examples of confidentiality cited in the application note leads one to believe that confidentiality is concerned only with the confidentiality of delivery, i.e., concealing the act of delivery/distribution of materials by the developer to the consumer (or intended recipient).

Confidentiality, however, can take on an additional form that addresses protection of contents during delivery from unauthorized exposure, for example, preventing a would-be hacker from examining the contents of the delivery with the intent to conduct analysis on the source code or other material and take advantage of any learned/identified vulnerabilities.

Additionally, closer examination of the ADO_DEL family reveals that at the lower level of the hierarchy, the integrity, confidentiality, and availability security concerns are addressed. However, higher in the hierarchy (at ADO_DEL.2 and ADO_DEL.3), only the "integrity" aspect of security is employed. Therefore, to address the remaining security concerns, an expansion of the ADO_DEL hierarchy may now be necessary, i.e., a par-allel set of components, or a restructuring of the family similar to that shown below.

ADO_DEL.1 (General/overall security concern)

ADO_DEL.2 (Detection of Security Infractions)

* Integrity

* Confidentiality



RI #210: Security and "Confidentiality"

* Availability

ADO_DEL.3 (Prevention of Security Infractions)

* Integrity

* Confidentiality

* Availability

Proposed Solution:

Table 47: RI #210: Security and "Confidentiality"

Discussion:


The nature of the problem consists in the fact that CCIMB-INTERP-016 (= RI #16) seems to be incomplete with respect to the definition of the term "confidentiality".

Given this situation we see two possible approaches, the first one which leaves the clarification of the intro-duced problem to the PP/ST by adequate interpretation of “confidentiality” if required and a second one which calls for a restructuring of the family ADO_DEL as proposed by the request.

Approach 1: “Clarification by PP/ST”

The final interpretation for RI #16 leaves the definition of adequate security measures during deliv-ery to the PP/ST of the TOE and gives only examples which form they could have. So, there is no need in imposing further requirements by the family ADO_DEL.

Approach 2: “Restructuring of the family ADO_DEL”

In order to address different security concerns the hierarchy of the family ADO_DEL is expanded to a parallel set of components. The component ADO_DEL.1 addresses all different security concerns in general form, the higher levels either address integrity, confidentiality or availability.

Approach 1 is the more flexible approach according to the general principles of the CC and require no addi-tional work.


With respect to the remark in the request concerning stronger emphasis on integrity compared to the other security aspects on higher levels of ADO_DEL the following can be stated:

Integrity is a CC-specific aspect relevant for all kinds of TOEs because one needs guarantee that only the certified TOE is delivered to the customers. In contrast a requirement for confidentiality for example can arrive only from the specific nature of the TOE (e.g. if secret keys are delivered as part of the TOE). Such requirements need to be derived from the security goals of the TOE (i.e. PP/ST etc.) and cannot be generally predefined in CC-components for ADO_DEL.


The final interpretation for RI #16 leaves the definition of adequate security measures during delivery to the PP/ST of the TOE and gives only examples which form they could have. So, there is no need in imposing further requirements by the family ADO_DEL.



Specific changes:


Rationale:

With respect to the remark in the request concerning stronger emphasis on integrity compared to the other security aspects on higher levels of ADO_DEL the following can be stated:

Integrity is a CC-specific aspect relevant for all kinds of TOEs because one needs guarantee that only the certified TOE is delivered to the customers. In contrast a requirement for confidentiality for example can arrive only from the specific nature of the TOE (e.g. if secret keys are delivered as part of the TOE). Such requirements need to be derived from the security goals of the TOE (i.e. PP/ST etc.) and cannot be generally predefined in CC-components for ADO_DEL.