Criteria Common for Information Technology Security Evaluation
Part 3: Security assurance requirements August 1999 Version 2.1 CCIMB-99-033
Part 3: Security assurance requirements
Foreword
This version of the Common Criteria for Information Technology Security Evaluation (CC 2.1) is a revision that aligns it with International Standard ISO/IEC 15408:1999. In addition, the document has been formatted to facilitate its use. Security specifications written using this document, and IT products/systems shown to be compliant with such specifications, are considered to be ISO/IEC 15408:1999 compliant. CC 2.0 was issued in May, 1998. Subsequently, a Mutual Recognition Arrangement was established to use the CC as the basis of mutual recognition of evaluation results performed by the signatory organisations. ISO/IEC JTC 1 adopted CC 2.0 with minor, mostly editorial modifications in June, 1999. CC version 2.1 consists of the following parts: Part 1: Introduction and general model Part 2: Security functional requirements Part 3: Security assurance requirements
This Legal NOTICE has been placed in all Parts of the CC by request: The seven governmental organisations (collectively called "the Common Criteria Project Sponsoring Organisations") listed just below and identified fully in Part 1 Annex A, as the joint holders of the copyright in the Common Criteria for Information Technology Security Evaluations, version 2.1 Parts 1 through 3 (called "CC 2.1"), hereby grant non-exclusive license to ISO/IEC to use CC 2.1 in the continued development/maintenance of the ISO/IEC 15408 international standard. However, the Common Criteria Project Sponsoring Organisations retain the right to use, copy, distribute, translate or modify CC 2.1 as they see fit. Canada: Communications Security Establishment France: Service Central de la Scurit des Systmes d'Information Germany: Bundesamt fr Sicherheit in der Informationstechnik Netherlands: Netherlands National Communications Security Agency United Kingdom: Communications-Electronics Security Group United States: National Institute of Standards and Technology United States: National Security Agency
Page ii of vi
Version 2.1
August 1999
Part 3: Security assurance requirementsv
Contents
1 1.1 1.2 1.2.1 1.2.2 1.2.3 2 2.1 2.1.1 2.1.2 2.1.3 2.1.4 2.1.5 2.1.6 2.2 2.3 2.4 2.5 2.6 2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.6.6 2.6.7 2.7 2.8 2.8.1 3 3.1 3.2 3.2.1 3.2.2 3.2.3 3.3 3.3.1 3.3.2 3.3.3 4 4.1 4.2
Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Organisation of CC Part 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CC assurance paradigm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CC philosophy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Assurance approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The CC evaluation assurance scale . . . . . . . . . . . . . . . . . . . . . . . . . . . . Security assurance requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Class structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Assurance family structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Assurance component structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Assurance elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . EAL structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Relationship between assurances and assurance levels . . . . . . . . . . . . Component taxonomy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Protection Profile and Security Target evaluation criteria class structure . Usage of terms in Part 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Assurance categorisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Assurance class and family overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Class ACM: Configuration management . . . . . . . . . . . . . . . . . . . . . . . Class ADO: Delivery and operation . . . . . . . . . . . . . . . . . . . . . . . . . . . Class ADV: Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Class AGD: Guidance documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . Class ALC: Life cycle support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Class ATE: Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Class AVA: Vulnerability assessment . . . . . . . . . . . . . . . . . . . . . . . . . Maintenance categorisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Maintenance of assurance class and family overview . . . . . . . . . . . . . . . . Class AMA: Maintenance of assurance . . . . . . . . . . . . . . . . . . . . . . . . Protection Profile and Security Target evaluation criteria . . . . . . . . . . . . Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Protection Profile criteria overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Protection Profile evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Relation to the Security Target evaluation criteria . . . . . . . . . . . . . . . . Evaluator tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Security Target criteria overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Security Target evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Relation to the other evaluation criteria in this Part 3 . . . . . . . . . . . . . Evaluator tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1 1 1 1 2 4 5 5 5 6 8 10 10 13 13 13 14 16 16 17 17 18 19 19 20 21 21 22 22 24 24 24 24 24 25 25 25 25 26
Class APE: Protection Profile evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 TOE description (APE_DES) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Security environment (APE_ENV) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
August 1999
Version 2.1
Page iii of viii
Contents
Part 3: Security assurance requirements
4.3 4.4 4.5 4.6 5 5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8 6 6.1 6.2 6.2.1 6.2.2 6.2.3 6.2.4 6.2.5 6.2.6 6.2.7 7 8 8.1 8.2 8.3 9 9.1 9.2 10 10.1 10.2 10.3 10.4 10.5 10.6 10.7 11 11.1 11.2
PP introduction (APE_INT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Security objectives (APE_OBJ) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IT security requirements (APE_REQ) . . . . . . . . . . . . . . . . . . . . . . . . . . . . Explicitly stated IT security requirements (APE_SRE) . . . . . . . . . . . . . . . Class ASE: Security Target evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . TOE description (ASE_DES) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Security environment (ASE_ENV) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ST introduction (ASE_INT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Security objectives (ASE_OBJ) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . PP claims (ASE_PPC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IT security requirements (ASE_REQ) . . . . . . . . . . . . . . . . . . . . . . . . . . . . Explicitly stated IT security requirements (ASE_SRE) . . . . . . . . . . . . . . . TOE summary specification (ASE_TSS) . . . . . . . . . . . . . . . . . . . . . . . . . . Evaluation assurance levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Evaluation assurance level (EAL) overview . . . . . . . . . . . . . . . . . . . . . . . Evaluation assurance level details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . EAL1 - functionally tested . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . EAL2 - structurally tested . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . EAL3 - methodically tested and checked . . . . . . . . . . . . . . . . . . . . . . . EAL4 - methodically designed, tested, and reviewed . . . . . . . . . . . . . EAL5 - semiformally designed and tested . . . . . . . . . . . . . . . . . . . . . . EAL6 - semiformally verified design and tested . . . . . . . . . . . . . . . . . EAL7 - formally verified design and tested . . . . . . . . . . . . . . . . . . . . .
30 31 33 36 38 39 40 41 43 45 47 49 51 53 53 54 55 56 58 60 62 64 66
Assurance classes, families, and components . . . . . . . . . . . . . . . . . . . . . . . . 68 Class ACM: Configuration management . . . . . . . . . . . . . . . . . . . . . . . . . . . CM automation (ACM_AUT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CM capabilities (ACM_CAP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CM scope (ACM_SCP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 70 73 81
Class ADO: Delivery and operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 Delivery (ADO_DEL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 Installation, generation and start-up (ADO_IGS) . . . . . . . . . . . . . . . . . . . . 88 Class ADV: Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 Functional specification (ADV_FSP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 High-level design (ADV_HLD) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 Implementation representation (ADV_IMP) . . . . . . . . . . . . . . . . . . . . . . . 106 TSF internals (ADV_INT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 Low-level design (ADV_LLD) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 Representation correspondence (ADV_RCR) . . . . . . . . . . . . . . . . . . . . . . 119 Security policy modeling (ADV_SPM) . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 Class AGD: Guidance documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 Administrator guidance (AGD_ADM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 User guidance (AGD_USR) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Page iv of viii
Version 2.1
August 1999
Part 3: Security assurance requirements
Contents
12 12.1 12.2 12.3 12.4 13 13.1 13.2 13.3 13.4 14 14.1 14.2 14.3 14.4 15 15.1 15.2 15.2.1 15.2.2 15.2.3 15.3 15.3.1 15.3.2 15.3.3 15.3.4 16 16.1 16.2 16.3 16.4 Annex A Annex B
Class ALC: Life cycle support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 Development security (ALC_DVS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134 Flaw remediation (ALC_FLR) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 Life cycle definition(ALC_LCD) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 Tools and techniques (ALC_TAT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144 Class ATE: Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147 Coverage (ATE_COV) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149 Depth (ATE_DPT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152 Functional tests (ATE_FUN) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156 Independent testing (ATE_IND) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159 Class AVA: Vulnerability assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164 Covert channel analysis (AVA_CCA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165 Misuse (AVA_MSU) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170 Strength of TOE security functions (AVA_SOF) . . . . . . . . . . . . . . . . . . . . 175 Vulnerability analysis (AVA_VLA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177 Assurance maintenance paradigm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183 Assurance maintenance cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184 TOE acceptance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186 TOE monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 Re-evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 Assurance maintenance class and families . . . . . . . . . . . . . . . . . . . . . . . . . 188 Assurance maintenance plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188 TOE component categorisation report . . . . . . . . . . . . . . . . . . . . . . . . . 190 Evidence of assurance maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . 190 Security impact analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191 Class AMA: Maintenance of assurance . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193 Assurance maintenance plan (AMA_AMP) . . . . . . . . . . . . . . . . . . . . . . . . 194 TOE component categorisation report (AMA_CAT) . . . . . . . . . . . . . . . . . 197 Evidence of assurance maintenance (AMA_EVD) . . . . . . . . . . . . . . . . . . 199 Security impact analysis (AMA_SIA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201 Cross reference of assurance component dependencies . . . . . . . . . . . . . . . 204 Cross reference of EALs and assurance components . . . . . . . . . . . . . . . . . 207
August 1999
Version 2.1
Page v of viii
Part 3: Security assurance requirements vi
List of Figures
Figure 2.1 Figure 2.2 Figure 2.3 Figure 2.4 Figure 2.5 Figure 4.1 Figure 5.1 Figure 8.1 Figure 9.1 Figure 10.1 Figure 10.2 Figure 11.1 Figure 12.1 Figure 13.1 Figure 14.1 Figure 15.1 Figure 15.2 Figure 15.3 Figure 16.1 -
Assurance class/family/component/element hierarchy . . . . . . . . . . . . . . . . . . . 6 Assurance component structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 EAL structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Assurance and assurance level association . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Sample class decomposition diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Protection Profile evaluation class decomposition . . . . . . . . . . . . . . . . . . . . . . 27 Security Target evaluation class decomposition . . . . . . . . . . . . . . . . . . . . . . . . 38 Configuration management class decomposition . . . . . . . . . . . . . . . . . . . . . . . 69 Delivery and operation class decomposition . . . . . . . . . . . . . . . . . . . . . . . . . . 85 Development class decomposition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 Relationships between TOE representations and requirements . . . . . . . . . . . . 91 Guidance documents class decomposition . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 Life-cycle support class decomposition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 Tests class decomposition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148 Vulnerability assessment class decomposition . . . . . . . . . . . . . . . . . . . . . . . . . 164 Example assurance maintenance cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185 Example TOE acceptance approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186 Example TOE monitoring approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 Maintenance of assurance class decomposition . . . . . . . . . . . . . . . . . . . . . . . . 193
August 1999
Version 2.1
Page vi of viii
Part 3: Security assurance requirements
List of Tables
Table 2.1 Table 2.2 Table 3.1 Table 3.2 Table 3.3 Table 3.4 Table 6.1 Table 6.2 Table 6.3 Table 6.4 Table 6.5 Table 6.6 Table 6.7 Table 6.8 Table 15.1 Table A.1 Table A.2 Table B.1 -
Assurance family breakdown and mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Maintenance of assurance class decomposition . . . . . . . . . . . . . . . . . . . . . . . . 22 Protection Profile families - only CC requirements . . . . . . . . . . . . . . . . . . . . . 25 Protection Profile families - CC extended requirements . . . . . . . . . . . . . . . . . 25 Security Target families - only CC requirements . . . . . . . . . . . . . . . . . . . . . . . 26 Security Target families - CC extended requirements . . . . . . . . . . . . . . . . . . . 26 Evaluation assurance level summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 EAL1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 EAL2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 EAL3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 EAL4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 EAL5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 EAL6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 EAL7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 Maintenance of assurance family breakdown and mapping . . . . . . . . . . . . . . . 188 Assurance component dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204 AMA Internal Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206 Evaluation assurance level summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
August 1999
Version 2.1
Page vii of viii
List of Tables
Part 3: Security assurance requirements
Page viii of viii
Version 2.1
August 1999
Part 3: Security assurance requirements4
Organisation of CC Part 3
1
1
Scope
This Part 3 defines the assurance requirements of the CC. It includes the evaluation assurance levels (EALs) that define a scale for measuring assurance, the individual assurance components from which the assurance levels are composed, and the criteria for evaluation of PPs and STs.
1.1
2 3
Organisation of CC Part 3
Clause 1 is the introduction and paradigm for this CC Part 3. Clause 2 describes the presentation structure of the assurance classes, families, components, and evaluation assurance levels along with their relationships. It also characterises the assurance classes and families found in clauses 8 through 14. Clauses 3, 4 and 5 provide a brief introduction to the evaluation criteria for PPs and STs, followed by detailed explanations of the families and components that are used for those evaluations. Clause 6 provides detailed definitions of the EALs. Clause 7 provides a brief introduction to the assurance classes and is followed by clauses 8 through 14 that provide detailed definitions of those classes. Clauses 15 and 16 provide a brief introduction to the evaluation criteria for maintenance of assurance, followed by detailed definitions of those families and components. Annex A provides a summary of the dependencies between the assurance components. Annex B provides a cross reference between the EALs and the assurance components.
4
5 6
7
8
9
1.2
10
CC assurance paradigm
The purpose of this subclause is to document the philosophy that underpins the CC approach to assurance. An understanding of this subclause will permit the reader to understand the rationale behind the CC Part 3 assurance requirements. CC philosophy The CC philosophy is that the threats to security and organisational security policy commitments should be clearly articulated and the proposed security measures be demonstrably sufficient for their intended purpose.
1.2.1
11
August 1999
Version 2.1
Page 1 of 208
1 - Scope
CC assurance paradigm
12
Furthermore, measures should be adopted that reduce the likelihood of vulnerabilities, the ability to exercise (i.e. intentionally exploit or unintentionally trigger) a vulnerability, and the extent of the damage that could occur from a vulnerability being exercised. Additionally, measures should be adopted that facilitate the subsequent identification of vulnerabilities and the elimination, mitigation, and/or notification that a vulnerability has been exploited or triggered. Assurance approach The CC philosophy is to provide assurance based upon an evaluation (active investigation) of the IT product or system that is to be trusted. Evaluation has been the traditional means of providing assurance and is the basis for prior evaluation criteria documents. In aligning the existing approaches, the CC adopts the same philosophy. The CC proposes measuring the validity of the documentation and of the resulting IT product or system by expert evaluators with increasing emphasis on scope, depth, and rigour. The CC does not exclude, nor does it comment upon, the relative merits of other means of gaining assurance. Research continues with respect to alternative ways of gaining assurance. As mature alternative approaches emerge from these research activities, they will be considered for inclusion in the CC, which is so structured as to allow their future introduction. Significance of vulnerabilities It is assumed that there are threat agents that will actively seek to exploit opportunities to violate security policies both for illicit gains and for wellintentioned, but nonetheless insecure actions. Threat agents may also accidentally trigger security vulnerabilities, causing harm to the organisation. Due to the need to process sensitive information and the lack of availability of sufficiently trusted products or systems, there is significant risk due to failures of IT. It is, therefore, likely that IT security breaches could lead to significant loss. IT security breaches arise through the intentional exploitation or the unintentional triggering of vulnerabilities in the application of IT within business concerns. Steps should be taken to prevent vulnerabilities arising in IT products and systems. To the extent feasible, vulnerabilities should be: a) b) c) eliminated -- that is, active steps should be taken to expose, and remove or neutralise, all exercisable vulnerabilities; minimised -- that is, active steps should be taken to reduce, to an acceptable residual level, the potential impact of any exercise of a vulnerability; monitored -- that is, active steps should be taken to ensure that any attempt to exercise a residual vulnerability will be detected so that steps can be taken to limit the damage.
1.2.2
13
14
1.2.2.1
15
16
17
Page 2 of 208
Version 2.1
August 1999
CC assurance paradigm
1 - Scope
1.2.2.2
18
Cause of vulnerabilities Vulnerabilities can arise through failures in: a) requirements -- that is, an IT product or system may possess all the functions and features required of it and still contain vulnerabilities that render it unsuitable or ineffective with respect to security; construction -- that is, an IT product or system does not meet its specifications and/or vulnerabilities have been introduced as a result of poor constructional standards or incorrect design choices; operation -- that is, an IT product or system has been constructed correctly to a correct specification but vulnerabilities have been introduced as a result of inadequate controls upon the operation.
b)
c)
1.2.2.3
19
CC assurance Assurance is grounds for confidence that an IT product or system meets its security objectives. Assurance can be derived from reference to sources such as unsubstantiated assertions, prior relevant experience, or specific experience. However, the CC provides assurance through active investigation. Active investigation is an evaluation of the IT product or system in order to determine its security properties. Assurance through evaluation Evaluation has been the traditional means of gaining assurance, and is the basis of the CC approach. Evaluation techniques can include, but are not limited to: a) b) c) d) e) f) g) h) i) j) analysis and checking of process(es) and procedure(s); checking that process(es) and procedure(s) are being applied; analysis of the correspondence between TOE design representations; analysis of the TOE design representation against the requirements; verification of proofs; analysis of guidance documents; analysis of functional tests developed and the results provided; independent functional testing; analysis for vulnerabilities (including flaw hypothesis); penetration testing.
1.2.2.4
20
August 1999
Version 2.1
Page 3 of 208
1 - Scope
CC assurance paradigm
1.2.3
21
The CC evaluation assurance scale The CC philosophy asserts that greater assurance results from the application of greater evaluation effort, and that the goal is to apply the minimum effort required to provide the necessary level of assurance. The increasing level of effort is based upon: a) b) c) scope -- that is, the effort is greater because a larger portion of the IT product or system is included; depth -- that is, the effort is greater because it is deployed to a finer level of design and implementation detail; rigour -- that is, the effort is greater because it is applied in a more structured, formal manner.
Page 4 of 208
Version 2.1
August 1999
Part 3: Security assurance requirements 23
Structures
2
2.1
22
Security assurance requirements
Structures
The following subclauses describe the constructs used in representing the assurance classes, families, components, and EALs along with the relationships among them. Figure 2.1 illustrates the assurance requirements defined in this CC Part 3. Note that the most abstract collection of assurance requirements is referred to as a class. Each class contains assurance families, which then contain assurance components, which in turn contain assurance elements. Classes and families are used to provide a taxonomy for classifying assurance requirements, while components are used to specify assurance requirements in a PP/ST. Class structure Figure 2.1 illustrates the assurance class structure. Class name Each assurance class is assigned a unique name. The name indicates the topics covered by the assurance class. A unique short form of the assurance class name is also provided. This is the primary means for referencing the assurance class. The convention adopted is an "A" followed by two letters related to the class name. Class introduction Each assurance class has an introductory subclause that describes the composition of the class and contains supportive text covering the intent of the class. Assurance families Each assurance class contains at least one assurance family. The structure of the assurance families is described in the following subclause.
23
2.1.1
24
2.1.1.1
25
26
2.1.1.2
27
2.1.1.3
28
August 1999
Version 2.1
Page 5 of 208
2 - Security assurance requirements
Structures
Common criteria assurance requirements
Assurance class
Class name Class introduction Assurance family Family name Objectives Component levelling Application notes Assurance component
Component identification Objectives Application notes Dependencies
Assurance elements Assurance elements
Assurance element
Figure 2.1 - Assurance class/family/component/element hierarchy
2.1.2
29
Assurance family structure Figure 2.1 illustrates the assurance family structure.
Page 6 of 208
Version 2.1
August 1999
Structures
2 - Security assurance requirements
2.1.2.1
30
Family name Every assurance family is assigned a unique name. The name provides descriptive information about the topics covered by the assurance family. Each assurance family is placed within the assurance class that contains other families with the same intent. A unique short form of the assurance family name is also provided. This is the primary means used to reference the assurance family. The convention adopted is that the short form of the class name is used, followed by an underscore, and then three letters related to the family name. Objectives The objectives subclause of the assurance family presents the intent of the assurance family. This subclause describes the objectives, particularly those related to the CC assurance paradigm, that the family is intended to address. The description for the assurance family is kept at a general level. Any specific details required for objectives are incorporated in the particular assurance component. Component levelling Each assurance family contains one or more assurance components. This subclause of the assurance family describes the components available and explains the distinctions between them. Its main purpose is to differentiate between the assurance components once it has been determined that the assurance family is a necessary or useful part of the assurance requirements for a PP/ST. Assurance families containing more than one component are levelled and rationale is provided as to how the components are levelled. This rationale is in terms of scope, depth, and/or rigour. Application notes The application notes subclause of the assurance family, if present, contains additional information for the assurance family. This information should be of particular interest to users of the assurance family (e.g. PP and ST authors, designers of TOEs, evaluators). The presentation is informal and covers, for example, warnings about limitations of use and areas where specific attention may be required. Assurance components Each assurance family has at least one assurance component. The structure of the assurance components is provided in the following subclause.
31
2.1.2.2
32
33
2.1.2.3
34
35
2.1.2.4
36
2.1.2.5
37
August 1999
Version 2.1
Page 7 of 208
2 - Security assurance requirements
Structures
2.1.3
38
Assurance component structure Figure 2.2 illustrates the assurance component structure.
Assurance component
Component identification Objectives Application notes Dependencies Assurance elements
Figure 2.2 - Assurance component structure
39
The relationship between components within a family is highlighted using a bolding convention. Those parts of the requirements that are new, enhanced or modified beyond the requirements of the previous component within a hierarchy are bolded. The same bolding convention is also used for dependencies. Component identification The component identification subclause provides descriptive information necessary to identify, categorise, register, and reference a component. Every assurance component is assigned a unique name. The name provides descriptive information about the topics covered by the assurance component. Each assurance component is placed within the assurance family that shares its security objective. A unique short form of the assurance component name is also provided. This is the primary means used to reference the assurance component. The convention used is that the short form of the family name is used, followed by a period, and then a numeric character. The numeric characters for the components within each family are assigned sequentially, starting from 1. Objectives The objectives subclause of the assurance component, if present, contains specific objectives for the particular assurance component. For those assurance components
2.1.3.1
40
41
42
2.1.3.2
43
Page 8 of 208
Version 2.1
August 1999
Structures
2 - Security assurance requirements
that have this subclause, it presents the specific intent of the component and a more detailed explanation of the objectives. 2.1.3.3
44
Application notes The application notes subclause of an assurance component, if present, contains additional information to facilitate the use of the component. Dependencies Dependencies among assurance components arise when a component is not selfsufficient, and relies upon the presence of another component. Each assurance component provides a complete list of dependencies to other assurance components. Some components may list "No dependencies", to indicate that no dependencies have been identified. The components depended upon may have dependencies on other components. The dependency list identifies the minimum set of assurance components which are relied upon. Components which are hierarchical to a component in the dependency list may also be used to satisfy the dependency. In specific situations the indicated dependencies might not be applicable. The PP/ ST author, by providing rationale for why a given dependency is not applicable, may elect not to satisfy that dependency. Assurance elements A set of assurance elements is provided for each assurance component. An assurance element is a security requirement which, if further divided, would not yield a meaningful evaluation result. It is the smallest security requirement recognised in the CC. Each assurance element is identified as belonging to one of the three sets of assurance elements: a) Developer action elements: the activities that shall be performed by the developer. This set of actions is further qualified by evidential material referenced in the following set of elements. Requirements for developer actions are identified by appending the letter "D" to the element number. Content and presentation of evidence elements: the evidence required, what the evidence shall demonstrate, and what information the evidence shall convey. Requirements for content and presentation of evidence are identified by appending the letter "C" to the element number. Evaluator action elements: the activities that shall be performed by the evaluator. This set of actions explicitly includes confirmation that the requirements prescribed in the content and presentation of evidence elements have been met. It also includes explicit actions and analysis that
2.1.3.4
45
46
47
48
2.1.3.5
49
50
b)
c)
August 1999
Version 2.1
Page 9 of 208
2 - Security assurance requirements
Structures
shall be performed in addition to that already performed by the developer. Implicit evaluator actions are also to be performed as a result of developer action elements which are not covered by content and presentation of evidence requirements. Requirements for evaluator actions are identified by appending the letter "E" to the element number.
51
The developer actions and content and presentation of evidence define the assurance requirements that are used to represent a developer's responsibilities in demonstrating assurance in the TOE security functions. By meeting these requirements, the developer can increase confidence that the TOE satisfies the functional and assurance requirements of a PP or ST. The evaluator actions define the evaluator's responsibilities in the two aspects of evaluation. The first aspect is validation of the PP/ST, in accordance with the classes APE and ASE in clauses 4 and 5. The second aspect is verification of the TOE's conformance with its functional and assurance requirements. By demonstrating that the PP/ST is valid and that the requirements are met by the TOE, the evaluator can provide a basis for confidence that the TOE will meet its security objectives. The developer action elements, content and presentation of evidence elements, and explicit evaluator action elements, identify the evaluator effort that shall be expended in verifying the security claims made in the ST of the TOE. Assurance elements Each element represents a requirement to be met. These statements of requirements are intended to be clear, concise, and unambiguous. Therefore, there are no compound sentences: each separable requirement is stated as an individual element. The elements have been written using the normal dictionary meaning for the terms used, rather than using a number of predefined terms as shorthand which results in implicit requirements. Therefore, elements are written as explicit requirements, with no reserved terms. In contrast to CC Part 2, neither assignment nor selection operations are relevant for elements in CC Part 3; however, refinements may be made to Part 3 elements as required. EAL structure Figure 2.3 illustrates the EALs and associated structure defined in this Part 3. Note that while the figure shows the contents of the assurance components, it is intended that this information would be included in an EAL by reference to the actual components defined in the CC. EAL name Each EAL is assigned a unique name. The name provides descriptive information about the intent of the EAL.
52
53
2.1.4
54
55
56
2.1.5
57
2.1.5.1
58
Page 10 of 208
Version 2.1
August 1999
Structures
2 - Security assurance requirements
59
A unique short form of the EAL name is also provided. This is the primary means used to reference the EAL. Objectives The objectives subclause of the EAL presents the intent of the EAL. Application notes The application notes subclause of the EAL, if present, contains information of particular interest to users of the EAL (e.g. PP and ST authors, designers of TOEs targeting this EAL, evaluators). The presentation is informal and covers, for example, warnings about limitations of use and areas where specific attention may be required.
2.1.5.2
60
2.1.5.3
61
Part 3 Assurance levels
Evaluation assurance level EAL name Objectives Application notes Assurance component
Component identification Objectives Application notes Dependencies
Assurance elements Assurance elements
Assurance element
Figure 2.3 - EAL structure
August 1999
Version 2.1
Page 11 of 208
2 - Security assurance requirements
Structures
Part 3 Assurance requirements Assurance class
Class name Class introduction
Part 3 Assurance levels
Evaluation assurance level Assurance family EAL name Family name Objectives Objectives Application notes Component levelling Assurance component
Component identification
Application notes Assurance component
Component identification Objectives Application notes Dependencies
Objectives Application notes Dependencies
Assurance elements Assurance elements
Assurance element
Assurance elements Assurance elements
Assurance element
Figure 2.4 - Assurance and assurance level association
2.1.5.4 Assurance components
62
A set of assurance components have been chosen for each EAL.
Page 12 of 208
Version 2.1
August 1999
Component taxonomy
2 - Security assurance requirements
63
A higher level of assurance than that provided by a given EAL can be achieved by: a) b) including additional assurance components from other assurance families; or replacing an assurance component with a higher level assurance component from the same assurance family.
2.1.6
64
Relationship between assurances and assurance levels Figure 2.4 illustrates the relationship between the assurance requirements and the assurance levels defined in the CC. While assurance components further decompose into assurance elements, assurance elements cannot be individually referenced by assurance levels. Note that the arrow in the figure represents a reference from an EAL to an assurance component within the class where it is defined.
2.2
65
Component taxonomy
This Part 3 contains classes of families and components that are grouped on the basis of related assurance. At the start of each class is a diagram that indicates the families in the class and the components in each family. Class name Family 1 1 2 3
Figure 2.5 - Sample class decomposition diagram
66
In Figure 2.5, above, the class as shown contains a single family. The family contains three components that are linearly hierarchical (i.e. component 2 requires more than component 1, in terms of specific actions, specific evidence, or rigour of the actions or evidence). The assurance families in this Part 3 are all linearly hierarchical, although linearity is not a mandatory criterion for assurance families that may be added in the future.
2.3
67
Protection Profile and Security Target evaluation criteria class structure
The requirements for protection profile and security target evaluation are treated as assurance classes and are presented using the similar structure as that used for the other assurance classes, described below. One notable difference is the absence of a component levelling subclause in the associated family descriptions. The reason is that each family has only a single component and therefore no levelling has occurred.
August 1999
Version 2.1
Page 13 of 208
2 - Security assurance requirements
Usage of terms in Part 3
68
Tables 3.1, 3.2, 3.3 and 3.2 in clause 3 of this Part 3 summarise, for both the APE and ASE classes, their constituent families and abbreviations for each. Narrative summaries for the APE families can be found in CC Part 1, annex B, subclauses B.2.2 through B.2.8, whereas narrative summaries for the ASE families can be found in CC Part 1, annex C, subclauses C.2.2 through C.2.9.
2.4
69
Usage of terms in Part 3
The following is a list of terms which are used in a precise way in this Part 3. They do not merit inclusion in the glossary because they are general English terms and their usage, though restricted to the explanations given below, is in conformance with dictionary definitions. However, those explanations of the terms were used as guidance in the development of this Part 3 and should be helpful for general understanding. Check -- This term is similar to, but less rigourous than "confirm" or "verify". This term requires a quick determination to be made by the evaluator, perhaps requiring only a cursory analysis, or perhaps no analysis at all. Coherent -- An entity is logically ordered and has a discernible meaning. For documentation, this addresses both the actual text and the structure of the document, in terms of whether it is understandable by its target audience. Complete -- All necessary parts of an entity have been provided. In terms of documentation, this means that all relevant information is covered in the documentation, at such a level of detail that no further explanation is required at that level of abstraction. Confirm -- This term is used to indicate that something needs to be reviewed in detail, and that an independent determination of sufficiency needs to be made. The level of rigour required depends on the nature of the subject matter. This term is only applied to evaluator actions. Consistent -- This term describes a relationship between two or more entities, indicating that there are no apparent contradictions between these entities. Counter (verb) -- This term is typically used in the context that a security objective counters a particular threat, but does not necessarily indicate that the threat is completely eradicated as a result. Demonstrate -- This term refers to an analysis leading to a conclusion, which is less rigourous than a "proof". Describe -- This term requires that certain, specific details of an entity be provided. Determine -- This term requires an independent analysis to be made, with the objective of reaching a particular conclusion. The usage of this term differs from "confirm" or "verify", since these other terms imply that an analysis has already been performed which needs to be reviewed, whereas the usage of "determine"
70
71
72
73
74
75
76
77 78
Page 14 of 208
Version 2.1
August 1999
Usage of terms in Part 3
2 - Security assurance requirements
implies a truly independent analysis, usually in the absence of any previous analysis having been performed.
79
Ensure -- This term, used by itself, implies a strong causal relationship between an action and its consequences. This term is typically preceded by the word "helps", which indicates that the consequence is not fully certain, on the basis of that action alone. Exhaustive -- This term is used in the CC with respect to conducting an analysis or other activity. It is related to "systematic" but is considerably stronger, in that it indicates not only that a methodical approach has been taken to perform the analysis or activity according to an unambiguous plan, but that the plan that was followed is sufficient to ensure that all possible avenues have been exercised. Explain -- This term differs from both "describe" and "demonstrate". It is intended to answer the question "Why?" without actually attempting to argue that the course of action that was taken was necessarily optimal. Internally consistent -- There are no apparent contradictions between any aspects of an entity. In terms of documentation, this means that there can be no statements within the documentation that can be taken to contradict each other. Justification -- This term refers to an analysis leading to a conclusion, but is more rigorous than a demonstration. This term requires significant rigour in terms of very carefully and thoroughly explaining every step of a logical argument. Mutually supportive -- This term describes a relationship between a group of entities, indicating that the entities possess properties which do not conflict with, and may assist the other entities in performing their tasks. It is not necessary to determine that every individual entity in question directly supports other entities in that grouping; rather, it is a more general determination that is made. Prove -- This refers to a formal analysis in its mathematical sense. It is completely rigourous in all ways. Typically, "prove" is used when there is a desire to show correspondence between two TSF representations at a high level of rigour. Specify -- This term is used in the same context as "describe", but is intended to be more rigourous and precise. It is very similar to "define". Trace (verb) -- This term is used to indicate that an informal correspondence is required between two entities with only a minimal level of rigour. Verify -- This term is similar in context to "confirm", but has more rigourous connotations. This term when used in the context of evaluator actions indicates that an independent effort is required of the evaluator.
80
81
82
83
84
85
86
87
88
August 1999
Version 2.1
Page 15 of 208
2 - Security assurance requirements
Assurance categorisation
2.5
89
Assurance categorisation
The assurance classes, families, and the abbreviation for each family are shown in Table 2.1.
Table 2.1 - Assurance family breakdown and mapping
Assurance Family Abbreviated Name CM automation ACM_AUT Class ACM: Configuration CM capabilities ACM_CAP management CM scope ACM_SCP ADO_DEL Class ADO: Delivery Delivery and operation Installation, generation and start-up ADO_IGS Functional specification ADV_FSP High-level design ADV_HLD Implementation representation ADV_IMP Class ADV: TSF internals ADV_INT Development Low-level design ADV_LLD Representation correspondence ADV_RCR Security policy modeling ADV_SPM AGD_ADM Class AGD: Guidance Administrator guidance documents User guidance AGD_USR Development security ALC_DVS Flaw remediation ALC_FLR Class ALC: Life cycle support Life cycle definition ALC_LCD Tools and techniques ALC_TAT Coverage ATE_COV Depth ATE_DPT Class ATE: Tests Functional tests ATE_FUN Independent testing ATE_IND Covert channel analysis AVA_CCA Class AVA: Misuse AVA_MSU Vulnerability Strength of TOE security functions AVA_SOF assessment Vulnerability analysis AVA_VLA
Assurance Class
2.6
90
Assurance class and family overview
The following summarises the assurance classes and families of clauses 8-14. These classes and family summaries are presented in the same order as they appear in clauses 8-14.
Page 16 of 208
Version 2.1
August 1999
Assurance class and family overview
2 - Security assurance requirements
2.6.1
91
Class ACM: Configuration management Configuration management (CM) helps to ensure that the integrity of the TOE is preserved, by requiring discipline and control in the processes of refinement and modification of the TOE and other related information. CM prevents unauthorised modifications, additions, or deletions to the TOE, thus providing assurance that the TOE and documentation used for evaluation are the ones prepared for distribution. CM automation (ACM_AUT) Configuration management automation establishes the level of automation used to control the configuration items. CM capabilities (ACM_CAP) Configuration management capabilities define the characteristics of the configuration management system. CM scope (ACM_SCP) Configuration management scope indicates the TOE items that need to be controlled by the configuration management system. Class ADO: Delivery and operation Assurance class ADO defines requirements for the measures, procedures, and standards concerned with secure delivery, installation, and operational use of the TOE, ensuring that the security protection offered by the TOE is not compromised during transfer, installation, start-up, and operation. Delivery (ADO_DEL) Delivery covers the procedures used to maintain security during transfer of the TOE to the user, both on initial delivery and as part of subsequent modification. It includes special procedures or operations required to demonstrate the authenticity of the delivered TOE. Such procedures and measures are the basis for ensuring that the security protection offered by the TOE is not compromised during transfer. While compliance with the delivery requirements cannot always be determined when a TOE is evaluated, it is possible to evaluate the procedures that a developer has developed to distribute the TOE to users. Installation, generation and start-up (ADO_IGS) Installation, generation, and start-up requires that the copy of the TOE is configured and activated by the administrator to exhibit the same protection properties as the master copy of the TOE. The installation, generation, and start-up procedures provide confidence that the administrator will be aware of the TOE configuration parameters and how they can affect the TSF.
2.6.1.1
92
2.6.1.2
93
2.6.1.3
94
2.6.2
95
2.6.2.1
96
2.6.2.2
97
August 1999
Version 2.1
Page 17 of 208
2 - Security assurance requirements
Assurance class and family overview
2.6.3
98
Class ADV: Development Assurance class ADV defines requirements for the stepwise refinement of the TSF from the TOE summary specification in the ST down to the actual implementation. Each of the resulting TSF representations provide information to help the evaluator determine whether the functional requirements of the TOE have been met. Functional specification (ADV_FSP) The functional specification describes the TSF, and must be a complete and accurate instantiation of the TOE security functional requirements. The functional specification also details the external interface to the TOE. Users of the TOE are expected to interact with the TSF through this interface. High-level design (ADV_HLD) The high-level design is a top level design specification that refines the TSF functional specification into the major constituent parts of the TSF. The high level design identifies the basic structure of the TSF and the major hardware, firmware, and software elements. Implementation representation (ADV_IMP) The implementation representation is the least abstract representation of the TSF. It captures the detailed internal workings of the TSF in terms of source code, hardware drawings, etc., as applicable. TSF internals (ADV_INT) The TSF internals requirements specify the requisite internal structuring of the TSF. Low-level design (ADV_LLD) The low-level design is a detailed design specification that refines the high-level design into a level of detail that can be used as a basis for programming and/or hardware construction. Representation correspondence (ADV_RCR) The representation correspondence is a demonstration of mappings between all adjacent pairs of available TSF representations, from the TOE summary specification through to the least abstract TSF representation that is provided. Security policy modeling (ADV_SPM) Security policy models are structured representations of security policies of the TSP, and are used to provide increased assurance that the functional specification corresponds to the security policies of the TSP, and ultimately to the TOE security functional requirements. This is achieved via correspondence mappings between
2.6.3.1
99
2.6.3.2
100
2.6.3.3
101
2.6.3.4
102
2.6.3.5
103
2.6.3.6
104
2.6.3.7
105
Page 18 of 208
Version 2.1
August 1999
Assurance class and family overview
2 - Security assurance requirements
the functional specification, the security policy model, and the security policies that are modelled. 2.6.4
106
Class AGD: Guidance documents Assurance class AGD defines requirements directed at the understandability, coverage and completeness of the operational documentation provided by the developer. This documentation, which provides two categories of information, for users and for administrators, is an important factor in the secure operation of the TOE. Administrator guidance (AGD_ADM) Requirements for administrative guidance help ensure that the environmental constraints can be understood by administrators and operators of the TOE. Administrative guidance is the primary means available to the developer for providing the TOE administrators with detailed, accurate information of how to administer the TOE in a secure manner and how to make effective use of the TSF privileges and protection functions. User guidance (AGD_USR) Requirements for user guidance help ensure that users are able to operate the TOE in a secure manner (e.g. the usage constraints assumed by the PP or ST must be clearly explained and illustrated). User guidance is the primary vehicle available to the developer for providing the TOE users with the necessary background and specific information on how to correctly use the TOE's protection functions. User guidance must do two things. First, it needs to explain what the user-visible security functions do and how they are to be used, so that users are able to consistently and effectively protect their information. Second, it needs to explain the user's role in maintaining the TOE's security. Class ALC: Life cycle support Assurance class ALC defines requirements for assurance through the adoption of a well defined life-cycle model for all the steps of the TOE development, including flaw remediation procedures and policies, correct use of tools and techniques and the security measures used to protect the development environment. Development security (ALC_DVS) Development security covers the physical, procedural, personnel, and other security measures used in the development environment. It includes physical security of the development location(s) and controls on the selection and hiring of development staff. Flaw remediation (ALC_FLR) Flaw remediation ensures that flaws discovered by the TOE consumers will be tracked and corrected while the TOE is supported by the developer. While future
2.6.4.1
107
2.6.4.2
108
2.6.5
109
2.6.5.1
110
2.6.5.2
111
August 1999
Version 2.1
Page 19 of 208
2 - Security assurance requirements
Assurance class and family overview
compliance with the flaw remediation requirements cannot be determined when a TOE is evaluated, it is possible to evaluate the procedures and policies that a developer has in place to track and repair flaws, and to distribute the repairs to consumers. 2.6.5.3
112
Life cycle definition (ALC_LCD) Life cycle definition establishes that the engineering practices used by a developer to produce the TOE include the considerations and activities identified in the development process and operational support requirements. Confidence in the correspondence between the requirements and the TOE is greater when security analysis and the production of evidence are done on a regular basis as an integral part of the development process and operational support activities. It is not the intent of this component to dictate any specific development process. Tools and techniques (ALC_TAT) Tools and techniques addresses the need to define the development tools being used to analyse and implement the TOE. It includes requirements concerning the development tools and implementation dependent options of those tools. Class ATE: Tests Assurance class ATE states testing requirements that demonstrate that the TSF satisfies the TOE security functional requirements. Coverage (ATE_COV) Coverage deals with the completeness of the functional tests performed by the developer on the TOE. It addresses the extent to which the TOE security functions are tested. Depth (ATE_DPT) Depth deals with the level of detail to which the developer tests the TOE. Testing of security functions is based upon increasing depth of information derived from analysis of the TSF representations. Functional tests (ATE_FUN) Functional testing establishes that the TSF exhibits the properties necessary to satisfy the requirements of its ST. Functional testing provides assurance that the TSF satisfies at least the requirements of the chosen functional components. However, functional tests do not establish that the TSF does no more than expected. This family focuses on functional testing performed by the developer. Independent testing (ATE_IND) Independent testing specifies the degree to which the functional testing of the TOE must be performed by a party other than the developer (e.g. a third party). This
2.6.5.4
113
2.6.6
114
2.6.6.1
115
2.6.6.2
116
2.6.6.3
117
2.6.6.4
118
Page 20 of 208
Version 2.1
August 1999
Maintenance categorisation
2 - Security assurance requirements
family adds value by the introduction of tests that are not part of the developers tests. 2.6.7
119
Class AVA: Vulnerability assessment Assurance class AVA defines requirements directed at the identification of exploitable vulnerabilities. Specifically, it addresses those vulnerabilities introduced in the construction, operation, misuse, or incorrect configuration of the TOE. Covert channel analysis (AVA_CCA) Covert channel analysis is directed towards the discovery and analysis of unintended communications channels that can be exploited to violate the intended TSP. Misuse (AVA_MSU) Misuse analysis investigates whether 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. Strength of TOE security functions (AVA_SOF) Strength of function analysis addresses TOE security functions that are realised by a probabilistic or permutational mechanism (e.g. a password or hash function). Even if such functions cannot be bypassed, deactivated, or corrupted, it may still be possible to defeat them by direct attack. A level or a specific metric may be claimed for the strength of each of these functions. Strength of function analysis is performed to determine whether such functions meet or exceed the claim. For example, strength of function analysis of a password mechanism can demonstrate that the password function meets the strength claim by showing that the password space is sufficiently large. Vulnerability analysis (AVA_VLA) Vulnerability analysis consists of the identification of flaws potentially introduced in the different refinement steps of the development. It results in the definition of penetration tests through the collection of the necessary information concerning: (1) the completeness of the TSF (does the TSF counter all the postulated threats?) and (2) the dependencies between all security functions. These potential vulnerabilities are assessed through penetration testing to determine whether they could, in practice, be exploitable to compromise the security of the TOE.
2.6.7.1
120
2.6.7.2
121
2.6.7.3
122
2.6.7.4
123
2.7
124
Maintenance categorisation
The requirements for the maintenance of assurance are treated as an assurance class and are presented using the class structure defined above.
August 1999
Version 2.1
Page 21 of 208
2 - Security assurance requirements
Maintenance of assurance class and family
125
The maintenance of assurance families, and the abbreviation for each family are shown in Table 2.2.
Table 2.2 - Maintenance of assurance class decomposition
Assurance Family Abbreviated Name Assurance maintenance plan AMA_AMP TOE component categorisation AMA_CAT Maintenance of assurance report Evidence of assurance maintenance AMA_EVD Security impact analysis AMA_SIA
Assurance Class
2.8
126
Maintenance of assurance class and family overview
The following summarises the assurance class and families of clause 16. The class and family summaries are presented in the same order as they appear in clause 16. Class AMA: Maintenance of assurance Assurance class AMA is aimed at maintaining the level of assurance that the TOE will continue to meet its security target as changes are made to the TOE or its environment. Each of the families in this class identifies developer and evaluator actions that are to be applied after the TOE has been successfully evaluated, although some requirements can be applied at the time of the evaluation. Assurance maintenance plan (AMA_AMP) The assurance maintenance plan identifies the plans and procedures a developer is to implement in order to ensure that the assurance that was established in the evaluated TOE is maintained as changes are made to the TOE or its environment. TOE component categorisation report (AMA_CAT) The TOE component categorisation report provides a categorisation of the components of a TOE (e.g. TSF subsystems) according to their relevance to security. This categorisation acts as a focus for the developer's security impact analysis. Evidence of assurance maintenance (AMA_EVD) Evidence of assurance maintenance seeks to establish confidence that the assurance in the TOE is being maintained by the developer, in accordance with the assurance maintenance plan.
2.8.1
127
2.8.1.1
128
2.8.1.2
129
2.8.1.3
130
Page 22 of 208
Version 2.1
August 1999
Maintenance of assurance class and family overview
2 - Security assurance
2.8.1.4
131
Security impact analysis (AMA_SIA) Security impact analysis seeks to establish confidence that assurance has been maintained in the TOE through an analysis performed by the developer of the security impact of all changes affecting the TOE since it was evaluated.
August 1999
Version 2.1
Page 23 of 208
Part 3: Security assurance requirements 52
Overview
3
Protection Profile and Security Target evaluation criteria
Overview
This clause introduces the evaluation criteria for PPs and STs. The evaluation criteria are then fully presented in clause 4, Class APE: Protection Profile evaluation, and clause 5, Class ASE: Security Target evaluation. These criteria are the first requirements presented in this Part 3 because the PP and ST evaluation will normally be performed before the TOE evaluation. They play a special role in that information about the TOE is assessed and the functional and assurance requirements are evaluated in order to find out whether the PP or ST is a meaningful basis for a TOE evaluation. Although these evaluation criteria differ somewhat from the requirements in clauses 7 through 14, they are presented in a similar manner because the developer and evaluator activities are comparable for PP, ST and TOE evaluations. The PP and ST classes differ from the TOE classes in that all the requirements in the PP or ST class need to be considered for a PP or ST evaluation, whereas the requirements presented in the TOE classes cover a wide range of topics not all of which need be considered for a given TOE. The evaluation criteria for PPs and STs are based on the information provided in annexes B and C of CC Part 1. Useful background information for the requirements in the classes APE and ASE, as presented in the following clauses, can be found there.
3.1
132
133
134
135
136
3.2
3.2.1
137
Protection Profile criteria overview
Protection Profile evaluation The goal of a PP evaluation is to demonstrate that the PP is complete, consistent, technically sound, and hence suitable for use as a statement of requirements for one or more evaluatable TOEs. Such a PP may be eligible for inclusion within a PP registry. Relation to the Security Target evaluation criteria As described in annexes B and C of CC Part 1, there are many similarities in structure and content between the generic PP and the TOE-specific ST. Consequently, the criteria for evaluating PPs contain requirements that are similar to many of those for STs, and the criteria for both are presented in a similar manner.
3.2.2
138
August 1999
Version 2.1
Page 24 of 208
Security Target criteria overview
3 - Protection Profile and Security Target evaluation criteria
3.2.3 3.2.3.1
139
Evaluator tasks Evaluator tasks for an evaluation based on CC requirements only Evaluators performing a PP evaluation that does not include requirements from outside the standard shall apply the requirements of the APE class as described in Table 3.1.
Table 3.1 - Protection Profile families - only CC requirements
Family Protection Profile, TOE description Class APE: Protection Profile, Security environment Protection Protection Profile, PP introduction Profile evaluation Protection Profile, Security objectives Protection Profile, IT security requirements 3.2.3.2
140
Class
Abbreviated Name APE_DES APE_ENV APE_INT APE_OBJ APE_REQ
Evaluator tasks for a CC extended evaluation Evaluators performing a PP evaluation that includes requirements from outside the standard shall apply the requirements of the APE class as described in Table 3.2.
Table 3.2 - Protection Profile families - CC extended requirements
Family Protection Profile, TOE description Protection Profile, Security environment Class APE: Protection Profile, PP introduction Protection Profile Protection Profile, Security objectives evaluation Protection Profile, TOE description Protection Profile, Explicitly stated IT security requirements
Class
Abbreviated Name APE_DES APE_ENV APE_INT APE_OBJ APE_DES APE_SRE
3.3
3.3.1
141
Security Target criteria overview
Security Target evaluation The goal of an ST evaluation is to demonstrate that the ST is complete, consistent, technically sound, and hence suitable for use as the basis for the corresponding TOE evaluation. Relation to the other evaluation criteria in this Part 3 There are two identified stages for the evaluation of a TOE; the ST evaluation and the corresponding TOE evaluation. The requirements for ST evaluations are
3.3.2
142
August 1999
Version 2.1
Page 25 of 208
3 - Protection Profile and Security Target evaluation criteria
Security Target criteria overview
discussed here and in clause 6 while the requirements for TOE evaluations are contained in clauses 7 through 14.
143
An ST evaluation includes a PP claims evaluation. If the ST does not claim PP conformance, the PP claims part of the ST shall contain a statement that the TOE does not claim conformance to any PP. Evaluator tasks Evaluator tasks for an evaluation based on CC requirements only Evaluators performing an ST evaluation that does not include requirements from outside the standard shall apply the requirements of the ASE class as described in Table 3.3.
Table 3.3 - Security Target families - only CC requirements
3.3.3 3.3.3.1
144
Family Abbreviated Name Security Target, TOE description ASE_DES Security Target, Security environment ASE_ENV Class ASE: Security Target, ST introduction ASE_INT Security Security Target, Security objectives ASE_OBJ Target ASE_PPC evaluation Security Target, PP claims Security Target, IT security requirements ASE_REQ Security Target, TOE summary specification ASE_TSS 3.3.3.2
145
Class
Evaluator tasks for a CC extended evaluation Evaluators performing an ST evaluation that includes requirements from outside the standard shall apply the requirements of the ASE class as described in Table 3.4.
Table 3.4 - Security Target families - CC extended requirements
Class
Class ASE: Security Target evaluation
Family Abbreviated Name Security Target, TOE description ASE_DES Security Target, Security environment ASE_ENV Security Target, ST introduction ASE_INT Security Target, Security objectives ASE_OBJ Security Target, PP claims ASE_PPC Security Target, IT security requirements ASE_REQ Security Target, Explicitly stated IT ASE_SRE security requirements Security Target, TOE summary specification ASE_TSS
Page 26 of 208
Version 2.1
August 1999
Security Target criteria overview
4 - Class APE: Protection Profile evaluation
4
146
Class APE: Protection Profile evaluation
The goal of a PP evaluation is to demonstrate that the PP is complete, consistent and technically sound. An evaluated PP is suitable for use as the basis for the development of STs. Such a PP is eligible for inclusion in a registry. Figure 4.1 shows the families within this class.
147
Class APE: Protection Profile evaluation APE_DES: Protection Profile, TOE description APE_ENV: Protection Profile, Security environment APE_INT: Protection Profile, PP introduction APE_OBJ: Protection Profile, Security objectives APE_REQ: Protection Profile, IT security requirements APE_SRE: Protection Profile, Explicitly stated IT security requirements 1 1 1 1 1
1
Figure 4.1 - Protection Profile evaluation class decomposition
August 1999
Version 2.1
Page 27 of 208
4 - Class APE: Protection Profile evaluation
TOE description (APE_DES)
4.1
APE_DES
TOE description (APE_DES)
Protection Profile, TOE description
Objectives
148
The TOE description is an aid to the understanding of the TOE's security requirements. Evaluation of the TOE description is required to show that it is coherent, internally consistent and consistent with all other parts of the PP.
APE_DES.1 Protection Profile, TOE description, Evaluation requirements Dependencies: APE_ENV.1 Protection Profile, Security environment, Evaluation requirements APE_INT.1 Protection Profile, PP introduction, Evaluation requirements APE_OBJ.1 Protection Profile, Security objectives, Evaluation requirements APE_REQ.1 Protection Profile, IT security requirements, Evaluation requirements Developer action elements:
APE_DES.1.1D
The PP developer shall provide a TOE description as part of the PP. Content and presentation of evidence elements:
APE_DES.1.1C
The TOE description shall as a minimum describe the product type and the general IT features of the TOE. Evaluator action elements:
APE_DES.1.1E
The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall confirm that the TOE description is coherent and internally consistent. The evaluator shall confirm that the TOE description is consistent with the other parts of the PP.
APE_DES.1.2E
APE_DES.1.3E
Page 28 of 208
Version 2.1
August 1999
Security environment (APE_ENV)
4 - Class APE: Protection Profile evaluation
4.2
APE_ENV
Security environment (APE_ENV)
Protection Profile, Security environment
Objectives
149
In order to determine whether the IT security requirements in the PP are sufficient, it is important that the security problem to be solved is clearly understood by all parties to the evaluation.
APE_ENV.1 Protection Profile, Security environment, Evaluation requirements Dependencies: No dependencies. Developer action elements:
APE_ENV.1.1D
The PP developer shall provide a statement of TOE security environment as part of the PP. Content and presentation of evidence elements:
APE_ENV.1.1C
The statement of TOE security environment shall identify and explain any assumptions about the intended usage of the TOE and the environment of use of the TOE. The statement of TOE security environment shall identify and explain any known or presumed threats to the assets against which protection will be required, either by the TOE or by its environment. The statement of TOE security environment shall identify and explain any organisational security policies with which the TOE must comply. Evaluator action elements:
APE_ENV.1.2C
APE_ENV.1.3C
APE_ENV.1.1E
The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall confirm that the statement of TOE security environment is coherent and internally consistent.
APE_ENV.1.2E
August 1999
Version 2.1
Page 29 of 208
4 - Class APE: Protection Profile evaluation
PP introduction (APE_INT)
4.3
APE_INT
PP introduction (APE_INT)
Protection Profile, PP introduction
Objectives
150
The PP introduction contains document management and overview information necessary to operate a PP registry. Evaluation of the PP introduction is required to demonstrate that the PP is correctly identified and that it is consistent with all other parts of the PP.
APE_INT.1 Protection Profile, PP introduction, Evaluation requirements Dependencies: APE_DES.1 Protection Profile, TOE description, Evaluation requirements APE_ENV.1 Protection Profile, Security environment, Evaluation requirements APE_OBJ.1 Protection Profile, Security objectives, Evaluation requirements APE_REQ.1 Protection Profile, IT security requirements, Evaluation requirements Developer action elements:
APE_INT.1.1D
The PP developer shall provide a PP introduction as part of the PP. Content and presentation of evidence elements:
APE_INT.1.1C
The PP introduction shall contain a PP identification that provides the labelling and descriptive information necessary to identify, catalogue, register, and cross reference the PP. The PP introduction shall contain a PP overview which summarises the PP in narrative form. Evaluator action elements:
APE_INT.1.2C
APE_INT.1.1E
The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall confirm that the PP introduction is coherent and internally consistent. The evaluator shall confirm that the PP introduction is consistent with the other parts of the PP.
APE_INT.1.2E
APE_INT.1.3E
Page 30 of 208
Version 2.1
August 1999
Security objectives (APE_OBJ)
4 - Class APE: Protection Profile evaluation
4.4
APE_OBJ
Security objectives (APE_OBJ)
Protection Profile, Security objectives
Objectives
151
The security objectives is a concise statement of the intended response to the security problem. Evaluation of the security objectives is required to demonstrate that the stated objectives adequately address the security problem. The security objectives are categorised as security objectives for the TOE and as security objectives for the environment. The security objectives for both the TOE and the environment must be shown to be traced back to the identified threats to be countered and/or policies and assumptions to be met by each.
APE_OBJ.1 Protection Profile, Security objectives, Evaluation requirements Dependencies: APE_ENV.1 Protection Profile, Security environment, Evaluation requirements Developer action elements:
APE_OBJ.1.1D
The PP developer shall provide a statement of security objectives as part of the PP. The PP developer shall provide the security objectives rationale. Content and presentation of evidence elements:
APE_OBJ.1.2D
APE_OBJ.1.1C
The statement of security objectives shall define the security objectives for the TOE and its environment. The security objectives for the TOE shall be clearly stated and traced back to aspects of the identified threats to be countered by the TOE and/or organisational security policies to be met by the TOE. The security objectives for the environment shall be clearly stated and traced back to aspects of identified threats not completely countered by the TOE and/or organisational security policies or assumptions not completely met by the TOE. The security objectives rationale shall demonstrate that the stated security objectives are suitable to counter the identified threats to security. The security objectives rationale shall demonstrate that the stated security objectives are suitable to cover all of the identified organisational security policies and assumptions.
APE_OBJ.1.2C
APE_OBJ.1.3C
APE_OBJ.1.4C
APE_OBJ.1.5C
August 1999
Version 2.1
Page 31 of 208
4 - Class APE: Protection Profile evaluation
Security objectives (APE_OBJ)
Evaluator action elements:
APE_OBJ.1.1E
The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall confirm that the statement of security objectives is complete, coherent, and internally consistent.
APE_OBJ.1.2E
Page 32 of 208
Version 2.1
August 1999
IT security requirements (APE_REQ)
4 - Class APE: Protection Profile evaluation
4.5
APE_REQ
IT security requirements (APE_REQ)
Protection Profile, IT security requirements
Objectives
152
The IT security requirements chosen for a TOE and presented or cited in a PP need to be evaluated in order to confirm that they are internally consistent and lead to the development of a TOE that will meet its security objectives. Not all of the security objectives expressed in a PP may be met by a compliant TOE, as some TOEs may depend on certain IT security requirements to be met by the IT environment. When this is the case, the environmental IT security requirements must be clearly stated and evaluated in context with the TOE requirements. This family presents evaluation requirements that permit the evaluator to determine that a PP is suitable for use as a statement of requirements for an evaluatable TOE. The additional criteria necessary for the evaluation of explicitly stated requirements is covered in the APE_SRE family. Application notes
153
154
155
The term "IT security requirements" refers to "TOE security requirements" and the optionally included "security requirements for the IT environment". The term "TOE security requirements" refers to "TOE security functional requirements" and/or "TOE security assurance requirements". In the APE_REQ.1 component, the word "appropriate" is used to indicate that certain elements allow options in certain cases. Which options are applicable depends on the given context in the PP. Detailed information for all these aspects is contained in CC Part 1, annex B.
156
157
APE_REQ.1 Protection Profile, IT security requirements, Evaluation requirements Dependencies: APE_OBJ.1 Protection requirements Developer action elements:
APE_REQ.1.1D
Profile,
Security
objectives,
Evaluation
The PP developer shall provide a statement of IT security requirements as part of the PP. The PP developer shall provide the security requirements rationale. Content and presentation of evidence elements:
APE_REQ.1.2D
APE_REQ.1.1C
The statement of TOE security functional requirements shall identify the TOE security functional requirements drawn from CC Part 2 functional requirements components.
August 1999
Version 2.1
Page 33 of 208
4 - Class APE: Protection Profile evaluation
IT security requirements (APE_REQ)
APE_REQ.1.2C
The statement of TOE security assurance requirements shall identify the TOE security assurance requirements drawn from CC Part 3 assurance requirements components. The statement of TOE security assurance requirements should include an Evaluation Assurance Level (EAL) as defined in CC Part 3. The evidence shall justify that the statement of TOE security assurance requirements is appropriate. The PP shall, if appropriate, identify any security requirements for the IT environment. All completed operations on IT security requirements included in the PP shall be identified. Any uncompleted operations on IT security requirements included in the PP shall be identified. Dependencies among the IT security requirements included in the PP should be satisfied. The evidence shall justify why any non-satisfaction of dependencies is appropriate. The PP shall include a statement of the minimum strength of function level for the TOE security functional requirements, either SOF-basic, SOFmedium or SOF-high, as appropriate. The PP shall identify any specific TOE security functional requirements for which an explicit strength of function is appropriate, together with the specific metric. The security requirements rationale shall demonstrate that the minimum strength of function level for the PP, together with any explicit strength of function claim, is consistent with the security objectives for the TOE. The security requirements rationale shall demonstrate that the IT security requirements are suitable to meet the security objectives. The security requirements rationale shall demonstrate that the set of IT security requirements together forms a mutually supportive and internally consistent whole.
APE_REQ.1.3C
APE_REQ.1.4C
APE_REQ.1.5C
APE_REQ.1.6C
APE_REQ.1.7C
APE_REQ.1.8C
APE_REQ.1.9C
APE_REQ.1.10C
APE_REQ.1.11C
APE_REQ.1.12C
APE_REQ.1.13C
APE_REQ.1.14C
Evaluator action elements:
APE_REQ.1.1E
The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
Page 34 of 208
Version 2.1
August 1999
IT security requirements (APE_REQ)
4 - Class APE: Protection Profile evaluation
APE_REQ.1.2E
The evaluator shall confirm that the statement of IT security requirements is complete, coherent, and internally consistent.
August 1999
Version 2.1
Page 35 of 208
4 - Class APE: Protection Profile evaluation
Explicitly stated IT security requirements (APE_SRE)
4.6
APE_SRE
Explicitly stated IT security requirements (APE_SRE)
Protection Profile, Explicitly stated IT security requirements
Objectives
158
If, after careful consideration, none of the requirements components in CC Part 2 or CC Part 3 are readily applicable to all or parts of the IT security requirements, the PP author may state other requirements which do not reference the CC. The use of such requirements shall be justified. This family presents evaluation requirements that permit the evaluator to determine that the explicitly stated requirements are clearly and unambiguously expressed. The evaluation of requirements taken from the CC in conjunction with valid explicitly stated security requirements is addressed by the APE_REQ family. Explicitly stated IT security requirements for a TOE presented or cited in a PP need to be evaluated in order to demonstrate that they are clearly and unambiguously expressed. Application notes
159
160
161
Formulation of the explicitly stated requirements in a structure comparable to those of existing CC components and elements involves choosing similar labelling, manner of expression, and level of detail. Using the CC requirements as a model means that the requirements can be clearly identified, that they are self-contained, and that the application of each requirement is feasible and will yield a meaningful evaluation result based on a compliance statement of the TOE for that particular requirement. The term "IT security requirements" refers to "TOE security requirements" and the optionally included "security requirements for the IT environment". The term "TOE security requirements" refers to "TOE security functional requirements" and/or "TOE security assurance requirements".
162
163
164
APE_SRE.1 Protection Profile, Explicitly stated IT security requirements, Evaluation requirements Dependencies: APE_REQ.1 Protection Profile, IT security requirements, Evaluation requirements Developer action elements:
APE_SRE.1.1D
The PP developer shall provide a statement of IT security requirements as part of the PP. The PP developer shall provide the security requirements rationale.
APE_SRE.1.2D
Page 36 of 208
Version 2.1
August 1999
Explicitly stated IT security requirements (APE_SRE)
4 - Class APE: Protection Profile evaluation
Content and presentation of evidence elements:
APE_SRE.1.1C
All TOE security requirements that are explicitly stated without reference to the CC shall be identified. All security requirements for the IT environment that are explicitly stated without reference to the CC shall be identified. The evidence shall justify why the security requirements had to be explicitly stated. The explicitly stated IT security requirements shall use the CC requirements components, families and classes as a model for presentation. The explicitly stated IT security requirements shall be measurable and state objective evaluation requirements such that compliance or noncompliance of a TOE can be determined and systematically demonstrated. The explicitly stated IT security \requirements shall be clearly and unambiguously expressed. The security requirements rationale shall demonstrate that the assurance requirements are applicable and appropriate to support any explicitly stated TOE security functional requirements. Evaluator action elements:
APE_SRE.1.2C
APE_SRE.1.3C
APE_SRE.1.4C
APE_SRE.1.5C
APE_SRE.1.6C
APE_SRE.1.7C
APE_SRE.1.1E
The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall determine that all of the dependencies of the explicitly stated IT security requirements have been identified.
APE_SRE.1.2E
August 1999
Version 2.1
Page 37 of 208
5 - Class ASE: Security Target evaluation
Explicitly stated IT security requirements (APE_SRE)
5
165
Class ASE: Security Target evaluation
The goal of an ST evaluation is to demonstrate that the ST is complete, consistent, technically sound, and hence suitable for use as the basis for the corresponding TOE evaluation. Figure 5.1 shows the families within this class.
166
Class ASE: Security Target evaluation APE_DES: Protection Profile, TOE description ASE_ENV: Security Target, Security environment ASE_INT: Security Target, ST introduction ASE_OBJ: Security Target, Security objectives ASE_PPC: Security Target, PP claims ASE_REQ: Security Target, IT security requirements ASE_SRE: Security Target, Explicitly stated IT security requirements ASE_TSS: Security Target, TOE summary specification 1 1 1 1 1 1
1
1
Figure 5.1 - Security Target evaluation class decomposition
Page 38 of 208
Version 2.1
August 1999
TOE description (ASE_DES)
5 - Class ASE: Security Target evaluation
5.1
ASE_DES
TOE description (ASE_DES)
Security Target, TOE description
Objectives
167
The TOE description is an aid to the understanding of the TOE's security requirements. Evaluation of the TOE description is required to show that it is coherent, internally consistent and consistent with all other parts of the ST.
ASE_DES.1 Security Target, TOE description, Evaluation requirements Dependencies: ASE_ENV.1 Security Target, Security environment, Evaluation requirements ASE_INT.1 Security Target, ST introduction, Evaluation requirements ASE_OBJ.1 Security Target, Security objectives, Evaluation requirements ASE_PPC.1 Security Target, PP claims, Evaluation requirements ASE_REQ.1 Security Target, IT security requirements, Evaluation requirements ASE_TSS.1 Security Target, TOE summary specification, Evaluation requirements Developer action elements:
ASE_DES.1.1D
The developer shall provide a TOE description as part of the ST. Content and presentation of evidence elements:
ASE_DES.1.1C
The TOE description shall as a minimum describe the product or system type, and the scope and boundaries of the TOE in general terms both in a physical and a logical way. Evaluator action elements:
ASE_DES.1.1E
The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall confirm that the TOE description is coherent and internally consistent. The evaluator shall confirm that the TOE description is consistent with the other parts of the ST.
ASE_DES.1.2E
ASE_DES.1.3E
August 1999
Version 2.1
Page 39 of 208
5 - Class ASE: Security Target evaluation
Security environment (ASE_ENV)
5.2
ASE_ENV
Security environment (ASE_ENV)
Security Target, Security environment
Objectives
168
In order to determine whether the IT security requirements in the ST are sufficient, it is important that the security problem to be solved is clearly understood by all parties to the evaluation.
ASE_ENV.1 Security Target, Security environment, Evaluation requirements Dependencies: No dependencies. Developer action elements:
ASE_ENV.1.1D
The developer shall provide a statement of TOE security environment as part of the ST. Content and presentation of evidence elements:
ASE_ENV.1.1C
The statement of TOE security environment shall identify and explain any assumptions about the intended usage of the TOE and the environment of use of the TOE. The statement of TOE security environment shall identify and explain any known or presumed threats to the assets against which protection will be required, either by the TOE or by its environment. The statement of TOE security environment shall identify and explain any organisational security policies with which the TOE must comply. Evaluator action elements:
ASE_ENV.1.2C
ASE_ENV.1.3C
ASE_ENV.1.1E
The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall confirm that the statement of TOE security environment is coherent and internally consistent.
ASE_ENV.1.2E
Page 40 of 208
Version 2.1
August 1999
ST introduction (ASE_INT)
5 - Class ASE: Security Target evaluation
5.3
ASE_INT
ST introduction (ASE_INT)
Security Target, ST introduction
Objectives
169
The ST introduction contains identification and indexing material. Evaluation of the ST introduction is required to demonstrate that the ST is correctly identified and that it is consistent with all other parts of the ST. Security Target, ST introduction, Evaluation requirements Dependencies: ASE_DES.1 Security Target, TOE description, Evaluation requirements ASE_ENV.1 Security Target, Security environment, Evaluation requirements ASE_OBJ.1 Security Target, Security objectives, Evaluation requirements ASE_PPC.1 Security Target, PP claims, Evaluation requirements ASE_REQ.1 Security Target, IT security requirements, Evaluation requirements ASE_TSS.1 Security Target, TOE summary specification, Evaluation requirements Developer action elements:
ASE_INT.1
ASE_INT.1.1D
The developer shall provide an ST introduction as part of the ST. Content and presentation of evidence elements:
ASE_INT.1.1C
The ST introduction shall contain an ST identification that provides the labelling and descriptive information necessary to control and identify the ST and the TOE to which it refers. The ST introduction shall contain an ST overview which summarises the ST in narrative form. The ST introduction shall contain a CC conformance claim that states any evaluatable claim of CC conformance for the TOE. Evaluator action elements:
ASE_INT.1.2C
ASE_INT.1.3C
ASE_INT.1.1E
The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall confirm that the ST introduction is coherent and internally consistent.
ASE_INT.1.2E
August 1999
Version 2.1
Page 41 of 208
5 - Class ASE: Security Target evaluation
ST introduction (ASE_INT)
ASE_INT.1.3E
The evaluator shall confirm that the ST introduction is consistent with the other parts of the ST.
Page 42 of 208
Version 2.1
August 1999
Security objectives (ASE_OBJ)
5 - Class ASE: Security Target evaluation
5.4
ASE_OBJ
Security objectives (ASE_OBJ)
Security Target, Security objectives
Objectives
170
The security objectives are a concise statement of the intended response to the security problem. Evaluation of the security objectives is required to demonstrate that the stated objectives adequately address the security problem. The security objectives are categorised as security objectives for the TOE and as security objectives for the environment. The security objectives for both the TOE and the environment must be shown to be traced back to the identified threats to be countered and/or policies and assumptions to be met by each.
ASE_OBJ.1 Security Target, Security objectives, Evaluation requirements Dependencies: ASE_ENV.1 Security Target, Security environment, Evaluation requirements Developer action elements:
ASE_OBJ.1.1D
The developer shall provide a statement of security objectives as part of the ST. The developer shall provide the security objectives rationale. Content and presentation of evidence elements:
ASE_OBJ.1.2D
ASE_OBJ.1.1C
The statement of security objectives shall define the security objectives for the TOE and its environment. The security objectives for the TOE shall be clearly stated and traced back to aspects of the identified threats to be countered by the TOE and/or organisational security policies to be met by the TOE. The security objectives for the environment shall be clearly stated and traced back to aspects of identified threats not completely countered by the TOE and/or organisational security policies or assumptions not completely met by the TOE. The security objectives rationale shall demonstrate that the stated security objectives are suitable to counter the identified threats to security. The security objectives rationale shall demonstrate that the stated security objectives are suitable to cover all of the identified organisational security policies and assumptions.
ASE_OBJ.1.2C
ASE_OBJ.1.3C
ASE_OBJ.1.4C
ASE_OBJ.1.5C
August 1999
Version 2.1
Page 43 of 208
5 - Class ASE: Security Target evaluation
Security objectives (ASE_OBJ)
Evaluator action elements:
ASE_OBJ.1.1E
The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall confirm that the statement of security objectives is complete, coherent, and internally consistent.
ASE_OBJ.1.2E
Page 44 of 208
Version 2.1
August 1999
PP claims (ASE_PPC)
5 - Class ASE: Security Target evaluation
5.5
ASE_PPC
PP claims (ASE_PPC)
Security Target, PP claims
Objectives
171
The goal of the evaluation of the Security Target PP claims is to determine whether the ST is a correct instantiation of the PP. Application notes
172
The family applies only in the case of a PP claim. In all other cases, no developer action and no evaluator action is necessary. Although additional evaluation activity is necessary when a PP claim is made, the ST evaluation effort is generally smaller than in cases where no PP is used because it is possible to reuse the PP evaluation results for the ST evaluation.
173
ASE_PPC.1 Security Target, PP claims, Evaluation requirements Dependencies: ASE_OBJ.1 Security requirements Target, Security objectives, Evaluation
ASE_REQ.1 Security Target, IT security requirements, Evaluation requirements Developer action elements:
ASE_PPC.1.1D ASE_PPC.1.2D
The developer shall provide any PP claims as part of the ST. The developer shall provide the PP claims rationale for each provided PP claim. Content and presentation of evidence elements:
ASE_PPC.1.1C
Each PP claim shall identify the PP for which compliance is being claimed, including qualifications needed for that claim. Each PP claim shall identify the IT security requirements statements that satisfy the permitted operations of the PP or otherwise further qualify the PP requirements. Each PP claim shall identify security objectives and IT security requirements statements contained in the ST that are in addition to those contained in the PP. Evaluator action elements:
ASE_PPC.1.2C
ASE_PPC.1.3C
ASE_PPC.1.1E
The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
August 1999
Version 2.1
Page 45 of 208
5 - Class ASE: Security Target evaluation
PP claims (ASE_PPC)
ASE_PPC.1.2E
The evaluator shall confirm that the PP claims are a correct instantiation of the PP.
Page 46 of 208
Version 2.1
August 1999
IT security requirements (ASE_REQ)
5 - Class ASE: Security Target evaluation
5.6
ASE_REQ
IT security requirements (ASE_REQ)
Security Target, IT security requirements
Objectives
174
The IT security requirements chosen for a TOE and presented or cited in an ST need to be evaluated in order to confirm that they are internally consistent and lead to the development of a TOE that will meet its security objectives. This family presents evaluation requirements that permit the evaluator to determine that an ST is suitable for use as a statement of requirements for the corresponding TOE. The additional criteria necessary for the evaluation of explicitly stated requirements is covered in the ASE_SRE family. Application notes
175
176
The term "IT security requirements" refers to "TOE security requirements" and the optionally included "security requirements for the IT environment". The term "TOE security requirements" refers to "TOE security functional requirements" and/or "TOE security assurance requirements". In the ASE_REQ.1 component, the word "appropriate" is used to indicate that certain elements allow options in certain cases. Which options are applicable depends on the given context in the ST. Detailed information for all these aspects is contained in CC Part 1, annex C.
177
178
ASE_REQ.1 Security Target, IT security requirements, Evaluation requirements Dependencies: ASE_OBJ.1 Security requirements Developer action elements:
ASE_REQ.1.1D
Target,
Security
objectives,
Evaluation
The developer shall provide a statement of IT security requirements as part of the ST. The developer shall provide the security requirements rationale. Content and presentation of evidence elements:
ASE_REQ.1.2D
ASE_REQ.1.1C
The statement of TOE security functional requirements shall identify the TOE security functional requirements drawn from CC Part 2 functional requirements components. The statement of TOE security assurance requirements shall identify the TOE security assurance requirements drawn from CC Part 3 assurance requirements components.
ASE_REQ.1.2C
August 1999
Version 2.1
Page 47 of 208
5 - Class ASE: Security Target evaluation
IT security requirements (ASE_REQ)
ASE_REQ.1.3C
The statement of TOE security assurance requirements should include an Evaluation Assurance Level (EAL) as defined in CC Part 3. The evidence shall justify that the statement of TOE security assurance requirements is appropriate. The ST shall, if appropriate, identify any security requirements for the IT environment. Operations on IT security requirements included in the ST shall be identified and performed. Dependencies among the IT security requirements included in the ST should be satisfied. The evidence shall justify why any non-satisfaction of dependencies is appropriate. The ST shall include a statement of the minimum strength of function level for the TOE security functional requirements, either SOF-basic, SOFmedium or SOF-high, as appropriate. The ST shall identify any specific TOE security functional requirements for which an explicit strength of function is appropriate, together with the specific metric. The security requirements rationale shall demonstrate that the minimum strength of function level for the ST together with any explicit strength of function claim is consistent with the security objectives for the TOE. The security requirements rationale shall demonstrate that the IT security requirements are suitable to meet the security objectives. The security requirements rationale shall demonstrate that the set of IT security requirements together forms a mutually supportive and internally consistent whole.
ASE_REQ.1.4C
ASE_REQ.1.5C
ASE_REQ.1.6C
ASE_REQ.1.7C
ASE_REQ.1.8C
ASE_REQ.1.9C
ASE_REQ.1.10C
ASE_REQ.1.11C
ASE_REQ.1.12C
ASE_REQ.1.13C
Evaluator action elements:
ASE_REQ.1.1E
The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall confirm that the statement of IT security requirements is complete, coherent, and internally consistent.
ASE_REQ.1.2E
Page 48 of 208
Version 2.1
August 1999
Explicitly stated IT security requirements (ASE_SRE)
5 - Class ASE: Security Target evaluation
5.7
ASE_SRE
Explicitly stated IT security requirements (ASE_SRE)
Security Target, Explicitly stated IT security requirements
Objectives
179
If, after careful consideration, none of the requirements components in CC Part 2 or CC Part 3 are readily applicable to all or parts of the IT security requirements, the ST author may state other requirements which do not reference the CC. The use of such requirements shall be justified. This family presents evaluation requirements that permit the evaluator to determine that the explicitly stated requirements are clearly and unambiguously expressed. The evaluation of requirements taken from the CC in conjunction with valid explicitly stated security requirements is addressed by the ASE_REQ family. Explicitly stated IT security requirements for a TOE presented or cited in an ST need to be evaluated in order to demonstrate that they are clearly and unambiguously expressed. Application notes
180
181
182
Formulation of the explicitly stated requirements in a structure comparable to those of existing CC components and elements involves choosing similar labelling, manner of expression, and level of detail. Using the CC requirements as a model means that the requirements can be clearly identified, that they are self-contained, and that the application of each requirement is feasible and will yield a meaningful evaluation result based on a compliance statement of the TOE for that particular requirement. The term "IT security requirements" refers to "TOE security requirements" and the optionally included "security requirements for the IT environment". The term "TOE security requirements" refers to "TOE security functional requirements" and/or "TOE security assurance requirements".
183
184
185
ASE_SRE.1 Security Target, Explicitly stated IT security requirements, Evaluation requirements Dependencies: ASE_REQ.1 Security Target, IT security requirements, Evaluation requirements Developer action elements:
ASE_SRE.1.1D
The developer shall provide a statement of IT security requirements as part of the ST. The developer shall provide the security requirements rationale.
ASE_SRE.1.2D
August 1999
Version 2.1
Page 49 of 208
5 - Class ASE: Security Target evaluation
Explicitly stated IT security requirements (ASE_SRE)
Content and presentation of evidence elements:
ASE_SRE.1.1C
All TOE security requirements that are explicitly stated without reference to the CC shall be identified. All security requirements for the IT environment that are explicitly stated without reference to the CC shall be identified. The evidence shall justify why the security requirements had to be explicitly stated. The explicitly stated IT security requirements shall use the CC requirements components, families and classes as a model for presentation. The explicitly stated IT security requirements shall be measurable and state objective evaluation requirements such that compliance or noncompliance of a TOE can be determined and systematically demonstrated. The explicitly stated IT security requirements shall be clearly and unambiguously expressed. The security requirements rationale shall demonstrate that the assurance requirements are applicable and appropriate to support any explicitly stated TOE security functional requirements. Evaluator action elements:
ASE_SRE.1.2C
ASE_SRE.1.3C
ASE_SRE.1.4C
ASE_SRE.1.5C
ASE_SRE.1.6C
ASE_SRE.1.7C
ASE_SRE.1.1E
The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall determine that all of the dependencies of the explicitly stated IT security requirements have been identified.
ASE_SRE.1.2E
Page 50 of 208
Version 2.1
August 1999
TOE summary specification (ASE_TSS) 5 - Class ASE: Security Target evaluation
5.8
ASE_TSS
TOE summary specification (ASE_TSS)
Security Target, TOE sum mary specification
Objectives
186
The TOE summary specification provides a high-level definition of the security functions claimed to meet the functional requirements and of the assurance measures taken to meet the assurance requirements. Application notes
187
The relationship between the IT security functions and the TOE security functional requirements can be a "many to many" relationship. Nevertheless, every security function shall contribute to the satisfaction of at least one security requirement in order be able to clearly define the TSF. Security functions that do not fulfil this requirement should normally not be necessary. Note, however, that the requirement that a security function contributes to the satisfaction of at least one security requirement is worded in a quite general manner, so that all the security functions found to be useful for the TOE should be justifiable. The statement of assurance measures is of specific relevance in all those cases where assurance requirements not taken from the CC are included in the ST. If the TOE security assurance requirements in the ST are exclusively based on CC evaluation assurance levels or other CC Part 3 assurance components, then the assurance measures could be presented in the form of a reference to the documents that show that the assurance requirements are met. In the ASE_TSS.1 component, the word "appropriate" is used to indicate that certain elements allow options in certain cases. Which options are applicable depends on the given context in the ST. Detailed information for all these aspects is contained in CC Part 1, annex C. Security Target, TOE summary specification, Evaluation requirements Dependencies: ASE_REQ.1 Security Target, IT security requirements, Evaluation requirements Developer action elements:
188
189
ASE_TSS.1
ASE_TSS.1.1D ASE_TSS.1.2D
The developer shall provide a TOE summary specification as part of the ST. The developer shall provide the TOE summary specification rationale. Content and presentation of evidence elements:
ASE_TSS.1.1C
The TOE summary specification shall describe the IT security functions and the assurance measures of the TOE.
August 1999
Version 2.1
Page 51 of 208
5 - Class ASE: Security Target evaluation
TOE summary specification (ASE_TSS)
ASE_TSS.1.2C
The TOE summary specification shall trace the IT security functions to the TOE security functional requirements such that it can be seen which IT security functions satisfy which TOE security functional requirements and that every IT security function contributes to the satisfaction of at least one TOE security functional requirement. The IT security functions shall be defined in an informal style to a level of detail necessary for understanding their intent. All references to security mechanisms included in the ST shall be traced to the relevant security functions so that it can be seen which security mechanisms are used in the implementation of each function. The TOE summary specification rationale shall demonstrate that the IT security functions are suitable to meet the TOE security functional requirements. The TOE summary specification rationale shall demonstrate that the combination of the specified IT security functions work together so as to satisfy the TOE security functional requirements. The TOE summary specification shall trace the assurance measures to the assurance requirements so that it can be seen which measures contribute to the satisfaction of which requirements. The TOE summary specification rationale shall demonstrate that the assurance measures meet all assurance requirements of the TOE. The TOE summary specification shall identify all IT security functions that are realised by a probabilistic or permutational mechanism, as appropriate. The TOE summary specification shall, for each IT security function for which it is appropriate, state the strength of function claim either as a specific metric, or as SOF-basic, SOF-medium or SOF-high. Evaluator action elements:
ASE_TSS.1.3C
ASE_TSS.1.4C
ASE_TSS.1.5C
ASE_TSS.1.6C
ASE_TSS.1.7C
ASE_TSS.1.8C
ASE_TSS.1.9C
ASE_TSS.1.10C
ASE_TSS.1.1E
The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall confirm that the TOE summary specification is complete, coherent, and internally consistent.
ASE_TSS.1.2E
Page 52 of 208
Version 2.1
August 1999
Part 3: Security assurance requirements 67
Evaluation assurance level (EAL) level (EAL) overview
6
190
Evaluation assurance levels
The Evaluation Assurance Levels (EALs) provide an increasing scale that balances the level of assurance obtained with the cost and feasibility of acquiring that degree of assurance. The CC approach identifies the separate concepts of assurance in a TOE at the end of the evaluation, and of maintenance of that assurance during the operational use of the TOE. It is important to note that not all families and components from CC Part 3 are included in the EALs. This is not to say that these do not provide meaningful and desirable assurances. Instead, it is expected that these families and components will be considered for augmentation of an EAL in those PPs and STs for which they provide utility.
191
6.1
192
Evaluation assurance level (EAL) overview
Table 6.1 represents a summary of the EALs. The columns represent a hierarchically ordered set of EALs, while the rows represent assurance families. Each number in the resulting matrix identifies a specific assurance component where applicable. As outlined in the next subclause, seven hierarchically ordered evaluation assurance levels are defined in the CC for the rating of a TOE's assurance. They are hierarchically ordered inasmuch as each EAL represents more assurance than all lower EALs. The increase in assurance from EAL to EAL is accomplished by substitution of a hierarchically higher assurance component from the same assurance family (i.e. increasing rigour, scope, and/or depth) and from the addition of assurance components from other assurance families (i.e. adding new requirements). These EALs consist of an appropriate combination of assurance components as described in clause 2 of this Part 3. More precisely, each EAL includes no more than one component of each assurance family and all assurance dependencies of every component are addressed. While the EALs are defined in the CC, it is possible to represent other combinations of assurance. Specifically, the notion of "augmentation" allows the addition of assurance components (from assurance families not already included in the EAL) or the substitution of assurance components (with another hierarchically higher assurance component in the same assurance family) to an EAL. Of the assurance constructs defined in the CC, only EALs may be augmented. The notion of an "EAL minus a constituent assurance component" is not recognised by the standard as a valid claim. Augmentation carries with it the obligation on the part of the claimant to justify the utility and added value of the added assurance component to the EAL. An EAL may also be extended with explicitly stated assurance requirements.
193
194
195
August 1999
Version 2.1
Page 53 of 208
6 - Evaluation assurance levels
Evaluation assurance level details
6.2
196
Evaluation assurance level details
The following subclauses provide definitions of the EALs, highlighting differences between the specific requirements and the prose characterisations of those requirements using bold type.
Table 6.1 - Evaluation assurance level summary
Assurance Components by Evaluation Assurance Level EAL1 EAL2 EAL3 EAL4 EAL5 EAL6 EAL7 1 2 1 2 Class ACM: ACM_AUT 1 2 3 4 5 4 5 Configuration ACM_CAP management ACM_SCP 1 2 3 3 3 1 2 3 Class ADO: ADO_DEL 1 2 2 Delivery and 1 ADO_IGS 1 1 1 1 1 1 operation 2 3 4 1 1 1 3 ADV_FSP 1 2 4 5 3 ADV_HLD 2 1 2 3 ADV_IMP 3 Class ADV: 1 2 3 ADV_INT Development 1 2 ADV_LLD 1 2 1 2 3 ADV_RCR 1 1 1 2 1 3 ADV_SPM 3 3 1 Class AGD: AGD_ADM 1 1 1 1 1 1 Guidance 1 1 1 1 1 1 1 AGD_USR documents 1 2 2 1 1 ALC_DVS Class ALC: ALC_FLR Life cycle 1 2 3 ALC_LCD 2 support 1 2 3 ALC_TAT 3 1 2 3 3 2 2 ATE_COV 1 2 3 1 2 Class ATE: ATE_DPT Tests 1 2 ATE_FUN 1 2 1 1 1 2 3 ATE_IND 2 2 2 2 1 2 AVA_CCA 2 Class AVA: AVA_MSU 1 2 3 2 3 Vulnerability 1 AVA_SOF 1 1 1 1 1 assessment 1 2 3 4 AVA_VLA 1 4 Assurance Class Assurance Family
Page 54 of 208
Version 2.1
August 1999
Evaluation assurance level details
6 - Evaluation assurance levels
6.2.1
Evaluation assurance level 1 (EAL1) - functionally tested Objectives
197
EAL1 is applicable where some confidence in correct operation is required, but the threats to security are not viewed as serious. It will be of value where independent assurance is required to support the contention that due care has been exercised with respect to the protection of personal or similar information. EAL1 provides an evaluation of the TOE as made available to the customer, including independent testing against a specification, and an examination of the guidance documentation provided. It is intended that an EAL1 evaluation could be successfully conducted without assistance from the developer of the TOE, and for minimal outlay. An evaluation at this level should provide evidence that the TOE functions in a manner consistent with its documentation, and that it provides useful protection against identified threats. Assurance components
198
199
200
EAL1 (see Table 6.2) provides a basic level of assurance by an analysis of the security functions using a functional and interface specification and guidance documentation, to understand the security behaviour. The analysis is supported by independent testing of the TOE security functions. This EAL provides a meaningful increase in assurance over an unevaluated IT product or system.
Table 6.2 - EAL1
201
202
Assurance class Assurance components Class ACM: Configuration ACM_CAP.1 Version numbers management Class ADO: Delivery and ADO_IGS.1 Installation, generation, and start-up operation procedures ADV_FSP.1 Informal functional specification Class ADV: Development ADV_RCR.1 Informal correspondence demonstration AGD_ADM.1 Administrator guidance Class AGD: Guidance documents AGD_USR.1 User guidance Class ATE: Tests ATE_IND.1 Independent testing - conformance
August 1999
Version 2.1
Page 55 of 208
6 - Evaluation assurance levels
Evaluation assurance level details
6.2.2
Evaluation assurance level 2 (EAL2) - structurally tested Objectives
203
EAL2 requires the co-operation of the developer in terms of the delivery of design information and test results, but should not demand more effort on the part of the developer than is consistent with good commercial practice. As such it should not require a substantially increased investment of cost or time. EAL2 is therefore applicable in those circumstances where developers or users require a low to moderate level of independently assured security in the absence of ready availability of the complete development record. Such a situation may arise when securing legacy systems, or where access to the developer may be limited. Assurance components
204
205
EAL2 (see Table 6.3) provides assurance by an analysis of the security functions, using a functional and interface specification, guidance documentation and the high-level design of the TOE, to understand the security behaviour. The analysis is supported by independent testing of the TOE security functions, evidence of developer testing based on the functional specification, selective independent confirmation of the developer test results, strength of function analysis, and evidence of a developer search for obvious vulnerabilities (e.g. those in the public domain). EAL2 also provides assurance through a configuration list for the TOE, and evidence of secure delivery procedures. This EAL represents a meaningful increase in assurance from EAL1 by requiring developer testing, a vulnerability analysis, and independent testing based upon more detailed TOE specifications.
206
207
208
Page 56 of 208
Version 2.1
August 1999
Evaluation assurance level details
6 - Evaluation assurance levels
Table 6.3 - EAL2
Assurance class Assurance components Class ACM: Configuration ACM_CAP.2 Configuration items management Class ADO: Delivery and ADO_DEL.1 Delivery procedures operation ADO_IGS.1 Installation, generation, and start-up procedures ADV_FSP.1 Informal functional specification Class ADV: Development ADV_HLD.1 Descriptive high-level design ADV_RCR.1 Informal correspondence demonstration AGD_ADM.1 Administrator guidance Class AGD: Guidance documents AGD_USR.1 User guidance ATE_COV.1 Evidence of coverage ATE_FUN.1 Functional testing Class ATE: Tests ATE_IND.2 Independent testing - sample Class AVA: Vulnerability AVA_SOF.1 Strength of TOE security function evaluation assessment AVA_VLA.1 Developer vulnerability analysis
August 1999
Version 2.1
Page 57 of 208
6 - Evaluation assurance levels
Evaluation assurance level details
6.2.3
Evaluation assurance level 3 (EAL3) - methodically tested and checked Objectives
209
EAL3 permits a conscientious developer to gain maximum assurance from positive security engineering at the design stage without substantial alteration of existing sound development practices. EAL3 is applicable in those circumstances where developers or users require a moderate level of independently assured security, and require a thorough investigation of the TOE and its development without substantial re-engineering. Assurance components
210
211
EAL3 (see Table 6.4) provides assurance by an analysis of the security functions, using a functional and interface specification, guidance documentation, and the high-level design of the TOE, to understand the security behaviour. The analysis is supported by independent testing of the TOE security functions, evidence of developer testing based on the functional specification and high-level design, selective independent confirmation of the developer test results, strength of function analysis, and evidence of a developer search for obvious vulnerabilities (e.g. those in the public domain). EAL3 also provides assurance through the use of development environment controls, TOE configuration management, and evidence of secure delivery procedures. This EAL represents a meaningful increase in assurance from EAL2 by requiring more complete testing coverage of the security functions and mechanisms and/or procedures that provide some confidence that the TOE will not be tampered with during development.
212
213
214
Page 58 of 208
Version 2.1
August 1999
Evaluation assurance level details
6 - Evaluation assurance levels
Table 6.4 - EAL3
Assurance class Assurance components Class ACM: Configuration ACM_CAP.3 Authorisation controls management ACM_SCP.1 TOE CM coverage Class ADO: Delivery and ADO_DEL.1 Delivery procedures operation ADO_IGS.1 Installation, generation, and start-up procedures ADV_FSP.1 Informal functional specification Class ADV: Development ADV_HLD.2 Security enforcing high-level design ADV_RCR.1 Informal correspondence demonstration AGD_ADM.1 Administrator guidance Class AGD: Guidance documents AGD_USR.1 User guidance Class ALC: Life cycle ALC_DVS.1 Identification of security measures support ATE_COV.2 Analysis of coverage ATE_DPT.1 Testing: high-level design Class ATE: Tests ATE_FUN.1 Functional testing ATE_IND.2 Independent testing - sample AVA_MSU.1 Examination of guidance Class AVA: Vulnerability AVA_SOF.1 Strength of TOE security function evaluation assessment AVA_VLA.1 Developer vulnerability analysis
August 1999
Version 2.1
Page 59 of 208
6 - Evaluation assurance levels
Evaluation assurance level details
6.2.4
Evaluation assurance level 4 (EAL4) - methodically designed, tested, and reviewed Objectives
215
EAL4 permits a developer to gain maximum assurance from positive security engineering based on good commercial development practices which, though rigorous, do not require substantial specialist knowledge, skills, and other resources. EAL4 is the highest level at which it is likely to be economically feasible to retrofit to an existing product line. EAL4 is therefore applicable in those circumstances where developers or users require a moderate to high level of independently assured security in conventional commodity TOEs and are prepared to incur additional security-specific engineering costs. Assurance components
216
217
EAL4 (see Table 6.5) provides assurance by an analysis of the security functions, using a functional and complete interface specification, guidance documentation, the high-level and low-level design of the TOE, and a subset of the implementation, to understand the security behaviour. Assurance is additionally gained through an informal model of the TOE security policy. The analysis is supported by independent testing of the TOE security functions, evidence of developer testing based on the functional specification and high-level design, selective independent confirmation of the developer test results, strength of function analysis, evidence of a developer search for vulnerabilities, and an independent vulnerability analysis demonstrating resistance to penetration attackers with a low attack potential. EAL4 also provides assurance through the use of development environment controls and additional TOE configuration management including automation, and evidence of secure delivery procedures. This EAL represents a meaningful increase in assurance from EAL3 by requiring more design description, a subset of the implementation, and improved mechanisms and/or procedures that provide confidence that the TOE will not be tampered with during development or delivery.
218
219
220
Page 60 of 208
Version 2.1
August 1999
Evaluation assurance level details
6 - Evaluation assurance levels
Table 6.5 - EAL4
Assurance components ACM_AUT.1 Partial CM automation Class ACM: Configuration ACM_CAP.4 Generation support and acceptance procedures management ACM_SCP.2 Problem tracking CM coverage Class ADO: Delivery and ADO_DEL.2 Detection of modification operation ADO_IGS.1 Installation, generation, and start-up procedures ADV_FSP.2 Fully defined external interfaces ADV_HLD.2 Security enforcing high-level design ADV_IMP.1 Subset of the implementation of the TSF Class ADV: Development ADV_LLD.1 Descriptive low-level design ADV_RCR.1 Informal correspondence demonstration ADV_SPM.1 Informal TOE security policy model AGD_ADM.1 Administrator guidance Class AGD: Guidance documents AGD_USR.1 User guidance ALC_DVS.1 Identification of security measures Class ALC: Life cycle ALC_LCD.1 Developer defined life-cycle model support ALC_TAT.1 Well-defined development tools ATE_COV.2 Analysis of coverage ATE_DPT.1 Testing: high-level design Class ATE: Tests ATE_FUN.1 Functional testing ATE_IND.2 Independent testing - sample AVA_MSU.2 Validation of analysis Class AVA: Vulnerability AVA_SOF.1 Strength of TOE security function evaluation assessment AVA_VLA.2 Independent vulnerability analysis
Assurance class
August 1999
Version 2.1
Page 61 of 208
6 - Evaluation assurance levels
Evaluation assurance level details
6.2.5
Evaluation assurance level 5 (EAL5) - semiformally designed and tested Objectives
221
EAL5 permits a developer to gain maximum assurance from security engineering based upon rigorous commercial development practices supported by moderate application of specialist security engineering techniques. Such a TOE will probably be designed and developed with the intent of achieving EAL5 assurance. It is likely that the additional costs attributable to the EAL5 requirements, relative to rigorous development without the application of specialised techniques, will not be large. EAL5 is therefore applicable in those circumstances where developers or users require a high level of independently assured security in a planned development and require a rigorous development approach without incurring unreasonable costs attributable to specialist security engineering techniques. Assurance components
222
223
EAL5 (see Table 6.6) provides assurance by an analysis of the security functions, using a functional and complete interface specification, guidance documentation, the high-level and low-level design of the TOE, and all of the implementation, to understand the security behaviour. Assurance is additionally gained through a formal model of the TOE security policy and a semiformal presentation of the functional specification and high-level design and a semiformal demonstration of correspondence between them. A modular TOE design is also required. The analysis is supported by independent testing of the TOE security functions, evidence of developer testing based on the functional specification, high-level design and low-level design, selective independent confirmation of the developer test results, strength of function analysis, evidence of a developer search for vulnerabilities, and an independent vulnerability analysis demonstrating resistance to penetration attackers with a moderate attack potential. The analysis also includes validation of the developer's covert channel analysis. EAL5 also provides assurance through the use of a development environment controls, and comprehensive TOE configuration management including automation, and evidence of secure delivery procedures. This EAL represents a meaningful increase in assurance from EAL4 by requiring semiformal design descriptions, the entire implementation, a more structured (and hence analysable) architecture, covert channel analysis, and improved mechanisms and/or procedures that provide confidence that the TOE will not be tampered with during development.
224
225
226
Page 62 of 208
Version 2.1
August 1999
Evaluation assurance level details
6 - Evaluation assurance levels
Table 6.6 - EAL5
Assurance components ACM_AUT.1 Partial CM automation Class ACM: Configuration ACM_CAP.4 Generation support and acceptance procedures management ACM_SCP.3 Development tools CM coverage Class ADO: Delivery and ADO_DEL.2 Detection of modification operation ADO_IGS.1 Installation, generation, and start-up procedures ADV_FSP.3 Semiformal functional specification ADV_HLD.3 Semiformal high-level design ADV_IMP.2 Implementation of the TSF Class ADV: Development ADV_INT.1 Modularity ADV_LLD.1 Descriptive low-level design ADV_RCR.2 Semiformal correspondence demonstration ADV_SPM.3 Formal TOE security policy model AGD_ADM.1 Administrator guidance Class AGD: Guidance documents AGD_USR.1 User guidance ALC_DVS.1 Identification of security measures Class ALC: Life cycle ALC_LCD.2 Standardised life-cycle model support ALC_TAT.2 Compliance with implementation standards ATE_COV.2 Analysis of coverage ATE_DPT.2 Testing: low-level design Class ATE: Tests ATE_FUN.1 Functional testing ATE_IND.2 Independent testing - sample AVA_CCA.1 Covert channel analysis Class AVA: Vulnerability AVA_MSU.2 Validation of analysis assessment AVA_SOF.1 Strength of TOE security function evaluation AVA_VLA.3 Moderately resistant
Assurance class
August 1999
Version 2.1
Page 63 of 208
6 - Evaluation assurance levels
Evaluation assurance level details
6.2.6
Evaluation assurance level 6 (EAL6) - semiformally verified design and tested Objectives
227
EAL6 permits developers to gain high assurance from application of security engineering techniques to a rigorous development environment in order to produce a premium TOE for protecting high value assets against significant risks. EAL6 is therefore applicable to the development of security TOEs for application in high risk situations where the value of the protected assets justifies the additional costs. Assurance components
228
229
EAL6 (see Table 6.7) provides assurance by an analysis of the security functions, using a functional and complete interface specification, guidance documentation, the high-level and low-level design of the of the TOE, and a structured presentation of the implementation, to understand the security behaviour. Assurance is additionally gained through a formal model of the TOE security policy, a semiformal presentation of the functional specification, high-level design, and low-level design and a semiformal demonstration of correspondence between them. A modular and layered TOE design is also required. The analysis is supported by independent testing of the TOE security functions, evidence of developer testing based on the functional specification, high-level design and low-level design, selective independent confirmation of the developer test results, strength of function analysis, evidence of a developer search for vulnerabilities, and an independent vulnerability analysis demonstrating resistance to penetration attackers with a high attack potential. The analysis also includes validation of the developer's systematic covert channel analysis. EAL6 also provides assurance through the use of a structured development process, development environment controls, and comprehensive TOE configuration management including complete automation, and evidence of secure delivery procedures. This EAL represents a meaningful increase in assurance from EAL5 by requiring more comprehensive analysis, a structured representation of the implementation, more architectural structure (e.g. layering), more comprehensive independent vulnerability analysis, systematic covert channel identification, and improved configuration management and development environment controls.
230
231
232
Page 64 of 208
Version 2.1
August 1999
Evaluation assurance level details
6 - Evaluation assurance levels
Table 6.7 - EAL6
Assurance components ACM_AUT.2 Complete CM automation Class ACM: ACM_CAP.5 Advanced support Configuration management ACM_SCP.3 Development tools CM coverage Class ADO: Delivery ADO_DEL.2 Detection of modification and operation ADO_IGS.1 Installation, generation, and start-up procedures ADV_FSP.3 Semiformal functional specification ADV_HLD.4 Semiformal high-level explanation ADV_IMP.3 Structured implementation of the TSF Class ADV: ADV_INT.2 Reduction of complexity Development ADV_LLD.2 Semiformal low-level design ADV_RCR.2 Semiformal correspondence demonstration ADV_SPM.3 Formal TOE security policy model Class AGD: Guidance AGD_ADM.1 Administrator guidance documents AGD_USR.1 User guidance ALC_DVS.2 Sufficiency of security measures Class ALC: Life cycle ALC_LCD.2 Standardised life-cycle model support ALC_TAT.3 Compliance with implementation standards - all parts ATE_COV.3 Rigorous analysis of coverage ATE_DPT.2 Testing: low-level design Class ATE: Tests ATE_FUN.2 Ordered functional testing ATE_IND.2 Independent testing - sample AVA_CCA.2 Systematic covert channel analysis Class AVA: AVA_MSU.3 Analysis and testing for insecure states Vulnerability AVA_SOF.1 Strength of TOE security function evaluation assessment AVA_VLA.4 Highly resistant
Assurance class
August 1999
Version 2.1
Page 65 of 208
6 - Evaluation assurance levels
Evaluation assurance level details
6.2.7
Evaluation assurance level 7 (EAL7) - formally verified design and tested Objectives
233
EAL7 is applicable to the development of security TOEs for application in extremely high risk situations and/or where the high value of the assets justifies the higher costs. Practical application of EAL7 is currently limited to TOEs with tightly focused security functionality that is amenable to extensive formal analysis. Assurance components
234
EAL7 (see Table 6.8) provides assurance by an analysis of the security functions, using a functional and complete interface specification, guidance documentation, the high-level and low-level design of the TOE, and a structured presentation of the implementation, to understand the security behaviour. Assurance is additionally gained through a formal model of the TOE security policy, a formal presentation of the functional specification and high-level design, a semiformal presentation of the low-level design, and formal and semiformal demonstration of correspondence between them, as appropriate. A modular, layered and simple TOE design is also required. The analysis is supported by independent testing of the TOE security functions, evidence of developer testing based on the functional specification high-level design, low-level design and implementation representation, complete independent confirmation of the developer test results, strength of function analysis, evidence of a developer search for vulnerabilities, and an independent vulnerability analysis demonstrating resistance to penetration attackers with a high attack potential. The analysis also includes validation of the developer's systematic covert channel analysis. EAL7 also provides assurance through the use of a structured development process, development environment controls, and comprehensive TOE configuration management including complete automation, and evidence of secure delivery procedures. This EAL represents a meaningful increase in assurance from EAL6 by requiring more comprehensive analysis using formal representations and formal correspondence, and comprehensive testing.
235
236
237
Page 66 of 208
Version 2.1
August 1999
Evaluation assurance level details
6 - Evaluation assurance levels
Table 6.8 - EAL7
Assurance class Class ACM: Configuration management Class ADO: Delivery and operation
Class ADV: Development
Class AGD: Guidance documents Class ALC: Life cycle support
Class ATE: Tests
Class AVA: Vulnerability assessment
Assurance components ACM_AUT.2 Complete CM automation ACM_CAP.5 Advanced support ACM_SCP.3 Development tools CM coverage ADO_DEL.3 Prevention of modification ADO_IGS.1 Installation, generation, and start-up procedures ADV_FSP.4 Formal functional specification ADV_HLD.5 Formal high-level design ADV_IMP.3 Structured implementation of the TSF ADV_INT.3 Minimisation of complexity ADV_LLD.2 Semiformal low-level design ADV_RCR.3 Formal correspondence demonstration ADV_SPM.3 Formal TOE security policy model AGD_ADM.1 Administrator guidance AGD_USR.1 User guidance ALC_DVS.2 Sufficiency of security measures ALC_LCD.3 Measurable life-cycle model ALC_TAT.3 Compliance with implementation standards - all parts ATE_COV.3 Rigorous analysis of coverage ATE_DPT.3 Testing: implementation representation ATE_FUN.2 Ordered functional testing ATE_IND.3 Independent testing - complete AVA_CCA.2 Systematic covert channel analysis AVA_MSU.3 Analysis and testing for insecure states AVA_SOF.1 Strength of TOE security function evaluation AVA_VLA.4 Highly resistant
August 1999
Version 2.1
Page 67 of 208
Part 3: Security assurance requirements 68
7
238
Assurance classes, families, and components
The next seven clauses provide the detailed requirements, presented in alphabetical order, of each of the assurance components, grouped by class and family.
August 1999
Version 2.1
Page 68 of 208
Part 3: Security assurance requirements 84
8
239
Class ACM: Configuration management
Configuration management (CM) is one method or means for establishing that the functional requirements and specifications are realised in the implementation of the TOE. CM meets these objectives by requiring discipline and control in the processes of refinement and modification of the TOE and the related information. CM systems are put in place to ensure the integrity of the portions of the TOE that they control, by providing a method of tracking any changes, and by ensuring that all changes are authorised. Figure 8.1 shows the families within this class, and the hierarchy of components within the families.
240
Class ACM: Configuration management ACM_AUT CM automation
1 2
ACM_CAP CM capabilities
1
2
3
4
5
ACM_SCP CM scope
1
2
3
Figure 8.1 -Configuration management class decomposition
August 1999
Version 2.1
Page 69 of 208
8 - Class ACM: Configuration management
CM automation (ACM_AUT)
8.1
ACM_AUT
CM automation (ACM_AUT)
CM automation
Objectives
241
The objective of introducing automated CM tools is to increase the effectiveness of the CM system. While both automated and manual CM systems can be bypassed, ignored, or prove insufficient to prevent unauthorised modification, automated systems are less susceptible to human error or negligence. Component levelling
242
The components in this family are levelled on the basis of the set of configuration items that are controlled through automated means. Application notes
243
ACM_AUT.1.1C introduces a requirement that is related to the implementation representation of the TOE. The implementation representation of the TOE consists of all hardware, software, and firmware that comprise the physical TOE. In the case of a software-only TOE, the implementation representation may consist solely of source and object code. ACM_AUT.1.2C introduces a requirement that the CM system provide an automated means to support the generation of the TOE. This requires that the CM system provide an automated means to assist in determining that the correct configuration items are used in generating the TOE. ACM_AUT.2.5C introduces a requirement that the CM system provide an automated means to ascertain the changes between the TOE and its preceding version. If no previous version of the TOE exists, the developer still needs to provide an automated means to ascertain the changes between the TOE and a future version of the TOE.
244
245
ACM_AUT.1 Partial CM automation Objectives
246
In development environments where the implementation representation is complex or is being developed by multiple developers, it is difficult to control changes without the support of automated tools. In particular, these automated tools need to be able to support the numerous changes that occur during development and ensure that those changes are authorised. It is the objective of this component to ensure that the implementation representation is controlled through automated means. Dependencies: ACM_CAP.3 Authorisation controls
Page 70 of 208
Version 2.1
August 1999
CM automation (ACM_AUT)
8 - Class ACM: Configuration management
Developer action elements:
ACM_AUT.1.1D ACM_AUT.1.2D
The developer shall use a CM system. The developer shall provide a CM plan. Content and presentation of evidence elements:
ACM_AUT.1.1C
The CM system shall provide an automated means by which only authorised changes are made to the TOE implementation representation. The CM system shall provide an automated means to support the generation of the TOE. The CM plan shall describe the automated tools used in the CM system. The CM plan shall describe how the automated tools are used in the CM system. Evaluator action elements:
ACM_AUT.1.2C
ACM_AUT.1.3C ACM_AUT.1.4C
ACM_AUT.1.1E
The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
ACM_AUT.2 Complete CM automation Objectives
247
In development environments where the configuration items are complex or are being developed by multiple developers, it is difficult to control changes without the support of automated tools. In particular, these automated tools need to be able to support the numerous changes that occur during development and ensure that those changes are authorised. It is the objective of this component to ensure that all configuration items are controlled through automated means. Providing an automated means of ascertaining changes between versions of the TOE and identifying which configuration items are affected by modifications to other configuration items assists in determining the impact of the changes between successive versions of the TOE. This in turn can provide valuable information in determining whether changes to the TOE result in all configuration items being consistent with one another. Dependencies: ACM_CAP.3 Authorisation controls Developer action elements:
248
ACM_AUT.2.1D
The developer shall use a CM system.
August 1999
Version 2.1
Page 71 of 208
8 - Class ACM: Configuration management
CM automation (ACM_AUT)
ACM_AUT.2.2D
The developer shall provide a CM plan. Content and presentation of evidence elements:
ACM_AUT.2.1C
The CM system shall provide an automated means by which only authorised changes are made to the TOE implementation representation, and to all other configuration items. The CM system shall provide an automated means to support the generation of the TOE. The CM plan shall describe the automated tools used in the CM system. The CM plan shall describe how the automated tools are used in the CM system. The CM system shall provide an automated means to ascertain the changes between the TOE and its preceding version. The CM system shall provide an automated means to identify all other configuration items that are affected by the modification of a given configuration item. Evaluator action elements:
ACM_AUT.2.2C
ACM_AUT.2.3C ACM_AUT.2.4C ACM_AUT.2.5C
ACM_AUT.2.6C
ACM_AUT.2.1E
The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
Page 72 of 208
Version 2.1
August 1999
CM capabilities (ACM_CAP)
8 - Class ACM: Configuration management
8.2
ACM_CAP
CM capabilities (ACM_CAP)
CM capabilities
Objectives
249
The capabilities of the CM system address the likelihood that accidental or unauthorised modifications of the configuration items will occur. The CM system should ensure the integrity of the TOE from the early design stages through all subsequent maintenance efforts. The objectives of this family include the following: a) ensuring that the TOE is correct and complete before it is sent to the consumer; b) ensuring that no configuration items are missed during evaluation; c) preventing unauthorised modification, addition, or deletion of TOE configuration items. Component levelling
250
251
The components in this family are levelled on the basis of the CM system capabilities, the scope of the CM documentation provided by the developer, and whether the developer provides justification that the CM system meets its security requirements. Application notes
252
ACM_CAP.2 introduces several elements which refer to configuration items. The ACM_SCP family contains requirements for the configuration items to be tracked by the CM system. ACM_CAP.2.3C introduces a requirement that a configuration list be provided. The configuration list contains all configuration items that are maintained by the CM system. ACM_CAP.2.6C introduces a requirement that the CM system uniquely identify all configuration items. This also requires that modifications to configuration items result in a new, unique identifier being assigned. ACM_CAP.3.8C introduces the requirement that the evidence shall demonstrate that the CM system operates in accordance with the CM plan. Examples of such evidence might be documentation such as screen snapshots or audit trail output from the CM system, or a detailed demonstration of the CM system by the developer. The evaluator is responsible for determining that this evidence is sufficient to show that the CM system operates in accordance with the CM plan. ACM_CAP.3.9C introduces the requirement that evidence be provided to show that all configuration items are being maintained under the CM system. Since a
253
254
255
256
August 1999
Version 2.1
Page 73 of 208
8 - Class ACM: Configuration management
CM capabilities (ACM_CAP)
configuration item refers to an item that is on the configuration list, this requirement states that all items on the configuration list are maintained under the CM system.
257
ACM_CAP.4.11C introduces the requirement that the CM system support the generation of the TOE. This requires that the CM system provide information and/ or electronic means to assist in determining that the correct configuration items are used in generating the TOE.
ACM_CAP.1 Version numbers Objectives
258
A unique reference is required to ensure that there is no ambiguity in terms of which instance of the TOE is being evaluated. Labelling the TOE with its reference ensures that users of the TOE can be aware of which instance of the TOE they are using. Dependencies: No dependencies. Developer action elements:
ACM_CAP.1.1D
The developer shall provide a reference for the TOE. Content and presentation of evidence elements:
ACM_CAP.1.1C ACM_CAP.1.2C
The reference for the TOE shall be unique to each version of the TOE. The TOE shall be labelled with its reference. Evaluator action elements:
ACM_CAP.1.1E
The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
ACM_CAP.2 Configuration items Objectives
259
A unique reference is required to ensure that there is no ambiguity in terms of which instance of the TOE is being evaluated. Labelling the TOE with its reference ensures that users of the TOE can be aware of which instance of the TOE they are using. Unique identification of the configuration items leads to a clearer understanding of the composition of the TOE, which in turn helps to determine those items which are subject to the evaluation requirements for the TOE.
260
Page 74 of 208
Version 2.1
August 1999
CM capabilities (ACM_CAP)
8 - Class ACM: Configuration management
Dependencies: No dependencies. Developer action elements:
ACM_CAP.2.1D ACM_CAP.2.2D ACM_CAP.2.3D
The developer shall provide a reference for the TOE. The developer shall use a CM system. The developer shall provide CM documentation. Content and presentation of evidence elements:
ACM_CAP.2.1C ACM_CAP.2.2C ACM_CAP.2.3C ACM_CAP.2.4C
The reference for the TOE shall be unique to each version of the TOE. The TOE shall be labelled with its reference. The CM documentation shall include a configuration list. The configuration list shall describe the configuration items that comprise the TOE. The CM documentation shall describe the method used to uniquely identify the configuration items. The CM system shall uniquely identify all configuration items. Evaluator action elements:
ACM_CAP.2.5C
ACM_CAP.2.6C
ACM_CAP.2.1E
The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
ACM_CAP.3 Authorisation controls Objectives
261
A unique reference is required to ensure that there is no ambiguity in terms of which instance of the TOE is being evaluated. Labelling the TOE with its reference ensures that users of the TOE can be aware of which instance of the TOE they are using. Unique identification of the configuration items leads to a clearer understanding of the composition of the TOE, which in turn helps to determine those items which are subject to the evaluation requirements for the TOE. Providing controls to ensure that unauthorised modifications are not made to the TOE, and ensuring proper functionality and use of the CM system, helps to maintain the integrity of the TOE.
262
263
August 1999
Version 2.1
Page 75 of 208
8 - Class ACM: Configuration management
CM capabilities (ACM_CAP)
Dependencies: ACM_SCP.1 TOE CM coverage ALC_DVS.1 Identification of security measures Developer action elements:
ACM_CAP.3.1D ACM_CAP.3.2D ACM_CAP.3.3D
The developer shall provide a reference for the TOE. The developer shall use a CM system. The developer shall provide CM documentation. Content and presentation of evidence elements:
ACM_CAP.3.1C ACM_CAP.3.2C ACM_CAP.3.3C ACM_CAP.3.4C ACM_CAP.3.5C
The reference for the TOE shall be unique to each version of the TOE. The TOE shall be labelled with its reference. The CM documentation shall include a configuration list and a CM plan. The configuration list shall describe the configuration items that comprise the TOE. The CM documentation shall describe the method used to uniquely identify the configuration items. The CM system shall uniquely identify all configuration items. The CM plan shall describe how the CM system is used. The evidence shall demonstrate that the CM system is operating in accordance with the CM plan. The CM documentation shall provide evidence that all configuration items have been and are being effectively maintained under the CM system. The CM system shall provide measures such that only authorised changes are made to the configuration items. Evaluator action elements:
ACM_CAP.3.6C ACM_CAP.3.7C ACM_CAP.3.8C
ACM_CAP.3.9C
ACM_CAP.3.10C
ACM_CAP.3.1E
The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
ACM_CAP.4 Generation support and acceptance procedures Objectives
264
A unique reference is required to ensure that there is no ambiguity in terms of which instance of the TOE is being evaluated. Labelling the TOE with its reference
Page 76 of 208
Version 2.1
August 1999
CM capabilities (ACM_CAP)
8 - Class ACM: Configuration management
ensures that users of the TOE can be aware of which instance of the TOE they are using.
265
Unique identification of the configuration items leads to a clearer understanding of the composition of the TOE, which in turn helps to determine those items which are subject to the evaluation requirements for the TOE. Providing controls to ensure that unauthorised modifications are not made to the TOE, and ensuring proper functionality and use of the CM system, helps to maintain the integrity of the TOE. The purpose of acceptance procedures is to confirm that any creation or modification of configuration items is authorised. Dependencies: ACM_SCP.1 TOE CM coverage ALC_DVS.1 Identification of security measures Developer action elements:
266
267
ACM_CAP.4.1D ACM_CAP.4.2D ACM_CAP.4.3D
The developer shall provide a reference for the TOE. The developer shall use a CM system. The developer shall provide CM documentation. Content and presentation of evidence elements:
ACM_CAP.4.1C ACM_CAP.4.2C ACM_CAP.4.3C
The reference for the TOE shall be unique to each version of the TOE. The TOE shall be labelled with its reference. The CM documentation shall include a configuration list, a CM plan, and an acceptance plan. The configuration list shall describe the configuration items that comprise the TOE. The CM documentation shall describe the method used to uniquely identify the configuration items. The CM system shall uniquely identify all configuration items. The CM plan shall describe how the CM system is used. The evidence shall demonstrate that the CM system is operating in accordance with the CM plan. The CM documentation shall provide evidence that all configuration items have been and are being effectively maintained under the CM system.
ACM_CAP.4.4C ACM_CAP.4.5C
ACM_CAP.4.6C ACM_CAP.4.7C ACM_CAP.4.8C
ACM_CAP.4.9C
August 1999
Version 2.1
Page 77 of 208
8 - Class ACM: Configuration management
CM capabilities (ACM_CAP)
ACM_CAP.4.10C
The CM system shall provide measures such that only authorised changes are made to the configuration items. The CM system shall support the generation of the TOE. The acceptance plan shall describe the procedures used to accept modified or newly created configuration items as part of the TOE. Evaluator action elements:
ACM_CAP.4.11C ACM_CAP.4.12C
ACM_CAP.4.1E
The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
ACM_CAP.5 Advanced support Objectives
268
A unique reference is required to ensure that there is no ambiguity in terms of which instance of the TOE is being evaluated. Labelling the TOE with its reference ensures that users of the TOE can be aware of which instance of the TOE they are using. Unique identification of the configuration items leads to a clearer understanding of the composition of the TOE, which in turn helps to determine those items which are subject to the evaluation requirements for the TOE. Providing controls to ensure that unauthorised modifications are not made to the TOE, and ensuring proper functionality and use of the CM system, helps to maintain the integrity of the TOE. The purpose of acceptance procedures is to confirm that any creation or modification of configuration items is authorised. Integration procedures help to ensure that generation of the TOE from a managed set of configuration items is correctly performed in an authorised manner. Requiring that the CM system be able to identify the master copy of the material used to generate the TOE helps to ensure that the integrity of this material is preserved by the appropriate technical, physical and procedural safeguards. Dependencies: ACM_SCP.1 TOE CM coverage ALC_DVS.2 Sufficiency of security measures Developer action elements:
269
270
271
272
273
ACM_CAP.5.1D ACM_CAP.5.2D
The developer shall provide a reference for the TOE. The developer shall use a CM system.
Page 78 of 208
Version 2.1
August 1999
CM capabilities (ACM_CAP)
8 - Class ACM: Configuration management
ACM_CAP.5.3D
The developer shall provide CM documentation. Content and presentation of evidence elements:
ACM_CAP.5.1C ACM_CAP.5.2C ACM_CAP.5.3C
The reference for the TOE shall be unique to each version of the TOE. The TOE shall be labelled with its reference. The CM documentation shall include a configuration list, a CM plan, an acceptance plan, and integration procedures. The configuration list shall describe the configuration items that comprise the TOE. The CM documentation shall describe the method used to uniquely identify the configuration items. The CM system shall uniquely identify all configuration items. The CM plan shall describe how the CM system is used. The evidence shall demonstrate that the CM system is operating in accordance with the CM plan. The CM documentation shall provide evidence that all configuration items have been and are being effectively maintained under the CM system. The CM system shall provide measures such that only authorised changes are made to the configuration items. The CM system shall support the generation of the TOE. The acceptance plan shall describe the procedures used to accept modified or newly created configuration items as part of the TOE. The integration procedures shall describe how the CM system is applied in the TOE manufacturing process. The CM system shall require that the person responsible for accepting a configuration item into CM is not the person who developed it. The CM system shall clearly identify the configuration items that comprise the TSF. The CM system shall support the audit of all modifications to the TOE, including as a minimum the originator, date, and time in the audit trail. The CM system shall be able to identify the master copy of all material used to generate the TOE.
ACM_CAP.5.4C ACM_CAP.5.5C
ACM_CAP.5.6C ACM_CAP.5.7C ACM_CAP.5.8C
ACM_CAP.5.9C
ACM_CAP.5.10C
ACM_CAP.5.11C ACM_CAP.5.12C
ACM_CAP.5.13C
ACM_CAP.5.14C
ACM_CAP.5.15C
ACM_CAP.5.16C
ACM_CAP.5.17C
August 1999
Version 2.1
Page 79 of 208
8 - Class ACM: Configuration management
CM capabilities (ACM_CAP)
ACM_CAP.5.18C
The CM documentation shall demonstrate that the use of the CM system, together with the development security measures, allow only authorised changes to be made to the TOE. The CM documentation shall demonstrate that the use of the integration procedures ensures that the generation of the TOE is correctly performed in an authorised manner. The CM documentation shall demonstrate that the CM system is sufficient to ensure that the person responsible for accepting a configuration item into CM is not the person who developed it. The CM documentation shall justify that the acceptance procedures provide for an adequate and appropriate review of changes to all configuration items. Evaluator action elements:
ACM_CAP.5.19C
ACM_CAP.5.20C
ACM_CAP.5.21C
ACM_CAP.5.1E
The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
Page 80 of 208
Version 2.1
August 1999
CM scope (ACM_SCP)
8 - Class ACM: Configuration management
8.3
ACM_SCP
CM scope (ACM_SCP)
CM scope
Objectives
274
The objective of this family is to ensure that all necessary TOE configuration items are tracked by the CM system. This helps to ensure that the integrity of these configuration items is protected through the capabilities of the CM system. The objectives of this family include the following: a) ensuring that the TOE implementation representation is tracked; b) ensuring that all necessary documentation, including problem reports, are tracked during development and operation; c) ensuring that configuration options (e.g. compiler switches) are tracked; and d) ensuring that development tools are tracked. Component levelling
275
276
The components in this family are levelled on the basis of which of the following are tracked by the CM system: the TOE implementation representation; design documentation; test documentation; user documentation; administrator documentation; CM documentation; security flaws; and development tools. Application notes
277
ACM_SCP.1.1C introduces the requirement that the TOE implementation representation be tracked by the CM system. The TOE implementation representation refers to all hardware, software, and firmware that comprise the physical TOE. In the case of a software-only TOE, the implementation representation may consist solely of source and object code. ACM_SCP.1.1C also introduces the requirement that the CM documentation be tracked by the CM system. This includes the CM plan, as well as information on the current versions of any tools that comprise the CM system. ACM_SCP.2.1C introduces the requirement that security flaws be tracked by the CM system. This requires that information regarding previous security flaws and their resolution be maintained, as well as details regarding current security flaws. ACM_SCP.3.1C introduces the requirement that development tools and other related information be tracked by the CM system. Examples of development tools are programming languages and compilers. Information pertaining to TOE generation items (such as compiler options, installation/generation options, and build options) is an example of information relating to development tools.
278
279
280
August 1999
Version 2.1
Page 81 of 208
8 - Class ACM: Configuration management
CM scope (ACM_SCP)
ACM_SCP.1 TOE CM coverage Objectives
281
A CM system can control changes only to those items that have been placed under CM. Placing the TOE implementation representation, design, tests, user and administrator documentation, and CM documentation under CM provides assurance that they have been modified in a controlled manner with proper authorisations. Dependencies: ACM_CAP.3 Authorisation controls Developer action elements:
ACM_SCP.1.1D
The developer shall provide CM documentation. Content and presentation of evidence elements:
ACM_SCP.1.1C
The CM documentation shall show that the CM system, as a minimum, tracks the following: the TOE implementation representation, design documentation, test documentation, user documentation, administrator documentation, and CM documentation. The CM documentation shall describe how configuration items are tracked by the CM system. Evaluator action elements:
ACM_SCP.1.2C
ACM_SCP.1.1E
The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
ACM_SCP.2 Problem tracking CM coverage Objectives
282
A CM system can control changes only to those items that have been placed under CM. Placing the TOE implementation representation, design, tests, user and administrator documentation, and CM documentation under CM provides assurance that they have been modified in a controlled manner with proper authorisations. The ability to track security flaws under CM ensures that security flaw reports are not lost or forgotten, and allows a developer to track security flaws to their resolution. Dependencies: ACM_CAP.3 Authorisation controls
283
Page 82 of 208
Version 2.1
August 1999
CM scope (ACM_SCP)
8 - Class ACM: Configuration management
Developer action elements:
ACM_SCP.2.1D
The developer shall provide CM documentation. Content and presentation of evidence elements:
ACM_SCP.2.1C
The CM documentation shall show that the CM system, as a minimum, tracks the following: the TOE implementation representation, design documentation, test documentation, user documentation, administrator documentation, CM documentation, and security flaws. The CM documentation shall describe how configuration items are tracked by the CM system. Evaluator action elements:
ACM_SCP.2.2C
ACM_SCP.2.1E
The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
ACM_SCP.3 Development tools CM coverage Objectives
284
A CM system can control changes only to those items that have been placed under CM. Placing the TOE implementation representation, design, tests, user and administrator documentation, and CM documentation under CM provides assurance that they have been modified in a controlled manner with proper authorisations. The ability to track security flaws under CM ensures that security flaw reports are not lost or forgotten, and allows a developer to track security flaws to their resolution. Development tools play an important role in ensuring the production of a quality version of the TOE. Therefore, it is important to control modifications to these tools. Dependencies: ACM_CAP.3 Authorisation controls Developer action elements:
285
286
ACM_SCP.3.1D
The developer shall provide CM documentation.
August 1999
Version 2.1
Page 83 of 208
8 - Class ACM: Configuration management
CM scope (ACM_SCP)
Content and presentation of evidence elements:
ACM_SCP.3.1C
The CM documentation shall show that the CM system, as a minimum, tracks the following: the TOE implementation representation, design documentation, test documentation, user documentation, administrator documentation, CM documentation, security flaws, and development tools and related information. The CM documentation shall describe how configuration items are tracked by the CM system. Evaluator action elements:
ACM_SCP.3.2C
ACM_SCP.3.1E
The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
Page 84 of 208
Version 2.1
August 1999
Part 3: Security assurance requirements 89
9
287
Class ADO: Delivery and operation
Delivery and operation provides requirements for correct delivery, installation, generation, and start-up of the TOE. Figure 9.1 shows the families within this class, and the hierarchy of components within the families.
288
Class ADO: Delivery and operation ADO_DEL Delivery ADO_IGS Installation, generation and start-up 1 1 2 2 3
Figure 9.1 -Delivery and operation class decomposition
August 1999
Version 2.1
Page 85 of 208
9 - Class ADO: Delivery and operation
Delivery (ADO_DEL)
9.1
ADO_DELDelivery
Delivery (ADO_DEL)
Objectives
289
The requirements for delivery call for system control and distribution facilities and procedures that provide assurance that the recipient receives the TOE that the sender intended to send, without any modifications. For a valid delivery, what is received must correspond precisely to the TOE master copy, thus avoiding any tampering with the actual version, or substitution of a false version. Component levelling
290
The components in this family are levelled on the basis of increasing requirements on the developer to detect and prevent modifications to the TOE during delivery.
ADO_DEL.1 Delivery procedures Dependencies: No dependencies. Developer action elements:
ADO_DEL.1.1D
The developer shall document procedures for delivery of the TOE or parts of it to the user. The developer shall use the delivery procedures. Content and presentation of evidence elements:
ADO_DEL.1.2D
ADO_DEL.1.1C
The delivery documentation shall describe all procedures that are necessary to maintain security when distributing versions of the TOE to a user's site. Evaluator action elements:
ADO_DEL.1.1E
The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
ADO_DEL.2 Detection of modification Dependencies: ACM_CAP.3 Authorisation controls Developer action elements:
ADO_DEL.2.1D
The developer shall document procedures for delivery of the TOE or parts of it to the user. The developer shall use the delivery procedures.
ADO_DEL.2.2D
Page 86 of 208
Version 2.1
August 1999
Delivery (ADO_DEL)
9 - Class ADO: Delivery and operation
Content and presentation of evidence elements:
ADO_DEL.2.1C
The delivery documentation shall describe all procedures that are necessary to maintain security when distributing versions of the TOE to a user's site. The delivery documentation shall describe how the various procedures and technical measures provide for the detection of modifications, or any discrepancy between the developer's master copy and the version received at the user site. The delivery documentation shall describe how the various procedures allow detection of attempts to masquerade as the developer, even in cases in which the developer has sent nothing to the user's site. Evaluator action elements:
ADO_DEL.2.2C
ADO_DEL.2.3C
ADO_DEL.2.1E
The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
ADO_DEL.3 Prevention of modification Dependencies: ACM_CAP.3 Authorisation controls Developer action elements:
ADO_DEL.3.1D
The developer shall document procedures for delivery of the TOE or parts of it to the user. The developer shall use the delivery procedures. Content and presentation of evidence elements:
ADO_DEL.3.2D
ADO_DEL.3.1C
The delivery documentation shall describe all procedures that are necessary to maintain security when distributing versions of the TOE to a user's site. The delivery documentation shall describe how the various procedures and technical measures provide for the prevention of modifications, or any discrepancy between the developer's master copy and the version received at the user site. The delivery documentation shall describe how the various procedures allow detection of attempts to masquerade as the developer, even in cases in which the developer has sent nothing to the user's site. Evaluator action elements:
ADO_DEL.3.2C
ADO_DEL.3.3C
ADO_DEL.3.1E
The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
August 1999
Version 2.1
Page 87 of 208
9 - Class ADO: Delivery and operation
Installation, generation and start-up (ADO_IGS)
9.2
ADO_IGS
Installation, generation and start-up (ADO_IGS)
Installation, generation and start-up
Objectives
291
Installation, generation, and start-up procedures are useful for ensuring that the TOE has been installed, generated, and started up in a secure manner as intended by the developer. The requirements for installation, generation and start-up call for a secure transition from the TOE's implementation representation being under configuration control to its initial operation in the user environment. Component levelling
292
The components in this family are levelled on the basis of whether the TOE generation options are logged. Application notes
293
It is recognised that the application of these requirements will vary depending on aspects such as whether the TOE is an IT product or system, whether it is delivered in an operational state, or whether it has to be brought up at the TOE owner's site, etc. For a given TOE, there will normally be a division of responsibility with respect to installation, generation and start-up between the TOE developer and the owner of the TOE, but there are examples where all activities take place at one site. For example, for a smart card all aspects of installation, generation and start-up may have been performed at the TOE developer's site. On the other hand the TOE might be delivered as an IT system in the form of software, where all aspects of installation, generation and start-up are carried out at the TOE owner's site. It might also be the case that the TOE is already installed by the time the evaluation starts. In this case it may be inappropriate to demand and analyse installation procedures. Furthermore, the generation requirements are applicable only to TOEs that provide the ability to generate portions of an operational TOE from its implementation representation. The installation, generation, and start-up procedures may exist as a separate documents or could be grouped with other administrative guidance. The requirements in this assurance family are presented separately from those in the AGD_ADM family, due to the infrequent, possibly one-time use of the installation, generation and start-up procedures.
294
295
296
ADO_IGS.1 Installation, generation, and start-up procedures Dependencies: AGD_ADM.1 Administrator guidance
Page 88 of 208
Version 2.1
August 1999
Installation, generation and start-up
9 - Class ADO: Delivery and operation
Developer action elements:
ADO_IGS.1.1D
The developer shall document procedures necessary for the secure installation, generation, and start-up of the TOE. Content and presentation of evidence elements:
ADO_IGS.1.1C
The documentation shall describe the steps necessary for secure installation, generation, and start-up of the TOE. Evaluator action elements:
ADO_IGS.1.1E
The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall determine that the installation, generation, and start-up procedures result in a secure configuration.
ADO_IGS.1.2E
ADO_IGS.2 Generation log Dependencies: AGD_ADM.1 Administrator guidance Developer action elements:
ADO_IGS.2.1D
The developer shall document procedures necessary for the secure installation, generation, and start-up of the TOE. Content and presentation of evidence elements:
ADO_IGS.2.1C
The documentation shall describe the steps necessary for secure installation, generation, and start-up of the TOE. The documentation shall describe procedures capable of creating a log containing the generation options used to generate the TOE in such a way that it is possible to determine exactly how and when the TOE was generated. Evaluator action elements:
ADO_IGS.2.2C
ADO_IGS.2.1E
The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall determine that the installation, generation, and start-up procedures result in a secure configuration.
ADO_IGS.2.2E
August 1999
Version 2.1
Page 89 of 208
Part 3: Security assurance requirements 126
10
297
Class ADV: Development
The development class encompasses four families of requirements for representing the TSF at various levels of abstraction from the functional interface to the implementation representation. The development class also includes a family of requirements for a correspondence mapping between the various TSF representations, ultimately requiring a demonstration of correspondence from the least abstract representation through all intervening representations to the TOE summary specification provided in the ST. In addition, there is a family of requirements for a TSP model, and for correspondence mappings between the TSP, the TSP model, and the functional specification. Finally, there is a family of requirements on the internal structure of the TSF, which covers aspects such as modularity, layering, and minimisation of complexity. Figure 10.1 shows the families within this class, and the hierarchy of components within the families. Class ADV: Development ADV_FSP Functional specification ADV_HLD High-level design ADV_IMP Implementation representation ADV_INT TSF internals ADV_LLD Low-level design ADV_RCR Representation correspondence ADV_SPM Security policy modeling 1 1 1 1 1 1 1 2 2 2 2 2 2 2 3 3 3 3 3 3 3 4 4 5
298
Figure 10.1 - Development class decomposition
299
The paradigm evident for these families is one of a functional specification of the TSF, decomposing the TSF into subsystems, decomposing the subsystems into modules, showing the implementation of the modules, and demonstration of correspondence between all decompositions that are provided as evidence. The requirements for the various TSF representations are separated into different
August 1999
Version 2.1
Page 90 of 208
10 - Class ADV: Development
families, however, to allow the PP/ST author to specify which subset of the TSF representations are required.
Environment APE/ASE_OBJ Security Objectives APE/ASE_REQ Functional Requirements/TSP ASE_TSS TOE Summary Specification ADV_FSP ADV_RCR Functional Specification ADV_HLD ADV_RCR High-level Design ADV_RCR ADV_LLD Low-level Design ADV_RCR Implementation Representation ADV_SPM ADV_SPM
Source corresponds to target.
Source is refined in target.
TSP Model
ADV_IMP
Figure 10.2 - Relationships between TOE representations and requirements
300
Figure 10.2 indicates the relationships between the various TSF representations and the objectives and requirements that they are intended to address. As the figure indicates, the APE and ASE classes define the requirements for the correspondence between the functional requirements and the security objectives as well as between
August 1999
Version 2.1
Page 91 of 208
10 - Class ADV: Development
the security objectives and the TOE's anticipated environment. Class ASE also defines requirements for the correspondence between both the security objectives and functional requirements and the TOE summary specification.
301
The requirements for all other correspondence shown in Figure 10.2 are defined in the ADV class. The ADV_SPM family defines the requirements for correspondence between the TSP and the TSP model, and between the TSP model and the functional specification. The ADV_RCR family defines the requirements for correspondence between all available TSF representations from the TOE summary specification through the implementation representation. Finally, each assurance family specific to a TSF representation (i.e. ADV_FSP, ADV_HLD, ADV_LLD and ADV_IMP) defines requirements relating that TSF representation to the functional requirements, the combination of which helps to ensure that the TOE security functional requirements have been addressed. The traceability analysis is always to be performed from the highest-level TSF representation down through each of the TSF representations that are provided. The CC captures this traceability requirement via dependencies on the ADV_RCR family. The ADV_INT family is not represented in this figure, as it is related to the internal structure of the TSF, and is only indirectly related to the process of refinement of the TSF representations. Application notes
302
The TOE security policy (TSP) is the set of rules that regulate how resources are managed, protected and distributed within a TOE, expressed by the TOE security functional requirements. The developer is not explicitly required to provide a TSP, as the TSP is expressed by the TOE security functional requirements, through a combination of security function policies (SFPs) and the other individual requirement elements. The TOE security functions (TSF) are all the parts of the TOE that have to be relied upon for enforcement of the TSP. 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. Although the requirements within the ASE_TSS family and within several families of this class call for several different TSF representations, it is not absolutely necessary for each and every TSF representation to be in a separate document. Indeed, it may be the case that a single document meets the documentation requirements for more than one TSF representation, since it is the information about each of these TSF representations that is required, rather than the resulting document structure. In cases where multiple TSF representations are combined within a single document, the developer should indicate which documents meet which requirements. Three types of specification style are mandated by this class: informal, semiformal and formal. The functional specification, high-level design, low-level design and TSP models will be written using one or more of these specification styles. Ambiguity in these specifications is reduced by using an increased level of formality.
303
304
305
Page 92 of 208
Version 2.1
August 1999
10 - Class ADV: Development
306
An informal specification is written as prose in natural language. Natural language is used here as meaning communication in any commonly spoken tongue (e.g. Dutch, English, French, German). An informal specification is not subject to any notational or special restrictions other than those required as ordinary conventions for that language (e.g. grammar and syntax). While no notational restrictions apply, the informal specification is also required to provide defined meanings for terms that are used in a context other than that accepted by normal usage. A semiformal specification is written in a restricted syntax language and is typically accompanied by supporting explanatory (informal) prose. The restricted syntax language may be a natural language with restricted sentence structure and keywords with special meanings, or it may be diagrammatic (e.g. data-flow diagrams, state transition diagrams, entity-relationship diagrams, data structure diagrams, and process or program structure diagrams). Whether based on diagrams or natural language, a set of conventions must be supplied to define the restrictions placed on the syntax. A formal specification is written in a notation based upon well-established mathematical concepts, and is typically accompanied by supporting explanatory (informal) prose. These mathematical concepts are used to define the syntax and semantics of the notation and the proof rules that support logical reasoning. The syntactic and semantic rules supporting a formal notation should define how to recognise constructs unambiguously and determine their meaning. There needs to be evidence that it is impossible to derive contradictions, and all rules supporting the notation need to be defined or referenced. Significant assurance can be gained by ensuring that the TSF can be traced though each of its representations, and by ensuring that the TSP model corresponds to the functional specification. The ADV_RCR family contains requirements for correspondence mappings between the various TSF representations, and the ADV_SPM family contains requirements for a correspondence mapping between the TSP model and the functional specification. A correspondence can take the form of an informal demonstration, a semiformal demonstration, or a formal proof. When an informal demonstration of correspondence is required, this means that only a basic correspondence is required. Correspondence methods include, for example, the use of a two-dimensional table with entries denoting correspondence, or the use of appropriate notation of design diagrams. Pointers and references to other documents may also be used. A semiformal demonstration of correspondence requires a structured approach at the analysis of the correspondence. This approach should lessen ambiguity that could exist in an informal correspondence by limiting the interpretation of the terms included in the correspondence. Pointers and references to other documents may be used. A formal proof of correspondence requires that well-established mathematical concepts be used to define the syntax and semantics of the formal notation and the proof rules that support logical reasoning. The security properties need to be expressible in the formal specification language, and these security properties need
307
308
309
310
311
312
August 1999
Version 2.1
Page 93 of 208
10 - Class ADV: Development
to be shown to be satisfied by the formal specification. Pointers and references to other documents may also be used.
313
The ADV_RCR.*.1C elements require that the developer provide evidence, for each adjacent pair of TSF representations, that all relevant security functionality of the more abstract TSF representation is refined in the less abstract TSF representation. The ADV_FSP.*.2E, ADV_HLD.*.2E, ADV_LLD.*.2E and ADV_IMP.*.2E elements each require the evaluator to determine that the TSF represented by that family of requirements is an accurate and complete instantiation of the TOE security functional requirements. In order to determine that a TSF representation is an accurate and complete instantiation of the TOE security functional requirements, it is intended that the evaluator use the evidence provided by the developer in ADV_RCR.*.1C as an input to this determination. By establishing a correspondence between the TOE security functional requirements and each of successive TSF representations down the chain, this step-wise process will ultimately provide more assurance that the least abstract TSF representation corresponds to the TOE security functional requirements, which is the ultimate goal of this class. If the evaluator makes no correspondence determinations back to the TOE security functional requirements for intermediate TSF representations, then trying to determine the correspondence from the least abstract TSF representation back to the TOE security functional requirements may represent too large a step to be accurately performed. Finally, depending on the set of TSF representations that are required, it is quite possible that the low-level design, high-level design, or even the functional specification might be the least abstract TSF representation that is provided.
Page 94 of 208
Version 2.1
August 1999
Functional specification (ADV_FSP)
10 - Class ADV: Development
10.1
ADV_FSP
Functional specification (ADV_FSP)
Functional specification
Objectives
314
The functional specification is a high-level description of the user-visible interface and behaviour of the TSF. It is an instantiation of the TOE security functional requirements. The functional specification has to show that all the TOE security functional requirements are addressed. Component levelling
315
The components in this family are levelled on the basis of the degree of formalism required of the functional specification, and the degree of detail provided for the external interfaces to the TSF. Application notes
316
The ADV_FSP.*.2E elements within this family define a requirement that the evaluator determine that the functional specification is an accurate and complete instantiation of the TOE security functional requirements. This provides a direct correspondence between the TOE security functional requirements and the functional specification, in addition to the pairwise correspondences required by the ADV_RCR family. It is expected that the evaluator will use the evidence provided in ADV_RCR as an input to making this determination, and the requirement for completeness is intended to be relative to the level of abstraction of the functional specification. For ADV_FSP.1.3C, it is intended that sufficient information is provided in the functional specification to understand how the TOE security functional requirements have been addressed, and to enable the specification of tests which reflect the TOE security functional requirements in the ST. It is not necessarily the case that such testing will cover all possible return values and error messages which could be generated at the interface, but the information provided should make clear the results of using an interface in the case of success and the most common instances of failure. ADV_FSP.2.3C introduces a requirement for a complete presentation of the functional interface. This will provide the necessary detail for supporting both thorough testing of the TOE and the assessment of vulnerabilities. In the context of the level of formality of the functional specification, informal, semiformal and formal are considered to be hierarchical in nature. Thus, ADV_FSP.1.1C and ADV_FSP.2.1C may also be met with either a semiformal or formal functional specification, provided that it is supported by informal, explanatory text where appropriate. In addition, ADV_FSP.3.1C may also be met with a formal functional specification.
317
318
319
August 1999
Version 2.1
Page 95 of 208
10 - Class ADV: Development
Functional specification (ADV_FSP)
ADV_FSP.1 Informal functional specification Dependencies: ADV_RCR.1 Informal correspondence demonstration Developer action elements:
ADV_FSP.1.1D
The developer shall provide a functional specification. Content and presentation of evidence elements:
ADV_FSP.1.1C
The functional specification shall describe the TSF and its external interfaces using an informal style. The functional specification shall be internally consistent. The functional specification shall describe the purpose and method of use of all external TSF interfaces, providing details of effects, exceptions and error messages, as appropriate. The functional specification shall completely represent the TSF. Evaluator action elements:
ADV_FSP.1.2C ADV_FSP.1.3C
ADV_FSP.1.4C
ADV_FSP.1.1E
The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall determine that the functional specification is an accurate and complete instantiation of the TOE security functional requirements.
ADV_FSP.1.2E
ADV_FSP.2 Fully defined external interfaces Dependencies: ADV_RCR.1 Informal correspondence demonstration Developer action elements:
ADV_FSP.2.1D
The developer shall provide a functional specification. Content and presentation of evidence elements:
ADV_FSP.2.1C
The functional specification shall describe the TSF and its external interfaces using an informal style. The functional specification shall be internally consistent. 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.
ADV_FSP.2.2C ADV_FSP.2.3C
Page 96 of 208
Version 2.1
August 1999
Functional specification (ADV_FSP)
10 - Class ADV: Development
ADV_FSP.2.4C ADV_FSP.2.5C
The functional specification shall completely represent the TSF. The functional specification shall include rationale that the TSF is completely represented. Evaluator action elements:
ADV_FSP.2.1E
The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall determine that the functional specification is an accurate and complete instantiation of the TOE security functional requirements.
ADV_FSP.2.2E
ADV_FSP.3 Semiformal functional specification Dependencies: ADV_RCR.1 Informal correspondence demonstration Developer action elements:
ADV_FSP.3.1D
The developer shall provide a functional specification. Content and presentation of evidence elements:
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. The functional specification shall be internally consistent. 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. The functional specification shall completely represent the TSF. The functional specification shall include rationale that the TSF is completely represented. Evaluator action elements:
ADV_FSP.3.2C ADV_FSP.3.3C
ADV_FSP.3.4C ADV_FSP.3.5C
ADV_FSP.3.1E
The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall determine that the functional specification is an accurate and complete instantiation of the TOE security functional requirements.
ADV_FSP.3.2E
August 1999
Version 2.1
Page 97 of 208
10 - Class ADV: Development
Functional specification (ADV_FSP)
ADV_FSP.4 Formal functional specification Dependencies: ADV_RCR.1 Informal correspondence demonstration Developer action elements:
ADV_FSP.4.1D
The developer shall provide a functional specification. Content and presentation of evidence elements:
ADV_FSP.4.1C
The functional specification shall describe the TSF and its external interfaces using a formal style, supported by informal, explanatory text where appropriate. The functional specification shall be internally consistent. 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. The functional specification shall completely represent the TSF. The functional specification shall include rationale that the TSF is completely represented. Evaluator action elements:
ADV_FSP.4.2C ADV_FSP.4.3C
ADV_FSP.4.4C ADV_FSP.4.5C
ADV_FSP.4.1E
The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall determine that the functional specification is an accurate and complete instantiation of the TOE security functional requirements.
ADV_FSP.4.2E
Page 98 of 208
Version 2.1
August 1999
High-level design (ADV_HLD)
10 - Class ADV: Development
10.2
ADV_HLD
High-level design (ADV_HLD)
High-level design
Objectives
320
The high-level design of a TOE provides a description of the TSF in terms of major structural units (i.e. subsystems) and relates these units to the functions that they provide. The high-level design requirements are intended to provide assurance that the TOE provides an architecture appropriate to implement the TOE security functional requirements. The high-level design refines the functional specification into subsystems. For each subsystem of the TSF, the high-level design describes its purpose and function, and identifies the security functions contained in the subsystem. The interrelationships of all subsystems are also defined in the high-level design. These interrelationships will be represented as external interfaces for data flow, control flow, etc., as appropriate. Component levelling
321
322
The components in this family are levelled on the basis of the degree of formalism required of the high-level design, and on the degree of detail required for the interface specifications. Application notes
323
The developer is expected to describe the design of the TSF in terms of subsystems. The term "subsystem" is used here to express the idea of decomposing the TSF into a relatively small number of parts. While the developer is not required to actually have "subsystems", the developer is expected to represent a similar level of decomposition. For example, a design may be similarly decomposed using "layers", "domains", or "servers". The term "security functionality" is used to represent the set of operations that a subsystem performs in contribution to security functions implemented by the TOE. This distinction is made because design constructs, such as subsystems and modules, do not necessarily relate to specific security functions. While a given subsystem may correspond directly to a security function, or even multiple security functions, it is also possible that many subsystems must be combined to implement a single security function. The term "TSP-enforcing subsystem" to refers a subsystem that contributes to the enforcement of the TSP, either directly or indirectly. The ADV_HLD.*.2E elements within this family define a requirement that the evaluator determine that the high-level design is an accurate and complete instantiation of the TOE security functional requirements. This provides a direct correspondence between the TOE security functional requirements and the highlevel design, in addition to the pairwise correspondences required by the ADV_RCR family. It is expected that the evaluator will use the evidence provided
324
325
326
August 1999
Version 2.1
Page 99 of 208
10 - Class ADV: Development
High-level design (ADV_HLD)
in ADV_RCR as an input to making this determination, and the requirement for completeness is intended to be relative to the level of abstraction of the high-level design.
327
ADV_HLD.3.8C introduces a requirement for a complete presentation for the interfaces to the subsystems. This will provide the necessary detail for supporting both thorough testing of the TOE (using components from ATE_DPT), and the assessment of vulnerabilities. In the context of the level of formality of the high-level design, informal, semiformal and formal are considered to be hierarchical in nature. Thus, ADV_HLD.1.1C and ADV_HLD.2.1C may also be met with either a semiformal or formal high-level design, and ADV_HLD.3.1C and ADV_HLD.4.1C may also be met with a formal high-level design.
328
ADV_HLD.1 Descriptive high-level design Dependencies: ADV_FSP.1 Informal functional specification ADV_RCR.1 Informal correspondence demonstration Developer action elements:
ADV_HLD.1.1D
The developer shall provide the high-level design of the TSF. Content and presentation of evidence elements:
ADV_HLD.1.1C ADV_HLD.1.2C ADV_HLD.1.3C
The presentation of the high-level design shall be informal. The high-level design shall be internally consistent. The high-level design shall describe the structure of the TSF in terms of subsystems. The high-level design shall describe the security functionality provided by each subsystem of the TSF. The high-level design shall identify any underlying hardware, firmware, and/ or software required by the TSF with a presentation of the functions provided by the supporting protection mechanisms implemented in that hardware, firmware, or software. The high-level design shall identify all interfaces to the subsystems of the TSF. The high-level design shall identify which of the interfaces to the subsystems of the TSF are externally visible.
ADV_HLD.1.4C
ADV_HLD.1.5C
ADV_HLD.1.6C ADV_HLD.1.7C
Page 100 of 208
Version 2.1
August 1999
High-level design (ADV_HLD)
10 - Class ADV: Development
Evaluator action elements:
ADV_HLD.1.1E
The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall determine that the high-level design is an accurate and complete instantiation of the TOE security functional requirements.
ADV_HLD.1.2E
ADV_HLD.2 Security enforcing high-level design Dependencies: ADV_FSP.1 Informal functional specification ADV_RCR.1 Informal correspondence demonstration Developer action elements:
ADV_HLD.2.1D
The developer shall provide the high-level design of the TSF. Content and presentation of evidence elements:
ADV_HLD.2.1C ADV_HLD.2.2C ADV_HLD.2.3C ADV_HLD.2.4C
The presentation of the high-level design shall be informal. The high-level design shall be internally consistent. The high-level design shall describe the structure of the TSF in terms of subsystems. The high-level design shall describe the security functionality provided by each subsystem of the TSF. The high-level design shall identify any underlying hardware, firmware, and/or software required by the TSF with a presentation of the functions provided by the supporting protection mechanisms implemented in that hardware, firmware, or software. The high-level design shall identify all interfaces to the subsystems of the TSF. The high-level design shall identify which of the interfaces to the subsystems of the TSF are externally visible. The high-level design shall describe the purpose and method of use of all interfaces to the subsystems of the TSF, providing details of effects, exceptions and error messages, as appropriate. The high-level design shall describe the separation of the TOE into TSPenforcing and other subsystems.
ADV_HLD.2.5C
ADV_HLD.2.6C ADV_HLD.2.7C
ADV_HLD.2.8C
ADV_HLD.2.9C
August 1999
Version 2.1
Page 101 of 208
10 - Class ADV: Development
High-level design (ADV_HLD)
Evaluator action elements:
ADV_HLD.2.1E
The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall determine that the high-level design is an accurate and complete instantiation of the TOE security functional requirements.
ADV_HLD.2.2E
ADV_HLD.3 Semiformal high-level design Dependencies: ADV_FSP.3 Semiformal functional specification ADV_RCR.2 Semiformal correspondence demonstration Developer action elements:
ADV_HLD.3.1D
The developer shall provide the high-level design of the TSF. Content and presentation of evidence elements:
ADV_HLD.3.1C ADV_HLD.3.2C ADV_HLD.3.3C ADV_HLD.3.4C
The presentation of the high-level design shall be semiformal. The high-level design shall be internally consistent. The high-level design shall describe the structure of the TSF in terms of subsystems. The high-level design shall describe the security functionality provided by each subsystem of the TSF. The high-level design shall identify any underlying hardware, firmware, and/or software required by the TSF with a presentation of the functions provided by the supporting protection mechanisms implemented in that hardware, firmware, or software. The high-level design shall identify all interfaces to the subsystems of the TSF. The high-level design shall identify which of the interfaces to the subsystems of the TSF are externally visible. The high-level design shall describe the purpose and method of use of all interfaces to the subsystems of the TSF, providing complete details of all effects, exceptions and error messages. The high-level design shall describe the separation of the TOE into TSP-enforcing and other subsystems.
ADV_HLD.3.5C
ADV_HLD.3.6C ADV_HLD.3.7C
ADV_HLD.3.8C
ADV_HLD.3.9C
Page 102 of 208
Version 2.1
August 1999
High-level design (ADV_HLD)
10 - Class ADV: Development
Evaluator action elements:
ADV_HLD.3.1E
The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall determine that the high-level design is an accurate and complete instantiation of the TOE security functional requirements.
ADV_HLD.3.2E
ADV_HLD.4 Semiformal high-level explanation Dependencies: ADV_FSP.3 Semiformal functional specification ADV_RCR.2 Semiformal correspondence demonstration Developer action elements:
ADV_HLD.4.1D
The developer shall provide the high-level design of the TSF. Content and presentation of evidence elements:
ADV_HLD.4.1C ADV_HLD.4.2C ADV_HLD.4.3C ADV_HLD.4.4C
The presentation of the high-level design shall be semiformal. The high-level design shall be internally consistent. The high-level design shall describe the structure of the TSF in terms of subsystems. The high-level design shall describe the security functionality provided by each subsystem of the TSF. The high-level design shall identify any underlying hardware, firmware, and/or software required by the TSF with a presentation of the functions provided by the supporting protection mechanisms implemented in that hardware, firmware, or software. The high-level design shall identify all interfaces to the subsystems of the TSF. The high-level design shall identify which of the interfaces to the subsystems of the TSF are externally visible. The high-level design shall describe the purpose and method of use of all interfaces to the subsystems of the TSF, providing complete details of all effects, exceptions and error messages. The high-level design shall describe the separation of the TOE into TSP-enforcing and other subsystems. The high-level design shall justify that the identified means of achieving separation, including any protection mechanisms, are sufficient to ensure a
ADV_HLD.4.5C
ADV_HLD.4.6C ADV_HLD.4.7C
ADV_HLD.4.8C
ADV_HLD.4.9C
ADV_HLD.4.10C
August 1999
Version 2.1
Page 103 of 208
10 - Class ADV: Development
High-level design (ADV_HLD)
clear and effective separation of TSP-enforcing from non-TSP-enforcing functions.
ADV_HLD.4.11C
The high-level design shall justify that the TSF mechanisms are sufficient to implement the security functions identified in the high-level design. Evaluator action elements:
ADV_HLD.4.1E
The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall determine that the high-level design is an accurate and complete instantiation of the TOE security functional requirements.
ADV_HLD.4.2E
ADV_HLD.5 Formal high-level design Dependencies: ADV_FSP.4 Formal functional specification ADV_RCR.3 Formal correspondence demonstration Developer action elements:
ADV_HLD.5.1D
The developer shall provide the high-level design of the TSF. Content and presentation of evidence elements:
ADV_HLD.5.1C ADV_HLD.5.2C ADV_HLD.5.3C ADV_HLD.5.4C
The presentation of the high-level design shall be formal. The high-level design shall be internally consistent. The high-level design shall describe the structure of the TSF in terms of subsystems. The high-level design shall describe the security functionality provided by each subsystem of the TSF. The high-level design shall identify any underlying hardware, firmware, and/or software required by the TSF with a presentation of the functions provided by the supporting protection mechanisms implemented in that hardware, firmware, or software. The high-level design shall identify all interfaces to the subsystems of the TSF. The high-level design shall identify which of the interfaces to the subsystems of the TSF are externally visible. The high-level design shall describe the purpose and method of use of all interfaces to the subsystems of the TSF, providing complete details of all effects, exceptions and error messages.
ADV_HLD.5.5C
ADV_HLD.5.6C ADV_HLD.5.7C
ADV_HLD.5.8C
Page 104 of 208
Version 2.1
August 1999
High-level design (ADV_HLD)
10 - Class ADV: Development
ADV_HLD.5.9C
The high-level design shall describe the separation of the TOE into TSP-enforcing and other subsystems. The high-level design shall justify that the identified means of achieving separation, including any protection mechanisms, are sufficient to ensure a clear and effective separation of TSP-enforcing from non-TSP-enforcing functions. The high-level design shall justify that the TSF mechanisms are sufficient to implement the security functions identified in the high-level design. Evaluator action elements:
ADV_HLD.5.10C
ADV_HLD.5.11C
ADV_HLD.5.1E
The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall determine that the high-level design is an accurate and complete instantiation of the TOE security functional requirements.
ADV_HLD.5.2E
August 1999
Version 2.1
Page 105 of 208
10 - Class ADV: Development
Implementation representation (ADV_IMP)
10.3
ADV_IMP
Implementation representation (ADV_IMP)
Implementation representation
Objectives
329
The description of the implementation representation in the form of source code, firmware, hardware drawings, etc. captures the detailed internal workings of the TSF in support of analysis. Component levelling
330
The components in this family are levelled on the basis of the completeness and structure of the implementation representation provided. Application notes
331
The implementation representation is used to express the notion of the least abstract representation of the TSF, specifically the one that is used to create the TSF itself without further design refinement. Source code that is then compiled or a hardware drawing that is used to build the actual hardware are examples of parts of an implementation representation. It is possible that evaluators may use the implementation representation to directly support other evaluation activities (e.g. vulnerability analysis, test coverage analysis, or identification of additional evaluator tests). It is expected that PP/ST authors will select a component that requires that the implementation is complete and comprehensive enough to address the needs of all other requirements included in the PP/ST.
332
ADV_IMP.1 Subset of the implementation of the TSF Application notes
333
ADV_IMP.1.1D requires that the developer provide the implementation representation for a subset of the TSF. The intention is that access to at least a portion of the TSF will provide the evaluator with an opportunity to examine the implementation representation for those portions of the TOE where such an examination can add significantly to the understanding of, and assurance in, the mechanisms employed. Provision of a sample of the implementation representation will also allow the evaluator to sample the traceability evidence to gain assurance in the approach taken for refinement, and to assess the presentation of the implementation representation itself. ADV_IMP.1.2E element defines a requirement that the evaluator determine that the least abstract TSF representation is an accurate and complete instantiation of the TOE security functional requirements. This provides a direct correspondence between the TOE security functional requirements and the least abstract TSF representation, in addition to the pairwise correspondences required by the ADV_RCR family. It is expected that the evaluator will use the evidence provided in ADV_RCR as an input to making this determination. The least abstract TSF
334
Page 106 of 208
Version 2.1
August 1999
Implementation representation (ADV_IMP)
10 - Class ADV: Development
representation for this component is an aggregate of the implementation representation that is provided and that portion of the low-level design for which no corresponding implementation representation is provided. Dependencies: ADV_LLD.1 Descriptive low-level design ADV_RCR.1 Informal correspondence demonstration ALC_TAT.1 Well-defined development tools Developer action elements:
ADV_IMP.1.1D
The developer shall provide the implementation representation for a selected subset of the TSF. Content and presentation of evidence elements:
ADV_IMP.1.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. The implementation representation shall be internally consistent. Evaluator action elements:
ADV_IMP.1.2C
ADV_IMP.1.1E
The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall determine that the least abstract TSF representation provided is an accurate and complete instantiation of the TOE security functional requirements.
ADV_IMP.1.2E
ADV_IMP.2 Implementation of the TSF Application notes
335
The ADV_IMP.2.2E element defines a requirement that the evaluator determine that the implementation representation is an accurate and complete instantiation of the TOE security functional requirements. This provides a direct correspondence between the TOE security functional requirements and the implementation representation, in addition to the pairwise correspondences required by the ADV_RCR family. It is expected that the evaluator will use the evidence provided in ADV_RCR as an input to making this determination. Dependencies: ADV_LLD.1 Descriptive low-level design ADV_RCR.1 Informal correspondence demonstration ALC_TAT.1 Well-defined development tools
August 1999
Version 2.1
Page 107 of 208
10 - Class ADV: Development
Implementation representation (ADV_IMP)
Developer action elements:
ADV_IMP.2.1D
The developer shall provide the implementation representation for the entire TSF. Content and presentation of evidence elements:
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. The implementation representation shall be internally consistent. The implementation representation shall describe the relationships between all portions of the implementation. Evaluator action elements:
ADV_IMP.2.2C ADV_IMP.2.3C
ADV_IMP.2.1E
The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall determine that the implementation representation is an accurate and complete instantiation of the TOE security functional requirements.
ADV_IMP.2.2E
ADV_IMP.3 Structured implementation of the TSF Application notes
336
The ADV_IMP.3.2E element defines a requirement that the evaluator determine that the implementation representation is an accurate and complete instantiation of the TOE security functional requirements. This provides a direct correspondence between the TOE security functional requirements and the implementation representation, in addition to the pairwise correspondences required by the ADV_RCR family. It is expected that the evaluator will use the evidence provided in ADV_RCR as an input to making this determination. Dependencies: ADV_INT.1 Modularity ADV_LLD.1 Descriptive low-level design ADV_RCR.1 Informal correspondence demonstration ALC_TAT.1 Well-defined development tools Developer action elements:
ADV_IMP.3.1D
The developer shall provide the implementation representation for the entire TSF. Content and presentation of evidence elements:
ADV_IMP.3.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.
Page 108 of 208
Version 2.1
August 1999
Implementation representation (ADV_IMP)
10 - Class ADV: Development
ADV_IMP.3.2C ADV_IMP.3.3C
The implementation representation shall be internally consistent. The implementation representation shall describe the relationships between all portions of the implementation. The implementation representation shall be structured into small and comprehensible sections. Evaluator action elements:
ADV_IMP.3.4C
ADV_IMP.3.1E
The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall determine that the implementation representation is an accurate and complete instantiation of the TOE security functional requirements.
ADV_IMP.3.2E
August 1999
Version 2.1
Page 109 of 208
10 - Class ADV: Development
TSF internals (ADV_INT)
10.4
ADV_INT
TSF internals (ADV_INT)
TSF internals
Objectives
337
This family addresses the internal structure of the TSF. Requirements are presented for modularity, layering (to separate levels of abstraction and minimise circular dependencies), minimisation of the complexity of policy enforcement mechanisms, and the minimisation of the amount of non-TSP-enforcing functionality within the TSF -- thus resulting in a TSF that is simple enough to be analysed. Modular design reduces the interdependence between elements of the TSF and thus reduces the risk that a change or error in one module will have effects throughout the TOE. Thus, a modular design provides the basis for determining the scope of interaction with other elements of the TSF, provides for increased assurance that unexpected effects do not occur, and also provides the basis for designing and evaluating test suites. The use of layering and of simpler designs for the TSP-enforcing functionality reduces the complexity of the TSF. This in turn enables a better understanding of the TSF, providing more assurance that the TOE security functional requirements are accurately and completely instantiated in the implementation. Minimising the amount of functionality in the TSF that does not enforce the TSP, reduces the possibility of flaws in the TSF. In combination with modularity and layering, it allows the evaluator to focus only on that functionality which is necessary for TSP enforcement. Design complexity minimisation contributes to the assurance that the code is understood -- the less complex the code in the TSF, the greater the likelihood that the design of the TSF is comprehensible. Design complexity minimisation is a key characteristic of a reference validation mechanism. Component levelling
338
339
340
341
342
The components in this family are levelled on the basis of the amount of structure and minimisation required. Application notes
343
The term "portions of the TSF" is used to represent parts of the TSF with a varying granularity based on the available TSF representations. The functional specification allows identification in terms of interfaces, the high-level design allows identification in terms of subsystems, the low-level design allows identification in terms of modules, and the implementation representation allows identification in terms of implementation units. The ADV_INT.2.5C and ADV_INT.3.5C elements address minimisation of mutual interactions between layers. Nevertheless, it is still permissible to have mutual interactions between layers, but in such cases the developer is required to
344
Page 110 of 208
Version 2.1
August 1999
TSF internals (ADV_INT)
10 - Class ADV: Development
demonstrate that these mutual interactions are necessary and cannot reasonably be avoided.
345
ADV_INT.2.6C introduces a reference monitor concept by requiring the minimisation of complexity of the portions of the TSF that enforce the access control and/or information flow control policies identified in the TSP. ADV_INT.3.6C further develops the reference monitor concept by requiring minimisation of the complexity of the entire TSF. Several of the elements within the components for this family refer to the architectural description. 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. Whereas the low-level design describes the design of the modules of the TSF, the purpose of the architectural description is to provide evidence of modularity, layering, and minimisation of complexity of the TSF, as applicable. Both the lowlevel design and the implementation representation are required to be in compliance with the architectural description, to provide assurance that these TSF representations possess the required modularity, layering, and minimisation of complexity.
346
ADV_INT.1 Modularity Dependencies: ADV_IMP.1 Subset of the implementation of the TSF ADV_LLD.1 Descriptive low-level design Developer action elements:
ADV_INT.1.1D
The developer shall design and structure the TSF in a modular fashion that avoids unnecessary interactions between the modules of the design. The developer shall provide an architectural description. Content and presentation of evidence elements:
ADV_INT.1.2D
ADV_INT.1.1C ADV_INT.1.2C
The architectural description shall identify the modules of the TSF. The architectural description shall describe the purpose, interface, parameters, and effects of each module of the TSF. The architectural description shall describe how the TSF design provides for largely independent modules that avoid unnecessary interactions. Evaluator action elements:
ADV_INT.1.3C
ADV_INT.1.1E
The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
August 1999
Version 2.1
Page 111 of 208
10 - Class ADV: Development
TSF internals (ADV_INT)
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.2 Reduction of complexity Application notes
347
This component introduces a reference monitor concept by requiring the minimisation of complexity of the portions of the TSF that enforce the access control and/or information flow control policies identified in the TSP. Dependencies: ADV_IMP.1 Subset of the implementation of the TSF ADV_LLD.1 Descriptive low-level design Developer action elements:
ADV_INT.2.1D
The developer shall design and structure the TSF in a modular fashion that avoids unnecessary interactions between the modules of the design. The developer shall provide an architectural description. The developer shall design and structure the TSF in a layered fashion that minimises mutual interactions between the layers of the design. The developer shall design and structure the TSF in such a way that minimises the complexity of the portions of the TSF that enforce any access control and/ or information flow control policies. Content and presentation of evidence elements:
ADV_INT.2.2D ADV_INT.2.3D
ADV_INT.2.4D
ADV_INT.2.1C
The architectural description shall identify the modules of the TSF and shall specify which portions of the TSF enforce the access control and/or information flow control policies. The architectural description shall describe the purpose, interface, parameters, and effects of each module of the TSF. The architectural description shall describe how the TSF design provides for largely independent modules that avoid unnecessary interactions. The architectural description shall describe the layering architecture. The architectural description shall show that mutual interactions have been minimised, and justify those that remain.
ADV_INT.2.2C
ADV_INT.2.3C
ADV_INT.2.4C ADV_INT.2.5C
Page 112 of 208
Version 2.1
August 1999
TSF internals (ADV_INT)
10 - Class ADV: Development
ADV_INT.2.6C
The architectural description shall describe how the portions of the TSF that enforce any access control and/or information flow control policies have been structured to minimise complexity. Evaluator action elements:
ADV_INT.2.1E
The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall determine that both the low-level design and the implementation representation are in compliance with the architectural description.
ADV_INT.2.2E
ADV_INT.3 Minimisation of complexity Application notes
348
This component requires that the reference monitor property "simple enough to be analysed" is fully addressed. When this component is combined with the functional requirements FPT_RVM.1 and FPT_SEP.3, the reference monitor concept would be fully realised. Dependencies: ADV_IMP.2 Implementation of the TSF ADV_LLD.1 Descriptive low-level design Developer action elements:
ADV_INT.3.1D
The developer shall design and structure the TSF in a modular fashion that avoids unnecessary interactions between the modules of the design. The developer shall provide an architectural description. The developer shall design and structure the TSF in a layered fashion that minimises mutual interactions between the layers of the design. The developer shall design and structure the TSF in such a way that minimises the complexity of the entire TSF. The developer shall design and structure the portions of the TSF that enforce any access control and/or information flow control policies such that they are simple enough to be analysed. The developer shall ensure that functions whose objectives are not relevant for the TSF are excluded from the TSF modules.
ADV_INT.3.2D ADV_INT.3.3D
ADV_INT.3.4D
ADV_INT.3.5D
ADV_INT.3.6D
August 1999
Version 2.1
Page 113 of 208
10 - Class ADV: Development
TSF internals (ADV_INT)
Content and presentation of evidence elements:
ADV_INT.3.1C
The architectural description shall identify the modules of the TSF and shall specify which portions of the TSF enforce the access control and/or information flow control policies. The architectural description shall describe the purpose, interface, parameters, and side-effects of each module of the TSF. The architectural description shall describe how the TSF design provides for largely independent modules that avoid unnecessary interactions. The architectural description shall describe the layering architecture. The architectural description shall show that mutual interactions have been minimised, and justify those that remain. The architectural description shall describe how the entire TSF has been structured to minimise complexity. The architectural description shall justify the inclusion of any non-TSPenforcing modules in the TSF. Evaluator action elements:
ADV_INT.3.2C
ADV_INT.3.3C
ADV_INT.3.4C ADV_INT.3.5C
ADV_INT.3.6C
ADV_INT.3.7C
ADV_INT.3.1E
The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall determine that both the low-level design and the implementation representation are in compliance with the architectural description. The evaluator shall confirm that the portions of the TSF that enforce any access control and/or information flow control policies are simple enough to be analysed.
ADV_INT.3.2E
ADV_INT.3.3E
Page 114 of 208
Version 2.1
August 1999
Low-level design (ADV_LLD)
10 - Class ADV: Development
10.5
ADV_LLD
Low-level design (ADV_LLD)
Low-level design
Objectives
349
The low-level design of a TOE provides a description of the internal workings of the TSF in terms of modules and their interrelationships and dependencies. The low-level design provides assurance that the TSF subsystems have been correctly and effectively refined. For each module of the TSF, the low-level design describes its purpose, function, interfaces, dependencies, and the implementation of any TSP-enforcing functions. Component levelling
350
351
The components in this family are levelled on the basis of the degree of formalism required of the low-level design, and on the degree of detail required for the interface specifications. Application notes
352
The term "TSP-enforcing module" refers to any module that must be relied upon for correct enforcement of the TSP. The term "security functionality" is used to represent the set of operations that a module performs in contribution to security functions implemented by the TOE. This distinction is made because modules do not necessarily relate to specific security functions. While a given module may correspond directly to a security function, or even multiple security functions, it is also possible that many modules must be combined to implement a single security function. The ADV_LLD.*.6C elements require that the low-level design describe how each TSP-enforcing function is provided. The intent of this requirement is that the lowlevel design provide a description of how each module is expected to be implemented from a design perspective. The ADV_LLD.*.2E elements within this family define a requirement that the evaluator determine that the low-level design is an accurate and complete instantiation of the TOE security functional requirements. This provides a direct correspondence between the TOE security functional requirements and the lowlevel design, in addition to the pairwise correspondences required by the ADV_RCR family. It is expected that the evaluator will use the evidence provided in ADV_RCR as an input to making this determination, and the requirement for completeness is intended to be relative to the level of abstraction of the low-level design. ADV_LLD.2.9C introduces a requirement for a complete presentation for the interfaces to the modules. This will provide the necessary detail for supporting both thorough testing of the TOE (using components from ATE_DPT), and the assessment of vulnerabilities.
353
354
355
356
August 1999
Version 2.1
Page 115 of 208
10 - Class ADV: Development
Low-level design (ADV_LLD)
357
In the context of the level of formality of the low-level design, informal, semiformal and formal are considered to be hierarchical in nature. Thus, ADV_LLD.1.1C may also be met with either a semiformal or formal low-level design, and ADV_LLD.2.1C may also be met with a formal low-level design.
ADV_LLD.1 Descriptive low-level design Dependencies: ADV_HLD.2 Security enforcing high-level design ADV_RCR.1 Informal correspondence demonstration Developer action elements:
ADV_LLD.1.1D
The developer shall provide the low-level design of the TSF. Content and presentation of evidence elements:
ADV_LLD.1.1C ADV_LLD.1.2C ADV_LLD.1.3C ADV_LLD.1.4C ADV_LLD.1.5C
The presentation of the low-level design shall be informal. The low-level design shall be internally consistent. The low-level design shall describe the TSF in terms of modules. The low-level design shall describe the purpose of each module. The low-level design shall define the interrelationships between the modules in terms of provided security functionality and dependencies on other modules. The low-level design shall describe how each TSP-enforcing function is provided. The low-level design shall identify all interfaces to the modules of the TSF. The low-level design shall identify which of the interfaces to the modules of the TSF are externally visible. The low-level design shall describe the purpose and method of use of all interfaces to the modules of the TSF, providing details of effects, exceptions and error messages, as appropriate. The low-level design shall describe the separation of the TOE into TSPenforcing and other modules. Evaluator action elements:
ADV_LLD.1.6C
ADV_LLD.1.7C ADV_LLD.1.8C
ADV_LLD.1.9C
ADV_LLD.1.10C
ADV_LLD.1.1E
The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
Page 116 of 208
Version 2.1
August 1999
Low-level design (ADV_LLD)
10 - Class ADV: Development
ADV_LLD.1.2E
The evaluator shall determine that the low-level design is an accurate and complete instantiation of the TOE security functional requirements.
ADV_LLD.2 Semiformal low-level design Dependencies: ADV_HLD.3 Semiformal high-level design ADV_RCR.2 Semiformal correspondence demonstration Developer action elements:
ADV_LLD.2.1D
The developer shall provide the low-level design of the TSF. Content and presentation of evidence elements:
ADV_LLD.2.1C ADV_LLD.2.2C ADV_LLD.2.3C ADV_LLD.2.4C ADV_LLD.2.5C
The presentation of the low-level design shall be semiformal. The low-level design shall be internally consistent. The low-level design shall describe the TSF in terms of modules. The low-level design shall describe the purpose of each module. The low-level design shall define the interrelationships between the modules in terms of provided security functionality and dependencies on other modules. The low-level design shall describe how each TSP-enforcing function is provided. The low-level design shall identify all interfaces to the modules of the TSF. The low-level design shall identify which of the interfaces to the modules of the TSF are externally visible. The low-level design shall describe the purpose and method of use of all interfaces to the modules of the TSF, providing complete details of all effects, exceptions and error messages. The low-level design shall describe the separation of the TOE into TSP-enforcing and other modules. Evaluator action elements:
ADV_LLD.2.6C ADV_LLD.2.7C ADV_LLD.2.8C
ADV_LLD.2.9C
ADV_LLD.2.10C
ADV_LLD.2.1E
The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall determine that the low-level design is an accurate and complete instantiation of the TOE security functional requirements.
ADV_LLD.2.2E
August 1999
Version 2.1
Page 117 of 208
10 - Class ADV: Development
Low-level design (ADV_LLD)
ADV_LLD.3 Formal low-level design Dependencies: ADV_HLD.5 Formal high-level design ADV_RCR.3 Formal correspondence demonstration Developer action elements:
ADV_LLD.3.1D
The developer shall provide the low-level design of the TSF. Content and presentation of evidence elements:
ADV_LLD.3.1C ADV_LLD.3.2C ADV_LLD.3.3C ADV_LLD.3.4C ADV_LLD.3.5C
The presentation of the low-level design shall be formal. The low-level design shall be internally consistent. The low-level design shall describe the TSF in terms of modules. The low-level design shall describe the purpose of each module. The low-level design shall define the interrelationships between the modules in terms of provided security functionality and dependencies on other modules. The low-level design shall describe how each TSP-enforcing function is provided. The low-level design shall identify all interfaces to the modules of the TSF. The low-level design shall identify which of the interfaces to the modules of the TSF are externally visible. The low-level design shall describe the purpose and method of use of all interfaces to the modules of the TSF, providing complete details of all effects, exceptions and error messages. The low-level design shall describe the separation of the TOE into TSP-enforcing and other modules. Evaluator action elements:
ADV_LLD.3.6C ADV_LLD.3.7C ADV_LLD.3.8C
ADV_LLD.3.9C
ADV_LLD.3.10C
ADV_LLD.3.1E
The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall determine that the low-level design is an accurate and complete instantiation of the TOE security functional requirements.
ADV_LLD.3.2E
Page 118 of 208
Version 2.1
August 1999
Representation correspondence (ADV_RCR)
10 - Class ADV: Development
10.6
ADV_RCR
Representation correspondence (ADV_RCR)
Representation correspondence
Objectives
358
The correspondence between the various TSF representations (i.e. TOE summary specification, functional specification, high-level design, low-level design, implementation representation) addresses the correct and complete instantiation of the requirements to the least abstract TSF representation provided. This conclusion is achieved by step-wise refinement and the cumulative results of correspondence determinations between all adjacent abstractions of representation. Component levelling
359
The components in this family are levelled on the basis of the required level of formality of the correspondence between the various TSF representations. Application notes
360
The developer must demonstrate to the evaluator that the most detailed, or least abstract, TSF representation provided is an accurate, consistent, and complete instantiation of the functions expressed as functional requirements in the ST. This is accomplished by showing correspondence between adjacent representations at a commensurate level of rigour. This family of requirements is not intended to address correspondence relating to the TSP model or the TSP. Rather, as shown in Figure 10.2, it is intended to address correspondence between various TSF representations (i.e. the TOE summary specification, functional specification, high-level design, low-level design, and implementation representation) that are provided. The ADV_RCR.*.1C elements refer to "all relevant security functionality" in defining the scope of what must be refined between an adjacent pair of TSF representations. For the refinements between the TOE summary specification and the functional specification, this element requires only that the TOE security functions in the TOE summary specification be refined in the functional specification, and does not require that the functional specification contain any details regarding assurance measures (which are presented in the TOE summary specification). Where the implementation representation is only provided for a subset of the TSF (as in ADV_IMP.1), the required refinements between the lowlevel design and the implementation representation are limited to the security functionality that is presented in the implementation representation. In all other cases, this element requires that all parts of the more abstract TSF representation be refined in the less abstract TSF representation. In the context of the level of formality for correspondence between adjacent TSF representations, informal, semiformal and formal are considered to be hierarchical in nature. Thus, ADV_RCR.2.2C and ADV_RCR.3.2C may be met with a formal proof of correspondence, and in the absence of any requirements on its level of
361
362
363
August 1999
Version 2.1
Page 119 of 208
10 - Class ADV: Development
Representation correspondence (ADV_RCR)
formality, a demonstration of correspondence may be informal, semiformal or formal. ADV_RCR.1 Informal correspondence demonstration Dependencies: No dependencies. Developer action elements:
ADV_RCR.1.1D
The developer shall provide an analysis of correspondence between all adjacent pairs of TSF representations that are provided. Content and presentation of evidence elements:
ADV_RCR.1.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. Evaluator action elements:
ADV_RCR.1.1E
The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
ADV_RCR.2 Semiformal correspondence demonstration Dependencies: No dependencies. Developer action elements:
ADV_RCR.2.1D
The developer shall provide an analysis of correspondence between all adjacent pairs of TSF representations that are provided. Content and presentation of evidence elements:
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. For each adjacent pair of provided TSF representations, where portions of both representations are at least semiformally specified, the demonstration of correspondence between those portions of the representations shall be semiformal.
ADV_RCR.2.2C
Page 120 of 208
Version 2.1
August 1999
Representation correspondence (ADV_RCR)
10 - Class ADV: Development
Evaluator action elements:
ADV_RCR.2.1E
The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
ADV_RCR.3 Formal correspondence demonstration Application notes
364
The developer must either demonstrate or prove correspondence, as described in the requirements below, commensurate with the level of rigour of presentation style. For example, correspondence must be proven when corresponding representations are formally specified. Dependencies: No dependencies. Developer action elements:
ADV_RCR.3.1D
The developer shall provide an analysis of correspondence between all adjacent pairs of TSF representations that are provided. For those corresponding portions of representations that are formally specified, the developer shall prove that correspondence. Content and presentation of evidence elements:
ADV_RCR.3.2D
ADV_RCR.3.1C
For each adjacent pair of provided TSF representations, the analysis shall prove or demonstrate that all relevant security functionality of the more abstract TSF representation is correctly and completely refined in the less abstract TSF representation. For each adjacent pair of provided TSF representations, where portions of one representation are semiformally specified and the other at least semiformally specified, the demonstration of correspondence between those portions of the representations shall be semiformal. For each adjacent pair of provided TSF representations, where portions of both representations are formally specified, the proof of correspondence between those portions of the representations shall be formal. Evaluator action elements:
ADV_RCR.3.2C
ADV_RCR.3.3C
ADV_RCR.3.1E
The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall determine the accuracy of the proofs of correspondence by selectively verifying the formal analysis.
ADV_RCR.3.2E
August 1999
Version 2.1
Page 121 of 208
10 - Class ADV: Development
Security policy modeling (ADV_SPM)
10.7
ADV_SPM
Security policy modeling (ADV_SPM)
Security policy modeling
Objectives
365
It is the objective of this family to provide additional assurance that the security functions in the functional specification enforce the policies in the TSP. This is accomplished via the development of a security policy model that is based on a subset of the policies of the TSP, and establishing a correspondence between the functional specification, the security policy model, and these policies of the TSP. Component levelling
366
The components in this family are levelled on the basis of the degree of formality required of the TSP model, and the degree of formality required of the correspondence between the TSP model and the functional specification. Application notes
367
While a TSP may include any policies, TSP models have traditionally represented only subsets of those policies, because modeling certain policies is currently beyond the state of the art. The current state of the art determines the policies that can be modeled, and the PP/ST author should identify specific functions and associated policies that can, and thus are required to be, modeled. At the very least, access control and information flow control policies are required to be modeled (if they are part of the TSP) since they are within the state of the art. For each of the components within this family, there is a requirement to describe the rules and characteristics of applicable policies of the TSP in the TSP model and to ensure that the TSP model satisfies the corresponding policies of the TSP. The "rules" and "characteristics" of a TSP model are intended to allow flexibility in the type of model that may be developed (e.g. state transition, non-interference). For example, rules may be represented as "properties" (e.g. simple security property) and characteristics may be represented as definitions such as "initial state", "secure state", "subjects" and "objects". In the context of the level of formality of the TSP model and the correspondence between the TSP model and the functional specification, informal, semiformal and formal are considered to be hierarchical in nature. Thus, ADV_SPM.1.1C may also be met with either a semiformal or formal TSP model, and ADV_SPM.2.1C may also be met with a formal TSP model. Furthermore, ADV_SPM.2.5C and ADV_SPM.3.5C may be met with a formal proof of correspondence. Finally, in the absence of any requirements on its level of formality, a demonstration of correspondence may be informal, semiformal or formal.
368
369
ADV_SPM.1 Informal TOE security policy model Dependencies: ADV_FSP.1 Informal functional specification
Page 122 of 208
Version 2.1
August 1999
Security policy modeling (ADV_SPM)
10 - Class ADV: Development
Developer action elements:
ADV_SPM.1.1D ADV_SPM.1.2D
The developer shall provide a TSP model. The developer shall demonstrate correspondence between the functional specification and the TSP model. Content and presentation of evidence elements:
ADV_SPM.1.1C ADV_SPM.1.2C
The TSP model shall be informal. The TSP model shall describe the rules and characteristics of all policies of the TSP that can be modeled. 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 modeled. 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. Evaluator action elements:
ADV_SPM.1.3C
ADV_SPM.1.4C
ADV_SPM.1.1E
The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
ADV_SPM.2 Semiformal TOE security policy model Dependencies: ADV_FSP.1 Informal functional specification Developer action elements:
ADV_SPM.2.1D ADV_SPM.2.2D
The developer shall provide a TSP model. The developer shall demonstrate correspondence between the functional specification and the TSP model. Content and presentation of evidence elements:
ADV_SPM.2.1C ADV_SPM.2.2C
The TSP model shall be semiformal. The TSP model shall describe the rules and characteristics of all policies of the TSP that can be modeled. 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 modeled.
ADV_SPM.2.3C
August 1999
Version 2.1
Page 123 of 208
10 - Class ADV: Development
Security policy modeling (ADV_SPM)
ADV_SPM.2.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. Where the functional specification is at least semiformal, the demonstration of correspondence between the TSP model and the functional specification shall be semiformal. Evaluator action elements:
ADV_SPM.2.5C
ADV_SPM.2.1E
The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
ADV_SPM.3 Formal TOE security policy model Dependencies: ADV_FSP.1 Informal functional specification Developer action elements:
ADV_SPM.3.1D ADV_SPM.3.2D
The developer shall provide a TSP model. The developer shall demonstrate or prove, as appropriate, correspondence between the functional specification and the TSP model. Content and presentation of evidence elements:
ADV_SPM.3.1C ADV_SPM.3.2C
The TSP model shall be formal. The TSP model shall describe the rules and characteristics of all policies of the TSP that can be modeled. 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 modeled. 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. Where the functional specification is semiformal, the demonstration of correspondence between the TSP model and the functional specification shall be semiformal. Where the functional specification is formal, the proof of correspondence between the TSP model and the functional specification shall be formal.
ADV_SPM.3.3C
ADV_SPM.3.4C
ADV_SPM.3.5C
ADV_SPM.3.6C
Page 124 of 208
Version 2.1
August 1999
Security policy modeling (ADV_SPM)
10 - Class ADV: Development
Evaluator action elements:
ADV_SPM.3.1E
The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
August 1999
Version 2.1
Page 125 of 208
10 - Class ADV: Development
Security policy modeling (ADV_SPM)
Page 126 of 208
Version 2.1
August 1999
Part 3: Security assurance requirements 132
11
370
Class AGD: Guidance documents
The guidance documents class provides the requirements for user and administrator guidance documentation. For the secure administration and use of the TOE it is necessary to describe all relevant aspects for the secure application of the TOE. Figure 11.1 shows the families within this class, and the hierarchy of components within the families.
371
Class AGD: Guidance documents AGD_ADM Administrator guidance AGD_USR User guidance 1 1
Figure 11.1 - Guidance documents class decomposition
August 1999
Version 2.1
Page 127 of 208
11 - Class AGD: Guidance documents
Part 3: Security assurance requirements
11.1
AGD_ADM
Administrator guidance (AGD_ADM)
Administrator guidance
Objectives
372
Administrator guidance refers to written material that is intended to be used by those persons responsible for configuring, maintaining, and administering the TOE in a correct manner for maximum security. Because the secure operation of the TOE is dependent upon the correct performance of the TSF, persons responsible for performing these functions are trusted by the TSF. Administrator guidance is intended to help administrators understand the security functions provided by the TOE, including both those functions that require the administrator to perform security-critical actions and those functions that provide security-critical information. Component levelling
373
This family contains only one component. Application notes
374
The requirements AGD_ADM.1.3C and AGD_ADM.1.7C encompass the aspect that any warnings to the users of a TOE with regard to the TOE security environment and the security objectives described in the PP/ST are appropriately covered in the administrator guidance. The concept of secure values, as employed in AGD_ADM.1.5C, has relevance where an administrator has control over security parameters. Guidance needs to be provided on secure and insecure settings for such parameters. This concept is related to the use of the component FMT_MSA.2 from CC Part 2.
375
AGD_ADM.1 Administrator guidance Dependencies: ADV_FSP.1 Informal functional specification Developer action elements:
AGD_ADM.1.1D
The developer shall provide administrator guidance addressed to system administrative personnel. Content and presentation of evidence elements:
AGD_ADM.1.1C
The administrator guidance shall describe the administrative functions and interfaces available to the administrator of the TOE. The administrator guidance shall describe how to administer the TOE in a secure manner.
AGD_ADM.1.2C
Page 128 of 208
Version 2.1
August 1999
Part 3: Security assurance requirements
11 - Class AGD: Guidance documents
AGD_ADM.1.3C
The administrator guidance shall contain warnings about functions and privileges that should be controlled in a secure processing environment. The administrator guidance shall describe all assumptions regarding user behaviour that are relevant to secure operation of the TOE. The administrator guidance shall describe all security parameters under the control of the administrator, indicating secure values as appropriate. The administrator guidance shall describe each type of security-relevant event relative to the administrative functions that need to be performed, including changing the security characteristics of entities under the control of the TSF. The administrator guidance shall be consistent with all other documentation supplied for evaluation. The administrator guidance shall describe all security requirements for the IT environment that are relevant to the administrator. Evaluator action elements:
AGD_ADM.1.4C
AGD_ADM.1.5C
AGD_ADM.1.6C
AGD_ADM.1.7C
AGD_ADM.1.8C
AGD_ADM.1.1E
The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
August 1999
Version 2.1
Page 129 of 208
11 - Class AGD: Guidance documents
Part 3: Security assurance requirements
11.2
AGD_USR
User guidance (AGD_USR)
User guidance
Objectives
376
User guidance refers to material that is intended to be used by non-administrative human users of the TOE, and by others (e.g. programmers) using the TOE's external interfaces. User guidance describes the security functions provided by the TSF and provides instructions and guidelines, including warnings, for its secure use. The user guidance provides a basis for assumptions about the use of the TOE and a measure of confidence that non-malicious users, application providers and others exercising the external interfaces of the TOE will understand the secure operation of the TOE and will use it as intended. Component levelling
377
378
This family contains only one component. Application notes
379
The requirements AGD_USR.1.3.C and AGD_USR.1.5C encompass the aspect that any warnings to the users of a TOE with regard to the TOE security environment and the security objectives described in the PP/ST are appropriately covered in the user guidance. In many cases it may be appropriate that guidance is provided in separate documents: one for human users, and one for application programmers and/or hardware designers using software or hardware interfaces.
380
AGD_USR.1 User guidance Dependencies: ADV_FSP.1 Informal functional specification Developer action elements:
AGD_USR.1.1D
The developer shall provide user guidance. Content and presentation of evidence elements:
AGD_USR.1.1C
The user guidance shall describe the functions and interfaces available to the non-administrative users of the TOE. The user guidance shall describe the use of user-accessible security functions provided by the TOE. The user guidance shall contain warnings about user-accessible functions and privileges that should be controlled in a secure processing environment.
AGD_USR.1.2C
AGD_USR.1.3C
Page 130 of 208
Version 2.1
August 1999
Part 3: Security assurance requirements
11 - Class AGD: Guidance documents
AGD_USR.1.4C
The user guidance shall clearly present all user responsibilities necessary for secure operation of the TOE, including those related to assumptions regarding user behaviour found in the statement of TOE security environment. The user guidance shall be consistent with all other documentation supplied for evaluation. The user guidance shall describe all security requirements for the IT environment that are relevant to the user. Evaluator action elements:
AGD_USR.1.5C
AGD_USR.1.6C
AGD_USR.1.1E
The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
August 1999
Version 2.1
Page 131 of 208
11 - Class AGD: Guidance documents
Part 3: Security assurance requirements
Page 132 of 208
Version 2.1
August 1999
Part 3: Security assurance requirements 146
12
381
Class ALC: Life cycle support
Life-cycle support is an aspect of establishing discipline and control in the processes of refinement of the TOE during its development and maintenance. Confidence in the correspondence between the TOE security requirements and the TOE is greater if security analysis and the production of the evidence are done on a regular basis as an integral part of the development and maintenance activities. Figure 12.1 shows the families within this class, and the hierarchy of components within the families.
382
Class ALC: Life cycle support ALC_DVS Development security ALC_FLR Flaw remediation ALC_LCD Life cycle definition ALC_TAT Tools and techniques 1 1 1 1 2 2 2 2 3 3 3
Figure 12.1 -Life-cycle support class decomposition
August 1999
Version 2.1
Page 133 of 208
12 - Class ALC: Life cycle support
Development security (ALC_DVS)
12.1
ALC_DVS
Development security (ALC_DVS)
Development security
Objectives
383
Development security is concerned with physical, procedural, personnel, and other security measures that may be used in the development environment to protect the TOE. It includes the physical security of the development location and any procedures used to select development staff. Component levelling
384
The components in this family are levelled on the basis of whether justification of the sufficiency of the security measures is required. Application notes
385
This family deals with measures to remove or reduce threats existing at the developer's site. Conversely, threats to be countered at the TOE user's site are normally covered in the security environment subclause of a PP or ST. The evaluator should determine whether there is a need for visiting the developer's site in order to confirm that the requirements of this family are met. It is recognised that confidentiality may not always be an issue for the protection of the TOE in its development environment. The use of the word "necessary" allows for the selection of appropriate safeguards.
386
387
ALC_DVS.1 Identification of security measures Dependencies: No dependencies. Developer action elements:
ALC_DVS.1.1D
The developer shall produce development security documentation. Content and presentation of evidence elements:
ALC_DVS.1.1C
The development security documentation shall describe all the physical, procedural, personnel, and other security measures that are necessary to protect the confidentiality and integrity of the TOE design and implementation in its development environment. The development security documentation shall provide evidence that these security measures are followed during the development and maintenance of the TOE.
ALC_DVS.1.2C
Page 134 of 208
Version 2.1
August 1999
Development security (ALC_DVS)
12 - Class ALC: Life cycle support
Evaluator action elements:
ALC_DVS.1.1E
The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall confirm that the security measures are being applied.
ALC_DVS.1.2E
ALC_DVS.2 Sufficiency of security measures Dependencies: No dependencies. Developer action elements:
ALC_DVS.2.1D
The developer shall produce development security documentation. Content and presentation of evidence elements:
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. The development security documentation shall provide evidence that these security measures are followed during the development and maintenance of the TOE. The evidence shall justify that the security measures provide the necessary level of protection to maintain the confidentiality and integrity of the TOE. Evaluator action elements:
ALC_DVS.2.2C
ALC_DVS.2.3C
ALC_DVS.2.1E
The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall confirm that the security measures are being applied.
ALC_DVS.2.2E
August 1999
Version 2.1
Page 135 of 208
12 - Class ALC: Life cycle support
Flaw remediation (ALC_FLR)
12.2
ALC_FLR
Flaw remediation (ALC_FLR)
Flaw remediation
Objectives
388
Flaw remediation requires that discovered security flaws be tracked and corrected by the developer. Although future compliance with flaw remediation procedures cannot be determined at the time of the TOE evaluation, it is possible to evaluate the policies and procedures that a developer has in place to track and correct flaws, and to distribute the flaw information and corrections. Component levelling
389
The components in this family are levelled on the basis of the increasing extent in scope of the flaw remediation procedures and the rigour of the flaw remediation policies. Application notes
390
This family provides assurance that the TOE will be maintained and supported in the future, requiring the TOE developer to track and correct flaws in the TOE. Additionally, requirements are included for the distribution of flaw corrections. However, this family does not impose evaluation requirements beyond the current evaluation. The flaw remediation procedures should describe the methods for dealing with all types of flaws encountered. Some flaws may not be fixable immediately. There may be some occasions where a flaw cannot be fixed and other (e.g. procedural) measures must be taken. The documentation provided should cover the procedures for providing the operational sites with fixes, and providing information on flaws where fixes are delayed (and what to do in the interim) or when fixes are not possible.
391
ALC_FLR.1 Basic flaw remediation Dependencies: No dependencies. Developer action elements:
ALC_FLR.1.1D
The developer shall document the flaw remediation procedures. Content and presentation of evidence elements:
ALC_FLR.1.1C
The flaw remediation procedures documentation shall describe the procedures used to track all reported security flaws in each release of the TOE. The flaw remediation procedures shall require that a description of the nature and effect of each security flaw be provided, as well as the status of finding a correction to that flaw.
ALC_FLR.1.2C
Page 136 of 208
Version 2.1
August 1999
Flaw remediation (ALC_FLR)
12 - Class ALC: Life cycle support
ALC_FLR.1.3C
The flaw remediation procedures shall require that corrective actions be identified for each of the security flaws. The flaw remediation procedures documentation shall describe the methods used to provide flaw information, corrections and guidance on corrective actions to TOE users. Evaluator action elements:
ALC_FLR.1.4C
ALC_FLR.1.1E
The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
ALC_FLR.2 Flaw reporting procedures Dependencies: No dependencies. Developer action elements:
ALC_FLR.2.1D ALC_FLR.2.2D
The developer shall document the flaw remediation procedures. The developer shall establish a procedure for accepting and acting upon user reports of security flaws and requests for corrections to those flaws. Content and presentation of evidence elements:
ALC_FLR.2.1C
The flaw remediation procedures documentation shall describe the procedures used to track all reported security flaws in each release of the TOE. The flaw remediation procedures shall require that a description of the nature and effect of each security flaw be provided, as well as the status of finding a correction to that flaw. The flaw remediation procedures shall require that corrective actions be identified for each of the security flaws. The flaw remediation procedures documentation shall describe the methods used to provide flaw information, corrections and guidance on corrective actions to TOE users. The procedures for processing reported security flaws shall ensure that any reported flaws are corrected and the correction issued to TOE users. The procedures for processing reported security flaws shall provide safeguards that any corrections to these security flaws do not introduce any new flaws.
ALC_FLR.2.2C
ALC_FLR.2.3C
ALC_FLR.2.4C
ALC_FLR.2.5C
ALC_FLR.2.6C
August 1999
Version 2.1
Page 137 of 208
12 - Class ALC: Life cycle support
Flaw remediation (ALC_FLR)
Evaluator action elements:
ALC_FLR.2.1E
The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
ALC_FLR.3 Systematic flaw remediation Dependencies: No dependencies. Developer action elements:
ALC_FLR.3.1D ALC_FLR.3.2D
The developer shall document the flaw remediation procedures. The developer shall establish a procedure for accepting and acting upon user reports of security flaws and requests for corrections to those flaws. The developer shall designate one or more specific points of contact for user reports and inquiries about security issues involving the TOE. Content and presentation of evidence elements:
ALC_FLR.3.3D
ALC_FLR.3.1C
The flaw remediation procedures documentation shall describe the procedures used to track all reported security flaws in each release of the TOE. The flaw remediation procedures shall require that a description of the nature and effect of each security flaw be provided, as well as the status of finding a correction to that flaw. The flaw remediation procedures shall require that corrective actions be identified for each of the security flaws. The flaw remediation procedures documentation shall describe the methods used to provide flaw information, corrections and guidance on corrective actions to TOE users. The procedures for processing reported security flaws shall ensure that any reported flaws are corrected and the correction issued to TOE users. The procedures for processing reported security flaws shall provide safeguards that any corrections to these security flaws do not introduce any new flaws. The flaw remediation procedures shall include a procedure requiring timely responses for the automatic distribution of security flaw reports and the associated corrections to registered users who might be affected by the security flaw.
ALC_FLR.3.2C
ALC_FLR.3.3C
ALC_FLR.3.4C
ALC_FLR.3.5C
ALC_FLR.3.6C
ALC_FLR.3.7C
Page 138 of 208
Version 2.1
August 1999
Flaw remediation (ALC_FLR)
12 - Class ALC: Life cycle support
Evaluator action elements:
ALC_FLR.3.1E
The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
August 1999
Version 2.1
Page 139 of 208
12 - Class ALC: Life cycle support
Life cycle definition(ALC_LCD)
12.3
ALC_LCD
Life cycle definition(ALC_LCD)
Life cycle definition
Objectives
392
Poorly controlled development and maintenance of the TOE can result in a flawed implementation of a TOE (or a TOE that does not meet all of its security requirements). This, in turn, results in security violations. Therefore, it is important that a model for the development and maintenance of a TOE be established as early as possible in the TOE's life-cycle. Using a model for the development and maintenance of a TOE does not guarantee that the TOE will be free of flaws, nor does it guarantee that the TOE will meet all of its security functional requirements. It is possible that the model chosen will be insufficient or inadequate and therefore no benefits in the quality of the TOE can be observed. Using a life-cycle model that has been approved by some group of experts (e.g. academic experts, standards bodies) improves the chances that the development and maintenance models will contribute to the overall quality of the TOE. Component levelling
393
394
The components in this family are levelled on the basis of increasing requirements for standardisation and measurability of the life-cycle model, and for compliance with that model. Application notes
395
A life-cycle model encompasses the procedures, tools and techniques used to develop and maintain the TOE. Aspects of the process that may be covered by such a model include design methods, review procedures, project management controls, change control procedures, test methods and acceptance procedures. An effective life-cycle model will address these aspects of the development and maintenance process within an overall management structure that assigns responsibilities and monitors progress. Although life-cycle definition deals with the maintenance of the TOE and hence with aspects becoming relevant after the completion of the evaluation, its evaluation adds assurance through an analysis of the life-cycle information for the TOE provided at the time of the evaluation. A standardised life-cycle model is a model that has been approved by some group of experts (e.g. academic experts, standards bodies). A measurable life-cycle model is a model with arithmetic parameters and/or metrics that measure TOE development properties (e.g. source code complexity metrics). A life-cycle model provides for the necessary control over the development and maintenance of the TOE, if the developer can supply information that shows that the model appropriately minimises the danger of security violations in the TOE.
396
397
398
399
Page 140 of 208
Version 2.1
August 1999
Life cycle definition(ALC_LCD)
12 - Class ALC: Life cycle support
Information given in the ST about the intended environment of the TOE and about the TOE's security objectives may be useful in defining the model for the portion of the life-cycle after the delivery of the TOE. ALC_LCD.1 Developer defined life-cycle model Dependencies: No dependencies. Developer action elements:
ALC_LCD.1.1D
The developer shall establish a life-cycle model to be used in the development and maintenance of the TOE. The developer shall provide life-cycle definition documentation. Content and presentation of evidence elements:
ALC_LCD.1.2D
ALC_LCD.1.1C
The life-cycle definition documentation shall describe the model used to develop and maintain the TOE. The life-cycle model shall provide for the necessary control over the development and maintenance of the TOE. Evaluator action elements:
ALC_LCD.1.2C
ALC_LCD.1.1E
The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
ALC_LCD.2 Standardised life-cycle model Dependencies: No dependencies. Developer action elements:
ALC_LCD.2.1D
The developer shall establish a life-cycle model to be used in the development and maintenance of the TOE. The developer shall provide life-cycle definition documentation. The developer shall use a standardised life-cycle model to develop and maintain the TOE. Content and presentation of evidence elements:
ALC_LCD.2.2D ALC_LCD.2.3D
ALC_LCD.2.1C
The life-cycle definition documentation shall describe the model used to develop and maintain the TOE.
August 1999
Version 2.1
Page 141 of 208
12 - Class ALC: Life cycle support
Life cycle definition(ALC_LCD)
ALC_LCD.2.2C
The life-cycle model shall provide for the necessary control over the development and maintenance of the TOE. The life-cycle definition documentation shall explain why the model was chosen. The life-cycle definition documentation shall explain how the model is used to develop and maintain the TOE. The life-cycle definition documentation shall demonstrate compliance with the standardised life-cycle model. Evaluator action elements:
ALC_LCD.2.3C
ALC_LCD.2.4C
ALC_LCD.2.5C
ALC_LCD.2.1E
The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
ALC_LCD.3 Measurable life-cycle model Dependencies: No dependencies. Developer action elements:
ALC_LCD.3.1D
The developer shall establish a life-cycle model to be used in the development and maintenance of the TOE. The developer shall provide life-cycle definition documentation. The developer shall use a standardised and measurable life-cycle model to develop and maintain the TOE. The developer shall measure the TOE development using the standardised and measurable life-cycle model. Content and presentation of evidence elements:
ALC_LCD.3.2D ALC_LCD.3.3D
ALC_LCD.3.4D
ALC_LCD.3.1C
The life-cycle definition documentation shall describe the model used to develop and maintain the TOE, including the details of its arithmetic parameters and/or metrics used to measure the TOE development against the model. The life-cycle model shall provide for the necessary control over the development and maintenance of the TOE. The life-cycle definition documentation shall explain why the model was chosen. The life-cycle definition documentation shall explain how the model is used to develop and maintain the TOE.
ALC_LCD.3.2C
ALC_LCD.3.3C ALC_LCD.3.4C
Page 142 of 208
Version 2.1
August 1999
Life cycle definition(ALC_LCD)
12 - Class ALC: Life cycle support
ALC_LCD.3.5C
The life-cycle definition documentation shall demonstrate compliance with the standardised and measurable life-cycle model. The life-cycle documentation shall provide the results of the measurements of the TOE development using the standardised and measurable life-cycle model. Evaluator action elements:
ALC_LCD.3.6C
ALC_LCD.3.1E
The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
August 1999
Version 2.1
Page 143 of 208
12 - Class ALC: Life cycle support
Tools and techniques (ALC_TAT)
12.4
ALC_TAT
Tools and techniques (ALC_TAT)
Tools and techniques
Objectives
400
Tools and techniques is an aspect of selecting tools that are used to develop, analyse and implement the TOE. It includes requirements to prevent ill-defined, inconsistent or incorrect development tools from being used to develop the TOE. This includes, but is not limited to, programming languages, documentation, implementation standards, and other parts of the TOE such as supporting runtime libraries. Component levelling
401
The components in this family are levelled on the basis of increasing requirements on the description and scope of the implementation standards and the documentation of implementation- dependent options. Application notes
402
There is a requirement for well-defined development tools. These are tools that have been shown to be applicable without the need for intensive further clarification. For example, programming languages and computer aided design (CAD) systems that are based on an a standard published by standards bodies are considered to be well-defined. Tools and techniques distinguishes between the implementation standards applied by the developer (ALC_TAT.2.3D) and the implementation standards for "all parts of the TOE" (ALC_TAT.3.3D) that additionally includes third party software, hardware, or firmware. The requirement in ALC_TAT.1.2C is especially applicable to programming languages so as to ensure that all statements in the source code have an unambiguous meaning.
403
404
ALC_TAT.1 Well-defined development tools Dependencies: ADV_IMP.1 Subset of the implementation of the TSF Developer action elements:
ALC_TAT.1.1D ALC_TAT.1.2D
The developer shall identify the development tools being used for the TOE. The developer shall document the selected implementation-dependent options of the development tools. Content and presentation of evidence elements:
ALC_TAT.1.1C
All development tools used for implementation shall be well-defined.
Page 144 of 208
Version 2.1
August 1999
Tools and techniques (ALC_TAT)
12 - Class ALC: Life cycle support
ALC_TAT.1.2C
The documentation of the development tools shall unambiguously define the meaning of all statements used in the implementation. The documentation of the development tools shall unambiguously define the meaning of all implementation-dependent options. Evaluator action elements:
ALC_TAT.1.3C
ALC_TAT.1.1E
The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
ALC_TAT.2 Compliance with implementation standards Dependencies: ADV_IMP.1 Subset of the implementation of the TSF Developer action elements:
ALC_TAT.2.1D ALC_TAT.2.2D
The developer shall identify the development tools being used for the TOE. The developer shall document the selected implementation-dependent options of the development tools. The developer shall describe the implementation standards to be applied. Content and presentation of evidence elements:
ALC_TAT.2.3D
ALC_TAT.2.1C ALC_TAT.2.2C
All development tools used for implementation shall be well-defined. The documentation of the development tools shall unambiguously define the meaning of all statements used in the implementation. The documentation of the development tools shall unambiguously define the meaning of all implementation-dependent options. Evaluator action elements:
ALC_TAT.2.3C
ALC_TAT.2.1E
The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall confirm that the implementation standards have been applied.
ALC_TAT.2.2E
ALC_TAT.3 Compliance with implementation standards - all parts Dependencies: ADV_IMP.1 Subset of the implementation of the TSF
August 1999
Version 2.1
Page 145 of 208
12 - Class ALC: Life cycle support
Tools and techniques (ALC_TAT)
Developer action elements:
ALC_TAT.3.1D ALC_TAT.3.2D
The developer shall identify the development tools being used for the TOE. The developer shall document the selected implementation-dependent options of the development tools. The developer shall describe the implementation standards for all parts of the TOE. Content and presentation of evidence elements:
ALC_TAT.3.3D
ALC_TAT.3.1C ALC_TAT.3.2C
All development tools used for implementation shall be well-defined. The documentation of the development tools shall unambiguously define the meaning of all statements used in the implementation. The documentation of the development tools shall unambiguously define the meaning of all implementation-dependent options. Evaluator action elements:
ALC_TAT.3.3C
ALC_TAT.3.1E
The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall confirm that the implementation standards have been applied.
ALC_TAT.3.2E
Page 146 of 208
Version 2.1
August 1999
Part 3: Security assurance requirements 163
13
405
Class ATE: Tests
The class "Tests" encompasses four families: coverage (ATE_COV), depth (ATE_DPT), independent testing (e.g. functional testing performed by evaluators) (ATE_IND), and functional tests (ATE_FUN). Testing helps to establish that the TOE security functional requirements are met. Testing provides assurance that the TOE satisfies at least the TOE security functional requirements, although it cannot establish that the TOE does no more than what was specified. Testing may also be directed toward the internal structure of the TSF, such as the testing of subsystems and modules against their specifications. The aspects of coverage and depth have been separated from functional tests for reasons of increased flexibility in applying the components of the families. However, the requirements in these three families are intended to be applied together. The independent testing family has dependencies on the other families to provide the necessary information to support the requirements, but is primarily concerned with independent evaluator actions. The emphasis in this class is on confirmation that the TSF operates according to its specification. This will include both positive testing based on functional requirements, and negative testing to check that undesirable behaviour is absent. This class does not address penetration testing, which is directed toward finding vulnerabilities that enable a user to violate the security policy. Penetration testing is based upon an analysis of the TOE that specifically seeks to identify vulnerabilities in the design and implementation of the TSF, and is addressed separately as an aspect of vulnerability assessment in the class AVA.
406
407
408
August 1999
Version 2.1
Page 147 of 208
13 - Class ATE: Tests
409
Figure 13.1 shows the families within this class, and the hierarchy of components within the families.
Class ATE Tests ATE_COV Coverage ATE_DPT Depth ATE_FUN Functional tests ATE_IND Independent testing 1 1 1 1 2 2 2 2 3 3 3
Figure 13.1 -Tests class decomposition
Page 148 of 208
Version 2.1
August 1999
Coverage (ATE_COV)
13 - Class ATE: Tests
13.1
ATE_COV
Coverage (ATE_COV)
Coverage
Objectives
410
This family addresses those aspects of testing that deal with completeness of test coverage. That is, it addresses the extent to which the TSF is tested, and whether or not the testing is sufficiently extensive to demonstrate that the TSF operates as specified. Component levelling
411
The components in this family are levelled on the basis of increasing rigour of interface testing, and increasing rigour of the analysis of the sufficiency of the tests to demonstrate that the TSF operates in accordance with its functional specification.
ATE_COV.1 Evidence of coverage Objectives
412
In this component, the objective is to establish that the TSF has been tested against its functional specification. This is to be achieved through an examination of developer evidence of correspondence. Application notes
413
While the testing objective is to cover the TSF, there is no requirement to provide anything to verify this assertion other than an informal mapping of tests to the functional specification and the testing data itself. In this component the developer is required to show how the tests that have been identified correspond to the TSF as described in the functional specification. This can be achieved by a statement of correspondence, perhaps using a table. This information is required to support the evaluator in planning the test programme for the evaluation. At this level there is no requirement for complete coverage of every aspect of the TSF by the developer, and the evaluator will need to take account of any deficiencies in this area. Dependencies: ADV_FSP.1 Informal functional specification ATE_FUN.1 Functional testing Developer action elements:
414
ATE_COV.1.1D
The developer shall provide evidence of the test coverage.
August 1999
Version 2.1
Page 149 of 208
13 - Class ATE: Tests
Coverage (ATE_COV)
Content and presentation of evidence elements:
ATE_COV.1.1C
The evidence of the test coverage shall show the correspondence between the tests identified in the test documentation and the TSF as described in the functional specification. Evaluator action elements:
ATE_COV.1.1E
The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
ATE_COV.2 Analysis of coverage Objectives
415
In this component, the objective is to establish that the TSF has been tested against its functional specification in a systematic manner. This is to be achieved through an examination of developer analysis of correspondence. Application notes
416
The developer is required to demonstrate that the tests which have been identified include testing of all of the security functions as described in the functional specification. The analysis should not only show the correspondence between tests and security functions, but should provide also sufficient information for the evaluator to determine how the functions have been exercised. This information can be used in planning for additional evaluator tests. Although at this level the developer has to demonstrate that each of the functions within the functional specification has been tested, the amount of testing of each function need not be exhaustive. Dependencies: ADV_FSP.1 Informal functional specification ATE_FUN.1 Functional testing Developer action elements:
ATE_COV.2.1D
The developer shall provide an analysis of the test coverage. Content and presentation of evidence elements:
ATE_COV.2.1C
The analysis of the test coverage shall demonstrate the correspondence between the tests identified in the test documentation and the TSF as described in the functional specification. The analysis of the test coverage shall demonstrate that the correspondence between the TSF as described in the functional specification and the tests identified in the test documentation is complete.
ATE_COV.2.2C
Page 150 of 208
Version 2.1
August 1999
Coverage (ATE_COV)
13 - Class ATE: Tests
Evaluator action elements:
ATE_COV.2.1E
The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
ATE_COV.3 Rigorous analysis of coverage Objectives
417
In this component, the objective is to establish that the TSF has been tested against its functional specification in a systematic and exhaustive manner. This is to be achieved through an examination of developer analysis of correspondence. Application notes
418
The developer is required to provide a convincing argument that the tests which have been identified cover all security functions, and that the testing of each security function is complete. There will remain little scope for the evaluator to devise additional functional tests of the TSF interfaces based on the functional specification, as they will have been exhaustively tested. Nevertheless, the evaluator should strive to devise such tests. Dependencies: ADV_FSP.1 Informal functional specification ATE_FUN.1 Functional testing Developer action elements:
ATE_COV.3.1D
The developer shall provide an analysis of the test coverage. Content and presentation of evidence elements:
ATE_COV.3.1C
The analysis of the test coverage shall demonstrate the correspondence between the tests identified in the test documentation and the TSF as described in the functional specification. The analysis of the test coverage shall demonstrate that the correspondence between the TSF as described in the functional specification and the tests identified in the test documentation is complete. The analysis of the test coverage shall rigorously demonstrate that all external interfaces of the TSF identified in the functional specification have been completely tested. Evaluator action elements:
ATE_COV.3.2C
ATE_COV.3.3C
ATE_COV.3.1E
The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
August 1999
Version 2.1
Page 151 of 208
13 - Class ATE: Tests
Depth (ATE_DPT)
13.2
ATE_DPT
Depth (ATE_DPT)
Depth
Objectives
419
The components in this family deal with the level of detail to which the TSF is tested. Testing of security functions is based upon increasing depth of information derived from analysis of the representations. The objective is to counter the risk of missing an error in the development of the TOE. Additionally, the components of this family, especially as testing is more concerned with the internal structure of the TSF, are more likely to discover any malicious code that has been inserted. Testing that exercises specific internal interfaces can provide assurance not only that the TSF exhibits the desired external security behaviour, but also that this behaviour stems from correctly operating internal mechanisms. Component levelling
420
421
422
The components in this family are levelled on the basis of increasing detail provided in the TSF representations, from the high-level design to the implementation representation. This levelling reflects the TSF representations presented in the ADV class. Application notes
423
The specific amount and type of documentation and evidence will, in general, be determined by the chosen component from ATE_FUN. Testing at the level of the functional specification is addressed by ATE_COV. The principle adopted within this family is that the level of testing be appropriate to the level of assurance being sought. Where higher components are applied, the test results will need to demonstrate that the implementation of the TSF is consistent with its design. For example, the high-level design should describe each of the subsystems and also describe the interfaces between these subsystems in sufficient detail. Evidence of testing must show that the internal interfaces between subsystems have been exercised. This may be achieved through testing via the external interfaces of the TSF, or by testing of the subsystem interfaces in isolation, perhaps employing a test harness. In cases where some aspects of an internal interface cannot be tested via the external interfaces there should either be justification that these aspects need not be tested, or the internal interface needs to be tested directly. In the latter case the high-level design needs to be sufficiently detailed in order to facilitate direct testing. The higher components in this family aim to check the correct operation of internal interfaces that become visible as the design becomes less abstract. When these components are applied it will be more difficult to provide adequate evidence of the depth of testing using the TSF's external interfaces alone, and modular testing will usually be necessary.
424 425
Page 152 of 208
Version 2.1
August 1999
Depth (ATE_DPT)
13 - Class ATE: Tests
ATE_DPT.1 Testing: high-level design Objectives
426
The subsystems of a TSF provide a high-level description of the internal workings of the TSF. Testing at the level of the subsystems, in order to demonstrate the presence of any flaws, provides assurance that the TSF subsystems have been correctly realised. Application notes
427
The developer is expected to describe the testing of the high-level design of the TSF in terms of "subsystems". The term "subsystem" is used to express the notion of decomposing the TSF into a relatively small number of parts. Dependencies: ADV_HLD.1 Descriptive high-level design ATE_FUN.1 Functional testing Developer action elements:
ATE_DPT.1.1D
The developer shall provide the analysis of the depth of testing. Content and presentation of evidence elements:
ATE_DPT.1.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. Evaluator action elements:
ATE_DPT.1.2E
The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
ATE_DPT.2 Testing: low-level design Objectives
428
The subsystems of a TSF provide a high-level description of the internal workings of the TSF. Testing at the level of the subsystems, in order to demonstrate the presence of any flaws, provides assurance that the TSF subsystems have been correctly realised. The modules of a TSF provide a description of the internal workings of the TSF. Testing at the level of the modules, in order to demonstrate the presence of any flaws, provides assurance that the TSF modules have been correctly realised.
429
August 1999
Version 2.1
Page 153 of 208
13 - Class ATE: Tests
Depth (ATE_DPT)
Application notes
430
The developer is expected to describe the testing of the high-level design of the TSF in terms of "subsystems". The term "subsystem" is used to express the notion of decomposing the TSF into a relatively small number of parts. The developer is expected to describe the testing of the low-level design of the TSF in terms of "modules". The term "modules" is used to express the notion of decomposing each of the "subsystems" of the TSF into a relatively small number of parts. Dependencies: ADV_HLD.2 Security enforcing high-level design ADV_LLD.1 Descriptive low-level design ATE_FUN.1 Functional testing Developer action elements:
431
ATE_DPT.2.1D
The developer shall provide the analysis of the depth of testing. Content and presentation of evidence elements:
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. Evaluator action elements:
ATE_DPT.2.1E
The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
ATE_DPT.3 Testing: implementation representation Objectives
432
The subsystems of a TSF provide a high-level description of the internal workings of the TSF. Testing at the level of the subsystems, in order to demonstrate the presence of any flaws, provides assurance that the TSF subsystems have been correctly realised. The modules of a TSF provide a description of the internal workings of the TSF. Testing at the level of the modules, in order to demonstrate the presence of any flaws, provides assurance that the TSF modules have been correctly realised. The implementation representation of a TSF provides a detailed description of the internal workings of the TSF. Testing at the level of the implementation, in order to demonstrate the presence of any flaws, provides assurance that the TSF implementation has been correctly realised.
433
434
Page 154 of 208
Version 2.1
August 1999
Depth (ATE_DPT)
13 - Class ATE: Tests
Application notes
435
The developer is expected to describe the testing of the high-level design of the TSF in terms of "subsystems". The term "subsystem" is used to express the notion of decomposing the TSF into a relatively small number of parts. The developer is expected to describe the testing of the low-level design of the TSF in terms of "modules". The term "modules" is used to express the notion of decomposing each of the "subsystems" of the TSF into a relatively small number of parts. The implementation representation is the one which is used to generate the TSF itself (e.g. source code which is then compiled). Dependencies: ADV_HLD.2 Security enforcing high-level design ADV_IMP.2 Implementation of the TSF ADV_LLD.1 Descriptive low-level design ATE_FUN.1 Functional testing Developer action elements:
436
437
ATE_DPT.3.1D
The developer shall provide the analysis of the depth of testing. Content and presentation of evidence elements:
ATE_DPT.3.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, low-level design and implementation representation. Evaluator action elements:
ATE_DPT.3.1E
The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
August 1999
Version 2.1
Page 155 of 208
13 - Class ATE: Tests
Functional tests (ATE_FUN)
13.3
ATE_FUN
Functional tests (ATE_FUN)
Functional tests
Objectives
438
Functional testing performed by the developer establishes that the TSF exhibits the properties necessary to satisfy the functional requirements of its PP/ST. Such functional testing provides assurance that the TSF satisfies at least the security functional requirements, although it cannot establish that the TSF does no more than what was specified. The family "Functional tests" is focused on the type and amount of documentation or support tools required, and what is to be demonstrated through developer testing. Functional testing is not limited to positive confirmation that the required security functions are provided, but may also include negative testing to check for the absence of particular undesired behaviour (often based on the inversion of functional requirements). This family contributes to providing assurance that the likelihood of undiscovered flaws is relatively small. The families ATE_COV, ATE_DPT and ATE_FUN are used in combination to define the evidence of testing to be supplied by a developer. Independent functional testing by the evaluator is specified by ATE_IND. Component levelling
439
440
441
This family contains two components, the higher requiring that ordering dependencies are analysed. Application notes
442
Procedures for performing tests are expected to provide instructions for using test programs and test suites, including the test environment, test conditions, test data parameters and values. The test procedures should also show how the test results are derived from the test inputs. This family specifies requirements for the presentation of all test plans, procedures and results. Thus the quantity of information that must be presented will vary in accordance with the use of ATE_COV and ATE_DPT. Ordering dependencies are relevant when the successful execution of a particular test depends upon the existence of a particular state. For example, this might require that test A be executed immediately before test B, since the state resulting from the successful execution of test A is a prerequisite for the successful execution of test B. Thus, failure of test B could be related to a problem with the ordering dependencies. In the above example, test B could fail because test C (rather than test A) was executed immediately before it, or the failure of test B could be related to a failure of test A.
443
444
Page 156 of 208
Version 2.1
August 1999
Functional tests (ATE_FUN)
13 - Class ATE: Tests
ATE_FUN.1 Functional testing Objectives
445
The objective is for the developer to demonstrate that all security functions perform as specified. The developer is required to perform testing and to provide test documentation. Dependencies: No dependencies. Developer action elements:
ATE_FUN.1.1D ATE_FUN.1.2D
The developer shall test the TSF and document the results. The developer shall provide test documentation. Content and presentation of evidence elements:
ATE_FUN.1.1C
The test documentation shall consist of test plans, test procedure descriptions, expected test results and actual test results. The test plans shall identify the security functions to be tested and describe the goal of the tests to be performed. The test procedure descriptions shall identify the tests to be performed and describe the scenarios for testing each security function. These scenarios shall include any ordering dependencies on the results of other tests. The expected test results shall show the anticipated outputs from a successful execution of the tests. The test results from the developer execution of the tests shall demonstrate that each tested security function behaved as specified. Evaluator action elements:
ATE_FUN.1.2C
ATE_FUN.1.3C
ATE_FUN.1.4C
ATE_FUN.1.5C
ATE_FUN.1.1E
The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
ATE_FUN.2 Ordered functional testing Objectives
446
The objective is for the developer to demonstrate that all security functions perform as specified. The developer is required to perform testing and to provide test documentation.
August 1999
Version 2.1
Page 157 of 208
13 - Class ATE: Tests
Functional tests (ATE_FUN)
447
In this component, an additional objective is to ensure that testing is structured such as to avoid circular arguments about the correctness of the portions of the TSF being tested. Application notes
448
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 is an important factor in determining the adequacy of testing, as there is a possibility of faults being concealed by the ordering of tests. Dependencies: No dependencies. Developer action elements:
ATE_FUN.2.1D ATE_FUN.2.2D
The developer shall test the TSF and document the results. The developer shall provide test documentation. Content and presentation of evidence elements:
ATE_FUN.2.1C
The test documentation shall consist of test plans, test procedure descriptions, expected test results and actual test results. The test plans shall identify the security functions to be tested and describe the goal of the tests to be performed. The test procedure descriptions shall identify the tests to be performed and describe the scenarios for testing each security function. These scenarios shall include any ordering dependencies on the results of other tests. The expected test results shall show the anticipated outputs from a successful execution of the tests. The test results from the developer execution of the tests shall demonstrate that each tested security function behaved as specified. The test documentation shall include an analysis of the test procedure ordering dependencies. Evaluator action elements:
ATE_FUN.2.2C
ATE_FUN.2.3C
ATE_FUN.2.4C
ATE_FUN.2.5C
ATE_FUN.2.6C
ATE_FUN.2.1E
The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
Page 158 of 208
Version 2.1
August 1999
Independent testing (ATE_IND)
13 - Class ATE: Tests
13.4
ATE_IND
Independent testing (ATE_IND)
Independent testing
Objectives
449 450
One objective is to demonstrate that the security functions perform as specified. An additional objective is to counter the risk of an incorrect assessment of the test outcomes on the part of the developer that results in the incorrect implementation of the specifications, or overlooks code that is non-compliant with the specifications. Component levelling
451
Levelling is based upon the amount of test documentation, test support and the amount of evaluator testing. Application notes
452
The testing specified in this family can be supported by a party with specialised knowledge other than the evaluator (e.g. an independent laboratory, an objective consumer organisation). Testing requires an understanding of the TOE consistent with the performance of other assurance activities, and the evaluator retains responsibility for ensuring that the requirements of this family are properly addressed when such support is used. This family deals with the degree to which there is independent functional testing of the TSF. Independent functional testing may take the form of repeating the developer's functional tests, in whole or in part. It may also take the form of the augmentation of the developer's functional tests, either to extend the scope or the depth of the developer's tests, or to test for obvious public domain security weaknesses that could be applicable to the TOE. These activities are complementary, and an appropriate mix must be planned for each TOE, which takes into account the availability and coverage of test results, and the functional complexity of the TSF. A test plan should be developed that is consistent with the level of other assurance activities, and which, as greater assurance is required, includes larger samples of repeated tests, and more independent positive and negative functional tests by the evaluator. Sampling of developer tests is intended to provide confirmation that the developer has carried out his planned test programme on the TSF, and has correctly recorded the results. The size of sample selected will be influenced by the detail and quality of the developer's functional test results. The evaluator will also need to consider the scope for devising additional tests, and the relative benefit that may be gained from effort in these two areas. It is recognised that repetition of all developer tests may be feasible and desirable in some cases, but may be very arduous and less productive in others. The highest component in this family should therefore be used with caution. Sampling will address the whole range of test results available, including those supplied to meet the requirements of both ATE_COV and ATE_DPT.
453
454
August 1999
Version 2.1
Page 159 of 208
13 - Class ATE: Tests
Independent testing (ATE_IND)
455
There is also a need to consider the different configurations of the TOE that are included within the evaluation. The evaluator will need to assess the applicability of the results provided, and to plan his own testing accordingly. Independent functional testing is distinct from penetration testing, the latter being based on an informed and systematic search for vulnerabilities in the design and/or implementation. Penetration testing is specified using the family AVA_VLA. The suitability of the TOE for testing is based on the access to the TOE, and the supporting documentation and information required (including any test software or tools) to run tests. The need for such support is addressed by the dependencies to other assurance families. Additionally, suitability of the TOE for testing may be based on other considerations. For example, the version of the TOE submitted by the developer may not be the final version. References to a subset of the TSF are intended to allow the evaluator to design an appropriate set of tests which is consistent with the objectives of the evaluation being conducted.
456
457
458
459
ATE_IND.1 Independent testing - conformance Objectives
460
In this component, the objective is to demonstrate that the security functions perform as specified. Application notes
461
This component does not address the use of developer test results. It is applicable where such results are not available, and also in cases where the developer's testing is accepted without validation. The evaluator is required to devise and conduct tests with the objective of confirming that the TOE security functional requirements are met. The approach is to gain confidence in correct operation through representative testing, rather than to conduct every possible test. The extent of testing to be planned for this purpose is a methodology issue, and needs to be considered in the context of a particular TOE and the balance of other evaluation activities. Dependencies: ADV_FSP.1 Informal functional specification AGD_ADM.1 Administrator guidance AGD_USR.1 User guidance Developer action elements:
ATE_IND.1.1D
The developer shall provide the TOE for testing.
Page 160 of 208
Version 2.1
August 1999
Independent testing (ATE_IND)
13 - Class ATE: Tests
Content and presentation of evidence elements:
ATE_IND.1.1C
The TOE shall be suitable for testing. Evaluator action elements:
ATE_IND.1.1E
The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall test a subset of the TSF as appropriate to confirm that the TOE operates as specified.
ATE_IND.1.2E
ATE_IND.2 Independent testing - sample Objectives
462
The objective is to demonstrate that the security functions perform as specified. Evaluator testing includes selecting and repeating a sample of the developer tests. Application notes
463
The intent is that the developer should provide the evaluator with materials necessary for the efficient reproduction of developer tests. This may include such things as machine-readable test documentation, test programs, etc. This component contains a requirement that the evaluator has available test results from the developer to supplement the programme of testing. The evaluator will repeat a sample of the developer's tests to gain confidence in the results obtained. Having established such confidence the evaluator will build upon the developer's testing by conducting additional tests that exercise the TOE in a different manner. By using a platform of validated developer test results the evaluator is able to gain confidence that the TOE operates correctly in a wider range of conditions than would be possible purely using the developer's own efforts, given a fixed level of resource. Having gained confidence that the developer has tested the TOE, the evaluator will also have more freedom, where appropriate, to concentrate testing in areas where examination of documentation or specialist knowledge has raised particular concerns. Dependencies: ADV_FSP.1 Informal functional specification AGD_ADM.1 Administrator guidance AGD_USR.1 User guidance ATE_FUN.1 Functional testing Developer action elements:
464
ATE_IND.2.1D
The developer shall provide the TOE for testing.
August 1999
Version 2.1
Page 161 of 208
13 - Class ATE: Tests
Independent testing (ATE_IND)
Content and presentation of evidence elements:
ATE_IND.2.1C ATE_IND.2.2C
The TOE shall be suitable for testing. The developer shall provide an equivalent set of resources to those that were used in the developer's functional testing of the TSF. Evaluator action elements:
ATE_IND.2.1E
The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall test a subset of the TSF as appropriate to confirm that the TOE operates as specified. The evaluator shall execute a sample of tests in the test documentation to verify the developer test results.
ATE_IND.2.2E
ATE_IND.2.3E
ATE_IND.3 Independent testing - complete Objectives
465
The objective is to demonstrate that all security functions perform as specified. Evaluator testing includes repeating all of the developer tests. Application notes
466
The intent is that the developer should provide the evaluator with materials necessary for the efficient reproduction of developer tests. This may include such things as machine-readable test documentation, test programs, etc. In this component the evaluator must repeat all of the developer's tests as part of the programme of testing. As in the previous component the evaluator will also conduct tests that aim to exercise the TOE in a different manner from that achieved by the developer. In cases where developer testing has been exhaustive, there may remain little scope for this. Dependencies: ADV_FSP.1 Informal functional specification AGD_ADM.1 Administrator guidance AGD_USR.1 User guidance ATE_FUN.1 Functional testing Developer action elements:
467
ATE_IND.3.1D
The developer shall provide the TOE for testing.
Page 162 of 208
Version 2.1
August 1999
Independent testing (ATE_IND)
13 - Class ATE: Tests
Content and presentation of evidence elements:
ATE_IND.3.1C ATE_IND.3.2C
The TOE shall be suitable for testing. The developer shall provide an equivalent set of resources to those that were used in the developer's functional testing of the TSF. Evaluator action elements:
ATE_IND.3.1E
The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall test a subset of the TSF as appropriate to confirm that the TOE operates as specified. The evaluator shall execute all tests in the test documentation to verify the developer test results.
ATE_IND.3.2E
ATE_IND.3.3E
August 1999
Version 2.1
Page 163 of 208
Part 3: Security assurance requirements 182
14
468
Class AVA: Vulnerability assessment
The class addresses the existence of exploitable covert channels, the possibility of misuse or incorrect configuration of the TOE, the possibility to defeat probabilistic or permutational mechanisms, and the possibility of exploitable vulnerabilities introduced in the development or the operation of the TOE. Figure 14.1 shows the families within this class, and the hierarchy of components within the families.
469
Class AVA: Vulnerability assessment AVA_CCA Covert channel analysis AVA_MSU Misuse AVA_SOF Strength of TOE security functions AVA_VLA Vulnerability analysis 1 1 1 1 2 3 4 2 2 3 3
Figure 14.1 -Vulnerability assessment class decomposition
August 1999
Version 2.1
Page 164 of 208
Covert channel analysis (AVA_CCA)
14 - Class AVA: Vulnerability assessment
14.1
AVA_CCA
Covert channel analysis (AVA_CCA)
Covert channel analysis
Objectives
470
Covert channel analysis is carried out to determine the existence and potential capacity of unintended signalling channels (i.e. illicit information flows) that may be exploited. The assurance requirements address the threat that unintended and exploitable signalling paths exist that may be exercised to violate the SFP. Component levelling
471
472
The components are levelled on increasing rigour of covert channel analysis. Application notes
473
Channel capacity estimations are based upon informal engineering measurements, as well as actual test measurements. Examples of assumptions upon which the covert channel analysis is based may include processor speed, system or network configuration, memory size, and cache size. 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. 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.
474
475
476
AVA_CCA.1 Covert channel analysis Objectives
477
The objective is to identify covert channels that are identifiable, through an informal search for covert channels. Dependencies: ADV_FSP.2 Fully defined external interfaces ADV_IMP.2 Implementation of the TSF AGD_ADM.1 Administrator guidance AGD_USR.1 User guidance
August 1999
Version 2.1
Page 165 of 208
14 - Class AVA: Vulnerability assessment
Covert channel analysis (AVA_CCA)
Developer action elements:
AVA_CCA.1.1D
The developer shall conduct a search for covert channels for each information flow ...