ISO/IEC 15408-3:1999

©  ISO/IEC 1999
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means, electronic
or mechanical, including photocopying and microfilm, without permission in writing from the publisher.
ISO/IEC Copyright Office • Case postale 56 • CH-1211 Genève 20 • Switzerland
Printed in Switzerland
ii
© ISO/IEC                                        ISO/IEC 15408-3:1999(E)
Contents
1 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1 Organisation of ISO/IEC 15408-3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 ISO/IEC 15408 assurance paradigm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2.1 ISO/IEC 15408 philosophy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2.2 Assurance approach. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2.3 The ISO/IEC 15408 evaluation assurance scale . . . . . . . . . . . . . . . . . 4
2 Security assurance requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1 Structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.1 Class structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.2 Assurance family structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.3 Assurance component structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.4 Assurance elements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.1.5 EAL structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.1.6 Relationship between assurances and assurance levels. . . . . . . . . . . . 13
2.2 Component taxonomy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3 Protection Profile and Security Target evaluation criteria class structure . 13
2.4 Usage of terms in ISO/IEC 15408-3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.5 Assurance categorisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.6 Assurance class and family overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.6.1 Class ACM: Configuration management . . . . . . . . . . . . . . . . . . . . . . 16
2.6.2 Class ADO: Delivery and operation . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.6.3 Class ADV: Development. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.6.4 Class AGD: Guidance documents. . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.6.5 Class ALC: Life cycle support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.6.6 Class ATE: Tests. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.6.7 Class AVA: Vulnerability assessment . . . . . . . . . . . . . . . . . . . . . . . . 20
2.7 Maintenance categorisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.8 Maintenance of assurance class and family overview . . . . . . . . . . . . . . . . 21
2.8.1 Class AMA: Maintenance of assurance . . . . . . . . . . . . . . . . . . . . . . . 21
3 Protection Profile and Security Target evaluation criteria . . . . . . . . . . . . 23
3.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2 Protection Profile criteria overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2.1 Protection Profile evaluation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2.2 Relation to the Security Target evaluation criteria . . . . . . . . . . . . . . . 23
3.2.3 Evaluator tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.3 Security Target criteria overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.3.1 Security Target evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.3.2 Relation to the other evaluation criteria in this part of ISO/IEC 15408 24
3.3.3 Evaluator tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4 Class APE: Protection Profile evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.1 TOE description (APE_DES) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.2 Security environment (APE_ENV) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.3 PP introduction (APE_INT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
iii
4.4 Security objectives (APE_OBJ) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.5 IT security requirements (APE_REQ) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.6 Explicitly stated IT security requirements (APE_SRE) . . . . . . . . . . . . . . . 36
5 Class ASE: Security Target evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.1 TOE description (ASE_DES) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
5.2 Security environment (ASE_ENV) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.3 ST introduction (ASE_INT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.4 Security objectives (ASE_OBJ) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.5 PP claims (ASE_PPC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.6 IT security requirements (ASE_REQ) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.7 Explicitly stated IT security requirements (ASE_SRE) . . . . . . . . . . . . . . . 49
5.8 TOE summary specification (ASE_TSS) . . . . . . . . . . . . . . . . . . . . . . . . . . 51
6 Evaluation assurance levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
6.1 Evaluation assurance level (EAL) overview . . . . . . . . . . . . . . . . . . . . . . . 53
6.2 Evaluation assurance level details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
6.2.1 EAL1 - functionally tested . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
6.2.2 EAL2 - structurally tested . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
6.2.3 EAL3 - methodically tested and checked . . . . . . . . . . . . . . . . . . . . . . 58
6.2.4 EAL4 - methodically designed, tested, and reviewed. . . . . . . . . . . . . 60
6.2.5 EAL5 - semiformally designed and tested . . . . . . . . . . . . . . . . . . . . . 62
6.2.6 EAL6 - semiformally verified design and tested . . . . . . . . . . . . . . . . 64
6.2.7 EAL7 - formally verified design and tested . . . . . . . . . . . . . . . . . . . . 66
7 Assurance classes, families, and components . . . . . . . . . . . . . . . . . . . . . . . . 69
8 Class ACM: Configuration management . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
8.1 CM automation (ACM_AUT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
8.2 CM capabilities (ACM_CAP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
8.3 CM scope (ACM_SCP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
9 Class ADO: Delivery and operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
9.1 Delivery (ADO_DEL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
9.2 Installation, generation and start-up (ADO_IGS) . . . . . . . . . . . . . . . . . . . . 90
10 Class ADV: Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
10.1 Functional specification (ADV_FSP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
10.2 High-level design (ADV_HLD) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
10.3 Implementation representation (ADV_IMP) . . . . . . . . . . . . . . . . . . . . . . . 109
10.4 TSF internals (ADV_INT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
10.5 Low-level design (ADV_LLD) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
10.6 Representation correspondence (ADV_RCR) . . . . . . . . . . . . . . . . . . . . . . 122
10.7 Security policy modeling (ADV_SPM) . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
11 Class AGD: Guidance documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
11.1 Administrator guidance (AGD_ADM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
11.2 User guidance (AGD_USR) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
iv
© ISO/IEC                                        ISO/IEC 15408-3:1999(E)
12 Class ALC: Life cycle support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
12.1 Development security (ALC_DVS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
12.2 Flaw remediation (ALC_FLR) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
12.3 Life cycle definition(ALC_LCD) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
12.4 Tools and techniques (ALC_TAT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
13 Class ATE: Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
13.1 Coverage (ATE_COV) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
13.2 Depth (ATE_DPT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
13.3 Functional tests (ATE_FUN) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
13.4 Independent testing (ATE_IND) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
14 Class AVA: Vulnerability assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
14.1 Covert channel analysis (AVA_CCA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
14.2 Misuse (AVA_MSU) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
14.3 Strength of TOE security functions (AVA_SOF) . . . . . . . . . . . . . . . . . . . . 178
14.4 Vulnerability analysis (AVA_VLA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
15 Assurance maintenance paradigm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
15.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
15.2 Assurance maintenance cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
15.2.1 TOE acceptance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
15.2.2 TOE monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
15.2.3 Re-evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
15.3 Assurance maintenance class and families . . . . . . . . . . . . . . . . . . . . . . . . . 192
15.3.1 Assurance maintenance plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
15.3.2 TOE component categorisation report . . . . . . . . . . . . . . . . . . . . . . . . 193
15.3.3 Evidence of assurance maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . 194
15.3.4 Security impact analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
16 Class AMA: Maintenance of assurance . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
16.1 Assurance maintenance plan (AMA_AMP) . . . . . . . . . . . . . . . . . . . . . . . . 198
16.2 TOE component categorisation report (AMA_CAT) . . . . . . . . . . . . . . . . . 201
16.3 Evidence of assurance maintenance (AMA_EVD) . . . . . . . . . . . . . . . . . . 203
16.4 Security impact analysis (AMA_SIA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
Annex A Cross reference of assurance component dependencies . . . . . . . . . . . . . . . 209
Annex B Cross reference of EALs and assurance components . . . . . . . . . . . . . . . . . 213
v
List of Figures
Figure 2.1 - Assurance class/family/component/element hierarchy . . . . . . . . . . . . . . . . . . . 6
Figure 2.2 - Assurance component structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Figure 2.3 - EAL structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Figure 2.4 - Assurance and assurance level association . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Figure 2.5 - Sample class decomposition diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Figure 4.1 - Protection Profile evaluation class decomposition . . . . . . . . . . . . . . . . . . . . . . 27
Figure 5.1 - Security Target evaluation class decomposition . . . . . . . . . . . . . . . . . . . . . . . . 39
Figure 8.1 - Configuration management class decomposition . . . . . . . . . . . . . . . . . . . . . . . 71
Figure 9.1 - Delivery and operation class decomposition . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Figure 10.1 - Development class decomposition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Figure 10.2 - Relationships between TOE representations and requirements . . . . . . . . . . . . 95
Figure 11.1 - Guidance documents class decomposition . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
Figure 12.1 - Life-cycle support class decomposition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
Figure 13.1 - Tests class decomposition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
Figure 14.1 - Vulnerability assessment class decomposition . . . . . . . . . . . . . . . . . . . . . . . . . 167
Figure 15.1 - Example assurance maintenance cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
Figure 15.2 - Example TOE acceptance approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
Figure 15.3 - Example TOE monitoring approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
Figure 16.1 - Maintenance of assurance class decomposition . . . . . . . . . . . . . . . . . . . . . . . . 197
vi
© ISO/IEC                                        ISO/IEC 15408-3:1999(E)
List of Tables
Table 2.1 - Assurance family breakdown and mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Table 2.2 - Maintenance of assurance class decomposition . . . . . . . . . . . . . . . . . . . . . . . . 21
Table 3.1 - Protection Profile families - only ISO/IEC 15408 requirements . . . . . . . . . . . 24
Table 3.2 - Protection Profile families - ISO/IEC 15408 extended requirements . . . . . . . . 24
Table 3.3 - Security Target families - only ISO/IEC 15408 requirements . . . . . . . . . . . . . 25
Table 3.4 - Security Target families - ISO/IEC 15408 extended requirements . . . . . . . . . 25
Table 6.1 - Evaluation assurance level summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Table 6.2 - EAL1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Table 6.3 - EAL2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Table 6.4 - EAL3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Table 6.5 - EAL4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Table 6.6 - EAL5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Table 6.7 - EAL6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Table 6.8 - EAL7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Table 15.1 - Maintenance of assurance family breakdown and mapping . . . . . . . . . . . . . . . 192
Table A.1 - Assurance component dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
Table A.2 - AMA Internal Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
Table B.1 - Evaluation assurance level summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
vii
1.2.1 ISO/IEC 15408 philosophy
The ISO/IEC 15408 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.
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.
1.2.2 Assurance approach
The ISO/IEC 15408 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, ISO/IEC 15408 adopts the same philosophy. ISO/IEC 15408 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.
ISO/IEC 15408 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 standard, which is so structured as to allow their future introduction.
1.2.2.1 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 well-intentioned, 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) eliminated — that is, active steps should be taken to expose, and remove or neutralise,
all exercisable vulnerabilities;
b) minimised — that is, active steps should be taken to reduce, to an acceptable residual
level, the potential impact of any exercise of a vulnerability;
c) 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.
© ISO/IEC ISO/IEC 15408-3:1999(E)
1.2.2.2 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;
b) 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;
c) 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.
1.2.2.3 ISO/IEC 15408 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 standard provides assurance through
active investigation. Active investigation is an evaluation of the IT product or system in order to
determine its security properties.
1.2.2.4 Assurance through evaluation
Evaluation has been the traditional means of gaining assurance, and is the basis of the ISO/IEC
15408 approach. Evaluation techniques can include, but are not limited to:
a) analysis and checking of process(es) and procedure(s);
b) checking that process(es) and procedure(s) are being applied;
c) analysis of the correspondence between TOE design representations;
d) analysis of the TOE design representation against the requirements;
e) verification of proofs;
f) analysis of guidance documents;
g) analysis of functional tests developed and the results provided;
h) independent functional testing;
i) analysis for vulnerabilities (including flaw hypothesis);
j) penetration testing.
1.2.3 The ISO/IEC 15408 evaluation assurance scale
The ISO/IEC 15408 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) scope — that is, the effort is greater because a larger portion of the IT product or
system is included;
b) depth — that is, the effort is greater because it is deployed to a finer level of design and
implementation detail;
c) rigour — that is, the effort is greater because it is applied in a more structured, formal
manner.
© ISO/IEC ISO/IEC 15408-3:1999(E)
2 Security assurance requirements
2.1 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 part of ISO/IEC 15408. 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.
2.1.1 Class structure
Figure 2.1 illustrates the assurance class structure.
2.1.1.1 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.
2.1.1.2 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.
2.1.1.3 Assurance families
Each assurance class contains at least one assurance family. The structure of the assurance families
is described in the following subclause.
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 element
Assurance elements
Assurance elements
Figure 2.1 - Assurance class/family/component/element hierarchy
2.1.2 Assurance family structure
Figure 2.1 illustrates the assurance family structure.
© ISO/IEC ISO/IEC 15408-3:1999(E)
2.1.2.1 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.
2.1.2.2 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 ISO/IEC 15408 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.
2.1.2.3 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.
2.1.2.4 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.
2.1.2.5 Assurance components
Each assurance family has at least one assurance component. The structure of the assurance
components is provided in the following subclause.
2.1.3 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
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.
2.1.3.1 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.
2.1.3.2 Objectives
The objectives subclause of the assurance component, if present, contains specific objectives for
the particular assurance component. For those assurance components that have this subclause, it
presents the specific intent of the component and a more detailed explanation of the objectives.
2.1.3.3 Application notes
The application notes subclause of an assurance component, if present, contains additional
information to facilitate the use of the component.
© ISO/IEC ISO/IEC 15408-3:1999(E)
2.1.3.4 Dependencies
Dependencies among assurance components arise when a component is not self-sufficient, 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.
2.1.3.5 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 standard.
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.
b) 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.
c) 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 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 reuirements. Requirements for evaluator actions are identified by appending
the letter “E” to the element number.
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.
2.1.4 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 ISO/IEC 15408-2, neither assignment nor selection operations are relevant for
elements in this part of ISO/IEC 15408; however, refinements may be made to ISO/IEC 15408-3
elements as required.
2.1.5 EAL structure
Figure 2.3 illustrates the EALs and associated structure defined in this part of ISO/IEC 15408. 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 ISO/
IEC 15408.
2.1.5.1 EAL name
Each EAL is assigned a unique name. The name provides descriptive information about the intent
of the EAL.
A unique short form of the EAL name is also provided. This is the primary means used to reference
the EAL.
2.1.5.2 Objectives
The objectives subclause of the EAL presents the intent of the EAL.
2.1.5.3 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.
© ISO/IEC ISO/IEC 15408-3:1999(E)
ISO/IEC 15408-3 Assurance levels
Evaluation assurance level
EAL name
Objectives
Application notes
Assurance component
Component identification
Objectives
Application notes
Dependencies
Assurance element
Assurance elements
Assurance elements
Figure 2.3 - EAL structure
ISO/IEC 15408-3 Assurance
ISO/IEC 15408-3 Assurance
requirements
levels
Assurance class
Class name
Class introduction
Evaluation assurance level
Assurance family
EAL name
Family name
Objectives
Objectives
Application notes
Component levelling
Assurance component
Component identification
Application notes
Objectives
Application notes
Assurance component
Dependencies
Component identification
Assurance element
Objectives
Assurance elements
Assurance elements
Application notes
Dependencies
Assurance element
Assurance elements
Assurance elements
Figure 2.4 - Assurance and assurance level association
2.1.5.4 Assurance components
A set of assurance components have been chosen for each EAL.
whereas narrative summaries for the ASE families can be found in ISO/IEC 15408-1, Annex C,
subclauses C.2.2 through C.2.8.
2.4 Usage of terms in ISO/IEC 15408-3
The following is a list of terms which are used in a precise way in this part of ISO/IEC 15408. 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 of
ISO/IEC 15408 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” implies a truly independent analysis, usually in the absence of
any previous analysis having been performed.
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.
© ISO/IEC ISO/IEC 15408-3:1999(E)
Exhaustive — This term is used in the standard 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.
2.5 Assurance categorisation
The assurance classes, families, and the abbreviation for each family are shown in Table 2.1.
2.6 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.
Table 2.1 -Assurance family breakdown and mapping
Assurance Class Assurance Family Abbreviated Name
CM automation ACM_AUT
Class ACM:
Configuration CM capabilities ACM_CAP
management
CM scope ACM_SCP
Delivery ADO_DEL
Class ADO: 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
Administrator guidance AGD_ADM
Class AGD: 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
2.6.1 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.
2.6.1.1 CM automation (ACM_AUT)
Configuration management automation establishes the level of automation used to control the
configuration items.
© ISO/IEC ISO/IEC 15408-3:1999(E)
2.6.1.2 CM capabilities (ACM_CAP)
Configuration management capabilities define the characteristics of the configuration management
system.
2.6.1.3 CM scope (ACM_SCP)
Configuration management scope indicates the TOE items that need to be controlled by the
configuration management system.
2.6.2 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.
2.6.2.1 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.
2.6.2.2 Installation, generation and start-up (ADO_IGS)
Installation, generation, and start-up requires tha
...