Evaluation Methodology for EAL5+ - Bundesamt f¼r Sicherheit in der

Application Notes and Interpretation of the Scheme (AIS)

AIS 34, Version 3

Date: 03.09.2009

Status: Effective

Subject: Evaluation Methodology for CC Assurance Classes for EAL5+ (CC v2.3 & v3.1) and EAL6 (CC v3.1)

Publisher: Certification body of the BSI in the context of the certification scheme

Distribution: Licensed evaluation facilities1,private confirmation bodies2,BSI internal,Internet site of BSI

1 All evaluators in the evaluation facilities licensed by BSI for evaluations in accordance with ITSEC or CC

2 All certifiers of the private confirmation bodies that issue confirmations in accordance with the German Signature Act.

Bundesamt für Sicherheit in der Informationstechnik AIS 34, Version 3Certification Scheme 2009

History of changes:

Version Date Status Changes Remarks

3 Draft 02 03.09.09 Draft Work Units for EAL 6 (CC 3.1 only) and Adaptation to Revision 3 of CC 3.1

2/139 AIS 34_3

AIS 34, Version 3 Bundesamt für Sicherheit in der Informationstechnik2009 Certification Scheme

Table of contents

0 Introduction ......................................................................................................................................... 6

0.1 Background .................................................................................................................................. 6

0.2 Specific References ...................................................................................................................... 6

0.3 Application notes and interpretation ............................................................................................. 6

0.4 Comments .................................................................................................................................... 8

0.5 Reference documents .................................................................................................................... 8

1 Supplementary methodology for CC v2.3 evaluation ........................................................................ 9

1.1 EAL5 evaluation ........................................................................................................................... 9

1.1.1 Introduction ........................................................................................................................... 9

1.1.2 Objectives .............................................................................................................................. 9

1.1.3 EAL5 evaluation relationship ................................................................................................ 9

1.1.4 EAL5 Configuration management activity .......................................................................... 11 1.1.4.1 Evaluation of CM automation (ACM_AUT.1) ............................................................. 11 1.1.4.2 Evaluation of CM capabilities (ACM_CAP.4) ............................................................. 12 1.1.4.3 Evaluation of CM scope (ACM_SCP.3) ....................................................................... 18

1.1.5 EAL5 Delivery and operation activity ................................................................................. 19 1.1.5.1 Evaluation of delivery (ADO_DEL.2) .......................................................................... 19 1.1.5.2 Evaluation of installation, generation and start-up (ADO_IGS.1) ................................ 19

1.1.6 EAL5 Development activity ................................................................................................ 20 1.1.6.1 Application notes .......................................................................................................... 20 1.1.6.2 Evaluation of the functional specification (ADV_FSP.3) ............................................. 22 1.1.6.3 Evaluation of the high-level design (ADV_HLD.3) ..................................................... 27 1.1.6.4 Evaluation of the implementation (ADV_IMP.2) ......................................................... 32 1.1.6.5 Evaluation of the TSF-internals (ADV_INT.1) ............................................................ 35 1.1.6.6 Evaluation of the low-level design (ADV_LLD.1) ....................................................... 38 1.1.6.7 Evaluation of representation correspondence (ADV_RCR.2) ....................................... 39 1.1.6.8 Evaluation of security policy modelling (ADV_SPM.3) .............................................. 42

1.1.7 EAL5 Guidance documents activity .................................................................................... 48 1.1.7.1 Application notes .......................................................................................................... 48 1.1.7.2 Evaluation of administrator guidance (AGD_ADM.1) ................................................. 48 1.1.7.3 Evaluation of user guidance (AGD_USR.1) ................................................................. 48

1.1.8 EAL5 Life cycle support activity ......................................................................................... 49 1.1.8.1 Evaluation of development security (ALC_DVS.1) ..................................................... 49 1.1.8.2 Evaluation of life-cycle definition (ALC_LCD.2) ........................................................ 50 1.1.8.3 Evaluation of tools and techniques (ALC_TAT.2) ....................................................... 53

1.1.9 EAL5 Test activity .............................................................................................................. 56 1.1.9.1 Application notes .......................................................................................................... 56 1.1.9.2 Evaluation of coverage (ATE_COV.2) ......................................................................... 58

AIS 34_3 3/139


1.1.9.3 Evaluation of depth (ATE_DPT.2) ............................................................................... 59 1.1.9.4 Evaluation of functional tests (ATE_FUN.1) ............................................................... 62 1.1.9.5 Evaluation of independent testing (ATE_IND.2) ......................................................... 63

1.1.10 EAL5 Vulnerability assessment activity ............................................................................ 64 1.1.10.1 Evaluation of covert channel analysis (AVA_CCA.1) ............................................... 65 1.1.10.2 Evaluation of misuse (AVA_MSU.2) ......................................................................... 70 1.1.10.3 Evaluation of strength of TOE security functions (AVA_SOF.1) .............................. 71 1.1.10.4 Evaluation of vulnerability analysis (AVA_VLA.3) .................................................. 72

1.2 Frequently used assurance components for EAL5 augmented evaluation .................................. 85

1.2.1 Life cycle support activity ................................................................................................... 85 1.2.1.1 Evaluation of development security (ALC_DVS.2) ..................................................... 85

1.2.2 Vulnerability assessment activity ........................................................................................ 89 1.2.2.1 Evaluation of misuse (AVA_MSU.3) ........................................................................... 89 1.2.2.2 Evaluation of vulnerability analysis (AVA_VLA.4) .................................................... 91

2 Supplementary methodology for CC v3.1 evaluation ...................................................................... 105

2.1 Evaluation of sub-activity (AVA_VAN.5) ............................................................................... 105

2.1.1 Objectives .......................................................................................................................... 105

2.1.2 Input .................................................................................................................................. 105

2.1.3 Application notes ............................................................................................................... 105

2.1.4 Action AVA_VAN.5.1E .................................................................................................... 105

2.1.5 Action AVA_VAN.5.2E .................................................................................................... 106

2.1.6 Action AVA_VAN.5.3E .................................................................................................... 107

2.1.7 Action AVA_VAN.5.4E .................................................................................................... 109

2.2 Evaluation of sub-activity (ADV_SPM.1) ................................................................................ 113

2.2.1 Objectives .......................................................................................................................... 113

2.2.2 Input .................................................................................................................................. 113


2.2.4 Action ADV_SPM.1.1E .................................................................................................... 114

2.3 Evaluation of sub-activity (ADV_TDS.5) ................................................................................ 118

2.3.1 Objectives .......................................................................................................................... 118

2.3.2 Input .................................................................................................................................. 118


2.3.4 Action ADV_TDS.5.1E ..................................................................................................... 119

2.3.5 Action ADV_TDS.5.2E ..................................................................................................... 125

2.4 Evaluation of sub-activity (ADV_IMP.2) ................................................................................. 127

2.4.1 Objectives .......................................................................................................................... 127

2.4.2 Input .................................................................................................................................. 127


2.4.4 Action ADV_IMP.2.1E ..................................................................................................... 127

2.5 Evaluation of sub-activity (ADV_INT.3) ................................................................................. 131

4/139 AIS 34_3


2.5.1 Objectives .......................................................................................................................... 131

2.5.2 Input .................................................................................................................................. 131


2.5.4 Action ADV_INT.3.1E ...................................................................................................... 132

2.5.5 Action ADV_INT.3.2E ...................................................................................................... 133

2.6 Evaluation of sub-activity (ATE_COV.3) ................................................................................ 135

2.6.1 Objectives .......................................................................................................................... 135

2.6.2 Input .................................................................................................................................. 135

2.6.3 Action ATE_COV.3.1E ..................................................................................................... 135

2.7 Evaluation of sub-activity (ATE_FUN.2) ................................................................................. 138

2.7.1 Objectives .......................................................................................................................... 138

2.7.2 Input .................................................................................................................................. 138


2.7.4 Action ATE_FUN.2.1E ..................................................................................................... 138

3 Annexes ........................................................................................................................................... 142

3.1 Evaluation Techniques and Tools ............................................................................................. 142

3.1.1 Semiformal and formal methods ........................................................................................ 142 3.1.1.1 Description of styles ................................................................................................... 142 3.1.1.2 Security policy models and styles ............................................................................... 146

AIS 34_3 5/139


0 Introduction

0.1 Background

1 Concerning evaluations according to CC version 2.3, the CEM version 2.3 includes no methodology for the assurance components related to EAL5 and above.

2 For evaluations according to EAL5 or above or if those components are used at a lower assurance level for augmentation, a methodology needs to be defined.

3 Concerning evaluations according to CC version 3.1, the CEM version 3.1 includes already the methodology for the assurance components related to EAL5, but the methodology for EAL6 and above is not completely defined.

4 For evaluations according to EAL6 or above or if those components are used at a lower assurance level for augmentation, a methodology still needs to be defined.

0.2 Specific References

5 1: CC version 2.3: part 3 [CC23]

2: CEM version 2.3 [CEM23]

3: CC version 3.1: part 3 [CC31]

4: CEM version 3.1 [CEM31]

5: CC Final Interpretations applicable to this document as of date 2009 [AIS32]

0.3 Application notes and interpretation

6 Concerning evaluations according to CC version 2.3, in the following table the right block indicates the assurance components covered by this document.

Methodology provided by [CEM23]

Methodology provided by this document

Assurance Class

Assurance Family

CC:EAL1

CC:EAL2

CC:EAL3

CC:EAL4

CC:EAL5

CC:EAL6

CC:EAL7

Class ACM: ACM_AUT - - - 1 1Configuration

ACM_CAP 1 2 3 4 4

Management ACM_SCP - - 1 2 3Class ADO: ADO_DEL - 1 1 2 2Delivery and operation

ADO_IGS 1 1 1 1 1

Class ADV: ADV_FSP 1 1 1 2 3Development ADV_HLD - 1 2 2 3

ADV_IMP - - - 1 2ADV_INT - - - - 1ADV_LLD - - - 1 1ADV_RCR 1 1 1 1 2ADV_SPM - - - 1 3

ClassAGD: AGD_ADM

1 1 1 1 1

Guidance documents

AGD_USR 1 1 1 1 1

Class ALC: ALC_DVS - - 1 1 1 2Life cycle ALC_FLR - - - - - - -Support ALC_LCD - - - 1 2

ALC_TAT - - - 1 2Class ATE: ATE_COV - 1 2 2 2Tests ATE_DPT - - 1 1 2

ATE_FUN - 1 1 1 1ATE_IND 1 2 2 2 2

6/139 AIS 34_3


Methodology provided by [CEM23]

Methodology provided by this document

Class AVA: AVA_CCA - - - - 1Vulnerability AVA_MSU - - 1 2 2 3assessment AVA_SOF - 1 1 1 1

AVA_VLA - 1 1 2 3 4

Table 1 Coverage of CC v23 assurance components

7 Concerning evaluations according to CC version 3.1, most of these assurance components are already covered by the CEM version 3.1. The following table indicates which of the assurance components given in the right block of the table above are addressed there. For the remaining components ADV_SPM.1 and AVA_VAN.5 of EAL5+ as chosen in the table above and additionally for ADV_TDS.5, ADV_IMP.2, ADV_INT.3, ATE_COV.3 and ATE_FUN.2 of EAL6 a methodology is provided by this document.

CC v2.3 assurance components

CC v3.1 coverage CEM v3.1 work units

ACM_AUT.1 ALC_CMC.4 Chap. 13.2.4

ACM_CAP.4 ALC_CMC.4, ALC_CMS.2 Chap. 13.2.4, Chap. 13.3.2ACM_SCP.3 ALC_CMS.5 Chap. 13.3.5ADO_DEL.2 ADO_DEL.1 Chap. 13.4.1ADO_IGS.1 AGD_PRE.1 Chap. 12.4.1ADV_FSP.3 ADV_FSP.5 Chap. 11.4.5ADV_HLD.3 ADV_TDS.4 Chap. 11.8.4ADV_IMP.2 ADV_IMP.1 Chap. 11.5.1ADV_INT.1 ADV_INT.2 Chap. 11.6.2

ADV_LLD.1 ADV_TDS.4 Chap. 11.8.4ADV_RCR.2 ADV_FSP.x, ADV_TDS.x,

ADV_IMP.x Chap. 11.4, 11.5, 11.8

ADV_SPM.3 ADV_SPM.1 Interpretation in this documentAGD_ADM.1 AGD_OPE.1 Chap. 12.3.1AGD_USR.1 AGD_OPE.1 Chap. 12.3.1ALC_DVS.1 ALC_DVS.1 Chap. 13.5.1ALC_LCD.2 ALC_LCD.2 Chap. 13.7.2ALC_TAT.2 ALC_TAT.2 Chap. 13.8.2ATE_COV.2 ATE_COV.2 Chap. 14.3.2ATE_DPT.2 ATE_DPT.3 Chap. 14.4.3ATE_FUN.1 ATE_FUN.1 Chap. 14.5.1ATE_IND.2 ATE_IND.2 Chap. 14.6.2AVA_CCA.1 AVA_VAN.x Chap. B.2.1.1, B2.1.4AVA_MSU.2 AGD_OPE.1, AGD_PRE.1,

AVA_VAN.xChap. 12.3.1, 12.4.1, 15.2.1–4, AVA_VAN.5: Interpretation in this document).

AVA_SOF.1 AVA_VAN.x, x depends on chosen strength of function

Chap. B.2.1.3

AVA_VLA.3 AVA_VAN.4, ADV_ARC.1 Chap. 15.2.4,Chap 11.3.1

ALC_DVS.2 ALC_DVS.2 Chap. 13.5.2AVA_MSU.3 AGD_OPE.1, AGD_PRE.1,

AVA_VAN.x12.3.1, 12.4.1, 15.2.1–4, AVA_VAN.5 Interpretation in this document

AVA_VLA.4 AVA_VAN.5, ADV_ARC.1 AVA_VAN.5: Interpretation in this document,ADV_ARC.1: Chap 11.3.1

Table 2 Coverage of CC v23 assurance components in CC v31

8 The following chapters outline the evaluation methodology as a supplement to the existing CEM version 2.3 [CEM23] and version 3.1 [CEM31].

AIS 34_3 7/139


0.4 Comments

9 The current code of practice in evaluations at EAL5+ and EAL6 level as well as available draft papers have been taken into account.

10 In chapter 1, all modifications compared to CEM version 2.3 [CEM23] are printed in bold letters. New work units are printed in bold letters, too.

11 Chapter 1 is structured according to EALs like [CEM23].

12 Note that a description of EAL5 for CC version 3.1 is not given in this document but in [CEM31].

13 For work units just referenced from EAL4, relevant final interpretations have to be taken into account, too.

14 Paragraphs indicated by an asterisk (*) give additional guidance to work units already defined in [CEM23] for EAL4.

15 For references to annexes A.x within chapter 1, see CEM version 2.3 [CEM23], annexes A.x.

0.5 Reference documents

CC31 Common Criteria for Information Technology Security EvaluationComprising Parts 1-3: Part 1: Introduction and General Model, Version 3.1 Revision 1, September 2006Part 2: Security Functional Requirements, Version 3.1 Revision 2, September 2007Part 3: Security Assurance Requirements, Version 3.1 Revision 2, September 2007

CEM31 Common Methodology for Information Technology Security EvaluationEvaluation Methodology, Version 3.1 Revision 2, September 2007

CC23 Common Criteria for Information Technology Security EvaluationComprising Parts 1-3: Part 1: Introduction and General Model, Version 2.3, August 2005Part 2: Security Functional Requirements, Version 2.3, August 2005Part 3: Security Assurance Requirements, Version 2.3, August 2005

CEM23 Common Methodology for Information Technology Security EvaluationEvaluation Methodology, Version 2.3, August 2005

BSI-7125 BSI-Certification: Procedural Description, BSI 7125

AIS 32 Application Notes and Interpretation of the Scheme, Taking over internationally agreed CC Final Interpretations in the German Certification Scheme, BSI

8/139 AIS 34_3


1 Supplementary methodology for CC v2.3 evaluation

16 In this chapter all references to CC or CEM refer to [CC23] or [CEM23], respectively.

1.1 EAL5 evaluation

1.1.1 Introduction

17 EAL5 provides a moderate to high level of assurance. The security functions are analysed using a functional specification, guidance documentation, the high-level and low-level design of the TOE, and the implementation to understand the security behaviour. Semiformal methods on the level of functional specification and high level design provide more preciseness and unambiguousness in specifications. The analysis is supported by independent testing of a subset of the TOE security functions, evidence of developer testing based on the functional specification, the high level design and the low level design, selective confirmation of the developer test results, analysis of strengths of the functions, evidence of a developer search for vulnerabilities, a covert channel analysis and an independent vulnerability analysis demonstrating resistance to moderate attack potential penetration attackers. Further assurance is gained through the use of a formal model of the TOE security policy and through the use of development environment controls, automated TOE configuration management, evidence of secure delivery procedures and the use of a standardized life-cycle model for TOE development and maintenance.

1.1.2 Objectives

18 The objective of this chapter is to define the minimal evaluation effort for achieving an EAL5 evaluation and to provide guidance on ways and means of accomplishing the evaluation.

1.1.3 EAL5 evaluation relationship

19 An EAL5 evaluation covers the following:

a) evaluation input task (Chapter 2 of CEM);

b) EAL5 evaluation activities comprising the following:

1) evaluation of the ST (Chapter 4 of CEM);

2) evaluation of the configuration management;

3) evaluation of the delivery and operation documents;

4) evaluation of the development documents;

5) evaluation of the guidance documents;

6) evaluation of the life cycle support;

7) evaluation of the tests;

8) testing;

9) evaluation of the vulnerability assessment;

c) evaluation output task (Chapter 2 of CEM).

20 The evaluation activities are derived from the EAL5 assurance requirements contained in the CC Part 3 and actual final interpretations as specifically indicated.

21 The ST evaluation is started prior to any TOE evaluation sub-activities since the ST provides the basis and context to perform these sub-activities. The ST evaluation used the assurance class ASE as refined by work units in CEM chapter 4 and associated final CC-interpretations.

AIS 34_3 9/139


22 The sub-activities comprising an EAL5 evaluation are described in this chapter. Although the sub-activities can, in general, be started more or less coincidentally, some dependencies between sub-activities have to be considered by the evaluator.

23 For guidance on dependencies see Annex A.4 of CEM [CEM23].

10/139 AIS 34_3


1.1.4 EAL5 Configuration management activity

24 The purpose of the configuration management activity is to assist the consumer in identifying the evaluated TOE, to ensure that configuration items are uniquely identified, and the adequacy of the procedures that are used by the developer to control and track changes that are made to the TOE. This includes details on what changes are tracked, how potential changes are incorporated, and the degree to which automation is used to reduce the scope for error.

25 The configuration management activity at EAL5 contains sub-activities related to the following components:

a) ACM_AUT.1;

b) ACM_CAP.4;

c) ACM_SCP.3Changes from EAL 4 (ACM_SCP.2) is the increased scope of that what is tracked by the CM system.

1.1.4.1 Evaluation of CM automation (ACM_AUT.1)

26 CEM for EAL4 is applicable.

27 Renumber work units: 4:ACM_AUT.1-x to 5:ACM_AUT.1-x, (x = 1...7).

AIS 34_3 11/139


1.1.4.2 Evaluation of CM capabilities (ACM_CAP.4)

1.1.4.2.1 Objectives

28 The objective of this sub-activity is to determine whether the developer has clearly identified the TOE and its associated configuration items, and whether the ability to modify these items is properly controlled.

29 CEM for EAL4 is applicable. Therefore, the work units for ACM_CAP.4 are re-printed in the following.

1.1.4.2.2 Input

30 The evaluation evidence for this sub-activity is:

a) the ST;

b) the TOE suitable for testing;

c) the configuration management documentation.

1.1.4.2.3 Evaluator actions

31 This sub-activity comprises one CC Part 3 evaluator action elements:

a) ACM_CAP.4.1E.

Action ACM_CAP.4.1E

ACM_CAP.4.1C(The reference for the TOE shall be unique to each version of the TOE.)

5:ACM_CAP.4-1 The evaluator shall check that the version of the TOE provided for evaluation is uniquely referenced.

32 The evaluator should use the developer’s CM system to validate the uniqueness of the reference by checking the configuration list to ensure that the configuration items are uniquely identified. Evidence that the version provided for evaluation is uniquely referenced may be incomplete if only one version is examined during the evaluation, and the evaluator should look for a referencing system that is capable of supporting unique references (e.g. use of numbers, letters or dates). However, the absence of any reference will normally lead to a fail verdict against this requirement unless the evaluator is confident that the TOE can be uniquely identified.

33 The evaluator should seek to examine more than one version of the TOE (e.g. during rework following discovery of a vulnerability), to check that the two versions are referenced differently.

ACM_CAP.4.2C (The TOE shall be labelled with its reference.)

5:ACM_CAP.4-2 The evaluator shall check that the TOE provided for evaluation is labelled with its reference.

34 The evaluator should ensure that the TOE contains a unique reference such that it is possible to distinguish different versions of the TOE. This could be achieved through labelled packaging or media, or by a label displayed by the operational TOE. This is to ensure that it would be possible for consumers to identify the TOE (e.g. at the point of purchase or use).

35 The TOE may provide a method by which it can be easily identified. For example, a software TOE may display its name and version number during the start up routine, or in response to a command line entry. A hardware or firmware TOE may be identified by a part number physically stamped on the TOE.

5:ACM_CAP.4-3 The evaluator shall check that the TOE references used are consistent.

12/139 AIS 34_3


36 If the TOE is labelled more than once then the labels have to be consistent. For example, it should be possible to relate any labelled guidance documentation supplied as part of the TOE to the evaluated operational TOE. This ensures that consumers can be confident that they have purchased the evaluated version of the TOE, that they have installed this version, and that they have the correct version of the guidance to operate the TOE in accordance with its ST. The evaluator can use the configuration list that is part of the provided CM documentation to verify the consistent use of identifiers.

37 The evaluator also verifies that the TOE reference is consistent with the ST.

38 For guidance on consistency analysis see Annex A.3 of CEM [CEM23].

ACM_CAP.4.3C (The CM documentation shall include a configuration list, a CM plan and an acceptance plan.)

5:ACM_CAP.4-4 The evaluator shall check that the CM documentation provided includes a configuration list.

39 A configuration list identifies the items being maintained under configuration control.

5:ACM_CAP.4-5 The evaluator shall check that the CM documentation provided includes a CM plan.

40 (*) The CM-Plan identified within the CM documentation should describe the CM approach for the TOE giving an overall understanding of how configuration management is applied, define activities, roles and responsibilities, procedures to be performed and an approach for version control.

5:ACM_CAP.4-6 The evaluator shall check that the CM documentation provided includes an acceptance plan.

41 (*) An acceptance plan describes the procedures that are to be used to ensure that the constituent parts of the TOE are of adequate quality prior to incorporation into the TOE. The acceptance plan should be identified within the CM documentation. Procedures for acceptance criteria should be identified within the acceptance plan.

ACM_CAP.4.4C(The configuration list shall uniquely identify all configuration items that comprise the TOE.)

5:ACM_CAP.4-7 The evaluator shall check that the configuration list uniquely identifies each configuration item.

42 The configuration list contains a list of the configuration items that comprise the TOE, together with sufficient information to uniquely identify which version of each item has been used (typically a version number). Use of this list will enable the evaluator to check that the correct configuration items, and the correct version of each item have been used during the evaluation.

ACM_CAP.4.5C (The configuration list shall describe the configuration items that comprise the TOE.)

5:ACM_CAP.4-8 The evaluator shall examine the configuration list to determine that it identifies the configuration items that comprise the TOE.

43 The minimum scope of configuration items to be covered in the configuration list is given by ACM_SCP.

ACM_CAP.4.6C (The CM documentation shall describe the method used to uniquely identify the configuration items.)

5:ACM_CAP.4-9 The evaluator shall examine the method of identifying configuration items to determine that it describes how configuration items are uniquely identified.

AIS 34_3 13/139


44 (*) Procedures should describe how the status of each configuration item can be tracked throughout the lifecycle of the TOE. The procedures may be detailed in the CM plan or throughout the CM documentation. The information included should describe:

a) the method how each configuration item is uniquely identified, such that it is possible to track versions of the same configuration item;

b) the method how configuration items are assigned unique identifiers and how they are entered into the CM system;

c) the method to be used to identify superseded versions of a configuration item;

d) the method used for identifying all tools used in the development of the TOE (including a process for changing the version of a tool and required procedures for regression testing within the development environment).

ACM_CAP.4.7C (The CM system shall uniquely identify all configuration items that comprise the TOE.)

5:ACM_CAP.4-10The evaluator shall examine the configuration items to determine that they are identified in a way that is consistent with the CM documentation.

45 Assurance that the CM system uniquely identifies all configuration items is gained by examining the identifiers for the configuration items. For both configuration items that comprise the TOE, and drafts of configuration items that are submitted by the developer as evaluation evidence, the evaluator confirms that each configuration item possesses a unique identifier in a manner consistent with the unique identification method that is described in the CM documentation.

ACM_CAP.4.8C (The CM plan shall describe how the CM system is used.)

5:ACM_CAP.4-11The evaluator shall examine the CM plan to determine that it describes how the CM system is used to maintain the integrity of the TOE configuration items.

46 The descriptions contained in a CM plan may include:

a) all activities performed in the TOE development environment that are subject to configuration management procedures (e.g. creation, modification or deletion of a configuration item);

b) the roles and responsibilities of individuals required to perform operations on individual configuration items (different roles may be identified for different types of configuration item (e.g. design documentation or source code));

c) the procedures that are used to ensure that only authorized individuals can make changes to configuration items;

d) the procedures that are used to ensure that concurrency problems do not occur as a result of simultaneous changes to configuration items;

e) the evidence that is generated as a result of application of the procedures. For example, for a change to a configuration item, the CM system might record a description of the change, accountability for the change, identification of all configuration items affected, status (e.g. pending or completed), and date and time of the change. This might be recorded in an audit trail of changes made or change control records;

f) the approach to version control and unique referencing of TOE versions (e.g. covering the release of patches in operating systems, and the subsequent detection of their application).

14/139 AIS 34_3


ACM_CAP.4.9C (The evidence shall demonstrate that the CM system is operating in accordance with the CM plan.)

5:ACM_CAP.4-12The evaluator shall check the CM documentation to ascertain that it includes the CM system records identified by the CM plan.

47 The output produced by the CM system should provide the evidence that the evaluator needs to be confident that the CM plan is being applied, and also that all configuration items are being maintained by the CM system as required by ACM_CAP.4.10C. Example output could include change control forms, or configuration item access approval forms.

5:ACM_CAP.4-13The evaluator shall examine the evidence to determine that the CM system is being used as it is described in the CM plan.

48 The evaluator should select and examine a sample of evidence covering each type of CM-relevant operation that has been performed on a configuration item (e.g. creation, modification, deletion, reversion to an earlier version) to confirm that all operations of the CM system have been carried out in line with documented procedures. The evaluator confirms that the evidence includes all the information identified for that operation in the CM plan. Examination of the evidence may require access to a CM tool that is used. The evaluator may choose to sample the evidence.

49 For guidance on sampling see Annex A.2 of CEM [CEM23].

50 Further confidence in the correct operation of the CM system and the effective maintenance of configuration items may be established by means of interview with selected development staff. In conducting such interviews, the evaluator should aim to gain a deeper understanding of how the CM system is used in practice as well as to confirm that the CM procedures are being applied as described in the CM documentation. Note that such interviews should complement rather than replace the examination of documentary evidence, and may not be necessary if the documentary evidence alone satisfies the requirement. However, given the wide scope of the CM plan it is possible that some aspects (e.g. roles and responsibilities) may not be clear from the CM plan and records alone. This is one case where clarification may be necessary through interviews.

51 It is expected that the evaluator will visit the development site in support of this activity.

52 For guidance on site visits see Annex A.5 of CEM [CEM23] and, if available, additional guidance of the Scheme.

ACM_CAP.4.10C (The CM documentation shall provide evidence that all configuration items have been and are being effectively maintained under the CM system.)

5:ACM_CAP.4-14The evaluator shall check that the configuration items identified in the configuration list are being maintained by the CM system.

53 The CM system employed by the developer should maintain the integrity of the TOE. The evaluator should check that for each type of configuration item (e.g. high-level design or source code modules) contained in the configuration list there are examples of the evidence generated by the procedures described in the CM plan. In this case, the approach to sampling will depend upon the level of granularity used in the CM system to control CM items. Where, for example, 10,000 source code modules are identified in the configuration list, a different sampling strategy should be applied compared to the case in which there are only 5, or even 1. The emphasis of this activity should be on ensuring that the CM system is being operated correctly, rather than on the detection of any minor error.


AIS 34_3 15/139


ACM_CAP.4.11C (The CM system shall provide measures such that only authorized changes are made to the configuration items.)

5:ACM_CAP.4-15The evaluator shall examine the CM access control measures described in the CM plan to determine that they are effective in preventing unauthorized access to the configuration items.

55 The evaluator may use a number of methods to determine that the CM access control measures are effective. For example, the evaluator may exercise the access control measures to ensure that the procedures could not be bypassed. The evaluator may use the outputs generated by the CM system procedures and already examined as part of the work unit 5:ACM_CAP.4-14. The evaluator may also witness a demonstration of the CM system to ensure that the access control measures employed are operating effectively.

56 The developer will have provided automated access control measures as part of the CM system and as such their suitability may be verified under the component ACM_AUT.1.

ACM_CAP.4.12C (The CM system shall support the generation of the TOE.)

5:ACM_CAP.4-16The evaluator shall check the CM documentation for procedures for supporting the generation of the TOE.

57 In this work unit the term generation applies to those processes adopted by the developer to progress the TOE from implementation to a state acceptable for delivery to the end customer.

58 The evaluator verifies the existence of generation support procedures within the CM documentation. The generation support procedures provided by the developer may be automated, and as such their existence may be verified under the component ACM_AUT.1.2C.

5:ACM_CAP.4-17The evaluator shall examine the TOE generation procedures to determine that they are effective in helping to ensure that the correct configuration items are used to generate the TOE.

59 The evaluator determines that by following the generation support procedures the version of the TOE expected by the customer (i.e. as described in the TOE ST and consisting of the correct configuration items) would be generated and delivered for installation at the customer site. For example, in a software TOE this may include checking that the procedures ensure that all source files and related libraries are included in the compiled object code.

60 The evaluator should bear in mind that the CM system need not necessarily possess the capability to generate the TOE, but should provide support for the process that will help reduce the probability of human error.

ACM_CAP.4.13C (The acceptance plan shall describe the procedures used to accept modified or newly created configuration items as part of the TOE.)

5:ACM_CAP.4-18The evaluator shall examine the acceptance procedures to determine that they describe the acceptance criteria to be applied to newly created or modified configuration items.

61 An acceptance plan describes the procedures that are to be used to ensure that the constituent parts of the TOE are of adequate quality prior to incorporation into the TOE. The acceptance plan should identify the acceptance procedures to be applied:

a) at each stage of the construction of the TOE (e.g. module, integration, system);

b) to the acceptance of software, firmware and hardware components;

c) to the acceptance of previously evaluated components.

16/139 AIS 34_3


62 The description of the acceptance criteria may include identification of:

a) developer roles or individuals responsible for accepting such configuration items;

b) any acceptance criteria to be applied before the configuration items are accepted (e.g. successful document review, or successful testing in the case of software, firmware or hardware).

AIS 34_3 17/139


1.1.4.3 Evaluation of CM scope (ACM_SCP.3)


63 The objective of this sub-activity is to determine whether the developer performs configuration management on the TOE implementation representation, design, tests, user and administrator guidance, the CM documentation, security flaws and development tools and related information.

1.1.4.3.2 Input


a) configuration item list.



a) ACM_SCP.3.1E.

Action ACM_SCP.3.1E

ACM_SCP.3.1C(The list of configuration items shall include the following: implementation representation; security flaws; development tools and related information; and the evaluation evidence required by the assurance components in the ST.)

5:ACM_SCP.3-1 The evaluator shall check that the configuration item list includes the set of items required by the CC.

66 The list should include at least the following:

a) the TOE implementation representation (i.e., the components or subsystems that compose the TOE). For a software-only TOE, the implementation representation may consist solely of source code; for a TOE that includes a hardware platform, the implementation representation may refer to a combination of software, firmware and a description of the hardware.

b) the evaluation evidence documentation required to by the assurance components in the ST.

c) the documentation used to record details of reported security flaws associated with the implementation (e.g., problem status reports derived from a developer's problem database).

d) 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 documentation. E.g. for a SW TOE: ‘development tools’ are usually programming languages and compiler and ‘related documentation’ comprises compiler and linker options.

18/139 AIS 34_3


1.1.5 EAL5 Delivery and operation activity

67 The purpose of the delivery and operation activity is to judge the adequacy of the documentation of the procedures used to ensure that the TOE is installed, generated, and started in the same way the developer intended it to be and that it is delivered without modification. This includes both the procedures taken while the TOE is in transit, as well as the initialisation, generation, and start-up procedures.

68 The delivery and operation activity at EAL5 contains sub-activities related to the following components:

a) ADO_DEL.2;

b) ADO_IGS.1.

1.1.5.1 Evaluation of delivery (ADO_DEL.2)

69 CEM for EAL4 is applicable under consideration of CC Interpretation 128.

1.1.5.2 Evaluation of installation, generation and start-up (ADO_IGS.1)


71 Renumber work units: 4:ADO_IGS.1-x to 5:ADO_IGS.1-x, (x = 1...2)

AIS 34_3 19/139


1.1.6 EAL5 Development activity

72 The purpose of the development activity is to assess the design documentation in terms of its adequacy to understand how the TSF provides the security functions of the TOE. This understanding is achieved through examination of increasingly refined descriptions of the TSF design documentation. Design documentation consists of a functional specification (which specifies the security functionality and describes the external interfaces of the TOE), a high-level design (which describes the architecture of the TOE in terms of internal subsystems), a low-level design (which describes the architecture of the TOE in terms of internal modules) and an architectural description (outlining the modularity of the design). Additionally, there is an implementation description (a source code level description), a security policy model (which describes the security policies enforced by the TOE) and a representation correspondence (which maps representations of the TOE to one another in order to ensure consistency).

73 The development activity at EAL5 contains sub-activities related to the following components:

a) ADV_FSP.3Changes from EAL 4 (ADV_FSP.2) is the semiformal style of the FSP;

b) ADV_HLD.3Changes from EAL 4 (ADV_HLD.2) is the semiformal style and increased completeness of interface description;

c) ADV_IMP.2Changes from EAL 4 (ADV_IMP.1) is the implementation representation of the entire TSF;

d) ADV_INT.1New component compared to EAL4 which deals with the internal structuring of the TSF;

e) ADV_LLD.1;

f) ADV_RCR.2Changes from EAL 4 (ADV_RCR.1) is the semiformal analysis from FSP to HLD;

g) ADV_SPM.3Changes from EAL 4 (ADV_SPM.1) is the formal TOE security policy model.

1.1.6.1 Application notes

74 The CC requirements for design documentation are levelled by formality. The CC considers a document’s degree of formality (that is, whether it is informal, semiformal or formal) to be hierarchical. An informal document is one that is expressed in a natural language (the methodology does not dictate the specific language that must be used; that issue is left for the scheme). A semiformal document is written in a restricted-syntax language, though not with the rigor of mathematics. A formal document is written in a mathematical language. The following paragraphs differentiate the contents of the different semiformal documents.

75 A semiformal functional specification comprises a characterization of all security functions required to fulfil the SFRs of the ST and their externally visible interfaces to the TSF. For example, if an operating system presents the user with a means of self-identification, of creating files, of modifying or deleting files, of setting permissions defining what other users may access files, and of communicating with remote machines, its functional specification would contain semiformal characterizations of each of these functions. If there are also audit functions that detect and record the occurrences of such events, characterizations of these audit functions would also be expected to be part of the functional specification; while these functions are technically not directly invoked by the

20/139 AIS 34_3


user at the external interface, they certainly are affected by what occurs at the user’s external interface. As test-coverage analysis is related to the functional specification, completeness of this specification is of importance in an evaluation process.

76 A semiformal high-level design is a characterization of the TOE expressed in terms of sequences of actions that occur in each subsystem in response to stimulus at its interface. For example, a firewall might be composed of subsystems that deal with packet filtering, with remote administration, with auditing, and with connection-level filtering. The high-level design of the firewall would characterize the actions that are taken, in terms of what actions each subsystem takes when an incoming packet arrives at the firewall.

77 An informal low-level design is a characterization of the TOE expressed in terms of sequences of actions that occur in a module in response to stimulus at its interface. For example, a virtual private networking subsystem might be composed of modules that create session keys, that encrypt traffic, that decrypt traffic, and that decide whether traffic needs to be encrypted. The low-level design of the encryption module would characterize the steps that the module takes when it receives a traffic stream that is to be encrypted.

78 While the functional specification characterizes the functions and services, the model characterizes the policies enforced by those functions and services available at the external interface. For example, access control policies would characterize the resources being protected and the conditions that must be met for access to be granted; audit policies would characterize the TOE’s auditable events, identifying both those that are selectable by the administrator and those that are always audited; identification and authentication policies would characterize how users are identified, how those claimed identities are authenticated, and any rules affecting how identities are authenticated (e.g. users on the corporate intranet need no authentication, while external users are authenticated with one-time passwords).

79 The semiformal demonstration of correspondence entails a structured approach. This approach will reduce ambiguity through its well-defined structure; yet it need not be as rigorous as a mathematical correspondence.

AIS 34_3 21/139


1.1.6.2 Evaluation of the functional specification (ADV_FSP.3)


80 The objective of this sub-activity is to determine whether the developer has provided an adequate description of all security functions of the TOE, whether the security functions provided by the TOE are sufficient to satisfy the security functional requirements of the ST, and whether all necessary explanatory text is provided.

1.1.6.2.2 Input


a) the ST;

b) the functional specification;

c) the user guidance;

d) the administrator guidance.


82 This sub-activity comprises two CC Part 3 evaluator action elements:

a) ADV_FSP.3.1E;

b) ADV_FSP.3.2E.

Action ADV_FSP.3.1E

(The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.)

ADV_FSP.3.1C(The functional specification shall describe the TSF and its external interfaces using a semiformal style, supported by informal, explanatory text where appropriate.)

5:ADV_FSP.3-1 The evaluator shall examine the functional specification to determine that the semiformal notation used for describing the TSF and its external interfaces is defined or referenced.

83 A semiformal notation can be either defined by the sponsor or a corresponding standard be referenced.

84 The evaluator should provide a mapping of security functions and their interfaces outlining in what part of the documentation a function or interface is semiformal described and what notation is used.

5:ADV_FSP.3-2 The evaluator shall examine all semiformal notations used to make sure that they are of a semiformal style and to justify the appropriateness of the manner how the semiformal notations are used for the TOE.

85 A semiformal notation uses a restricted syntax. The syntax of all semiformal notations used in the functional specification shall be defined or a corresponding standard be referenced.

86 The evaluator shall verify that the semiformal notations used for expressing the functional specification is capable of expressing features relevant to security. In order to determine this, the evaluator can refer to the TSS part of the ST and compare the TSF security features stated in the ST and those described in the FSP using the semiformal notations.

87 For details on semiformal methods refer to Annex 3.1.1 ‘Semiformal and formalmethods’.

88 Information on the developer’s tools could be supportive for the evaluator’s tasks.

22/139 AIS 34_3


5:ADV_FSP.3-3 The evaluator shall examine the functional specification to determine that it contains all necessary informal explanatory text.

89 Supporting narrative descriptions are necessary for those portions of the functional specification that are difficult to understand only from the semiformal (or formal, if any) description (for example, to make clear the meaning of any semiformal or formal notation). Any restrictions placed upon the syntax shall be clearly explained.

90 Informal explanatory text supporting semiformal or formal descriptions has to be linked to the relevant semiformal or formal parts.

ADV_FSP.3.2C(The functional specification shall be internally consistent.)

5:ADV_FSP.3-4 The evaluator shall examine the functional specification to determine that it is internally consistent.

91 The evaluator validates the functional specification by ensuring that the descriptions of the interfaces making up the TSFI are consistent with the descriptions of the functions of the TSF.

92 (*) The informal explanatory text supporting semiformal or formal descriptions has to be explicitly part of the consistency check.


ADV_FSP.3.3C(The functional specification shall describe the purpose and method of use of all external TSF interfaces, providing complete details of all effects, exceptions and error messages.)

5:ADV_FSP.3-5 The evaluator shall examine the functional specification to determine that it identifies all of the external TOE security function interfaces.

94 The term external refers to that which is visible to the user. External interfaces to the TOE are either direct interfaces to the TSF or interfaces to non-TSF portions of the TOE. However, these non-TSF interfaces might have eventual access to the TSF. These external interfaces that directly or indirectly access the TSF collectively make up the TOE security function interface (TSFI). Figure 1.1 shows a TOE with TSF (shaded) portions and non-TSF (empty) portions. This TOE has three external interfaces: interface c is a direct interface to the TSF; interface b is an indirect interface to the TSF; and interface a is an interface to non-TSF portions of the TOE. Therefore, interfaces b and c make up the TSFI.

95 It should be noted that all security functions reflected in the functional requirements of CC Part 2 (or in extended components thereof) will have some sort of externally-visible manifestation. While not all of these are necessarily interfaces from which the security function can be tested, they are all externally-visible to some extent and must therefore be included in the functional specification.

96 For guidance on determining the TOE boundary see Annex A.6 of CEM [CEM23].

AIS 34_3 23/139


Figure 1.1 TSF Interfaces

5:ADV_FSP.3-6 The evaluator shall examine the functional specification to determine that it describes all of the external TOE security function interfaces.

97 For a TOE that has no threat of malicious users (i.e. FPT_PHP, FPT_RVM, and FPT_SEP are rightfully excluded from its ST), the only interfaces that are specified in the functional specification (and expanded upon in the other TSF representation descriptions) are those to and from the TSF. The absence of FPT_PHP, FPT_RVM, and FPT_SEP presumes there is no concern for any sort of bypassing of the security features; therefore, there is no concern with any possible impact that other interfaces might have on the TSF.

98 On the other hand, if the TOE has a threat of malicious users or bypass (i.e. FPT_PHP, FPT_RVM, and FPT_SEP are included in its ST), all external interfaces are specified in the functional specification, but only to the extent that the effect of each is made clear: interfaces to the security functions (i.e. interfaces b and c in Figure 1.1) are completely specified, while other interfaces are described only to the extent that it is clear that the TSF is inaccessible through the interface (i.e. that the interface is of type a, rather than b in Figure 1.1). The inclusion of FPT_PHP, FPT_RVM, and FPT_SEP implies a concern that all interfaces might have some effect upon the TSF. Because each external interface is a potential TSF interface, the functional specification must contain a description of each interface in sufficient detail so that an evaluator can determine whether the interface is security relevant.

99 Some architectures lend themselves to readily provide this interface description in sufficient detail for groups of external interfaces. For example, a kernel architecture is such that all calls to the operating system are handled by kernel programs; any calls that might violate the TSP must be called by a program with the privilege to do so. All programs that execute with privilege must be included in the functional specification. Any program external to the kernel that executes without privilege is incapable of affecting the TSP (i.e. such programs are interfaces of type a, rather than b in Figure 1.1) and may, therefore, be excluded from the functional specification. It is worth noting that, while the evaluator’s understanding of the interface description can be expedited in cases where there is a kernel architecture, such an architecture is not necessary.

5:ADV_FSP.3-7 The evaluator shall examine the presentation of the TSFI to determine that it adequately and correctly describes the complete behaviour of the TOE at each external interface describing effects, exceptions and error messages.

100 In order to assess the adequacy and correctness of an interface’s presentation, the evaluator uses the functional specification, the TOE summary specification of the ST, and the user and administrator guidance to assess the following factors:

24/139 AIS 34_3


a) All security relevant user input parameters (or a characterization of those parameters) should be identified. For completeness, parameters outside of direct user control should be identified if they are usable by administrators.

b) Complete security relevant behaviour described in the reviewed guidance should be reflected in the description of semantics in the functional specification. This should include an identification of the behaviour in terms of events and the effect of each event. For example, if an operating system provides a rich file system interface, where it provides a different error code for each reason why a file is not opened upon request, the functional specification should explain that a file is either opened upon request, or else that the request is denied, along with a listing of the reasons why the open request might be denied (e.g. access denied, no such file, file is in use by another user, user is not authorized to open the file after 5pm, etc.). It would be insufficient for the functional specification merely to explain that a file is either opened upon request, or else that an error code is returned. The description of the semantics should include how the security requirements apply to the interface (e.g. whether the use of the interface is an auditable event and, if so, the information that can be recorded).

c) All interfaces are described for all possible modes of operation. If the TSF provides the notion of privilege, the description of the interface should explain how the interface behaves in the presence or absence of privilege.

d) The information contained in the descriptions of the security relevant parameters and syntax of the interface should be consistent across all documentation.

101 Verification of the above is done by reviewing the functional specification and the TOE summary specification of the ST, as well as the user and administrator guidance provided by the developer. For example, if the TOE were an operating system and its underlying hardware, the evaluator would look for discussions of user-accessible programs, descriptions of protocols used to direct the activities of programs, descriptions of user-accessible databases used to direct the activities of programs, and for user interfaces (e.g. commands, application program interfaces) as applicable to the TOE under evaluation; the evaluator would also ensure that the processor instruction set is described.

102 This review might be iterative, such that the evaluator would not discover the functional specification to be incomplete until the design, source code, or other evidence is examined and found to contain parameters or error messages that have been omitted from the functional specification.

103 The level of details shall also support the testing approach to meet the ATE_COV requirement.

ADV_FSP.3.4C(The functional specification shall completely represent the TSF.)

5:ADV_FSP.3-8 The evaluator shall examine the functional specification to determine that the TSF is fully represented.

104 In order to assess the completeness of the TSF representation, the evaluator consults the TOE summary specification of the ST, the user guidance, and the administrator guidance. None of these should describe security functions that are absent from the TSF presentation of the functional specification.

ADV_FSP.3.5C(The functional specification shall include rationale that the TSF is completely represented.)

5:ADV_FSP.3-9 The evaluator shall examine the functional specification to determine that it contains a convincing argument that the TSF is completely represented by the functional specification.

AIS 34_3 25/139


105 The evaluator determines that there is a convincing argument that there are no interfaces of the TSFI that are missing from the functional specification. This may include a description of the procedure or methodology that the developer used to ensure that all external interfaces are covered. The argument would prove inadequate if, for example, the evaluator discovers commands, parameters, error messages, or other interfaces to the TSF in other evaluation evidence, yet absent from the functional specification.

Action ADV_FSP.3.2E

(The evaluator shall determine that the functional specification is an accurate and complete instantiation of the TOE security functional requirements.)

5:ADV_FSP.3-10 The evaluator shall examine the functional specification to determine that it is a complete instantiation of the TOE security functional requirements.

106 (*) To ensure that all ST security functional requirements are covered by the functional specification, the evaluator may construct a map between the ST security functional requirements and the functional specification ensuring that all security functional requirements can be mapped onto aspects of the security functions or their TSFI presentations in the functional specification.

5:ADV_FSP.3-11 The evaluator shall examine the functional specification to determine that it is an accurate instantiation of the TOE security functional requirements.

107 For each (*) specification of a security function or each interface to a security function with specific characteristics, the detailed information in the functional specification must be exactly as it is specified in the ST. For example, if the ST contains user authentication requirements that the password length must be eight characters, the TOE must have eight-character passwords; if the functional specification describes six-character fixed length passwords, the functional specification would not be an accurate instantiation of the requirements.

108 (*) Further example: The ST may specify a requirement on Residual Information Protection (FDP_RIP) in terms of an event and an object; FSP shall specify (i) the event in the operation of the TOE, (ii) how the relevant object is related to the event and (iii) the method of deletion. If the FSP shows that the object is not related to the event or if the method of deletion is not applicable to the object or the event, the functional specification would not be an accurate instantiation of the requirements.

109 For each interface in the functional specification that operates on a controlled resource, the evaluator determines whether it returns an error code that indicates a possible failure due to enforcement of one of the security requirements; if no error code is returned, the evaluator determines whether an error code should be returned. For example, an operating system might present an interface to OPEN a controlled object. The description of this interface may include an error code that indicates that access was not authorized to the object. If such an error code does not exist, the evaluator should confirm that this is appropriate (because, perhaps, access mediation is performed on READs and WRITEs, rather than on OPENs).

26/139 AIS 34_3


1.1.6.3 Evaluation of the high-level design (ADV_HLD.3)


110 The objective of this sub-activity is to determine whether the high-level design provides a description of the TSF in terms of major structural units (i.e. subsystems), provides a description of the interfaces to these structural units, and is a correct realisation of the functional specification.

1.1.6.3.2 Input


a) the ST;


c) the high-level design.



a) ADV_HLD.3.1E;

b) ADV_HLD.3.2E.

Action ADV_HLD.3.1E

ADV_HLD.3.1C(The presentation of the high-level design shall be semiformal.)

5:ADV_HLD.3-1 The evaluator shall examine the high level design to determine that the semiformal notation used for describing the structure of the TSF, the security functionality of all subsystems and the interfaces of all subsystems is defined or referenced.

113 A semiformal notation can be either defined by the sponsor or a corresponding standard be referenced.

114 The evaluator should provide a mapping of subsystems, their security functionality and their interfaces outlining in what part of the documentation a subsystem or interface is semiformal described and what notation is used.

5:ADV_HLD.3-2 The evaluator shall examine all semiformal notations used to make sure that they are of a semiformal style and to justify the appropriateness of the manner how the semiformal notations are used for the TOE.

115 A semiformal notation uses a restricted syntax. The syntax of all semiformal notations used in the high-level design shall be defined or a corresponding standard be referenced.

116 The evaluator shall verify that the semiformal notations used for expressing the high-level design is capable of expressing features relevant to security. In order to determine this, the evaluator can refer to the FSP and to the TSS part of the ST and compare the TSF security features stated in the FSP and in the ST and those described in the HLD using the semiformal notations.

117 For details on semiformal methods refer to Annex 3.1.1 ‘Semiformal and formalmethods’.

118 Information on the developer’s tools could be supportive for the evaluator’s tasks.

5:ADV_HLD.3-3 The evaluator shall examine the high-level design to determine that it contains all necessary informal explanatory text.

119 Supporting narrative descriptions are necessary for those portions of the high level design that are difficult to understand only from the semiformal (or formal, if any)

AIS 34_3 27/139


description (for example, to make clear the meaning of any semiformal or formal notation). Any restrictions placed upon the syntax must be clearly explained.

120 Informal explanatory text supporting semiformal or formal descriptions has to be linked to the relevant semiformal or formal parts.

ADV_HLD.3.2C(The high-level design shall be internally consistent.)

5:ADV_HLD.3-4 The evaluator shall examine the presentation of the high-level design to determine that it is internally consistent.


122 The evaluator validates the subsystem interface specifications by ensuring that the interface specifications are consistent with the description of the purpose of the subsystem.

123 (*) The informal explanatory text supporting semiformal or formal descriptions has to be explicitly part of the consistency check.

124 The use of appropriate tools supporting the semiformal notation used in the high-level design could be efficient for the evaluators tasks.

125 ADV_HLD.3.3C(The high-level design shall describe the structure of the TSF in terms of subsystems.)

5:ADV_HLD.3-5 The evaluator shall examine the high-level design to determine that the TSF is described in terms of subsystems.

126 With respect to the high-level design, the term subsystem refers to large, related units (such as memory-management, file-management, process-management). Breaking a design into the basic functional areas aids in the understanding of the design.

127 The primary purpose for examining the high-level design is to aid the evaluator’s understanding of the TOE. The developer’s choice of subsystem definition, and of the grouping of TSFs within each subsystem, are an important aspect of making the high-level design useful in understanding the TOE’s intended operation. As part of this work unit, the evaluator should make an assessment as to the appropriateness of the number of subsystems presented by the developer, and also of the choice of grouping of functions within subsystems. The evaluator should ensure that the decomposition of the TSF into subsystems is sufficient for the evaluator to gain a high-level understanding of how the functionality of the TSF is provided.

128 The subsystems used to describe the high-level design need not be called “subsystems”, but should represent a similar level of decomposition. For example, the design may be decomposed using “layers” or “managers”.

129 There may be some interaction between the choice of subsystem definition and the scope of the evaluator’s analysis. A discussion on this interaction is found following work unit 5:ADV_HLD.3-12

ADV_HLD.3.4C(The high-level design shall describe the security functionality provided by each subsystem of the TSF.)

5:ADV_HLD.3-6 The evaluator shall examine the high-level design to determine that it describes the security functionality of each subsystem.

130 The security functional behaviour of a subsystem is a description of what the subsystem does. This should include a description of any actions that the subsystem may be directed to perform through its functions and the effects the subsystem may have on the security state of the TOE (e.g. changes in subjects, objects, security databases).

ADV_HLD.3.5C(The high-level design shall identify any underlying hardware, firmware, and/or

28/139 AIS 34_3


software required by the TSF with a presentation of the functions provided by the supporting protection mechanisms implemented in that hardware, firmware, or software.)

5:ADV_HLD.3-7 The evaluator shall check the high-level design to determine that it identifies all hardware, firmware, and software required by the TSF.

131 If the ST contains no security requirements for the IT environment, this work unit is not applicable and is therefore considered to be satisfied.

132 If the ST contains the optional statement of security requirements for the IT environment, the evaluator compares the list of hardware, firmware, or software required by the TSF as stated in the high-level design to the statement of security requirements for the IT environment to determine that they agree. The information in the ST characterizes the underlying abstract machine on which the TOE will execute.

133 If the high-level design includes security requirements for the IT environment that are not included in the ST, or if they differ from those included in the ST, this inconsistency is assessed by the evaluator under Action ADV_HLD.3.2E.

5:ADV_HLD.3-8 The evaluator shall examine the high-level design to determine that it includes a presentation of the functions provided by the supporting protection mechanisms implemented in the underlying hardware, firmware, or software.

134 If the ST contains no security requirements for the IT environment, this work unit is not applicable and is therefore considered to be satisfied.

135 The presentation of the functions provided by the underlying abstract machine on which the TOE executes need not be at the same level of detail as the presentation of functions that are part of the TSF. The presentation should explain how the TOE uses the functions provided in the hardware, firmware, or software that implement the security requirements for the IT environment that the TOE is dependent upon to support the TOE security objectives.

136 The statement of security requirements for the IT environment may be abstract, particularly if it is intended to be capable of being satisfied by a variety of different combinations of hardware, firmware, or software. As part of the Tests activity, where the evaluator is provided with at least one instance of an underlying machine that is claimed to satisfy the security requirements for the IT environment, the evaluator can determine whether it provides the necessary security functions for the TOE. This determination by the evaluator does not require testing or analysis of the underlying machine; it is only a determination that the functions expected to be provided by it actually exist.

ADV_HLD.3.6C(The high-level design shall identify all interfaces to the subsystems of the TSF.)

5:ADV_HLD.3-9 The evaluator shall check that the high-level design identifies the interfaces to the TSF subsystems.

137 The high-level design includes, for each subsystem, the name of each of its entry points.

ADV_HLD.3.7C(The high-level design shall identify which of the interfaces to the subsystems of the TSF are externally visible.)

5:ADV_HLD.3-10 The evaluator shall check that the high-level design identifies which of the interfaces to the subsystems of the TSF are externally visible.

138 As discussed under work unit 5:ADV_FSP.3-5, external interfaces (i.e. those visible to the user) may directly or indirectly access the TSF. Any external interface that accesses the TSF either directly or indirectly is included in the identification for this work unit. External interfaces that do not access the TSF need not be included.

ADV_HLD.3.8C(The high-level design shall describe the purpose and method of use of all

AIS 34_3 29/139


interfaces to the subsystems of the TSF, providing complete details of all effects, exceptions and error messages.)

5:ADV_HLD.3-11 The evaluator shall examine the high-level design to determine that it describes the interfaces to each subsystem in terms of their purpose and method of use, and provides complete details of all effects, exceptions and error messages, entirely.

139 The high-level design should include descriptions in terms of the purpose and method of use for all interfaces of each subsystem. Descriptions shall be provided in detail for all interfaces. The evaluator needs to understand the nature of the interactions between subsystems to establish confidence that the TOE design is sound.

140 Detailed descriptions would include details of any input and output parameters, of the effects of the interface, and of any exceptions or error messages it produces. In the case of external interfaces, the required description is included in the functional specification and can be referenced in the high-level design without replication.

141 The level of details shall also support the testing approach to meet the ATE_DPT requirement.

ADV_HLD.3.9C(The high-level design shall describe the separation of the TOE into TSP-enforcing and other subsystems.)

5:ADV_HLD.3-12 The evaluator shall check that the high-level design describes the separation of the TOE into TSP-enforcing and other subsystems.

142 The TSF comprises all the parts of the TOE that have to be relied upon for enforcement of the TSP. Because the TSF includes both functions that directly enforce the TSP, and also those functions that, while not directly enforcing the TSP, contribute to the enforcement of the TSP in a more indirect manner, all TSP-enforcing subsystems are contained in the TSF. Subsystems that play no role in TSP enforcement are not part of the TSF. An entire subsystem is part of the TSF if any portion of it is.

143 As explained under work unit 5:ADV_HLD.3-5, the developer’s choice of subsystem definition, and of the grouping of TSFs within each subsystem, are important aspects of making the high-level design useful in understanding the TOE’s intended operation. However, the choice of grouping of TSFs within subsystems also affects the scope of the TSF, because a subsystem with any function that directly or indirectly enforces the TSP is part of the TSF. While the goal of understandability is important, it is also helpful to limit the extent of the TSF so as to reduce the amount of analysis that is required. The two goals of understandability and scope reduction may sometimes work against each other. The evaluator should bear this in mind when assessing the choice of subsystem definition.

Action ADV_HLD.3.2E

(The evaluator shall determine that the high-level design is an accurate and complete instantiation of the TOE security functional requirements.)

5:ADV_HLD.3-13 The evaluator shall examine the high-level design to determine that it is an accurate instantiation of the TOE security functional requirements.

144 The evaluator analyses the high-level design for each TOE security function to ensure that the function is accurately described. The evaluator also ensures that the function has no dependencies that are not included in the high-level design.

145 The evaluator also analyses the security requirements for the IT environment in both the ST and the high-level design to ensure that they agree. For example, if the ST includes TOE security functional requirements for the storage of an audit trail, and the high-level design stated that audit trail storage is provided by the IT environment, then the high-level design is not an accurate instantiation of the TOE security functional requirements.

30/139 AIS 34_3


146 The evaluator should validate the subsystem interface specifications by ensuring that the interface specifications are consistent with the description of the purpose of the subsystem.

5:ADV_HLD.3-14 The evaluator shall examine the high-level design to determine that it is a complete instantiation of the TOE security functional requirements.

147 To ensure that all ST security functional requirements are covered by the high-level design, the evaluator may construct a map between the TOE security functional requirements and the high-level design.

AIS 34_3 31/139


1.1.6.4 Evaluation of the implementation (ADV_IMP.2)


148 The objective of this sub-activity is to determine whether the implementation representation is sufficient to satisfy the functional requirements of the ST and is a correct realisation of the low-level design.

1.1.6.4.2 Application notes

149 If the implementation includes source code, source code analysis tools can be used to assess the code quality and search for particular kinds of vulnerability. If the implementation includes hardware drawings, the developer's CAD tools may be useful in analysing them.

150 Although this activity is more likely than any other to benefit from the use of automated tools, informal examination and compliance analysis can still be used.

1.1.6.4.3 Input


a) the ST;

b) the low-level design;

c) implementation representation of the entire TSF;

d) the development tool documentation.



a) ADV_IMP.2.1E;

b) ADV_IMP.2.2E.

Action ADV_IMP.2.1E

ADV_IMP.2.1C(The implementation representation shall unambiguously define the TSF to a level of detail such that the TSF can be generated without further design decisions.)

5:ADV_IMP.2-1 The evaluator shall examine the implementation representation to determine that it unambiguously defines the TSF to a level of detail such that the TSF can be generated without any further design decisions.

153 This work unit requires the evaluator to confirm that the implementation representation is suitable for analysis. The evaluator should consider the process needed to generate the TSF from the representation provided. If the process is well-defined, requiring no further design decisions (for example, requiring only the compilation of source code, or the building of hardware from hardware drawings), then the implementation representation can be said to be suitable.

154 Any programming languages used must be well defined with an unambiguous definition of all statements, as well as the compiler options used to generate the object code. This determination will have been made as part of the ALC_TAT.2 sub-activity.

5:ADV_IMP.2-2 The evaluator shall check the completeness of the implementation representation provided.

155 The developer provides the implementation representation for the TSF, which the evaluator checks to ensure that all portions of the TSF are included.

156 This check could be done by using configuration management information or the evaluation contributions to the assurance component ACM_SCP.3. Development

32/139 AIS 34_3


tools could be used to rebuild the TOE (if applicable, e.g. the TSF is completely implemented as a software), and thus to get evidence that the implementation representation for the TSF provided is complete. Consistency to the evidence provided for generation of the TOE (if required by the ST) can be of importance.

ADV_IMP.2.2C(The implementation representation shall be internally consistent.)

5:ADV_IMP.2-3 The evaluator shall examine the implementation representation to determine that it is internally consistent.

157 The evaluator looks for inconsistencies by comparing portions of the implementation representation. In the case of source code, for example, if one portion of the source code includes a call to a subprogram in another portion, the evaluator looks to see that the arguments of the calling program match the called program’s handling of the arguments. In the case of hardware drawings, the evaluator looks for such things as agreement between the nature and characteristics of the two ends of a circuit trace (e.g. voltage level, direction of logic, signal timing requirements). For guidance on consistency analysis see Annex A.3 of CEM.

158 (*) It is of specific importance to review those parts of the implementation representation in detail which are directly or indirectly related to the TOE security functions instantiation and their behaviour in operation.

159 It is of specific importance for interfaces being relevant to security to analyse e.g. if these interfaces in the implementation representation are in line with its specification, only external interfaces are declared as such, or only specified interface input parameters are accepted.

160 For performing vulnerability assessment (under AVA activities), significantly more investigation might be necessary, but this depends on the attack scenarios considered. E.g. vulnerability assessment should include the analysis whether there is a functionality not being intended by the TOE.

ADV_IMP.2.3C(The implementation representation shall describe the relationships between all portions of the implementation.)

5:ADV_IMP.2-4 The evaluator shall examine the implementation representation to determine that it describes the relationships between all portions of the implementation.

161 The evaluator’s objective is to gain an understanding of how different parts of the implementation belong together and to gain assurance of the correctness of the implementation of the TSF mechanisms. The interrelationships between the single modules might have already been analysed on the LLD representation level (cf. ADV_LLD.1.5C). The relationships within a module represent an object for analysis inherent to the implementation representation level.

162 In the case that the implementation representation includes software source code as well as hardware drawings, understanding the relation between hardware parts and software parts of the implementation representation is of importance.

163 It is of specific importance for interfaces relevant to security that the evaluator understands how different parts of the TSF work together via their interfaces and to understand the behaviour of the TSF in operation.

164 The evaluator can use developer’s tools in order to perform the current work unit, e.g. a debugger.

Action ADV_IMP.2.2E

(The evaluator shall determine that the implementation representation is an accurate and complete instantiation of the TOE security functional requirements.)

AIS 34_3 33/139


5:ADV_IMP.2-5 The evaluator shall examine the implementation representation to determine that it is an accurate instantiation of the TOE security functional requirements.

165 The evaluator determines that the implementation representation matches the TOE security functional requirement. Therefore, he should track specific characteristics of the requirements in the implementation representation. For example, if the ST contains a requirement for subset residual information protection, so that some resources shall become unavailable upon their de-allocation, and the source code does not contain any appropriate instruction, then the implementation representation is not an accurate instantiation of the TOE security functional requirements.

5:ADV_IMP.2-6 The evaluator shall examine the implementation representation to determine that it is a complete instantiation of the TOE security functional requirements.

166 To ensure that all TOE security functional requirements are covered by the implementation representation, the evaluator may construct a map between the TOE security functional requirements and the implementation representation ensuring that all security functional requirements can be mapped onto parts of the implementation representation.

34/139 AIS 34_3


1.1.6.5 Evaluation of the TSF-internals (ADV_INT.1)


167 The objective of this sub-activity is to determine whether the TSF are designed and structured in a modular fashion that avoids unnecessary interactions between the modules of the design - thus contributing to TSF that are simple enough to be understood.


168 The purpose of the architectural description is to provide evidence of modularity of the TSF whereas the low-level design describes the design of the modules of the TSF. The degree of refinement of the TSF subsystems into modules is the same for the low-level design and for the architectural description, but the architectural description is not intended to be a duplication of the low-level design evidence but a supplement.

169 Therefore, the architectural description is an analysis of the module structure of the low-level design and its interfaces. It provides a rationale about modularity aspects (and reduced and minimised design complexity at higher component level) of the design of the TSF. The modules of the architectural description can differ from the modules of the low-level design. In this case the assurance elements ADV_INT.1.1C and ADV_INT.1.2C are not trivial, but define the module structure of the architectural description.

170 This sub-activity may be performed in conjunction with the ADV_LLD sub-activity.

1.1.6.5.3 Input


a) the ST;

b) the low-level design;

c) the implementation representation;

d) the architectural description.



a) ADV_INT.1.1E;

b) ADV_INT.1.2E.

Action ADV_INT.1.1E

ADV_INT.1.1C(The architectural description shall identify the modules of the TSF.)

ADV_INT.1-1 The evaluator shall check the architectural description to determine that it identify a module structure and all modules of the low-level design are covered by this module structure.

173 The architectural description identifies a modular structure of the TSF. This structure can be the same as in the low-level design of differ from it. If the modular structure of the architectural description does not differ from it in the low-level design, this work unit can be fulfilled by referring to the low-level design.

174 The architectural description provides an analysis of modularity based on module definition and classification as defined in the low-level design.

175 The analysis can be informal.

176 This work unit may be performed in conjunction with the work unit ADV_INT.1-2.

AIS 34_3 35/139


ADV_INT.1.2C(The architectural description shall describe the purpose, interface, parameters, and effects of each module of the TSF.)

ADV_INT.1-2 The evaluator shall examine the architectural description to determine that all interfaces of modules of the low-level design are covered in the modularity analysis.

177 This work unit may be performed in conjunction with the work unit ADV_INT.1-1 but with a focus on interfaces between modules.

178 If the modular structure of the architectural description does not differ from it in the low-level design, this work unit can be fulfilled by referring to the low-level design.

ADV_INT.1.3C(The architectural description shall describe how the TSF design provides for largely independent modules that avoid unnecessary interactions.)

ADV_INT.1-3 The evaluator shall examine the architectural description to determine that it describes how the TSF design provides for largely independent modules that avoid unnecessary interactions.

179 For the purpose of this analysis, modules are viewed as interacting in two ways:

a) to provide services to one another, and

b) to co-operate in support of security or other functions.

180 It should be considered that it is possible that some modules must be combined to implement a single security function and that dependencies in design and technical implementation may exist between modules that limit modularity. Analysis can include findings of how security functions are realised by modules (simple ore complex mapping), if a modules implements a unique functionality, aspects of grouping of modules in terms of functionality, timing of operational aspects of functionality on the module level, etc.

181 At first, the evaluator analysis, if the developer has provided sufficient evidence why the architecture of the TSF is modular.

182 In addition, the evaluator analysis, if the architectural description includes specific information on interrelationships between modules.

183 Evidence, that interactions occur are necessary, is required. Note that necessity may be justified by non-security issues such as performance.

184 Aspects of decomposition, abstraction, data hiding as well as the purpose of multiple used variables can be of importance.

Action ADV_INT.1.2E

(The evaluator shall determine that both the low-level design and the implementation representation are in compliance with the architectural description.)

ADV_INT.1-4 The evaluator shall examine the architectural description to determine that the low-level design is in compliance with the architectural description.

185 The architectural description is at a similar level of abstraction to the low-level design, in that it is concerned with the modules of the TSF.

186 The evaluator looks for consistency between module specification in the low level design and the analysis of modularity.

187 If the modular structure of the architectural description does not differ from it in the low-level design, this work unit is not applicable and therefore considered to be satisfied.

36/139 AIS 34_3


ADV_INT.1-5 The evaluator shall examine the architectural description to determine that the implementation representation is in compliance with the architectural description.

188 The evaluator looks for consistency between the analysis of modularity in the architectural description and the implementation representation (source code and/or hardware drawings) of the TSF. Correspondence information between low-level design and implementation may support this consistency check, but this consistency check is focused on the aspects, that the modularity concept outlined in the architectural description is not made ineffective by the way the implementation level is structured.

AIS 34_3 37/139


1.1.6.6 Evaluation of the low-level design (ADV_LLD.1)


190 Renumber work units: 4:ADV_LLD.1-x to 5:ADV_LLD.1-x, (x = 1...12)

38/139 AIS 34_3


1.1.6.7 Evaluation of representation correspondence (ADV_RCR.2)


191 The objective of this sub-activity is to determine whether the developer has correctly and completely implemented the requirements of the ST, functional specification, high-level design and low-level design in the implementation representation.

1.1.6.7.2 Input


a) the ST;


c) the high-level design;

d) the low-level design;

e) the implementation representation;

f) the correspondence analysis between the TOE summary specification and the functional specification;

g) the correspondence analysis between the functional specification and the high-level design;

h) the correspondence analysis between the high-level design and the low-level design;

i) the correspondence analysis between the low-level design and the implementation representation.


193 The correspondence analysis shall be presented in such a way that the relationships between the specifications are clear, and that where each specification addresses the same point, that point is addressed consistently.

194 Evaluators must be able to demonstrate that every relevant part of the TSF was considered in the analysis.


195 This sub-activity comprises one CC Part 3 evaluator action element:

a) ADV_RCR.2.1E.

Action ADV_RCR.2.1E

ADV_RCR.2.1C(For each adjacent pair of provided TSF representations, the analysis shall demonstrate that all relevant security functionality of the more abstract TSF representation is correctly and completely refined in the less abstract TSF representation.)

and ADV_RCR.2.2C(For each adjacent pair of provided TSF representations, where portions of both representations are at least semiformal specified, the demonstration of correspondence between those portions of the representations shall be semiformal.)

5:ADV_RCR.2-1 The evaluator shall examine the correspondence analysis between the TOE summary specification and the functional specification to determine that the functional specification is a correct and complete representation of the TOE security functions.

AIS 34_3 39/139


196 The evaluator’s goal in this work unit is to determine that all security functions identified in the TOE summary specification are represented in the functional specification and that they are represented accurately.

197 The evaluator reviews the correspondence between the TOE security functions of the TOE summary specification and the functional specification. The evaluator looks for consistency and accuracy in the correspondence. Where the correspondence analysis indicates a relationship between a security function of the TOE summary specification and a specified security feature of a security function or an interface description in the functional specification, the evaluator verifies that the security functionality of both are the same. (*) In specific cases, a security function of the TOE summary specification may correctly and completely described by a corresponding interface description in the functional specification.

198 This work unit may be done in conjunction with work units 5:ADV_FSP.3-10 and 5:ADV_FSP.3-11.

5:ADV_RCR.2-2 The evaluator shall check the correspondence analysis between the functional specification and the high-level design to determine that it is semiformal.

199 A semiformal notation uses a restricted syntax. The syntax of all semiformal notations used in the correspondence analysis shall be defined or a corresponding standard be referenced.

200 The evaluator shall verify that the correspondence analysis uses a semiformal notation to provide the mapping between the functional specification and the high-level design. For details on semiformal methods refer to Annex 3.1.1 ‘Semiformaland formal methods’.

201 If the semiformal styles of the functional specification and the high-level design are different, a transcription as a translation of the one representation into the other notation could be reasonable either for providing the semiformal correspondence analysis or for the evaluators to verify the correspondence analysis.

5:ADV_RCR.2-3 The evaluator shall examine the correspondence analysis to determine that it contains all necessary informal explanatory text.

202 Supporting narrative descriptions are necessary for those portions of the correspondence analysis that are difficult to understand only from the semiformal description (for example, to make clear the meaning and the specific use of a semiformal notation). Any restrictions placed upon the syntax must be clearly explained.

203 Informal explanatory text supporting semiformal descriptions has to be linked to the relevant semiformal parts of the analysis.

5:ADV_RCR.2-4 The evaluator shall examine the correspondence analysis between the functional specification and the high-level design to determine that the high-level design is a correct and complete representation of the functional specification.

204 The evaluator uses the correspondence analysis, the functional specification, and the high-level design to ensure that it is possible to map each security function identified in the functional specification onto a TSF subsystem described in the high-level design. For each security function, the correspondence indicates which TSF subsystems are involved in the support of the function. The evaluator verifies that the high-level design includes a description of a correct realisation of each security function.

5:ADV_RCR.2-5 The evaluator shall examine the correspondence analysis between the high-level design and the low-level design to determine that the low-level design is a correct and complete representation of the high-level design.

205 The evaluator uses the correspondence analysis, the high-level design, and the low-level design to ensure that it is possible to map each TSF module identified in the low-level design onto a TSF subsystem described in the high-level design. For each TOE security

40/139 AIS 34_3


function, the correspondence indicates which TSF modules are involved in the support of the function. The evaluator verifies that the low-level design includes a description of a correct realisation of each security function.

5:ADV_RCR.2-6 The evaluator shall examine the correspondence analysis between the low-level design and the implementation representation to determine that the implementation representation is a correct and complete representation of the low-level design.

206 The evaluator uses the correspondence analysis, the low-level design, and the TSF implementation representation to ensure that it is possible to map each single TSF implementation unit (e.g. routines) identified in the implementation representation onto a TSF module described in the low-level design. For each TOE security function, the correspondence indicates which TSF implementation units are involved in the support of the function. The evaluator verifies that the TSF implementation representation includes a description of a correct realisation of each security function.

AIS 34_3 41/139


1.1.6.8 Evaluation of security policy modelling (ADV_SPM.3)


207 The objectives of this sub-activity are to determine whether the formal TOE security policy model clearly and consistently describes the rules and characteristics of the security policies by properties and features as their counterparts and whether this description corresponds with the description of security functions in the functional specification.


208 This activity applies to cases where the developer has formally modelled all security policies of the TOE that are capable of being modelled formally.

209 A formal TOE security policy model is a representation of the rules (synonymously termed “principles”) and characteristics of security policies in mathematical terms. Their formal counterparts are called security properties and security features , respectively. The representation includes but is not limited to algebraic specifications, finite state machines and logic formalisms strong enough to formally infer the properties from the features. The formal TSP model is accompanied by an informal interpretation explaining how the rules and characteristics are mapped to the respective properties and features .

210 It is recognized that not all policies (see work units for ADV_SPM.3.2C) can be formally modelled for all TOEs. This is because either the state of the art is insufficient to formally model a given policy, or because the nature of the TOE renders impossible the modelling of policies that would otherwise be possible to model.

211 Hence the possibility to model some policy depends on the very nature of the TOE enforcing it.

212 While access control policies and information flow control policies have both been formally modelled successfully, the possibility of modelling other policies is based on a case by case decision. Abstention from formally modelling security relevant policies requires argumentation and rests the burden of proof entirely on the developer’s side.

213 For any security policy where formal models are not possible, the policy must be provided in semiformal form. For any security policy where neither formal nor semiformal models are possible, the policy must be provided in an informal form. If none of the TOE’s security policies can be formally modelled, ADV_SPM.3 cannot be met.

1.1.6.8.3 Input


a) the ST;


c) the TOE security policy model (TSP model);

d) the user guidance;

e) the administrator guidance.

1.1.6.8.4 Evaluator Actions


a) ADV_SPM.3.1E.

Action ADV_SPM.3.1E

ADV_SPM.3.1C(The TSP model shall be formal.)

42/139 AIS 34_3


5:ADV_SPM.3-1 The evaluator shall examine the TOE security policy model to determine that it is written in a formal style.

216 The evaluator identifies the formal framework upon which the TOE security policy model is based and ensures that it is founded on well established mathematical concepts. He also identifies the security properties and features addressed in the application notes and ensures the formalization of at least one security policy.

217 For guidance on formal methods refer to Annex 3.1.1 ‘Semiformal and formalmethods’.

5:ADV_SPM.3-2 The evaluator shall examine the TOE security policy model to determine that it contains all necessary informal explanatory text.

218 Supporting narrative descriptions are necessary for all parts of the model (for example, to make clear the meaning of any formal notation and how they are used) including the security properties and features.

ADV_SPM.3.2C(The TSP model shall describe the rules (principles) and characteristics of all policies of the TSP that can be modelled.)

5:ADV_SPM.3-3 The evaluator shall check the TOE security policy model to determine that all security policies that are explicitly included in the ST are modelled.

219 The security policy is expressed by the collection of the functional security requirements in the ST. Therefore, to determine the nature of the security policy (and hence what policies must be modelled), the evaluator analyses the ST functional requirements for those policies explicitly called for (e.g. by FDP_ACC and FDP_IFC, if included in the ST).

220 If the ST contains no explicit policies (e.g. because neither FDP_ACC nor FDP_IFC are included in the ST), this work unit is not applicable and is therefore considered to be satisfied.

5:ADV_SPM.3-4 The evaluator shall examine the TOE security policy model to determine that all security policies represented by the security functional requirements claimed in the ST are modelled.

221 In addition to the explicitly-listed policies (see work unit 5:ADV_SPM.3-3), the evaluator analyses the ST functional requirements for those policies implied by the other functional security requirement classes. For example, inclusion of FDP requirements (other than FDP_ACC and FDP_IFC) would need a description of the Data Protection policy being enforced; inclusion of any FIA requirements would necessitate that a description of the Identification and Authentication policies be present in the model; inclusion of FAU requirements need a description of the Audit policies; etc. While the other functional requirement families are not typically associated with what are commonly referred to as security policies, they nevertheless do enforce security policies (e.g. non-repudiation, reference mediation, privacy, etc.) that must be included in the TOE security policy model.

222 If the ST contains no such implicit policies, this work unit is not applicable and is therefore considered to be satisfied.

5:ADV_SPM.3-5 The evaluator shall examine the rules and characteristics of the security policies to determine that the modelled security behaviour of the TOE is clearly articulated.

223 The TSP model’s properties describe the TOE’s behaviour in enforcing the principles of the policy. For example, a policy that is modelled on the basis of state transitions would include principles of its states, identify its initial state, and define what it means to be a secure state.

224 The TSP model’s features describe the attributes and conditions of the TOE that come into consideration when enforcing its policy’s characteristics. For example, a

AIS 34_3 43/139


policy that is modelled on the basis of state transitions would describe the necessary conditions to transform the TOE from one state to the next.

225 Together the rules and characteristics describe the entire security posture of the TOE security policy.

226 In the context of a formal TOE security policy model the security behaviour is considered to be clearly articulated only if an adequate mapping from rules and characteristics to their respective formal counterparts properties and features has been given. The mapping is considered to be adequate if the level of abstraction from the TOE’s realization is detailed enough to allow for correct identification of all security objectives and the relation to the security environment.

227 The above condition for clear articulation is necessary but not sufficient. An informal interpretation of all formal concepts (including attributes, predicates and variables, if available) must be provided in order to make clear their intended meaning.

ADV_SPM.3.3C(The TSP model shall include a rationale that demonstrates that it is consistent and complete with respect to all policies of the TSP that can be modelled.)

5:ADV_SPM.3-6 The evaluator shall examine the TOE security policy model rationale to determine that it formally proves the correspondence between the security properties and the security features.

228 The proof shall show that the security features enforce the security properties. To determine the enforcement, the evaluator considers the security properties and the security features and verifies that the arguments used in the proof are valid. The proof of correspondence between the security properties and the security features shall be formal.

5:ADV_SPM.3-7 The evaluator shall examine the TOE security policy model rationale to determine that it proves the internal consistency of the TOE security policy model.

229 The proof shall show the absence of contradictions within the TOE security policy model. In determining the absence of contradictions, the evaluator verifies that the arguments used in the proof are valid.

230 Since the TOE security policy model is formal, the proof of its internal consistency shall be formal. It is recognized that a complete formal proof of the internal consistency of the TOE security policy model usually is not possible due to the fundamental nature of formal frameworks. Generally, it is sufficient to generate evidence using formal proofs based on the specific TOE security policy model that prove the internal consistency by means of a combination with generic arguments of the formal framework.

231 For additional guidance on consistency analysis see Annex A.3 of CEM.

5:ADV_SPM.3-8 The evaluator shall examine the TOE security policy model rationale to determine that the behaviour modelled is consistent with respect to policies described by the security policies (as articulated by the functional requirements in the ST).

232 The examination considers the informal relationships of the model. Hence the meaning of consistency reflects the conventional understanding in contrast to the internal consistency concept of the previous work unit.

233 In determining consistency, the evaluator verifies that the rationale shows that each description of properties and features in the TSP model accurately reflects the intent of the security policies. For example, if a policy stated that access control was necessary to the granularity of a single individual, then a TSP model describing the security behaviour of a TOE in the context of controlling groups of users would not

44/139 AIS 34_3


be consistent. Likewise, if the policy stated that access control for groups of users was necessary, then a TSP model describing the security behaviour of a TOE in the context of controlling individual users would also not be consistent.

234 The evaluator also examines whether the security policies are reflected within their formal counterparts of the TSP model.

235 For additional guidance on consistency analysis see Annex A.3 of CEM.

5:ADV_SPM.3-9 The evaluator shall examine the TOE security policy model rationale to determine that the behaviour modelled is complete with respect to the policies described by the security policies (i.e. as articulated by the functional requirements in the ST).

236 In determining completeness of this rationale, the evaluator considers the properties and features of the TSP model and maps those properties and features to explicit policy statements (i.e. functional requirements). The rationale should show that all policies that are required to be modelled have an associated property or feature description in the TOE security policy model.

237 Abstention from formally modelling policy statements always calls for justification on the developer’s side (also confer the application notes above).

ADV_SPM.3.4C(The demonstration of correspondence between the TSP model and the functional specification shall show that all of the security functions in the functional specification are consistent and complete with respect to the TSP model.)

5:ADV_SPM.3-10The evaluator shall examine the functional specification correspondence demonstration of the TOE security policy model to determine that it identifies all security functions described in the functional specification that implement a portion of the policy.

238 The degree of formality of the correspondence is the same as the degree of formality of the functional specification: the correspondence to an informal functional specification is informal; the correspondence to a semiformal functional specification is semiformal (see 5:ADV_SPM.3-12); and the correspondence to a formal functional specification is formal (see 5:ADV_SPM.3-13).

239 In determining completeness, the evaluator reviews the functional specification, identifies which functions directly support the TSP model and verifies that these functions are present in the functional specification correspondence demonstration of the TOE security policy model.

5:ADV_SPM.3-11 The evaluator shall examine the functional specification correspondence demonstration of the TOE security policy model to determine that the descriptions of the functions identified as implementing the TSP model are consistent with the descriptions in the functional specification.

240 The meaning of consistency reflects the conventional understanding in contrast to the internal consistency concept of work unit 5:ADV_SPM.3-7.

241 The evaluator verifies that the functional specification correspondence demonstrates, that the functional description in the FSP of the functions, identified as implementing the policy described in the TSP model, correspond to the associated features of the TSP model and therefore enforce the associated properties of the TSP model.

242 In cases where a security policy is enforced differently for untrusted users and administrators, the policies for each are described consistently with the respective behaviour descriptions in the user and administrator guidance. For example, the “identification and authentication” policy enforced upon remote untrusted users might be more stringent than that enforced upon administrators whose only point of access is within a physically-protected area; the differences in authentication should correspond to

AIS 34_3 45/139


the differences in the descriptions of authentication within the user and administrator guidance.

243 For additional guidance on consistency analysis see Annex A.3 of CEM [CEM23].

ADV_SPM.3.5C(Where the functional specification is semiformal, the demonstration of correspondence between the TSP model and the functional specification shall be semiformal.)

5:ADV_SPM.3-12The evaluator shall examine the functional specification correspondence demonstration of the TOE security policy model to determine that it is presented in a semiformal style.

244 If the functional specification is not semiformal, this work unit is not applicable and is therefore considered to be satisfied. If the ST includes ADV_FSP.4 ‘Formal functional specification’ then ADV_SPM.3.5C and this work unit are not applicable. Therefore in this case this work unit is considered to be satisfied; however, the work unit 5:ADV_SPM.3-13 applies.

245 The functional specification correspondence demonstration described in work units 5:ADV_SPM.3-10 and 5:ADV_SPM.3-11 has to be semiformal.

246 A semiformal correspondence is one that results from a structured approach with a substantial degree of rigor (in terms of completeness and correctness), but is not as rigorous as a mathematical proof. Such a semiformal correspondence limits the subjective interpretations of its terms, and so it provides less ambiguity than would exist in an informal correspondence.

247 For guidance on semiformal methods refer to Annex 3.1.1 ‘Semiformal and formalmethods’.

ADV_SPM.3.6C(Where the functional specification is formal, the proof of correspondence between the TSP model and the functional specification shall be formal.)

5:ADV_SPM.3-13The evaluator shall examine the functional specification correspondence demonstration of the TOE security policy model to determine that it is in a formal style.

248 If the ST includes ADV_FSP.3 ‘Semiformal functional specification’ then ADV_SPM.3.6C and this work unit are not applicable. However, in this case the functional specification is considered to be semiformal and work unit 5:ADV_SPM.3-12 applies.

249 The functional specification correspondence demonstration described in work units 5:ADV_SPM.3-10 and 5:ADV_SPM.3-11 has to be a formal proof.

250 The formal proof of correspondence removes all subjective interpretations of its terms by enlisting well-established mathematical concepts to define the syntax and semantics of the formal notation and the proof rules that support logical reasoning. The security properties within the TOE (which are identified in the formal TSP model) are expressed in a formal specification language and shown to be satisfied by the formal specification.

251 For guidance on formal methods refer to Annex 3.1.1 ‘Semiformal and formalmethods’.

46/139 AIS 34_3


1.1.7 EAL5 Guidance documents activity

252 The purpose of the guidance document activity is to judge the adequacy of the documentation describing how to use the operational TOE. Such documentation includes both that aimed at trusted administrators and non-administrator users whose incorrect actions could adversely affect the security of the TOE, as well as that aimed at untrusted users whose incorrect actions could adversely affect the security of their own data.

253 The guidance documents activity at EAL5 contains sub-activities related to the following components:

a) AGD_ADM.1;

b) AGD_USR.1.


254 The guidance documents activity applies to those functions and interfaces which are related to the security of the TOE. The secure configuration of the TOE is described in the ST.

1.1.7.2 Evaluation of administrator guidance (AGD_ADM.1)


256 Renumber work units: 4:AGD_ADM.1-x to 5:AGD_ADM.1-x, (x = 1...8)

1.1.7.3 Evaluation of user guidance (AGD_USR.1)


258 Renumber work units: 4:AGD_USR.1-x to 5:AGD_USR.1-x, (x = 1...6)

AIS 34_3 47/139


1.1.8 EAL5 Life cycle support activity

259 The purpose of the life-cycle support activity is to determine the adequacy of the procedures the developer uses during the development and maintenance of the TOE. These procedures include the security measures used throughout TOE development, the life-cycle model used by the developer, and the tools used by the developer throughout the life-cycle of the TOE. (*) The life-cycle model can also be extended on the operational life phase of the TOE, especially in the context of ALC_FLR.

260 Developer security procedures are intended to protect the TOE and its associated design information from interference or disclosure. Interference in the development process may allow the deliberate introduction of vulnerabilities. Disclosure of design information may allow vulnerabilities to be more easily exploited. The adequacy of the procedures will depend on the nature of the TOE and the development process.

261 Poorly controlled development and maintenance of the TOE can result in vulnerabilities in the implementation. Conformance to a defined life-cycle model can help to improve controls in this area. A standardized life-cycle model used for the TOE can avoid the use of proprietary possibly inexperienced methods.

262 The use of well-defined development tools helps to ensure that vulnerabilities are not inadvertently introduced during refinement.

263 The life-cycle support activity at EAL5 contains sub-activities related to the following components:

a) ALC_DVS.1;

b) ALC_LCD.2;Changes from EAL 4 (ALC_LCD.1) is the need for a standardized life-cycle model.

c) ALC_TAT.2.Changes from EAL 4 (ALC_TAT.1) is the compliance with defined implementation standards.

1.1.8.1 Evaluation of development security (ALC_DVS.1)


265 Renumber work units: 4:ALC_DVS.1-x to 5:ALC_DVS.1-x, (x = 1...4)

48/139 AIS 34_3


1.1.8.2 Evaluation of life-cycle definition (ALC_LCD.2)


266 The objective of this sub-activity is to determine whether the developer has used a documented and standardized model of the TOE life-cycle.

1.1.8.2.2 Input


a) the ST;

b) the life-cycle definition documentation;

c) Information about the standard used.



a) ALC_LCD.2.1E.

Action ALC_LCD.2.1E

ALC_LCD.2.1C(The life-cycle definition documentation shall describe the model used to develop and maintain the TOE.)

5:ALC_LCD.2-1 The evaluator shall examine the documented description of the life-cycle model used to determine that it covers the development and maintenance process.

269 A life-cycle model encompasses the procedures, tools and techniques used to develop and maintain the TOE. The description of the life-cycle model should include information on the procedures, tools and techniques used by the developer (e.g. for design, coding, testing, bug-fixing). It should describe 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 development and maintenance process covered by the life-cycle model).

ALC_LCD.2.2C (The life-cycle model shall provide for the necessary control over the development and maintenance of the TOE)

5:ALC_LCD.2-2 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 development and maintenance of the TOE.

270 The information provided in the life-cycle model gives the evaluator assurance that the development and maintenance procedures adopted would minimize the likelihood of security flaws. For example, if the life-cycle model described the review process, but did not make provision for recording changes 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 actions relating to the TOE development (e.g. those actions covered under the ACM activity). Identified deficiencies in the life-cycle model will be of concern if they might reasonably be expected to give rise to the introduction of flaws into the TOE, either accidentally or deliberately.

271 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.

AIS 34_3 49/139


ALC_LCD.2.3C(The life-cycle definition documentation shall explain why the model was chosen.)

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

272 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 security 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.2.4C(The life-cycle definition documentation shall explain how the model is used to develop and maintain the TOE.)

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

273 Whereas the requirements of ALC_LCD.1 are confined to a description of the model used, this component requires the developer to explain how the standardized model has been applied to the TOE under evaluation. This explanation shall cover using the life-cycle model for development and maintenance of the TOE as well as adaptation of the standardized model to meet specific TOE or organisational requirements. Usage of the life-cycle model chosen shall be compliant with the configuration management (class ACM).

5:ALC_LCD.2-5 The evaluator shall examine the life-cycle definition for consistency with the Security Target of the TOE.

274 If the Security Target contains aspects of the TOE development and production, e.g. specific assumptions, policies and objectives for these life-cycle phases, consistency with the life-cycle definition documentation and the standardized model used has to be determined.

275 If the life-cycle model used for the TOE covers aspects after TOE delivery (e.g. the assurance family ALC_FLR is chosen), the life-cycle definition documentation has to be analysed for consistency between information given in the ST about the intended operating environment of the TOE and about the TOE's security objectives in comparison to the model for the portion of the life-cycle after the delivery of the TOE. If the assurance family ALC_FLR is chosen, the relevant information shall be considered in the context of the analysis.

ALC_LCD.2.5C(The life-cycle definition documentation shall demonstrate compliance with the standardised life-cycle model.)

5:ALC_LCD.2-6 The evaluator shall examine the life-cycle definition documentation to determine that it demonstrates that the life-cycle model used corresponds to the standardized model.

276 A standardized life-cycle model is a model that has been approved by some group of experts (e.g. academic experts, standards bodies). A formal approval for the standardized life-cycle model is not mandated, but it should be public, well accepted and used by a wider group of experts or e.g. being common practice in a specific industry.

277 Examples of standardized life cycle models are the Waterfall Model, Rapid Prototyping or the V-Model and the Spiral Model.

278 The life-cycle definition documentation should relate aspects of the standardized model to the specific development and maintenance procedures in place for the

50/139 AIS 34_3


TOE, such that conformance to the standardized 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 standardized model to individual development procedures and roles or personnel from the development environment.

279 Through completion of this work unitFehler: Referenz nicht gefunden, the evaluator should gain a clear understanding of how the standardized model has been applied, and that it has been applied correctly.

AIS 34_3 51/139


1.1.8.3 Evaluation of tools and techniques (ALC_TAT.2)


280 The objectives of this sub-activity are to determine whether the developer has used well-defined development tools (e.g. programming languages or computer-aided design (CAD) systems) that yield consistent and predictable results, and whether implementation standards have been applied.

1.1.8.3.2 Input


a) the development tool documentation;

b) the implementation standards description;

c) the provided implementation representation of the TSF.


282 This work may be performed in parallel with the ADV_IMP sub-activity, specifically with regard to determining the use of features in the tools that will affect the object code (e.g. compilation options).



a) ALC_TAT.2.1E;

b) ALC_TAT.2.2E.

Action ALC_TAT.2.1E

ALC_TAT.2.1C(All development tools used for implementation shall be well-defined.)

5:ALC_TAT.2-1 The evaluator shall examine the development tool documentation provided to determine that all development tools are well-defined.

284 For example, a well-defined language, compiler or CAD system may be considered to be one that conforms to a recognized standard, such as the ISO standards. A well-defined language is one that has a clear and complete description of its syntax, and a detailed description of the semantics of each construct.

ALC_TAT.2.2C(The documentation of the development tools shall unambiguously define the meaning of all statements used in the implementation.)

5:ALC_TAT.2-2 The evaluator shall examine the documentation of development tools to determine that it unambiguously defines the meaning of all statements used in the implementation.

285 The development tool documentation (e.g. programming language specifications and user manuals) should cover all statements used in the implementation representation of the TOE, and for each such statement provide a clear and unambiguous definition of the purpose and effect of that statement. This work may be performed in parallel with the evaluator’s examination of the implementation representation performed during the ADV_IMP sub-activity. The key test the evaluator should apply is whether or not the documentation is sufficiently clear for the evaluator to be able to understand the implementation representation. The documentation should not assume (for example) that the reader is an expert in the programming language used.

52/139 AIS 34_3


286 Reference to the use of a documented standard is an acceptable approach to meet this requirement, provided that the standard is available to the evaluator. Any differences from the standard should be documented.

287 The critical test is whether the evaluator can understand the TOE source code when performing source code analysis covered in the ADV_IMP sub-activity. However, the following checklist can additionally be used in searching for problem areas:

a) In the language definition, phrases such as “the effect of this construct is undefined”, and terms such as “implementation dependent” or “erroneous” may indicate ill-defined areas;

b) Aliasing (allowing the same piece of memory to be referenced in different ways) is a common source of ambiguity problems;

c) Exception handling (e.g. what happens after memory exhaustion or stack overflow) is often poorly defined.

288 Most languages in common use, however well designed, will have some problematic constructs. If the implementation language is mostly well defined, but some problematic constructs exist, then an inconclusive verdict should be assigned, pending examination of the source code.

289 The evaluator should verify, during the examination of source code, that any use of the problematic constructs does not introduce vulnerabilities. The evaluator should also ensure that constructs precluded by the documented standard are not used.

ALC_TAT.2.3C(The documentation of the development tools shall unambiguously define the meaning of all implementation dependent options.)

5:ALC_TAT.2-3 The evaluator shall examine the development tool documentation to determine that it unambiguously defines the meaning of all implementation-dependent options.

290 The documentation of software development tools should include definitions of implementation-dependent options that may affect the meaning of the executable code, and those that are different from the standard language as documented. Where source code is provided to the evaluator, information should also be provided on compilation and linking options used.

291 The documentation for hardware design and development tools should describe the use of all options that affect the output from the tools (e.g. detailed hardware specifications, or actual hardware).

Action ALC_TAT.2.2E

(The evaluator shall confirm that the implementation standards have been applied.)

5:ALC_TAT.2-4 The evaluator shall examine aspects of the implementation process to determine that documented implementation standards have been applied.

292 This work unit requires the evaluator to analyse the provided implementation representation of the TOE to determine whether the documented implementation standards have been applied.

293 The evaluator should verify that constructs excluded by the documented standard are not used.

294 Additionally, the evaluator shall verify the developer’s procedures which ensure the application of the defined standards within the design and implementation process of the TOE. Therefore, documentary evidence should be supplemented by visiting the development environment. A visit to the development environment will allow the evaluator to:

a) observe the application of defined standards;

AIS 34_3 53/139


b) examine documentary evidence of application of procedures describing the use of defined standards;

c) interview development staff to check awareness of the application of defined standards and procedures.

295 A development site visit is a useful means of gaining confidence in the procedures being used. Any decision not to make such a visit should be determined in consultation with the overseer.

296 The evaluator compares the provided implementation representation with the description of the applied implementation standards and verifies their use. At this level it is not required that the complete provided implementation representation of the TSF is based on implementation standards. It is only required that those implementation standards, referenced by the developer, are applied indeed. If the referenced implementation standards are not applied for at least parts of the provided implementation representation, this work unit fails.

297 This work unit may be performed in conjunction with the ADV_IMP.* sub-activities.

54/139 AIS 34_3


1.1.9 EAL5 Test activity

298 The purpose of this activity is to determine whether the TOE behaves as specified in the design documentation and in accordance with the TOE security functional requirements specified in the ST. This is accomplished by determining that the developer has tested the TSF against its functional specification, the high-level design and the low-level design, gaining confidence in those test results by performing a sample of the developer’s tests, and by independently testing a subset of the TSF.

299 The tests activity at EAL5 contains sub-activities related to the following components:

a) ATE_COV.2;

b) ATE_DPT.2;Changes from EAL 4 (ATE_DPT.1) is testing at low-level design.

c) ATE_FUN.1;

d) ATE_IND.2.


300 The size and composition of the evaluator’s test subset depends upon several factors discussed in the independent testing (ATE_IND.2) sub-activity. One such factor affecting the composition of the subset is known public domain weaknesses, information about which the evaluator needs access (e.g. from a scheme).

301 The CC has separated coverage and depth from functional tests to increase the flexibility when applying the components of the families. However, the requirements of the families are intended to be applied together to confirm that the TSF operates according to its specification. This tight coupling of families has led to some duplication of evaluator work effort across sub-activities. These application notes are used to minimize duplication of text between sub-activities of the same activity and EAL.

1.1.9.1.1 Understanding the expected behaviour of the TOE

302 Before the adequacy of test documentation can be accurately evaluated, or before new tests can be created, the evaluator has to understand the desired expected behaviour of a security function in the context of the requirements it is to satisfy.

303 The evaluator may choose to focus on one security function of the TSF at a time. For each security function, the evaluator examines the ST requirement and the relevant parts of the functional specification, high-level design, low level-design and guidance documentation to gain an understanding of the way the TOE is expected to behave.

304 With an understanding of the expected behaviour, the evaluator examines the test plan to gain an understanding of the testing approach. In most cases, the testing approach will entail a security function being stimulated at either the external or internal interfaces and its responses are observed. However, there may be cases where a security function cannot be adequately tested at an interface (as may be the case, for instance, for residual information protection functionality); in such cases, other means will need to be employed.

1.1.9.1.2 Testing vs. alternate approaches to verify the expected behaviour of a security function

305 In cases where it is impractical or inadequate to test at an interface, the test plan should identify the alternate approach to verify expected behaviour. It is the evaluator’s responsibility to determine the suitability of the alternate approach. However, the following should be considered when assessing the suitability of alternate approaches:

a) an analysis of the implementation representation to determine that the required behaviour should be exhibited by the TOE is an acceptable alternate approach.

AIS 34_3 55/139


This could mean a code inspection for a software TOE or perhaps a chip mask inspection for a hardware TOE.

b) it is acceptable to use evidence of developer integration or module testing, even if the EAL is not commensurate with evaluation exposure to the low-level design or implementation. If evidence of developer integration or module testing is used in verifying the expected behaviour of a security function, care should be given to confirm that the testing evidence reflects the current implementation of the TOE. If the subsystem or modules have been changed since testing occurred, evidence that the changes were tracked and addressed by analysis or further testing will usually be required.

306 It should be emphasized that supplementing the testing effort with alternate approaches should only be undertaken when both the developer and evaluator determine that there exists no other practical means to test the expected behaviour of a security function. This alternative is made available to the developer to minimize the cost (time and/or money) of testing under the circumstances described above; it is not designed to give the evaluator more latitude to demand unwarranted additional information about the TOE, nor to replace testing in general.

1.1.9.1.3 Verifying the adequacy of tests

307 Test prerequisites are necessary to establish the required initial conditions for the test. They may be expressed in terms of parameters that must be set or in terms of test ordering in cases where the completion of one test establishes the necessary prerequisites for another test. The evaluator must determine that the prerequisites are complete and appropriate in that they will not bias the observed test results towards the expected test results.

308 The test steps and expected results specify the actions and parameters to be applied to the interfaces as well as how the expected results should be verified and what they are. The evaluator must determine that the test steps and expected results are consistent with the functional specification, the high-level design and the low-level design. The tests must verify behaviour documented in these specifications. This means that each security functional behaviour characteristic explicitly described in the functional specification, the high-level design and the low-level design should have tests and expected results to verify that behaviour. One opportunity for testing how each TSP-enforcing function is provided (cf. ADV_LLD.1.6C) can be performing of the code coverage, i.e. every statement of the TSP-enforcing source code has been tested.

309 Although all of the TSF has to be tested by the developer, exhaustive specification testing of the interfaces is not required. The overall aim of this activity is to determine that each security function has been sufficiently tested against the behavioural claims in the functional specification, the high-level design and the low-level design. The test procedures will provide insight as to how the security functions have been exercised by the developer during testing. The evaluator will use this information when developing additional tests to independently test the TOE.

56/139 AIS 34_3


1.1.9.2 Evaluation of coverage (ATE_COV.2)

310 CEM for EAL4 including Figure 8.2 in [CEM23] is applicable.

311 Renumber work units: 4:ATE_COV.2-x to 5:ATE_COV.2-x, (x = 1...4)

AIS 34_3 57/139


1.1.9.3 Evaluation of depth (ATE_DPT.2)


312 The objective of this sub-activity is to determine whether the developer has tested the TSF against its high-level design and low-level design.

1.1.9.3.2 Input

a) the ST;




e) the test documentation;

f) the depth of testing analysis.



a) ATE_DPT.2.1E.

Action ATE_DPT.2.1E

ATE_DPT.2.1C(The depth analysis shall demonstrate that the tests identified in the test documentation are sufficient to demonstrate that the TSF operates in accordance with its high-level design and low-level design.)

5:ATE_DPT.2-1 The evaluator shall examine the depth of testing analysis for the mapping between the tests identified in the test documentation and the high-level design.

314 The depth of testing analysis identifies all subsystems described in the high-level design and provides a mapping of the tests to these subsystems. Correspondence may take the form of a table or matrix. In some cases the mapping may be sufficient to show test correspondence. In other cases a rationale (typically prose) may have to supplement the mapping evidence provided by the developer.

315 All design details specified in the high-level design that map to and satisfy TOE security requirements are subject to testing and hence, should be mapped to test documentation. Figure 8.3 of [CEM23] displays a conceptual framework of the mapping between subsystems described in the high-level design and the tests outlined in the TOE’s test documentation used to test them. Tests may involve one or multiple security functions depending on the test dependencies or the overall goal of the test being performed.

5:ATE_DPT.2-2 The evaluator shall examine the depth of testing analysis for the mapping between the tests identified in the test documentation and the low-level design.

316 The depth of testing analysis identifies all modules described in the low-level design and provides a mapping of the tests to the modules. Correspondence may take the form of a table or matrix. In some cases the mapping may be sufficient to show test correspondence. In other cases a rationale (typically prose) may have to supplement the mapping evidence provided by the developer.

317 All design details specified in the low-level design that map to and satisfy TOE security requirements are subject to testing and, hence, should be mapped to the test documentation. Figure 1.2 below displays a conceptual framework of the mapping between modules described in the low-level design and the tests outlined in the TOE’s test documentation used to test them. Tests may involve one or

58/139 AIS 34_3


multiple security functions depending on the test dependencies or the overall goal of the test being performed.

318 The focus of this examination is to have evidence, that all design details of the modules are adequately tested rather than showing that all modules and interfaces are only touched by test cases.

5:ATE_DPT.2-3 The evaluator shall examine the developer’s test plan to determine that the testing approach for each security function of the TSF is suitable to demonstrate the expected behaviour.

319 Guidance on this work unit, as it pertains to the high level design, can be found in:

a) Application notes (see above), Understanding the expected behaviour of the TOE;

b) Application notes (see above), Testing vs. alternate approaches to verify the expected behaviour of a security function.

320 Testing of the TSF may be performed at the external interfaces, internal interfaces, or a combination of both. Whatever strategy is used the evaluator will consider its appropriateness for adequately testing the security functions. Specifically the evaluator determines whether testing at the internal interfaces for a security function is necessary or whether these internal interfaces can be adequately tested (albeit implicitly) by exercising the external interfaces. This determination is left to the evaluator, as is its justification.

5:ATE_DPT.2-4 The evaluator shall examine the test procedures to determine that the test pre-requisites, test steps and expected result(s) adequately test each security function.

321 Guidance on this work unit, as it pertains to the high-level and low-level design, can be found in:

a) Application notes (see above), Verifying the adequacy of tests.

322 (*) In case of testing the high-level design the examination of the test procedures might make use of high-level design information on the structure and interaction of subsystems to get evidence that specific test cases (possibly activated from an external interface, see previous work unit) are adequate to cover a design detail of a subsystem or its interface as specified.

323 In case of testing the low-level design the examination of the test procedures might make use of low-level design information on the structure and interaction of modules to get evidence that specific test cases (possibly activated from an external interface, see previous work unit) are adequate to cover a design detail of a module or its interface as specified.

5:ATE_DPT.2-5 The evaluator shall check the depth of testing analysis to ensure that the TSF as defined in the high-level design is completely mapped to the tests in the test documentation.

324 The depth of testing analysis provides a complete statement of correspondence between the high-level design and the test plan and procedures. All subsystems and internal interfaces described in the high-level design have to be present in the depth of testing analysis. All the subsystems and internal interfaces present in the depth of testing analysis must have tests mapped to them in order for completeness to be claimed. As Figure 8.3 of [CEM23] displays, all the subsystems and internal interfaces have tests attributed to them and therefore complete depth of testing is depicted in this example. Incomplete coverage would be evident if a subsystem or internal interface was identified in the depth of testing analysis and no tests could be attributed to it.

5:ATE_DPT.2-6 The evaluator shall check the depth of testing analysis to ensure that the TSF as defined in the low-level design is completely mapped to the tests in the test documentation.

325 The depth of testing analysis provides a complete statement of correspondence between the low-level design and the test plan and procedures. All modules and

AIS 34_3 59/139


internal interfaces described in the low-level design have to be present in the depth of testing analysis. All the modules and internal interfaces present in the depth of testing analysis must have tests mapped to them in order for completeness to be claimed (see also above Application note, Verifying the adequacy of tests). As Figure 1.2 below displays, all the modules and internal interfaces have tests attributed to them and therefore complete depth of testing is depicted in this example. Incomplete coverage would be evident if a module or internal interface was identified in the depth of testing analysis and no tests could be attributed to it.

SF - 1

T - 1

T - 2

T - 5

T - 4

T - 3 T - 6

T - 7

Test documentation

Depth of testing analysis

SF - 2

SF - 4

Subsystem - 1

Functional specification

Security Function - 1 (SF - 1)Security Function - 2 (SF - 2)Security Function - 3 (SF - 3)Security Function - 4 (SF - 4)

T - 8

T - 6

T - 5

T - 9

T - 6

Test - 1 (T - 1)Test - 2 (T - 2)Test - 3 (T - 3)Test - 4 (T - 4)Test - 5 (T - 5)Test - 6 (T - 6)Test - 7 (T - 7)Test - 8 (T - 8)Test - 9 (T - 9)

Rationale (if required) for completeness

High-level Design

Subsystem - 1 (SF - 1, SF - 3)Subsystem - 2 (SF - 2, SF - 4)

Low-level Design

Module - 1 (SF - 1, SF - 3)Module - 2 (SF - 2)Module - 3 (SF - 4)

M odule - 2

SF - 3

Subsystem - 2

Module - 1

Module - 3

T - 1 1

Test - 10 (T - 10)

T - 1 0

T - 1 2

Test - 11 (T - 11)Test - 12 (T - 12)

Figure 1.2 A conceptual framework of the depth of testing analysis on the module-level

60/139 AIS 34_3


1.1.9.4 Evaluation of functional tests (ATE_FUN.1)


327 Renumber work units: 4:ATE_FUN.1-x to 5:ATE_FUN.1-x, (x = 1...12)

AIS 34_3 61/139


1.1.9.5 Evaluation of independent testing (ATE_IND.2)


329 Renumber work units: 4:ATE_IND.2-x to 5:ATE_IND.2-x, (x = 1...11)

330 Note on work unit 5:ATE_IND.2-9: At EAL1, independent evaluator tests have to cover all security functions of the TOE as no developer tests are required (see ATE_IND.1-3). At EAL5 completeness has to be guaranteed by developer test. Thus, the evaluator does not necessarily test all functions.

62/139 AIS 34_3


1.1.10 EAL5 Vulnerability assessment activity

331 The purpose of the vulnerability assessment activity is to determine the existence and exploitability of flaws or weaknesses in the TOE in the intended environment. This determination is based upon analysis performed by the developer and the evaluator, and is supported by evaluator testing.

332 Generally, the vulnerability assessment activity covers various vulnerabilities in the construction and operation of the TOE. Construction vulnerabilities take advantage of some property of the TOE which was introduced during its construction, e.g. overcoming, deactivating, bypassing, corrupting, circumventing TSF. Operational vulnerabilities take advantage of weaknesses in non-technical countermeasures to violate the security of the TOE, e.g. misuse or incorrect configuration.

333 Assessment of construction vulnerabilities is covered by the assurance families AVA_VLA, AVA_SOF and AVA_CCA. Basically, all construction vulnerabilities can be considered in the context of AVA_VLA due to the fact, that this family allows application of a wide range of assessment methodologies being unspecific to the kind of an attack scenario.

334 The family AVA_SOF offers a specific methodology for TSF, which can be overcome by the use of sufficient resources, expertise and opportunity in the form of a direct attack. The underlying technical concept of those TSF is based on probabilistic or permutational mechanisms. For those TSF a qualification of their security behaviour and the effort required to overcome them can be made using a quantitative or statistical analysis.

335 The family AVA_CCA offers another specific methodology for those TSF that can cause illicit information flows. For those TSF a channel capacity estimation can be done using informal engineering measurements, as well as actual test measurements.

336 Assessment of operational vulnerabilities is covered by the assurance family AVA_MSU. Misuse investigates whether the TOE can be configured or used in a manner that is insecure but that an administrator or user of the TOE would reasonably believe to be secure.

337 The methodical relationships between the families of the class AVA are depicted below:

AVA

VLA

MSU

VLA-unspecific

SOF

CCA

338 The vulnerability assessment activity at EAL5 contains sub-activities related to the following components:

a) AVA_CCA.1

b) AVA_MSU.2;

c) AVA_SOF.1;

d) AVA_VLA.3.Changes from EAL 4 (AVA_VLA.2) is moderate attack potential.

1.1.10.1 Evaluation of covert channel analysis (AVA_CCA.1)


339 The objectives of this sub-activity are to determine whether the TOE is implemented in such a way that permits unintended yet exploitable signalling channels to violate the

AIS 34_3 63/139


TSP. The AVA_CCA.1 addresses covert channels that are identifiable, through an informal search for covert channels.


340 The TOE resources processes and stores information represented by user data. This information (i) may flow with the user data between objects by internal TOE transfer, inter-TSF transfers or transfer outside TSF control and (ii) may be generated and passed to other user data. It is one of the aspects of an information control policy to address common information function issues on operations, causing the information under control of the policy to flow from and to controlled subjects covered by the policy. The other aspect is the illicit information flow addressed by the covert channel analysis. This aspect is more general than the direct access to objects containing user data addressed by the FDP_ACC and FDP_ACF families. Information is a more abstract view on relation between the properties of entities, i.e. a signal contains information for a system, if this is able to react to this signal. An unenforced signalling channel carrying information under control of the information flow control policy can also be caused by observation of the processing of any object containing or related to this information (e.g. side channels). An enforced signalling channels may be identified in terms of the resources that are manipulated and the entities that make or detect such manipulation. Classically, covert channels have been identified as timing or storage channels, according to the resource being modified or modulated.

341 Channel capacity estimations are based upon informal engineering measurements, as well as actual test measurements.

342 Examples of assumptions upon which the covert channel analysis is based may include processor speed, system or network configuration, memory size, and cache size.

343 The selective validation of the covert channel analysis through testing allows the evaluator the opportunity to verify any aspect of the covert channel analysis (e.g. identification, capacity estimation, elimination, monitoring, and exploitation scenarios). This does not impose a requirement to demonstrate the entire set of covert channel analysis results.

344 If there are no information flow control SFPs in the ST, this family of assurance requirements is no longer applicable, as this family applies only to information flow control SFPs. Note if the ST claims FDP_IFF.5, the AVA_CCA.1 is not applicable without an accepted valid rationale.

345 The FDP_IFF.1 and FDP_IFF.2 have no dependency on AVA_CCA.1. Supposing the ST claims the SFR FDP_IFF.1 or FDP_IFF.2 as the only SFRs from the FDP_IFF family, then it is sufficient either to determine the absence of an applicable covert channel (channel capacity = 0, cf. AVA_CCA.1.4C) or if the covert channel analysis estimates a positive capacity of a type of illicit information flow, the conclusion, whether these functional requirements are met (cf. AVA_CCA.1.2E), depends on the decision, whether the relevant security objectives are actually reached.

1.1.10.1.3 Input


a) the ST;


c) the TOE security policy model;

d) the high-level design;

e) the low-level design;

f) the implementation representation;

g) the user guidance;

64/139 AIS 34_3


h) the administrator guidance;

i) the covert channel analysis documentation;

j) the TOE suitable for testing.



a) AVA_CCA.1.1E.

b) AVA_CCA.1.2E.

c) AVA_CCA.1.3E.

Action AVA_CCA.1.1E

AVA_CCA.1.1C(The analysis documentation shall identify covert channels and estimate their capacity.)

5:AVA_CCA.1-1 The evaluator shall check the covert channel analysis documentation to determine that it identifies covert channels.

348 Check the covert channel analysis to determine that it identifies covert channels with reference to the information flow control policies as defined in the ST by SFR of the FDP_IFC family:

- If the ST does not define any SFR of the family FDP_IFC then the AVA_CCA.1 is not applicable.

- If the ST defines a SFR of the family FDP_IFC then the evaluator check whether the covert channel analysis documentation provided by the developer address the information flow control policy.

If the ST claims FDP_IFF.5 then the dependency on AVA_CCA.3 shall be fulfilled. Otherwise a reasonable rationale shall be provided.

349 The covert channel analysis documentation will cover the SFP identified by the FDP_IFC component if it identifies illicit information flow violating the information flow control SFP in terms of the subjects under control of the policy, the information under control of the policy, and operations which cause illicit information to flow to and from controlled subjects covered by the policy.

5:AVA_CCA.1-2 The evaluator shall check the covert channel analysis documentation to determine that it estimates the capacity of the covert channels.

350 Capacities are typically expressed in terms of bits per second or bits per operation which cause the illicit information flow.

351 Note if the ST claims the SFR FDP_IFF.3, FDP_IFF.4 or FDP_IFF.6 it shall define maximum capacity for types of illicit information flaws by assignment. If the ST claims SFR FDP_IFF.5 any covert channel identified by this SFR with positive capacity will violate the SFP of this SFR. If the ST claims SFR FDP_IFF.1 or FDP_IFF.2 only, a covert channel identified by these SFR with positive capacity may violate the SFP of this SFR (see AVA_CCA.1-8).

AVA_CCA.1.2C(The analysis documentation shall describe the procedures used for determining the existence of covert channels, and the information needed to carry out the covert channel analysis.)

5:AVA_CCA.1-3 The evaluator shall examine the covert channel analysis documentation to determine that it describes the procedures used to determine the existence of covert channels.

AIS 34_3 65/139


352 The procedures used may be manual procedures, automated tools, or a combination. Any manual procedures are described in the documentation. Any automated tools are identified and either described or referenced.

5:AVA_CCA.1-4 The evaluator shall examine the covert channel analysis documentation to determine that it describes the information needed to conduct the covert channel analysis.

353 The information used in conducting the covert channel analysis comes from such sources as system reference manuals containing descriptions of TSF primitives, CPU and I/O processor instructions, their effects on system objects and registers, TSF parameters or instruction fields, and so on; the high-level design, low-level design, and functional specification; and TSF source code and processor-instruction (micro) code.

AVA_CCA.1.3C(The analysis documentation shall describe all assumptions made during the covert channel analysis.)

5:AVA_CCA.1-5 The evaluator shall examine the covert channel analysis documentation to determine that it describes the assumptions made during the covert channel analysis.

354 The analysis documentation includes all factors that affect the calculation or implementation of the covert channels. Such factors include the assumed noiselessness of the channel, the aggregation of the data variables used to implement the channel, and any encoding that is used to transmit information through the channel.

AVA_CCA.1.4C(The analysis documentation shall describe the method used for estimating channel capacity, based on worst case scenarios.)

5:AVA_CCA.1-6 The evaluator shall examine the covert channel analysis documentation to determine that it describes the method used to estimate the capacity of the covert channels.

355 The method used may be manual calculations, automated tools, or a combination. Any manual calculations are described in the documentation. Any automated tools are identified and either described or referenced.

356 If the ST claims functional requirements FDP_IFF.1 or FDP_IFF.2 only, then it is sufficient to determine the absence of an applicable covert channel (channel capacity = 0). This determination shall make use of state of the art assessment techniques in the context of the attack potential considered under AVA_VLA.

AVA_CCA.1.5C(The analysis documentation shall describe the worst case exploitation scenario for each identified covert channel.)

5:AVA_CCA.1-7 The evaluator shall examine the covert channel analysis documentation to determine that it describes the worst-case exploitation scenario for each covert channel.

357 Worst case refers to the most efficient implementation of a channel (which yields the greatest bandwidth). While the theoretical worst case bandwidth may not be realised in practice, the scenario producing such results is nevertheless described.

AVA_CCA.1.2E

(The evaluator shall confirm that the results of the covert channel analysis show that the TOE meets its functional requirements.)

5:AVA_CCA.1-8 The evaluator shall examine the covert channel analysis documentation to determine that the TOE meets its functional requirements.

66/139 AIS 34_3


358 The covert channel analysis documentation will cover the SFP identified by the FDP_IFC component if it identifies illicit information flow violating the information flow control SFP in terms of the subjects under control of the policy, the information under control of the policy, and operations which cause illicit information to flow to and from controlled subjects covered by the policy.

359 The FDP_IFF requirements shall be verified to ensure that they take into account the covert channels as described in the covert channel analysis documentation.

- If the ST claims components FDP_IFF.3 the covert channel analysis shall confirm that the capacity of the found illicit information flow does not exceed the defined maximum capacity assigned for this type of illicit information flow.

- If the ST claims components FDP_IFF.4 the covert channel analysis shall confirm that the capacity of the found illicit information flow does not exceed the defined maximum capacity assigned for this type of illicit information flow in FDP_IFF.4.1 and does not found any illicit information flow of types identified in FDP_IFF.4.2.

- If the ST claims components FDP_IFF.6 the covert channel analysis shall confirm that all illicit information flow which exceeds the defined maximum capacity are monitored.

However, assignments in FDP_IFF.1 and FDP_IFF.2 might be written in such a way that covert channels would have an impact on them as well. In this case, if the covert channel analysis estimates a positive capacity of a type of illicit information flow, the conclusion, whether these functional requirements are met, depends on the decision, whether the relevant security objectives are actually reached.

360 Similarly, the audit requirements might also be affected by the presence of the covert channel analysis. For example, the use of resources that implement covert channels might be auditable events, in which case they would be expected to be listed in FAU_GEN.

361 Fulfilment of other functional requirements may likewise be affected by covert channels (e.g. FDP_ETC, FDP_ITC, FDP_ITT, FDP_ROL, FDP_UCT, FDP_UIT, also FMT_MSA, FPT_SEP).

AVA_CCA.1.3E

(The evaluator shall selectively validate the covert channel analysis through testing.)

5:AVA_CCA.1-9 The evaluator shall test a selection of the covert channels.

362 Testing of the covert channel analysis provides the opportunity to verify the identification, capacity estimation, elimination, monitoring, and exploitation scenarios of the covert channels that are identified and described in the covert channel analysis.

5:AVA_CCA.1-10 The evaluator shall produce test documentation for the tests of covert channels, in sufficient detail to enable the tests to be repeatable. The test documentation shall include:

a) identification of the covert channel the TOE being tested;

b) instructions to connect and set-up all required test equipment as required to conduct the test;

c) instructions to establish all test prerequisite initial conditions;

d) instructions to stimulate the TSF;

e) instructions for observing the behaviour of the TSF, among other for measurement of the channel capacity;

AIS 34_3 67/139


f) descriptions of all expected results and the necessary analysis to be performed on the observed behaviour for comparison against expected results;

g) instructions to conclude the test and establish the necessary post-test state for the TOE.

363 The intent of specifying this level of detail in the test documentation is to allow another evaluator to repeat the tests and obtain an equivalent result.

68/139 AIS 34_3


1.1.10.2 Evaluation of misuse (AVA_MSU.2)


365 Renumber work units: 4:AVA_MSU.2-x to 5:AVA_MSU.2-x, (x = 1...10)

AIS 34_3 69/139


1.1.10.3 Evaluation of strength of TOE security functions (AVA_SOF.1)


367 Renumber work units: 4:AVA_SOF.1-x to 5:AVA_SOF.1-x, (x = 1...8)

70/139 AIS 34_3


1.1.10.4 Evaluation of vulnerability analysis (AVA_VLA.3)


368 The objective of this sub-activity is to determine whether the TOE, in its intended environment, has vulnerabilities exploitable by attackers possessing moderate attack potential.


369 The use of the term guidance in this sub-activity refers to the user guidance, the administrator guidance, and the secure installation, generation, and start-up procedures.

370 The consideration of exploitable vulnerabilities will be determined by the security objectives and functional requirements in the ST. For example, if measures to prevent bypass of the security functions are not required in the ST (FPT_PHP, FPT_RVM and FPT_SEP are absent) then vulnerabilities based on bypass should not be considered.

371 Vulnerabilities may be in the public domain, or not, and may require skill to exploit, or not. These two aspects are related, but are distinct. It should not be assumed that, simply because a vulnerability is in the public domain, it can be easily exploited.

372 The following terms are used in the guidance with specific meaning:

a) Vulnerability - a weakness in the TOE that can be used to violate a security policy in some environment;

b) Vulnerability analysis - A systematic search for vulnerabilities in the TOE, and an assessment of those found to determine their relevance for the intended environment for the TOE;

c) Obvious vulnerability - a vulnerability that is open to exploitation that requires a minimum of understanding of the TOE, technical sophistication and resources;

d) Potential vulnerability - A vulnerability the existence of which is suspected (by virtue of a postulated attack path), but not confirmed, in the TOE;

e) Exploitable vulnerability - A vulnerability that can be exploited in the intended environment for the TOE;

f) Non-exploitable vulnerability - A vulnerability that cannot be exploited in the intended environment for the TOE;

g) Residual vulnerability - A non-exploitable vulnerability that could be exploited by an attacker with greater attack potential than is anticipated in the intended environment for the TOE;

h) Penetration testing - Testing carried out to determine the exploitability of identified TOE potential vulnerabilities in the intended environment for the TOE.

1.1.10.4.3 Input


a) the ST;





f) the architectural description;

AIS 34_3 71/139


g) the TOE security policy model;

h) the user guidance;

i) the administrator guidance;

j) the secure installation, generation, and start-up procedures;

k) the vulnerability analysis;

l) the strength of function claims analysis;

m) the covert channel analysis;

n) the TOE suitable for testing.

o) tests results of functional tests.

374 Other input for this sub-activity is:

a) current information regarding obvious vulnerabilities (e.g. from an overseer).

375 Note: In case of an augmentation of AVA_VLA.3 at lower assurance levels, specific deliverables might not be part of the assurance package used for a TOE evaluation (e.g. Covert Channel Analysis at EAL4). In this case the evaluator has to give a rationale in the evaluation report of why these specific deliverables could not be used for vulnerability analysis.


376 This sub-activity comprises five CC Part 3 evaluator action elements:

a) AVA_VLA.3.1E;

b) AVA_VLA.3.2E;

c) AVA_VLA.3.3E;

d) AVA_VLA.3.4E;

e) AVA_VLA.3.5E.

Action AVA_VLA.3.1E

AVA_VLA.3.1C(The vulnerability analysis documentation shall describe the analysis of the TOE deliverables performed to search for ways in which a user can violate the TSP.)AVA_VLA.3.2C(The vulnerability analysis documentation shall describe the disposition of identified vulnerabilities.)AVA_VLA.3.3C(The vulnerability analysis documentation shall show, for all identified vulnerabilities, that the vulnerability cannot be exploited in the intended environment for the TOE.)AVA_VLA.3.4C(The vulnerability analysis documentation shall justify that the TOE, with the identified vulnerabilities, is resistant to obvious penetration attacks.)

5:AVA_VLA.3-1 The evaluator shall examine the developer’s vulnerability analysis to determine that the search for vulnerabilities has considered all relevant information.

377 The developer’s vulnerability analysis should cover the developer’s search for vulnerabilities in at least all evaluation deliverables and public domain information sources.

378 Information in the public domain is highly dynamic. Therefore, it is possible that new vulnerabilities are reported in the public domain between the time the developer performs the vulnerability analysis and the time that the evaluation is completed. The point at

72/139 AIS 34_3


which monitoring of the public domain information ceases is an evaluation authority issue; therefore guidance and agreement should be sought from the evaluation authority.

379 (*) For public domain sources information on both, breadth and depth of the search is required. E.g. queries for keywords for the TOE, for the type of TOE, for the technology of the TOE and related ones, specific attackers, type of attacks, design techniques, protocols, languages, ...

380 (*) Deviation of test results of functional tests performed in a test environment vs. the operational environment of the TOE might give indications on potential vulnerabilities in the operational environment of the TOE.

5:AVA_VLA.3-2 The evaluator shall examine the developer’s vulnerability analysis to determine that each identified vulnerability is described and that a rationale is given for why it is not exploitable in the intended environment for the TOE.

381 A vulnerability is termed non-exploitable if one or more of the following conditions exist:

a) security functions or measures in the (IT or non-IT) environment prevent exploitation of the vulnerability in the intended environment. For instance, restricting physical access to the TOE to authorized users only may effectively render a TOE’s vulnerability to tampering unexploitable;

b) In the course of determining attack potential necessary to exploit identified vulnerabilities, the rating of a vulnerability considered results in at least "Resistance to attacker with attack potential of moderate" or the vulnerability is exploitable, but only by attackers possessing high attack potential. For instance, a vulnerability requiring detailed design knowledge, and considerable time and skill to exploit, may require an attack potential beyond that of moderate. A rationale shall justify why an attack with less specialised resources is not possible. However, such vulnerabilities are reported in the ETR as residual vulnerabilities;

c) either the threat is not claimed to be countered or the violable organisational security policy is not claimed to be achieved by the ST. For instance, a firewall whose ST makes no availability policy claim and is vulnerable to TCP SYN attacks (an attack on a common Internet protocol that renders hosts incapable of servicing connection requests) should not fail this evaluator action on the basis of this vulnerability alone.

382 For guidance on determining attack potential necessary to exploit a vulnerability see Annex A.8 of CEM [CEM23]Fehler: Referenz nicht gefunden.

5:AVA_VLA.3-3 The evaluator shall examine the developer’s vulnerability analysis to determine that it is consistent with the ST and the guidance.

383 The developer’s vulnerability analysis may address a vulnerability by suggesting specific configurations or settings for TOE functions. If such operating constraints are deemed to be effective and consistent with the ST, then all such configurations/ settings should be adequately described in the guidance so that they may be employed by the consumer.

AVA_VLA.3.5C(The vulnerability analysis documentation shall show that the search for vulnerabilities is systematic.)

5:AVA_VLA.3-4 The evaluator shall examine the developer’s vulnerability analysis to determine that it is systematic.

A vulnerability analysis is considered to be systematic, if it exhibits the following characteristics:

a) it follows a predetermined, planned approach;

b) it is repeatable;

AIS 34_3 73/139


c) it employs a method whereby completeness of the items being relevant for the analysis can be determined.For instant, the developer can consider - for each security function - how it is provided (cf. ADV_LLD.1.6C, ‘security mechanisms’), how it interacts with other TSF and its external visible interfaces (cf. ADV_LLD.1.8C) in order to explore potential vulnerabilities. The found vulnerabilities could also be categorized in another sensible way.

384 An approach based on brainstorming techniques would not meet this requirement unless the results were analysed to ensure that all areas of potential vulnerability had been considered.

Action AVA_VLA.3.2E

(The evaluator shall conduct penetration testing, building on the developer vulnerability analysis, to ensure the identified vulnerabilities have been addressed.)

5:AVA_VLA.3-5 The evaluator shall devise penetration tests, building on the developer vulnerability analysis.

385 The evaluator prepares for penetration testing:

a) as necessary to attempt to disprove the developer’s analysis in cases where the developer’s rationale for why a vulnerability is unexploitable is suspect in the opinion of the evaluator;

b) as necessary to determine the susceptibility of the TOE, in its intended environment, to a vulnerability not considered by the developer. The evaluator should have access to current information (e.g. from the overseer) regarding obvious public domain vulnerabilities that may not have been considered by the developer, and may also have identified potential vulnerabilities as a result of performing other evaluation activities.

386 The evaluator is not expected to test for vulnerabilities (including those in the public domain) beyond those for which a moderate attack potential is required to effect an attack. In many cases, however, it will be necessary to carry out a test before the attack potential required can be determined. Where, as a result of evaluation expertise, the evaluator confirms a vulnerability that is beyond moderate attack potential, this is reported in the ETR as a residual vulnerability.

Editors note: This evaluator action is based on the developer vulnerability analysis. Hence the evaluator can merely confirm, but not discover a vulnerability being beyond moderate attack potential within the current action.

387 With an understanding of the suspected vulnerability, the evaluator determines the most feasible way to test for the TOE’s susceptibility. Specifically the evaluator considers:

a) the security function interfaces that will be used to stimulate the TSF and observe responses;

b) initial conditions that will need to exist for the test (i.e. any particular objects or subjects that will need to exist and security attributes they will need to have);

c) special test equipment that will be required to either stimulate a security function or make observations of a security function.

388 The evaluator will probably find it practical to carry out penetration testing using a series of test cases, where each test case will test for a specific vulnerability.

5:AVA_VLA.3-6 The evaluator shall produce penetration test documentation for the tests that build upon the developer vulnerability analysis, in sufficient detail to enable the tests to be repeatable. The test documentation shall include:

a) identification of the vulnerability the TOE is being tested for;

74/139 AIS 34_3


b) instructions to connect and set-up all required test equipment as required to conduct the penetration test;

c) instructions to establish all penetration test prerequisite initial conditions;


e) instructions for observing the behaviour of the TSF;




5:AVA_VLA.3-7 The evaluator shall conduct penetration testing, building on the developer vulnerability analysis.

390 The evaluator uses the penetration test documentation resulting from work unit 5:AVA_VLA.3-5Fehler: Referenz nicht gefunden as a basis for executing penetration tests on the TOE, but this does not preclude the evaluator from performing additional ad hoc penetration tests. If required, the evaluator may devise ad hoc tests as a result of information learned during penetration testing that, if performed by the evaluator, are to be recorded in the penetration test documentation. Such tests may be required to follow up unexpected results or observations, or to investigate potential vulnerabilities suggested to the evaluator during the pre-planned testing.

5:AVA_VLA.3-8 The evaluator shall record the actual results of the penetration tests.

391 While some specific details of the actual test results may be different from those expected (e.g. time and date fields in an audit record) the overall result should be identical. Any differences should be justified.

5:AVA_VLA.3-9 The evaluator shall report in the ETR the evaluator penetration testing efforts, outlining the testing approach, configuration, depth and results.

392 The penetration testing information reported in the ETR allows the evaluator to convey the overall penetration testing approach and effort expended on this sub-activity. The intent of providing this information is to give a meaningful overview of the evaluator’s penetration testing effort. It is not intended that the information regarding penetration testing in the ETR be an exact reproduction of specific test steps or results of individual penetration tests. The intention is to provide enough detail to allow other evaluators and overseers to gain some insight about the penetration testing approach chosen, amount of penetration testing performed, TOE test configurations, and the overall results of the penetration testing activity.

393 Information that would typically be found in the ETR section regarding evaluator penetration testing efforts is:

a) TOE test configurations. The particular configurations of the TOE that were penetration tested;

b) security functions penetration tested. A brief listing of the security functions that were the focus of the penetration testing;

c) verdict for the sub-activity. The overall judgement on the results of penetration testing.

394 This list is by no means exhaustive and is only intended to provide some context as to the type of information that should be present in the ETR concerning the penetration testing the evaluator performed during the evaluation.

Action AVA_VLA.3.3E

(The evaluator shall perform an independent vulnerability analysis.)

AIS 34_3 75/139


5:AVA_VLA.3-10 The evaluator shall examine all inputs to this sub-activity to determine possible security vulnerabilities not already addressed by the developer’s vulnerability analysis.

395 A flaw hypothesis methodology should be used whereby specifications and documentation for the TOE are analysed and then vulnerabilities in the TOE are hypothesised , or speculated. The list of hypothesised vulnerabilities is then prioritised on the basis of the estimated probability that a vulnerability exists and, assuming a vulnerability does exist, the attack potential required to exploit it, and on the extent of control or compromise it would provide. The prioritised list of potential vulnerabilities is used to direct penetration testing against the TOE.

396 For guidance on determining attack potential necessary to exploit a vulnerability see Annex A.8 of CEM [CEM23]Fehler: Referenz nicht gefunden.

397 Vulnerabilities hypothesised as exploitable only by attackers possessing high attack potential do not result in a failure of this evaluator action. Where analysis supports the hypothesis, these need not be considered further as an input to penetration testing. However, such vulnerabilities are reported in the ETR as residual vulnerabilities.

398 Vulnerabilities hypothesised exploitable by an attacker possessing a moderate attack potential, that do not result in a violation of the security objectives specified in the ST, do not result in a failure of this evaluator action. Where analysis supports the hypothesis, these need not be considered further as an input to penetration testing.

399 Vulnerabilities hypothesised as potentially exploitable by an attacker possessing a low or moderate attack potential and resulting in a violation of the security objectives should be the highest priority potential vulnerabilities comprising the list used to direct penetration testing against the TOE.

400 Subject to the threats being present in the intended environment, the evaluator’s independent vulnerability analysis should consider generic vulnerabilities under each of the following headings:

a) generic vulnerabilities relevant for the type of TOE being evaluated, as may be supplied by the overseer;

b) bypassing;

c) tampering;

d) direct attacks;

e) misuse.

401 Items b) - e) are now explained in greater detail.

Bypassing

402 Bypassing includes any means by which an attacker could avoid security enforcement, by:

a) exploiting the capabilities of interfaces to the TOE, or of utilities which can interact with the TOE;

b) inheriting privileges or other capabilities that should otherwise be denied;

c) (where confidentiality is a concern) reading sensitive data stored or copied to inadequately protected areas.

403 Each of the following should be considered (where relevant) in the evaluator’s independent vulnerability analysis.

a) Attacks based on exploiting the capabilities of interfaces or utilities generally take advantage of the absence of the required security enforcement on those

76/139 AIS 34_3


interfaces. For example, gaining access to functionality that is implemented at a lower level than that at which access control is enforced. Relevant items include:1) changing the predefined sequence of invocation of functions;2) executing an additional function;3) using a component in an unexpected context or for an unexpected purpose;4) using implementation detail introduced in less abstract representations;5) using the delay between time of access check and time of use.

b) Changing the predefined sequence of invocation of components should be considered where there is an expected order in which interfaces to the TOE (e.g. user commands) are called to perform some security function (e.g. opening a file for access and then reading data from it). If a security function is invoked on one of the TOE interfaces (e.g. an access control check), the evaluator should consider whether it is possible to bypass the security function by performing the call at a later point in the sequence or by missing it out altogether.

c) Executing an additional component (in the predefined sequence) is a similar form of attack to the one just described, but involves the calling of some other TOE interface at some point in the sequence. It can also involve attacks based on interception of sensitive data passed over a network by use of network traffic analysers (the additional component here being the network traffic analyser).

d) Using a component in an unexpected context or for an unexpected purpose includes using an unrelated TOE interface to bypass a security function by using it to achieve a purpose that it was not designed or intended to achieve. Covert channels are an example of this type of attack. The use of undocumented interfaces (which may be insecure) also falls into this category (these include undocumented support and help facilities).

e) Using implementation detail introduced in lower representations again includes the use of covert channels in which an attacker takes advantage of additional functions, resources or attributes that are introduced to the TOE as a consequence of the refinement process (e.g. use of a lock variable as a covert channel). Additional functionality may also include test harness code contained in software modules.

f) Using the delay between time of check and time of use includes scenarios where an access control check is made and access granted, and an attacker is subsequently able to create conditions in which, had they applied at the time the access check was made, would have caused the check to fail. An example would be a user creating a background process to read and send highly sensitive data to the user’s terminal, and then logging out and logging back in again at a lower sensitivity level. If the background process is not terminated when the user logs off, the MAC checks would have been effectively bypassed.

g) Attacks based on inheriting privileges are generally based on illicitly acquiring the privileges or capabilities of some privileged component, usually by exiting from it in an uncontrolled or unexpected manner. Relevant items include:1) executing data not intended to be executable, or making it executable;2) generating unexpected input for a component;3) invalidating assumptions and properties on which lower-level components rely.

h) Executing data not intended to be executable, or making it executable includes attacks involving viruses (e.g. putting executable code or commands in a file which are automatically executed when the file is edited or accessed, thus inheriting any privileges the owner of the file has).

AIS 34_3 77/139


i) Generating unexpected input for a component can have unexpected effects which an attacker could take advantage of. For example, if the TOE is an application implementing security functions that could be bypassed if a user gains access to the underlying operating system, it may be possible to gain such access following the login sequence by exploring the effect of hitting various control or escape sequences whilst a password is being authenticated.

j) Invalidating assumptions and properties on which lower level components rely includes attacks based on breaking out of the constraints of an application to gain access to an underlying operating system in order to bypass the security functions implemented by the application. In this case the assumption being invalidated is that it is not possible for a user of the application to gain such access. A similar attack can be envisaged if security functions are implemented by an application on an underlying database management system: again the security functions could be bypassed if an attacker can break out of the constraints of the application.

k) Attacks based on reading sensitive data stored in inadequately protected areas (applicable where confidentiality is a concern) include the following issues which should be considered as possible means of gaining access to sensitive data:1) disk scavenging;2) access to unprotected memory;3) exploiting access to shared writable files or other shared resources (e.g. swap files);4) Activating error recovery to determine what access users can obtain. For example, after a crash an automatic file recovery system may employ a lost and found directory for headerless files, which are on disc without labels. If the TOE implements mandatory access controls, it is important to investigate at what security level this directory is kept (e.g. at system high), and who has access to this directory.

Tampering

404 Tampering includes any attack based on an attacker attempting to influence the behaviour of a security function or mechanism (i.e. corruption or de-activation), for example by:

a) accessing data on whose confidentiality or integrity the security function or mechanism relies;

b) forcing the TOE to cope with unusual or unexpected circumstances;

c) disabling or delaying security enforcement.


a) Attacks based on accessing data on whose confidentiality or integrity the security function or mechanism include:1) reading, writing or modifying internal data directly or indirectly;2) using a component in an unexpected context or for an unexpected purpose;3) using interference between components that are not visible at a higher level of abstraction.

b) Reading, writing or modifying internal data directly or indirectly includes the following types of attack which should be considered:1) reading ‘secrets’ stored internally, such as user passwords;2) spoofing internal data that security enforcing mechanisms rely upon;3) modifying environment variables (e.g. logical names), or data in configuration files or temporary files.

c) It may be possible to hoodwink a trusted process into modifying a protected file that it wouldn’t normally access.

78/139 AIS 34_3


d) The evaluator should also consider the following ‘dangerous features’:1) source code resident on the TOE along with a compiler (for instance, it may be possible to modify the login source code);2) an interactive debugger and patch facility (for instance, it may be possible to modify the executable image);3) the possibility of making changes at device controller level, where file protection does not exist;4) diagnostic code which exists in the source code and that may be optionally included;5) developer’s tools left in the TOE.

e) Using a component in an unexpected context or for an unexpected purpose includes (for example), where the TOE is an application built upon an operating system, users exploiting knowledge of a word processor package or other editor to modify their own command file (e.g. to acquire greater privileges).

f) Using interference between components which are not visible at a higher level of abstraction includes attacks exploiting shared access to resources, where modification of a resource by one component can influence the behaviour of another (trusted) component, e.g. at source code level, through the use of global data or indirect mechanisms such as shared memory or semaphores.

g) Attacks based on forcing the TOE to cope with unusual or unexpected circumstances should always be considered. Relevant items include:1) generating unexpected input for a component;2) invalidating assumptions and properties on which lower-level components rely.

h) Generating unexpected input for a component includes investigating the behaviour of the TOE when:1) command input buffers overflow (possibly ‘crashing the stack’ or overwriting other storage, which an attacker may be able to take advantage of, or forcing a crash dump that may contain sensitive information such as clear-text passwords);2) invalid commands or parameters are entered (including supplying a read-only parameter to an interface which expects to return data via that parameter);3) an end-of-file marker (e.g. CTRL/Z or CTRL/D) or null character is inserted in an audit trail.

i) Invalidating assumptions and properties on which lower-level components rely includes attacks taking advantage of errors in the source code where the code assumes (explicitly or implicitly) that security relevant data is in a particular format or has a particular range of values. In these cases the evaluator should determine whether they can invalidate such assumptions by causing the data to be in a different format or to have different values, and if so whether this could confer advantage to an attacker.

j) The correct behaviour of the security functions may be dependent on assumptions that are invalidated under extreme circumstances where resource limits are reached or parameters reach their maximum value. The evaluator should consider (where practical) the behaviour of the TOE when these limits are reached, for example:1) changing dates (e.g. examining how the TOE behaves when a critical date threshold is passed);2) filling discs;3) exceeding the maximum number of users;4) filling the audit log;5) saturating security alarm queues at a console;6) overloading various parts of a multi-user TOE which relies heavily upon communications components;

AIS 34_3 79/139


7) swamping a network, or individual hosts, with traffic;8) filling buffers or fields.

k) Attacks based on disabling or delaying security enforcement include the following items:1) using interrupts or scheduling functions to disrupt sequencing;2) disrupting concurrence;3) using interference between components which are not visible at a higher level of abstraction.

l) Using interrupts or scheduling functions to disrupt sequencing includes investigating the behaviour of the TOE when:1) a command is interrupted (with CTRL/C, CTRL/Y, etc.);2) a second interrupt is issued before the first is acknowledged.

m) The effects of terminating security critical processes (e.g. an audit daemon) should be explored. Similarly, it may be possible to delay the logging of audit records or the issuing or receipt of alarms such that it is of no use to an administrator (since the attack may already have succeeded).

n) Disrupting concurrence includes investigating the behaviour of the TOE when two or more subjects attempt simultaneous access. It may be that the TOE can cope with the interlocking required when two subjects attempt simultaneous access, but that the behaviour becomes less well defined in the presence of further subjects. For example, a critical security process could be put into a resource-wait state if two other processes are accessing a resource which it requires.

o) Using interference between components which are not visible at a higher level of abstraction may provide a means of delaying a time-critical trusted process.

Direct attacks

406 Direct attack includes the identification of any penetration tests necessary to confirm or disprove the claimed minimum strength of functions. When identifying penetration tests under this heading, the evaluator should also be aware of the possibility of vulnerabilities existing as a result of security mechanisms being susceptible to direct attack.

Misuse

407 Misuse includes the identification of any penetration tests necessary to confirm or disprove the misuse analysis. Issues to be considered include:

a) behaviour of the TOE when start-up, closedown or error recovery is activated;

b) behaviour of the TOE under extreme circumstances (sometimes termed overload or asymptotic behaviour), particularly where this could lead to the de-activation or disabling of a security enforcing function or mechanism;

c) any potential for unintentional misconfiguration or insecure use arising from attacks noted in the section on tampering above.

Action AVA_VLA.3.4E

(The evaluator shall perform independent penetration testing, based on the independent vulnerability analysis, to determine the exploitability of additional identified vulnerabilities in the intended environment.)

5:AVA_VLA.3-11 The evaluator shall devise penetration tests, based on the independent vulnerability analysis.

408 The evaluator prepares for penetration testing based on the prioritised list of vulnerabilities hypothesised in evaluator action AVA_VLA.3.3E.

409 The evaluator is not expected to test for vulnerabilities beyond those for which a moderate attack potential is required to effect an attack. However, as a result of evaluation expertise, the evaluator may discover a vulnerability that is exploitable

80/139 AIS 34_3


only by an attacker with greater than moderate attack potential. Such vulnerabilities are to be reported in the ETR as residual vulnerabilities.





411 The evaluator will probably find it practical to carry out penetration test using a series of test cases, where each test case will test for a specific vulnerability.

5:AVA_VLA.3-12 The evaluator shall produce penetration test documentation for the tests based on the independent vulnerability analysis, in sufficient detail to enable the tests to be repeatable. The test documentation shall include:

a) identification of the obvious vulnerability the TOE is being tested for;








5:AVA_VLA.3-13 The evaluator shall conduct penetration testing, based on the independent vulnerability analysis.

413 The evaluator uses the penetration test documentation resulting from work unit 5:AVA_VLA.3-11 as a basis for executing penetration tests on the TOE, but this does not preclude the evaluator from performing additional ad hoc penetration tests. If required, the evaluator may devise new tests as a result of information learned during penetration testing that, if performed by the evaluator, are to be recorded in the penetration test documentation. Such tests may be required to follow up unexpected results or observations, or to investigate potential vulnerabilities suggested to the evaluator during the pre-planned testing.

414 Should penetration testing show that a hypothesised vulnerability does not exist, then the evaluator should determine whether or not the evaluator’s own analysis was incorrect, or if evaluation deliverables are incorrect or incomplete.



5:AVA_VLA.3-15 The evaluator shall report in the ETR the evaluator penetration testing effort, outlining the testing approach, configuration, depth and results.

AIS 34_3 81/139








Action AVA_VLA.3.5E

(The evaluator shall determine that the TOE is resistant to penetration attacks performed by an attacker possessing a moderate attack potential)

5:AVA_VLA.3-16The evaluator shall examine the results of all penetration testing and the conclusions of all vulnerability analysis to determine that the TOE, in its intended environment, is resistant to an attacker possessing a moderate attack potential.

419 If the results reveal that the TOE, in its intended environment, has vulnerabilities exploitable by an attacker possessing less than a high attack potential, then this evaluator action fails.

5:AVA_VLA.3-17 The evaluator shall report in the ETR all exploitable vulnerabilities and residual vulnerabilities, detailing for each:

a) its source (e.g. CEM activity being undertaken when it was conceived, known to the evaluator, read in a publication);

b) the implicated security function(s), objective(s) not met, organisational security policy(ies) contravened and threat(s) realised;

c) a description;

d) whether it is exploitable in its intended environment or not (i.e. exploitable or residual);

e) identification of evaluation party (e.g. developer, evaluator) who identified it.

82/139 AIS 34_3


1.2 Frequently used assurance components for EAL5 augmented evaluation

1.2.1 Life cycle support activity

1.2.1.1 Evaluation of development security (ALC_DVS.2)

420 The objective of this sub-activity is to determine whether the developer’s security controls on the development environment are adequate to provide the confidentiality and integrity of the TOE design and implementation that is necessary to ensure that secure operation of the TOE is not compromised. Additionally, sufficiency of the measures as applied is intended be justified. Change compared to ALC_DVS.1 is a justification for sufficiency of the measures.

1.2.1.1.1 Input


a) the ST;

b) the development security documentation;

c) a rationale for justification of the measures.

422 In addition, the evaluator may need to examine other deliverables to determine that the security controls are well-defined and followed. Specifically, the evaluator may need to examine the developer’s configuration management documentation (the input for the ACM_CAP.x and ACM_SCP.x sub-activities). Evidence that the procedures are being applied is also required.



a) ALC_DVS.2.1E;

b) ALC_DVS.2.2E.

Action ALC_DVS.2.1E

ALC_DVS.2.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 design and implementation in its development environment.)

6:ALC_DVS.2-1 The evaluator shall examine the development security documentation to determine that it details all security measures used in the development environment that are necessary to protect the confidentiality and integrity of the TOE design and implementation.

424 The evaluator determines what is necessary by first referring to the ST for any information that may assist in the determination of necessary protection, especially the sections on threats, organisational security policies and assumptions, although there may be no information provided explicitly. The statement of security objectives for the environment may also be useful in this respect.

425 If no explicit information is available from the ST the evaluator will need to make a determination of the necessary measures, based upon a consideration of the intended environment for the TOE. In cases where the developer’s measures are considered less than what is necessary, a clear justification should be provided for the assessment, based on a potential exploitable vulnerability.

426 The following types of security measures are considered by the evaluator when examining the documentation:

AIS 34_3 83/139


a) physical, for example physical access controls used to prevent unauthorized access to the TOE development environment (during normal working hours and at other times);

b) procedural, for example covering:

- granting of access to the development environment or to specific parts of the environment such as development machines- revocation of access rights when a person leaves the development team - transfer of protected material out of the development environment- admitting and escorting visitors to the development environment- roles and responsibilities in ensuring the continued application of security

measures, and the detection of security breaches.

c) personnel, for example any controls or checks made to establish the trustworthiness of new development staff;

d) other security measures, for example the logical protections on any development machines.

427 The development security documentation should identify the locations at which development occurs, and describe the aspects of development performed, along with the security measures applied at each location. For example, development could occur at multiple facilities within a single building, multiple buildings at the same site, or at multiple sites. Development includes such tasks as creating multiple copies of the TOE, where applicable. This work unit should not overlap with those for ADO_DEL, but the evaluator should ensure that all aspects are covered by one sub-activity or the other.

428 In addition, the development security documentation may describe different security measures that can be applied to different aspects of development in terms of their performance and the required inputs and outputs. For example, different procedures may be applicable to the development of different portions of the TOE, or to different stages of the development process.

6:ALC_DVS.2-2 The evaluator shall examine the development confidentiality and integrity policies in order to determine the sufficiency of the security measures employed.

429 These include the policies governing:

a) what information relating to the TOE development needs to be kept confidential, and which members of the development staff are allowed to access such material;

b) what material must be protected from unauthorized modification in order to preserve the integrity of the TOE, and which members of the development staff are allowed to modify such material.

430 The evaluator should determine that these policies are described in the development security documentation, that the security measures employed are consistent with the policies, and that they are complete.

431 It should be noted that configuration management procedures will help protect the integrity of the TOE and the evaluator should avoid overlap with the work units conducted for the ACM_CAP sub-activity. For example, the CM documentation may describe the security procedures necessary for controlling the roles or individuals who should have access to the development environment and who may modify the TOE.

432 Whereas the ACM_CAP requirements are fixed, those for ALC_DVS, mandating only necessary measures, are dependent on the nature of the TOE, and on information that may be provided in the Security Environment section of the ST. For example, the ST may identify an organisational security policy that requires the TOE to be developed by staff who have security clearance. The evaluators would then determine that such a policy had been applied under this sub-activity.

84/139 AIS 34_3


ALC_DVS.2.2C(The development security documentation shall provide evidence that these security measures are followed during the development and maintenance of the TOE.)

6:ALC_DVS.2-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.

433 Where documentary evidence is produced the evaluator inspects it to ensure compliance with procedures. Examples of the evidence produced may include entry logs and audit trails. The evaluator may choose to sample the evidence.


ALC_DVS.2.3C(The evidence shall justify that the security measures provide the necessary level of protection to maintain the confidentiality and integrity of the TOE.)

6:ALC_DVS.2-4 The evaluator shall examine the development security documentation to determine that an appropriate justification is given why the security measures provide the necessary level of protection to maintain the confidentiality and integrity of the TOE.

435 Since attacks on the TOE or its related information are assumed in different design and production stages, measures and procedures need to have an appropriate level necessary to prevent those attacks or to make them more difficult.

436 Since this level depends on the overall attack potential claimed for the TOE (cf. AVA_VLA.x chosen), the development security documentation shall justify the necessary level of protection to maintain the confidentiality and integrity of the TOE. This level has to be achieved by the security measures applied.

437 The concept of protection measures shall be consistent, and the justification shall include an analysis of how the measures are mutually supportive. All aspects of development and production on all the different sites with all roles involved up to delivery of the TOE shall be analysed.

438 Justification may include an analysis of potential vulnerabilities taking the applied security measures into account.

439 There may be a convincing argument showing e.g.

- that the technical measures and mechanisms of the developer’s infrastructure are sufficient for keeping the appropriate security level (e.g. cryptographic mechanisms as well as physical protection mechanisms, properties of the CM system (cf. 5:ACM_CAP.4-15));

- that the system containing the master copy of the TOE (including concerning guidance documents) provides effective protection against logical attacks e. g. by ‘trojan’ code or viruses. It might be adequate, if the master copy is kept on an isolated system where only the software necessary to maintain this master copy is installed and where no additional software is installed afterwards;

- Data brought into this system should be well considered to avoid that hidden functionality is installed on the system. The effectiveness of these measures should be tested, e.g. by independent trying to get access to the machine, install some additional executable (program, macro etc.) or manage to get some information out of the machine using logical attacks;

- The appropriate organisational (procedural and personal) measures are unconditionally enforced.

Action ALC_DVS.2.2E

AIS 34_3 85/139


(The evaluator shall confirm that the security measures are being applied.)

6:ALC_DVS.2-5 The evaluator shall examine the development security documentation and associated evidence to determine that the security measures are being applied.

440 This work unit requires the evaluator to determine that the security measures described in the development security documentation are being followed, such that the integrity of the TOE and the confidentiality of associated documentation is being adequately protected. For example, this could be determined by examination of the documentary evidence provided. Documentary evidence should be supplemented by visiting the development environment. A visit to the development environment will allow the evaluator to:

a) observe the application of security measures (e.g. physical measures);

b) examine documentary evidence of application of procedures;

c) interview development staff to check awareness of the development security policies and procedures, and their responsibilities.

441 A development site visit is a useful means of gaining confidence in the measures being used. Any decision not to make such a visit should be determined in consultation with the overseer.

442 For guidance on site visits see Annex A.5 of CEM [CEM23] and, if available, additional guidance of the Scheme.

86/139 AIS 34_3


1.2.2 Vulnerability assessment activity

1.2.2.1 Evaluation of misuse (AVA_MSU.3)

443 Change compared to AVA_MSU.2 is analysis and testing for insecure states.

444 CEM for EAL4 is applicable for work units 1 to 10.

445 Renumber work units: 4:AVA_MSU.2-x to 6:AVA_MSU.3-x, (x = 1...10)

446 For action AVA_MSU.3.5E new work units are needed as defined below.

Action AVA_MSU.3.5E

(The evaluator shall perform independent testing to determine that an administrator or user, with an understanding of the guidance documentation, would reasonably be able to determine if the TOE is configured and operating in a manner that is insecure.)

6:AVA_MSU.3-11 The evaluator shall devise independent misuse tests based on the guidance documentation to determine, whether an administrator or user will be able to detect if the TOE is configured and operating in a manner that is insecure.

447 The evaluator frames test cases and testing strategy being appropriate for the TOE.

448 With an understanding of the expected behaviour of the TOE under a concrete configuration the evaluator has to determine the most feasible way to test for the TOE’s misuse. All TOE configurations and modes of operation being part of the evaluation have to be considered, but sampling of misuse testing is allowed. The most critical aspects have to be covered. In case of a sampling a rationale has to be provided.

6:AVA_MSU.3-12 The evaluator shall produce misuse test documentation for the misuse test subset in sufficient details to enable the tests to be repeatable.

449 The test documentation shall include:

a) an exact identification of the TOE configuration and the mode of operation being under test;

b) an unambiguous identification of the relevant guidance documentation for the specific test;

c) instructions for observing the behaviour of the TSF and for determining a secure or insecure state of the TOE;

d) information on what the expected secure or insecure state of the TOE is.


6:AVA_MSU.3-13 The evaluator shall conduct independent misuse testing.

451 The evaluator uses the misuse test documentation resulting from the previous work unit as a basis for executing independent misuse tests on the TOE.

6:AVA_MSU.3-14 The evaluator shall record the actual results of the misuse tests.

452 While some specific details of the actual test results may be different from those expected the overall result should be identical. Any differences in terms of insecure states of the TOE should be justified.

453 In case of an identified insecure state of the TOE, consequences for guidance documentation or TOE design have to be determined in order to enforce that an administrator or user, with an understanding of the guidance documentation, will reasonably be able to determine if the TOE is configured and operating in a manner that is insecure.

AIS 34_3 87/139


1.2.2.2 Evaluation of vulnerability analysis (AVA_VLA.4)


454 The objective of this sub-activity is to determine whether the TOE, in its intended environment, has vulnerabilities exploitable by attackers possessing high attack potential. Change compared to AVA_VLA.3 is high attack potential.


455 The use of the term guidance in this sub-activity refers to the user guidance, the administrator guidance, and the secure installation, generation, and start-up procedures.

456 The consideration of exploitable vulnerabilities will be determined by the security objectives and functional requirements in the ST. For example, if measures to prevent bypass of the security functions are not required in the ST (FPT_PHP, FPT_RVM and FPT_SEP are absent) then vulnerabilities based on bypass should not be considered.

457 Vulnerabilities may be in the public domain, or not, and may require skill to exploit, or not. These two aspects are related, but are distinct. It should not be assumed that, simply because a vulnerability is in the public domain, it can be easily exploited.

458 The following terms are used in the guidance with specific meaning:

a) Vulnerability - a weakness in the TOE that can be used to violate a security policy in some environment;

b) Vulnerability analysis - A systematic search for vulnerabilities in the TOE, and an assessment of those found to determine their relevance for the intended environment for the TOE;

c) Obvious vulnerability - a vulnerability that is open to exploitation that requires a minimum of understanding of the TOE, technical sophistication and resources;

d) Potential vulnerability - A vulnerability the existence of which is suspected (by virtue of a postulated attack path), but not confirmed, in the TOE;

e) Exploitable vulnerability - A vulnerability that can be exploited in the intended environment for the TOE;

f) Non-exploitable vulnerability - A vulnerability that cannot be exploited in the intended environment for the TOE;

g) Residual vulnerability - A non-exploitable vulnerability that could be exploited by an attacker with greater attack potential than is anticipated in the intended environment for the TOE;

h) Penetration testing - Testing carried out to determine the exploitability of identified TOE potential vulnerabilities in the intended environment for the TOE.

1.2.2.2.3 Input


a) the ST;





f) the architectural description;

88/139 AIS 34_3


g) the TOE security policy model;

h) the user guidance;

i) the administrator guidance;

j) the secure installation, generation, and start-up procedures;

k) the vulnerability analysis;

l) the strength of function claims analysis;

m) the covert channel analysis;

n) the TOE suitable for testing;

o) tests results of functional tests.


a) current information regarding obvious vulnerabilities (e.g. from an overseer).

461 Note: In case of an augmentation of AVA_VLA.4 at lower assurance levels, specific deliverables might not be part of the assurance package used for a TOE evaluation (e.g. Covert Channel Analysis at EAL4). In this case the evaluator has to give a rationale in the evaluation report of why these specific deliverables could not be used for vulnerability analysis.


462 This sub-activity comprises five CC Part 3 evaluator action elements:

a) AVA_VLA.4.1E;

b) AVA_VLA.4.2E;

c) AVA_VLA.4.3E;

d) AVA_VLA.4.4E;

e) AVA_VLA.4.5E.

Action AVA_VLA.4.1E

AVA_VLA.4.1C(The vulnerability analysis documentation shall describe the analysis of the TOE deliverables performed to search for ways in which a user can violate the TSP.)AVA_VLA.4.2C(The vulnerability analysis documentation shall describe the disposition of identified vulnerabilities.)AVA_VLA.4.3C(The vulnerability analysis documentation shall show, for all identified vulnerabilities, that the vulnerability cannot be exploited in the intended environment for the TOE.)AVA_VLA.4.4C(The vulnerability analysis documentation shall justify that the TOE, with the identified vulnerabilities, is resistant to obvious penetration attacks. )

6:AVA_VLA.4-1 The evaluator shall examine the developer’s vulnerability analysis to determine that the search for vulnerabilities has considered all relevant information.

463 The developer’s vulnerability analysis should cover the developer’s search for vulnerabilities in at least all evaluation deliverables and public domain information sources.

464 Information in the public domain is highly dynamic. Therefore, it is possible that new vulnerabilities are reported in the public domain between the time the developer performs the vulnerability analysis and the time that the evaluation is completed. The point at

AIS 34_3 89/139


which monitoring of the public domain information ceases is an evaluation authority issue; therefore guidance and agreement should be sought from the evaluation authority.

465 (*) For public domain sources information on both, breadth and depth of the search is required. E.g. queries for keywords for the TOE, for the type of TOE, for the technology of the TOE and related ones, specific attackers, type of attacks, design techniques, protocols, languages, ...

466 (*) Deviation of test results of functional tests performed in a test environment vs. the operational environment of the TOE might give indications on potential vulnerabilities in the operational environment of the TOE.

6:AVA_VLA.4-2 The evaluator shall examine the developer’s vulnerability analysis to determine that each identified vulnerability is described and that a rationale is given for why it is not exploitable in the intended environment for the TOE.

467 A vulnerability is termed non-exploitable if one or more of the following conditions exist:

a) security functions or measures in the (IT or non-IT) environment prevent exploitation of the vulnerability in the intended environment. For instance, restricting physical access to the TOE to authorized users only may effectively render a TOE’s vulnerability to tampering unexploitable;

b) In the course of determining attack potential necessary to exploit identified vulnerabilities, the rating of a vulnerability considered results in at least "Resistance to attacker with attack potential of high" or the vulnerability is exploitable, but only by attackers possessing an attack potential being judged to be beyond normal practicability. A rationale shall justify why an attack with less specialised resources is not possible. However, such vulnerabilities are reported in the ETR as residual vulnerabilities;

c) either the threat is not claimed to be countered or the violable organisational security policy is not claimed to be achieved by the ST. For instance, a firewall whose ST makes no availability policy claim and is vulnerable to TCP SYN attacks (an attack on a common Internet protocol that renders hosts incapable of servicing connection requests) should not fail this evaluator action on the basis of this vulnerability alone.

468 For guidance on determining attack potential necessary to exploit a vulnerability see Annex A.8 of CEM [CEM23].

The following supplemented table (cf. table 4 of [CEM23]) defines the term ‘beyond normal practicability’:

Range of values Resistant to attacker with attack potential of:

SOF rating

<10 No rating

10-17 Low Basic

18-24 Moderate Medium

25-40 High High

≥41 Beyond normal practicability

High

Examples for the usage of the table:

- The evaluator finds an attack path to effect a successful attack using an identified vulnerability with a value of 23 according to CEM A.8.2.3, table 3. As a result of the table above, this rating supports resistance of the TOE against an

90/139 AIS 34_3


attack potential of moderate. But as the attack potential for this successful attack is determined only above moderate (i.e. high), the TOE does not meet a claimed resistance against high attack potential.

- The evaluator finds an attack path which may effect a successful attack with a value of 27 according to CEM A.8.2.3, table 3. To substantiate this value, it is necessary to carry out a penetration test (see 6:AVA_VLA.4-6, 4-12). If in this case the penetration tests confirm a value being at least 25 to effect this attack successfully, the attack potential used is assessed as beyond normal practicability. This result would not contradict a claimed resistance against high attack potential.

- The evaluator finds an attack path to effect a successful attack with a value higher than 40 according to the CEM A.8.2.3, table 3. As a result of the above table, this rating supports resistance of the TOE against an attack potential determined as beyond normal practicability without corroboration by penetration tests. This result would not contradict a claimed resistance against high attack potential.

Note: For the overall determination that the TOE is resistant to penetration attacks performed by an attacker possessing a high attack potential refer to action AVA_VLA.4.5E below.

6:AVA_VLA.4-3 The evaluator shall examine the developer’s vulnerability analysis to determine that it is consistent with the ST and the guidance.

469 The developer’s vulnerability analysis may address a vulnerability by suggesting specific configurations or settings for TOE functions. If such operating constraints are deemed to be effective and consistent with the ST, then all such configurations/ settings should be adequately described in the guidance so that they may be employed by the consumer.

AVA_VLA.4.5C(The vulnerability analysis documentation shall show that the search for vulnerabilities is systematic.)

6:AVA_VLA.4-4 The evaluator shall examine the developer’s vulnerability analysis to determine that it is systematic.

A vulnerability analysis is considered to be systematic, if it exhibits the following characteristics:

a) it follows a predetermined, planned approach;

b) it is repeatable;

c) it employs a method whereby completeness of the items being relevant for the analysis can be determined.For instant, the developer can consider - for each security function - how it is provided (cf. ADV_LLD.1.6C, ‘security mechanisms’), how it interacts with other TSF and its external visible interfaces (cf. ADV_LLD.1.8C) in order to explore potential vulnerabilities. The found vulnerabilities could also be categorized in another sensible way.

470 An approach based on brainstorming techniques would not meet this requirement unless the results were analysed to ensure that all areas of potential vulnerability had been considered.

AVA_VLA.4.6C(The vulnerability analysis documentation shall provide a justification that the analysis completely addresses the TOE deliverables.)

6:AVA_VLA.4-5 The evaluator shall examine the developer’s analysis documentation to determine that a justification is given for why the analysis completely addresses the TOE deliverables.

AIS 34_3 91/139


471 The task of the evaluator is to examine the developer’s justification:

a) whether and how completeness of the usage of deliverables is reached. The evaluator decides that the all TOE deliverables have been addressed, if the developer’s analysis refers each contribution that has to be submitted to the evaluator in the frame of the evaluation assurance package chosen;

b) whether the developer’s strategy for searching for vulnerabilities in the TOE deliverables is reasonably explained and

c) whether the justification shows how all relevant aspects of the deliverables were considered and outlined in the developer’s analysis.

Action AVA_VLA.4.2E

(The evaluator shall conduct penetration testing, building on the developer vulnerability analysis, to ensure the identified vulnerabilities have been addressed.)

6:AVA_VLA.4-6 The evaluator shall devise penetration tests, building on the developer vulnerability analysis.

472 The evaluator prepares for penetration testing:

a) as necessary to attempt to disprove the developer’s analysis in cases where the developer’s rationale for why a vulnerability is unexploitable is suspect in the opinion of the evaluator;

b) as necessary to determine the susceptibility of the TOE, in its intended environment, to a vulnerability not considered by the developer. The evaluator should have access to current information (e.g. from the overseer) regarding obvious public domain vulnerabilities that may not have been considered by the developer, and may also have identified potential vulnerabilities as a result of performing other evaluation activities.

473 The evaluator is not expected to test for vulnerabilities (including those in the public domain) beyond those, for which a high attack potential is required to effect an attack (i.e. those beyond normal practicability). In many cases, however, it will be necessary to carry out a test before the attack potential required can be determined. Where, as a result of evaluation expertise, the evaluator confirms a vulnerability that is beyond normal practicability , this is reported in the ETR as a residual vulnerability.

Editors note: This evaluator action is based on the developer vulnerability analysis. Hence the evaluator can merely confirm, but not discover a vulnerability being beyond high attack potential within the current action.





475 The evaluator will probably find it practical to carry out penetration testing using a series of test cases, where each test case will test for a specific vulnerability.

6:AVA_VLA.4-7 The evaluator shall produce penetration test documentation for the tests that build upon the developer vulnerability analysis, in sufficient detail to enable the tests to be repeatable. The test documentation shall include:

92/139 AIS 34_3


a) identification of the vulnerability the TOE is being tested for;








6:AVA_VLA.4-8 The evaluator shall conduct penetration testing, building on the developer vulnerability analysis.

477 The evaluator uses the penetration test documentation resulting from work unit 6:AVA_VLA.4-6Fehler: Referenz nicht gefunden as a basis for executing penetration tests on the TOE, but this does not preclude the evaluator from performing additional ad hoc penetration tests. If required, the evaluator may devise ad hoc tests as a result of information learned during penetration testing that, if performed by the evaluator, are to be recorded in the penetration test documentation. Such tests may be required to follow up unexpected results or observations, or to investigate potential vulnerabilities suggested to the evaluator during the pre-planned testing.



6:AVA_VLA.4-10 The evaluator shall report in the ETR the evaluator penetration testing efforts, outlining the testing approach, configuration, depth and results.







Action AVA_VLA.4.3E

AIS 34_3 93/139


(The evaluator shall perform an independent vulnerability analysis.)

6:AVA_VLA.4-11 The evaluator shall examine all inputs to this sub-activity to determine possible security vulnerabilities not already addressed by the developer’s vulnerability analysis.

482 A flaw hypothesis methodology should be used whereby specifications and documentation for the TOE are analysed and then vulnerabilities in the TOE are hypothesised , or speculated. The list of hypothesised vulnerabilities is then prioritised on the basis of the estimated probability that a vulnerability exists and, assuming a vulnerability does exist, the attack potential required to exploit it, and on the extent of control or compromise it would provide. The prioritised list of potential vulnerabilities is used to direct penetration testing against the TOE.

483 For guidance on determining attack potential necessary to exploit a vulnerability see Annex A.8 of CEM [CEM23] and supplemented table outlined under work unit AVA_VLA.4-2 above.

484 Vulnerabilities hypothesised as exploitable only by attackers possessing an attack potential being judged to be beyond normal practicability do not result in a failure of this evaluator action. Where analysis supports the hypothesis, these need not be considered further as an input to penetration testing. However, such vulnerabilities are reported in the ETR as residual vulnerabilities.

485 Vulnerabilities hypothesised exploitable by an attacker possessing a high attack potential, that do not result in a violation of the security objectives specified in the ST, do not result in a failure of this evaluator action. Where analysis supports the hypothesis, these need not be considered further as an input to penetration testing.

486 Vulnerabilities hypothesised as potentially exploitable by an attacker possessing a low, moderate or high (but practical) attack potential and resulting in a violation of the security objectives should be the highest priority potential vulnerabilities comprising the list used to direct penetration testing against the TOE.

487 Subject to the threats being present in the intended environment, the evaluator’s independent vulnerability analysis should consider generic vulnerabilities under each of the following headings:

a) generic vulnerabilities relevant for the type of TOE being evaluated, as may be supplied by the overseer;

b) bypassing;

c) tampering;

d) direct attacks;

e) misuse.

488 Items b) - e) are now explained in greater detail.

Bypassing

489 Bypassing includes any means by which an attacker could avoid security enforcement, by:

a) exploiting the capabilities of interfaces to the TOE, or of utilities which can interact with the TOE;

b) inheriting privileges or other capabilities that should otherwise be denied;

c) (where confidentiality is a concern) reading sensitive data stored or copied to inadequately protected areas.


94/139 AIS 34_3


a) Attacks based on exploiting the capabilities of interfaces or utilities generally take advantage of the absence of the required security enforcement on those interfaces. For example, gaining access to functionality that is implemented at a lower level than that at which access control is enforced. Relevant items include:1) changing the predefined sequence of invocation of functions;2) executing an additional function;3) using a component in an unexpected context or for an unexpected purpose;4) using implementation detail introduced in less abstract representations;5) using the delay between time of access check and time of use.

b) Changing the predefined sequence of invocation of components should be considered where there is an expected order in which interfaces to the TOE (e.g. user commands) are called to perform some security function (e.g. opening a file for access and then reading data from it). If a security function is invoked on one of the TOE interfaces (e.g. an access control check), the evaluator should consider whether it is possible to bypass the security function by performing the call at a later point in the sequence or by missing it out altogether.

c) Executing an additional component (in the predefined sequence) is a similar form of attack to the one just described, but involves the calling of some other TOE interface at some point in the sequence. It can also involve attacks based on interception of sensitive data passed over a network by use of network traffic analysers (the additional component here being the network traffic analyser).

d) Using a component in an unexpected context or for an unexpected purpose includes using an unrelated TOE interface to bypass a security function by using it to achieve a purpose that it was not designed or intended to achieve. Covert channels are an example of this type of attack. The use of undocumented interfaces (which may be insecure) also falls into this category (these include undocumented support and help facilities).

e) Using implementation detail introduced in lower representations again includes the use of covert channels in which an attacker takes advantage of additional functions, resources or attributes that are introduced to the TOE as a consequence of the refinement process (e.g. use of a lock variable as a covert channel). Additional functionality may also include test harness code contained in software modules.

f) Using the delay between time of check and time of use includes scenarios where an access control check is made and access granted, and an attacker is subsequently able to create conditions in which, had they applied at the time the access check was made, would have caused the check to fail. An example would be a user creating a background process to read and send highly sensitive data to the user’s terminal, and then logging out and logging back in again at a lower sensitivity level. If the background process is not terminated when the user logs off, the MAC checks would have been effectively bypassed.

g) Attacks based on inheriting privileges are generally based on illicitly acquiring the privileges or capabilities of some privileged component, usually by exiting from it in an uncontrolled or unexpected manner. Relevant items include:1) executing data not intended to be executable, or making it executable;2) generating unexpected input for a component;3) invalidating assumptions and properties on which lower-level components rely.

h) Executing data not intended to be executable, or making it executable includes attacks involving viruses (e.g. putting executable code or commands in a file

AIS 34_3 95/139


which are automatically executed when the file is edited or accessed, thus inheriting any privileges the owner of the file has).

i) Generating unexpected input for a component can have unexpected effects which an attacker could take advantage of. For example, if the TOE is an application implementing security functions that could be bypassed if a user gains access to the underlying operating system, it may be possible to gain such access following the login sequence by exploring the effect of hitting various control or escape sequences whilst a password is being authenticated.

j) Invalidating assumptions and properties on which lower level components rely includes attacks based on breaking out of the constraints of an application to gain access to an underlying operating system in order to bypass the security functions implemented by the application. In this case the assumption being invalidated is that it is not possible for a user of the application to gain such access. A similar attack can be envisaged if security functions are implemented by an application on an underlying database management system: again the security functions could be bypassed if an attacker can break out of the constraints of the application.

k) Attacks based on reading sensitive data stored in inadequately protected areas (applicable where confidentiality is a concern) include the following issues which should be considered as possible means of gaining access to sensitive data:1) disk scavenging;2) access to unprotected memory;3) exploiting access to shared writable files or other shared resources (e.g. swap files);4) Activating error recovery to determine what access users can obtain. For example, after a crash an automatic file recovery system may employ a lost and found directory for headerless files, which are on disc without labels. If the TOE implements mandatory access controls, it is important to investigate at what security level this directory is kept (e.g. at system high), and who has access to this directory.

Tampering

491 Tampering includes any attack based on an attacker attempting to influence the behaviour of a security function or mechanism (i.e. corruption or de-activation), for example by:

a) accessing data on whose confidentiality or integrity the security function or mechanism relies;

b) forcing the TOE to cope with unusual or unexpected circumstances;

c) disabling or delaying security enforcement.


a) Attacks based on accessing data on whose confidentiality or integrity the security function or mechanism include:1) reading, writing or modifying internal data directly or indirectly;2) using a component in an unexpected context or for an unexpected purpose;3) using interference between components that are not visible at a higher level of abstraction.

b) Reading, writing or modifying internal data directly or indirectly includes the following types of attack which should be considered:1) reading ‘secrets’ stored internally, such as user passwords;2) spoofing internal data that security enforcing mechanisms rely upon;3) modifying environment variables (e.g. logical names), or data in configuration files or temporary files.

96/139 AIS 34_3


c) It may be possible to hoodwink a trusted process into modifying a protected file that it wouldn’t normally access.

d) The evaluator should also consider the following ‘dangerous features’:1) source code resident on the TOE along with a compiler (for instance, it may be possible to modify the login source code);2) an interactive debugger and patch facility (for instance, it may be possible to modify the executable image);3) the possibility of making changes at device controller level, where file protection does not exist;4) diagnostic code which exists in the source code and that may be optionally included;5) developer’s tools left in the TOE.

e) Using a component in an unexpected context or for an unexpected purpose includes (for example), where the TOE is an application built upon an operating system, users exploiting knowledge of a word processor package or other editor to modify their own command file (e.g. to acquire greater privileges).

f) Using interference between components which are not visible at a higher level of abstraction includes attacks exploiting shared access to resources, where modification of a resource by one component can influence the behaviour of another (trusted) component, e.g. at source code level, through the use of global data or indirect mechanisms such as shared memory or semaphores.

g) Attacks based on forcing the TOE to cope with unusual or unexpected circumstances should always be considered. Relevant items include:1) generating unexpected input for a component;2) invalidating assumptions and properties on which lower-level components rely.

h) Generating unexpected input for a component includes investigating the behaviour of the TOE when:1) command input buffers overflow (possibly ‘crashing the stack’ or overwriting other storage, which an attacker may be able to take advantage of, or forcing a crash dump that may contain sensitive information such as clear-text passwords);2) invalid commands or parameters are entered (including supplying a read-only parameter to an interface which expects to return data via that parameter);3) an end-of-file marker (e.g. CTRL/Z or CTRL/D) or null character is inserted in an audit trail.

i) Invalidating assumptions and properties on which lower-level components rely includes attacks taking advantage of errors in the source code where the code assumes (explicitly or implicitly) that security relevant data is in a particular format or has a particular range of values. In these cases the evaluator should determine whether they can invalidate such assumptions by causing the data to be in a different format or to have different values, and if so whether this could confer advantage to an attacker.

j) The correct behaviour of the security functions may be dependent on assumptions that are invalidated under extreme circumstances where resource limits are reached or parameters reach their maximum value. The evaluator should consider (where practical) the behaviour of the TOE when these limits are reached, for example:1) changing dates (e.g. examining how the TOE behaves when a critical date threshold is passed);2) filling discs;3) exceeding the maximum number of users;4) filling the audit log;

AIS 34_3 97/139


5) saturating security alarm queues at a console;6) overloading various parts of a multi-user TOE which relies heavily upon communications components;7) swamping a network, or individual hosts, with traffic;8) filling buffers or fields.

k) Attacks based on disabling or delaying security enforcement include the following items:1) using interrupts or scheduling functions to disrupt sequencing;2) disrupting concurrence;3) using interference between components which are not visible at a higher level of abstraction.

l) Using interrupts or scheduling functions to disrupt sequencing includes investigating the behaviour of the TOE when:1) a command is interrupted (with CTRL/C, CTRL/Y, etc.);2) a second interrupt is issued before the first is acknowledged.

m) The effects of terminating security critical processes (e.g. an audit daemon) should be explored. Similarly, it may be possible to delay the logging of audit records or the issuing or receipt of alarms such that it is of no use to an administrator (since the attack may already have succeeded).

n) Disrupting concurrence includes investigating the behaviour of the TOE when two or more subjects attempt simultaneous access. It may be that the TOE can cope with the interlocking required when two subjects attempt simultaneous access, but that the behaviour becomes less well defined in the presence of further subjects. For example, a critical security process could be put into a resource-wait state if two other processes are accessing a resource which it requires.

o) Using interference between components which are not visible at a higher level of abstraction may provide a means of delaying a time-critical trusted process.

Direct attacks

493 Direct attack includes the identification of any penetration tests necessary to confirm or disprove the claimed minimum strength of functions. When identifying penetration tests under this heading, the evaluator should also be aware of the possibility of vulnerabilities existing as a result of security mechanisms being susceptible to direct attack.

Misuse

494 Misuse includes the identification of any penetration tests necessary to confirm or disprove the misuse analysis. Issues to be considered include:

a) behaviour of the TOE when start-up, closedown or error recovery is activated;

b) behaviour of the TOE under extreme circumstances (sometimes termed overload or asymptotic behaviour), particularly where this could lead to the de-activation or disabling of a security enforcing function or mechanism;

c) any potential for unintentional misconfiguration or insecure use arising from attacks noted in the section on tampering above.

Action AVA_VLA.4.4E

(The evaluator shall perform independent penetration testing, based on the independent vulnerability analysis, to determine the exploitability of additional identified vulnerabilities in the intended environment.)

6:AVA_VLA.4-12 The evaluator shall devise penetration tests, based on the independent vulnerability analysis.

495 The evaluator prepares for penetration testing based on the prioritised list of vulnerabilities hypothesised in evaluator action AVA_VLA.4.3E.

98/139 AIS 34_3


496 The evaluator is not expected to test for vulnerabilities beyond those, for which a high attack potential is required to effect an attack (i.e. those beyond normal practicability). However, as a result of evaluation expertise, the evaluator may discover a vulnerability that is exploitable by an attacker having an attack potential beyond normal practicability. Such vulnerabilities are to be reported in the ETR as residual vulnerabilities.





498 The evaluator will probably find it practical to carry out penetration test using a series of test cases, where each test case will test for a specific vulnerability.

6:AVA_VLA.4-13 The evaluator shall produce penetration test documentation for the tests based on the independent vulnerability analysis, in sufficient detail to enable the tests to be repeatable. The test documentation shall include:

a) identification of the obvious vulnerability the TOE is being tested for;








6:AVA_VLA.4-14 The evaluator shall conduct penetration testing, based on the independent vulnerability analysis.

500 The evaluator uses the penetration test documentation resulting from work unit 6:AVA_VLA.4-12 as a basis for executing penetration tests on the TOE, but this does not preclude the evaluator from performing additional ad hoc penetration tests. If required, the evaluator may devise new tests as a result of information learned during penetration testing that, if performed by the evaluator, are to be recorded in the penetration test documentation. Such tests may be required to follow up unexpected results or observations, or to investigate potential vulnerabilities suggested to the evaluator during the pre-planned testing.

501 Should penetration testing show that a hypothesised vulnerability does not exist, then the evaluator should determine whether or not the evaluator’s own analysis was incorrect, or if evaluation deliverables are incorrect or incomplete.



AIS 34_3 99/139


6:AVA_VLA.4-16 The evaluator shall report in the ETR the evaluator penetration testing effort, outlining the testing approach, configuration, depth and results.







Action AVA_VLA.4.5E

(The evaluator shall determine that the TOE is resistant to penetration attacks performed by an attacker possessing a high attack potential)

6:AVA_VLA.4-17 The evaluator shall examine the results of all penetration testing and the conclusions of all vulnerability analysis to determine that the TOE, in its intended environment, is resistant to an attacker possessing a high attack potential.

506 For a final rating of high, it shall be evident that the TOE could only be defeated by attackers possessing a high level of expertise, opportunity and resources, and performing a successful attack being judged to be beyond normal practicability.

507 If the results reveal that the TOE, in its intended environment, has vulnerabilities exploitable by an attacker possessing an attack potential less than beyond normal practicability, then this evaluator action fails.

6:AVA_VLA.4-18 The evaluator shall report in the ETR all exploitable vulnerabilities and residual vulnerabilities, detailing for each:


b) the implicated security function(s), objective(s) not met, organisational security policy(ies) contravened and threat(s) realised;

c) a description;

d) whether it is exploitable in its intended environment or not (i.e. exploitable or residual);

e) identification of evaluation party (e.g. developer, evaluator) who identified it.

100/139 AIS 34_3


2 Supplementary methodology for CC v3.1 evaluation

508 In this chapter all references to CC or CEM refer to [CC31] or [CEM31], respectively. The methodology in this chapter can be used for evaluations according to EAL5+ or EAL6.

2.1 Evaluation of sub-activity (AVA_VAN.5)

509 The work units for the evaluation of the sub-activity AVA_VAN.5 are copied from the work units of AVA_VAN.4 as far as possible except that the TOE is attacked by attackers posessing High attack potential.

2.1.1 Objectives

510 The objective of this sub-activity is to determine whether the TOE, in its operational environment, has vulnerabilities exploitable by attackers possessing High attack potential.

2.1.2 Input


a) the ST;


c) the TOE design;

d) the security architecture description;


f) the guidance documentation;

g) the TOE suitable for testing;

h) information publicly available to support the identification of possible potential vulnerabilities;

i) the results of the testing of the basic design.

512 The remaining implicit evaluation evidence for this sub-activity depends on the components that have been included in the assurance package. The evidence provided for each component is to be used as input in this sub-activity.


a) current information regarding public domain potential vulnerabilities and attacks (e.g. from an evaluation authority).

2.1.3 Application notes

514 The methodical analysis approach takes the form of a structured examination of the evidence. This method requires the evaluator to specify the structure and form the analysis will take (i.e. the manner in which the analysis is performed is predetermined, unlike the focused analysis). The method is specified in terms of the information that will be considered and how/why it will be considered. Further guidance on methodical vulnerability analysis can be found in [CEM31] Annex B.2.2.2.3.

2.1.4 Action AVA_VAN.5.1E

AVA_VAN.5.1C The TOE shall be suitable for testing.

AVA_VAN.5-1 The evaluator shall examine the TOE to determine that the test configuration is consistent with the configuration under evaluation as specified in the ST.

AIS 34_3 101/139


515 The TOE provided by the developer and identified in the test plan should have the same unique reference as established by the CM capabilities (ALC_CMC) sub-activities and identified in the ST introduction.

516 It is possible for the ST to specify more than one configuration for evaluation. The TOE may comprise a number of distinct hardware and software entities that need to be tested in accordance with the ST. The evaluator verifies that all test configurations are consistent with the ST.

517 The evaluator should consider the security objectives for the operational environment described in the ST that may apply to the test environment and ensure they are met in the testing environment. There may be some objectives for the operational environment that do not apply to the test environment. For example, an objective about user clearances may not apply; however, an objective about a single point of connection to a network would apply.

518 If any test resources are used (e.g. meters, analysers) it will be the evaluator's responsibility to ensure that these resources are calibrated correctly.

AVA_VAN.5-2 The evaluator shall examine the TOE to determine that it has been installed properly and is in a known state

519 It is possible for the evaluator to determine the state of the TOE in a number of ways. For example, previous successful completion of the Evaluation of sub-activity (AGD_PRE.1) sub-activity will satisfy this work unit if the evaluator still has confidence that the TOE being used for testing was installed properly and is in a known state. If this is not the case, then the evaluator should follow the developer's procedures to install and start up the TOE, using the supplied guidance only.

520 If the evaluator has to perform the installation procedures because the TOE is in an unknown state, this work unit when successfully completed could satisfy work unit AGD_PRE.1-3.


AVA_VAN.5-3 The evaluator shall examine sources of information publicly available to identify potential vulnerabilities in the TOE.

521 The evaluator examines the sources of information publicly available to support the identification of possible potential vulnerabilities in the TOE. There are many sources of publicly available information which the evaluator should consider using items such as those available on the world wide web, including:

a) specialist publications (magazines, books);

b) research papers;

c) conference proceedings.

522 The evaluator should not constrain their consideration of publicly available information to the above, but should consider any other relevant information available.

523 While examining the evidence provided the evaluator will use the information in the public domain to further search for potential vulnerabilities. Where the evaluators have identified areas of concern, the evaluator should consider information publicly available that relate to those areas of concern.

524 The availability of information that may be readily available to an attacker that helps to identify and facilitate attacks may substantially enhance the attack potential of a given attacker. The accessibility of vulnerability information and sophisticated attack tools on the Internet makes it more likely that this information will be used in attempts to identify potential vulnerabilities in the TOE and exploit them. Modern search tools make such information easily available to the evaluator, and the determination of resistance to published potential vulnerabilities and well known generic attacks can be achieved in a cost-effective manner.

102/139 AIS 34_3


525 The search of the information publicly available should be focused on those sources that refer to the technologies used in the development of the product from which the TOE is derived. The extensiveness of this search should consider the following factors: TOE type, evaluator experience in this TOE type, expected attack potential and the level of ADV evidence available.

526 The identification process is iterative, where the identification of one potential vulnerability may lead to identifying another area of concern that requires further investigation.

527 The evaluator will describe the approach to be taken to identify potential vulnerabilities in the publicly available material, detailing the search to be performed. This may be driven by factors such as areas of concern identified by the evaluator, linked to the evidence the attacker is assumed to be able to obtain. However, it is recognised that in this type of search the approach may further evolve as a result of findings during the search. Therefore, the evaluator will also report any actions taken in addition to those described in the approach to further investigate issues thought to lead to potential vulnerabilities, and will report the evidence examined in completing the search for potential vulnerabilities.


AVA_VAN.5-4 The evaluator shall conduct a methodical analysis of ST, guidance documentation, functional specification, TOE design, security architecture description and implementation representation to identify possible potential vulnerabilities in the TOE.

528 Guidance on methodical vulnerability analysis is provided in [CEM31] Annex B.2.2.2.3.

529 This approach to identification of potential vulnerabilities is to take an ordered and planned approach. A system is to be applied in the examination. The evaluator is to describe the method to be used in terms of the manner in which this information is to be considered and the hypothesis that is to be created.

530 A flaw hypothesis methodology should be used whereby the ST, development (functional specification, TOE design and implementation representation) and guidance evidence are analysed and then vulnerabilities in the TOE are hypothesised, or speculated.

531 The evaluator should use the knowledge of the TOE design and operation gained from the TOE deliverables to conduct a flaw hypothesis to identify potential flaws in the development of the TOE and potential errors in the specified method of operation of the TOE.

532 The security architecture description provides the developer vulnerability analysis, as it documents how the TSF protects itself from interference from untrusted subjects and prevents the bypass of security enforcement functionality. Therefore, the evaluator should build upon the understanding of the TSF protection gained from the analysis of this evidence and then develop this in the knowledge gained from other development (e.g. ADV) evidence.

533 The approach taken to the methodical search for vulnerabilities is to consider any areas of concern identified in the results of the evaluator's assessment of the development and guidance evidence. However, the evaluator should also consider each aspect of the security architecture analysis to search for any ways in which the protection of the TSF can be undermined. It may be helpful to structure the methodical analysis on the basis of the material presented in the security architecture description, introducing concerns from other ADV evidence as appropriate. The analysis can then be further developed to ensure all other material from the ADV evidence is considered.

534 The following provide some examples of hypotheses that may be created when examining the evidence:

AIS 34_3 103/139


a) consideration of malformed input for interfaces available to an attacker at the external interfaces;

b) examination of a key security mechanism cited in the security architecture description, such as process separation, hypothesising internal buffer overflows that may lead to degradation of separation;

c) search to identify any objects created in the TOE implementation representation that are then not fully controlled by the TSF, and could be used by an attacker to undermine SFRs.

535 For example, the evaluator may identify that interfaces are a potential area of weakness in the TOE and specify an approach to the search that 'all interface specifications in the evidence provided will be searched to hypothesise potential vulnerabilities' and go on to explain the methods used in the hypothesis.

536 In addition, areas of concern the evaluator has identified during examination of the evidence during the conduct of evaluation activities. Areas of concern may also be identified during the conduct of other work units associated with this component, in particular AVA_VAN.5-7, AVA_VAN.5-5 and AVA_VAN.5-6) where the development and conduct of penetration tests may identify further areas of concerns for investigation, or potential vulnerabilities.

537 However, examination of only a subset of the development and guidance evidence or their contents is not permitted in this level of rigour. The approach description should provide a demonstration that the methodical approach used is complete, providing confidence that the approach used to search the deliverables has considered all of the information provided in those deliverables.

538 This approach to identification of potential vulnerabilities is to take an ordered and planned approach; applying a system to the examination. The evaluator is to describe the method to be used in terms of how the evidence will be considered; the manner in which this information is to be considered and the hypothesis that is to be created. This approach should be agreed with the evaluation authority, and the evaluation authority should provide detail of any additional approaches the evaluator should take to the vulnerability analysis and identify any additional information that should be considered by the evaluator.

539 Although a system to identifying potential vulnerabilities is predefined, the identification process may still be iterative, where the identification of one potential vulnerability may lead to identifying another area of concern that requires further investigation.

540 Subject to the SFRs the TOE is to meet in the operational environment, the evaluator's independent vulnerability analysis should consider generic potential vulnerabilities under each of the following headings:

a) generic potential vulnerabilities relevant for the type of TOE being evaluated, as may be supplied by the evaluation authority;

b) bypassing;

c) tampering;

d) direct attacks;

e) monitoring;

f) misuse.

541 Items b) - f) are explained in greater detail in [CEM31] Annex B.2.1.

542 The security architecture description should be considered in light of each of the above generic potential vulnerabilities. Each potential vulnerability should be considered to search for possible ways in which to defeat the TSF protection and undermine the TSF.

104/139 AIS 34_3


AVA_VAN.5-5 The evaluator shall record in the ETR the identified potential vulnerabilities that are candidates for testing and applicable to the TOE in its operational environment.

543 It may be identified that no further consideration of the potential vulnerability is required if for example the evaluator identifies that measures in the operational environment, either IT or non-IT, prevent exploitation of the potential vulnerability in that operational environment. For instance, restricting physical access to the TOE to authorised users only may effectively render a potential vulnerability to tampering unexploitable.

544 The evaluator records any reasons for exclusion of potential vulnerabilities from further consideration if the evaluator determines that the potential vulnerability is not applicable in the operational environment. Otherwise the evaluator records the potential vulnerability for further consideration.

545 A list of potential vulnerabilities applicable to the TOE in its operational environment, which can be used as an input into penetration testing activities, shall be reported in the ETR by the evaluators.


AVA_VAN.5-6 The evaluator shall devise penetration tests, based on the independent search for potential vulnerabilities.

546 The evaluator prepares for penetration testing as necessary to determine the susceptibility of the TOE, in its operational environment, to the potential vulnerabilities identified during the search of the sources of publicly available information and the analysis of the TOE guidance and design evidence. The evaluator should have access to current information (e.g. from the evaluation authority) regarding known potential vulnerabilities that may not have been considered by the evaluator.

547 The evaluator is reminded that, as for considering the security architecture description in the search for vulnerabilities (as detailed in AVA_VAN.5-3), testing should be performed to confirm the architectural properties. If requirements from ATE_DPT are included in the SARs, the developer testing evidence will include testing performed to confirm the correct implementation of any specific mechanisms detailed in the security architecture description. However, the developer testing will not necessarily include testing of all aspects of the architectural properties that protect the TSF, as much of this testing will be negative testing in nature, attempting to disprove the properties. In developing the strategy for penetration testing, the evaluator will ensure that all aspects of the security architecture description are tested, either in functional testing (as considered in 14, [CEM31]) or evaluator penetration testing.

548 The evaluator will probably find it practical to carry out penetration test using a series of test cases, where each test case will test for a specific potential vulnerability.

549 The evaluator is not expected to test for potential vulnerabilities (including those in the public domain) beyond those which required a High attack potential. In some cases, however, it will be necessary to carry out a test before the exploitability can be determined. Where, as a result of evaluation expertise, the evaluator discovers an exploitable vulnerability that is beyond High attack potential, this is reported in the ETR as a residual vulnerability.

550 Guidance on determining the necessary attack potential to exploit a potential vulnerability can be found in [CEM31] Annex B.4.

551 Potential vulnerabilities hypothesised as exploitable by an attacker possessing a High (or less) attack potential and resulting in a violation of the security objectives should be the highest priority potential vulnerabilities comprising the list used to direct penetration testing against the TOE.

AVA_VAN.5-7 The evaluator shall produce penetration test documentation for the tests based on the list of potential vulnerabilities in sufficient detail to enable the tests to be repeatable. The test documentation shall include:

AIS 34_3 105/139


a) identification of the potential vulnerability the TOE is being tested for;

b) instructions to connect and setup all required test equipment as required to conduct the penetration test;






552 The evaluator prepares for penetration testing based on the list of potential vulnerabilities identified during the search of the public domain and the analysis of the evaluation evidence.

553 The evaluator is not expected to determine the exploitability for potential vulnerabilities beyond those for which a High attack potential is required to effect an attack. However, as a result of evaluation expertise, the evaluator may discover a potential vulnerability that is exploitable only by an attacker with greater than High attack potential. Such vulnerabilities are to be reported in the ETR as residual vulnerabilities.

554 With an understanding of the potential vulnerability, the evaluator determines the most feasible way to test for the TOE's susceptibility. Specifically the evaluator considers:

a) the TSFI or other TOE interface that will be used to stimulate the TSF and observe responses (It is possible that the evaluator will need to use an interface to the TOE other than the TSFI to demonstrate properties of the TSF such as those described in the security architecture description (as required by ADV_ARC). It should the noted, that although these TOE interfaces provide a means of testing the TSF properties, they are not the subject of the test.);


c) special test equipment that will be required to either stimulate a TSFI or make observations of a TSFI;

d) whether theoretical analysis should replace physical testing, particularly relevant where the results of an initial test can be extrapolated to demonstrate that repeated attempts of an attack are likely to succeed after a given number of attempts.

555 The evaluator will probably find it practical to carry out penetration testing using a series of test cases, where each test case will test for a specific potential vulnerability.


AVA_VAN.5-8 The evaluator shall conduct penetration testing.

557 The evaluator uses the penetration test documentation resulting from work unit AVA_VAN.5-6 as a basis for executing penetration tests on the TOE, but this does not preclude the evaluator from performing additional ad hoc penetration tests. If required, the evaluator may devise ad hoc tests as a result of information learnt during penetration testing that, if performed by the evaluator, are to be recorded in the penetration test documentation. Such tests may be required to follow up unexpected results or observations, or to investigate potential vulnerabilities suggested to the evaluator during the pre-planned testing.

106/139 AIS 34_3


558 Should penetration testing show that a hypothesised potential vulnerability does not exist, then the evaluator should determine whether or not the evaluator's own analysis was incorrect, or if evaluation deliverables are incorrect or incomplete.

559 The evaluator is not expected to test for potential vulnerabilities (including those in the public domain) beyond those which required a High attack potential. In some cases, however, it will be necessary to carry out a test before the exploitability can be determined. Where, as a result of evaluation expertise, the evaluator discovers an exploitable vulnerability that is beyond High attack potential, this is reported in the ETR as a residual vulnerability.

AVA_VAN.5-9 The evaluator shall record the actual results of the penetration tests.

560 While some specific details of the actual test results may be different from those expected (e.g. time and date fields in an audit record) the overall result should be identical. Any unexpected test results should be investigated. The impact on the evaluation should be stated and justified.

AVA_VAN.5-10 The evaluator shall report in the ETR the evaluator penetration testing effort, outlining the testing approach, configuration, depth and results.

561 The penetration testing information reported in the ETR allows the evaluator to convey the overall penetration testing approach and effort expended on this sub-activity. The intent of providing this information is to give a meaningful overview of the evaluator's penetration testing effort. It is not intended that the information regarding penetration testing in the ETR be an exact reproduction of specific test steps or results of individual penetration tests. The intention is to provide enough detail to allow other evaluators and evaluation authorities to gain some insight about the penetration testing approach chosen, amount of penetration testing performed, TOE test configurations, and the overall results of the penetration testing activity.



b) TSFI penetration tested. A brief listing of the TSFI and other TOE interfaces that were the focus of the penetration testing;

c) Verdict for the sub-activity. The overall judgement on the results of penetration testing.


AVA_VAN.5-11 The evaluator shall examine the results of all penetration testing to determine that the TOE, in its operational environment, is resistant to an attacker possessing a High attack potential.

564 If the results reveal that the TOE, in its operational environment, has vulnerabilities exploitable by an attacker possessing an attack potential less than or equal to High, then this evaluator action fails.

565 The guidance in B.4 and the guidance for special technical areas (e.g. AIS 26) that is relevant for the national scheme should be used to determine the attack potential required to exploit a particular vulnerability and whether it can therefore be exploited in the intended environment. It may not be necessary for the attack potential to be calculated in every instance, only if there is some doubt as to whether or not the vulnerability can be exploited by an attacker possessing an attack potential less than or equal to High.

AIS 34_3 107/139


AVA_VAN.5-12 The evaluator shall report in the corresponding ETR-part in consideration of the guidelines from AIS 14 and AIS 19 all exploitable vulnerabilities and residual vulnerabilities, detailing for each:


b) the SFR(s) not met;

c) a description;

d) whether it is exploitable in its operational environment or not (i.e. exploitable or residual);

e) the amount of time, level of expertise, level of knowledge of the TOE, level of opportunity and the equipment required to perform the identified vulnerabilities, and the corresponding values using the tables 3 and 4 of [CEM31] Annex B.4.

108/139 AIS 34_3


2.2 Evaluation of sub-activity (ADV_SPM.1)

2.2.1 Objectives

566 The objectives of this sub-activity are to determine whether the formal security policy model of the TSF clearly and consistently describes the rules and characteristics of the security policies and whether this description corresponds with the description of security functions in the functional specification.

2.2.2 Input


a) the ST;


c) formal security policy model (ADV_SPM.1.1D);

d) formal proof of correspondence between the model and any formal functional specification (ADV_SPM.1.3D);

e) demonstration of correspondence between the model and the functional specification (ADV_SPM.1.4D).


568 This activity applies to cases where the developer has provided a formal security policy model of the TOE.

569 A formal TOE security policy model is a representation of the rules (synonymously termed “principles”) of security policies and characteristics of the TSF behaviour in mathematical terms. Their formal counterparts are called security properties and security features, respectively. The representation includes but is not limited to algebraic specifications, finite state machines and logic formalisms strong enough to formally infer the properties from the features. The formal TSP model is accompanied by an informal interpretation explaining how the rules and characteristics are mapped to the respective properties and features .

570 The creation of a formal security policy model helps to identify and eliminate ambiguous, inconsistent, contradictory, or unenforceable security policy elements. Once the TOE has been built, the formal model serves the evaluation effort by contributing to the evaluator's judgement of how well the developer has understood the security functionality being implemented and whether there are inconsistencies between the security requirements and the TOE design. The confidence in the model is accompanied by a proof that it contains no inconsistencies.

571 A formal security model is a precise formal presentation of the important aspects of security and their relationship to the behaviour of the TOE; it identifies the set of rules (principles) that defines the TOE security policy and the set of practises (characteristics) that regulates how the TSF manages, protects, and otherwise controls the system resources. The model includes the set of restrictions and properties that specify how information and computing resources are prevented from being used to violate the SFRs, accompanied by a persuasive set of engineering arguments showing that these restrictions and properties play a key role in the enforcement of the SFRs. It consists both of the formalisms that express the security functionality, as well as ancillary text to explain the model and to provide it with context. The security behaviour of the TSF is modelled both in terms of external behaviour (i.e. how the TSF interacts with the rest of the TOE and with its operational environment), as well as its internal behaviour.

572 The Security Policy Model of the TOE is informally abstracted from its realisation by considering the proposed security requirements of the ST. The informal abstraction is taken to be successful if the TOE's principles turn out to be enforced by its

AIS 34_3 109/139


characteristics. The purpose of formal methods lies within the enhancement of the rigour of enforcement. Informal arguments are always prone to fallacies; especially if relationships among subjects, objects and operations get more and more involved. In order to minimise the risk of insecure state arrivals the rules and characteristics of the security policy model are mapped to respective properties and features within some formal system, whose rigour and strength can afterwards be used to obtain the security properties by means of theorems and formal proof.

573 While the term “formal security policy model” is used in academic circles, the CC's approach has no fixed definition of “security”; it would equate to whatever SFRs are being claimed. Therefore, the formal security policy model is merely a formal representation of the set of SFRs being claimed.

574 The term security policy has traditionally been associated with only access control policies, whether label-based (mandatory access control) or user-based (discretionary access control). However, a security policy is not limited to access control; there are also audit policies, identification policies, authentication policies, encryption policies, management policies, and any other security policies that are enforced by the TOE, as described in the PP/ST. ADV_SPM.1.1D contains an assignment for identifying these policies that are formally modelled.

575 It is recognized that not all policies can be formally modelled for all TOEs. This is because either a given policy can not be formally modelled in the otherwise well suited framework, or because the nature of the TOE renders impossible the modelling of policies that would otherwise be possible to model.

2.2.4 Action ADV_SPM.1.1E

ADV_SPM.1.1C The model shall be in a formal style, supported by explanatory text as required, and identify the security policies of the TSF that are modelled.

ADV_SPM.1-1 The evaluator shall examine the TOE security policy model to determine that it is written in a formal style.

576 The evaluator identifies the formal framework upon which the TOE security policy model is based and ensures that it is founded on well established mathematical concepts. He also identifies the security properties and features addressed in the application notes and ensures the formalization of at least one security policy.

577 For guidance on formal methods refer to [CC31] part3, Annex A.5.

ADV_SPM.1-2 The evaluator shall examine the TOE security policy model to determine that it contains all necessary informal explanatory text.

578 Supporting narrative descriptions are necessary for all parts of the model (for example, to make clear the meaning of any formal notation and how they are used) including the security properties and features.

ADV_SPM.1-3 The evaluator shall examine the TOE security policy model to determine that all security policies of the TSF are identified that are modelled.

579 The evaluator determines whether the SPM identifies the security policies for which a model is provided, identifying the relevant portions of the statement of SFRs that comprise each of the modelled policies.

580 The evaluator determines whether the list of security policies identified by the SPM is consistent with the assignment of ADV_SPM.1.1D in the ST.

581 The evaluator determines whether for each security policy identified by the SPM a model is in fact provided.

ADV_SPM.1.2C For all policies that are modelled, the model shall define security for the TOE and provide a formal proof that the TOE cannot reach a state that is not secure.

110/139 AIS 34_3


ADV_SPM.1-4 The evaluator shall examine the principles and characteristics of the security policies to determine that the modelled security behaviour of the TOE is clearly articulated.

582 The security policies are expressed in terms of security principles (rules) which are modelled by security properties and define the secure state of the TOE. For example, a model based on state transitions could describe the security policies in terms of principles of its states, identify its initial state, and define what it means to be a secure state.

583 The evaluator determines that the security policies are reflected within their formal counterparts of the TSP model.

584 The TOE security behaviour is expressed in terms of security characteristics (i.e. portions of TOE security functionality managing, protecting, and otherwise controlling the system resources including attributes and conditions of the TOE) which are modelled by security features. For example, a model based on state transitions could describe the characteristics as possible actions in each secure state in a level of detail sufficient to decide into which state the TOE will be transformed by that action.

585 Together the security principles and characteristics describe the entire security posture of the TOE.

586 In the context of a formal TOE security policy model the security behaviour is considered to be clearly articulated only if an adequate mapping from principles and characteristics to their respective formal counterparts properties and features has been given. The mapping is considered to be adequate if the level of abstraction from the TOE’s realization is detailed enough to allow for correct identification of all security objectives and the relation to the security environment.

587 The above condition for clear articulation is necessary but not sufficient. An informal interpretation of all formal concepts (including attributes, predicates and variables, if available) must be provided in order to make clear their intended meaning.

ADV_SPM.1-5 The evaluator shall examine the TOE security policy model rationale to determine that it formally proves that the security features enforce the security properties.

588 To determine the enforcement, the evaluator considers the security properties and the security features and verifies that the arguments used in the proof are valid. The proof of correspondence between the security properties and the security features shall be formal.

589 The validity of the security properties shall mean that the TOE is in a secure state. By this, the evaluator confirms by means of the rationale that the TOE never reaches an insecure state.

ADV_SPM.1-6 The evaluator shall examine the TOE security policy model rationale to determine that it proves the internal consistency of the TOE security policy model.

590 The proof shall show the absence of contradictions within the TOE security policy model. In determining the absence of contradictions, the evaluator verifies that the arguments used in the proof are valid.

591 Since the TOE security policy model is formal, the proof of its internal consistency shall be formal. It is recognized that a complete formal proof of the internal consistency of the TOE security policy model usually is not possible due to the fundamental nature of formal frameworks. Generally, it is sufficient to generate evidence using formal proofs based on the specific TOE security policy model that prove the internal consistency by means of a combination with generic arguments of the formal framework.

ADV_SPM.1.3C The correspondence between the model and the functional specification shall be at the correct level of formality.

ADV_SPM.1-7 The evaluator shall examine the correspondence between the model and the functional specification to determine that a semiformal demonstration of correspondence between the model and any semiformal functional specification is provided.

AIS 34_3 111/139


592 This work unit is only applicable to a semiformal presentation of the functional specification, which is required by ADV_FSP.5.2C.

593 A semiformal correspondence is one that results from a structured approach with a substantial degree of rigor (in terms of completeness and correctness), but is not as rigorous as a mathematical proof. Such a semiformal correspondence limits the subjective interpretations of its terms, and so it provides less ambiguity than would exist in an informal correspondence.

594 For guidance on semiformal methods refer to Annex 3.1.1 ‘Semiformal and formalmethods’.

ADV_SPM.1-8 The evaluator shall examine the correspondence between the model and the functional specification to determine that a formal proof of correspondence between the model and any formal functional specification is provided.

595 This work unit is only applicable to a formal presentation of the functional specification, which is required by ADV_FSP.6.2D.

596 There should be a formal proof of correspondence between the model and any formal functional specification.

597 The formal proof of correspondence removes all subjective interpretations of its terms by enlisting well-established mathematical concepts to define the syntax and semantics of the formal notation and uses rules that support logical reasoning. The security features within the TOE (which are identified in the formal TSP model) are expressed in a formal specification language and shown to be satisfied by the formal specification.

598 For guidance on formal methods refer to [CC31] part 3, Annex A.5.

ADV_SPM.1.4C The correspondence shall show that the functional specification is consistent and complete with respect to the model.

ADV_SPM.1-9 The evaluator shall examine the correspondence to determine that the behaviour at the TSF interfaces (as articulated in the functional specification) is complete with respect to the behaviour modelled by the security features.

599 The term “correspondence” here means both the formal proof of correspondence between the formal SPM and any formal FSP required by ADV_SPM.1.2D and the demonstration of correspondence between the formal SPM and the FSP required by ADV_SPM.1.3D.

600 In determining completeness of the correspondence, the evaluator considers the description of TSFI behaviour and maps adequate portions (characteristics) to corresponding features of the TSP model. The demonstration should show that all characteristics belonging to policies that are required to be modelled have an associated feature description in the TOE security policy model, and that each feature of the TSP model does occur in the mapping.

601 Abstention from formally modelling TSFI behaviour always calls for justification on the developer’s side (also confer the application notes above).

ADV_SPM.1-10 The evaluator shall examine the correspondence to determine that the behaviour at the TSF interfaces (as articulated in the functional specification) is consistent with respect to the behaviour modelled by the security features.

602 The term “correspondence” here means both the formal proof of correspondence between the formal SPM and any formal FSP required by ADV_SPM.1.3D and the demonstration of correspondence between the SPM and the FSP required by ADV_SPM.1.4D.

603 The meaning of consistency reflects the conventional understanding in contrast to the internal consistency concept of work unit ADV_SPM.1-6.

604 In determining consistency, the evaluator resumes the mapping of TSFI behaviour to security features established in the preceding work unit and verifies that the correspondence shows that each security feature of the TSP model accurately reflects the corresponding TSFI behaviour.

112/139 AIS 34_3


605 For example, if TSFI behaviour dealt with access management on the granularity of single individuals, then a TSP model describing the security behaviour of the TOE in terms of groups of users would not be consistent. Likewise, if TSFI behaviour dealt with access management for groups of users, then a TSP model describing the security behaviour of the TOE in terms of individual users would also not be consistent.

606 As another example, if remote untrusted users had to pass more stringent authentication procedures than administrators whose only point of access were within a physically-protected area, then this difference in authentication procedures had to be reflected in the security features.

AIS 34_3 113/139


2.3 Evaluation of sub-activity (ADV_TDS.5)

607 The work units for the evaluation of the sub-activity ADV_TDS.5 are copied from the work units of ADV_TDS.4 as far as possible.

608 Editor's note:

609 The main differences between ADV_TDS.4 and ADV_TDS.5 are that the description of the modules needs to be semiformal and that all modules need to be described on the same level of detail, regardless of their classification as SFR-enforcing, SFR-supporting and so on.

610 Since semiformal parts already exist in ADV_TDS.4, the existing work unit ADV_TDS.4-5 could be slightly extended for the checking of the semiformal aspects.

611 The requirement, that all modules are described at maximal detail has the following effect: Work units .4-13, .4-14, and .4-15 are not needed any more, because they were only necessary due to the lower level of detail of the description for SFR-non-interfering modules in ADV_TDS.4. Since all modules are described at the same level in ADV_TDS.5, the SFR-non-interfering modules are already covered by preceding work units together with all other modules.

2.3.1 Objectives

612 The objectives of this sub-activity are to determine whether the TOE design provides a description of the TOE in terms of subsystems sufficient to determine the TSF boundary, and provides a description of the TSF internals in terms of modules (and optionally higher-level abstractions). It provides enough information about the modules for the evaluator to determine that the SFRs are completely and accurately implemented; as such, the TOE design provides an explanation of the implementation representation.

2.3.2 Input


a) the ST;


c) security architecture description;

d) the TOE design.


614 There are three types of activity that the evaluator must undertake with respect to the TOE design. First, the evaluator determines that the TSF boundary has been adequately described. Second, the evaluator determines that the developer has provided documentation that conforms to the content and presentation requirements this subsystem, and that is consistent with other documentation provided for the TOE. Finally, the evaluator must analyse the design information provided for the modules (at a detailed level) to understand how the system is implemented, and with that knowledge ensure that the TSFI in the functional specification are adequately described, and that the test information adequately tests the TSF (done in the Class ATE: Tests work units).

2.3.4 Action ADV_TDS.5.1E

ADV_TDS.5.1C The design shall describe the structure of the TOE in terms of subsystems.

ADV_TDS.5-1 The evaluator shall examine the TOE design to determine that the structure of the entire TOE is described in terms of subsystems.

615 The evaluator ensures that all of the subsystems of the TOE are identified. This description of the TOE will be used as input to work unit ADV_TDS.5-4, where the parts

114/139 AIS 34_3


of the TOE that make up the TSF are identified. That is, this requirement is on the entire TOE rather than on only the TSF.

616 The TOE (and TSF) may be described in multiple layers of abstraction (i.e. subsystems and modules) Depending upon the complexity of the TOE, its design may be described in terms of subsystems and modules, as described in CC Part 3 Annex A.4, ADV_TDS: Subsystems and Modules. For a very simple TOE that can be described solely at the “module” level (see ADV_TDS.5-2), this work unit is not applicable and therefore considered to be satisfied.

617 In performing this activity, the evaluator examines other evidence presented for the TOE (e.g., ST, operator user guidance) to determine that the description of the TOE in such evidence is consistent with the description contained in the TOE design.

ADV_TDS.5.2C The design shall describe the TSF in terms of modules, designating each module as SFR-enforcing, SFR-supporting, or SFR-non-interfering.

ADV_TDS.5-2 The evaluator shall examine the TOE design to determine that the entire TSF is described in terms of modules.

618 The evaluator will examine the modules for specific properties in other work units; in this work unit the evaluator determines that the modular description covers the entire TSF, and not just a portion of the TSF. The evaluator uses other evidence provided for the evaluation (e.g., functional specification, architectural description) in making this determination. For example, if the functional specification contains interfaces to functionality that does not appear to be described in the TOE design description, it may be the case that a portion of the TSF has not been included appropriately. Making this determination will likely be an iterative process, where as more analysis is done on the other evidence, more confidence can be gained with respect to the completeness of the documentation.

619 Unlike subsystems, modules describe the implementation in a level of detail that can serve as a guide to reviewing the implementation representation. A description of a module should be such that one could create an implementation of the module from the description, and the resulting implementation would be 1) identical to the actual TSF implementation in terms of the interfaces presented, 2) identical in the use of interfaces that are mentioned in the design, and 3) functionally equivalent to the description of the purpose of the TSF module. For instance, RFC 793 provides a high-level description of the TCP protocol. It is necessarily implementation independent. While it provides a wealth of detail, it is not a suitable design description because it is not specific to an implementation. An actual implementation can add to the protocol specified in the RFC, and implementation choices (for instance, the use of global data vs. local data in various parts of the implementation) may have an impact on the analysis that is performed. The design description of the TCP module would list the interfaces presented by the implementation (rather than just those defined in RFC 793), as well as an algorithm description of the processing associated with the modules implementing TCP (assuming it was part of the TSF).

ADV_TDS.5-3 The evaluator shall check the TOE design to determine that the TSF modules are identified as either SFR-enforcing, SFR-supporting, or SFR-non-interfering.

620 The purpose of designating each module (according to the role a particular module plays in the enforcement of the SFRs) is to allow developers to provide less information about the parts of the TSF that have little role in security. It is always permissible for the developer to provide more information or detail than the requirements demand, as might occur when the information has been gathered outside the evaluation context. In such cases the developer must still designate the modules as either SFR-enforcing, SFR-supporting, or SFR-non-interfering.

621 The accuracy of these designations is continuously reviewed as the evaluation progresses. The concern is the mis-designation of modules as being less important (and hence, having less information) than is really the case. While blatant mis-designations may be

AIS 34_3 115/139


immediately apparent (e.g., designating an authentication module as anything but SFR-enforcing when User identification (FIA_UID) is one of the SFRs being claimed), other mis-designations might not be discovered until the TSF is better understood. The evaluator must therefore keep in mind that these designations are the developer's initial best effort, but are subject to change. Further guidance is provided under work unit ADV_TDS.5-16, which examines the accuracy of these designations.

ADV_TDS.5.3C The design shall identify all subsystems of the TSF.

ADV_TDS.5-4 The evaluator shall examine the TOE design to determine that all subsystems of the TSF are identified.

622 If the design is presented solely in terms of modules, then subsystems in these requirements are equivalent to modules and the activity should be performed at the module level.

623 In work unit ADV_TDS.5-1 all of the subsystems of the TOE were identified, and a determination made that the non-TSF subsystems were correctly characterised. Building on that work, the subsystems that were not characterised as non-TSF subsystems should be precisely identified. The evaluator determines that, of the hardware and software installed and configured according to the Preparative procedures (AGD_PRE) guidance, each subsystem has been accounted for as either one that is part of the TSF, or one that is not.

ADV_TDS.5.4C The design shall provide a semiformal description of each subsystem of the TSF, supported by informal, explanatory text where appropriate.

ADV_TDS.5-5 The evaluator shall examine the TDS documentation to determine that the semiformal notation used for describing the subsystems, modules and their interfaces is defined or referenced.

624 A semiformal notation can be either defined by the sponsor or a corresponding standard be referenced. The evaluator should provide a mapping of security functions and their interfaces outlining in what part of the documentation a function or interface is semiformal described and what notation is used. The evaluator examines all semiformal notations used to make sure that they are of a semiformal style and to justify the appropriateness of the manner how the semiformal notations are used for the TOE.

625 The evaluator is reminded that a semi-formal presentation is characterised by a standardised format with a well-defined syntax that reduces ambiguity that may occur in informal presentations. The syntax of all semiformal notations used in the functional specification shall be defined or a corresponding standard be referenced. The evaluator verifies that the semiformal notations used for expressing the functional specification are capable of expressing features relevant to security. In order to determine this, the evaluator can refer to the SFR and compare the TSF security features stated in the ST and those described in the FSP using the semiformal notations.

626 Note that ADV_TDS.5.7C requires the module description to be semiformal. This work unit therefore applies also to that description.

ADV_TDS.5-6 The evaluator shall examine the TOE design to determine that each subsystem of the TSF describes its role in the enforcement of SFRs described in the ST.

627 If the design is presented solely in terms of modules, then this work unit will be considered satisfied by the assessment done in subsequent work units; no explicit action on the part of the evaluator is necessary in this case.

628 On systems that are complex enough to warrant a subsystem-level description of the TSF in addition to the modular description, the goal of the subsystem-level description is to give the evaluator context for the modular description that follows. Therefore, the evaluator ensures that the subsystem-level description contains a description of how the security functional requirements are achieved in the design, but at a level of abstraction above the modular description. This description should discuss the mechanisms used at a level that is aligned with the module description; this will provide the evaluators the road

116/139 AIS 34_3


map needed to intelligently assess the information contained in the module description. A well-written set of subsystem descriptions will help guide the evaluator in determining the modules that are most important to examine, thus focusing the evaluation activity on the portions of the TSF that have the most relevance with respect to the enforcement of the SFRs.

629 The evaluator ensures that all subsystems of the TSF have a description. While the description should focus on the role that the subsystem plays in enforcing or supporting the implementation of the SFRs, enough information must be present so that a context for understanding the SFR-related functionality is provided.

ADV_TDS.5-7 The evaluator shall examine the TOE design to determine that each SFR-non-interfering subsystem of the TSF is described such that the evaluator can determine that the subsystem is SFR-non-interfering.


631 An SFR-non-interfering subsystem is one on which the SFR-enforcing and SFR-supporting subsystems have no dependence; that is, they play no role in implementing SFR functionality.

632 The evaluator ensures that all subsystems of the TSF have a description. While the description should focus on the role that the subsystem do not plays in enforcing or supporting the implementation of the SFRs, enough information must be present so that a context for understanding the SFRnon-interfering functionality is provided.

ADV_TDS.5.5C The design shall provide a description of the interactions among all subsystems of the TSF.

ADV_TDS.5-8 The evaluator shall examine the TOE design to determine that interactions between the subsystems of the TSF are described.


634 On systems that are complex enough to warrant a subsystem-level description of the TSF in addition to the modular description, the goal of describing the interactions between the subsystems is to help provide the reader a better understanding of how the TSF performs it functions. These interactions do not need to be characterised at the implementation level (e.g., parameters passed from one routine in a subsystem to a routine in a different subsystem; global variables; hardware signals (e.g., interrupts) from a hardware subsystem to an interrupt-handling subsystem), but the data elements identified for a particular subsystem that are going to be used by another subsystem need to be covered in this discussion. Any control relationships between subsystems (e.g., a subsystem responsible for configuring a rule base for a firewall system and the subsystem that actually implements these rules) should also be described.

635 It should be noted while the developer should characterise all interactions between subsystems, the evaluators need to use their own judgement in assessing the completeness of the description. If the reason for an interaction is unclear, or if there are SFR-related interactions (discovered, for instance, in examining the module-level documentation) that do not appear to be described, the evaluator ensures that this information is provided by the developer. However, if the evaluator can determine that interactions among a particular set of subsystems, while incompletely described by the developer, and a complete description will not aid in understanding the overall functionality nor security functionality provided by the TSF, then the evaluator may choose to consider the description sufficient, and not pursue completeness for its own sake.

AIS 34_3 117/139


ADV_TDS.5.6C The design shall provide a mapping from the subsystems of the TSF to the modules of the TSF.

ADV_TDS.5-9 The evaluator shall examine the TOE design to determine that the mapping between the subsystems of the TSF and the modules of the TSF is complete.

636 If the design is presented solely in terms of modules, then this work unit is considered satisfied.

637 For TOEs that are complex enough to warrant a subsystem-level description of the TSF in addition to the modular description, the developer provides a simple mapping showing how the modules of the TSF are allocated to the subsystems. This will provide the evaluator a guide in performing their module-level assessment. To determine completeness, the evaluator examines each mapping and determines that all subsystems map to at least one module, and that all modules map to exactly one subsystem.

ADV_TDS.5-10 The evaluator shall examine the TOE design to determine that the mapping between the subsystems of the TSF to the modules of the TSF is accurate.

638 If the design is presented solely in terms of modules, then this work unit is considered satisfied.

639 For TOEs that are complex enough to warrant a subsystem-level description of the TSF in addition to the modular description, the developer provides a simple mapping showing how the modules of the TSF are allocated to the subsystems. This will provide the evaluator a guide in performing their module-level assessment. The evaluator may choose to check the accuracy of the mapping in conjunction with performing other work units. An “inaccurate” mapping is one where the module is mistakenly associated with a subsystem where its functions are not used within the subsystem. Because the mapping is intended to be a guide supporting more detailed analysis, the evaluator is cautioned to apply appropriate effort to this work unit. Expending extensive evaluator resources verifying the accuracy of the mapping is not necessary. Inaccuracies that lead to mis-understandings related to the design that are uncovered as part of this or other work units are the ones that should be associated with this work unit and corrected.

ADV_TDS.5.7C The design shall provide a semiformal description of each module in terms of its purpose, interaction, interfaces, return values from those interfaces, and called interfaces to other modules, supported by informal, explanatory text where appropriate.

ADV_TDS.5-11 The evaluator shall examine the TOE design to determine that the semiformal description of the purpose of each module, and its relationship with other modules is complete and accurate.

640 The developer may designate modules as SFR-enforcing, SFR-supporting, and SFR non-interfering, but these “tags” are used only to describe the amount and type of information the developer must provide, and can be used to limit the amount of information the developer has to develop if their engineering process does not produce the documentation required. Whether the modules have been categorised by the developer or not, it is the evaluator's responsibility to determine that the modules have the appropriate information for their role (SFR-enforcing, etc.) in the TOE, and to obtain the appropriate information from the developer should the developer fail to provide the required information for a particular module.

641 The purpose of a module provides a description indicating what function the module is fulfilling. A word of caution to the evaluator is in order. The focus of this work unit should be to provide the evaluator an understanding of how the module works so that determinations can be made about the soundness of the implementation of the SFRs, as well as to support architectural analysis performed for ADV_ARC subsystems. As long as the evaluator has a sound understanding of the module's operation, and its relationship to other modules and the TOE as a whole, the evaluator should consider the objective of the work

118/139 AIS 34_3


achieved and not engage in a documentation exercise for the developer (by requiring, for example, a complete algorithmic description for a self-evident implementation representation).

642 Because the modules are at such a low level, it may be difficult determine completeness and accuracy impacts from other documentation, such as operational user guidance, the functional specification, the TSF internals, or the security architecture description. However, the evaluator uses the information present in those documents to the extent possible to help ensure that the purpose is accurately and completely described. This analysis can be aided by the analysis performed for the work units for the ADV_TDS.5.8C element, which maps the TSFI in the functional specification to the modules of the TSF.

ADV_TDS.5-12 The evaluator shall examine the TOE design to determine that the semiformal description of the interfaces presented by each module contain an accurate and complete description of the related parameters, the invocation conventions for each interface, and any values returned directly by the interface.

643 The interfaces of a module are those interfaces used by other modules as a means to invoke the operations provided, and to provide inputs to or receive outputs from the module. The purpose in the specification of these interfaces is to permit the exercise of them during testing. Inter-module interfaces that are not SFR-related need not be specified or described, since they are not a factor in testing. Likewise, other internal interfaces that are not a factor in traversing SFR-related paths of execution (such as those internal paths that are fixed).

644 SFR-related interfaces are all interfaces that are called directly or indirectly from SFR-enforcing modules. Those interfaces need to be described with all the parameter used in such a call. This allows the evaluator to understand the purpose of the call in the context of operation of the SFR-enforcing modules.

645 SFR-related interfaces are described in terms of how they are invoked, and any values that are returned. This description would include a list of parameters, and descriptions of these parameters. Note that global data would also be considered parameters if used by the module (either as inputs or outputs) when invoked. If a parameter were expected to take on a set of values (e.g., a “flag” parameter), the complete set of values the parameter could take on, that would have an effect on module processing, would be specified. Likewise, parameters representing data structures are described such that each field of the data structure is identified and described. Note that different programming languages may have additional “interfaces” that would be non-obvious; an example would be operator/function overloading in C++. This “implicit interface” in the class description would also be described as part of the low-level TOE design. Note that although a module could present only one interface, it is more common that a module presents a small set of related interfaces.

646 In terms of the assessment of parameters (inputs and outputs) to a module, any use of global data must also be considered. A module “uses” global data if it either reads or writes the data. In order to assure the description of such parameters (if used) is complete, the evaluator uses other information provided about the module in the TOE design (interfaces, algorithmic description, etc.), as well as the description of the particular set of global data assessed in work unit ADV_TDS.5-10. For instance, the evaluator could first determine the processing the module performs by examining its function and interfaces presented (particularly the parameters of the interfaces). They could then check to see if the processing appears to “touch” any of the global data areas identified in the TDS design. The evaluator then determines that, for each global data area that appears to be “touched”, that global data area is listed as a means of input or output by the module the evaluator is examining.

647 Invocation conventions are a programming-reference-type description that one could use to correctly invoke a module's interface if one were writing a program to make use of the

AIS 34_3 119/139


module's functionality through that interface. This includes necessary inputs and outputs, including any set-up that may need to be performed with respect to global variables.

648 Values returned through the interface refer to values that are either passed through parameters or messages; values that the function call itself returns in the style of a “C” program function call; or values passed through global means (such as certain error routines in *ix-style operating systems).

649 In order to assure the description is complete, the evaluator uses other information provided about the module in the TOE design (e.g., algorithmic description, global data used) to ensure that it appears all data necessary for performing the functions of the module is presented to the module, and that any values that other modules expect the module under examination to provide are identified as being returned by the module. The evaluator determines accuracy by ensuring that the description of the processing matches the information listed as being passed to or from an interface.

ADV_TDS.5.8C The mapping shall demonstrate that all TSFIs trace to the behaviour described in the TOE design that they invoke.

ADV_TDS.5-13 The evaluator shall examine the TOE design to determine that it contains a complete and accurate mapping from the TSFI described in the functional specification to the modules of the TSF described in the TOE design.

650 The modules described in the TOE design provide a description of the implementation of the TSF. The TSFI provide a description of how the implementation is exercised. The evidence from the developer identifies the module that is initially invoked when an operation is requested at the TSFI, and identify the chain of modules invoked up to the module that is primarily responsible for implementing the functionality. However, a complete call tree for each TSFI is not required for this work unit. The cases in which more than one module would have to be identified are where there are “entry point” modules or wrapper modules that have no functionality other than conditioning inputs or de-multiplexing an input. Mapping to one of these modules would not provide any useful information to the evaluator.

651 The evaluator assesses the completeness of the mapping by ensuring that all of the TSFI map to at least one module. The verification of accuracy is more complex.

652 The first aspect of accuracy is that each TSFI is mapped to a module at the TSF boundary. This determination can be made by reviewing the module description and its interfaces/interactions. The next aspect of accuracy is that each TSFI identifies a chain of modules between the initial module identified and a module that is primarily responsible for implementing the function presented at the TSF. Note that this may be the initial module, or there may be several modules, depending on how much pre-conditioning of the inputs is done. It should be noted that one indicator of a pre-conditioning module is that it is invoked for a large number of the TSFI, where the TSFI are all of similar type (e.g., system call). The final aspect of accuracy is that the mapping makes sense. For instance, mapping a TSFI dealing with access control to a module that checks passwords is not accurate. The evaluator should again use judgement in making this determination. The goal is that this information aids the evaluator in understanding the system and implementation of the SFRs, and ways in which entities at the TSF boundary can interact with the TSF. The bulk of the assessment of whether the SFRs are described accurately by the modules is performed in other work units.

2.3.5 Action ADV_TDS.5.2E

ADV_TDS.5-14 The evaluator shall examine the TOE security functional requirements and the TOE design, to determine that all ST security functional requirements are covered by the TOE design.

653 The evaluator may construct a map between the TOE security functional requirements and the TOE design. This map will likely be from a functional requirement to a set of subsystems, and later to modules. Note that this map may have to be at a level of detail

120/139 AIS 34_3


below the component or even element level of the requirements, because of operations (assignments, refinements, selections) performed on the functional requirement by the ST author.

654 For example, the FDP_ACC.1 Subset access control component contains an element with assignments. If the ST contained, for instance, ten rules in the FDP_ACC.1 Subset access control assignment, and these ten rules were implemented in specific places within fifteen modules, it would be inadequate for the evaluator to map FDP_ACC.1 Subset access control to one subsystem and claim the work unit had been completed. Instead, the evaluator would map FDP_ACC.1 Subset access control (rule 1) to modules x, y and z of subsystem A; FDP_ACC.1 Subset access control (rule 2) to x, p, and q of subsystem A; etc.

ADV_TDS.5-15 The evaluator shall examine the TOE design to determine that it is an accurate instantiation of all security functional requirements.

655 The evaluator may construct a map between the TOE security functional requirements and the TOE design. This map will likely be from a functional requirement to a set of subsystems and modules. Note that this map may have to be at a level of detail below the component or even element level of the requirements, because of operations (assignments, refinements, selections) performed on the functional requirement by the ST author.

656 As an example, if the ST requirements specified a role-based access control mechanism, the evaluator would first identify the subsystems, and modules that contribute to this mechanism's implementation. This could be done by in-depth knowledge or understanding of the TOE design or by work done in the previous work unit. Note that this trace is only to identify the subsystems, and modules, and is not the complete analysis.

657 The next step would be to understand what mechanism the subsystems, and modules implemented. For instance, if the design described an implementation of access control based on UNIX-style protection bits, the design would not be an accurate instantiation of those access control requirements present in the ST example used above. If the evaluator could not determine that the mechanism was accurately implemented because of a lack of detail, the evaluator would have to assess whether all of the SFR-enforcing subsystems and modules have been identified, or if adequate detail had been provided for those subsystems and modules.

AIS 34_3 121/139


2.4 Evaluation of sub-activity (ADV_IMP.2)

658 The work units for the evaluation of the sub-activity ADV_IMP.2 are copied from the work units of ADV_IMP.1 as far as possible.

659 Editor's note:

660 The difference to ADV_IMP.1 consists only in the fact that the mapping between TOE design and implementation representation needs to be complete now.

661 This was covered by the new work unit ADV_IMP.2-4.

662 Two other additions were made in comparison to ADV_IMP.1:

• In work unit -1 a remark was added that explicit verification of the fact that the actual TOE is uniquely generatable from the implementation representation can be easier to do and at the same time be more reliable than trying to "see" this in the source code. (Of course this is already true for ADV_IMP.1, if possible.)

• Because of the completeness requirement it seemed to be adequate to add a paragraph in work unit -3, that usually the evaluator should at least check the accuracy of the implementation of the SFRs and of those parts of the security architecture, for which this is possible. (Note, that in CC 3.1 there is no explicit requirement any more to map the SFRs to the implementation representation.)

2.4.1 Objectives

663 The objective of this sub-activity is to determine that the implementation representation made available by the developer is suitable for use in other analysis activities; suitability is judged by its conformance to the requirements for this component.

2.4.2 Input


a) the implementation representation;

b) the documentation of the development tools, as resulting from ALC_TAT;

c) the TOE design description.


665 The entire implementation representation is made available to ensure that analysis activities are not curtailed due to lack of information. This does not, however, imply that all of the representation is examined in detail when the analysis activities are being performed. This is likely impractical in almost all cases, in addition to the fact that it most likely will not result in a higher-assurance TOE.

666 The new aspect for ADV_IMP.2 in comparison to ADV_IMP.1 is that the developer needs to demonstrate and the evaluator will confirm that the complete implementation representation is mapped to the TOE design description. This does, however, not imply that all other work units need an examination of the complete implementation representation. Aspects like appropriate level of detail and form of the implementation representation can be covered by sampling as for ADV_IMP.1.

2.4.4 Action ADV_IMP.2.1E

ADV_IMP.2.1C The implementation representation shall define the TSF to a level of detail such that the TSF can be generated without further design decisions.

ADV_IMP.2-1 The evaluator shall check that the implementation representation defines the TSF to a level of detail such that the TSF can be generated without further design decisions.

122/139 AIS 34_3


667 Source code or hardware diagrams and/or IC hardware design language code or layout data that are used to build the actual hardware are examples of parts of an implementation representation. The evaluator samples the implementation representation to gain confidence that it is at the appropriate level and not, for instance, a pseudo-code level which requires additional design decisions to be made. The evaluator is encouraged to perform a quick check when first looking at the implementation representation to assure themselves that the developer is on the right track. However, the evaluator is also encourage to perform the bulk of this check while working on other work units that call for examining the implementation; this will ensure the sample examined for this work unit is relevant.

668 If the evaluator has the possibility to actually execute or witness the "built" procedure used to transfer the implementation representation into the actual implementation, and to compare the result to the TOE as delivered, this may provide an easier and at the same time more reliable check for this work unit (and possibly also for the following one).

ADV_IMP.2.2C The implementation representation shall be in the form used by the development personnel.

ADV_IMP.2-2 The evaluator shall check that the implementation representation is in the form used by development personnel.

669 The implementation representation is manipulated by the developer in form that it suitable for transformation to the actual implementation. For instance, the developer may work with files containing source code, which is eventually compiled to become part of the TSF. The developer makes available the implementation representation in the form they use, so that the evaluator may use automated techniques in the analysis. This also increases the confidence that the implementation representation examined is actually the one used in the production of the TSF (as opposed to the case where it is supplied in an alternate presentation format, such as a word processor document). It should be noted that other forms of the implementation representation may also be used by the developer; these forms are supplied as well. The overall goal is to supply the evaluator with the information that will maximise the evaluator's analysis efforts.

670 The evaluator samples the implementation representation to gain confidence that it is the version that is usable by the developer. The sample is such that the evaluator has assurance that all areas of the implementation representation are in conformance with the requirement; however, a complete examination of the entire implementation representation is unnecessary.

671 Conventions in some forms of the implementation representation may make it difficult or impossible to determine from just the implementation representation itself what the actual result of the compilation or run-time interpretation will be. For example, compiler directives for C language compilers will cause the compiler to exclude or include entire portions of the code.

672 Some forms of the implementation representation may require additional information because they introduce significant barriers to understanding and analysis. Examples include shrouded source code or source code that has been obfuscated in other ways such that it prevents understanding and/or analysis. These forms of implementation representation typically result from by taking a version of the implementation representation that is used by the TOE developer and running a shrouding or obfuscation program on it. While the shrouded representation is what is compiled and may be closer to the implementation (in terms of structure) than the original, un-shrouded representation, supplying such obfuscated code may cause significantly more time to be spent in analysis tasks involving the representation. When such forms of representation are created, the components require details on the shrouding tools/algorithms used so that the un-shrouded representation can be supplied, and the additional information can be used to gain confidence that the shrouding process does not compromise any security mechanisms.

AIS 34_3 123/139


673 The evaluator samples the implementation representation to gain confidence that all of the information needed to interpret the implementation representation has been supplied. Note that the tools are among those referenced by Tools and techniques (ALC_TAT) components. The evaluator is encouraged to perform a quick check when first looking at the implementation representation to assure themselves that the developer is on the right track. However, the evaluator is also encouraged to perform the bulk of this check while working on other work units that call for examining the implementation; this will ensure the sample examined for this work unit is relevant.

ADV_IMP.2.3C The mapping between the TOE design description and the entire implementation representation shall demonstrate their correspondence.

ADV_IMP.2-3 The evaluator shall examine the mapping between the TOE design description and the entire implementation representation to determine that it is accurate.

674 The evaluator augments the determination of existence (specified in work unit ADV_IMP.2-1) by verifying the accuracy of the implementation representation and the TOE design description. For those parts of TOE design description that are interesting, the evaluator would verify the implementation representation accurately reflects the description provided in the TOE design description.

675 For example, the TOE design description might identify a login module that is used to identify and authenticate users. If user authentication is sufficiently significant, the evaluator would verify that the corresponding code in fact implements that service as described in the TOE design description. It might also be worthwhile to verify that the code accepts the parameters as described in the functional specification.

676 Usually it will be expected that the evaluator considers at least the functionality required by the SFRs chosen in the ST and aspects described in the security architecture description as "interesting" in the sense discussed above. Note however that not all aspects of the security architecture are necessarily traceable to specific parts of the implementation representation.

677 It is worth pointing out the developer must perform the mapping for the entire implementation representation, thereby guaranteeing that the chosen sample will be covered.

ADV_IMP.2-4 The evaluator shall examine the mapping between the TOE design description and the entire implementation representation to determine that it is complete.

678 Note that the completeness here is relevant in both directions: The complete TOE design needs to be covered by the implementation representation and all parts of the implementation representation needs to be mapped to a corresponding part of the TOE design.

679 In order to confirm that the entire implementation representation is covered by the mapping the evaluator will not need to examine the content of every part of the implementation representation. If (in the case of a software TOE) the mapping is for example described by mapping each source code file to a module in the TOE design description, it will be sufficient if this mapping is plausible from the role of the source code file the evaluator can conclude from information like the naming of the source code files, their grouping in subdirectories or their grouping in "built" procedures. Note, that aspects of accuracy are covered by the preceeding work unit.

680 In order to confirm that the entire design description is covered by the implementation, the evaluator may either use a similar argument as in the other direction, i. e. that all modules contained in the TOE design description are mapped to parts of the implementation representation in a plausible way. In addition, if the evaluator has established in the preceding work unit that all SFRs and all applicable parts of the security architecture description are traceable to the implementation representation this may be seen as sufficient evidence that the mapping is complete.

124/139 AIS 34_3


2.5 Evaluation of sub-activity (ADV_INT.3)

681 The work units for the evaluation of the sub-activity ADV_INT.3 are copied from the work units of ADV_INT.2 as far as possible.

682 Editor's note:

683 There are two new new aspects in ADV_INT.3 compared to ADV_INT.2:

• Besides being "well structured" the TSF shall also be "not overly complex". This was introduced in the already existing work units in order to handle "well structured" and "not overly complex" in parallel, wherever possible. This seems to be more economical than adding a set of very similar new work units for the "not overly complex" aspect. In practice we expect, that the developer will also try to discuss both aspects in a parallel way instead of producing two separate justifications.

• The evaluator is required to perform an analysis of the entire TSF. This could also be included into the existing work units by adequate wording. Here we assume that only some activities are really useful to be done for the complete TSF and TOE design: Checking that the set of all modules is understandable will be possible for many TOEs, applying a complexity metric (which should ideally be automated) should also be possible. On the other hand, for checking that implementation standards (as defined in ATE_TAT) are used correctly, sampling should be sufficient like in ADV_INT.2, since there is no additional use of looking into every single source file to check for "nice" programming.

2.5.1 Objectives

684 The objective of this sub-activity is to determine whether the TSF is designed and structured such that the likelihood of flaws is reduced and that maintenance can be more readily performed without the introduction of flaws.

2.5.2 Input


a) the modular design description;

b) the implementation representation (if ADV_IMP is part of the claimed assurance);

c) the TSF internals description;

d) the documentation of the coding standards, as resulting from ALC_TAT.


686 The role of the internals description is to provide evidence of the structure of the design and implementation of the TSF.

687 The structure of the design has two aspects: the constituent parts of the TSF and the procedures used to design the TSF. In cases where the TSF is designed in a manner consistent with the design represented by the TOE design (see ADV_TDS), the assessment of the TSF design is obvious. In cases where the design procedures (see ALC_TAT) are being followed, the assessment of the TSF design procedures is similarly obvious.

688 In cases where the TSF is implemented using procedure-based software, this structure is assessed on the basis of its modularity; the modules identified in the internals description are the same as the modules identified in the TOE design (TOE design (ADV_TDS)). A module consists of one or more source code files that cannot be decomposed into smaller compilable units.

AIS 34_3 125/139


689 The primary goal of this component is to ensure the TSF's implementation representation is understandable to facilitate maintenance and analysis (of both the developer and evaluator).

2.5.4 Action ADV_INT.3.1E

ADV_INT.3.1C The justification shall describe the characteristics used to judge the meaning of “well-structured” and “complex”.

ADV_INT.3-1 The evaluator shall examine the justification to determine that it identifies the basis for determining whether the TSF is "well-structured" and "not overly complex".

690 The evaluator verifies that the criteria for determining the characteristic of being "well-structured" and "complex" are clearly defined in the justification. Acceptable criteria typically originate from industry standards for the technology discipline. For example, procedural software that executes linearly is traditionally viewed as well-structured if it adheres to software engineering programming practises, such as those defined in the IEEE Standard (IEEE Std 610.12-1990). For example, it would identify the criteria for the procedural software portions of the TSF:

a) the process used for modular decomposition

b) coding standards used in the development of the implementation

c) a description of the maximum acceptable level of intermodule coupling exhibited by

the TSF

d) a description of the minimum acceptable level of cohesion exhibited the modules of

the TSF

691 Complexity can for example be measured in the number of decision points and logical paths of execution that code takes. Software engineering literature cites complexity as a negative characteristic of software because it impedes understanding of the logic and flow of the code. Another impediment to the understanding of code is the presence of code that is unnecessary, in that it is unused or redundant.

692 Design complexity minimisation is a key characteristic of a reference validation mechanism, the purpose of which is to arrive at a TSF that is easily understood so that it can be completely analysed.

693 See also CC 3.1, Part 3, Annex A.3 for additional information on TSF internals.

694 The consideration in that annex and those made in the preceding paragraphs of this work unit are mainly derived from common knowledge about procedural software. For other types of technologies used in the TOE - such as non-procedural software (e.g. object-oriented programming), widespread commodity hardware (e.g. PC microprocessors), and special-purpose hardware (e.g. smart-card processors) - the evaluation authority should be consulted for determining the adequacy of criteria for being “well-structured” and "not overly complex".

695 The evaluator is reminded to be open for plausible definitions given by the developer. If. for example, a smart card developer can justify that the metrics used by him to measure complexity are an industry standard in his field, this should usually be sufficient for acceptance of such metrics.

696

ADV_INT.3.2C The TSF internals description shall demonstrate that the entire TSF is well-structured and is not overly complex.

ADV_INT.3-2 The evaluator shall examine the TSF internals description to determine that it demonstrates that the TSF is well-structured and not overly complex.

126/139 AIS 34_3


697 The evaluator examines the internals description to ensure that it provides a sound explanation of how the TSF meets the criteria from ADV_INT.3-1

698 For example, it would explain how the procedural software portions of the TSF meet the following:

a) that there is a one-to-one correspondence between the modules identified in the TSF and the modules described in the TOE design (ADV_TDS)

b) how the TSF design is a reflection of the modular decomposition process

c) a justification for all instances where the coding standards were not used or met

d) a justification for any coupling or cohesion outside the acceptable bounds

e) how the modular decomposition process reduces complexity

2.5.5 Action ADV_INT.3.2E

ADV_INT.3-3 The evaluator shall determine that the entire TOE design is well-structured and not overly complex.

699 The evaluator examines the TOE design description of the TSF to verify the accuracy of the justification. For example, a sample of the TOE design is analysed to determine its adherence to the design standards, etc. As with all areas where the evaluator performs activities on a subset the evaluator provides a justification of the sample size and scope

700 The description of the TOE's decomposition into subsystems and modules will make the argument that the TSF is well-structured self-evident. Verification that the procedures for structuring the TSF (as examined in ALC_TAT) are being followed will make it self-evident that the TSF is well-structured.

701 Using the metrics defined by the developer for measuring the complexity of the design will show if the metrics is met. If the metrics is only defined for the implementation representation and not for the TOE design (note that adequateness of the metrics was considered already in work unit ADV_INT.3-1), there may be no need for using the metrics in this work unit, the complexity-issue is then covered by the next work unit.

ADV_INT.3-4 The evaluator shall determine that the entire TSF is well-structured and not overly complex.

702 If ADV_IMP is not part of the claimed assurance, then this work unit is not applicable and is therefore considered to be satisfied.

703 The evaluator examines a sample of the TSF to verify the accuracy of the internals description. For example, a sample of the procedural software portions of the TSF is analysed to determine its cohesion and coupling, its adherence to the coding standards, etc. As with all areas where the evaluator performs activities on a subset the evaluator provides a justification of the sample size and scope.

704 Similarly the evaluator applies the metric for complexity as defined by the developer and examined in work unit ADV_INT.3-1 to either a sample of the implementation representation or the complete implementation representation (this may depend on the metric) and verifies that the metric is in fact met. The evaluator may only restrict his application of the metrics to a sample if the developer has provided the results of the application of the metrics for the entire TSF and the sampling serves as means to convince the evaluator that the application as done by the developer was correct (similar to the evaluator's sampling of functional testing already done by the developer).

AIS 34_3 127/139


2.6 Evaluation of sub-activity (ATE_COV.3)

705 The work units for the evaluation of the sub-activity ATE_COV.3 are copied from the work units of ATE_COV.2 as far as possible.

706 Editor's note:

707 The difference to ATE_COV.2 consists in the requirement for complete testing of each TSFI. This is covered by the new work unit ATE_COV.3-5.

2.6.1 Objectives

708 The objective of this sub-activity is to determine whether the developer has tested all of the TSFIs exhaustively, and that the developer's test coverage evidence shows correspondence between the tests identified in the test documentation and the TSFIs described in the functional specification.

709 A particular objective of this component is to confirm that all parameters of all of the TSFIs have been tested.

2.6.2 Input


a) the ST;


c) the test documentation;

d) the test coverage analysis.

2.6.3 Action ATE_COV.3.1E

ATE_COV.3.1C The analysis of the test coverage shall demonstrate the correspondence between the tests in the test documentation and the TSFIs in the functional specification.

ATE_COV.3-1 The evaluator shall examine the test coverage analysis to determine that the correspondence between the tests in the test documentation and the interfaces in the functional specification is accurate.

711 A simple cross-table may be sufficient to show test correspondence. The identification of the tests and the interfaces presented in the test coverage analysis has to be unambiguous.

712 The evaluator is reminded that this does not imply that all tests in the test documentation must map to interfaces in the functional specification.

ATE_COV.3-2 The evaluator shall examine the test plan to determine that the testing approach for each interface demonstrates the expected behaviour of that interface.

713 Guidance on this work unit can be found in:

a) 14.2.1 [CEM31], Understanding the expected behaviour of the TOE

b) 14.2.2 [CEM31], Testing vs. alternate approaches to verify the expected behaviour of functionality

ATE_COV.3-3 The evaluator shall examine the test procedures to determine that the test prerequisites, test steps and expected result(s) adequately test each interface.

714 Guidance on this work units, as it pertains to the functional specification, can be found in:

a) 14.2.3 [CEM31], Verifying the adequacy of tests

128/139 AIS 34_3


ATE_COV.3.2C The analysis of the test coverage shall demonstrate that all TSFIs in the functional specification have been completely tested.

ATE_COV.3-4 The evaluator shall examine the test coverage analysis to determine that the correspondence between the interfaces in the functional specification and the tests in the test documentation is complete.

715 All TSFIs that are described in the functional specification have to be present in the test coverage analysis and mapped to tests in order for completeness to be claimed. Exhaustive specification testing of interfaces is required for this mapping. Incomplete coverage would be evident if an interface was identified in the functional specification and no test was mapped to it.

The evaluator is reminded that this does not imply that all tests in the test documentation must map to interfaces in the functional specification.

ATE_COV.3-5 The evaluator shall examine the test coverage analysis to determine that the correspondence between the interfaces in the functional specification and the tests in the test documentation shows that all TSFIs were tested completely.

This means that the evaluator examines whether all aspects of purpose, method of use, parameters, parameter descriptions, actions and error messages for all TSFIs present in the functional specification are covered by the tests. Note that the level of detail present in the functional specification depends on the component of ADV_FSP chosen in the ST of the TOE.

716 The evaluator may conclude that the higher level descriptions in the functional specification, like purpose or method of use, are implicitly covered, if coverage of lower level descriptions like parameters, parameter descriptions, actions and error messages are covered. Therefore in general it will only be necessary to confirm coverage on these lower levels.

717 The evaluator is reminded that (for example) coverage of all parameters does not necessarily mean coverage of every possible value a parameter may allow. However every value for which a distinct qualitative behaviour of the TOE is expected, needs to be covered.

718 As an example: If one of the parameters of a function call is a two byte value, which specifies the length of further parameters, only some typical values need to be tested. However the evaluator will make sure that some specific cases (like the value zero or the maximal value) will be covered.

719 If the evaluator sees that a potential attacker might be able to invoke a TSFI with inconsistent parameter values (e. g. if one parameter specifies the length of a second parameter and it is possible to make the second parameter actually longer than the chosen value for the first parameter suggests) and this case is not covered by the developer's testing, the evaluator may decide either to test this during his activities in AVA_VAN or to require the developer to provide coverage also for this case.

720 Similar considerations as for parameters hold for error messages specified in the functional specification: Each error message, which belongs to a qualitatively distinct error case, needs to be covered by testing. Note, that there may be exceptions, for example error messages for errors, which cannot be provoked during testing,. For such error messages other ways of coverage need to be found as discussed in 14.2.2 [CEM31], "Testing vs. alternate approaches to verify the expected behaviour of functionality".

721 Note that also the developer is allowed to use such alternative approaches to testing (e. g. checking something in the source code) in his coverage table. Of course the evaluator has to examine in this case, if this use of an alternative approach is acceptable (usually only in cases where testing is practically impossible).

AIS 34_3 129/139


2.7 Evaluation of sub-activity (ATE_FUN.2)

722 The work units for the evaluation of the sub-activity ATE_FUN.2 are copied from the work units of ATE_FUN.2 as far as possible.

723 Editor's note:

724 The difference to ATE_FUN.1 consists in the requirement for an "analysis of test ordering dependencies". Since this is a new concept on this level, the new work unit ATE_FUN.2-8 was written for this, which also gives a long example of what we understand as the important aspect of this work unit.

2.7.1 Objectives

725 The objective of this sub-activity is to determine whether the developer correctly performed and documented the tests in the test documentation and to ensure that testing is structured such as to avoid circular arguments about the correctness of the interfaces being tested.

2.7.2 Input


a) the ST;


c) the test documentation.


727 Although the test procedures may state pre-requisite initial test conditions in terms of ordering of tests, they may not provide a rationale for the ordering. An analysis of test ordering, which provides this rationale, is an important factor in determining the adequacy of testing, as there is a possibility of faults being concealed by the ordering of tests.

2.7.4 Action ATE_FUN.2.1E

ATE_FUN.2.1C The test documentation shall consist of test plans, expected test results and actual test results.

ATE_FUN.2-1 The evaluator shall check that the test documentation includes test plans, expected test results and actual test results.

728 The evaluator checks that test plans, expected tests results and actual test results are included in the test documentation.

ATE_FUN.2.2C The test plans shall identify the tests to be performed and describe the scenarios for performing each test. These scenarios shall include any ordering dependencies on the results of other tests.

ATE_FUN.2-2 The evaluator shall examine the test plan to determine that it describes the scenarios for performing each test.

729 The evaluator determines that the test plan provides information about the test configuration being used: both on the configuration of the TOE and on any test equipment being used. This information should be detailed enough to ensure that the test configuration is reproducible.

730 The evaluator also determines that the test plan provides information about how to execute the test: any necessary automated set-up procedures (and whether they require privilege to run), inputs to be applied, how these inputs are applied, how output is obtained, any automated clean-up procedures (and whether they require privilege to run), etc. This information should be detailed enough to ensure that the test is reproducible.

130/139 AIS 34_3


731 The evaluator may wish to employ a sampling strategy when performing this work unit.

ATE_FUN.2-3 The evaluator shall examine the test plan to determine that the TOE test configuration is consistent with the ST.

732 The TOE referred to in the developer's test plan should have the same unique reference as established by the CM capabilities (ALC_CMC) sub-activities and identified in the ST introduction.

733 It is possible for the ST to specify more than one configuration for evaluation. The evaluator verifies that all test configurations identified in the developer test documentation are consistent with the ST. For example, the ST might define configuration options that must be set, which could have an impact upon what constitutes the TOE by including or excluding additional portions. The evaluator verifies that all such variations of the TOE are considered.

734 The evaluator should consider the security objectives for the operational environment described in the ST that may apply to the test environment. There may be some objectives for the operational environment that do not apply to the test environment. For example, an objective about user clearances may not apply; however, an objective about a single point of connection to a network would apply.


736 If this work unit is applied to a component TOE that might be used/integrated in a composed TOE (see Class ACO: Composition), the following will apply. In the instances that the component TOE under evaluation depends on other components in the operational environment to support their operation, the developer may wish to consider using the other component(s) that will be used in the composed TOE to fulfil the requirements of the operational environment as one of the test configurations. This will reduce the amount an additional testing that will be required for the composed TOE evaluation.

ATE_FUN.2-4 The evaluator shall examine the test plans to determine that sufficient instructions are provided for any ordering dependencies.

737 Some steps may have to be performed to establish initial conditions. For example, user accounts need to be added before they can be deleted. An example of ordering dependencies on the results of other tests is the need to perform actions in a test that will result in the generation of audit records, before performing a test to consider the searching and sorting of those audit records. Another example of an ordering dependency would be where one test case generates a file of data to be used as input for another test case.


ATE_FUN.2.3C The expected test results shall show the anticipated outputs from a successful execution of the tests.

ATE_FUN.2-5 The evaluator shall examine the test documentation to determine that all expected tests results are included.

739 The expected test results are needed to determine whether or not a test has been successfully performed. Expected test results are sufficient if they are unambiguous and consistent with expected behaviour given the testing approach.


ATE_FUN.2.4C The actual test results shall be consistent with the expected test results.

ATE_FUN.2-6 The evaluator shall check that the actual test results in the test documentation are consistent with the expected test results in the test documentation.

741 A comparison of the actual and expected test results provided by the developer will reveal any inconsistencies between the results. It may be that a direct comparison of actual results cannot be made until some data reduction or synthesis has been first

AIS 34_3 131/139


performed. In such cases, the developer's test documentation should describe the process to reduce or synthesise the actual data.

742 For example, the developer may need to test the contents of a message buffer after a network connection has occurred to determine the contents of the buffer. The message buffer will contain a binary number. This binary number would have to be converted to another form of data representation in order to make the test more meaningful. The conversion of this binary representation of data into a higher-level representation will have to be described by the developer in enough detail to allow an evaluator to perform the conversion process (i.e. synchronous or asynchronous transmission, number of stop bits, parity, etc.).

743 It should be noted that the description of the process used to reduce or synthesise the actual data is used by the evaluator not to actually perform the necessary modification but to assess whether this process is correct. It is up to the developer to transform the expected test results into a format that allows an easy comparison with the actual test results.


ATE_FUN.2-7 The evaluator shall report the developer testing effort, outlining the testing approach, configuration, depth and results.

745 The developer testing information recorded in the ETR allows the evaluator to convey the overall testing approach and effort expended on the testing of the TOE by the developer. The intent of providing this information is to give a meaningful overview of the developer testing effort. It is not intended that the information regarding developer testing in the ETR be an exact reproduction of specific test steps or results of individual tests. The intention is to provide enough detail to allow other evaluators and evaluation authorities to gain some insight about the developer's testing approach, amount of testing performed, TOE test configurations, and the overall results of the developer testing.

746 Information that would typically be found in the ETR section regarding the developer testing effort is:

a) TOE test configurations. The particular configurations of the TOE that were tested, including whether any privileged code was required to set up the test or clean up afterwards;

b) testing approach. An account of the overall developer testing strategy employed;

c) testing results. A description of the overall developer testing results.

747 This list is by no means exhaustive and is only intended to provide some context as to the type of information that should be present in the ETR concerning the developer testing effort.

ATE_FUN.2.5C The test documentation shall include an analysis of the test procedure ordering dependencies.

ATE_FUN.2-8 The evaluator shall examine the analysis of the test procedure ordering dependencies to determine that a sufficient justification for the chosen ordering of test cases is given.

748 Usually the evaluator will generate a table of all cases, where the test documentation requires a certain ordering of the tests and will then examine if sufficient justification is given in any case, why testing in this ordering is adequate and sufficient.

749 As an example we assume that the TSF provide a random number generator, which needs to be initialised (for example with an adequate seed) before random numbers of

132/139 AIS 34_3


a specified quality can be generated. In this case the evaluator will consider the following question:

750 Does the test documentation only describe an ordering of tests, where the initialisation is done before calling the function to generate a random number?

751 In this case the justification needs to show, why the developer expects, that in the intended environment of the TOE the random number function will not be called without initialisation of the random number generator.

752 If for example the user guidance documentation includes a clear instruction that the random number generator needs to be initialised adequately before being called, this may be considered adequate as a justification. (note that the question if it can be plausibly assumed that users will follow such instruction is covered by the evaluation activities for the classes ASE and AGD and needs not to be re-examined here.)

753 If, on the other hand, the TOE provides an authentication protocol, which implicitly uses random numbers provided by the random number generator, and an attacker can therefore "call" the random number generator implicitly by simply trying to authenticate himself, and if neither the TOE nor the environment prevent an attacker from doing this even before the random number generator is initialised, a test case needs to show, what happens in such situation.

754 If, for example, instead of returning a "bad" random number, the random number function would return an error, when called without proper initialisation, it would be much better to include a test showing this secure behaviour instead of trying to justify why the functions are only tested in the usual order.

755 Note: Of course even without ATE_FUN.2 an evaluator would be expected to look for potential vulnerabilities like the one described above. However, ATE_FUN.2.5C adds assurance by requiring the developer to give a systematic justification, why his chosen order of test cases doesn't hide such potential failures of security functions.

AIS 34_3 133/139


3 Annexes

3.1 Evaluation Techniques and Tools

3.1.1 Semiformal and formal methods

756 In [CC31] part 3, Annex A.5, supplementary material on formal methods is provided. So this annex mainly concerns CC v2.3 evaluations.

3.1.1.1 Description of styles

757 This section provides general guidance on specification styles. Specific and detailed information is in those work units under the specific evaluator action elements where examination of the style of specifications, TSP model and correspondence demonstrations has to be performed.

758 The ADV class mandates three types of specification styles: informal, semiformal and formal. These styles are briefly described in the application notes to the ADV class in CC part 2. The functional specification, high-level design, low-level design and TSP models will be written using one or more of these specification styles. The TSF representations and the TSP model (in the following referred to as specifications) may use one or more notations in semiformal and formal style. The level of formality of the correspondence representation depends on the style of the adjacent pair of provided TSF representation (see the ADV_RCR family for details).

759 The hierarchy of components within these families increase the formality of the styles

- to reduce the ambiguity of the TSF representation through the hierarchy of components within the families,

- to reduce the likelihood of refinement errors in the available TSF representations,

- to strengthen the evidence for correctness of the TSF representations and the methods for their examination.

The styles are shortly characterised by

- informal style- defined semantics

- semiformal style - defined semantics and syntax

- formal style - defined semantics, syntax and rules of inference.

760 Regarding the notions of semantics and syntax the degree of precision varies with the style of description.

761 Informal descriptions require the semantics to provide meaning to all terms with the help of natural language explanations.

762 Semiformal descriptions restrict the syntax formation of terms to well defined expressions having a precise meaning in the technical community.

763 Formal style descriptions restrict the semantics and syntax even further: The formation of syntactical terms follows a formal language description required to be decidable. Examples include well established implicit formation rules being as precise as the formation of terms and formulas in first order predicate calculus or formal meta language descriptions using Extended Bachus Naur Form. Apart from informal descriptions the semantics of formal terms is restricted to well established mathematical models. Formal derivation of theorems is restricted to predefined inference rules, which are based on well known logical reasoning (classical logic, intuitionistic logic, modal logic, temporal logic, etc.). Algorithmic model checking can serve as a substitute for theorem proving whenever the reference to well established model checkers is clear and appropriate meta theorems are given to guarantee the equivalence to an inference by proof rules.

134/139 AIS 34_3


764 In the context of the level of formality informal, semiformal and formal styles are considered to be hierarchical in nature. Thus, requirements for a informal or semiformal style of specification may also be met with either a semiformal or formal specification style provided, that is supported by informal, explanatory text where appropriate. The set of presentation elements, syntactic and semantic rules is referred in the following as notation. A formal style of presentation uses a formal notation and rules of inference which is referred to in the following as formal system.

765 The developer action element ADV_x.y.1C (where here and in the following x stands for family FSP, HLD, LLD and SPM and y stands for the component) describes the style in which the presentation of evidence shall be provided by the developer. The evaluator action element ADV_x.y.1E requires the evaluator to confirm that the information provided meets all requirements for presentation of evidence. If the ADV_x.y.1C requires a informal style the evaluator may perform the work unit e:ADV_x.y-1, where here and in the following e stands for the EAL number, in parallel with the other work units examining the content of evidence. If the ADV_x.y.1C requires a semiformal or a formal style this implies the application of semiformal or formal methods to examine the content. Therefore it is recommended to perform the work units e:ADV_x.y-1 identifying the used notations and e:ADV_x.y-2 examining their rigour before the analysis of the content of evidence. If a notation or their usage in the documentation does not provide the level of formality the necessary rigorous methods of analysis may be not applicable. The work unit e:ADV_x.y-3 examining the necessary informal explanatory text may be performed in parallel with the other work units. Of course the evaluator might detect errors in the presentation of evidence during the evaluator action as well which result in a fail verdict for the evaluator action element ADV_x.y.1E.

766 The following text provides a guidance for the examination of specification styles and their use for correspondence demonstration in the sub-activities for the assurance families ADV_FSP, ADV_HLD, ADV_LLD, ADV_SPM and ADV_RCR.

Informal style

767 An informal specification is one that is expressed in a natural language. If developer action elements ADV_x.y.1C require an informal specification the work unit e:ADV_x.y-1 will require the evaluator to determine that it contains all necessary informal explanatory text. The evaluator should examine the specification to make sure that it

nnnnnnnnnnnnnnnnnnnnnnnnnnnnnn)provides defined meanings of terms, abbreviations and acronyms that are used in a context other than that accepted by normal usage,

oooooooooooooooooooooooooooooo)if semiformal or formal notations are used appropriate informal, explanatory text shall support the understanding.

770 This enforces the informal specification to provide defined semantics of its statements. An informal specification uses the ordinary conventions for the natural language i.e. any common spoken tongue. It may use figures and semiformal elements of presentation like data flow diagrams to illustrate the informal specification. If the specification uses a semiformal notation it will be accompanied by supporting explanatory informal text appropriate for unambiguous common understanding.

771 Examples for the use of informal style are:

- The CC part 1 provides in section 2.3 a glossary of CC specific terms and describes in section 2.4 reserved terms in accordance with the ISO definitions contained in ISO/IEC Directives Part 2, Rules for the structure and drafting of International Standards. This clarifies the use of the verbs “shall”, “should”, “may” and “can” in the context of the CC.

AIS 34_3 135/139


- International standards and the Request for Interpretation (RFC) are specified in an informal style. They use semiformal notations as well e.g. the abstract syntax notation ASN.1 for specification of message formats.

772 Informal style does not excuse the absence of precision or informal definitions. The evaluator’s verdict fails if some technical term remains undefined, the evaluators lack of information prevents decision, or ambiguous interpretations cause confusion.

Semiformal style

773 A semiformal specification is expressed in a restricted syntax language with defined semantics. It reduces the ambiguity of specification and strengthens the method of analysis.

774 The evaluator should examine the identified notations to make sure that

- The syntax rules are defined or a definition is referenced.

- The notations with the explanatory text provide a defined semantics which is characterised by

a) defined meanings of terms, abbreviations and acronyms that are used in a context other than that accepted by normal usage,

b) the use of a semiformal notation is accompanied by supporting explanatory text in informal style appropriate for unambiguous meaning,

c) expression of rules and characteristics of applicable policies of the TSP, security functionality and interfaces (providing details of effects, exceptions and error messages) of TSF, their subsystems or modules to be specified for the assurance family for which the notations are used.

- The notations contain a restricted syntax language which means

d) a set of conventions must be supplied to define the restrictions imposed on the syntax.

775 Examples for the use of semiformal style are:

- The restricted syntax language may be a natural language with restricted sentence structure and keywords with special meanings. The CC part 1 (paragraph 148) and part 2 provide a semiformal notation for the security functional requirements consisting of classes, families and components together with rules for permitted operations. As required by APE_SRE.1.4C an explicitly stated IT security requirement shall use the CC requirements components, families and classes as a model for presentation.

- Formally specified languages may be used to define the data structures for the use of TSFI or an interface of subsystems or modules in semiformal style. Thus e.g. ISO/IEC 8824 and 8825 define the abstract syntax notation ASN.1 and ISO/IEC 8834 the semantic of the object identifier (OID). ASN.1 makes possible extracting the encoded information by automated tools (parser). The interface specification may describe the complete details of all effects caused by interface usage by means of other semiformal notations e.g. state-transition diagrams.

- Diagrams are commonly used for the specification of data-flow, state-transition, entity-relation-ship, data or process or program structures in a semiformal style, e.g. the Unified Modelling Language (UML) for object-oriented analysis and design includes model diagrams, their semantics and an interchange format between case tools. The graphical presentation assists the understanding of interaction and behaviour of entities depending on events. The abstraction accompanied by the graphical presentation normally needs to be compensated by informal description. Data-flow and state-transition diagrams may be very helpful, e.g. for the precise description and the analysis of protocols.

136/139 AIS 34_3


- Programming languages like ANSI C defines a strong syntax and well-defined semantics. The source code together with supporting explanatory text and documentation of well-defined development tools provides an unambiguous semiformal description of the TSF implementation, their security features and interfaces. Although having a very high level of formality programming languages may be of semiformal styles only because of missing inference rules. But some software development tools support also formal methods in software design including theorem prover.

776 These example show that semiformal style covers a wide range of capabilities and level of formality. The developer should use appropriate notation for presentation of evidence depending on the type of TOE (e.g. hardware, software), the development methodology and the purpose of the specification.

777 The semiformal style supports a structured analysis of the content, the consistency, the completeness and the correspondence of the representation. A semiformal analysis is one that results from a structured approach with a substantial degree of rigor in terms of completeness and correctness.

778 A semiformal interface specification supports the evaluator in analysing and assessing the external behaviour of a TSF, their subsystems or modules for any input (e.g. to decide about acceptance or rejection of a message and its content analysis). Semiformal evidence for conservation of properties can be obtained by means of flow charts and state transition diagrams visualizing the uniquely defined states and their interrelationship during the course of security preserving transitions. The developer may use semiformal notations like software specification languages to ensure correct refinement of the specifications from functional specification via high and low level design down to the implementation level.

779 This way the semiformal presentation clearly establishes its accuracy and superiority over informal descriptions.

Formal style

780 A formal specification is expressed within a formal system based upon well-established mathematical concepts. These mathematical concepts are used to define well-defined semantics, syntax and rules of inference. A formal system is an abstract system of identities and relations that can be described by specifying a formal alphabet, a formal language over that alphabet which is based on a formal syntax, and a set of formal rules of inference for constructing derivations of sentences in the formal language.

781 The evaluator should examine the identified formal systems to make sure that

- The semantics, syntax and inference rules of the formal system are defined or a definition is referenced.

- Each formal system with the explanatory text provides a defined semantics which

a) provides defined meanings of terms, abbreviations and acronyms that are used in a context other than that accepted by normal usage,

b) the use of a formal system and semiformal notation if any use is accompanied by supporting explanatory text in informal style appropriate for unambiguous meaning,

c) the formal system is able to express rules and characteristics of applicable policies of the TSP, security functionality and interfaces (providing details of effects, exceptions and error messages) of TSF, their subsystems or modules to be specified for the assurance family for which the notations are used.

d) the notation provides rules to determine the meaning of syntactical valid constructs.

AIS 34_3 137/139


- Each formal system uses a formal syntax that

e) provides rules to unambiguously recognise constructs.

- Each formal system provides proof rules which

f) support logical reasoning of well-established mathematical concepts,

g) help to prevent derivation of contradictions.

782 If the developer uses a formal system which is already accepted by the certification body the evaluator can rely on the level of formality and strength of the system and focus on the instantiation of the formal system to the TOE specifications and correspondence proofs.

783 The formal style supports mathematical proofs of the security properties based on the security features, the consistency of refinements and the correspondence of the representations. Formal tool support seems adequate whenever manual derivations would otherwise become long winded and incomprehensible. Formal tools are also apt to reduce the error probability inherent in manual derivations.

784 Examples of formal systems which were already successfully used for certified products:

- The Verification Support Environment (VSE) project was initiated by the German Federal Office for Security in Information Technology (BSI). The objective was to develop a tool which allows for an industrial development of software as the higher assurance levels demand the use of formal methods like VSE II (see http://www.bsi.de/aufgaben/projekte/fmethode/tools/vse.htm)

- Isabelle is a popular generic theorem proving environment. It allows mathematical formulas to be expressed in a formal language and provides tools for proving those formulas within a logical calculus. The main application is the formalisation of mathematical proofs and in particular formal verification, which includes proving the correctness of computer hardware or software and proving properties of computer languages and protocols (see e.g. http://www.cl.cam.ac.uk/Research/HVG/Isabelle/)

- The B method is a formal system based on the propositional calculus, the first order predicate calculus with inference rules and set theory (see e.g. http://vl.fmnet.info/b/). It can be used in order to specify, design and code software by a refinement process. The global correctness of the software is achieved by the verification of mathematical proofs.

3.1.1.2 Security policy models and styles

785 The assurance family Security policy modelling ADV_SPM requires in their components an increasing level of formality of the TSP model and correspondence demonstration between the TSP model and the functional specification. The following section provides some guidance how the general requirements on styles applies to the TSP models.

786 The TOE Security Policy (TSP) is a set of rules and characterisitcs that regulate how assets are managed, protected and distributed within a TOE. The TSP can be explicitly stated in the ST by the SFR (e.g. of families FDP_ACC or FDP_AFC) or be drawn from other SFR (e.g. of classes FAU, FIA or FPR) claimed in the ST. Although these TSF are provided in semiformal style the policies are normally described by rules and characteristics in informal style. A TOE security policy model is a structured representation of security policies to be enforced by the TOE.

787 According to ADV_SPM.*.2C the TSP model shall model all security policies of the TSP that can be modelled by the respective level defined by ADV_SPM.*.1C or a rationale shall be given why a lower level of formality is applied. Thus the TSP model may contain for policy sets of the TSP different models of different levels of formality as state of the art.

138/139 AIS 34_3

http://www.cl.cam.ac.uk/Research/HVG/Isabelle/


788 An informal TSP model is a description of the TSP enforced by the security functional requirements claimed in the ST. As stated in CEM paragraph 1470 all TSP in the ST can be informally modelled.

789 Modelling means to describe the rules and characteristics of the policies by the properties and features in the TSP model and to provide evidence that the features imply these properties. The strength of this evidence depends on the level of formality: an informal model may provide a rationale but a formal model shall provide a formal proof that the security features imply the security properties.

TSP

Characteristics

Properties

Modeled Policies

Rules

Features

TSP - Model

ST SFR FSP TSF TSF

ADV_SPM.*.3C

ADV_SPM.*.4C ADV_SPM.*.5,6C

ADV_SPM.*.2C

ADV_RCR.*

Form al TSP - Model

ADV_SPM.3

Semiformal TSP - Model

ADV_SPM.2

Informal TSP - Model

ADV_SPM.1 Form of

TSP

Characteristics

Properties

Modeled Policies

Principles

(Rules)

Features

TSP Model

ST SFR FSP TSF TSF

ADV_SPM.*.3C

ADV_SPM.*.4C ADV_SPM.*.5,6C

ADV_SPM.*.2C

ADV_SPM.*.1C

ADV_RCR.*

Formal TSP - Model

ADV_SPM.3

-

Semiformal TSP - Model

ADV_SPM.2

-

Informal TS P - Model

ADV_SPM.1

-

Content of Presentation

Presentation

Figure 1.3 TOE security policy models and correspondence demonstration

790 The possibility of formally modelling TSPs is dependent on the state of the art. A wide range of examples have already been given in the past for successfully modelling Access Control including Identification and Authentication. Hence inclusion of access control policies almost always requires the developer to provide the model in a formal style.

791 Whenever in doubt the evaluator should negotiate the type of style (formal, semiformal or informal) with the certification body in advance in order to agree upon the state of the art for the specific policy under question.

AIS 34_3 139/139

Documents

Evaluation Methodology for EAL5+ - Bundesamt f¼r Sicherheit in der