ISO/IEC 15408-2:1999

INTERNATIONAL ISO/IEC
STANDARD 15408-2
First edition
1999-12-01
Information technology — Security
techniques — Evaluation criteria for IT
security —
Part 2:
Security functional requirements
Technologies de l'information — Techniques de sécurité — Critères
d'évaluation pour la sécurité TI —
Partie 2: Exigences fonctionnelles de sécurité
Reference number
bc
©  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-2:1999(E)
vii
Contents
1 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1 Extending and maintaining functional requirements . . . . . . . . . . . . . . . . . 1
1.2 Organisation of ISO/IEC 15408-2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Functional requirements paradigm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2 Security functional components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1.1 Class structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1.2 Family structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.1.3 Component structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.1.4 Permitted functional component operations . . . . . . . . . . . . . . . . . . . . . 13
2.2 Component catalogue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2.1 Component changes highlighting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3 Class FAU: Security audit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.1 Security audit automatic response (FAU_ARP) . . . . . . . . . . . . . . . . . . . . . 18
3.2 Security audit data generation (FAU_GEN) . . . . . . . . . . . . . . . . . . . . . . . . 19
3.3 Security audit analysis (FAU_SAA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.4 Security audit review (FAU_SAR) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.5 Security audit event selection (FAU_SEL) . . . . . . . . . . . . . . . . . . . . . . . . 26
3.6 Security audit event storage (FAU_STG) . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4 Class FCO: Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.1 Non-repudiation of origin (FCO_NRO) . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.2 Non-repudiation of receipt (FCO_NRR) . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5 Class FCS: Cryptographic support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.1 Cryptographic key management (FCS_CKM) . . . . . . . . . . . . . . . . . . . . . . 38
5.2 Cryptographic operation (FCS_COP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
6 Class FDP: User data protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
6.1 Access control policy (FDP_ACC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
6.2 Access control functions (FDP_ACF) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
6.3 Data authentication (FDP_DAU) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
6.4 Export to outside TSF control (FDP_ETC) . . . . . . . . . . . . . . . . . . . . . . . . 52
6.5 Information flow control policy (FDP_IFC) . . . . . . . . . . . . . . . . . . . . . . . 54
6.6 Information flow control functions (FDP_IFF) . . . . . . . . . . . . . . . . . . . . . 56
6.7 Import from outside TSF control (FDP_ITC) . . . . . . . . . . . . . . . . . . . . . . . 61
6.8 Internal TOE transfer (FDP_ITT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
6.9 Residual information protection (FDP_RIP) . . . . . . . . . . . . . . . . . . . . . . . 66
6.10 Rollback (FDP_ROL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
6.11 Stored data integrity (FDP_SDI) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
iii
6.12 Inter-TSF user data confidentiality transfer protection (FDP_UCT) . . . . . 72
6.13 Inter-TSF user data integrity transfer protection (FDP_UIT) . . . . . . . . . . . 73
7 Class FIA: Identification and authentication . . . . . . . . . . . . . . . . . . . . . . . . 77
7.1 Authentication failures (FIA_AFL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
7.2 User attribute definition (FIA_ATD) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
7.3 Specification of secrets (FIA_SOS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
7.4 User authentication (FIA_UAU) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
7.5 User identification (FIA_UID) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
7.6 User-subject binding (FIA_USB) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
8 Class FMT: Security management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
8.1 Management of functions in TSF (FMT_MOF) . . . . . . . . . . . . . . . . . . . . . 93
8.2 Management of security attributes (FMT_MSA) . . . . . . . . . . . . . . . . . . . . 94
8.3 Management of TSF data (FMT_MTD) . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
8.4 Revocation (FMT_REV) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
8.5 Security attribute expiration (FMT_SAE) . . . . . . . . . . . . . . . . . . . . . . . . . 100
8.6 Security management roles (FMT_SMR) . . . . . . . . . . . . . . . . . . . . . . . . . . 101
9 Class FPR: Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
9.1 Anonymity (FPR_ANO) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
9.2 Pseudonymity (FPR_PSE) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
9.3 Unlinkability (FPR_UNL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
9.4 Unobservability (FPR_UNO) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
10 Class FPT: Protection of the TSF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
10.1 Underlying abstract machine test (FPT_AMT) . . . . . . . . . . . . . . . . . . . . . 118
10.2 Fail secure (FPT_FLS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
10.3 Availability of exported TSF data (FPT_ITA) . . . . . . . . . . . . . . . . . . . . . . 120
10.4 Confidentiality of exported TSF data (FPT_ITC) . . . . . . . . . . . . . . . . . . . 121
10.5 Integrity of exported TSF data (FPT_ITI) . . . . . . . . . . . . . . . . . . . . . . . . . 122
10.6 Internal TOE TSF data transfer (FPT_ITT) . . . . . . . . . . . . . . . . . . . . . . . . 124
10.7 TSF physical protection (FPT_PHP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
10.8 Trusted recovery (FPT_RCV) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
10.9 Replay detection (FPT_RPL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
10.10 Reference mediation (FPT_RVM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
10.11 Domain separation (FPT_SEP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
10.12 State synchrony protocol (FPT_SSP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
10.13 Time stamps (FPT_STM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
10.14 Inter-TSF TSF data consistency (FPT_TDC) . . . . . . . . . . . . . . . . . . . . . . . 140
10.15 Internal TOE TSF data replication consistency (FPT_TRC) . . . . . . . . . . . 141
10.16 TSF self test (FPT_TST) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
11 Class FRU: Resource utilisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
11.1 Fault tolerance (FRU_FLT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
11.2 Priority of service (FRU_PRS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
11.3 Resource allocation (FRU_RSA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
12 Class FTA: TOE access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
12.1 Limitation on scope of selectable attributes (FTA_LSA) . . . . . . . . . . . . . . 154
iv
© ISO/IEC ISO/IEC 15408-2:1999(E)
12.2 Limitation on multiple concurrent sessions (FTA_MCS) . . . . . . . . . . . . . 155
12.3 Session locking (FTA_SSL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
12.4 TOE access banners (FTA_TAB) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
12.5 TOE access history (FTA_TAH) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
12.6 TOE session establishment (FTA_TSE) . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
13 Class FTP: Trusted path/channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
13.1 Inter-TSF trusted channel (FTP_ITC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
13.2 Trusted path (FTP_TRP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
Annex A Security functional requirements application notes . . . . . . . . . . . . . . . . . . 169
A.1 Structure of the notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
A.1.1 Class structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
A.1.2 Family structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
A.1.3 Component structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
A.2 Dependency table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
Annex B Functional classes, families, and components . . . . . . . . . . . . . . . . . . . . . . . 179
Annex C Security audit (FAU) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
C.1 Security audit automatic response (FAU_ARP) . . . . . . . . . . . . . . . . . . . . . 183
C.2 Security audit data generation (FAU_GEN) . . . . . . . . . . . . . . . . . . . . . . . . 184
C.3 Security audit analysis (FAU_SAA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
C.4 Security audit review (FAU_SAR) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
C.5 Security audit event selection (FAU_SEL) . . . . . . . . . . . . . . . . . . . . . . . . 194
C.6 Security audit event storage (FAU_STG) . . . . . . . . . . . . . . . . . . . . . . . . . . 195
Annex D Communication (FCO) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
D.1 Non-repudiation of origin (FCO_NRO) . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
D.2 Non-repudiation of receipt (FCO_NRR) . . . . . . . . . . . . . . . . . . . . . . . . . . 203
Annex E Cryptographic support (FCS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
E.1 Cryptographic key management (FCS_CKM) . . . . . . . . . . . . . . . . . . . . . . 209
E.2 Cryptographic operation (FCS_COP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
Annex F User data protection (FDP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
F.1 Access control policy (FDP_ACC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
F.2 Access control functions (FDP_ACF) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
F.3 Data authentication (FDP_DAU) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
F.4 Export to outside TSF control (FDP_ETC) . . . . . . . . . . . . . . . . . . . . . . . . 227
F.5 Information flow control policy (FDP_IFC) . . . . . . . . . . . . . . . . . . . . . . . 229
F.6 Information flow control functions (FDP_IFF) . . . . . . . . . . . . . . . . . . . . . 232
F.7 Import from outside TSF control (FDP_ITC) . . . . . . . . . . . . . . . . . . . . . . . 238
F.8 Internal TOE transfer (FDP_ITT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
F.9 Residual information protection (FDP_RIP) . . . . . . . . . . . . . . . . . . . . . . . 245
F.10 Rollback (FDP_ROL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
F.11 Stored data integrity (FDP_SDI) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
F.12 Inter-TSF user data confidentiality transfer protection (FDP_UCT) . . . . . 251
F.13 Inter-TSF user data integrity transfer protection (FDP_UIT) . . . . . . . . . . . 252
v
Annex G Identification and authentication (FIA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
G.1 Authentication failures (FIA_AFL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
G.2 User attribute definition (FIA_ATD) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
G.3 Specification of secrets (FIA_SOS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
G.4 User authentication (FIA_UAU) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262
G.5 User identification (FIA_UID) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
G.6 User-subject binding (FIA_USB) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267
Annex H Security management (FMT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
H.1 Management of functions in TSF (FMT_MOF) . . . . . . . . . . . . . . . . . . . . . 271
H.2 Management of security attributes (FMT_MSA) . . . . . . . . . . . . . . . . . . . . 273
H.3 Management of TSF data (FMT_MTD) . . . . . . . . . . . . . . . . . . . . . . . . . . . 276
H.4 Revocation (FMT_REV) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278
H.5 Security attribute expiration (FMT_SAE) . . . . . . . . . . . . . . . . . . . . . . . . . 279
H.6 Security management roles (FMT_SMR) . . . . . . . . . . . . . . . . . . . . . . . . . . 280
Annex I Privacy (FPR) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
I.1 Anonymity (FPR_ANO) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285
I.2 Pseudonymity (FPR_PSE) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287
I.3 Unlinkability (FPR_UNL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292
I.4 Unobservability (FPR_UNO) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294
Annex J Protection of the TSF (FPT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
J.1 Underlying abstract machine test (FPT_AMT) . . . . . . . . . . . . . . . . . . . . . 303
J.2 Fail secure (FPT_FLS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305
J.3 Availability of exported TSF data (FPT_ITA) . . . . . . . . . . . . . . . . . . . . . . 306
J.4 Confidentiality of exported TSF data (FPT_ITC) . . . . . . . . . . . . . . . . . . . 307
J.5 Integrity of exported TSF data (FPT_ITI) . . . . . . . . . . . . . . . . . . . . . . . . . 308
J.6 Internal TOE TSF data transfer (FPT_ITT) . . . . . . . . . . . . . . . . . . . . . . . . 310
J.7 TSF physical protection (FPT_PHP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312
J.8 Trusted recovery (FPT_RCV) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314
J.9 Replay detection (FPT_RPL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317
J.10 Reference mediation (FPT_RVM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318
J.11 Domain separation (FPT_SEP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319
J.12 State synchrony protocol (FPT_SSP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321
J.13 Time stamps (FPT_STM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322
J.14 Inter-TSF TSF data consistency (FPT_TDC) . . . . . . . . . . . . . . . . . . . . . . . 323
J.15 Internal TOE TSF data replication consistency (FPT_TRC) . . . . . . . . . . . 324
J.16 TSF self test (FPT_TST) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325
Annex K Resource utilisation (FRU) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327
K.1 Fault tolerance (FRU_FLT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328
K.2 Priority of service (FRU_PRS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330
K.3 Resource allocation (FRU_RSA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331
Annex L TOE access (FTA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333
L.1 Limitation on scope of selectable attributes (FTA_LSA) . . . . . . . . . . . . . . 334
L.2 Limitation on multiple concurrent sessions (FTA_MCS) . . . . . . . . . . . . . 335
L.3 Session locking (FTA_SSL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336
L.4 TOE access banners (FTA_TAB) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338
vi
© ISO/IEC ISO/IEC 15408-2:1999(E)
L.5 TOE access history (FTA_TAH) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339
L.6 TOE session establishment (FTA_TSE) . . . . . . . . . . . . . . . . . . . . . . . . . . . 340
Annex M Trusted path/channels (FTP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341
M.1 Inter-TSF trusted channel (FTP_ITC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342
M.2 Trusted path (FTP_TRP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343
vii
reflecting the needs of the market. These security functional requirements are presented as the
current state of the art in requirements specification and evaluation.
This part of ISO/IEC 15408 does not presume to include all possible security functional
requirements but rather contains those that are known and agreed to be of value by the ISO/IEC
15408-2 authors at the time of release.
Since the understanding and needs of consumers may change, the functional requirements in this
part of ISO/IEC 15408 will need to be maintained. It is envisioned that some PP/ST authors may
have security needs not (yet) covered by the functional requirement components in ISO/IEC
15408-2. In those cases the PP/ST author may choose to consider using functional requirements
not taken from the standard (referred to as extensibility), as explained in Annexes B and C of ISO/
IEC 15408-1.
1.2 Organisation of ISO/IEC 15408-2
Clause 1 is the introductory material for ISO/IEC 15408-2.
Clause 2 introduces the catalogue of ISO/IEC 15408-2 functional components while clauses 3
through 13 describe the functional classes.
Annex A provides additional information of interest to potential users of the functional
components including a complete cross reference table of the functional component dependencies.
Annexes B through M provide the application notes for the functional classes. They are a
repository for informative supporting material for the users of this part of ISO/IEC 15408, which
may help them to apply relevant operations and select appropriate audit or documentation
information.
Those who author PPs or STs should refer to Clause 2 of ISO/IEC 15408-1 for relevant structures,
rules, and guidance:
- ISO/IEC 15408-1, clause 2 defines the terms used in ISO/IEC 15408.
- ISO/IEC 15408-1, Annex B defines the structure for PPs.
- ISO/IEC 15408-1, Annex C defines the structure for STs.
1.3 Functional requirements paradigm
This subclause describes the paradigm used in the security functional requirements of this part of
ISO/IEC 15408. Figures 1.1 and 1.2 depict some of the key concepts of the paradigm. This
subclause provides descriptive text for those figures and for other key concepts not depicted. Key
concepts discussed are highlighted in bold/italics. This subclause is not intended to replace or
supersede any of the terms found in the ISO/IEC 15408 glossary in ISO/IEC 15408-1, clause 2.
©ISO/IEC ISO/IEC 15408-2:1999(E)

Target of Evaluation (TOE)
TOE Security Functions Interface (TSFI)
Human
TOE Security Functions
User
Security
(TSF)
/ Remote IT
Attributes
Product
Enforces TOE Security Policy
Subject
(TSP)
Object/
Subject
Information
Subject
Security
Security
Attributes
Security
Attributes
Attributes
Security Resource Process
User Attributes
Subject
TSF Scope of Control (TSC)
Figure 1.1 - Security functional requirements paradigm (Monolithic TOE)
This part of ISO/IEC 15408 is a catalogue of security functional requirements that can be specified
for a Target of Evaluation (TOE). A TOE is an IT product or system (along with user and
administrator guidance documentation) containing resources such as electronic storage media (e.g.
disks), peripheral devices (e.g. printers), and computing capacity (e.g. CPU time) that can be used
for processing and storing information and is the subject of an evaluation.
TOE evaluation is concerned primarily with ensuring that a defined TOE Security Policy (TSP) is
enforced over the TOE resources. The TSP defines the rules by which the TOE governs access to
its resources, and thus all information and services controlled by the TOE.
The TSP is, in turn, made up of multiple Security Function Policies (SFPs). Each SFP has a scope
of control, that defines the subjects, objects, and operations controlled under the SFP. The SFP is
implemented by a Security Function (SF), whose mechanisms enforce the policy and provide
necessary capabilities.
Local (Internal TOE)
Local User
Trusted Path
Internal TOE Transfer
SF
SF
SF
SF
SF SF
Local TOE
Inter-TSF
Transfers
Transfer
Outside TSF
Control
Inter-TSF
Trusted
RF: Remote
Path
Function
Untrusted IT Product
Remote Trusted IT Product
Remote User
Figure 1.2 - Diagram of security functions in a distributed TOE
Those portions of a TOE that must be relied on for the correct enforcement of the TSP are
collectively referred to as the TOE Security Functions (TSF). The TSF consists of all hardware,
software, and firmware of a TOE that is either directly or indirectly relied upon for security
enforcement.
A reference monitor is an abstract machine that enforces the access control policies of a TOE. A
reference validation mechanism is an implementation of the reference monitor concept that
possesses the following properties: tamperproof, always invoked, and simple enough to be
subjected to thorough analysis and testing. The TSF may consist of a reference validation
mechanism and/or other security functions necessary for the operation of the TOE.
The TOE may be a monolithic product containing hardware, firmware, and software.
Alternatively a TOE may be a distributed product that consists internally of multiple separated
parts. Each of these parts of the TOE provides a particular service for the TOE, and is connected
to the other parts of the TOE through an internal communication channel. This channel can be as
small as a processor bus, or may encompass a network internal to the TOE.
©ISO/IEC ISO/IEC 15408-2:1999(E)

When the TOE consists of multiple parts, each part of the TOE may have its own part of the TSF
which exchanges user and TSF data over internal communication channels with other parts of the
TSF. This interaction is called internal TOE transfer. In this case the separate parts of the TSF
abstractly form the composite TSF, which enforces the TSP.
TOE interfaces may be localised to the particular TOE, or they may allow interaction with other
IT products over external communication channels. These external interactions with other IT
products may take two forms:
a) The security policy of the ‘remote trusted IT product’ and the TSP of the local TOEs
have been administratively coordinated and evaluated. Exchanges of information in
this situation are called inter-TSF transfers, as they are between the TSFs of distinct
trusted products.
b) The remote IT product may not be evaluated, indicated in Figure 1.2 as ‘untrusted IT
product’, therefore its security policy is unknown. Exchanges of information in this
situation are called transfers outside TSF control, as there is no TSF (or its policy
characteristics are unknown) on the remote IT product.
The set of interactions that can occur with or within a TOE and are subject to the rules of the TSP
is called the TSF Scope of Control (TSC). The TSC encompasses a defined set of interactions
based on subjects, objects, and operations within the TOE, but it need not encompass all resources
of a TOE.
The set of interfaces, whether interactive (man-machine interface) or programmatic (application
programming interface), through which resources are accessed that are mediated by the TSF, or
information is obtained from the TSF, is referred to as the TSF Interface (TSFI). The TSFI defines
the boundaries of the TOE functions that provide for the enforcement of the TSP.
Users are outside of the TOE, and therefore outside of the TSC. However, in order to request that
services be performed by the TOE, users interact with the TOE through the TSFI. There are two
types of users of interest to the ISO/IEC 15408-2 security functional requirements: human users
and external IT entities. Human users are further differentiated as local human users, meaning
they interact directly with the TOE via TOE devices (e.g. workstations), or remote human users,
meaning they interact indirectly with the TOE through another IT product.
A period of interaction between users and the TSF is referred to as a user session. Establishment
of user sessions can be controlled based on a variety of considerations, for example: user
authentication, time of day, method of accessing the TOE, and number of allowed concurrent
sessions per user.
This part of ISO/IEC 15408 uses the term authorised to signify a user who possesses the rights
and/or privileges necessary to perform an operation. The term authorised user, therefore, indicates
that it is allowable for a user to perform an operation as defined by the TSP.
To express requirements that call for the separation of administrator duties, the relevant ISO/IEC
15408-2 security functional components (from family FMT_SMR) explicitly state that
administrative roles are required. A role is a pre-defined set of rules establishing the allowed
interactions between a user and the TOE. A TOE may support the definition of any number of roles.
For example, roles related to the secure operation of a TOE may include “Audit Administrator”
and “User Accounts Administrator”.
TOEs contain resources that may be used for the processing and storing of information. The
primary goal of the TSF is the complete and correct enforcement of the TSP over the resources and
information that the TOE controls.
TOE resources can be structured and utilised in many different ways. However, ISO/IEC 15408-2
makes a specific distinction that allows for the specification of desired security properties. All
entities that can be created from resources can be characterised in one of two ways. The entities
may be active, meaning that they are the cause of actions that occur internal to the TOE and cause
operations to be performed on information. Alternatively, the entities may be passive, meaning that
they are either the container from which information originates or to which information is stored.
Active entities are referred to as subjects. Several types of subjects may exist within a TOE:
a) those acting on behalf of an authorised user and which are subject to all the rules of the
TSP (e.g. UNIX processes);
b) those acting as a specific functional process that may in turn act on behalf of multiple
users (e.g. functions as might be found in client/server architectures); or
c) those acting as part of the TOE itself (e.g. trusted processes).
ISO/IEC 15408-2 addresses the enforcement of the TSP over types of subjects as those listed
above.
Passive entities (i.e. information containers) are referred to in the ISO/IEC 15408-2 security
functional requirements as objects. Objects are the targets of operations that may be performed by
subjects. In the case where a subject (an active entity) is the target of an operation (e.g. interprocess
communication), a subject may also be acted on as an object.
Objects can contain information. This concept is required to specify information flow control
policies as addressed in the FDP class.
Users, subjects, information and objects possess certain attributes that contain information that
allows the TOE to behave correctly. Some attributes, such as file names, may be intended to be
informational (i.e. to increase the user-friendliness of the TOE) while others, such as access control
information, may exist specifically for the enforcement of the TSP. These latter attributes are
generally referred to as ‘security attributes’. The word attribute will be used as a shorthand in this
part of ISO/IEC 15408 for the word ‘security attribute’, unless otherwise indicated. However, no
matter what the intended purpose of the attribute information, it may be necessary to have controls
on attributes as dictated by the TSP.
Data in a TOE is categorised as either user data or TSF data. Figure 1.3 depicts this relationship.
User Data is information stored in TOE resources that can be operated upon by users in accordance
with the TSP and upon which the TSF places no special meaning. For example, the contents of an
electronic mail message is user data. TSF Data is information used by the TSF in making TSP
decisions. TSF Data may be influenced by users if allowed by the TSP. Security attributes,
authentication data and access control list entries are examples of TSF data.
There are several SFPs that apply to data protection such as access control SFPs and information
flow control SFPs. The mechanisms that implement access control SFPs base their policy
decisions on attributes of the subjects, objects and operations within the scope of control. These
attributes are used in the set of rules that govern operations that subjects may perform on objects.
©ISO/IEC ISO/IEC 15408-2:1999(E)

The mechanisms that implement information flow control SFPs base their policy decisions on the
attributes of the subjects and information within the scope of control and the set of rules that govern
the operations by subjects on information. The attributes of the information, which may be
associated with the attributes of the container (or may not, as in the case of a multi-level database)
stay with the information as it moves.
TOE DATA
Security Attributes
TSF DATA
User Attributes
Object Attributes
Authentication
USER DATA
Data
Subject Attributes
Information Attributes
Figure 1.3 - Relationship between user data and TSF data
Two specific types of TSF data addressed by ISO/IEC 15408-2 can be, but are not necessarily, the
same. These are authentication data and secrets.
Authentication data is used to verify the claimed identity of a user requesting services from a TOE.
The most common form of authentication data is the password, which depends on being kept secret
in order to be an effective security mechanism. However, not all forms of authentication data need
to be kept secret. Biometric authentication devices (e.g. fingerprint readers, retinal scanners) do not
rely on the fact that the data is kept secret, but rather that the data is something that only one user
possesses and that cannot be forged.
The term secrets, as used in ISO/IEC 15408-2 functional requirements, while applicable to
authentication data, is intended to also be applicable to other types of data that must be kept secret
in order to enforce a specific SFP. For example, a trusted channel mechanism that relies on
cryptography to preserve the confidentiality of information being transmitted via the channel can
only be as strong as the method used to keep the cryptographic keys secret from unauthorised
disclosure.
Therefore, some, but not all, authentication data needs to be kept secret and some, but not all,
secrets are used as authentication data. Figure 1.4 shows this relationship between secrets and
authentication data. In the Figure the types of data typically encountered in the authentication data
and the secrets sections are indicated.
AUTHENTICATION DATA
BIOMETRICS
SMART CARDS
PASSWORDS
CRYPTO VARIABLES
SECRETS
Figure 1.4 - Relationship between “authentication data” and “secrets”
©ISO/IEC ISO/IEC 15408-2:1999(E)
2 Security functional components
2.1 Overview
This clause defines the content and presentation of the functional requirements of ISO/IEC 15408,
and provides guidance on the organisation of the requirements for new components to be included
in an ST. The functional requirements are expressed in classes, families, and components.
2.1.1 Class structure
Figure 2.1 illustrates the functional class structure in diagrammatic form. Each functional class
includes a class name, class introduction, and one or more functional families.
Functional
Class
Class
Name
Class
Introduction
A
B
Key
C
Functional
l
A contains B plus a number of C

Families
Figure 2.1 - Functional class structure
2.1.1.1 Class name
The class name subclause provides information necessary to identify and categorise a functional
class. Every functional class has a unique name. The categorical information consists of a short
name of three characters. The short name of the class is used in the specification of the short names
of the families of that class.
2.1.1.2 Class introduction
The class introduction expresses the common intent or approach of those families to satisfy
security objectives. The definition of functional classes does not reflect any formal taxonomy in
the specification of the requirements.
The class introduction provides a figure describing the families in this class and the hierarchy of
the components in each family, as explained in 2.2.
2.1.2 Family structure
Figure 2.2 illustrates the functional family structure in diagrammatic form.
Functional
Family Family name
Family behaviour
Component levelling
Management
Audit
Components
Figure 2.2 - Functional family structure
2.1.2.1 Family name
The family name subclause provides categorical and descriptive information necessary to identify
and categorise a functional family. Every functional family has a unique name. The categorical
information consists of a short name of seven characters, with the first three identical to the short
name of the class followed by an underscore and the short name of the family as follows
XXX_YYY. The unique short form of the family name provides the principal reference name for
the components.
2.1.2.2 Family behaviour
The family behaviour is the narrative description of the functional family stating its security
objective and a general description of the functional requirements. These are described in greater
detail below:
a) The security objectives of the family address a security problem that may be solved
with the help of a TOE that incorporates a component of this family;
b) The description of the functional requirements summarises all the requirements that
are included in the component(s). The description is aimed at authors of PPs, STs and
functional packages who wish to assess whether the family is relevant to their specific
requirements.
©ISO/IEC ISO/IEC 15408-2:1999(E)

2.1.2.3 Component levelling
Functional families contain one or more components, any one of which can be selected for
inclusion in PPs, STs and functional packages. The goal of this section is to provide information
to users in selecting an appropriate functional component once the family has been identified as
being a necessary or useful part of their security requirements.
This section of the functional family description describes the components available, and their
rationale. The exact details of the components are contained within each component.
The relationships between components within a functional family may or may not be hierarchical.
A component is hierarchical to another if it offers more security.
As explained in 2.2 the descriptions of the families provide a graphical overview of the hierarchy
of the components in a family.
2.1.2.4 Management
The management requirements contain information for the PP/ST authors to consider as
management activities for a given component. The management requirements are detailed in
components of the management class (FMT).
A PP/ST author may select the indicated management requirements or may include other
management requirements not listed. As such the information should be considered informative.
2.1.2.5 Audit
The audit requirements contain auditable events for the PP/ST authors to select, if requirements
from the class FAU, Security audit, are included in the PP/ST. These requirements include security
relevant events in terms of the various levels of detail supported by the components of the
FAU_GEN Security audit data generation family. For example, an audit note might include
actions that are in terms of: Minimal - successful use of the security mechanism; Basic - any use
of the security mechanism as well as relevant information regarding the security attributes
involved; Detailed - any configuration changes made to the mechanism, including the actual
configuration values before and after the change.
It should be observed that the categorisation of auditable events is hierarchical. For example, when
Basic Audit Generation is desired, all auditable events identified as being both Minimal and Basic
should be included in the PP/ST through the use of the appropriate assignment operation, except
when the higher level event simply provides more detail than the lower level event. When Detailed
Audit Generation is desired, all identified auditable events (Minimal, Basic and Detailed) should
be included in the PP/ST.
In the class FAU the rules governing the audit are explained in more detail.
2.1.3 Component structure
Figure 2.3 illustrates the functional component structure.
Component
Component
Identification
Functional
Elements
Dependencies
Figure 2.3 - Functional component structure
2.1.3.1 Component identification
The component identification subclause provides descriptive information necessary to identify,
categorise, register and cross-reference a component. The following is provided as part of every
functional component:
A unique name. The name reflects the purpose of the component.
A short name. A unique short form of the functional component name. This short name serves as
the principal reference name for the categorisation, registration and cross-referencing of the
component. This short name reflects the class and family to which the component belongs and the
component number within the family.
A hierarchical-to list. A list of other components that this component is hierarchical to and for
which this component can be used to satisfy dependencies to the listed components.
2.1.3.2 Functional elements
A set of elements is provided for each component. Each element is individually defined and is self-
contained.
A functional element is a security functional requirement that if further divided would not yield a
meaningful evaluation result. It is the smallest security functional requirement identified and
recognised in ISO/IEC 15408.
When building packages, PPs and/or STs, it is not permitted to select only one or more elements
from a component. The complete set of elements of a component must be selected for inclusion in
a PP, ST or package.
A unique short form of the functional element name is provided. For example the requirement
name FDP_IFF.4.2 reads as follows: F - functional requirement, DP - class “User data protection”,
_IFF - family “Information flow control functions”, .4 - 4th component named “Partial elimination
of illicit information flows”, .2 - 2nd element of the component.
©ISO/IEC ISO/IEC 15408-2:1999(E)

2.1.3.3 Dependencies
Dependencies among functional components arise when a component is not self sufficient and
relies upon the functionality of, or interaction with, another component for its own proper
functioning.
Each functional component provides a complete list of dependencies to other functional and
assurance components. Some components may list “No dependencies”. The components depended
upon may in turn have dependencies on other components. The list provided in the components
will be the direct dependencies. That is only references to the functional requirements that are
required for this requirement to perform its job properly. The indirect dependencies, that is the
dependencies that result from the depended upon components can be found in Annex A of this part
of ISO/IEC 15408. It is noted that in some cases the dependency is optional in that a number of
functional requirements are provided, where each one of them would be sufficient to satisfy the
dependency (see for example FDP_UIT.1).
The dependency list identifies the minimum functional or assurance components needed to satisfy
the security requirements associated with an identified component. Components that are
hierarchical to the identified component may also be used to satisfy the dependency.
The dependencies indicated in ISO/IEC 15408-2 are normative. They must be satisfied within a
PP/ST. In specific situations the indicated dependencies might not be applicable. The PP/ST
author, by providing the rationale why it is not applicable, may leave the depended upon
component out of the package, PP or ST.
2.1.4 Permitted functional component operations
The functional components used in the definition of the requirements in a PP, an ST or a functional
package may be exactly as specified in clauses 3 to 13 of this part of ISO/IEC 15408, or they may
be tailored to meet a specific security objective. However, selecting and tailoring these functional
components is complicated by the fact that identified component dependencies must be considered.
Thus, this tailoring is restricted to an approved set of operations.
A list of permitted operations is included with each functional component. Not all operations are
permitted on all functional components.
The permitted operations are selected from the following set:
- iteration: allows a component to be used more than once with varying operations,
- assignment: allows the specification of an identified parameter,
- selection: allows the specification of one or more elements from a list,
- refinement: allows the addition of details.
2.1.4.1 Iteration
Where necessary to cover different aspects of the same requirement (e.g. identification of more
than one type of user), repetitive use of the same component from this part of ISO/IEC 15408 to
cover each aspect is permitted.
...