Common Criteria for Information Technology
Security Evaluation

Part 1: Introduction and general model
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:
France:
Germany:
Netherlands:
Communications Security Establishment
Service Central de la Sécurité des Systèmes d’Information
Bundesamt für Sicherheit in der Informationstechnik
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 1: Introduction and general model iv
1
2
2.1
2.2
2.3
4.3
4.3.1
4.3.2
4.3.3
4.3.4
4.3.5
4.4
4
4.1
4.1.1
4.1.2
4.2
4.2.1
4.2.2
4.2.3
4.4.1
4.4.2
4.4.3
4.5
4.5.1
4.5.2
4.5.3
4.6
3
3.1
3.2
3.2.1
3.2.2
3.2.3
3.2.4
3.3
3.4
5
5.1
5.2
5.2.1
5.3
5.3.1
August 1999
Contents
Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Common abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Scope of glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Target audience of the CC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Consumers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Developers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Evaluators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Others . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Evaluation context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Organisation of the Common Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
General model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Security context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
General security context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Information technology security context . . . . . . . . . . . . . . . . . . . . . . . 16
Common Criteria approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
TOE evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Security concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Security environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Security objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
IT security requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
TOE summary specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
TOE implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
CC descriptive material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Expression of security requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Use of security requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Sources of security requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Types of evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
PP evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
ST evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
TOE evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Assurance maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Common Criteria requirements and evaluation results . . . . . . . . . . . . . . . 30
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Requirements in PPs and STs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
PP evaluation results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Requirements in TOE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
TOE evaluation results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Version 2.1
Page iii of vi

Contents Part 1: Introduction and general model
5.4
5.5
Annex A
A.1
A.2
A.3
Annex B
B.1
B.2
B.2.1
B.2.2
B.2.3
B.2.4
B.2.5
B.2.6
B.2.7
B.2.8
Annex C
C.1
C.2
C.2.1
C.2.2
C.2.3
C.2.4
C.2.5
C.2.6
C.2.7
C.2.8
C.2.9
Annex D
Caveats on evaluation results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Use of TOE evaluation results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
The Common Criteria project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Development of the Common Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Sponsoring organisations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Specification of Protection Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Content of Protection Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Content and presentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
PP introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
TOE description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
TOE security environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Security objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
IT security requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Application notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Specification of Security Targets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Content of Security Target . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Content and presentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
ST introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
TOE description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
TOE security environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Security objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
IT security requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
TOE summary specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
PP claims . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Page iv of vi Version 2.1
August 1999

Part 1: Introduction and general model
Figure 3.1 Evaluation context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Figure 4.1 Security concepts and relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Figure 4.2 Evaluation concepts and relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Figure 4.3 TOE development model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Figure 4.4 TOE evaluation process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Figure 4.5 Derivation of requirements and specifications . . . . . . . . . . . . . . . . . . . . . . . . . 21
Figure 4.6 Organisation and construction of requirements . . . . . . . . . . . . . . . . . . . . . . . . 25
Figure 4.7 Use of security requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Figure 5.1 Evaluation results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Figure 5.2 Use of TOE evaluation results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Figure B.1 - Protection Profile content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Figure C.1 - Security Target content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
August 1999 Version 2.1
Page v of vi

Part 1: Introduction and general model
Table 3.1 Roadmap to the Common Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Page vi of vi Version 2.1
August 1999

2
3
4
5
6
1
Part 1: Introduction and general model 2
This multipart standard, the Common Criteria (CC), is meant to be used as the basis for evaluation of security properties of IT products and systems. By establishing such a common criteria base, the results of an IT security evaluation will be meaningful to a wider audience.
The CC will permit comparability between the results of independent security evaluations. It does so by providing a common set of requirements for the security functions of IT products and systems and for assurance measures applied to them during a security evaluation. The evaluation process establishes a level of confidence that the security functions of such products and systems and the assurance measures applied to them meet these requirements. The evaluation results may help consumers to determine whether the IT product or system is secure enough for their intended application and whether the security risks implicit in its use are tolerable.
The CC is useful as a guide for the development of products or systems with IT security functions and for the procurement of commercial products and systems with such functions. During evaluation, such an IT product or system is known as a Target of Evaluation (TOE). Such TOEs include, for example, operating systems, computer networks, distributed systems, and applications.
The CC addresses protection of information from unauthorised disclosure, modification, or loss of use. The categories of protection relating to these three types of failure of security are commonly called confidentiality, integrity, and availability, respectively. The CC may also be applicable to aspects of IT security outside of these three. The CC concentrates on threats to that information arising from human activities, whether malicious or otherwise, but may be applicable to some non-human threats as well. In addition, the CC may be applied in other areas of IT, but makes no claim of competence outside the strict domain of IT security.
The CC is applicable to IT security measures implemented in hardware, firmware or software. Where particular aspects of evaluation are intended only to apply to certain methods of implementation, this will be indicated within the relevant criteria statements.
Certain topics, because they involve specialised techniques or because they are somewhat peripheral to IT security, are considered to be outside the scope of the
CC. Some of these are identified below.
a) The CC does not contain security evaluation criteria pertaining to administrative security measures not related directly to the IT security measures. However, it is recognised that a significant part of the security of a TOE can often be achieved through administrative measures such as organisational, personnel, physical, and procedural controls. Administrative security measures in the operating environment of the TOE are treated as
August 1999 Version 2.1
Page 1 of 56

1 - Scope b) c) d) e) secure usage assumptions where these have an impact on the ability of the
IT security measures to counter the identified threats.
The evaluation of technical physical aspects of IT security such as electromagnetic emanation control is not specifically covered, although many of the concepts addressed will be applicable to that area. In particular, the CC addresses some aspects of physical protection of the TOE.
The CC addresses neither the evaluation methodology nor the administrative and legal framework under which the criteria may be applied by evaluation authorities. However, it is expected that the CC will be used for evaluation purposes in the context of such a framework and such a methodology.
The procedures for use of evaluation results in product or system accreditation are outside the scope of the CC. Product or system accreditation is the administrative process whereby authority is granted for the operation of an IT product or system in its full operational environment.
Evaluation focuses on the IT security parts of the product or system and those parts of the operational environment that may directly affect the secure use of IT elements. The results of the evaluation process are consequently a valuable input to the accreditation process. However, as other techniques are more appropriate for the assessments of non-IT related product or system security properties and their relationship to the IT security parts, accreditors should make separate provision for those aspects.
The subject of criteria for the assessment of the inherent qualities of cryptographic algorithms is not covered in the CC. Should independent assessment of mathematical properties of cryptography embedded in a TOE be required, the evaluation scheme under which the CC is applied must make provision for such assessments.
Page 2 of 56 Version 2.1
August 1999

Part 1: Introduction and general model 7 Common abbreviations
7
8
The following abbreviations are common to more than one part of the CC:
CC Common Criteria
EAL Evaluation Assurance Level
IT Information Technology
PP Protection Profile
SF Security Function
SFP Security Function Policy
SOF Strength of Function
ST Security Target
TOE Target of Evaluation
TSC TSF Scope of Control
TSF TOE Security Functions
TSFI TSF Interface
TSP TOE Security Policy
This subclause 2.2 contains only those terms which are used in a specialised way throughout the CC. The majority of terms in the CC are used either according to their accepted dictionary definitions or according to commonly accepted definitions that may be found in ISO security glossaries or other well-known collections of security terms. Some combinations of common terms used in the CC, while not meriting glossary definition, are explained for clarity in the context where they are used. Explanations of the use of terms and concepts used in a specialised way in CC
Part 2 and CC Part 3 can be found in their respective “paradigm” subclauses.
August 1999 Version 2.1
Page 3 of 56

2 - Definitions Glossary
19
20
21
22
16
17
18
13
14
15
23
24
10
11
12
9
Assets — Information or resources to be protected by the countermeasures of a
TOE.
Assignment — The specification of an identified parameter in a component.
Assurance — Grounds for confidence that an entity meets its security objectives.
Attack potential — The perceived potential for success of an attack, should an attack be launched, expressed in terms of an attacker’s expertise, resources and motivation.
Augmentation — The addition of one or more assurance component(s) from Part 3 to an EAL or assurance package.
Authentication data — Information used to verify the claimed identity of a user.
Authorised user — A user who may, in accordance with the TSP, perform an operation.
Class — A grouping of families that share a common focus.
Component — The smallest selectable set of elements that may be included in a
PP, an ST, or a package.
Connectivity — The property of the TOE which allows interaction with IT entities external to the TOE. This includes exchange of data by wire or by wireless means, over any distance in any environment or configuration.
Dependency — A relationship between requirements such that the requirement that is depended upon must normally be satisfied for the other requirements to be able to meet their objectives.
Element — An indivisible security requirement.
Evaluation — Assessment of a PP, an ST or a TOE, against defined criteria.
Evaluation Assurance Level (EAL) — A package consisting of assurance components from Part 3 that represents a point on the CC predefined assurance scale.
Evaluation authority — A body that implements the CC for a specific community by means of an evaluation scheme and thereby sets the standards and monitors the quality of evaluations conducted by bodies within that community.
Evaluation scheme — The administrative and regulatory framework under which the CC is applied by an evaluation authority within a specific community.
Page 4 of 56 Version 2.1
August 1999

31
32
29
30
33
34
25
26
27
28
38
39
40
41
35
36
37
Glossary 2 - Definitions
Extension — The addition to an ST or PP of functional requirements not contained in Part 2 and/or assurance requirements not contained in Part 3 of the CC.
External IT entity — Any IT product or system, untrusted or trusted, outside of the TOE that interacts with the TOE.
Family — A grouping of components that share security objectives but may differ in emphasis or rigour.
Formal — Expressed in a restricted syntax language with defined semantics based on well-established mathematical concepts.
Human user — Any person who interacts with the TOE.
Identity — A representation (e.g. a string) uniquely identifying an authorised user, which can either be the full or abbreviated name of that user or a pseudonym.
Informal — Expressed in natural language.
Internal communication channel — A communication channel between separated parts of TOE.
Internal TOE transfer — Communicating data between separated parts of the
TOE.
Inter-TSF transfers — Communicating data between the TOE and the security functions of other trusted IT products.
Iteration — The use of a component more than once with varying operations.
Object — An entity within the TSC that contains or receives information and upon which subjects perform operations.
Organisational security policies — One or more security rules, procedures, practices, or guidelines imposed by an organisation upon its operations.
Package — A reusable set of either functional or assurance components (e.g. an
EAL), combined together to satisfy a set of identified security objectives.
Product — A package of IT software, firmware and/or hardware, providing functionality designed for use or incorporation within a multiplicity of systems.
Protection Profile (PP) — An implementation-independent set of security requirements for a category of TOEs that meet specific consumer needs.
Reference monitor — The concept of an abstract machine that enforces TOE access control policies.
August 1999 Version 2.1
Page 5 of 56

2 - Definitions Glossary
57
58
48
49
50
51
52
53
46
47
43
44
45
42
54
55
56
Page 6 of 56
Reference validation mechanism — An implementation of the reference monitor concept that possesses the following properties: it is tamperproof, always invoked, and simple enough to be subjected to thorough analysis and testing.
Refinement — The addition of details to a component.
Role — A predefined set of rules establishing the allowed interactions between a user and the TOE.
Secret — Information that must be known only to authorised users and/or the TSF in order to enforce a specific SFP.
Security attribute — Information associated with subjects, users and/or objects that is used for the enforcement of the TSP.
Security Function (SF) — A part or parts of the TOE that have to be relied upon for enforcing a closely related subset of the rules from the TSP.
Security Function Policy (SFP) — The security policy enforced by an SF.
Security objective — A statement of intent to counter identified threats and/or satisfy identified organisation security policies and assumptions.
Security Target (ST) — A set of security requirements and specifications to be used as the basis for evaluation of an identified TOE.
Selection — The specification of one or more items from a list in a component.
Semiformal — Expressed in a restricted syntax language with defined semantics.
Strength of Function (SOF) — A qualification of a TOE security function expressing the minimum efforts assumed necessary to defeat its expected security behaviour by directly attacking its underlying security mechanisms.
SOF-basic — A level of the TOE strength of function where analysis shows that the function provides adequate protection against casual breach of TOE security by attackers possessing a low attack potential.
SOF-medium — A level of the TOE strength of function where analysis shows that the function provides adequate protection against straightforward or intentional breach of TOE security by attackers possessing a moderate attack potential.
SOF-high — A level of the TOE strength of function where analysis shows that the function provides adequate protection against deliberately planned or organised breach of TOE security by attackers possessing a high attack potential.
Subject — An entity within the TSC that causes operations to be performed.
System — A specific IT installation, with a particular purpose and operational environment.
Version 2.1
August 1999

59
60
61
62
70
71
68
69
65
66
63
64
67
Glossary 2 - Definitions
Target of Evaluation (TOE) — An IT product or system and its associated administrator and user guidance documentation that is the subject of an evaluation.
TOE resource — Anything useable or consumable in the TOE.
TOE Security Functions (TSF) — A set consisting of all hardware, software, and firmware of the TOE that must be relied upon for the correct enforcement of the
TSP.
TOE Security Functions Interface (TSFI) — A set of interfaces, whether interactive (man-machine interface) or programmatic (application programming interface), through which TOE resources are accessed, mediated by the TSF, or information is obtained from the TSF.
TOE Security Policy (TSP) — A set of rules that regulate how assets are managed, protected and distributed within a TOE.
TOE security policy model — A structured representation of the security policy to be enforced by the TOE.
Transfers outside TSF control — Communicating data to entities not under control of the TSF.
Trusted channel — A means by which a TSF and a remote trusted IT product can communicate with necessary confidence to support the TSP.
Trusted path — A means by which a user and a TSF can communicate with necessary confidence to support the TSP.
TSF data — Data created by and for the TOE, that might affect the operation of the
TOE.
TSF Scope of Control (TSC) — The set of interactions that can occur with or within a TOE and are subject to the rules of the TSP.
User — Any entity (human user or external IT entity) outside the TOE that interacts with the TOE.
User data — Data created by and for the user, that does not affect the operation of the TSF.
August 1999 Version 2.1
Page 7 of 56

Part 1: Introduction and general model 12 Introduction
72
73
74
75
76
3.2.1
77
78
This clause introduces the main concepts of the CC. It identifies the target audience, evaluation context, and the approach taken to present the material.
Information held by IT products or systems is a critical resource that enables organisations to succeed in their mission. Additionally, individuals have a reasonable expectation that their personal information contained in IT products or systems remain private, be available to them as needed, and not be subject to unauthorised modification. IT products or systems should perform their functions while exercising proper control of the information to ensure it is protected against hazards such as unwanted or unwarranted dissemination, alteration, or loss. The term IT security is used to cover prevention and mitigation of these and similar hazards.
Many consumers of IT lack the knowledge, expertise or resources necessary to judge whether their confidence in the security of their IT products or systems is appropriate, and they may not wish to rely solely on the assertions of the developers.
Consumers may therefore choose to increase their confidence in the security measures of an IT product or system by ordering an analysis of its security (i.e. a security evaluation).
The CC can be used to select the appropriate IT security measures and it contains criteria for evaluation of security requirements.
There are three groups with a general interest in evaluation of the security properties of IT products and systems: TOE consumers, TOE developers, and TOE evaluators.
The criteria presented in this document have been structured to support the needs of all three groups. They are all considered to be the principal users of this CC. The three groups can benefit from the criteria as explained in the following paragraphs.
Consumers
The CC plays an important role in supporting techniques for consumer selection of
IT security requirements to express their organisational needs. The CC is written to ensure that evaluation fulfils the needs of the consumers as this is the fundamental purpose and justification for the evaluation process.
Consumers can use the results of evaluations to help decide whether an evaluated product or system fulfils their security needs. These security needs are typically identified as a result of both risk analysis and policy direction. Consumers can also
August 1999 Version 2.1
Page 8 of 56

Target audience of the CC 3 - Overview
79
3.2.2
80
81
82
3.2.3
83
3.2.4
84 use the evaluation results to compare different products or systems. Presentation of the assurance requirements within a hierarchy supports this need.
The CC gives consumers — especially in consumer groups and communities of interest — an implementation-independent structure termed the Protection Profile
(PP) in which to express their special requirements for IT security measures in a
TOE.
Developers
The CC is intended to support developers in preparing for and assisting in the evaluation of their products or systems and in identifying security requirements to be satisfied by each of their products or systems. It is also quite possible that an associated evaluation methodology, potentially accompanied by a mutual recognition agreement for evaluation results, would further permit the CC to support someone, other than the TOE developer, in preparing for and assisting in the evaluation of a developer’s TOE.
The CC constructs can then be used to make claims that the TOE conforms to its identified requirements by means of specified security functions and assurances to be evaluated. Each TOE’s requirements are contained in an implementationdependent construct termed the Security Target (ST). One or more PPs may provide the requirements of a broad consumer base.
The CC describes security functions that a developer could include in the TOE. The
CC can be used to determine the responsibilities and actions to support evidence that is necessary to support the evaluation of the TOE. It also defines the content and presentation of that evidence.
Evaluators
The CC contains criteria to be used by evaluators when forming judgements about the conformance of TOEs to their security requirements. The CC describes the set of general actions the evaluator is to carry out and the security functions on which to perform these actions. Note that the CC does not specify procedures to be followed in carrying out those actions.
Others
While the CC is oriented towards specification and evaluation of the IT security properties of TOEs, it may also be useful as reference material to all parties with an interest in or responsibility for IT security. Some of the additional interest groups that can benefit from information contained in the CC are: a) b) system custodians and system security officers responsible for determining and meeting organisational IT security policies and requirements; auditors, both internal and external, responsible for assessing the adequacy of the security of a system;
August 1999 Version 2.1
Page 9 of 56

3 - Overview Evaluation context
85
86
87
88 c) d) e) f) security architects and designers responsible for the specification of the security content of IT systems and products; accreditors responsible for accepting an IT system for use within a particular environment; sponsors of evaluation responsible for requesting and supporting an evaluation; and evaluation authorities responsible for the management and oversight of IT security evaluation programmes.
In order to achieve greater comparability between evaluation results, evaluations should be performed within the framework of an authoritative evaluation scheme that sets the standards, monitors the quality of the evaluations and administers the regulations to which the evaluation facilities and evaluators must conform.
The CC does not state requirements for the regulatory framework. However, consistency between the regulatory frameworks of different evaluation authorities will be necessary to achieve the goal of mutual recognition of the results of such evaluations. Figure 3.1 depicts the major elements that form the context for evaluations.
Use of a common evaluation methodology contributes to the repeatability and objectivity of the results but is not by itself sufficient. Many of the evaluation criteria require the application of expert judgement and background knowledge for which consistency is more difficult to achieve. In order to enhance the consistency of the evaluation findings, the final evaluation results could be submitted to a certification process. The certification process is the independent inspection of the results of the evaluation leading to the production of the final certificate or approval.
The certificate is normally publicly available. It is noted that the certification process is a means of gaining greater consistency in the application of IT security criteria.
The evaluation scheme, methodology, and certification processes are the responsibility of the evaluation authorities that run evaluation schemes and are outside the scope of the CC.
Page 10 of 56 Version 2.1
August 1999

Organisation of the Common Criteria 3 - Overview
89
Evaluate
Evaluation
Criteria
(the CC)
Evaluation
Methodology
Evaluation
Scheme
Final
Evaluation
Results
Approve/
Certify
List of
Certificates/
Register
Figure 3.1 - Evaluation context
The CC is presented as a set of distinct but related parts as identified below. Terms used in the description of the parts are explained in clause 4.
a) Part 1, Introduction and general model, is the introduction to the CC. It defines general concepts and principles of IT security evaluation and presents a general model of evaluation. Part 1 also presents constructs for expressing IT security objectives, for selecting and defining IT security requirements, and for writing high-level specifications for products and systems. In addition, the usefulness of each part of the CC is described in terms of each of the target audiences.
b) c)
Part 2, Security functional requirements, establishes a set of functional components as a standard way of expressing the functional requirements for
TOEs. Part 2 catalogues the set of functional components, families, and classes.
Part 3, Security assurance requirements, establishes a set of assurance components as a standard way of expressing the assurance requirements for
TOEs. Part 3 catalogues the set of assurance components, families and classes. Part 3 also defines evaluation criteria for PPs and STs and presents evaluation assurance levels that define the predefined CC scale for rating assurance for TOEs, which is called the Evaluation Assurance Levels
(EALs).
August 1999 Version 2.1
Page 11 of 56

3 - Overview Organisation of the Common Criteria
90
91
In support of the three parts of the CC listed above, it is anticipated that other types of documents will be published, including technical rationale material and guidance documents.
The following table presents, for the three key target audience groupings, how the parts of the CC will be of interest.
Table 3.1 - Roadmap to the Common Criteria
Consumers
Part 1 Use for background information and reference purposes.
Guidance structure for PPs.
Part 2 Use for guidance and reference when formulating statements of requirements for security functions.
Part 3 Use for guidance when determining required levels of assurance.
Developers
Use for background information and reference for the development of requirements and formulating security specifications for TOEs.
Use for reference when interpreting statements of functional requirements and formulating functional specifications for TOEs.
Use for reference when interpreting statements of assurance requirements and determining assurance approaches of TOEs.
Evaluators
Use for background information and reference purposes.
Guidance structure for PPs and STs.
Use as mandatory statement of evaluation criteria when determining whether a TOE effectively meets claimed security functions.
Use as mandatory statement of evaluation criteria when determining the assurance of
TOEs and when evaluating
PPs and STs.
Page 12 of 56 Version 2.1
August 1999

Part 1: Introduction and general model 29 Security context
92
93
4.1.1
94
This clause presents the general concepts used throughout the CC, including the context in which the concepts are to be used and the CC approach for applying the concepts. Part 2 and Part 3 expand on the use of these concepts and assume that the approach described is used. This clause assumes some knowledge of IT security and does not propose to act as a tutorial in this area.
The CC discusses security using a set of security concepts and terminology. An understanding of these concepts and the terminology is a prerequisite to the effective use of the CC. However, the concepts themselves are quite general and are not intended to restrict the class of IT security problems to which the CC is applicable.
General security context
Security is concerned with the protection of assets from threats, where threats are categorised as the potential for abuse of protected assets. All categories of threats should be considered; but in the domain of security greater attention is given to those threats that are related to malicious or other human activities. Figure 4.1
illustrates high level concepts and relationships.
August 1999 Version 2.1
Page 13 of 56

4 - General model Security context
95
96
97
Owners value wish to minimise impose countermeasures to reduce that may be reduced by may be aware of that may possess that exploit vulnerabilities leading to
Threat agents give rise to threats that increase to risk to assets wish to abuse and/or may damage
Figure 4.1 - Security concepts and relationships
Safeguarding assets of interest is the responsibility of owners who place value on those assets. Actual or presumed threat agents may also place value on the assets and seek to abuse assets in a manner contrary to the interests of the owner. Owners will perceive such threats as potential for impairment of the assets such that the value of the assets to the owners would be reduced. Security specific impairment commonly includes, but is not limited to, damaging disclosure of the asset to unauthorised recipients (loss of confidentiality), damage to the asset through unauthorised modification (loss of integrity), or unauthorised deprivation of access to the asset (loss of availability).
The owners of the assets will analyse the possible threats to determine which ones apply to their environment. The results are known as risks. This analysis can aid in the selection of countermeasures to counter the risks and reduce it to an acceptable level.
Countermeasures are imposed to reduce vulnerabilities and to meet security policies of the owners of the assets (either directly or indirectly by providing direction to other parties). Residual vulnerabilities may remain after the imposition of countermeasures. Such vulnerabilities may be exploited by threat agents representing a residual level of risk to the assets. Owners will seek to minimise that risk given other constraints.
Page 14 of 56 Version 2.1
August 1999

Security context 4 - General model
98
99
Assurance
Techniques produce assurance giving
Owners require
Evaluation gives evidence of confidence that countermeasures risk minimise assets.
to
Figure 4.2 - Evaluation concepts and relationships
Owners will need to be confident that the countermeasures are adequate to counter the threats to assets before they will allow exposure of their assets to the specified threats. Owners may not themselves possess the capability to judge all aspects of the countermeasures, and may therefore seek evaluation of the countermeasures.
The outcome of evaluation is a statement about the extent to which assurance is gained that the countermeasures can be trusted to reduce the risks to the protected assets. The statement assigns an assurance rating of the countermeasures, assurance being that property of the countermeasures that gives grounds for confidence in their proper operation. This statement can be used by the owner of the assets in deciding whether to accept the risk of exposing the assets to the threats. Figure 4.2
illustrates these relationships.
Owners of assets will normally be held responsible for those assets and should be able to defend the decision to accept the risks of exposing the assets to the threats.
This requires that the statements resulting from evaluation are defensible. Thus, evaluation should lead to objective and repeatable results that can be cited as evidence.
August 1999 Version 2.1
Page 15 of 56

4 - General model Common Criteria approach
104
4.2.1
105
4.1.2
100
101
102
103
106
Page 16 of 56
Information technology security context
Many assets are in the form of information that is stored, processed and transmitted by IT products or systems to meet requirements laid down by owners of the information. Information owners may require that dissemination and modification of any such information representations (data) be strictly controlled. They may demand that the IT product or system implement IT specific security controls as part of the overall set of security countermeasures put in place to counteract the threats to the data.
IT systems are procured and constructed to meet specific requirements and may, for economic reasons, make maximum use of existing commodity IT products such as operating systems, general purpose application components, and hardware platforms. IT security countermeasures implemented by a system may use functions of the underlying IT products and depend upon the correct operation of IT product security functions. The IT products may, therefore, be subject to evaluation as part of the IT system security evaluation.
Where an IT product is incorporated or being considered for incorporation in multiple IT systems, there are cost advantages in evaluating the security aspects of such a product independently and building a catalogue of evaluated products. The results of such an evaluation should be expressed in a manner that supports incorporation of the product in multiple IT systems without unnecessary repetition of work required to examine the product’s security.
An IT system accreditor has the authority of the owner of the information to determine whether the combination of IT and non-IT security countermeasures furnishes adequate protection for the data, and thus to decide whether to permit the operation of the system. The accreditor may call for evaluation of the IT countermeasures in order to determine whether the IT countermeasures provide adequate protection and whether the specified countermeasures are properly implemented by the IT system. This evaluation may take various forms and degrees of rigour, depending upon the rules imposed upon, or by, the accreditor.
Confidence in IT security can be gained through actions that may be taken during the processes of development, evaluation, and operation.
Development
The CC does not mandate any specific development methodology or life cycle model. Figure 4.3 depicts underlying assumptions about the relationship between the security requirements and the TOE. The figure is used to provide a context for discussion and should not be construed as advocating a preference for one methodology (e.g. waterfall) over another (e.g. prototyping).
It is essential that the security requirements imposed on the IT development be effective in contributing to the security objectives of consumers. Unless suitable
Version 2.1
August 1999

Common Criteria approach 4 - General model
Security requirements requirements are established at the start of the development process, the resulting end product, however well engineered, may not meet the objectives of its anticipated consumers.
Functional specification
High-level design
107
108
Source code/
Hardware drawings
Implementation
Figure 4.3 - TOE development model
The process is based on the refinement of the security requirements into a TOE summary specification expressed in the security target. Each lower level of refinement represents a design decomposition with additional design detail. The least abstract representation is the TOE implementation itself.
The CC does not mandate a specific set of design representations. The CC requirement is that there should be sufficient design representations presented at a sufficient level of granularity to demonstrate where required:
August 1999 Version 2.1
Page 17 of 56

4 - General model Common Criteria approach
109 a) b) that each refinement level is a complete instantiation of the higher levels
(i.e. all TOE security functions, properties, and behaviour defined at the higher level of abstraction must be demonstrably present in the lower level); that each refinement level is an accurate instantiation of the higher levels
(i.e. there should be no TOE security functions, properties, and behaviour defined at the lower level of abstraction that are not required by the higher level).
The CC assurance criteria identify the design abstraction levels of functional specification, high-level design, low-level design, and implementation. Depending upon the assurance level specified, developers may be required to show how the development methodology meets the CC assurance requirements.
Security requirements
(PP and ST)
Develop
TOE
Evaluation criteria
Evaluation
Methodology
Evaluation
Scheme
TOE and
Evaluation
Evidence
Evaluate
TOE
4.2.2
110
Page 18 of 56
Evaluation
Results
Operate
TOE
Feedback
Figure 4.4 - TOE evaluation process
TOE evaluation
The TOE evaluation process as described in Figure 4.4 may be carried out in parallel with development, or it may follow. The principal inputs to TOE evaluation are:
Version 2.1
August 1999

Security concepts 4 - General model
113
114
111
112
4.2.3
115
116 a) b) c) the set of TOE evidence, which includes the evaluated ST as the basis for
TOE evaluation; the TOE for which the evaluation is required; the evaluation criteria, methodology and scheme.
In addition, informative material (such as application notes of the CC) and the IT security expertise of the evaluator and the evaluation community are likely to be used as inputs to the evaluation.
The expected result of the evaluation process is a confirmation that the TOE satisfies its security requirements as stated in the ST with one or more reports documenting the evaluator findings about the TOE as determined by the evaluation criteria. These reports will be useful to actual and potential consumers of the product or system represented by the TOE as well as to the developer.
The degree of confidence gained through an evaluation depends on the assurance requirements (e.g. Evaluation Assurance Level) met.
Evaluation can lead to better IT security products in two ways. Evaluation is intended to identify errors or vulnerabilities in the TOE that the developer may correct, thereby reducing the probability of security failures in future operation.
Also in preparing for the rigours of evaluation, the developer may take more care in
TOE design and development. Therefore, the evaluation process can exert a strong, though indirect, positive effect on the initial requirements, the development process, the end product, and the operational environment.
Operation
Consumers may elect to use evaluated TOEs in their environments. Once a TOE is in operation, it is possible that previously unknown errors or vulnerabilities may surface or environmental assumptions may need to be revised. As a result of operation, feedback could be given that would require the developer to correct the
TOE or redefine its security requirements or environmental assumptions. Such changes may require the TOE to be re-evaluated or the security of its operational environment to be strengthened. In some instances this may only require that the needed updates are evaluated in order to regain confidence in the TOE. Although the CC contains criteria to cover assurance maintenance, detailed procedures for reevaluation, including reuse of evaluation results, are outside the scope of the CC.
Evaluation criteria are most useful in the context of the engineering processes and regulatory frameworks that are supportive of secure TOE development and evaluation. This subclause is provided for illustration and guidance purposes only and is not intended to constrain the analysis processes, development approaches, or evaluation schemes within which the CC might be employed.
August 1999 Version 2.1
Page 19 of 56

4 - General model Security concepts
117
118
119
The CC is applicable when IT is being used and there is concern about the ability of the IT element to safeguard assets. In order to show that the assets are secure, the security concerns must be addressed at all levels from the most abstract to the final
IT implementation in its operational environment. These levels of representation, as described in the following subclauses, permit security problems and issues to be characterised and discussed but do not, of themselves, demonstrate that the final IT implementation actually exhibits the required security behaviour and can, therefore, be trusted.
The CC requires that certain levels of representation contain a rationale for the representation of the TOE at that level. That is, such a level must contain a reasoned and convincing argument that shows that it is in conformance with the higher level, and is itself complete, correct and internally consistent. Statements of rationale demonstrating conformance with the adjacent higher level representation contribute to the case for TOE correctness. Rationale directly demonstrating compliance with security objectives supports the case that the TOE is effective in countering the threats and enforcing the organisational security policy.
The CC layers the different levels of representation as described in Figure 4.5, which illustrates the means by which the security requirements and specifications might be derived when developing a PP or ST. All TOE security requirements ultimately arise from consideration of the purpose and context of the TOE. This chart is not intended to constrain the means by which PPs and STs are developed, but illustrates how the results of some analytic approaches relate to the content of
PPs and STs.
Page 20 of 56 Version 2.1
August 1999

Security concepts 4 - General model
Assets requiring protection TOE purpose
TOE physical environment
Establish security environment
Threats
Security
Environment material (PP/ST)
Assumptions Organisational security policies
Establish security objectives
Security objectives
Security
Objectives material (PP/ST) CC requirements catalogue
4.3.1
120
Functional requirements
Establish security requirements
Assurance requirements
Requirements for the environment
Security
Requirements material (PP/ST)
Establish
TOE summary specification
TOE summary specification
Security
Specification material (ST)
Figure 4.5 - Derivation of requirements and specifications
Security environment
The security environment includes all the laws, organisational security policies, customs, expertise and knowledge that are determined to be relevant. It thus defines
August 1999 Version 2.1
Page 21 of 56

4 - General model Security concepts
121
122
4.3.2
123
124
Page 22 of 56 the context in which the TOE is intended to be used. The security environment also includes the threats to security that are, or are held to be, present in the environment.
To establish the security environment, the PP or ST writer has to take into account: a) the TOE physical environment which identifies all aspects of the TOE operating environment relevant to TOE security, including known physical and personnel security arrangements; b) c) the assets requiring protection by the element of the TOE to which security requirements or policies will apply; this may include assets that are directly referred to, such as files and databases, as well as assets that are indirectly subject to security requirements, such as authorisation credentials and the IT implementation itself; the TOE purpose, which would address the product type and the intended usage of the TOE.
Investigation of the security policies, threats and risks should permit the following security specific statements to be made about the TOE: a) A statement of assumptions which are to be met by the environment of the
TOE in order for the TOE to be considered secure. This statement can be accepted as axiomatic for the TOE evaluation.
b) c)
A statement of threats to security of the assets would identify all the threats perceived by the security analysis as relevant to the TOE. The CC characterises a threat in terms of a threat agent, a presumed attack method, any vulnerabilities that are the foundation for the attack, and identification of the asset under attack. An assessment of risks to security would qualify each threat with an assessment of the likelihood of such a threat developing into an actual attack, the likelihood of such an attack proving successful, and the consequences of any damage that may result.
A statement of applicable organisational security policies would identify relevant policies and rules. For an IT system, such policies may be explicitly referenced, whereas for a general purpose IT product or product class, working assumptions about organisational security policy may need to be made.
Security objectives
The results of the analysis of the security environment could then be used to state the security objectives that counter the identified threats and address identified organisational security policies and assumptions. The security objectives should be consistent with the stated operational aim or product purpose of the TOE, and any knowledge about its physical environment.
The intent of determining security objectives is to address all of the security concerns and to declare which security aspects are either addressed directly by the
Version 2.1
August 1999

Security concepts 4 - General model
128
129
125
126
4.3.3
127
130
131
132
TOE or by its environment. This categorisation is based on a process incorporating engineering judgement, security policy, economic factors and risk acceptance decisions.
The security objectives for the environment would be implemented within the IT domain, and by non-technical or procedural means.
Only the security objectives for the TOE and its IT environment are addressed by
IT security requirements.
IT security requirements
The IT security requirements are the refinement of the security objectives into a set of security requirements for the TOE and security requirements for the environment which, if met, will ensure that the TOE can meet its security objectives.
The CC presents security requirements under the distinct categories of functional requirements and assurance requirements.
The functional requirements are levied on those functions of the TOE that are specifically in support of IT security, and define the desired security behaviour.
Part 2 defines the CC functional requirements. Examples of functional requirements include requirements for identification, authentication, security audit and non-repudiation of origin.
When the TOE contains security functions that are realised by a probabilistic or permutational mechanism (e.g. a password or hash function), the assurance requirements may specify that a minimum strength level consistent with the security objectives is to be claimed. In this case, the level specified will be one of the following SOF-basic, SOF-medium, SOF-high. Each such function will be required to meet that minimum level or at least an optionally defined specific metric.
The degree of assurance can be varied for a given set of functional requirements; therefore it is typically expressed in terms of increasing levels of rigour built with assurance components. Part 3 defines the CC assurance requirements and a scale of evaluation assurance levels (EALs) constructed using these components. The assurance requirements are levied on actions of the developer, on evidence produced and on the actions of the evaluator. Examples of assurance requirements include constraints on the rigour of the development process and requirements to search for and analyse the impact of potential security vulnerabilities.
Assurance that the security objectives are achieved by the selected security functions is derived from the following two factors: a) confidence in the correctness of the implementation of the security functions, i.e., the assessment whether they are correctly implemented; and b) confidence in the effectiveness of the security functions, i.e., the assessment whether they actually satisfy the stated security objectives.
August 1999 Version 2.1
Page 23 of 56

4 - General model CC descriptive material
133
4.3.4
134
4.3.5
135
136
4.4.1
137
Security requirements generally include both requirements for the presence of desired behaviour and requirements for the absence of undesired behaviour. It is normally possible to demonstrate, by use or testing, the presence of the desired behaviour. It is not always possible to perform a conclusive demonstration of absence of undesired behaviour. Testing, design review, and implementation review contribute significantly to reducing the risk that such undesired behaviour is present. The rationale statements provide further support to the claim that such undesired behaviour is absent.
TOE summary specification
The TOE summary specification provided in the ST defines the instantiation of the security requirements for the TOE. It provides a high-level definition of the security functions claimed to meet the functional requirements, and assurance measures taken to meet the assurance requirements.
TOE implementation
The TOE implementation is the realisation of the TOE based on its security functional requirements and the TOE summary specification contained in the ST.
TOE implementation is accomplished using a process of applying security and IT engineering skills and knowledge. The TOE will meet the security objectives if it correctly and effectively implements all the security requirements contained in the
ST.
The CC presents the framework in which an evaluation can take place. By presenting the requirements for evidence and analysis, a more objective, and hence useful evaluation result can be achieved. The CC incorporates a common set of constructs and a language in which to express and communicate the relevant aspects of IT security, and permits those responsible for IT security to benefit from the prior experience and expertise of others.
Expression of security requirements
The CC defines a set of constructs that combine into meaningful assemblies of security requirements of known validity, which can be used in establishing security requirements for prospective products and systems. The relationships among the various constructs for requirements expression are described below and illustrated in figure 4.6.
Page 24 of 56 Version 2.1
August 1999

CC descriptive material 4 - General model
Class b Family k
Class a
Family i
Family j
Component
Component
.....
Component
Component
Component
.....
Component
CC Catalogues
Component
Component
.....
Component
Packages
Reusable set of functional or assurance requirements.
Optional input to PP or ST
Optional extended (non-CC)
Security Requirements
Protection Profile
Possible input sources for PP
Security Target
Possible input sources for ST
141
4.4.1.2
142
143
4.4.1.3
144
138
139
4.4.1.1
140
Figure 4.6 - Organisation and construction of requirements
The organisation of the CC security requirements into the hierarchy of class family - component is provided to help consumers to locate specific security requirements.
The CC presents requirements for functional and assurance aspects in the same general style and uses the same organisation and terminology for each.
Class
The term class is used for the most general grouping of security requirements. All the members of a class share a common focus, while differing in coverage of security objectives.
The members of a class are termed families.
Family
A family is a grouping of sets of security requirements that share security objectives but may differ in emphasis or rigour.
The members of a family are termed components.
Component
A component describes a specific set of security requirements and is the smallest selectable set of security requirements for inclusion in the structures defined in the
CC. The set of components within a family may be ordered to represent increasing strength or capability of security requirements that share a common purpose. They
August 1999 Version 2.1
Page 25 of 56

4 - General model CC descriptive material
145
146
147
148
149
4.4.2
150
Page 26 of 56 may also be partially ordered to represent related non-hierarchical sets. In some instances, there is only one component in a family so ordering is not applicable.
The components are constructed from individual elements. The element is the lowest level expression of security requirements, and is the indivisible security requirement that can be verified by the evaluation.
Dependencies between components
Dependencies may exist between components. Dependencies arise when a component is not self sufficient and relies upon the presence of another component.
Dependencies may exist between functional components, between assurance components, and between functional and assurance components.
Component dependency descriptions are part of the CC component definitions. In order to ensure completeness of the TOE requirements, dependencies should be satisfied when incorporating components into PPs and STs where appropriate.
Permitted operations on components
CC components may be used exactly as defined in the CC, or they may be tailored through the use of permitted operations in order to meet a specific security policy or counter a specific threat. Each CC component identifies and defines any permitted operations of assignment and selection, the circumstances under which these operations may be applied to the component, and the results of the application of the operation. The operations of iteration and refinement can be performed for any component. These four operations are described as follows: a) b)
iteration, which permits the use of a component more than once with varying operations;
assignment, which permits the specification of a parameter to be filled in when the component is used; c) d)
selection, which permits the specification of items that are to be selected from a list given in the component;
refinement, which permits the addition of extra detail when the component is used.
Some required operations may be completed (in whole or part) in the PP or may be left to be completed in the ST. Nevertheless, all operations must be completed in the ST.
Use of security requirements
The CC defines three types of requirement constructs: package, PP and ST. The CC further defines a set of IT security criteria that can address the needs of many communities and thus serve as a major expert input to the production of these constructs. The CC has been developed around the central notion of using wherever
Version 2.1
August 1999

CC descriptive material 4 - General model possible the security requirements components defined in the CC, which represent a well-known and understood domain. Figure 4.7 shows the relationship between these different constructs.
Security
Requirements
Develop
Package
Packages
Catalogue
Develop
PP
PPs
Catalogue
Develop
ST
4.4.2.1
151
152
4.4.2.2
153
Figure 4.7 - Use of security requirements
Package
An intermediate combination of components is termed a package. The package permits the expression of a set of functional or assurance requirements that meet an identifiable subset of security objectives. A package is intended to be reusable and to define requirements that are known to be useful and effective in meeting the identified objectives. A package may be used in the construction of larger packages,
PPs, and STs.
The evaluation assurance levels (EALs) are predefined assurance packages contained in Part 3. An EAL is a baseline set of assurance requirements for evaluation. EALs each define a consistent set of assurance requirements. Together, the EALs form an ordered set that is the predefined assurance scale of the CC.
Protection Profile
The PP contains a set of security requirements either from the CC, or stated explicitly, which should include an EAL (possibly augmented by additional assurance components). The PP permits the implementation independent
August 1999 Version 2.1
Page 27 of 56

4 - General model CC descriptive material
154
4.4.2.3
155
156
4.4.3
157 expression of security requirements for a set of TOEs that will comply fully with a set of security objectives. A PP is intended to be reusable and to define TOE requirements that are known to be useful and effective in meeting the identified objectives, both for functions and assurance. A PP also contains the rationale for security objectives and security requirements.
A PP could be developed by user communities, IT product developers, or other parties interested in defining such a common set of requirements. A PP gives consumers a means of referring to a specific set of security needs and facilitates future evaluation against those needs.
Security Target
An ST contains a set of security requirements that may be made by reference to a
PP, directly by reference to CC functional or assurance components, or stated explicitly. An ST permits the expression of security requirements for a specific
TOE that are shown, by evaluation, to be useful and effective in meeting the identified objectives.
An ST contains the TOE summary specification, together with the security requirements and objectives, and the rationale for each. An ST is the basis for agreement between all parties as to what security the TOE offers.
Sources of security requirements
TOE security requirements can be constructed by using the following inputs: a) Existing PPs
The TOE security requirements in an ST may be adequately expressed by, or are intended to comply with, a pre-existing statement of requirements contained in an existing PP.
b) c)
Existing PPs may be used as a basis for a new PP.
Existing packages
Part of the TOE security requirements in a PP or ST may have already been expressed in a package that may be used.
A set of predefined packages is the EALs defined in Part 3. The TOE assurance requirements in a PP or ST should include an EAL from Part 3.
Existing functional or assurance requirements components
The TOE functional or assurance requirements in a PP or ST may be expressed directly, using the components in Part 2 or 3.
d) Extended requirements
Page 28 of 56 Version 2.1
August 1999

Types of evaluation 4 - General model
158
4.5.1
159
4.5.2
160
4.5.3
161
162
Additional functional requirements not contained in Part 2 and/or additional assurance requirements not contained in Part 3 may be used in a PP or ST.
Existing requirements material from Parts 2 and 3 should be used where available.
The use of an existing PP will help to ensure that the TOE will meet a well known set of needs of known utility and thus be more widely recognised.
PP evaluation
The PP evaluation is carried out against the evaluation criteria for PPs contained in
Part 3. The goal of such an evaluation is to demonstrate that the PP is complete, consistent, and technically sound and suitable for use as a statement of requirements for an evaluatable TOE.
ST evaluation
The evaluation of the ST for the TOE is carried out against the evaluation criteria for STs contained in Part 3. The goal of such an evaluation is twofold: first to demonstrate that the ST is complete, consistent, and technically sound and hence suitable for use as the basis for the corresponding TOE evaluation; second, in the case where an ST claims conformance to a PP, to demonstrate that the ST properly meets the requirements of the PP.
TOE evaluation
The TOE evaluation is carried out against the evaluation criteria contained in Part
3 using an evaluated ST as the basis. The goal of such an evaluation is to demonstrate that the TOE meets the security requirements contained in the ST.
TOE assurance maintenance is carried out against the evaluation criteria contained in Part 3 using a previously evaluated TOE as the basis. The goal is to derive confidence that assurance already established in a TOE is maintained and that the
TOE will continue to meet its security requirements as changes are made to the TOE or its environment.
August 1999 Version 2.1
Page 29 of 56

Part 1: Introduction and general model 34 Introduction
163
This clause presents the expected results from PP and TOE evaluation. PP or TOE evaluations lead respectively to catalogues of evaluated PPs or TOEs. ST evaluation leads to intermediate results that are used in the frame of a TOE evaluation.
Evaluate
PP
PP Evaluation
Results
Catalogue
PP
Evaluated
PP
Evaluate
ST
ST Evaluation
Results
164
165
August 1999
Evaluate
TOE
TOE Evaluation
Results
Catalogue
Certificates
Evaluated
TOE
Figure 5.1 - Evaluation results
Evaluation should lead to objective and repeatable results that can be cited as evidence, even if there is no totally objective scale for representing the results of an
IT security evaluation. The existence of a set of evaluation criteria is a necessary pre-condition for evaluation to lead to a meaningful result and provides a technical basis for mutual recognition of evaluation results between evaluation authorities.
But the application of criteria contains both objective and subjective elements, that's why precise and universal ratings for IT security are not, therefore, feasible.
A rating made relative to the CC represents the findings of a specific type of investigation of the security properties of a TOE. Such a rating does not guarantee fitness for use in any particular application environment. The decision to accept a
TOE for use in a specific application environment is based on consideration of many security issues including the evaluation findings.
Version 2.1
Page 30 of 56

Requirements in PPs and STs 5 - Common Criteria requirements and evaluation results
166
167
5.2.1
168
169
170
The CC defines a set of IT security criteria that can address the needs of many communities. The CC has been developed around the central notion that the use of the security functional components contained in Part 2, and the EALs and assurance components contained in Part 3, represents the preferred course of action for expression of TOE requirements in PPs and STs, as they represent a well-known and understood domain.
The CC recognises the possibility that functional and assurance requirements not included in the provided catalogues may be required in order to represent the complete set of IT security requirements. The following shall apply to the inclusion of these extended functional or assurance requirements: a) b)
Any extended functional or assurance requirements included in a PP or ST shall be clearly and unambiguously expressed such that evaluation and demonstration of compliance is feasible. The level of detail and manner of expression of existing CC functional or assurance components shall be used as a model.
Evaluation results obtained using extended functional or assurance requirements shall be caveated as such. c) The incorporation of extended functional or assurance requirements into a
PP or ST shall conform to the APE or ASE classes of the Part 3, as appropriate.
PP evaluation results
The CC contains the evaluation criteria that permit an evaluator to state whether a
PP is complete, consistent, and technically sound and hence suitable for use as a statement of requirements for an evaluatable TOE.
Evaluation of the PP shall result in a pass/fail statement. A PP for which the evaluation results in a pass statement shall be eligible for inclusion within a registry.
The CC contains the evaluation criteria that permit an evaluator to determine whether the TOE satisfies the security requirements expressed in the ST. By using the CC in evaluation of the TOE, the evaluator will be able to make statements about: a) whether the specified security functions of the TOE meet the functional requirements and are thereby effective in meeting the security objectives of the TOE; b) whether the specified security functions of the TOE are correctly implemented.
August 1999 Version 2.1
Page 31 of 56

Caveats on evaluation results 5 - Common Criteria requirements and evaluation results
171
172
173
5.3.1
174
175
176
The security requirements expressed in the CC define the known working domain of applicability of IT security evaluation criteria. A TOE for which the security requirements are expressed only in terms of the functional and assurance requirements drawn from the CC will be evaluatable against the CC. Use of assurance packages that do not contain an EAL shall be justified.
However, there may be a need for a TOE to meet security requirements not directly expressed in the CC. The CC recognises the necessity to evaluate such a TOE but, as the additional requirements lie outside the known domain of applicability of the
CC, the results of such an evaluation must be caveated accordingly. Such a caveat may place at risk universal acceptance of the evaluation results by the involved evaluation authorities.
The results of a TOE evaluation shall include a statement of conformance to the CC.
The use of CC terms to describe the security of a TOE permits comparison of the security characteristics of TOEs in general.
TOE evaluation results
The result of the TOE evaluation shall be a statement that describes the extent to which the TOE can be trusted to conform to the requirements.
Evaluation of the TOE shall result in a pass/fail statement. A TOE for which the evaluation results in a pass statement shall be eligible for inclusion within a registry.
The pass result of evaluation shall be a statement that describes the extent to which the PP or TOE can be trusted to conform to the requirements. The results shall be caveated with respect to Part 2 (functional requirements), Part 3 (assurance requirements) or directly to a PP, as listed below.
a) b)
Part 2 conformant - A PP or TOE is Part 2 conformant if the functional requirements are only based upon functional components in Part 2.
Part 2 extended - A PP or TOE is Part 2 extended if the functional requirements include functional components not in Part 2.
c) d) e)
Part 3 conformant - A PP or TOE is Part 3 conformant if the assurance requirements are in the form of an EAL or assurance package that is based only upon assurance components in Part 3.
Part 3 augmented - A PP or TOE is Part 3 augmented if the assurance requirements are in the form of an EAL or assurance package, plus other assurance components in Part 3.
Part 3 extended - A PP or TOE is Part 3 extended if the assurance requirements are in the form of an EAL associated with additional
Page 32 of 56 Version 2.1
August 1999

Use of TOE evaluation results 5 - Common Criteria requirements and evaluation results
177 f) assurance requirements not in Part 3 or an assurance package that includes
(or is entirely made up from) assurance requirements not in Part 3.
Conformant to PP - A TOE is conformant to a PP only if it is compliant with all parts of the PP.
IT products and systems differ in respect to the use of the results of the evaluation.
Figure 5.2 shows options for processing the results of evaluation. Products can be evaluated and catalogued at successively higher levels of aggregation until operational systems are achieved, at which time they may be subject to evaluation in connection with system accreditation.
178
179
PPs
Catalogue
(optional)
Security requirements
Develop
& evaluate
TOE
Evaluated
Products
Catalogue
(optional)
Evaluation results
Catalogue product
Evaluated product
(alternatives)
Accredit system
Accredited system
System accreditation criteria
Figure 5.2 - Use of TOE evaluation results
The TOE is developed in response to requirements that may take account of the security properties of any evaluated products incorporated and PPs referenced.
Subsequent evaluation of the TOE leads to a set of evaluation results documenting the findings of the evaluation.
Following an evaluation of an IT product intended for wider use, a summary of the evaluation findings might be entered in a catalogue of evaluated products so that it becomes available to a wider market seeking to use secure IT products.
August 1999 Version 2.1
Page 33 of 56

Use of TOE evaluation results
180
5 - Common Criteria requirements and evaluation results
Where the TOE is or will be included in an installed IT system that has been subject to evaluation, the evaluation results will be available to the system accreditor. The
CC evaluation results may then be considered by the accreditor when applying organisation specific accreditation criteria that call for CC evaluation. CC evaluation results are one of the inputs to an accreditation process that leads to a decision on accepting the risk of system operation.
Page 34 of 56 Version 2.1
August 1999

Part 1: Introduction and general model 37 Background
181
182
183
184
The CC represents the outcome of a series of efforts to develop criteria for evaluation of IT security that are broadly useful within the international community. In the early 1980’s the Trusted Computer System Evaluation Criteria
(TCSEC) was developed in the United States. In the succeeding decade, various countries began initiatives to develop evaluation criteria that built upon the concepts of the TCSEC but were more flexible and adaptable to the evolving nature of IT in general.
In Europe, the Information Technology Security Evaluation Criteria (ITSEC) version 1.2 was published in 1991 by the European Commission after joint development by the nations of France, Germany, the Netherlands, and the United
Kingdom. In Canada, the Canadian Trusted Computer Product Evaluation Criteria
(CTCPEC) version 3.0 was published in early 1993 as a combination of the ITSEC and TCSEC approaches. In the United States, the draft Federal Criteria for
Information Technology Security (FC) version 1.0 was also published in early
1993, as a second approach to combining North American and European concepts for evaluation criteria.
Work had begun in 1990 in the International Organization for Standardization
(ISO) to develop an international standard evaluation criteria for general use. The new criteria was to be responsive to the need for mutual recognition of standardised security evaluation results in a global IT market. This task was assigned to Working
Group 3 (WG 3) of subcommittee 27 (SC 27) of the Joint Technical Committee 1
(JTC 1). Initially, progress was slow within WG3 because of the extensive amount of work and intensive multilateral negotiations required.
In June 1993, the sponsoring organisations of the CTCPEC, FC, TCSEC and ITSEC
(which are identified in the next subclause) pooled their efforts and began a joint activity to align their separate criteria into a single set of IT security criteria that could be widely used. This activity was named the CC Project. Its purpose was to resolve the conceptual and technical differences found in the source criteria and to deliver the results to ISO as a contribution to the international standard under development. Representatives of the sponsoring organisations formed CC Editorial
Board (CCEB) to develop the CC. A liaison was then established between the
CCEB and WG 3, and the CCEB contributed several early versions of the CC to
WG 3 via the liaison channel. As a result of the interaction between WG 3 and the
August 1999 Version 2.1
Page 35 of 56

A - The Common Criteria project Sponsoring organisations
185
186
187
CCEB, these versions were adopted as successive working drafts of various Parts of the ISO criteria beginning in 1994.
Version 1.0 of the CC was completed by the CCEB in January 1996 and was approved by ISO in April 1996 for distribution as a Committee Draft (CD). The CC
Project then performed a number of trial evaluations using CC Version 1.0, and an extensive public review of the document was conducted. The CC Project subsequently undertook an extensive revision of the CC based on the comments received from trial use, public review and interaction with ISO. The revision work has been carried out by the successor to the CCEB, now called the CC
Implementation Board (CCIB).
The CCIB completed CC version 2.0 “Beta” in October 1997 and presented it to
WG 3, which approved it as a Second Committee Draft. Subsequent intermediate draft versions were provided informally to WG 3 experts for feedback as they were produced by the CCIB. The CCIB received and responded to a series of comments that came both directly from WG 3 experts and from ISO National Bodies via the
CD balloting. The culmination of this process is CC Version 2.0.
For historical and continuity purposes, ISO/IEC JTC 1/SC 27/WG 3 has accepted the continued use of the term “Common Criteria” (CC) within the document, while recognising that its official name in the ISO context is “Evaluation Criteria for
Information Technology Security”.
188
The seven European and North American governmental organisations listed below constitute the CC project sponsoring organisations. These organisations have provided nearly all of the effort that went into developing the CC from its inception to its completion. These organisations are also “evaluation authorities” for their respective national governments. They have committed themselves to replacing their respective evaluation criteria with the CC version 2.0 now that its technical development has been completed and it is in the final stages of acceptance as an
International Standard.
CANADA:
Communications Security Establishment
Criteria Coordinator
I2A Computer and Network Security
P.O. Box 9703, Terminal
Ottawa, Canada K1G 3Z4
Tel: +1.613.991.7882, Fax: +1.613.991.7455
E-mail: criteria@cse-cst.gc.ca
WWW: http://www.cse-cst.gc.ca/cse/english/cc.html
FTP: ftp://ftp.cse-cst.gc.ca/pub/criteria/CC2.0
FRANCE:
Service Central de la Sécurité des Systèmes d'Information (SCSSI)
Centre de Certification de la Sécurité des Technologies de l'Information
18, rue du docteur Zamenhof
F-92131 Issy les Moulineaux
France
Tel: +33.1.41463784, Fax: +33.1.41463701
E-mail: ssi20@calva.net
Page 36 of 56 Version 2.1
August 1999

Sponsoring organisations A - The Common Criteria project
GERMANY:
Bundesamt für Sicherheit in der Informationstechnik
(BSI)
German Information Security Agency (GISA)
Abteilung V
Postfach 20 03 63
D-53133 Bonn
Germany
Tel: +49.228.9582.300, Fax: +49.228.9582.427
E-mail: cc@bsi.de
WWW: http://www.bsi.bund.de/cc
NETHERLANDS:
Netherlands National Communications Security Agency
P.O. Box 20061
NL 2500 EB The Hague
The Netherlands
Tel: +31.70.3485637, Fax: +31.70.3486503
E-mail: criteria@nlncsa.minbuza.nl
WWW: http://www.tno.nl/instit/fel/refs/cc.html
UNITED KINGDOM:
Communications-Electronics Security Group
Compusec Evaluation Methodology
P.O. Box 144
Cheltenham GL52 5UE
United Kingdom
Tel: +44.1242.221.491 ext. 5257, Fax: +44.1242.252.291
E-mail: criteria@cesg.gov.uk
WWW: http://www.cesg.gov.uk/cchtml
FTP: ftp://ftp.cesg.gov.uk/pub
UNITED STATES - NIST:
National Institute of Standards and Technology
Computer Security Division
820 Diamond, MS: NN426
Gaithersburg, Maryland 20899
U.S.A.
Tel: +1.301.975.2934, Fax: +1.301.948.0279
E-mail: criteria@nist.gov
WWW: http://csrc.nist.gov/cc
UNITED STATES - NSA:
National Security Agency
Attn: V2, Common Criteria Technical Advisor
Fort George G. Meade, Maryland 20755-6740
U.S.A.
Tel: +1.410.859.4458, Fax: +1.410.684.7512
E-mail: common_criteria@radium.ncsc.mil
WWW: http://www.radium.ncsc.mil/tpep/
August 1999 Version 2.1
Page 37 of 56

Part 1: Introduction and general model 43 Overview
189
190
B.2.1
191
192
B.2.2
193
A PP defines an implementation-independent set of IT security requirements for a category of TOEs. Such TOEs are intended to meet common consumer needs for IT security. Consumers can therefore construct or cite a PP to express their IT security needs without reference to any specific TOE.
This annex contains the requirements for the PP in descriptive form. The assurance class APE, contained in clause 4 of CC Part 3, contains these requirements in the form of assurance components to be used for evaluation of the PP.
Content and presentation
A PP shall conform to the content requirements described in this annex. A PP should be presented as a user-oriented document that minimises reference to other material that might not be readily available to the PP user. The rationale may be supplied separately, if that is appropriate.
The contents of the PP are portrayed in Figure B.1, which should be used when constructing the structural outline of the PP document.
PP introduction
The PP introduction shall contain document management and overview information necessary to operate a PP registry as follows: a) The PP identification shall provide the labelling and descriptive information necessary to identify, catalogue, register, and cross reference a
PP.
b) The PP overview shall summarise the PP in narrative form. The overview should be sufficiently detailed for a potential user of the PP to determine whether the PP is of interest. The overview should also be usable as a stand alone abstract for use in PP catalogues and registers.
August 1999 Version 2.1
Page 38 of 56

Content of Protection Profile B - Specification of Protection Profiles
PROTECTION PROFILE
PP Introduction
PP identification
PP overview
TOE Description
TOE Security environment
Security objectives
IT security
requirements
Assumptions
Threats
Organisational security policies
Security objectives for the TOE
Security objectives for the environment
TOE security requirements
TOE security functional requirements
TOE security assurance requirements
Security requirements for the IT environment
PP application notes
Rationale
Security objectives rationale
Security requirements rationale
B.2.3
194
195
Figure B.1 - Protection Profile content
TOE description
This part of the PP shall describe the TOE as an aid to the understanding of its security requirements, and shall address the product type and the general IT features of the TOE.
The TOE description provides context for the evaluation. The information presented in the TOE description will be used in the course of the evaluation to identify inconsistencies. As a PP does not normally refer to a specific implementation, the described TOE features may be assumptions. If the TOE is a product or system whose primary function is security, this part of the PP may be used to describe the wider application context into which such a TOE will fit.
August 1999 Version 2.1
Page 39 of 56

B - Specification of Protection Profiles Content of Protection Profile
B.2.4
196
197
B.2.5
198
Page 40 of 56
TOE security environment
The statement of TOE security environment shall describe the security aspects of the environment in which the TOE is intended to be used and the manner in which it is expected to be employed. This statement shall include the following: a) A description of assumptions shall describe the security aspects of the environment in which the TOE will be used or is intended to be used. This shall include the following: information about the intended usage of the TOE, including such aspects as the intended application, potential asset value, and possible limitations of use; and b) information about the environment of use of the TOE, including physical, personnel, and connectivity aspects.
A description of threats shall include all threats to the assets against which specific protection within the TOE or its environment is required. Note that not all possible threats that might be encountered in the environment need to be listed, only those which are relevant for secure TOE operation.
A threat shall be described in terms of an identified threat agent, the attack, and the asset that is the subject of the attack. Threat agents should be described by addressing aspects such as expertise, available resources, and motivation. Attacks should be described by addressing aspects such as attack methods, any vulnerabilities exploited, and opportunity.
If security objectives are derived from only organisational security policies and assumptions, then the description of threats may be omitted.
c) A description of organisational security policies shall identify, and if necessary explain, any organisational security policy statements or rules with which the TOE must comply. Explanation and interpretation may be necessary to present any individual policy statement in a manner that permits it to be used to set clear security objectives.
If security objectives are derived from only threats and assumptions, then the description of organisational security policies may be omitted.
Where the TOE is physically distributed, it may be necessary to discuss the security environmental aspects (assumptions, threats, organisational security policies) separately for distinct domains of the TOE environment.
Security objectives
The statement of security objectives shall define the security objectives for the
TOE and its environment. The security objectives shall address all of the security environment aspects identified. The security objectives shall reflect the stated intent
Version 2.1
August 1999

Content of Protection Profile B - Specification of Protection Profiles
B.2.6
199
August 1999 and shall be suitable to counter all identified threats and cover all identified organisational security policies and assumptions. The following categories of objectives shall be identified. Note: when a threat or organisational security policy is to be covered partly by the TOE and partly by its environment, then the related objective shall be repeated in each category.
a) The security objectives for the TOE shall be clearly stated and traced back to aspects of identified threats to be countered by the TOE and/or organisational security policies to be met by the TOE.
b) 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.
Note that security objectives for the environment may be a re-statement, in whole or part, of the assumptions portion of the statement of the TOE security environment.
IT security requirements
This part of the PP defines the detailed IT security requirements that shall be satisfied by the TOE or its environment. The IT security requirements shall be stated as follows: a) The statement of TOE security requirements shall define the functional and assurance security requirements that the TOE and the supporting evidence for its evaluation need to satisfy in order to meet the security objectives for the TOE. The TOE security requirements shall be stated as follows:
1) The statement of TOE security functional requirements should define the functional requirements for the TOE as functional components drawn from Part 2 where applicable.
Where necessary to cover different aspects of the same requirement
(e.g. identification of more than one type of user), repetitive use (i.e.
applying the operation of iteration) of the same Part 2 component to cover each aspect is possible.
Where AVA_SOF.1 is included in the TOE security assurance requirements (e.g. EAL2 and higher), the statement of TOE security functional requirements shall include a minimum strength level for the TOE security functions realised by a probabilistic or permutational mechanism (e.g. a password or hash function). All such functions shall meet this minimum level. The level shall be one of the following: SOF-basic, SOF-medium, SOF-high. The selection of the level shall be consistent with the identified security objectives for the TOE. Optionally, specific strength of function metrics may be defined for selected functional requirements, in order to meet
Version 2.1
Page 41 of 56

B - Specification of Protection Profiles Content of Protection Profile
Page 42 of 56 b) c)
2) certain security objectives for the TOE.
As part of the strength of TOE security functions evaluation
(AVA_SOF.1), it will be assessed whether the strength claims made for individual TOE security functions and the overall minimum strength level are met by the TOE.
The statement of TOE security assurance requirements should state the assurance requirements as one of the EALs optionally augmented by Part 3 assurance components. The PP may also extend the EAL by explicitly stating additional assurance requirements not taken from Part 3.
The optional statement of Security requirements for the IT environment shall identify the IT security requirements that are to be met by the IT environment of the TOE. If the TOE has no asserted dependencies on the IT environment, this part of the PP may be omitted.
Note that security requirements for the non-IT environment, while often useful in practice, are not required to be a formal part of the PP as they do not relate directly to the implementation of the TOE.
The following common conditions shall apply equally to the expression of security functional and assurance requirements for the TOE and its IT environment:
1) All IT security requirements should be stated by reference to security requirements components drawn from Part 2 or Part 3 where applicable. Should none of the Part 2 or Part 3 requirements components be readily applicable to all or part of the security requirements, the PP may state those requirements explicitly without reference to the CC.
2)
3)
4)
Any explicit statement of TOE security functional or assurance requirements shall be clearly and unambiguously expressed such that evaluation and demonstration of compliance is feasible. The level of detail and manner of expression of existing CC functional or assurance requirements shall be used as a model.
When requirements components that specify required operations
(assignment or selection) are selected, the PP shall use those operations to amplify the requirements to the level of detail necessary to demonstrate that the security objectives are met. Any required operations that are not performed within the PP shall be identified as such.
By using operations on the requirements components, the TOE security requirements statements may optionally prescribe or forbid the use of particular security mechanisms where necessary.
Version 2.1
August 1999

Content of Protection Profile B - Specification of Protection Profiles
B.2.7
200
B.2.8
201
202
5) All dependencies among the IT security requirements should be satisfied. Dependencies may be satisfied by the inclusion of the relevant requirement within the TOE security requirements, or as a requirement on the environment.
Application notes
This optional part of the PP may contain additional supporting information that is considered relevant or useful for the construction, evaluation, or use of the TOE.
Rationale
This part of the PP presents the evidence used in the PP evaluation. This evidence supports the claims that the PP is a complete and cohesive set of requirements and that a conformant TOE would provide an effective set of IT security countermeasures within the security environment. The rationale shall include the following: a) The security objectives rationale shall demonstrate that the stated security objectives are traceable to all of the aspects identified in the TOE security environment and are suitable to cover them. b) The security requirements rationale shall demonstrate that the set of security requirements (TOE and environment) is suitable to meet and traceable to the security objectives. The following shall be demonstrated:
1) that the combination of the individual functional and assurance requirements components for the TOE and its IT environment together meet the stated security objectives;
2)
3) that the set of security requirements together forms a mutually supportive and internally consistent whole; that the choice of security requirements is justified. Any of the following conditions shall be specifically justified:
4)
— choice of requirements not contained in Parts 2 or 3;
— choice of assurance requirements not including an EAL; and
— non-satisfaction of dependencies; that the selected strength of function level for the PP, together with any explicit strength of function claim, is consistent with the security objectives for the TOE.
This potentially bulky material may be distributed separately as it may not be appropriate or useful to all PP users.
August 1999 Version 2.1
Page 43 of 56

Part 1: Introduction and general model 53 Overview
203
204
205
206
An ST contains the IT security requirements of an identified TOE and specifies the functional and assurance security measures offered by that TOE to meet stated requirements.
The ST for a TOE is a basis for agreement between the developers, evaluators and, where appropriate, consumers on the security properties of the TOE and the scope of the evaluation. The audience for the ST is not confined to those responsible for the production of the TOE and its evaluation, but may also include those responsible for managing, marketing, purchasing, installing, configuring, operating, and using the TOE.
The ST may incorporate the requirements of, or claim conformance to, one or more
PPs. The impact of such a PP conformance claim is not considered when initially defining the required ST content in subclause C.2. Subclause C.2.8 addresses the impact of a PP conformance claim on the required ST content.
This annex contains the requirements for the ST in descriptive form. The assurance class ASE, contained in clause 5 of CC Part 3, contains these requirements in the form of assurance components to be used for evaluation of the ST.
C.2.1
207
208
C.2.2
209
Content and presentation
An ST shall conform to the content requirements described in this annex. An ST should be presented as a user-oriented document that minimises reference to other material that might not be readily available to the ST user. The rationale may be supplied separately, if that is appropriate.
The contents of the ST are portrayed in Figure C.1, which should be used when constructing the structural outline of the ST.
ST introduction
The ST introduction shall contain the following document management and overview information.
August 1999 Version 2.1
Page 44 of 56

Content of Security Target C - Specification of Security Targets a) b) c)
The ST identification shall provide the labelling and descriptive information necessary to control and identify the ST and the TOE to which it refers.
The ST overview shall summarise the ST in narrative form. The overview should be sufficiently detailed for a potential consumer of the TOE to determine whether the TOE is of interest. The overview should also be usable as a stand alone abstract for incorporation in evaluated products lists.
A CC conformance claim shall state any evaluatable claim of CC conformance for the TOE, as identified in section 5.4 of this Part 1.
August 1999 Version 2.1
Page 45 of 56

C - Specification of Security Targets Content of Security Target
C.2.3
210
SECURITY TARGET
ST introduction
TOE Description
TOE Security environment
Security objectives
IT security
requirements
TOE summary specification
PP claims
Rationale
ST identification
ST overview
CC conformance
Assumptions
Threats
Organisational security policies
Security objectives for the TOE
Security objectives for the environment
TOE security requirements
TOE security functional requirements
TOE security assurance requirements
Security requirements for the IT environment
TOE security functions
Assurance measures
PP reference
PP tailoring
PP additions
Security objectives rationale
Security requirements rationale
TOE summary specification rationale
PP claims rationale
Figure C.1 - Security Target content
TOE description
This part of the ST shall describe the TOE as an aid to the understanding of its security requirements, and shall address the product or system type. The scope and boundaries of the TOE shall be described in general terms both in a physical way
(hardware and/or software components/modules) and a logical way (IT and security features offered by the TOE).
Page 46 of 56 Version 2.1
August 1999

Content of Security Target C - Specification of Security Targets
211
C.2.4
212
213
The TOE description provides context for the evaluation. The information presented in the TOE description will be used in the course of the evaluation to identify inconsistencies. If the TOE is a product or system whose primary function is security, this part of the ST may be used to describe the wider application context into which such a TOE will fit.
TOE security environment
The statement of TOE security environment shall describe the security aspects of the environment in which the TOE is intended to be used and the manner in which it is expected to be employed. This statement shall include the following: a) A description of assumptions shall describe the security aspects of the environment in which the TOE will be used or is intended to be used. This shall include the following: b) information about the intended usage of the TOE, including such aspects as the intended application, potential asset value, and possible limitations of use; and information about the environment of use of the TOE, including physical, personnel, and connectivity aspects.
A description of threats shall include all threats to the assets against which specific protection within the TOE or its environment is required. Note that not all possible threats that might be encountered in the environment need to be listed, only those which are relevant for secure TOE operation.
A threat shall be described in terms of an identified threat agent, the attack, and the asset that is the subject of the attack. Threat agents should be described by addressing aspects such as expertise, available resources, and motivation. Attacks should be described by addressing aspects such as attack methods, any vulnerabilities exploited, and opportunity.
c)
If security objectives are derived from only organisational security policies and assumptions, then the description of threats may be omitted.
A description of organisational security policies shall identify, and if necessary explain, any organisational security policy statements or rules with which the TOE must comply. Explanation and interpretation may be necessary to present any individual policy statement in a manner that permits it to be used to set clear security objectives.
If security objectives are derived from only threats and assumptions, then the description of organisational security policies may be omitted.
Where the TOE is physically distributed, it may be necessary to discuss the security environmental aspects (assumptions, threats, organisational security policies) separately for distinct domains of the TOE environment.
August 1999 Version 2.1
Page 47 of 56

C - Specification of Security Targets Content of Security Target
C.2.5
214
C.2.6
215
Page 48 of 56
Security objectives
The statement of security objectives shall define the security objectives for the
TOE and its environment. The security objectives shall address all of the security environment aspects identified. The security objectives shall reflect the stated intent and shall be suitable to counter all identified threats and cover all identified organisational security policies and assumptions. The following categories of objectives shall be identified. Note: when a threat or organisational security policy is to be covered partly by the TOE and partly by its environment, then the related objective shall be repeated in each category.
a) b)
The security objectives for the TOE shall be clearly stated and traced back to aspects of 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.
Note that security objectives for the environment may be a re-statement, in whole or part, of the assumptions portion of the statement of the TOE security environment.
IT security requirements
This part of the ST defines the detailed IT security requirements that shall be satisfied by the TOE or its environment. The IT security requirements shall be stated as follows: a) The statement of TOE security requirements shall define the functional and assurance security requirements that the TOE and the supporting evidence for its evaluation need to satisfy in order to meet the security objectives for the TOE. The TOE security requirements shall be stated as follows:
1) The statement of TOE security functional requirements should define the functional requirements for the TOE as functional components drawn from Part 2 where applicable.
Where necessary to cover different aspects of the same requirement
(e.g. identification of more than one type of user), repetitive use (i.e., applying the operation of iteration) of the same Part 2 component to cover each aspect is possible.
Where AVA_SOF.1 is included in the TOE security assurance requirements (e.g. EAL2 and higher), the statement of TOE security functional requirements shall include a minimum strength level for the TOE security functions realised by a probabilistic or permutational mechanism (e.g. a password or hash function). All
Version 2.1
August 1999

Content of Security Target C - Specification of Security Targets b) c)
2) such functions shall meet this minimum level. The level shall be one of the following: SOF-basic, SOF-medium, SOF-high. The selection of the level shall be consistent with the identified security objectives for the TOE. Optionally, specific strength of function metrics may be defined for selected functional requirements, in order to meet certain security objectives for the TOE.
As part of the strength of TOE security functions evaluation
(AVA_SOF.1), it will be assessed whether the strength claims made for individual TOE security functions and the overall minimum strength level are met by the TOE.
The statement of TOE security assurance requirements should state the assurance requirements as one of the EALs optionally augmented by Part 3 assurance components. The ST may also extend the EAL by explicitly stating additional assurance requirements not taken from Part 3.
The optional statement of security requirements for the IT environment shall identify the IT security requirements that are to be met by the IT environment of the TOE. If the TOE has no asserted dependencies on the IT environment, this part of the ST may be omitted.
Note that security requirements for the non-IT environment, while often useful in practice, are not required to be a formal part of the ST as they do not relate directly to the implementation of the TOE.
The following common conditions shall apply equally to the expression of security functional and assurance requirements for the TOE and its IT environment:
1) All IT security requirements should be stated by reference to security requirements components drawn from Part 2 or Part 3 where applicable. Should none of the Part 2 or Part 3 requirements components be readily applicable to all or part of the security requirements, the ST may state those requirements explicitly without reference to the CC.
2)
3)
Any explicit statement of TOE security functional or assurance requirements shall be clearly and unambiguously expressed such that evaluation and demonstration of compliance is feasible. The level of detail and manner of expression of existing CC functional or assurance requirements shall be used as a model.
Any required operations shall be used to amplify the requirements to the level of detail necessary to demonstrate that the security objectives are met. All specified operations on the requirements components shall be performed.
August 1999 Version 2.1
Page 49 of 56

C - Specification of Security Targets Content of Security Target
C.2.7
216
217
4) All dependencies among the IT security requirements should be satisfied. Dependencies may be satisfied by the inclusion of the relevant requirement within the TOE security requirements, or as a requirement on the environment.
TOE summary specification
The TOE summary specification shall define the instantiation of the security requirements for the TOE. This specification shall provide a description of the security functions and assurance measures of the TOE that meet the TOE security requirements. Note that the functional information provided as part of the TOE summary specification could be identical in some cases to the information to be provided for the TOE as part of the ADV_FSP requirements.
The TOE summary specification contains the following: a) The statement of TOE security functions shall cover the IT security functions and shall specify how these functions satisfy the TOE security functional requirements. This statement shall include a bi-directional mapping between functions and requirements that clearly shows which functions satisfy which requirements and that all requirements are met. Each security function shall, as a minimum, contribute to the satisfaction of at least one TOE security functional requirement.
1)
2)
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.
b)
3) When AVA_SOF.1 is included in the TOE assurance requirements, all IT security functions that are realised by a probabilistic or permutational mechanism (e.g. a password or hash function), shall be identified. The likelihood to breach the mechanisms of such functions by deliberate or accidental attack is of relevance to the security of the TOE. A strength of TOE security function analysis shall be provided for all these functions. The strength of each identified function shall be determined and claimed as either SOFbasic, SOF-medium or SOF-high, or as the optionally defined specific metric. The evidence provided about the strength of function shall be sufficient to allow the evaluators to make their independent assessment and to confirm that the strength claims are adequate and correct.
The statement of assurance measures specifies the assurance measures of the TOE which are claimed to satisfy the stated assurance requirements. The assurance measures shall be traced to the assurance requirements so that it
Page 50 of 56 Version 2.1
August 1999

Content of Security Target C - Specification of Security Targets
C.2.8
218
219
220
August 1999 can be seen which measures contribute to the satisfaction of which requirements.
If appropriate, the definition of assurance measures may be made by reference to relevant quality plans, life cycle plans, or management plans.
PP claims
The ST may optionally make a claim that the TOE conforms with the requirements of one (or possibly more than one) PP. For any PP conformance claims made, the
ST shall include a PP claims statement that contains the explanation, justification, and any other supporting material necessary to substantiate the claims.
The content and presentation of the ST statements of TOE objectives and requirements could be affected by PP claims made for the TOE. The impact on the
ST can be summarised by considering the following cases for each PP claimed: a) If there is no claim of PP compliance made, then the full presentation of the
TOE objectives and requirements should be made as described in this annex. No PP claims are included.
b) c)
If the ST claims only compliance with the requirements of a PP without need for further qualification, then reference to the PP is sufficient to define and justify the TOE objectives and requirements. Restatement of the PP contents is unnecessary.
If the ST claims compliance with the requirements of a PP, and that PP requires further qualification, then the ST shall show that the PP requirements for qualification have been met. Such a situation would typically arise where the PP contains uncompleted operations. In such a situation, the ST may refer to the specific requirements but complete the operations within the ST. In some circumstances, where the requirements to complete operations are substantial, it may be preferable to restate the PP contents within the ST as an aid to clarity.
d) If the ST claims compliance with the requirements of a PP but extends that
PP by the addition of further objectives and requirements, then the ST shall define the additions, whereas a PP reference may be sufficient to define the
PP objectives and requirements. In some circumstances, where the additions are substantial, it may be preferable to restate the PP contents within the ST as an aid to clarity.
e) The case where an ST claims to be partially conformant to a PP is not admissible for CC evaluation.
The CC is not prescriptive with respect to the choice of restating or referencing PP objectives and requirements. The fundamental requirement is that the ST content be complete, clear, and unambiguous such that evaluation of the ST is possible, the ST is an acceptable basis for the TOE evaluation, and the traceability to any claimed
PP is clear.
Version 2.1
Page 51 of 56

C - Specification of Security Targets Content of Security Target
221
C.2.9
222
Page 52 of 56
If any PP conformance claim is made, the PP claims statement shall contain the following material for each PP claimed.
a) The PP reference statement shall identify the PP for which compliance is being claimed plus any amplification that may be needed with respect to that claim. A valid claim implies that the TOE meets all the requirements of the
PP.
b) The PP tailoring statement shall identify the IT security requirements statements that satisfy the permitted operations of the PP or otherwise further qualify the PP requirements.
c) The PP additions statement shall identify the TOE objectives and requirements statements that are additional to the PP objectives and requirements.
Rationale
This part of the ST presents the evidence used in the ST evaluation. This evidence supports the claims that the ST is a complete and cohesive set of requirements, that a conformant TOE would provide an effective set of IT security countermeasures within the security environment, and that the TOE summary specification addresses the requirements. The rationale also demonstrates that any PP conformance claims are valid. The rationale shall include the following: a) b)
The security objectives rationale shall demonstrate that the stated security objectives are traceable to all of the aspects identified in the TOE security environment and are suitable to cover them.
The security requirements rationale shall demonstrate that the set of security requirements (TOE and environment) is suitable to meet and traceable to the security objectives. The following shall be demonstrated:
1) that the combination of the individual functional and assurance requirements components for the TOE and its IT environment together meet the stated security objectives;
2)
3) that the set of security requirements together forms a mutually supportive and internally consistent whole; that the choice of security requirements is justified. Any of the following conditions shall be specifically justified:
4)
— choice of requirements not contained in Parts 2 or 3;
— choice of assurance requirements not including an EAL; and
— non-satisfaction of dependencies; that the selected strength of function level for the ST, together with any explicit strength of function claim, is consistent with the security objectives for the TOE.
Version 2.1
August 1999

Content of Security Target C - Specification of Security Targets
223 c) The TOE summary specification rationale shall show that the TOE security functions and assurance measures are suitable to meet the TOE security requirements. The following shall be demonstrated:
1)
2)
3) that the combination of specified TOE IT security functions work together so as to satisfy the TOE security functional requirements; that the strength of TOE function claims made are valid, or that assertions that such claims are unnecessary are valid.
that the claim is justified that the stated assurance measures are compliant with the assurance requirements.
d)
The statement of rationale shall be presented at a level of detail that matches the level of detail of the definition of the security functions.
The PP claims rationale statement shall explain any difference between the
ST security objectives and requirements and those of any PP to which conformance is claimed. This part of the ST may be omitted if no claims of
PP conformance are made or if ST security objectives and requirements are identical to those of any claimed PP.
This potentially bulky material may be distributed separately as it may not be appropriate or useful to all ST users.
August 1999 Version 2.1
Page 53 of 56

Part 1: Introduction and general model 55
[B&L] Bell, D. E. and LaPadula, L. J., Secure Computer Systems: Unified Exposition and
MULTICS Interpretation, Revision 1, US Air Force ESD-TR-75-306, MITRE Corporation MTR-
2997, Bedford MA, March 1976.
[Biba] Biba, K. J., Integrity Considerations for Secure Computer Systems, ESD-TR-372, ESD/
AFSC, Hanscom AFB, Bedford MA., April 1977.
[CTCPEC] Canadian Trusted Computer Product Evaluation Criteria, Version 3.0, Canadian
System Security Centre, Communications Security Establishment, Government of Canada,
January 1993.
[FC] Federal Criteria for Information Technology Security, Draft Version 1.0, (Volumes I and II), jointly published by the National Institute of Standards and Technology and the National Security
Agency, US Government, January 1993.
[Gogu1] Goguen, J. A. and Meseguer, J., “Security Policies and Security Models,” 1982
Symposium on Security and Privacy, pp.11-20, IEEE, April 1982.
[Gogu2] Goguen, J. A. and Meseguer, J., “Unwinding and Inference Control,” 1984 Symposium on Security and Privacy, pp.75-85, IEEE, May 1984.
[ITSEC] Information Technology Security Evaluation Criteria, Version 1.2, Office for Official
Publications of the European Communities, June 1991.
[ISO/IEC 7498-2:1989] Information processing systems - Open Systems Interconnection - Basic
Reference Model, Part 2: Security Architecture.
[TCSEC] Trusted Computer Systems Evaluation Criteria, US DoD 5200.28-STD, December 1985.
August 1999 Version 2.1
Page 54 of 56

D - Bibliography
August 1999 Version 2.1
Page 55 of 56

Common Criteria for Information Technology
Security Evaluation

Part 2: Security functional requirements
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:
France:
Germany:
Netherlands:
Communications Security Establishment
Service Central de la Sécurité des Systèmes d’Information
Bundesamt für Sicherheit in der Informationstechnik
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 2: Security functional requirements vii
4
4.1
4.2
5
5.1
5.2
3
3.1
3.2
3.3
3.4
3.5
3.6
6.7
6.8
6.9
6.10
6.11
6.12
6.13
6
6.1
6.2
6.3
6.4
6.5
6.6
1
1.1
1.2
1.3
2
2.1
2.1.1
2.1.2
2.1.3
2.1.4
2.2
2.2.1
Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Extending and maintaining functional requirements . . . . . . . . . . . . . . . . . 1
Organisation of CC Part 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Functional requirements paradigm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Security functional components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Class structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Family structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Component structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Permitted functional component operations . . . . . . . . . . . . . . . . . . . . . 13
Component catalogue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Component changes highlighting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Class FAU: Security audit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Security audit automatic response (FAU_ARP) . . . . . . . . . . . . . . . . . . . . . 18
Security audit data generation (FAU_GEN) . . . . . . . . . . . . . . . . . . . . . . . . 19
Security audit analysis (FAU_SAA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Security audit review (FAU_SAR) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Security audit event selection (FAU_SEL) . . . . . . . . . . . . . . . . . . . . . . . . 27
Security audit event storage (FAU_STG) . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Class FCO: Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Non-repudiation of origin (FCO_NRO) . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Non-repudiation of receipt (FCO_NRR) . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Class FCS: Cryptographic support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Cryptographic key management (FCS_CKM) . . . . . . . . . . . . . . . . . . . . . . 37
Cryptographic operation (FCS_COP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Class FDP: User data protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Access control policy (FDP_ACC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Access control functions (FDP_ACF) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Data authentication (FDP_DAU) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Export to outside TSF control (FDP_ETC) . . . . . . . . . . . . . . . . . . . . . . . . 53
Information flow control policy (FDP_IFC) . . . . . . . . . . . . . . . . . . . . . . . 55
Information flow control functions (FDP_IFF) . . . . . . . . . . . . . . . . . . . . . 57
Import from outside TSF control (FDP_ITC) . . . . . . . . . . . . . . . . . . . . . . . 62
Internal TOE transfer (FDP_ITT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Residual information protection (FDP_RIP) . . . . . . . . . . . . . . . . . . . . . . . 67
Rollback (FDP_ROL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Stored data integrity (FDP_SDI) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Inter-TSF user data confidentiality transfer protection (FDP_UCT) . . . . . 73
Inter-TSF user data integrity transfer protection (FDP_UIT) . . . . . . . . . . . 75
August 1999 Version 2.1
Page iii of viii

Contents Part 2: Security functional requirements
8
8.1
8.2
8.3
8.4
8.5
8.6
9
9.1
9.2
9.3
9.4
7
7.1
7.2
7.3
7.4
7.5
7.6
10
10.1
10.2
10.3
10.4
10.5
10.6
10.7
10.8
10.9
10.10
10.11
10.12
10.13
10.14
10.15
10.16
11
11.1
11.2
11.3
12
12.1
12.2
12.3
12.4
Page iv of viii
Class FIA: Identification and authentication . . . . . . . . . . . . . . . . . . . . . . . . 79
Authentication failures (FIA_AFL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
User attribute definition (FIA_ATD) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Specification of secrets (FIA_SOS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
User authentication (FIA_UAU) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
User identification (FIA_UID) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
User-subject binding (FIA_USB) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Class FMT: Security management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Management of functions in TSF (FMT_MOF) . . . . . . . . . . . . . . . . . . . . . 97
Management of security attributes (FMT_MSA) . . . . . . . . . . . . . . . . . . . . 98
Management of TSF data (FMT_MTD) . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Revocation (FMT_REV) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Security attribute expiration (FMT_SAE) . . . . . . . . . . . . . . . . . . . . . . . . . 105
Security management roles (FMT_SMR) . . . . . . . . . . . . . . . . . . . . . . . . . . 106
Class FPR: Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Anonymity (FPR_ANO) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Pseudonymity (FPR_PSE) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Unlinkability (FPR_UNL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Unobservability (FPR_UNO) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
Class FPT: Protection of the TSF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Underlying abstract machine test (FPT_AMT) . . . . . . . . . . . . . . . . . . . . . 122
Fail secure (FPT_FLS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Availability of exported TSF data (FPT_ITA) . . . . . . . . . . . . . . . . . . . . . . 124
Confidentiality of exported TSF data (FPT_ITC) . . . . . . . . . . . . . . . . . . . 125
Integrity of exported TSF data (FPT_ITI) . . . . . . . . . . . . . . . . . . . . . . . . . 126
Internal TOE TSF data transfer (FPT_ITT) . . . . . . . . . . . . . . . . . . . . . . . . 128
TSF physical protection (FPT_PHP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Trusted recovery (FPT_RCV) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
Replay detection (FPT_RPL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
Reference mediation (FPT_RVM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
Domain separation (FPT_SEP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
State synchrony protocol (FPT_SSP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
Time stamps (FPT_STM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
Inter-TSF TSF data consistency (FPT_TDC) . . . . . . . . . . . . . . . . . . . . . . . 145
Internal TOE TSF data replication consistency (FPT_TRC) . . . . . . . . . . . 146
TSF self test (FPT_TST) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
Class FRU: Resource utilisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
Fault tolerance (FRU_FLT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
Priority of service (FRU_PRS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
Resource allocation (FRU_RSA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
Class FTA: TOE access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
Limitation on scope of selectable attributes (FTA_LSA) . . . . . . . . . . . . . . 158
Limitation on multiple concurrent sessions (FTA_MCS) . . . . . . . . . . . . . 159
Session locking (FTA_SSL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
TOE access banners (FTA_TAB) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
Version 2.1
August 1999

Part 2: Security functional requirements Contents
Annex C
C.1
C.2
C.3
C.4
C.5
C.6
Annex D
D.1
D.2
Annex E
E.1
E.2
F.7
F.8
F.9
F.10
F.11
F.12
F.13
Annex F
F.1
F.2
F.3
F.4
F.5
F.6
Annex G
G.1
G.2
12.5
12.6
13
13.1
13.2
Annex A
A.1
A.1.1
A.1.2
A.1.3
A.2
Annex B
TOE access history (FTA_TAH) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
TOE session establishment (FTA_TSE) . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
Class FTP: Trusted path/channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
Inter-TSF trusted channel (FTP_ITC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
Trusted path (FTP_TRP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
Security functional requirements application notes . . . . . . . . . . . . . . . . . . 173
Structure of the notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
Class structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
Family structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
Component structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
Dependency table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
Functional classes, families, and components . . . . . . . . . . . . . . . . . . . . . . . 183
Security audit (FAU) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
Security audit automatic response (FAU_ARP) . . . . . . . . . . . . . . . . . . . . . 187
Security audit data generation (FAU_GEN) . . . . . . . . . . . . . . . . . . . . . . . . 188
Security audit analysis (FAU_SAA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
Security audit review (FAU_SAR) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
Security audit event selection (FAU_SEL) . . . . . . . . . . . . . . . . . . . . . . . . 198
Security audit event storage (FAU_STG) . . . . . . . . . . . . . . . . . . . . . . . . . . 199
Communication (FCO) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
Non-repudiation of origin (FCO_NRO) . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
Non-repudiation of receipt (FCO_NRR) . . . . . . . . . . . . . . . . . . . . . . . . . . 207
Cryptographic support (FCS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
Cryptographic key management (FCS_CKM) . . . . . . . . . . . . . . . . . . . . . . 213
Cryptographic operation (FCS_COP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
User data protection (FDP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
Access control policy (FDP_ACC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
Access control functions (FDP_ACF) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
Data authentication (FDP_DAU) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
Export to outside TSF control (FDP_ETC) . . . . . . . . . . . . . . . . . . . . . . . . 232
Information flow control policy (FDP_IFC) . . . . . . . . . . . . . . . . . . . . . . . 234
Information flow control functions (FDP_IFF) . . . . . . . . . . . . . . . . . . . . . 237
Import from outside TSF control (FDP_ITC) . . . . . . . . . . . . . . . . . . . . . . . 243
Internal TOE transfer (FDP_ITT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
Residual information protection (FDP_RIP) . . . . . . . . . . . . . . . . . . . . . . . 250
Rollback (FDP_ROL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252
Stored data integrity (FDP_SDI) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
Inter-TSF user data confidentiality transfer protection (FDP_UCT) . . . . . 256
Inter-TSF user data integrity transfer protection (FDP_UIT) . . . . . . . . . . . 257
Identification and authentication (FIA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
Authentication failures (FIA_AFL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
User attribute definition (FIA_ATD) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
August 1999 Version 2.1
Page v of viii

Contents Part 2: Security functional requirements
Annex I
I.1
I.2
I.3
I.4
J.6
J.7
J.8
J.9
J.10
J.11
J.12
J.13
Annex J
J.1
J.2
J.3
J.4
J.5
J.14
J.15
J.16
G.3
G.4
G.5
G.6
Annex H
H.1
H.2
H.3
H.4
H.5
H.6
Annex K
K.1
K.2
K.3
Annex L
L.1
L.2
L.3
L.4
L.5
L.6
Specification of secrets (FIA_SOS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264
User authentication (FIA_UAU) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
User identification (FIA_UID) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270
User-subject binding (FIA_USB) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
Security management (FMT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273
Management of functions in TSF (FMT_MOF) . . . . . . . . . . . . . . . . . . . . . 275
Management of security attributes (FMT_MSA) . . . . . . . . . . . . . . . . . . . . 277
Management of TSF data (FMT_MTD) . . . . . . . . . . . . . . . . . . . . . . . . . . . 280
Revocation (FMT_REV) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282
Security attribute expiration (FMT_SAE) . . . . . . . . . . . . . . . . . . . . . . . . . 283
Security management roles (FMT_SMR) . . . . . . . . . . . . . . . . . . . . . . . . . . 284
Privacy (FPR) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287
Anonymity (FPR_ANO) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289
Pseudonymity (FPR_PSE) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292
Unlinkability (FPR_UNL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297
Unobservability (FPR_UNO) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
Protection of the TSF (FPT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303
Underlying abstract machine test (FPT_AMT) . . . . . . . . . . . . . . . . . . . . . 307
Fail secure (FPT_FLS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309
Availability of exported TSF data (FPT_ITA) . . . . . . . . . . . . . . . . . . . . . . 310
Confidentiality of exported TSF data (FPT_ITC) . . . . . . . . . . . . . . . . . . . 311
Integrity of exported TSF data (FPT_ITI) . . . . . . . . . . . . . . . . . . . . . . . . . 312
Internal TOE TSF data transfer (FPT_ITT) . . . . . . . . . . . . . . . . . . . . . . . . 314
TSF physical protection (FPT_PHP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316
Trusted recovery (FPT_RCV) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319
Replay detection (FPT_RPL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323
Reference mediation (FPT_RVM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324
Domain separation (FPT_SEP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326
State synchrony protocol (FPT_SSP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328
Time stamps (FPT_STM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329
Inter-TSF TSF data consistency (FPT_TDC) . . . . . . . . . . . . . . . . . . . . . . . 330
Internal TOE TSF data replication consistency (FPT_TRC) . . . . . . . . . . . 331
TSF self test (FPT_TST) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332
Resource utilisation (FRU) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334
Fault tolerance (FRU_FLT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335
Priority of service (FRU_PRS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337
Resource allocation (FRU_RSA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338
TOE access (FTA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341
Limitation on scope of selectable attributes (FTA_LSA) . . . . . . . . . . . . . . 342
Limitation on multiple concurrent sessions (FTA_MCS) . . . . . . . . . . . . . 343
Session locking (FTA_SSL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344
TOE access banners (FTA_TAB) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346
TOE access history (FTA_TAH) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347
TOE session establishment (FTA_TSE) . . . . . . . . . . . . . . . . . . . . . . . . . . . 348
Page vi of viii Version 2.1
August 1999

Part 2: Security functional requirements Contents
Annex M
M.1
M.2
Trusted path/channels (FTP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351
Inter-TSF trusted channel (FTP_ITC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352
Trusted path (FTP_TRP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353
August 1999 Version 2.1
Page vii of viii

Part 2: Security functional requirements viii
Figure 1.1 Security functional requirements paradigm (Monolithic TOE) . . . . . . . . . . . . 3
Figure 1.2 Diagram of security functions in a distributed TOE . . . . . . . . . . . . . . . . . . . . . 4
Figure 1.3 Relationship between user data and TSF data . . . . . . . . . . . . . . . . . . . . . . . . . 7
Figure 1.4 Relationship between “authentication data” and “secrets” . . . . . . . . . . . . . . . . 8
Figure 2.1 Functional class structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Figure 2.2 Functional family structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Figure 2.3 Functional component structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Figure 2.4 Sample class decomposition diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Figure 3.1 Security audit class decomposition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Figure 4.1 Communication class decomposition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Figure 5.1 Cryptographic support class decomposition . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Figure 6.1 User data protection class decomposition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Figure 6.2 User data protection class decomposition (cont.) . . . . . . . . . . . . . . . . . . . . . . . 46
Figure 7.1 Identification and authentication class decomposition . . . . . . . . . . . . . . . . . . . 80
Figure 8.1 Security management class decomposition . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Figure 9.1 Privacy class decomposition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Figure 10.1 - Protection of the TSF class decomposition . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
Figure 10.2 - Protection of the TSF class decomposition (Cont.) . . . . . . . . . . . . . . . . . . . . . 121
Figure 11.1 - Resource utilisation class decomposition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
Figure 12.1 - TOE access class decomposition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
Figure 13.1 - Trusted path/channels class decomposition . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
Figure A.1 - Functional class structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
Figure A.2 - Functional family structure for application notes . . . . . . . . . . . . . . . . . . . . . . . 174
Figure A.3 - Functional component structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
Figure C.1 - Security audit class decomposition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
Figure D.1 - Communication class decomposition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
Figure E.1 Cryptographic support class decomposition . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
Figure F.1 User data protection class decomposition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
Figure F.2 User data protection class decomposition (cont.) . . . . . . . . . . . . . . . . . . . . . . . 222
Figure G.1 - Identification and authentication class decomposition . . . . . . . . . . . . . . . . . . . 260
Figure H.1 - Security management class decomposition . . . . . . . . . . . . . . . . . . . . . . . . . . . 274
Figure I.1 Privacy class decomposition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287
Figure J.1 Protection of the TSF class decomposition . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304
Figure J.2 Protection of the TSF class decomposition (Cont.) . . . . . . . . . . . . . . . . . . . . . 305
Figure K.1 - Resource utilisation class decomposition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334
Figure L.1 TOE access class decomposition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341
Figure M.1 - Trusted path/channels class decomposition . . . . . . . . . . . . . . . . . . . . . . . . . . . 351
August 1999 Version 2.1
Page viii of viii

1
2
3
Extending and maintaining functional requirements
8 Part 2: Security functional requirements
4
Security functional components, as defined in this CC Part 2, are the basis for the
TOE IT security functional requirements expressed in a Protection Profile (PP) or a Security Target (ST). These requirements describe the desired security behaviour expected of a Target of Evaluation (TOE) and are intended to meet the security objectives as stated in a PP or an ST. These requirements describe security properties that users can detect by direct interaction with the TOE (i.e. inputs, outputs) or by the TOE’s response to stimulus.
Security functional components express security requirements intended to counter threats in the assumed operating environment of the TOE and/or cover any identified organisational security policies and assumptions.
-
-
-
The audience for this CC Part 2 includes consumers, developers, and evaluators of secure IT systems and products. CC Part 1 clause 3 provides additional information on the target audience of the CC, and on the use of the CC by the groups that comprise the target audience. These groups may use this part of the CC as follows:
Consumers who use CC Part 2 when selecting components to express functional requirements to satisfy the security objectives expressed in a PP or ST. CC Part 1 subclause 4.3 provides more detailed information on the relationship between security objectives and security requirements.
Developers, who respond to actual or perceived consumer security requirements in constructing a TOE, may find a standardised method to understand those requirements in this part of the CC. They can also use the contents of this part of the CC as a basis for further defining the TOE security functions and mechanisms that comply with those requirements.
Evaluators, who use the functional requirements defined in this part of the
CC in verifying that the TOE functional requirements expressed in the PP or ST satisfy the IT security objectives and that all dependencies are accounted for and shown to be satisfied. Evaluators also should use this part of the CC to assist in determining whether a given TOE satisfies stated requirements.
The CC and the associated security functional requirements described herein are not meant to be a definitive answer to all the problems of IT security. Rather, the CC offers a set of well understood security functional requirements that can be used to create trusted products or systems reflecting the needs of the market. These security functional requirements are presented as the current state of the art in requirements specification and evaluation.
August 1999 Version 2.1
Page 1 of 354

1 - Scope Organisation of CC Part 2
5
6
9
7
8
10
11
12
This part of the CC 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 CC Part 2 authors at the time of release.
Since the understanding and needs of consumers may change, the functional requirements in this part of the CC 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 CC Part 2. In those cases the PP/ST author may choose to consider using functional requirements not taken from the CC (referred to as extensibility), as explained in annexes B and C of CC Part 1.
-
-
-
Clause 1 is the introductory material for CC Part 2.
Clause 2 introduces the catalogue of CC Part 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 the
CC, 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 CC Part 1 for relevant structures, rules, and guidance:
CC Part 1, clause 2 defines the terms used in the CC.
CC Part 1, annex B defines the structure for PPs.
CC Part 1, annex C defines the structure for STs.
This subclause describes the paradigm used in the security functional requirements of this part of the CC. 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
CC glossary in CC Part 1, clause 2.
Page 2 of 354 Version 2.1
August 1999

Functional requirements paradigm 1 - Scope
Target of Evaluation (TOE)
TOE Security Functions Interface (TSFI)
Human
User
/ Remote IT
Product
User
Security
Attributes
Subject
TOE Security Functions
(TSF)
Enforces TOE Security Policy
(TSP)
Subject
Security
Attributes
Security
Attributes
Subject
Object/
Information
Security
Attributes
Resource
Subject
TSF Scope of Control (TSC)
Security
Attributes
Process
13
14
15
Figure 1.1 - Security functional requirements paradigm (Monolithic TOE)
This part of the CC 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.
August 1999 Version 2.1
Page 3 of 354

1 - Scope Functional requirements paradigm
16
17
18
Local User
Local (Internal TOE)
Trusted Path
Internal TOE Transfer
SF
SF
SF
Transfers
Outside TSF
Control
Inter-TSF
Trusted
Path
SF
SF
SF
Local TOE
Inter-TSF
Transfer
RF: Remote
Function
Untrusted IT Product
Remote User
Remote Trusted IT Product
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.
Page 4 of 354 Version 2.1
August 1999

Functional requirements paradigm 1 - Scope
19
20
21
22
23
24
25
August 1999
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.
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 CC Part 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.
Version 2.1
Page 5 of 354

1 - Scope Functional requirements paradigm
31
32
28
29
26
27
30
33
Page 6 of 354
This part of the CC 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 CC Part 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, CC
Part 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).
CC Part 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 CC Part 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.
Version 2.1
August 1999

Functional requirements paradigm 1 - Scope
34
35
36
37
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 the CC 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.
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
USER DATA
TSF DATA
Authentication
Data
Security Attributes
User Attributes
Object Attributes
Subject Attributes
Information Attributes
August 1999
Figure 1.3 - Relationship between user data and TSF data
Version 2.1
Page 7 of 354

1 - Scope Functional requirements paradigm
38
39
40
41
Two specific types of TSF data addressed by CC Part 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 CC Part 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”
Page 8 of 354 Version 2.1
August 1999

Overview 16 Part 2: Security functional requirements
42
2.1.1
43
This clause defines the content and presentation of the functional requirements of the CC, 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.
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
A contains B plus a number of C
Functional
Families
2.1.1.1
44
2.1.1.2
45
Figure 2.1 - Functional class structure
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.
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.
August 1999 Version 2.1
Page 9 of 354

2 - Security functional components Overview
46
2.1.2
47
The class introduction provides a figure describing the families in this class and the hierarchy of the components in each family, as explained in subclause 2.2.
Family structure
Figure 2.2 illustrates the functional family structure in diagrammatic form.
2.1.2.1
48
2.1.2.2
49
Functional
Family Family name
Family behaviour
Component levelling
Management
Audit
Components
Family name
Figure 2.2 - Functional family structure
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.
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) b)
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;
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.
Page 10 of 354 Version 2.1
August 1999

Overview 2 - Security functional components
2.1.2.3
50
51
52
53
2.1.2.4
54
55
2.1.2.5
56
57
58
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 Subclause 2.2 the descriptions of the families provide a graphical overview of the hierarchy of the components in a family.
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.
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.
August 1999 Version 2.1
Page 11 of 354

2 - Security functional components Overview
2.1.3
59
Component structure
Figure 2.3 illustrates the functional component structure.
Component
Component
Identification
Functional
Elements
Dependencies
61
62
2.1.3.1
60
63
2.1.3.2
64
65
66
Figure 2.3 - Functional component structure
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.
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 the CC.
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.
Page 12 of 354 Version 2.1
August 1999

Overview 2 - Security functional components
73
74
67
2.1.3.3
68
69
70
71
2.1.4
72
-
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.
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 the CC. 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 CC Part 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.
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 the CC, 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,
August 1999 Version 2.1
Page 13 of 354

2 - Security functional components Overview
80
81
2.1.4.1
75
2.1.4.2
76
77
2.1.4.3
78
2.1.4.4
79
-
-
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.
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 the CC to cover each aspect is permitted.
Assignment
Some functional component elements contain parameters or variables that enable the PP/ST author to specify a policy or a set of values for incorporation into the PP or ST to meet a specific security objective. These elements clearly identify each parameter and constraint on values that may be assigned to that parameter.
Any aspect of an element whose acceptable values can be unambiguously described or enumerated can be represented by a parameter. The parameter may be an attribute or rule that narrows the requirement to a specific value or range of values.
For instance, based on a specified security objective, the functional component element may state that a given operation should be performed a number of times. In this case, the assignment would provide the number, or range of numbers, to be used in the parameter.
Selection
This is the operation of picking one or more items from a list in order to narrow the scope of a component element.
Refinement
For all functional component elements the PP/ST author is permitted to limit the set of acceptable implementations by specifying additional detail in order to meet a security objective. Refinement of an element consists of adding these technical details.
Within a ST, the meanings of the terms subject and object might need to be explained for the TOE to be meaningful, and are therefore subject to refinement.
Like the other operations, refinement does not levy any completely new requirements. It applies an elaboration, interpretation, or a special meaning to a requirement, rule, constant or condition based on security objectives. Refinement shall only further restrict the set of possible acceptable functions or mechanisms to implement the requirements, but never increase it. Refinement does not allow new requirements to be created, and therefore does not increase the list of dependencies associated with a component. The PP/ST author must be careful that the dependency needs of other requirements that depend on this requirement, are satisfied.
Page 14 of 354 Version 2.1
August 1999

Component catalogue 2 - Security functional components
84
85
87
88
82
83
86
The grouping of the components in this part of the CC does not reflect any formal taxonomy.
This part of the CC contains classes of families and components, which are rough groupings on the basis of related function or purpose, presented in alphabetic order.
At the start of each class is an informative diagram that indicates the taxonomy of each class, indicating the families in each class and the components in each family.
The diagram is a useful indicator of the hierarchical relationship that may exist between components.
In the description of the functional components, a section identifies the dependencies between the component and any other components.
In each class a figure describing the family hierarchy similar to Figure 2.4, is provided. In Figure 2.4. the first family, Family 1, contains three hierarchical components, where component 2 and component 3 can both be used to satisfy dependencies on component 1. Component 3 is hierarchical to component 2 and can also be used to satisfy dependencies on component 2.
Class Name
Family 1
Family 2
Family 3
1 2 3
1
2 3
2
1 4
3
Figure 2.4 - Sample class decomposition diagram
In Family 2 there are three components not all of which are hierarchical.
Components 1 and 2 are hierarchical to no other components. Component 3 is hierarchical to component 2, and can be used to satisfy dependencies on component 2, but not to satisfy dependencies on component 1.
In Family 3, components 2, 3, and 4 are hierarchical to component 1. Components 2 and 3 are both hierarchical to component 1, but non-comparable. Component 4 is hierarchical to both component 2 and component 3.
These diagrams are meant to complement the text of the families and make identification of the relationships easier. They do not replace the “Hierarchical to:” note in each component that is the mandatory claim of hierarchy for each component.
August 1999 Version 2.1
Page 15 of 354

2 - Security functional components Component catalogue
2.2.1
89
Component changes highlighting
The relationship between components within a family is highlighted using a
bolding convention. This bolding convention calls for the bolding of all new requirements. For hierarchical components, requirements and/or dependencies are bolded when they are enhanced or modified beyond the requirements of the previous component. In addition, any new or enhanced permitted operations beyond the previous component are also highlighted using bold type.
Page 16 of 354 Version 2.1
August 1999

Part 2: Security functional requirements 30
90
Class FAUSecurity audit
Security auditing involves recognising, recording, storing, and analysing information related to security relevant activities (i.e. activities controlled by the
TSP). The resulting audit records can be examined to determine which security relevant activities took place and whom (which user) is responsible for them.
Security audit
FAU_ARP Security audit automatic response
FAU_GEN Security audit data generation
1
1
2
FAU_SAA Security audit analysis 1
2
3 4
FAU_SAR Security audit review
1
2
3
FAU_SEL Security audit event selection 1
FAU_STG Security audit event storage
1
3
2
4
August 1999
Figure 3.1 - Security audit class decomposition
Version 2.1
Page 17 of 354

3 - Class FAU: Security audit Security audit automatic response (FAU_ARP)
91
Family behaviour
This family defines the response to be taken in case of detected events indicative of a potential security violation.
Component levelling
FAU_ARP Security audit automatic response 1
92
93
94
At FAU_ARP.1 Security alarms, the TSF shall take actions in case a potential security violation is detected.
Management: FAU_ARP.1
The following actions could be considered for the management functions in FMT: a) the management (addition, removal, or modification) of actions.
Audit: FAU_ARP.1
The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST: a) Minimal: Actions taken due to imminent security violations.
FAU_ARP.1
Security alarms
Hierarchical to: No other components.
FAU_ARP.1.1
The TSF shall take [assignment: list of the least disruptive actions] upon detection of a potential security violation.
Dependencies: FAU_SAA.1 Potential violation analysis
Page 18 of 354 Version 2.1
August 1999

Security audit data generation (FAU_GEN) 3 - Class FAU: Security audit
95
Family behaviour
This family defines requirements for recording the occurrence of security relevant events that take place under TSF control. This family identifies the level of auditing, enumerates the types of events that shall be auditable by the TSF, and identifies the minimum set of audit-related information that should be provided within various audit record types.
Component levelling
1
FAU_GEN Security audit data generation
2
96
97
FAU_GEN.1 Audit data generation defines the level of auditable events, and specifies the list of data that shall be recorded in each record.
At FAU_GEN.2 User identity association, the TSF shall associate auditable events to individual user identities.
98
Management: FAU_GEN.1, FAU_GEN.2
There are no management activities foreseen.
99
Audit: FAU_GEN.1, FAU_GEN.2
There are no actions identified that should be auditable if FAU_GEN Security audit data generation is included in the PP/ST.
FAU_GEN.1
Audit data generation
Hierarchical to: No other components.
FAU_GEN.1.1
The TSF shall be able to generate an audit record of the following auditable events: a) Start-up and shutdown of the audit functions; b) All auditable events for the [selection: minimum, basic, detailed, not
specified] level of audit; and c) [assignment: other specifically defined auditable events].
FAU_GEN.1.2
The TSF shall record within each audit record at least the following information:
August 1999 Version 2.1
Page 19 of 354

3 - Class FAU: Security audit Security audit data generation (FAU_GEN) a) Date and time of the event, type of event, subject identity, and the outcome (success or failure) of the event; and b) For each audit event type, based on the auditable event definitions of the functional components included in the PP/ST, [assignment: other
audit relevant information]
Dependencies: FPT_STM.1 Reliable time stamps
FAU_GEN.2
User identity association
Hierarchical to: No other components.
FAU_GEN.2.1
The TSF shall be able to associate each auditable event with the identity of the user that caused the event.
Dependencies: FAU_GEN.1 Audit data generation
FIA_UID.1 Timing of identification
Page 20 of 354 Version 2.1
August 1999

Security audit analysis (FAU_SAA) 3 - Class FAU: Security audit

3 - Class FAU: Security audit Security audit analysis (FAU_SAA)
107
108 a) maintenance of the rules by (adding, modifying, deletion) of rules from the set of rules.
Management: FAU_SAA.2
The following actions could be considered for the management functions in FMT: a) maintenance (deletion, modification, addition) of the group of users in the profile target group.
Management: FAU_SAA.3
The following actions could be considered for the management functions in FMT: a) maintenance (deletion, modification, addition) of the subset of system events.
109
110
Management: FAU_SAA.4
The following actions could be considered for the management functions in FMT: a) maintenance (deletion, modification, addition) of the subset of system events; b) maintenance (deletion, modification, addition) of the set of sequence of system events.
Audit: FAU_SAA.1, FAU_SAA.2, FAU_SAA.3, FAU_SAA.4
The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST: a) Minimal: Enabling and disabling of any of the analysis mechanisms; b) Minimal: Automated responses performed by the tool.
FAU_SAA.1
Potential violation analysis
Hierarchical to: No other components.
FAU_SAA.1.1
The TSF shall be able to apply a set of rules in monitoring the audited events and based upon these rules indicate a potential violation of the TSP.
FAU_SAA.1.2
The TSF shall enforce the following rules for monitoring audited events: a) b)
Accumulation or combination of [assignment: subset of defined
auditable events] known to indicate a potential security violation;
[assignment: any other rules].
Page 22 of 354 Version 2.1
August 1999

Security audit analysis (FAU_SAA) 3 - Class FAU: Security audit
Dependencies: FAU_GEN.1 Audit data generation
FAU_SAA.2
Profile based anomaly detection
Hierarchical to: FAU_SAA.1
FAU_SAA.2.1
The TSF shall be able to maintain profiles of system usage, where an individual profile represents the historical patterns of usage performed by the member(s) of [assignment: the profile target group].
FAU_SAA.2.2
The TSF shall be able to maintain a suspicion rating associated with each user whose activity is recorded in a profile, where the suspicion rating represents the degree to which the user’s current activity is found inconsistent with the established patterns of usage represented in the profile.
FAU_SAA.2.3
The TSF shall be able to indicate an imminent violation of the TSP when a user’s suspicion rating exceeds the following threshold conditions [assignment:
conditions under which anomalous activity is reported by the TSF].
Dependencies: FIA_UID.1 Timing of identification
FAU_SAA.3
Simple attack heuristics
Hierarchical to: FAU_SAA.1
FAU_SAA.3.1
The TSF shall be able to maintain an internal representation of the following signature events [assignment: a subset of system events] that may indicate a violation of the TSP.
FAU_SAA.3.2
The TSF shall be able to compare the signature events against the record of system activity discernible from an examination of [assignment: the
information to be used to determine system activity].
FAU_SAA.3.3
The TSF shall be able to indicate an imminent violation of the TSP when a system event is found to match a signature event that indicates a potential violation of the TSP.
Dependencies: No dependencies
FAU_SAA.4
Complex attack heuristics
Hierarchical to: FAU_SAA.3
FAU_SAA.4.1
The TSF shall be able to maintain an internal representation of the following event sequences of known intrusion scenarios [assignment: list of sequences of system
events whose occurrence are representative of known penetration scenarios] and the following signature events [assignment: a subset of system events] that may indicate a potential violation of the TSP.
August 1999 Version 2.1
Page 23 of 354

3 - Class FAU: Security audit Security audit analysis (FAU_SAA)
FAU_SAA.4.2
The TSF shall be able to compare the signature events and event sequences against the record of system activity discernible from an examination of [assignment: the
information to be used to determine system activity].
FAU_SAA.4.3
The TSF shall be able to indicate an imminent violation of the TSP when system
activity is found to match a signature event or event sequence that indicates a potential violation of the TSP.
Dependencies: No dependencies
Page 24 of 354 Version 2.1
August 1999

Security audit review (FAU_SAR) 3 - Class FAU: Security audit

3 - Class FAU: Security audit Security audit review (FAU_SAR)
119
Audit: FAU_SAR.3
The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST: a) Detailed: the parameters used for the viewing.
FAU_SAR.1
Audit review
120
This component will provide authorised users the capability to obtain and interpret the information. In case of human users this information needs to be in a human understandable presentation. In case of external IT entities the information needs to be unambiguously represented in an electronic fashion.
Hierarchical to: No other components.
FAU_SAR.1.1
The TSF shall provide [assignment: authorised users] with the capability to read [assignment: list of audit information] from the audit records.
FAU_SAR.1.2
The TSF shall provide the audit records in a manner suitable for the user to interpret the information.
Dependencies: FAU_GEN.1 Audit data generation
FAU_SAR.2
Restricted audit review
Hierarchical to: No other components.
FAU_SAR.2.1
The TSF shall prohibit all users read access to the audit records, except those users that have been granted explicit read-access.
Dependencies: FAU_SAR.1 Audit review
FAU_SAR.3
Selectable audit review
Hierarchical to: No other components.
FAU_SAR.3.1
The TSF shall provide the ability to perform [selection: searches, sorting,
ordering] of audit data based on [assignment: criteria with logical relations].
Dependencies: FAU_SAR.1 Audit review
Page 26 of 354 Version 2.1
August 1999

Security audit event selection (FAU_SEL) 3 - Class FAU: Security audit
121
Family behaviour
This family defines requirements to select the events to be audited during TOE operation. It defines requirements to include or exclude events from the set of auditable events.
FAU_SEL Security audit event selection 1
122
123
FAU_SEL.1 Selective audit, requires the ability to include or exclude events from the set of audited events based upon attributes to be specified by the PP/ST author.
Management: FAU_SEL.1
The following actions could be considered for the management functions in FMT: a) maintenance of the rights to view/modify the audit events.
124
Audit: FAU_SEL.1
The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST: a) Minimal: All modifications to the audit configuration that occur while the audit collection functions are operating.
FAU_SEL.1
Selective audit
Hierarchical to: No other components.
FAU_SEL.1.1
The TSF shall be able to include or exclude auditable events from the set of audited events based on the following attributes: a) [selection: object identity, user identity, subject identity, host identity,
event type] b) [assignment: list of additional attributes that audit selectivity is based
upon].
Dependencies: FAU_GEN.1 Audit data generation
FMT_MTD.1 Management of TSF data
August 1999 Version 2.1
Page 27 of 354

3 - Class FAU: Security audit Security audit event storage (FAU_STG)
128
129
126
127
130
131
125
132
Family behaviour
This family defines the requirements for the TSF to be able to create and maintain a secure audit trail.
Component levelling
FAU_STG Security audit event storage
1
3
2
4
At FAU_STG.1 Protected audit trail storage, requirements are placed on the audit trail. It will be protected from unauthorised deletion and/or modification.
FAU_STG.2 Guarantees of audit data availability specifies the guarantees that the
TSF maintains over the audit data given the occurrence of an undesired condition.
FAU_STG.3 Action in case of possible audit data loss specifies actions to be taken if a threshold on the audit trail is exceeded.
FAU_STG.4 Prevention of audit data loss specifies actions in case the audit trail is full.
Management: FAU_STG.1
There are no management activities foreseen.
Management: FAU_STG.2
The following actions could be considered for the management functions in FMT: a) maintenance of the parameters that control the audit storage capability.
Management: FAU_STG.3
The following actions could be considered for the management functions in FMT: a) maintenance of the threshold; b) maintenance (deletion, modification, addition) of actions to be taken in case of imminent audit storage failure.
Page 28 of 354 Version 2.1
August 1999

Security audit event storage (FAU_STG) 3 - Class FAU: Security audit
133
134
135
Management: FAU_STG.4
The following actions could be considered for the management functions in FMT: a) maintenance (deletion, modification, addition) of actions to be taken in case of audit storage failure.
Audit: FAU_STG.1, FAU_STG.2
There are no actions identified that should be auditable if FAU_GEN Security audit data generation is included in the PP/ST.
Audit: FAU_STG.3
The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST: a) Basic: Actions taken due to exceeding of a threshold.
136
Audit: FAU_STG.4
The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST: a) Basic: Actions taken due to the audit storage failure.
FAU_STG.1
Protected audit trail storage
Hierarchical to: No other components.
FAU_STG.1.1
The TSF shall protect the stored audit records from unauthorised deletion.
FAU_STG.1.2
The TSF shall be able to [selection: prevent, detect] modifications to the audit records.
Dependencies: FAU_GEN.1 Audit data generation
FAU_STG.2
Guarantees of audit data availability
Hierarchical to: FAU_STG.1
FAU_STG.2.1
The TSF shall protect the stored audit records from unauthorised deletion.
FAU_STG.2.2
The TSF shall be able to [selection: prevent, detect] modifications to the audit records.
FAU_STG.2.3
The TSF shall ensure that [assignment: metric for saving audit records] audit records will be maintained when the following conditions occur: [selection:
audit storage exhaustion, failure, attack].
Dependencies: FAU_GEN.1 Audit data generation
August 1999 Version 2.1
Page 29 of 354

3 - Class FAU: Security audit Security audit event storage (FAU_STG)
FAU_STG.3
Action in case of possible audit data loss
Hierarchical to: No other components.
FAU_STG.3.1
The TSF shall take [assignment: actions to be taken in case of possible audit
storage failure] if the audit trail exceeds [assignment: pre-defined limit].
Dependencies: FAU_STG.1 Protected audit trail storage
FAU_STG.4
Prevention of audit data loss
Hierarchical to: FAU_STG.3
FAU_STG.4.1
The TSF shall [selection: ‘ignore auditable events’, ‘prevent auditable events, except those taken by the authorised user with special rights’, ‘overwrite the
oldest stored audit records’] and [assignment: other actions to be taken in case
of audit storage failure] if the audit trail is full.
Dependencies: FAU_STG.1 Protected audit trail storage
Page 30 of 354 Version 2.1
August 1999

Part 2: Security functional requirements 36
137
138
Class FAUCommunication
This class provides two families specifically concerned with assuring the identity of a party participating in a data exchange. These families are related to assuring the identity of the originator of transmitted information (proof of origin) and assuring the identity of the recipient of transmitted information (proof of receipt). These families ensure that an originator cannot deny having sent the message, nor can the recipient deny having received it.
Figure 4.1 shows the decomposition of this class into its constituent components.
Communication
FCO_NRO Non-repudiation of origin
FCO_NRR Non-repudiation of receipt
Figure 4.1 - Communication class decomposition
1
1
2
2
August 1999 Version 2.1
Page 31 of 354

4 - Class FCO: Communication Non-repudiation of origin (FCO_NRO)
140
141
FCO_NRO
139
142
143
Non-repudiation of origin
Family behaviour
Non-repudiation of origin ensures that the originator of information cannot successfully deny having sent the information. This family requires that the TSF provide a method to ensure that a subject that receives information during a data exchange is provided with evidence of the origin of the information. This evidence can then be verified by either this subject or other subjects.
Component levelling
FCO_NRO Non-repudiation of origin 1 2
FCO_NRO.1 Selective proof of origin requires the TSF to provide subjects with the capability to request evidence of the origin of information.
FCO_NRO.2 Enforced proof of origin requires that the TSF always generate evidence of origin for transmitted information.
Management: FCO_NRO.1, FCO_NRO.2
The following actions could be considered for the management functions in FMT: a) The management of changes to information types, fields, originator attributes and recipients of evidence.
Audit: FCO_NRO.1
The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST: a) Minimal: The identity of the user who requested that evidence of origin would be generated.
b) Minimal: The invocation of the non-repudiation service.
c) Basic: Identification of the information, the destination, and a copy of the evidence provided.
d) Detailed: The identity of the user who requested a verification of the evidence.
Page 32 of 354 Version 2.1
August 1999

Non-repudiation of origin (FCO_NRO) 4 - Class FCO: Communication
144
Audit: FCO_NRO.2
The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST: a) Minimal: The invocation of the non-repudiation service.
b) Basic: Identification of the information, the destination, and a copy of the evidence provided.
c) Detailed: The identity of the user who requested a verification of the evidence.
FCO_NRO.1
Selective proof of origin
Hierarchical to: No other components.
FCO_NRO.1.1
The TSF shall be able to generate evidence of origin for transmitted
[assignment: list of information types] at the request of the [selection:
originator, recipient, [assignment: list of third parties]].
FCO_NRO.1.2
The TSF shall be able to relate the [assignment: list of attributes] of the originator of the information, and the [assignment: list of information fields] of the information to which the evidence applies.
FCO_NRO.1.3
The TSF shall provide a capability to verify the evidence of origin of information to [selection: originator, recipient, [assignment: list of third
parties]] given [assignment: limitations on the evidence of origin].
Dependencies: FIA_UID.1 Timing of identification
FCO_NRO.2
Enforced proof of origin
Hierarchical to: FCO_NRO.1
FCO_NRO.2.1
The TSF shall enforce the generation of evidence of origin for transmitted
[assignment: list of information types] at all times.
FCO_NRO.2.2
The TSF shall be able to relate the [assignment: list of attributes] of the originator of the information, and the [assignment: list of information fields] of the information to which the evidence applies.
FCO_NRO.2.3
The TSF shall provide a capability to verify the evidence of origin of information to [selection: originator, recipient, [assignment: list of third parties]] given
[assignment: limitations on the evidence of origin].
Dependencies: FIA_UID.1 Timing of identification
Non-repudiation of receipt FCO_NRR
August 1999 Version 2.1
Page 33 of 354

4 - Class FCO: Communication Non-repudiation of receipt (FCO_NRR)

Non-repudiation of receipt (FCO_NRR) 4 - Class FCO: Communication a) Minimal: The invocation of the non-repudiation service.
b) Basic: Identification of the information, the destination, and a copy of the evidence provided.
c) Detailed: The identity of the user who requested a verification of the evidence.
FCO_NRR.1
Selective proof of receipt
Hierarchical to: No other components.
FCO_NRR.1.1
The TSF shall be able to generate evidence of receipt for received [assignment:
list of information types] at the request of the [selection: originator, recipient,
[assignment: list of third parties]].
FCO_NRR.1.2
The TSF shall be able to relate the [assignment: list of attributes] of the recipient of the information, and the [assignment: list of information fields] of the information to which the evidence applies.
FCO_NRR.1.3
The TSF shall provide a capability to verify the evidence of receipt of information to [selection: originator, recipient, [assignment: list of third
parties]] given [assignment: limitations on the evidence of receipt].
Dependencies: FIA_UID.1 Timing of identification
FCO_NRR.2
Enforced proof of receipt
Hierarchical to: FCO_NRR.1
FCO_NRR.2.1
The TSF shall enforce the generation of evidence of receipt for received
[assignment: list of information types].
FCO_NRR.2.2
The TSF shall be able to relate the [assignment: list of attributes] of the recipient of the information, and the [assignment: list of information fields] of the information to which the evidence applies.
FCO_NRR.2.3
The TSF shall provide a capability to verify the evidence of receipt of information to [selection: originator, recipient, [assignment: list of third parties]] given
[assignment: limitations on the evidence of receipt].
Dependencies: FIA_UID.1 Timing of identification
August 1999 Version 2.1
Page 35 of 354

4 - Class FCO: Communication Non-repudiation of receipt (FCO_NRR)
Page 36 of 354 Version 2.1
August 1999

Part 2: Security functional requirements 42 Cryptographic key management
151
152
153
Class FAUCryptographic support
The TSF may employ cryptographic functionality to help satisfy several high-level security objectives. These include (but are not limited to): identification and authentication, non-repudiation, trusted path, trusted channel and data separation.
This class is used when the TOE implements cryptographic functions, the implementation of which could be in hardware, firmware and/or software.
The FCS class is composed of two families: FCS_CKM Cryptographic key management and FCS_COP Cryptographic operation. The FCS_CKM family addresses the management aspects of cryptographic keys, while the FCS_COP family is concerned with the operational use of those cryptographic keys.
Figure 5.1 shows the decomposition of this class into its constituent components.
FCS_CKM
154
Cryptographic support
FCS_CKM Cryptographic key management
3
4
1
2
1 FCS_COP Cryptographic operation
Figure 5.1 - Cryptographic support class decomposition
Cryptographic key management
Family behaviour
Cryptographic keys must be managed throughout their life cycle. This family is intended to support that lifecycle and consequently defines requirements for the following activities: cryptographic key generation, cryptographic key distribution, cryptographic key access and cryptographic key destruction. This family should be included whenever there are functional requirements for the management of cryptographic keys.
August 1999 Version 2.1
Page 37 of 354

157
158
155
156
5 - Class FCS: Cryptographic support
159
160
Cryptographic key management
(FCS_CKM)
Component levelling
FCS_CKM Cryptographic key management
3
4
1
2
FCS_CKM.1 Cryptographic key generation requires cryptographic keys to be generated in accordance with a specified algorithm and key sizes which can be based on an assigned standard.
FCS_CKM.2 Cryptographic key distribution requires cryptographic keys to be distributed in accordance with a specified distribution method which can be based on an assigned standard.
FCS_CKM.3 Cryptographic key access requires access to cryptographic keys to be performed in accordance with a specified access method which can be based on an assigned standard.
FCS_CKM.4 Cryptographic key destruction requires cryptographic keys to be destroyed in accordance with a specified destruction method which can be based on an assigned standard.
Management: FCS_CKM.1, FCS_CKM.2, FCS_CKM.3, FCS_CKM.4
The following actions could be considered for the management functions in FMT: a) b) a) the management of changes to cryptographic key attributes. Examples of key attributes include user, key type (e.g. public, private, secret), validity period, and use (e.g. digital signature, key encryption, key agreement, data encryption).
Audit: FCS_CKM.1, FCS_CKM.2, FCS_CKM.3, FCS_CKM.4
The following actions should be auditable if FAU_GEN Security Audit Data
Generation is included in the PP/ST:
Minimal: Success and failure of the activity.
Basic: The object attribute(s), and object value(s) excluding any sensitive information (e.g. secret or private keys).
Page 38 of 354 Version 2.1
August 1999

Cryptographic key management
(FCS_CKM)
5 - Class FCS: Cryptographic support
FCS_CKM.1
Cryptographic key generation
Hierarchical to: No other components.
FCS_CKM.1.1
The TSF shall generate cryptographic keys in accordance with a specified cryptographic key generation algorithm [assignment: cryptographic key
generation algorithm] and specified cryptographic key sizes [assignment:
cryptographic key sizes] that meet the following: [assignment: list of standards].
Dependencies: [FCS_CKM.2 Cryptographic key distribution or
FCS_COP.1 Cryptographic operation]
FCS_CKM.4 Cryptographic key destruction
FMT_MSA.2 Secure security attributes
FCS_CKM.2
Cryptographic key distribution
Hierarchical to: No other components.
FCS_CKM.2.1
The TSF shall distribute cryptographic keys in accordance with a specified cryptographic key distribution method [assignment: cryptographic key
distribution method] that meets the following: [assignment: list of standards].
Dependencies: [FDP_ITC.1 Import of user data without security attributes or
FCS_CKM.1 Cryptographic key generation]
FCS_CKM.4 Cryptographic key destruction
FMT_MSA.2 Secure security attributes
FCS_CKM.3
Cryptographic key access
Hierarchical to: No other components.
FCS_CKM.3.1
The TSF shall perform [assignment: type of cryptographic key access] in accordance with a specified cryptographic key access method [assignment:
cryptographic key access method] that meets the following: [assignment: list of
standards].
Dependencies: [FDP_ITC.1 Import of user data without security attributes or
FCS_CKM.1 Cryptographic key generation]
FCS_CKM.4 Cryptographic key destruction
FMT_MSA.2 Secure security attributes
August 1999 Version 2.1
Page 39 of 354

5 - Class FCS: Cryptographic support Cryptographic operation (FCS_COP)
FCS_CKM.4
Cryptographic key destruction
Hierarchical to: No other components.
FCS_CKM.4.1
The TSF shall destroy cryptographic keys in accordance with a specified cryptographic key destruction method [assignment: cryptographic key
destruction method] that meets the following: [assignment: list of standards].
Dependencies: [FDP_ITC.1 Import of user data without security attributes or
FCS_CKM.1 Cryptographic key generation]
FMT_MSA.2 Secure security attributes
FCS_COP
161
162
Cryptographic operation
Family behaviour
In order for a cryptographic operation to function correctly, the operation must be performed in accordance with a specified algorithm and with a cryptographic key of a specified size. This family should be included whenever there are requirements for cryptographic operations to be performed.
Typical cryptographic operations include data encryption and/or decryption, digital signature generation and/or verification, cryptographic checksum generation for integrity and/or verification of checksum, secure hash (message digest), cryptographic key encryption and/or decryption, and cryptographic key agreement.
Component levelling
FCS_COP Cryptographic operation 1
163
164
165
FCS_COP.1 Cryptographic operation requires a cryptographic operation to be performed in accordance with a specified algorithm and with a cryptographic key of specified sizes. The specified algorithm and cryptographic key sizes can be based on an assigned standard.
Management: FCS_COP.1
There are no management activities foreseen for these components.
Audit: FCS_COP.1
The following actions should be auditable if FAU_GEN Security Audit Data
Generation is included in the PP/ST:
Page 40 of 354 Version 2.1
August 1999

Cryptographic operation (FCS_COP) 5 - Class FCS: Cryptographic support a) Minimal: Success and failure, and the type of cryptographic operation. b) Basic: Any applicable cryptographic mode(s) of operation, subject attributes and object attributes.
FCS_COP.1
Cryptographic operation
Hierarchical to: No other components.
FCS_COP.1.1
The TSF shall perform [assignment: list of cryptographic operations] in accordance with a specified cryptographic algorithm [assignment:
cryptographic algorithm] and cryptographic key sizes [assignment:
cryptographic key sizes] that meet the following: [assignment: list of standards].
Dependencies: [FDP_ITC.1 Import of user data without security attributes or
FCS_CKM.1 Cryptographic key generation]
FCS_CKM.4 Cryptographic key destruction
FMT_MSA.2 Secure security attributes
August 1999 Version 2.1
Page 41 of 354

5 - Class FCS: Cryptographic support Cryptographic operation (FCS_COP)
Page 42 of 354 Version 2.1
August 1999

Part 2: Security functional requirements 78
166
167
August 1999
Class FDPUser data protection
This class contains families specifying requirements for TOE security functions and
TOE security function policies related to protecting user data. FDP is split into four groups of families (listed below) that address user data within a TOE, during import, export, and storage as well as security attributes directly related to user data.
The families in this class are organised into four groups: a) User data protection security function policies:
-
FDP_ACC Access control policy; and
FDP_IFC Information flow control policy.
Components in these families permit the PP/ST author to name the user data protection security function policies and define the scope of control of the policy, necessary to address the security objectives. The names of these policies are meant to be used throughout the remainder of the functional components that have an operation that calls for an assignment or selection of an "access control SFP" or an "information flow control SFP". The rules that define the functionality of the named access control and information flow control SFPs will be defined in the FDP_ACF and FDP_IFF families
(respectively).
-
-
-
-
-
b) Forms of user data protection:
FDP_ACF Access control functions;
FDP_IFF Information flow control functions;
FDP_ITT Internal TOE transfer;
FDP_RIP Residual information protection;
FDP_ROL Rollback; and
FDP_SDI Stored data integrity.
-
-
c) Off-line storage, import and export:
FDP_DAU Data authentication;
FDP_ETC Export to outside TSF control; and
FDP_ITC Import from outside TSF control.
Components in these families address the trustworthy transfer into or out of the TSC.
-
d) Inter-TSF communication:
FDP_UCT Inter-TSF user data confidentiality transfer protection; and
FDP_UIT Inter-TSF user data integrity transfer protection.
Version 2.1
Page 43 of 354

6 - Class FDP: User data protection
Components in these families address communication between the TSF of the TOE and another trusted IT product.
Figures 6.1 and 6.2 show the decomposition of this class into its constituent components.
Page 44 of 354 Version 2.1
August 1999

6 - Class FDP: User data protection
User data protection
FDP_ACC Access control policy 1 2
FDP_ACF Access control functions
FDP_DAU Data authentication
FDP_ETC Export to outside TSF control
FDP_IFC Information flow control policy
FDP_IFF Information flow control functions
FDP_ITC Import from outside TSF control
FDP_ITT Internal TOE transfer
1
2
1
3
2
4
Figure 6.1 - User data protection class decomposition
1
1
1
2
1
2
2
1
3
6
2
4 5
August 1999 Version 2.1
Page 45 of 354

6 - Class FDP: User data protection
User data protection
FDP_RIP Residual information protection
FDP_ROL Rollback
FDP_SDI Stored data integrity
FDP_UCT Inter-TSF user data confidentiality transfer protection
FDP_UIT Inter-TSF user data integrity transfer protection
1 2
1 2
1 2
1
1
2 3
Figure 6.2 - User data protection class decomposition (cont.)
Page 46 of 354 Version 2.1
August 1999

Access control policy (FDP_ACC) 6 - Class FDP: User data protection
FDP_ACC
168
Access control policy
Family behaviour
This family identifies the access control SFPs (by name) and defines the scope of control of the policies that form the identified access control portion of the TSP.
This scope of control is characterised by three sets: the subjects under control of the policy, the objects under control of the policy, and the operations among controlled subjects and controlled objects that are covered by the policy. The criteria allows multiple policies to exist, each having a unique name. This is accomplished by iterating components from this family once for each named access control policy.
The rules that define the functionality of an access control SFP will be defined by other families such as FDP_ACF and FDP_SDI. The names of the access control
SFPs identified here in FDP_ACC are meant to be used throughout the remainder of the functional components that have an operation that calls for an assignment or selection of an “access control SFP.”
Component levelling
FDP_ACC Access control policy 1 2
169
170
FDP_ACC.1 Subset access control requires that each identified access control SFP be in place for a subset of the possible operations on a subset of the objects in the
TOE.
FDP_ACC.2 Complete access control requires that each identified access control
SFP cover all operations on subjects and objects covered by that SFP. It further requires that all objects and operations with the TSC are covered by at least one identified access control SFP.
171
172
Management: FDP_ACC.1, FDP_ACC.2
There are no management activities foreseen for this component.
Audit: FDP_ACC.1, FDP_ACC.2
There are no events identified that should be auditable if FAU_GEN Security audit data generation is included in the PP/ST.
FDP_ACC.1
Subset access control
Hierarchical to: No other components.
FDP_ACC.1.1
The TSF shall enforce the [assignment: access control SFP] on [assignment: list
of subjects, objects, and operations among subjects and objects covered by the
SFP].
August 1999 Version 2.1
Page 47 of 354

6 - Class FDP: User data protection Access control policy (FDP_ACC)
Dependencies: FDP_ACF.1 Security attribute based access control
FDP_ACC.2
Complete access control
Hierarchical to: FDP_ACC.1
FDP_ACC.2.1
The TSF shall enforce the [assignment: access control SFP] on [assignment: list of
subjects and objects] and all operations among subjects and objects covered by the SFP.
FDP_ACC.2.2
The TSF shall ensure that all operations between any subject in the TSC and any object within the TSC are covered by an access control SFP.
Dependencies: FDP_ACF.1 Security attribute based access control
Page 48 of 354 Version 2.1
August 1999

Access control functions (FDP_ACF) 6 - Class FDP: User data protection
FDP_ACF
173
174
175
176
177
Access control functions
Family behaviour
This family describes the rules for the specific functions that can implement an access control policy named in FDP_ACC. FDP_ACC specifies the scope of control of the policy.
Component levelling
FDP_ACF Access control functions 1
This family addresses security attribute usage and characteristics of policies. The component within this family is meant to be used to describe the rules for the function that implements the SFP as identified in FDP_ACC. The PP/ST author may also iterate this component to address multiple policies in the TOE.
FDP_ACF.1 Security attribute based access control allows the TSF to enforce access based upon security attributes and named groups of attributes. Furthermore, the TSF may have the ability to explicitly authorise or deny access to an object based upon security attributes.
Management: FDP_ACF.1
The following actions could be considered for the management functions in FMT
Management: a) Managing the attributes used to make explicit access or denial based decisions.
Audit: FDP_ACF.1
The following events should be auditable if FAU_GEN Security audit data generation is included in the PP/ST: a) Minimal: Successful requests to perform an operation on an object covered by the SFP.
b) Basic: All requests to perform an operation on an object covered by the
SFP.
c) Detailed: The specific security attributes used in making an access check.
August 1999 Version 2.1
Page 49 of 354

6 - Class FDP: User data protection Access control functions (FDP_ACF)
FDP_ACF.1
Security attribute based access control
Hierarchical to: No other components.
FDP_ACF.1.1
The TSF shall enforce the [assignment: access control SFP] to objects based on
[assignment: security attributes, named groups of security attributes].
FDP_ACF.1.2
The TSF shall enforce the following rules to determine if an operation among controlled subjects and controlled objects is allowed: [assignment: rules governing access among controlled subjects and controlled objects using
controlled operations on controlled objects].
FDP_ACF.1.3
The TSF shall explicitly authorise access of subjects to objects based on the following additional rules: [assignment: rules, based on security attributes, that
explicitly authorise access of subjects to objects].
FDP_ACF.1.4
The TSF shall explicitly deny access of subjects to objects based on the
[assignment: rules, based on security attributes, that explicitly deny access of
subjects to objects].
Dependencies: FDP_ACC.1 Subset access control
FMT_MSA.3 Static attribute initialisation
Page 50 of 354 Version 2.1
August 1999

Data authentication (FDP_DAU) 6 - Class FDP: User data protection
179
180
FDP_DAU
178
181
182
183
Data authentication
Family behaviour
Data authentication permits an entity to accept responsibility for the authenticity of information (e.g., by digitally signing it). This family provides a method of providing a guarantee of the validity of a specific unit of data that can be subsequently used to verify that the information content has not been forged or fraudulently modified. In contrast to Class FAU, this family is intended to be applied to "static" data rather than data that is being transferred.
Component levelling
FDP_DAU Data authentication 1 2
FDP_DAU.1 Basic Data Authentication requires that the TSF is capable of generating a guarantee of authenticity of the information content of objects (e.g.
documents).
FDP_DAU.2 Data Authentication with Identity of Guarantor additionally requires that the TSF is capable of establishing the identity of the subject who provided the guarantee of authenticity.
Management: FDP_DAU.1, FDP_DAU.2
The following actions could be considered for the management functions in FMT
Management: a) The assignment or modification of the objects for which data authentication may apply could be configurable in the system.
Audit: FDP_DAU.1
The following events should be auditable if FAU_GEN Security audit data generation is included in the PP/ST.
a) Minimal: Successful generation of validity evidence.
b) Basic: Unsuccessful generation of validity evidence.
c) Detailed: The identity of the subject that requested the evidence.
Audit: FDP_DAU.2
The following events should be auditable if FAU_GEN Security audit data generation is included in the PP/ST.
August 1999 Version 2.1
Page 51 of 354

6 - Class FDP: User data protection Data authentication (FDP_DAU) a) Minimal: Successful generation of validity evidence.
b) Basic: Unsuccessful generation of validity evidence.
c) Detailed: The identity of the subject that requested the evidence.
d) Detailed: The identity of the subject that generated the evidence.
FDP_DAU.1
Basic data authentication
Hierarchical to: No other components.
FDP_DAU.1.1
The TSF shall provide a capability to generate evidence that can be used as a
guarantee of the validity of [assignment: list of objects or information types].
FDP_DAU.1.2
The TSF shall provide [assignment: list of subjects] with the ability to verify
evidence of the validity of the indicated information.
Dependencies: No dependencies
FDP_DAU.2
Data authentication with identity of guarantor
Hierarchical to: FDP_DAU.1
FDP_DAU.2.1
The TSF shall provide a capability to generate evidence that can be used as a guarantee of the validity of [assignment: list of objects or information types].
FDP_DAU.2.2
The TSF shall provide [assignment: list of subjects] with the ability to verify evidence of the validity of the indicated information and the identity of the user that generated the evidence.
Dependencies: FIA_UID.1 Timing of identification
Page 52 of 354 Version 2.1
August 1999

Export to outside TSF control
(FDP_ETC)
6 - Class FDP: User data protection
187
188
FDP_ETC
184
185
186
189
Export to outside TSF control
Family behaviour
This family defines functions for exporting user data from the TOE such that its security attributes and protection either can be explicitly preserved or can be ignored once it has been exported. It is concerned with limitations on export and with the association of security attributes with the exported user data.
Component levelling
1
FDP_ETC Export to outside TSF control
2
FDP_ETC.1 Export of user data without security attributes requires that the TSF enforce the appropriate SFPs when exporting user data outside the TSF. User data that is exported by this function is exported without its associated security attributes.
FDP_ETC.2 Export of user data with security attributes requires that the TSF enforce the appropriate SFPs using a function that accurately and unambiguously associates security attributes with the user data that is exported.
Management: FDP_ETC.1
There are no management activities foreseen for this component.
Management: FDP_ETC.2
The following actions could be considered for the management functions in FMT
Management: a) The additional exportation control rules could be configurable by a user in a defined role.
Audit: FDP_ETC.1, FDP_ETC.2
The following events shall be auditable if FAU_GEN Security audit data generation is included in the PP/ST: a) Minimal: Successful export of information.
b) Basic: All attempts to export information.
August 1999 Version 2.1
Page 53 of 354

6 - Class FDP: User data protection Export to outside TSF control (FDP_ETC)
FDP_ETC.1
Export of user data without security attributes
Hierarchical to: No other components.
FDP_ETC.1.1
The TSF shall enforce the [assignment: access control SFP(s) and/or
information flow control SFP(s)] when exporting user data, controlled under the SFP(s), outside of the TSC.
FDP_ETC.1.2
The TSF shall export the user data without the user data’s associated security attributes.
Dependencies: [FDP_ACC.1 Subset access control, or
FDP_IFC.1 Subset information flow control]
FDP_ETC.2
Export of user data with security attributes
Hierarchical to: No other components.
FDP_ETC.2.1
The TSF shall enforce the [assignment: access control SFP(s) and/or
information flow control SFP(s)] when exporting user data, controlled under the SFP(s), outside of the TSC.
FDP_ETC.2.2
The TSF shall export the user data with the user data’s associated security attributes.
FDP_ETC.2.3
The TSF shall ensure that the security attributes, when exported outside the
TSC, are unambiguously associated with the exported user data.
FDP_ETC.2.4
The TSF shall enforce the following rules when user data is exported from the
TSC: [assignment: additional exportation control rules].
Dependencies: [FDP_ACC.1 Subset access control, or
FDP_IFC.1 Subset information flow control]
Page 54 of 354 Version 2.1
August 1999

Information flow control policy
(FDP_IFC)
6 - Class FDP: User data protection
192
193
FDP_IFC
190
191
194
Information flow control policy
Family behaviour
This family identifies the information flow control SFPs (by name) and defines the scope of control of the policies that form the identified information flow control portion of the TSP. This scope of control is characterised by three sets: the subjects under control of the policy, the information under control of the policy, and operations which cause controlled information to flow to and from controlled subjects covered by the policy. The criteria allows multiple policies to exist, each having a unique name. This is accomplished by iterating components from this family once for each named information flow control policy. The rules that define the functionality of an information flow control SFP will be defined by other families such as FDP_IFF and FDP_SDI. The names of the information flow control SFPs identified here in FDP_IFC are meant to be used throughout the remainder of the functional components that have an operation that calls for an assignment or selection of an “information flow control SFP.”
The TSF mechanism controls the flow of information in accordance with the information flow control SFP. Operations that would change the security attributes of information are not generally permitted as this would be in violation of an information flow control SFP. However, such operations may be permitted as exceptions to the information flow control SFP if explicitly specified.
Component levelling
FDP_IFC Information flow control policy 1 2
FDP_IFC.1 Subset information flow control requires that each identified information flow control SFPs be in place for a subset of the possible operations on a subset of information flows in the TOE.
FDP_IFC.2 Complete information flow control requires that each identified information flow control SFP cover all operations on subjects and information covered by that SFP. It further requires that all information flows and operations with the TSC are covered by at least one identified information flow control SFP.
In conjunction with the FPT_RVM.1 component, this gives the “always invoked” aspect of a reference monitor.
Management: FDP_IFC.1, FDP_IFC.2
There are no management activities foreseen for this component.
August 1999 Version 2.1
Page 55 of 354

6 - Class FDP: User data protection Information flow control policy
(FDP_IFC)
195
Audit: FDP_IFC.1, FDP_IFC.2
There are no events identified that should be auditable if FAU_GEN Security audit data generation is included in the PP/ST.
FDP_IFC.1
Subset information flow control
Hierarchical to: No other components.
FDP_IFC.1.1
The TSF shall enforce the [assignment: information flow control SFP] on
[assignment: list of subjects, information, and operations that cause controlled
information to flow to and from controlled subjects covered by the SFP].
Dependencies: FDP_IFF.1 Simple security attributes
FDP_IFC.2
Complete information flow control
Hierarchical to: FDP_IFC.1
FDP_IFC.2.1
FDP_IFC.2.2
The TSF shall enforce the [assignment: information flow control SFP] on
[assignment: list of subjects and information] and all operations that cause that information to flow to and from subjects covered by the SFP.
The TSF shall ensure that all operations that cause any information in the TSC to flow to and from any subject in the TSC are covered by an information flow control SFP.
Dependencies: FDP_IFF.1 Simple security attributes
Page 56 of 354 Version 2.1
August 1999

Information flow control functions
(FDP_IFF)
6 - Class FDP: User data protection
198
201
202
199
200
FDP_IFF
196
197
Information flow control functions
Family behaviour
This family descibes the rules for the specific functions that can implement the information flow control SFPs named in FDP_IFC, which also specifies the scope of control of the policy. It consists of two kinds of requirements: one addressing the common information flow function issues, and a second addressing illicit information flows (i.e. covert channels). This division arises because the issues concerning illicit information flows are, in some sense, orthogonal to the rest of an information flow control SFP. By their nature they circumvent the information flow control SFP resulting in a violation of the policy. As such, they require special functions to either limit or prevent their occurrence.
Component levelling
FDP_IFF Information flow control functions
1
3
6
2
4 5
FDP_IFF.1 Simple security attributes requires security attributes on information, and on subjects that cause that information to flow and on subjects that act as recipients of that information. It specifies the rules that must be enforced by the function, and describes how security attributes are derived by the function.
FDP_IFF.2 Hierarchical security attributes expands on the requirements of
FDP_IFF.1 Simple security attributes by requiring that all information flow control
SFPs in the TSP use hierarchical security attributes that form a lattice.
FDP_IFF.3 Limited illicit information flows requires the SFP to cover illicit information flows, but not necessarily eliminate them.
FDP_IFF.4 Partial elimination of illicit information flows requires the SFP to cover the elimination of some (but not necessarily all) illicit information flows.
FDP_IFF.5 No illicit information flows requires SFP to cover the elimination of all illicit information flows.
FDP_IFF.6 Illicit information flow monitoring requires the SFP to monitor illicit information flows for specified and maximum capacities.
August 1999 Version 2.1
Page 57 of 354

204
205
6 - Class FDP: User data protection
203
206
207
Information flow control functions
(FDP_IFF)
Management: FDP_IFF.1, FDP_IFF.2
The following actions could be considered for the management functions in FMT
Management: a) Managing the attributes used to make explicit access based decisions.
Management: FDP_IFF.3, FDP_IFF.4, FDP_IFF.5
There are no management activities foreseen for these components.
Management: FDP_IFF.6
The following actions could be considered for the management functions in FMT
Management: a) The enabling or disabling of the monitoring function.
b) Modification of the maximum capacity at which the monitoring occurs.
Audit: FDP_IFF.1, FDP_IFF.2, FDP_IFF.5
The following events should be auditable if FAU_GEN Security audit data generation is included in a PP/ST: a) Minimal: Decisions to permit requested information flows.
b) Basic: All decisions on requests for information flow.
c) Detailed: The specific security attributes used in making an information flow enforcement decision.
d) Detailed: Some specific subsets of the information that has flowed based upon policy goals (e.g. auditing of downgraded material).
Audit: FDP_IFF.3, FDP_IFF.4, FDP_IFF.6
The following events should be auditable if FAU_GEN Security audit data generation is included in a PP/ST: a) Minimal: Decisions to permit requested information flows.
b) Basic: All decisions on requests for information flow.
c) Basic: The use of identified illicit information flow channels.
d) Detailed: The specific security attributes used in making an information flow enforcement decision.
Page 58 of 354 Version 2.1
August 1999

Information flow control functions
(FDP_IFF)
6 - Class FDP: User data protection e) Detailed: Some specific subsets of the information that has flowed based upon policy goals (e.g. auditing of downgraded material).
f) Detailed: The use of identified illicit information flow channels with estimated maximum capacity exceeding a specified value.
FDP_IFF.1
Simple security attributes
Hierarchical to: No other components.
FDP_IFF.1.1
The TSF shall enforce the [assignment: information flow control SFP] based on the following types of subject and information security attributes:
FDP_IFF.1.2
FDP_IFF.1.3
FDP_IFF.1.4
FDP_IFF.1.5
FDP_IFF.1.6
The TSF shall permit an information flow between a controlled subject and controlled information via a controlled operation if the following rules hold:
[assignment: for each operation, the security attribute-based relationship that
must hold between subject and information security attributes].
The TSF shall enforce the [assignment: additional information flow control SFP
rules].
The TSF shall provide the following [assignment: list of additional SFP
capabilities].
The TSF shall explicitly authorise an information flow based on the following rules: [assignment: rules, based on security attributes, that explicitly authorise
information flows].
The TSF shall explicitly deny an information flow based on the following rules:
[assignment: rules, based on security attributes, that explicitly deny information
flows].
Dependencies: FDP_IFC.1 Subset information flow control
FMT_MSA.3 Static attribute initialisation
FDP_IFF.2
Hierarchical security attributes
Hierarchical to: FDP_IFF.1
FDP_IFF.2.1
FDP_IFF.2.2
The TSF shall enforce the [assignment: information flow control SFP] based on the following types of subject and information security attributes: [assignment: the
minimum number and type of security attributes].
The TSF shall permit an information flow between a controlled subject and controlled information via a controlled operation if the following rules, based on
the ordering relationships between security attributes hold: [assignment: for each operation, the security attribute-based relationship that must hold between
subject and information security attributes].
August 1999 Version 2.1
Page 59 of 354

6 - Class FDP: User data protection Information flow control functions
(FDP_IFF)
FDP_IFF.2.3
FDP_IFF.2.4
FDP_IFF.2.5
FDP_IFF.2.6
FDP_IFF.2.7
The TSF shall enforce the [assignment: additional information flow control SFP
rules].
The TSF shall provide the following [assignment: list of additional SFP
capabilities]
The TSF shall explicitly authorise an information flow based on the following rules:
[assignment: rules, based on security attributes, that explicitly authorise
information flows].
The TSF shall explicitly deny an information flow based on the following rules:
[assignment: rules, based on security attributes, that explicitly deny information
flows].
The TSF shall enforce the following relationships for any two valid information flow control security attributes: a) There exists an ordering function that, given two valid security attributes, determines if the security attributes are equal, if one security attribute is greater than the other, or if the security attributes are incomparable; and b) There exists a “least upper bound” in the set of security attributes, such that, given any two valid security attributes, there is a valid security attribute that is greater than or equal to the two valid security attributes; and c) There exists a “greatest lower bound” in the set of security attributes, such that, given any two valid security attributes, there is a valid security attribute that is not greater than the two valid security attributes.
Dependencies: FDP_IFC.1 Subset information flow control
FMT_MSA.3 Static attribute initialisation
FDP_IFF.3
Limited illicit information flows
Hierarchical to: No other components.
FDP_IFF.3.1
The TSF shall enforce the [assignment: information flow control SFP] to limit the capacity of [assignment: types of illicit information flows] to a [assignment:
maximum capacity].
Dependencies: AVA_CCA.1 Covert channel analysis
FDP_IFC.1 Subset information flow control
Page 60 of 354 Version 2.1
August 1999

Information flow control functions
(FDP_IFF)
6 - Class FDP: User data protection
FDP_IFF.4
Partial elimination of illicit information flows
Hierarchical to: FDP_IFF.3
FDP_IFF.4.1
FDP_IFF.4.2
The TSF shall enforce the [assignment: information flow control SFP] to limit the capacity of [assignment: types of illicit information flows] to a [assignment:
maximum capacity].
The TSF shall prevent [assignment: types of illicit information flows].
Dependencies: AVA_CCA.1 Covert channel analysis
FDP_IFC.1 Subset information flow control
FDP_IFF.5
No illicit information flows
Hierarchical to: FDP_IFF.4
FDP_IFF.5.1
The TSF shall ensure that no illicit information flows exist to circumvent
[assignment: name of information flow control SFP].
Dependencies: AVA_CCA.3 Exhaustive covert channel analysis
FDP_IFC.1 Subset information flow control
FDP_IFF.6
Illicit information flow monitoring
Hierarchical to: No other components.
FDP_IFF.6.1
The TSF shall enforce the [assignment: information flow control SFP] to monitor [assignment: types of illicit information flows] when it exceeds the
[assignment: maximum capacity].
Dependencies: AVA_CCA.1 Covert channel analysis
FDP_IFC.1 Subset information flow control
August 1999 Version 2.1
Page 61 of 354

FDP_ITC
208
209
210
211
6 - Class FDP: User data protection
212
213
Import from outside TSF control
(FDP_ITC)
Import from outside TSF control
Family behaviour
This family defines the mechanisms for introduction of user data into the TOE such that it has appropriate security attributes and is appropriately protected. It is concerned with limitations on importation, determination of desired security attributes, and interpretation of security attributes associated with the user data.
Component levelling
1
FDP_ITC Import from outside TSF control
2
This family contains two components to address the preservation of security attributes of imported user data for access control and information control policies.
Component FDP_ITC.1 Import of user data without security attributes requires that the security attributes correctly represent the user data and are supplied separately from the object.
Component FDP_ITC.2 Import of user data with security attributes requires that security attributes correctly represent the user data and are accurately and unambiguously associated with the user data imported from outside the TSC.
Management: FDP_ITC.1, FDP_ITC.2
The following actions could be considered for the management functions in FMT
Management: a) The modification of the additional control rules used for import.
Audit: FDP_ITC.1, FDP_ITC.2
The following events should be auditable if FAU_GEN Security audit data generation is included in the PP/ST: a) Minimal: Successful import of user data, including any security attributes.
b) Basic: All attempts to import user data, including any security attributes.
c) Detailed: The specification of security attributes for imported user data supplied by an authorised user.
Page 62 of 354 Version 2.1
August 1999

Import from outside TSF control
(FDP_ITC)
6 - Class FDP: User data protection
FDP_ITC.1
Import of user data without security attributes
Hierarchical to: No other components.
FDP_ITC.1.1
FDP_ITC.1.2
FDP_ITC.1.3
The TSF shall enforce the [assignment: access control SFP and/or information
flow control SFP] when importing user data, controlled under the SFP, from outside of the TSC.
The TSF shall ignore any security attributes associated with the user data when imported from outside the TSC.
The TSF shall enforce the following rules when importing user data controlled under the SFP from outside the TSC: [assignment: additional importation
control rules].
Dependencies: [FDP_ACC.1 Subset access control, or
FDP_IFC.1 Subset information flow control]
FMT_MSA.3 Static attribute initialisation
FDP_ITC.2
Import of user data with security attributes
Hierarchical to: No other components.
FDP_ITC.2.1
FDP_ITC.2.2
FDP_ITC.2.3
FDP_ITC.2.4
FDP_ITC.2.5
The TSF shall enforce the [assignment: access control SFP and/or information
flow control SFP] when importing user data, controlled under the SFP, from outside of the TSC.
The TSF shall use the security attributes associated with the imported user data.
The TSF shall ensure that the protocol used provides for the unambiguous association between the security attributes and the user data received.
The TSF shall ensure that interpretation of the security attributes of the imported user data is as intended by the source of the user data.
The TSF shall enforce the following rules when importing user data controlled under the SFP from outside the TSC: [assignment: additional importation
control rules].
Dependencies: [FDP_ACC.1 Subset access control, or
FDP_IFC.1 Subset information flow control]
[FTP_ITC.1 Inter-TSF trusted channel, or
FTP_TRP.1 Trusted path]
FPT_TDC.1 Inter-TSF basic TSF data consistency
August 1999 Version 2.1
Page 63 of 354

6 - Class FDP: User data protection Internal TOE transfer (FDP_ITT)
215
216
217
218
FDP_ITT
214
219
220
Page 64 of 354
Internal TOE transfer
Family behaviour
This family provides requirements that address protection of user data when it is transferred between parts of a TOE across an internal channel. This may be contrasted with the FDP_UCT and FDP_UIT families, which provide protection for user data when it is transferred between distinct TSFs across an external channel, and FDP_ETC and FDP_ITC, which address transfer of data to or from outside the
TSF’s control.
Component levelling
1 2
FDP_ITT Internal TOE transfer
3 4
FDP_ITT.1 Basic internal transfer protection requires that user data be protected when transmitted between parts of the TOE.
FDP_ITT.2 Transmission separation by attribute requires separation of data based on the value of SFP-relevant attributes in addition to the first component.
FDP_ITT.3 Integrity monitoring requires that the SF monitor user data transmitted between parts of the TOE for identified integrity errors.
FDP_ITT.4 Attribute-based integrity monitoring expands on the third component by allowing the form of integrity monitoring to differ by SFP-relevant attribute.
Management: FDP_ITT.1, FDP_ITT.2
The following actions could be considered for the management functions in FMT
Management: a) If the TSF provides multiple methods to protect user data during transmission between physically separated parts of the TOE, the TSF could provide a pre-defined role with the ability to select the method that will be used.
Management: FDP_ITT.3, FDP_ITT.4
The following actions could be considered for the management functions in FMT
Management: a) The specification of the actions to be taken upon detection of an integrity error could be configurable.
Version 2.1
August 1999

Internal TOE transfer (FDP_ITT) 6 - Class FDP: User data protection
221
Audit: FDP_ITT.1, FDP_ITT.2
The following events should be auditable if FAU_GEN Security audit data generation is included in the PP/ST: a) Minimal: Successful transfers of user data, including identification of the protection method used.
222 b) Basic: All attempts to transfer user data, including the protection method used and any errors that occurred.
Audit: FDP_ITT.3, FDP_ITT.4
The following events should be auditable if FAU_GEN Security audit data generation is included in the PP/ST: a) Minimal: Successful transfers of user data, including identification of the integrity protection method used.
b) Basic: All attempts to transfer user data, including the integrity protection method used and any errors that occurred.
c) Basic: Unauthorised attempts to change the integrity protection method.
d) Detailed: The action taken upon detection of an integrity error.
FDP_ITT.1
Basic internal transfer protection
Hierarchical to: No other components.
FDP_ITT.1.1
The TSF shall enforce the [assignment: access control SFP(s) and/or
information flow control SFP(s)] to prevent the [selection: disclosure,
modification, loss of use] of user data when it is transmitted between physically-separated parts of the TOE.
Dependencies: [FDP_ACC.1 Subset access control, or
FDP_IFC.1 Subset information flow control]
FDP_ITT.2
Transmission separation by attribute
Hierarchical to: FDP_ITT.1
FDP_ITT.2.1
FDP_ITT.2.2
The TSF shall enforce the [assignment: access control SFP(s) and/or information
flow control SFP(s)] to prevent the [selection: disclosure, modification, loss of use] of user data when it is transmitted between physically-separated parts of the TOE.
The TSF shall separate data controlled by the SFP(s) when transmitted between physically-separated parts of the TOE, based on the values of the following: [assignment: security attributes that require separation].
August 1999 Version 2.1
Page 65 of 354

6 - Class FDP: User data protection Internal TOE transfer (FDP_ITT)
Dependencies: [FDP_ACC.1 Subset access control, or
FDP_IFC.1 Subset information flow control]
FDP_ITT.3
Integrity monitoring
Hierarchical to: No other components.
FDP_ITT.3.1
FDP_ITT.3.2
The TSF shall enforce the [assignment: access control SFP(s) and/or
information flow control SFP(s)] to monitor user data transmitted between physically-separated parts of the TOE for the following errors: [assignment:
integrity errors].
Upon detection of a data integrity error, the TSF shall [assignment: specify the
action to be taken upon integrity error].
Dependencies: [FDP_ACC.1 Subset access control, or
FDP_IFC.1 Subset information flow control]
FDP_ITT.1 Basic internal transfer protection
FDP_ITT.4
Attribute-based integrity monitoring
Hierarchical to: FDP_ITT.3
FDP_ITT.4.1
FDP_ITT.4.2
The TSF shall enforce the [assignment: access control SFP(s) and/or information
flow control SFP(s)] to monitor user data transmitted between physically-separated parts of the TOE for the following errors: [assignment: integrity errors], based on the following attributes: [assignment: security attributes that require separate
transmission channels].
Upon detection of a data integrity error, the TSF shall [assignment: specify the
action to be taken upon integrity error].
Dependencies: [FDP_ACC.1 Subset access control, or
FDP_IFC.1 Subset information flow control]
FDP_ITT.2 Transmission separation by attribute
Page 66 of 354 Version 2.1
August 1999

Residual information protection
(FDP_RIP)
6 - Class FDP: User data protection
FDP_RIP
223
Residual information protection
Family behaviour
This family addresses the need to ensure that deleted information is no longer accessible, and that newly created objects do not contain information that should not be accessible. This family requires protection for information that has been logically deleted or released, but may still be present within the TOE.
Component levelling
FDP_RIP Residual information protection 1 2
224
225
226
FDP_RIP.1 Subset residual information protection requires that the TSF ensure that any residual information content of any resources is unavailable to a defined subset of the objects in the TSC upon the resource’s allocation or deallocation.
FDP_RIP.2 Full residual information protection requires that the TSF ensure that any residual information content of any resources is unavailable to all objects upon the resource’s allocation or deallocation.
Management: FDP_RIP.1, FDP_RIP.2
The following actions could be considered for the management functions in FMT
Management:
227 a) The choice of when to perform residual information protection (i.e. upon allocation or deallocation) could be made configurable within the TOE.
Audit: FDP_RIP.1, FDP_RIP.2
There are no events identified that should be auditable if FAU_GEN Security audit data generation is included in the PP/ST.
FDP_RIP.1
Subset residual information protection
Hierarchical to: No other components.
FDP_RIP.1.1
The TSF shall ensure that any previous information content of a resource is made unavailable upon the [selection: allocation of the resource to, deallocation
of the resource from] the following objects: [assignment: list of objects].
Dependencies: No dependencies
August 1999 Version 2.1
Page 67 of 354

6 - Class FDP: User data protection Residual information protection
(FDP_RIP)
FDP_RIP.2
Full residual information protection
Hierarchical to: FDP_RIP.1
FDP_RIP.2.1
The TSF shall ensure that any previous information content of a resource is made unavailable upon the [selection: allocation of the resource to, deallocation of the
resource from] all objects.
Dependencies: No dependencies
Page 68 of 354 Version 2.1
August 1999

Rollback (FDP_ROL) 6 - Class FDP: User data protection
229
230
FDP_ROL
228
231
232
Rollback
Family behaviour
The rollback operation involves undoing the last operation or a series of operations, bounded by some limit, such as a period of time, and return to a previous known state. Rollback provides the ability to undo the effects of an operation or series of operations to preserve the integrity of the user data.
Component levelling
FDP_ROL Rollback 1 2
FDP_ROL.1 Basic rollback addresses a need to roll back or undo a limited number of operations within the defined bounds.
FDP_ROL.2 Advanced rollback addresses the need to roll back or undo all operations within the defined bounds.
Management: FDP_ROL.1, FDP_ROL.2
The following actions could be considered for the management functions in FMT
Management: a) The boundary limit to which rollback may be performed could be a configurable item within the TOE.
b) Permission to perform a rollback operation could be restricted to a well defined role.
Audit: FDP_ROL.1, FDP_ROL.2
The following events should be auditable if FAU_GEN Security audit data generation is specified in the PP/ST: a) Minimal: All successful rollback operations.
b) Basic: All attempts to perform rollback operations.
c) Detailed: All attempts to perform rollback operations, including identification of the types of operations rolled back.
August 1999 Version 2.1
Page 69 of 354

6 - Class FDP: User data protection Rollback (FDP_ROL)
FDP_ROL.1
Basic rollback
Hierarchical to: No other components.
FDP_ROL.1.1
The TSF shall enforce [assignment: access control SFP(s) and/or information
flow control SFP(s)] to permit the rollback of the [assignment: list of
operations] on the [assignment: list of objects].
FDP_ROL.1.2
The TSF shall permit operations to be rolled back within the [assignment:
boundary limit to which rollback may be performed].
Dependencies: [FDP_ACC.1 Subset access control, or
FDP_IFC.1 Subset information flow control]
FDP_ROL.2
Advanced rollback
Hierarchical to: FDP_ROL.1
FDP_ROL.2.1
The TSF shall enforce [assignment: access control SFP(s) and/or information flow
control SFP(s)] to permit the rollback of all the operations on the [assignment: list
of objects].
FDP_ROL.2.2
The TSF shall permit operations to be rolled back within the [assignment: boundary
limit to which rollback may be performed].
Dependencies: [FDP_ACC.1 Subset access control, or
FDP_IFC.1 Subset information flow control]
Page 70 of 354 Version 2.1
August 1999

Stored data integrity (FDP_SDI) 6 - Class FDP: User data protection
234
235
236
237
FDP_SDI
233
238
Stored data integrity
Family behaviour
This family provides requirements that address protection of user data while it is stored within the TSC. Integrity errors may affect user data stored in memory, or in a storage device. This family differs from FDP_ITT Internal TOE transfer which protects the user data from integrity errors while being transferred within the TOE.
Component levelling
FDP_SDI Stored data integrity 1 2
FDP_SDI.1 Stored data integrity monitoring requires that the SF monitor user data stored within the TSC for identified integrity errors.
FDP_SDI.2 Stored data integrity monitoring and action adds the additional capability to the first component by allowing for actions to be taken as a result of an error detection.
Management: FDP_SDI.1
There are no management activities foreseen for this component.
Management: FDP_SDI.2
The following actions could be considered for the management functions in FMT
Management: a) The actions to be taken upon the detection of an integrity error could be configurable.
Audit: FDP_SDI.1
The following events should be auditable if FAU_GEN Security audit data generation is included in the PP/ST: a) Minimal: Successful attempts to check the integrity of user data, including an indication of the results of the check.
b) Basic: All attempts to check the integrity of user data, including an indication of the results of the check, if performed.
c) Detailed: The type of integrity error that occurred.
August 1999 Version 2.1
Page 71 of 354

6 - Class FDP: User data protection Stored data integrity (FDP_SDI)
239
Audit: FDP_SDI.2
The following events should be auditable if FAU_GEN Security audit data generation is included in the PP/ST: a) Minimal: Successful attempts to check the integrity of user data, including an indication of the results of the check.
b) Basic: All attempts to check the integrity of user data, including an indication of the results of the check, if performed.
c) Detailed: The type of integrity error that occurred.
d) Detailed: The action taken upon detection of an integrity error.
FDP_SDI.1
Stored data integrity monitoring
Hierarchical to: No other components.
FDP_SDI.1.1
The TSF shall monitor user data stored within the TSC for [assignment:
integrity errors] on all objects, based on the following attributes: [assignment:
user data attributes].
Dependencies: No dependencies
FDP_SDI.2
Stored data integrity monitoring and action
Hierarchical to: FDP_SDI.1
FDP_SDI.2.1
FDP_SDI.2.2
The TSF shall monitor user data stored within the TSC for [assignment: integrity
errors] on all objects, based on the following attributes: [assignment: user data
attributes].
Upon detection of a data integrity error, the TSF shall [assignment: action to
be taken].
Dependencies: No dependencies
Page 72 of 354 Version 2.1
August 1999

Inter-TSF user data confidentiality transfer protection (FDP_UCT)
6 - Class FDP: User data protection
FDP_UCT
240
Inter-TSF user data confidentiality transfer protection
Family behaviour
This family defines the requirements for ensuring the confidentiality of user data when it is transferred using an external channel between distinct TOEs or users on distinct TOEs.
Component levelling
FDP_UCT Inter-TSF user data confidentiality transfer protection
1
241
242
243
In FDP_UCT.1 Basic data exchange confidentiality, the goal is to provide protection from disclosure of user data while in transit.
Management: FDP_UCT.1
There are no management activities foreseen for this component.
Audit: FDP_UCT.1
The following events should be auditable if FAU_GEN Security audit data generation is included in the PP/ST.
a) Minimal: The identity of any user or subject using the data exchange mechanisms.
b) Basic: The identity of any unauthorised user or subject attempting to use the data exchange mechanisms.
c) Basic: A reference to the names or other indexing information useful in identifying the user data that was transmitted or received. This could include security attributes associated with the information.
FDP_UCT.1
Basic data exchange confidentiality
Hierarchical to: No other components.
FDP_UCT.1.1
The TSF shall enforce the [assignment: access control SFP(s) and/or
information flow control SFP(s)] to be able to [selection: transmit, receive] objects in a manner protected from unauthorised disclosure.
August 1999 Version 2.1
Page 73 of 354

6 - Class FDP: User data protection Inter-TSF user data confidentiality transfer protection (FDP_UCT)
Dependencies: [FTP_ITC.1 Inter-TSF trusted channel, or
FTP_TRP.1 Trusted path]
[FDP_ACC.1 Subset access control, or
FDP_IFC.1 Subset information flow control]
Page 74 of 354 Version 2.1
August 1999

Inter-TSF user data integrity transfer protection (FDP_UIT)
6 - Class FDP: User data protection
248
249
245
246
247
FDP_UIT
244
Inter-TSF user data integrity transfer protection
Family behaviour
This family defines the requirements for providing integrity for user data in transit between the TSF and another trusted IT product and recovering from detectable errors. At a minimum, this family monitors the integrity of user data for modifications. Furthermore, this family supports different ways of correcting detected integrity errors.
Component levelling
1
FDP_UIT Inter-TSF user data integrity transfer protection
2 3
FDP_UIT.1 Data exchange integrity addresses detection of modifications, deletions, insertions, and replay errors of the user data transmitted.
FDP_UIT.2 Source data exchange recovery addresses recovery of the original user data by the receiving TSF with help from the source trusted IT product.
FDP_UIT.3 Destination data exchange recovery addresses recovery of the original user data by the receiving TSF on its own without any help from the source trusted IT product.
Management: FDP_UIT.1, FDP_UIT.2, FDP_UIT.3
There are no management activities foreseen for this component.
Audit: FDP_UIT.1
The following events should be auditable if FAU_GEN Security audit data generation is included in the PP/ST.
a) Minimal: The identity of any user or subject using the data exchange mechanisms.
b) Basic: The identity of any user or subject attempting to use the user data exchange mechanisms, but who is unauthorised to do so.
c) Basic: A reference to the names or other indexing information useful in identifying the user data that was transmitted or received. This could include security attributes associated with the user data.
d) Basic: Any identified attempts to block transmission of user data.
August 1999 Version 2.1
Page 75 of 354

6 - Class FDP: User data protection Inter-TSF user data integrity transfer protection (FDP_UIT)
250 e) Detailed: The types and/or effects of any detected modifications of transmitted user data.
Audit: FDP_UIT.2, FDP_UIT.3
The following events should be auditable if FAU_GEN Security audit data generation is included in the PP/ST.
a) Minimal: The identity of any user or subject using the data exchange mechanisms.
b) Minimal: Successful recovery from errors including they type of error that was detected.
c) Basic: The identity of any user or subject attempting to use the user data exchange mechanisms, but who is unauthorised to do so.
d) Basic: A reference to the names or other indexing information useful in identifying the user data that was transmitted or received. This could include security attributes associated with the user data.
e) Basic: Any identified attempts to block transmission of user data.
f) Detailed: The types and/or effects of any detected modifications of transmitted user data.
FDP_UIT.1
Data exchange integrity
Hierarchical to: No other components.
FDP_UIT.1.1
FDP_UIT.1.2
The TSF shall enforce the [assignment: access control SFP(s) and/or information flow control SFP(s)] to be able to [selection: transmit, receive] user data in a manner protected from [selection: modification, deletion, insertion,
replay] errors.
The TSF shall be able to determine on receipt of user data, whether [selection:
modification, deletion, insertion, replay] has occurred.
Dependencies: [FDP_ACC.1 Subset access control, or
FDP_IFC.1 Subset information flow control]
[FTP_ITC.1 Inter-TSF trusted channel, or
FTP_TRP.1 Trusted path]
Page 76 of 354 Version 2.1
August 1999

Inter-TSF user data integrity transfer protection (FDP_UIT)
6 - Class FDP: User data protection
FDP_UIT.2
Source data exchange recovery
Hierarchical to: No other components.
FDP_UIT.2.1
The TSF shall enforce the [assignment: access control SFP(s) and/or
information flow control SFP(s)] to be able to recover from [assignment: list of
recoverable errors] with the help of the source trusted IT product.
Dependencies: [FDP_ACC.1 Subset access control, or
FDP_IFC.1 Subset information flow control]
FDP_UIT.1 Data exchange integrity
FTP_ITC.1 Inter-TSF trusted channel
FDP_UIT.3
Destination data exchange recovery
Hierarchical to: FDP_UIT.2
FDP_UIT.3.1
The TSF shall enforce the [assignment: access control SFP(s) and/or information
flow control SFP(s)] to be able to recover from [assignment: list of recoverable
errors] without any help from the source trusted IT product.
Dependencies: [FDP_ACC.1 Subset access control, or
FDP_IFC.1 Subset information flow control]
FDP_UIT.1 Data exchange integrity
FTP_ITC.1 Inter-TSF trusted channel
August 1999 Version 2.1
Page 77 of 354

6 - Class FDP: User data protection Inter-TSF user data integrity transfer protection (FDP_UIT)
Page 78 of 354 Version 2.1
August 1999

Part 2: Security functional requirements 94
251
252
253
Class FIAIdentification and authentication
Families in this class address the requirements for functions to establish and verify a claimed user identity.
Identification and Authentication is required to ensure that users are associated with the proper security attributes (e.g. identity, groups, roles, security or integrity levels).
The unambiguous identification of authorised users and the correct association of security attributes with users and subjects is critical to the enforcement of the intended security policies. The families in this class deal with determining and verifying the identity of users, determining their authority to interact with the TOE, and with the correct association of security attributes for each authorised user. Other classes of requirements (e.g. User Data Protection, Security Audit) are dependent upon correct identification and authentication of users in order to be effective.
August 1999 Version 2.1
Page 79 of 354

7 - Class FIA: Identification and authentication
Identification and authentication
FIA_AFL Authentication failures
FIA_ATD User attribute definition
FIA_SOS Specification of secrets
FIA_UAU User authentication
FIA_UID User identification
FIA_USB User-subject binding
1
2
5
6
7
1
3
4
1
1
1
1
2
2
Figure 7.1 - Identification and authentication class decomposition
Page 80 of 354 Version 2.1
August 1999

Authentication failures (FIA_AFL) 7 - Class FIA: Identification and authentication
FIA_AFL
254
Authentication failures
Family behaviour
This family contains requirements for defining values for some number of unsuccessful authentication attempts and TSF actions in cases of authentication attempt failures. Parameters include, but are not limited to, the number of failed authentication attempts and time thresholds.
Component levelling
FIA_AFL Authentication failures 1
255
FIA_AFL.1 requires that the TSF be able to terminate the session establishment process after a specified number of unsuccessful user authentication attempts. It also requires that, after termination of the session establishment process, the TSF be able to disable the user account or the point of entry (e.g. workstation) from which the attempts were made until an administrator-defined condition occurs.
256
Management: FIA_AFL.1
The following actions could be considered for the management functions in FMT: a) management of the threshold for unsuccessful authentication attempts; b) management of actions to be taken in the event of an authentication failure.
257
Audit: FIA_AFL.1
The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST: a) Minimal: the reaching of the threshold for the unsuccesful authentication attempts and the actions (e.g. disabling of a terminal) taken and the subsequent, if appropriate, restoration to the normal state (e.g. re-enabling of a terminal).
FIA_AFL.1
Authentication failure handling
FIA_AFL.1.1
FIA_AFL.1.2
Hierarchical to: No other components.
The TSF shall detect when [assignment: number] unsuccessful authentication attempts occur related to [assignment: list of authentication events].
When the defined number of unsuccessful authentication attempts has been met or surpassed, the TSF shall [assignment: list of actions].
August 1999 Version 2.1
Page 81 of 354

7 - Class FIA: Identification and authentication Authentication failures (FIA_AFL)
Dependencies: FIA_UAU.1 Timing of authentication
Page 82 of 354 Version 2.1
August 1999

User attribute definition (FIA_ATD) 7 - Class FIA: Identification and authentication
FIA_ATD
258
User attribute definition
Family behaviour
All authorised users may have a set of security attributes, other than the user’s identity, that is used to enforce the TSP. This family defines the requirements for associating user security attributes with users as needed to support the TSP.
Component levelling
FIA_ATD User attribute definition 1
259
260
FIA_ATD.1 User attribute definition, allows user security attributes for each user to be maintained individually.
Management: FIA_ATD.1
The following actions could be considered for the management functions in FMT: a) if so indicated in the assignment, the authorised administrator might be able to define additional security attributes for users.
261
Audit: FIA_ATD.1
There are no actions identified that should be auditable if FAU_GEN Security audit data generation is included in the PP/ST.
FIA_ATD.1
User attribute definition
Hierarchical to: No other components.
FIA_ATD.1.1
The TSF shall maintain the following list of security attributes belonging to individual users: [assignment: list of security attributes].
Dependencies: No dependencies
August 1999 Version 2.1
Page 83 of 354

7 - Class FIA: Identification and authentication Specification of secrets (FIA_SOS)
263
264
FIA_SOS
262
265
266
267
Specification of secrets
Family behaviour
This family defines requirements for mechanisms that enforce defined quality metrics on provided secrets and generate secrets to satisfy the defined metric.
Component levelling
1
FIA_SOS Specification of secrets
2
FIA_SOS.1 Verification of secrets requires the TSF to verify that secrets meet defined quality metrics.
FIA_SOS.2 TSF Generation of secrets requires the TSF to be able to generate secrets that meet defined quality metrics.
Management: FIA_SOS.1
The following actions could be considered for the management functions in FMT: a) the management of the metric used to verify the secrets.
Management: FIA_SOS.2
The following actions could be considered for the management functions in FMT: a) the management of the metric used to generate the secrets.
Audit: FIA_SOS.1, FIA_SOS.2
The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST: a) Minimal: Rejection by the TSF of any tested secret; b) Basic: Rejection or acceptance by the TSF of any tested secret; c) Detailed: Identification of any changes to the defined quality metrics.
Page 84 of 354 Version 2.1
August 1999

Specification of secrets (FIA_SOS) 7 - Class FIA: Identification and authentication
FIA_SOS.1
Verification of secrets
Hierarchical to: No other components.
FIA_SOS.1.1
The TSF shall provide a mechanism to verify that secrets meet [assignment: a
defined quality metric].
Dependencies: No dependencies
FIA_SOS.2
TSF Generation of secrets
Hierarchical to: No other components.
FIA_SOS.2.1
FIA_SOS.2.2
The TSF shall provide a mechanism to generate secrets that meet [assignment:
a defined quality metric].
The TSF shall be able to enforce the use of TSF generated secrets for
[assignment: list of TSF functions].
Dependencies: No dependencies
August 1999 Version 2.1
Page 85 of 354

7 - Class FIA: Identification and authentication User authentication (FIA_UAU)
FIA_UAU
268
272
273
274
275
269
270
271
Page 86 of 354
User authentication
Family behaviour
This family defines the types of user authentication mechanisms supported by the
TSF. This family also defines the required attributes on which the user authentication mechanisms must be based.
Component levelling
2
FIA_UAU User authentication
5
6
7
1
3
4
FIA_UAU.1 Timing of authentication, allows a user to perform certain actions prior to the authentication of the user’s identity.
FIA_UAU.2 User authentication before any action, requires that users authenticate themselves before any action will be allowed by the TSF.
FIA_UAU.3 Unforgeable authentication, requires the authentication mechanism to be able to detect and prevent the use of authentication data that has been forged or copied.
FIA_UAU.4 Single-use authentication mechanisms, requires an authentication mechanism that operates with single-use authentication data.
FIA_UAU.5 Multiple authentication mechanisms, requires that different authentication mechanisms be provided and used to authenticate user identities for specific events.
FIA_UAU.6 Re-authenticating, requires the ability to specify events for which the user needs to be re-authenticated.
FIA_UAU.7 Protected authentication feedback, require that only limited feedback information is provided to the user during the authentication.
Version 2.1
August 1999

User authentication (FIA_UAU) 7 - Class FIA: Identification and authentication
278
279
276
277
280
281
August 1999
Management: FIA_UAU.1
The following actions could be considered for the management functions in FMT: a) management of the authentication data by an administrator; b) management of the authentication data by the associated user; c) managing the list of actions that can be taken before the user is authenticated.
Management: FIA_UAU.2
The following actions could be considered for the management functions in FMT: a) management of the authentication data by an administrator; b) management of the authentication data by the user associated with this data.
Management: FIA_UAU.3, FIA_UAU.4, FIA_UAU.7
There are no management activities foreseen.
Management: FIA_UAU.5
The following actions could be considered for the management functions in FMT: a) the management of authentication mechanisms; b) the management of the rules for authentication.
Management: FIA_UAU.6
The following actions could be considered for the management functions in FMT: a) if an authorised administrator could request re-authentication, the management includes a re-authentication request.
Audit: FIA_UAU.1
The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST: a) Minimal: Unsuccessful use of the authentication mechanism; b) Basic: All use of the authentication mechanism; c) Detailed: All TSF mediated actions performed before authentication of the user.
Version 2.1
Page 87 of 354

7 - Class FIA: Identification and authentication User authentication (FIA_UAU)
282
283
284
285
286
287
Audit: FIA_UAU.2
The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST: a) Minimal: Unsuccessful use of the authentication mechanism; b) Basic: All use of the authentication mechanism.
Audit: FIA_UAU.3
The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST: a) Minimal: Detection of fraudulent authentication data; b) Basic: All immediate measures taken and results of checks on the fraudulent data.
Audit: FIA_UAU.4
The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST: a) Minimal: Attempts to reuse authentication data.
Audit: FIA_UAU.5
The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST: a) Minimal: The final decision on authentication; b) Basic: The result of each activated mechanism together with the final decision.
Audit: FIA_UAU.6
The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST: a) Minimal: Failure of reauthentication; b) Basic: All reauthentication attempts.
Audit: FIA_UAU.7
There are no auditable events foreseen.
Page 88 of 354 Version 2.1
August 1999

User authentication (FIA_UAU) 7 - Class FIA: Identification and authentication
FIA_UAU.1
Timing of authentication
Hierarchical to: No other components.
FIA_UAU.1.1
The TSF shall allow [assignment: list of TSF mediated actions] on behalf of the user to be performed before the user is authenticated.
FIA_UAU.1.2
The TSF shall require each user to be successfully authenticated before allowing any other TSF-mediated actions on behalf of that user.
Dependencies: FIA_UID.1 Timing of identification
FIA_UAU.2
User authentication before any action
Hierarchical to: FIA_UAU.1
FIA_UAU.2.1
The TSF shall require each user to be successfully authenticated before allowing
any other TSF-mediated actions on behalf of that user.
Dependencies: FIA_UID.1 Timing of identification
FIA_UAU.3
Unforgeable authentication
Hierarchical to: No other components.
FIA_UAU.3.1
The TSF shall [selection: detect, prevent] use of authentication data that has been forged by any user of the TSF.
FIA_UAU.3.2
The TSF shall [selection: detect, prevent] use of authentication data that has been copied from any other user of the TSF.
Dependencies: No dependencies
FIA_UAU.4
Single-use authentication mechanisms
Hierarchical to: No other components.
FIA_UAU.4.1
The TSF shall prevent reuse of authentication data related to [assignment:
identified authentication mechanism(s)].
Dependencies: No dependencies
FIA_UAU.5
Multiple authentication mechanisms
Hierarchical to: No other components.
FIA_UAU.5.1
The TSF shall provide [assignment: list of multiple authentication mechanisms] to support user authentication.
August 1999 Version 2.1
Page 89 of 354

7 - Class FIA: Identification and authentication User authentication (FIA_UAU)
FIA_UAU.5.2
The TSF shall authenticate any user’s claimed identity according to the
[assignment: rules describing how the multiple authentication mechanisms
provide authentication].
Dependencies: No dependencies
FIA_UAU.6
Re-authenticating
Hierarchical to: No other components.
FIA_UAU.6.1
The TSF shall re-authenticate the user under the conditions [assignment: list
of conditions under which re-authentication is required].
Dependencies: No dependencies
FIA_UAU.7
Protected authentication feedback
Hierarchical to: No other components.
FIA_UAU.7.1
The TSF shall provide only [assignment: list of feedback] to the user while the authentication is in progress.
Dependencies: FIA_UAU.1 Timing of authentication
Page 90 of 354 Version 2.1
August 1999

User identification (FIA_UID) 7 - Class FIA: Identification and authentication
289
290
FIA_UID
288
291
292
293
User identification
Family behaviour
This family defines the conditions under which users shall be required to identify themselves before performing any other actions that are to be mediated by the TSF and which require user identification.
Component levelling
FIA_UID User identification 1 2
FIA_UID.1 Timing of identification, allows users to perform certain actions before being identified by the TSF.
FIA_UID.2 User identification before any action, require that users identify themselves before any action will be allowed by the TSF.
Management: FIA_UID.1
The following actions could be considered for the management functions in FMT: a) the management of the user identities; b) if an authorised administrator can change the actions allowed before identification, the managing of the action lists.
Management: FIA_UID.2
The following actions could be considered for the management functions in FMT: a) the management of the user identities.
Audit: FIA_UID.1, FIA_UID.2
The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST: a) Minimal: Unsuccessful use of the user identification mechanism, including the user identity provided; b) Basic: All use of the user identification mechanism, including the user identity provided.
August 1999 Version 2.1
Page 91 of 354

7 - Class FIA: Identification and authentication User identification (FIA_UID)
FIA_UID.1
Timing of identification
Hierarchical to: No other components.
FIA_UID.1.1
FIA_UID.1.2
The TSF shall allow [assignment: list of TSF-mediated actions] on behalf of the user to be performed before the user is identified.
The TSF shall require each user to be succesfully identified before allowing any other TSF-mediated actions on behalf of that user.
Dependencies: No dependencies
FIA_UID.2
User identification before any action
Hierarchical to: FIA_UID.1
FIA_UID.2.1
The TSF shall require each user to identify itself before allowing any other TSF-
mediated actions on behalf of that user.
Dependencies: No dependencies
Page 92 of 354 Version 2.1
August 1999

User-subject binding (FIA_USB) 7 - Class FIA: Identification and authentication
FIA_USB
294
User-subject binding
Family behaviour
An authenticated user, in order to use the TOE, typically activates a subject. The user’s security attributes are associated (totally or partially) with this subject. This family defines requirements to create and maintain the association of the user’s security attributes to a subject acting on the user’s behalf.
Component levelling
FIA_USB User-subject binding 1
295
296
297
FIA_USB.1 User-subject binding requires the maintenance of an association between the user’s security attributes and a subject acting on the user’s behalf.
Management: FIA_USB.1
The following actions could be considered for the management functions in FMT: a) an authorised administrator can define default subject security attributes.
Audit: FIA_USB.1
The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST: a) Minimal: Unsuccessful binding of user security attributes to a subject
(e.g. creation of a subject). b) Basic: Success and failure of binding of user security attributes to a subject (e.g. success and failure to create a subject).
FIA_USB.1
User-subject binding
FIA_USB.1.1
Hierarchical to: No other components.
The TSF shall associate the appropriate user security attributes with subjects acting on behalf of that user.
Dependencies: FIA_ATD.1 User attribute definition
August 1999 Version 2.1
Page 93 of 354

7 - Class FIA: Identification and authentication User-subject binding (FIA_USB)
Page 94 of 354 Version 2.1
August 1999

298
299
Class FM TSecurity management
This class is intended to specify the management of several aspects of the TSF: security attributes, TSF data and functions. The different management roles and their interaction, such as separation of capability, can be specified.
This class has several objectives: a) management of TSF data, which include, for example, banners; b) management of security attributes, which include, for example, the
Access Control Lists, and Capability Lists; c) management of functions of the TSF, which includes, for example, the selection of functions, and rules or conditions influencing the behaviour of the TSF; d) definition of security roles.
August 1999 Version 2.1
Page 95 of 354

8 - Class FMT: Security management
Security management
FMT_MOF Management of functions in TSF
FMT_MSA Management of security attributes
FMT_MTD Management of TSF data
FMT_REV Revocation
FMT_SAE Security attribute expiration
FMT_SMR Security management roles
1
1
2
3
1
2
3
1
1
1
3
2
Figure 8.1 - Security management class decomposition
August 1999 Version 2.1
Page 96 of 354

Management of functions in TSF
(FMT_MOF)
8 - Class FMT: Security management
FMT_MOF
300
Management of functions in TSF
Family behaviour
This family allows authorised users control over the management of functions in the
TSF. Examples of functions in the TSF include the audit functions and the multiple authentication functions.
Component levelling
FMT_MOF Management of functions in TSF 1
301
FMT_MOF.1 Management of security functions behaviour allows the authorised users (roles) to manage the behaviour of functions in the TSF that use rules or have specified conditions that may be manageable.
302
Management: FMT_MOF.1
The following actions could be considered for the management functions in FMT
Management: a) managing the group of roles that can interact with the functions in the
TSF;
303
Audit: FMT_MOF.1
The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP / ST: a) Basic: All modifications in the behaviour of the functions in the TSF.
FMT_MOF.1
Management of security functions behaviour
Hierarchical to: No other components.
FMT_MOF.1.1
The TSF shall restrict the ability to [selection: determine the behaviour of,
disable, enable, modify the behaviour of] the functions [assignment: list of
functions] to [assignment: the authorised identified roles].
Dependencies: FMT_SMR.1 Security roles
August 1999 Version 2.1
Page 97 of 354

8 - Class FMT: Security management Management of security attributes
(FMT_MSA)
305
306
307
FMT_MSA
304
308
309
310
Page 98 of 354
Management of security attributes
Family behaviour
This family allows authorised users control over the management of security attributes. This management might include capabilities for viewing and modifying of security attributes.
Component levelling
1
FMT_MSA Management of security attributes 2
3
FMT_MSA.1 Management of security attributes allows authorised users (roles) to manage the specified security attributes.
FMT_MSA.2 Secure security attributes ensures that values assigned to security attributes are valid with respect to the secure state.
FMT_MSA.3 Static attribute initialisation ensures that the default values of security attributes are appropriately either permissive or restrictive in nature.
Management: FMT_MSA.1
The following actions could be considered for the management functions in FMT
Management: a) managing the group of roles that can interact with the security attributes.
Management: FMT_MSA.2
There are no additional management activities foreseen for this component.
Management: FMT_MSA.3
The following actions could be considered for the management functions in FMT
Management: a) managing the group of roles that can specify initial values; b) managing the permissive or restrictive setting of default values for a given access control SFP.
Version 2.1
August 1999

Management of security attributes
(FMT_MSA)
8 - Class FMT: Security management
311
312
Audit: FMT_MSA.1
The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP / ST: a) Basic: All modifications of the values of security attributes.
Audit: FMT_MSA.2
The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP / ST: a) Minimal: All offered and rejected values for a security attribute; b) Detailed: All offered and accepted secure values for a security attribute.
Audit: FMT_MSA.3
313
The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP / ST: a) Basic: Modifications of the default setting of permissive or restrictive rules. b) Basic: All modifications of the initial values of security attributes.
FMT_MSA.1
Management of security attributes
Hierarchical to: No other components.
FMT_MSA.1.1
The TSF shall enforce the [assignment: access control SFP, information flow
control SFP] to restrict the ability to [selection: change_default, query, modify,
delete, [assignment: other operations]] the security attributes [assignment: list
of security attributes] to [assignment: the authorised identified roles].
Dependencies: [FDP_ACC.1 Subset access control or
FDP_IFC.1 Subset information flow control]
FMT_SMR.1 Security roles
FMT_MSA.2
Secure security attributes
Hierarchical to: No other components.
FMT_MSA.2.1
The TSF shall ensure that only secure values are accepted for security attributes.
August 1999 Version 2.1
Page 99 of 354

8 - Class FMT: Security management Management of security attributes
(FMT_MSA)
Dependencies: ADV_SPM.1 Informal TOE security policy model
[FDP_ACC.1 Subset access control or
FDP_IFC.1 Subset information flow control]
FMT_MSA.1 Management of security attributes
FMT_SMR.1 Security roles
FMT_MSA.3
Static attribute initialisation
Hierarchical to: No other components.
FMT_MSA.3.1
The TSF shall enforce the [assignment: access control SFP, information flow
control SFP] to provide [selection: restrictive, permissive, other property] default values for security attributes that are used to enforce the SFP.
FMT_MSA.3.2
The TSF shall allow the [assignment: the authorised identified roles] to specify alternative initial values to override the default values when an object or information is created.
Dependencies: FMT_MSA.1 Management of security attributes
FMT_SMR.1 Security roles
Page 100 of 354 Version 2.1
August 1999

Management of TSF data (FMT_MTD) 8 - Class FMT: Security management
315
316
317
FMT_MTD
314
318
319
320
Management of TSF data
Family behaviour
This family allows authorised users (roles) control over the management of TSF data. Examples of TSF data include audit information, clock, system configuration and other TSF configuration parameters.
Component levelling
1
FMT_MTD Management of TSF data 2
3
FMT_MTD.1 Management of TSF data allows authorised users to manage TSF data.
FMT_MTD.2 Management of limits on TSF data specifies the action to be taken if limits on TSF data are reached or exceeded.
FMT_MTD.3 Secure TSF data ensures that values assigned to TSF data are valid with respect to the secure state.
Management: FMT_MTD.1
The following actions could be considered for the management functions in FMT
Management: a) managing the group of roles that can interact with the TSF data.
Management: FMT_MTD.2
The following actions could be considered for the management functions in FMT
Management: a) managing the group of roles that can interact with the limits on the TSF data.
Management: FMT_MTD.3
There are no additional management activities foreseen for this component.
August 1999 Version 2.1
Page 101 of 354

8 - Class FMT: Security management Management of TSF data (FMT_MTD)
321
322
Audit: FMT_MTD.1
The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP / ST: a) Basic: All modifications to the values of TSF data.
Audit: FMT_MTD.2
The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP / ST: a) Basic: All modifications to the limits on TSF data; b) Basic: All modifications in the actions to be taken in case of violation of the limits.
323
Audit: FMT_MTD.3
The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP / ST: a) Minimal: All rejected values of TSF data.
FMT_MTD.1
Management of TSF data
Hierarchical to: No other components.
FMT_MTD.1.1
The TSF shall restrict the ability to [selection: change_default, query, modify,
delete, clear, [assignment: other operations]] the [assignment: list of TSF data] to [assignment: the authorised identified roles].
Dependencies: FMT_SMR.1 Security roles
FMT_MTD.2
Management of limits on TSF data
Hierarchical to: No other components.
FMT_MTD.2.1
The TSF shall restrict the specification of the limits for [assignment: list of TSF
data] to [assignment: the authorised identified roles].
FMT_MTD.2.2
The TSF shall take the following actions, if the TSF data are at, or exceed, the indicated limits: [assignment: actions to be taken].
Dependencies: FMT_MTD.1 Management of TSF data
FMT_SMR.1 Security roles
Page 102 of 354 Version 2.1
August 1999

Management of TSF data (FMT_MTD) 8 - Class FMT: Security management
FMT_MTD.3
Secure TSF data
Hierarchical to: No other components.
FMT_MTD.3.1
The TSF shall ensure that only secure values are accepted for TSF data.
Dependencies: ADV_SPM.1 Informal TOE security policy model
FMT_MTD.1 Management of TSF data
August 1999 Version 2.1
Page 103 of 354

8 - Class FMT: Security management Revocation (FMT_REV)
FMT_REV
324
Revocation
Family behaviour
This family addresses revocation of security attributes for a variety of entities within a TOE.
Component levelling
FMT_REV Revocation 1
325
326
FMT_REV.1 Revocation provides for revocation of security attributes to be enforced at some point in time.
Management: FMT_REV.1
The following actions could be considered for the management functions in FMT
Management: a) managing the group of roles that can invoke revocation of security attributes;
327 b) managing the lists of users, subjects, objects and other resources for which revocation is possible; c) managing the revocation rules.
Audit: FMT_REV.1
The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP / ST: a) Minimal: Unsuccessful revocation of security attributes; b) Basic: All attempts to revoke security attributes.
FMT_REV.1
Revocation
Hierarchical to: No other components.
FMT_REV.1.1
The TSF shall restrict the ability to revoke security attributes associated with the [selection: users, subjects, objects, other additional resources] within the
TSC to [assignment: the authorised identified roles].
FMT_REV.1.2
The TSF shall enforce the rules [assignment: specification of revocation rules].
Dependencies: FMT_SMR.1 Security roles
Page 104 of 354 Version 2.1
August 1999

Security attribute expiration
(FMT_SAE)
8 - Class FMT: Security management
FMT_SAE
328
Security attribute expiration
Family behaviour
This family addresses the capability to enforce time limits for the validity of security attributes.
Component levelling
FMT_SAE Security attribute expiration 1
329
330
FMT_SAE.1 Time-limited authorisation provides the capability for an authorised user to specify an expiration time on specified security attributes.
Management: FMT_SAE.1
The following actions could be considered for the management functions in FMT
Management: a) managing the list of security attributes for which expiration is to be supported;
331 b) the actions to be taken if the expiration time has passed.
Audit: FMT_SAE.1
The following actions should be audited if FAU Security Audit is included in the
PP/ST: a) Basic: Specification of the expiration time for an attribute; b) Basic: Action taken due to attribute expiration.
FMT_SAE.1
Time-limited authorisation
Hierarchical to: No other components.
FMT_SAE.1.1
The TSF shall restrict the capability to specify an expiration time for
[assignment: list of security attributes for which expiration is to be supported] to
[assignment: the authorised identified roles].
FMT_SAE.1.2
For each of these security attributes, the TSF shall be able to [assignment: list
of actions to be taken for each security attribute] after the expiration time for the indicated security attribute has passed.
Dependencies: FMT_SMR.1 Security roles
FPT_STM.1 Reliable time stamps
August 1999 Version 2.1
Page 105 of 354

8 - Class FMT: Security management Security management roles (FMT_SMR)
333
334
335
FMT_SMR
332
336
337
338
Security management roles
Family behaviour
This family is intended to control the assignment of different roles to users. The capabilities of these roles with respect to security management are described in the other families in this class.
Component levelling
2
FMT_SMR Security management roles
1
3
FMT_SMR.1 Security roles specifies the roles with respect to security that the TSF recognises.
FMT_SMR.2 Restrictions on security roles specifies that in addition to the specification of the roles, there are rules that control the relationship between the roles.
FMT_SMR.3 Assuming roles requires that an explicit request is given to the TSF to assume a role.
Management: FMT_SMR.1
The following actions could be considered for the management functions in FMT
Management: a) managing the group of users that are part of a role.
Management: FMT_SMR.2
The following actions could be considered for the management functions in FMT
Management: a) managing the group of users that are part of a role; b) managing the conditions that the roles must satisfy.
Management: FMT_SMR.3
There are no additional management activities foreseen for this component.
Page 106 of 354 Version 2.1
August 1999

Security management roles
(FMT_SMR)
8 - Class FMT: Security management
339
340
Audit: FMT_SMR.1
The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP / ST: a) Minimal: modifications to the group of users that are part of a role; b) Detailed: every use of the rights of a role.
Audit: FMT_SMR.2
The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP / ST: a) Minimal: modifications to the group of users that are part of a role; b) Minimal: unsuccessful attempts to use a role due to the given conditions on the roles; c) Detailed: every use of the rights of a role.
341
Audit: FMT_SMR.3
The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP / ST: a) Minimal: explicit request to assume a role.
FMT_SMR.1
Security roles
Hierarchical to: No other components.
FMT_SMR.1.1
The TSF shall maintain the roles [assignment: the authorised identified roles].
FMT_SMR.1.2
The TSF shall be able to associate users with roles.
Dependencies: FIA_UID.1 Timing of identification
FMT_SMR.2
Restrictions on security roles
Hierarchical to: FMT_SMR.1
FMT_SMR.2.1
The TSF shall maintain the roles: [assignment: the authorised identified roles].
FMT_SMR.2.2
The TSF shall be able to associate users with roles.
FMT_SMR.2.3
The TSF shall ensure that the conditions [assignment: conditions for the
different roles] are satisfied.
Dependencies: FIA_UID.1 Timing of identification
August 1999 Version 2.1
Page 107 of 354

8 - Class FMT: Security management Security management roles (FMT_SMR)
FMT_SMR.3
Assuming roles
Hierarchical to: No other components.
FMT_SMR.3.1
The TSF shall require an explicit request to assume the following roles:
[assignment: the roles].
Dependencies: FMT_SMR.1 Security roles
Page 108 of 354 Version 2.1
August 1999

342
Class FPRPrivacy
This class contains privacy requirements. These requirements provide a user protection against discovery and misuse of identity by other users.
Privacy
FPR_ANO Anonymity 1 2
2
FPR_PSE Pseudonymity 1
3
FPR_UNL Unlinkability 1
FPR_UNO Unobservability
1
3
4
2
Figure 9.1 - Privacy class decomposition
August 1999 Version 2.1
Page 109 of 354

9 - Class FPR: Privacy Anonymity (FPR_ANO)
FPR_ANO
343
Anonym ity
Family behaviour
This family ensures that a user may use a resource or service without disclosing the user’s identity. The requirements for Anonymity provide protection of the user identity. Anonymity is not intended to protect the subject identity.
Component levelling
FPR_ANO Anonymity 1 2
344
345
346
347
FPR_ANO.1 Anonymity requires that other users or subjects are unable to determine the identity of a user bound to a subject or operation.
FPR_ANO.2 Anonymity without soliciting information enhances the requirements of FPR_ANO.1 by ensuring that the TSF does not ask for the user identity.
Management: FPR_ANO.1, FPR_ANO.2
There are no management activities foreseen for these components.
Audit: FPR_ANO.1, FPR_ANO.2
The following actions shall be auditable if FAU_GEN Security audit data generation is included in the PP / ST: a) Minimal: The invocation of the anonymity mechanism.
FPR_ANO.1
Anonymity
Hierarchical to: No other components.
FPR_ANO.1.1
The TSF shall ensure that [assignment: set of users and/or subjects] are unable to determine the real user name bound to [assignment: list of subjects and/or
operations and/or objects].
Dependencies: No dependencies
FPR_ANO.2
Anonymity without soliciting information
Hierarchical to: FPR_ANO.1
FPR_ANO.2.1
The TSF shall ensure that [assignment: set of users and/or subjects are unable to determine the real user name bound to [assignment: list of subjects and/or
operations and/or objects].
Page 110 of 354 Version 2.1
August 1999

Anonymity (FPR_ANO) 9 - Class FPR: Privacy
FPR_ANO.2.2
The TSF shall provide [assignment: list of services] to [assignment: list of
subjects] without soliciting any reference to the real user name.
Dependencies: No dependencies
August 1999 Version 2.1
Page 111 of 354

9 - Class FPR: Privacy Pseudonymity (FPR_PSE)
FPR_PSE
348
Pseudonymity
Family behaviour
This family ensures that a user may use a resource or service without disclosing its user identity, but can still be accountable for that use.
Component levelling
2
FPR_PSE Pseudonymity 1
3
349
350
351
352
FPR_PSE.1 Pseudonymity requires that a set of users and/or subjects are unable to determine the identity of a user bound to a subject or operation, but that this user is still accountable for its actions.
FPR_PSE.2 Reversible pseudonymity requires the TSF to provide a capability to determine the original user identity based on a provided alias.
FPR_PSE.3 Alias pseudonymity requires the TSF to follow certain construction rules for the alias to the user identity.
Management: FPR_PSE.1, FPR_PSE.2, FPR_PSE.3
There are no management activities foreseen for these components.
353
Audit: FPR_PSE.1, FPR_PSE.2, FPR_PSE.3
The following actions shall be auditable if FAU_GEN Security audit data generation is included in the PP / ST: a) Minimal: The subject/user that requested resolution of the user identity should be audited.
FPR_PSE.1
Pseudonymity
FPR_PSE.1.1
FPR_PSE.1.2
Hierarchical to: No other components.
The TSF shall ensure that [assignment: set of users and/or subjects] are unable to determine the real user name bound to [assignment: list of subjects and/or
operations and/or objects].
The TSF shall be able to provide [assignment: number of aliases] aliases of the real user name to [assignment: list of subjects].
Page 112 of 354 Version 2.1
August 1999

Pseudonymity (FPR_PSE) 9 - Class FPR: Privacy
FPR_PSE.1.3
The TSF shall [selection: determine an alias for a user, accept the alias from the
user] and verify that it conforms to the [assignment: alias metric].
Dependencies: No dependencies
FPR_PSE.2
Reversible pseudonymity
Hierarchical to: FPR_PSE.1
FPR_PSE.2.1
FPR_PSE.2.2
FPR_PSE.2.3
FPR_PSE.2.4
The TSF shall ensure that [assignment: set of users and/or subjects] are unable to determine the real user name bound to [assignment: list of subjects and/or
operations and/or objects].
The TSF shall be able to provide [assignment: number of aliases] aliases of the real user name to [assignment: list of subjects].
The TSF shall [selection: determine an alias for a user, accept the alias from the
user] and verify that it conforms to the [assignment: alias metric].
The TSF shall provide [selection: an authorised user, [assignment: list of trusted
subjects]] a capability to determine the user identity based on the provided alias only under the following [assignment: list of conditions].
Dependencies: FIA_UID.1 Timing of identification
FPR_PSE.3
Alias pseudonymity
Hierarchical to: FPR_PSE.1
FPR_PSE.3.1
FPR_PSE.3.2
FPR_PSE.3.3
FPR_PSE.3.4
The TSF shall ensure that [assignment: set of users and/or subjects] are unable to determine the real user name bound to [assignment: list of subjects and/or
operations and/or objects].
The TSF shall be able to provide [assignment: number of aliases] aliases of the real user name to [assignment: list of subjects].
The TSF shall [selection: determine an alias for a user, accept the alias from the
user] and verify that it conforms to the [assignment: alias metric].
The TSF shall provide an alias to the real user name which shall be identical to an alias provided previously under the following [assignment: list of
conditions] otherwise the alias provided shall be unrelated to previously provided aliases.
Dependencies: No dependencies
August 1999 Version 2.1
Page 113 of 354

9 - Class FPR: Privacy Unlinkability (FPR_UNL)
FPR_UNL
354
Unlinkability
Family behaviour
This family ensures that a user may make multiple uses of resources or services without others being able to link these uses together.
Component levelling
FPR_UNL Unlinkability 1
355
356
FPR_UNL.1 Unlinkability requires that users and/or subjects are unable to determine whether the same user caused certain specific operations in the system.
Management: FPR_UNL.1
The following actions could be considered for the management functions in FMT: a) the management of the unlinkability function.
357
Audit: FPR_UNL.1
The following actions shall be auditable if FAU_GEN Security audit data generation is included in the PP / ST: a) Minimal: The invocation of the unlinkability mechanism.
FPR_UNL.1
Unlinkability
Hierarchical to: No other components.
FPR_UNL.1.1
The TSF shall ensure that [assignment: set of users and/or subjects] are unable to determine whether [assignment: list of operations] [selection: were caused by
the same user, are related as follows [assignment: list of relations]].
Dependencies: No dependencies
Page 114 of 354 Version 2.1
August 1999

Unobservability (FPR_UNO) 9 - Class FPR: Privacy
359
360
361
362
364
365
FPR_UNO
358
363
Unobservability
Family behaviour
This family ensures that a user may use a resource or service without others, especially third parties, being able to observe that the resource or service is being used.
Component levelling
2
FPR_UNO Unobservability
1
3
4
FPR_UNO.1 Unobservability requires that users and/or subjects cannot determine whether an operation is being performed.
FPR_UNO.2 Allocation of information impacting unobservability requires that the
TSF provide specific mechanisms to avoid the concentration of privacy related information within the TOE. Such concentrations might impact unobservability if a security compromise occurs.
FPR_UNO.3 Unobservability without soliciting information requires that the TSF does not try to obtain privacy related information that might be used to compromise unobservability.
FPR_UNO.4 Authorised user observability requires the TSF to provide one or more authorised users with a capability to observe the usage of resources and/or services.
Management: FPR_UNO.1, FPR_UNO.2
The following actions could be considered for the management functions in FMT: a) the management of the behaviour of the unobservability function.
Management: FPR_UNO.3
There are no management activities foreseen for these components.
Management: FPR_UNO.4
The following actions could be considered for the management functions in FMT:
August 1999 Version 2.1
Page 115 of 354

9 - Class FPR: Privacy Unobservability (FPR_UNO)
366 a) the list of authorised users that are capable of determining the occurence of operations.
Audit: FPR_UNO.1, FPR_UNO.2
The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP / ST:
367
368 a) Minimal: The invocation of the unobservability mechanism.
Audit: FPR_UNO.3
There are no actions identified that should be auditable if FAU_GEN Security
Audit Data Generation is included in the PP/ST.
Audit: FPR_UNO.4
The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP / ST: a) Minimal: The observation of the use of a resource or service by a user or subject.
FPR_UNO.1
Unobservability
Hierarchical to: No other components.
FPR_UNO.1.1
The TSF shall ensure that [assignment: list of users and/or subjects] are unable to observe the operation [assignment: list of operations] on [assignment: list of
objects] by [assignment: list of protected users and/or subjects].
Dependencies: No dependencies
FPR_UNO.2
Allocation of information impacting unobservability
Hierarchical to: FPR_UNO.1
FPR_UNO.2.1
The TSF shall ensure that [assignment: list of users and/or subjects] are unable to observe the operation [assignment: list of operations] on [assignment: list of
objects] by [assignment: list of protected users and/or subjects].
FPR_UNO.2.2
The TSF shall allocate the [assignment: unobservability related information] among different parts of the TOE such that the following conditions hold during the lifetime of the information: [assignment: list of conditions].
Dependencies: No dependencies
Page 116 of 354 Version 2.1
August 1999

Unobservability (FPR_UNO) 9 - Class FPR: Privacy
FPR_UNO.3
Unobservability without soliciting information
Hierarchical to: No other components.
FPR_UNO.3.1
The TSF shall provide [assignment: list of services] to [assignment: list of
subjects] without soliciting any reference to [assignment: privacy related
information].
Dependencies: FPR_UNO.1 Unobservability
FPR_UNO.4
Authorised user observability
Hierarchical to: No other components.
FPR_UNO.4.1
The TSF shall provide [assignment: set of authorised users] with the capability to observe the usage of [assignment: list of resources and/or services].
Dependencies: No dependencies
August 1999 Version 2.1
Page 117 of 354

9 - Class FPR: Privacy Unobservability (FPR_UNO)
Page 118 of 354 Version 2.1
August 1999

369
370
Class FPTProtection of the TOE Security Functions
This class contains families of functional requirements that relate to the integrity and management of the mechanisms that provide the TSF (independent of TSPspecifics) and to the integrity of TSF data (independent of the specific contents of the TSP data). In some sense, families in this class may appear to duplicate components in the FDP (User data protection) class; they may even be implemented using the same mechanisms. However, FDP focuses on user data protection, while
FPT focuses on TSF data protection. In fact, components from the FPT class are necessary to provide requirements that the SFPs in the TOE cannot be tampered with or bypassed.
From the point of view of this class, there are three significant portions for the TSF: a) The TSF's abstract machine, which is the virtual or physical machine upon which the specific TSF implementation under evaluation executes.
b) The TSF's implementation, which executes on the abstract machine and implements the mechanisms that enforce the TSP.
c) The TSF's data, which are the administrative databases that guide the enforcement of the TSP.
August 1999 Version 2.1
Page 119 of 354

10 - Class FPT: Protection of the TSF
Protection of the TSF
FPT_AMT Underlying abstract machine test
FPT_FLS Fail secure
FPT_ITA Availability of exported TSF data
FPT_ITC Confidentiality of exported TSF data
FPT_ITI Integrity of exported TSF data
FPT_ITT Internal TOE TSF data transfer
FPT_PHP TSF physical protection
FPT_RCV Trusted recovery
1
1
1
1
1
1
3
1
4
3
1
2
2
2
2 3
Figure 10.1 - Protection of the TSF class decomposition
Page 120 of 354 Version 2.1
August 1999

10 - Class FPT: Protection of the TSF
Protection of the TSF
FPT_RPL Replay detection
FPT_RVM Reference mediation
FPT_SEP Domain separation
FPT_SSP State synchrony protocol
FPT_STM Time stamps
FPT_TDC Inter-TSF TSF data consistency
FPT_TRC Internal TOE TSF data replication consistency
FPT_TST TSF self test
1
1
Figure 10.2 - Protection of the TSF class decomposition (Cont.)
1
1
1
1
1
1
2
2
3
August 1999 Version 2.1
Page 121 of 354

10 - Class FPT: Protection of the TSF Underlying abstract machine test
(FPT_AMT)
FPT_AMT
371
Underlying abstract machine test
Family behaviour
This family defines requirements for the TSF to perform testing to demonstrate the security assumptions made about the underlying abstract machine upon which the
TSF relies. This “abstract” machine could be a hardware/firmware platform, or it could be some known and assessed hardware/software combination acting as a virtual machine.
Component levelling
FPT_AMT Underlying abstract machine test 1
372
373
FPT_AMT.1 Abstract machine testing, provides for testing of the underlying abstract machine.
Management: FPT_AMT.1
The following actions could be considered for the management functions in FMT: a) management of the conditions under which abstract machine test occurs, such as during initial start-up, regular interval, or under specified conditions; b) management of the time interval if appropriate.
Audit: FPT_AMT.1
374 The following actions should be audited if FAU_GEN Security audit data generation is included in the PP/ST: a) Basic: Execution of the tests of the underlying machine and the results of the tests.
FPT_AMT.1
Abstract machine testing
Hierarchical to: No other components.
FPT_AMT.1.1
The TSF shall run a suite of tests [selection: during initial start-up, periodically
during normal operation, at the request of an authorised user, other conditions] to demonstrate the correct operation of the security assumptions provided by the abstract machine that underlies the TSF.
Dependencies: No dependencies
Page 122 of 354 Version 2.1
August 1999

Fail secure (FPT_FLS) 10 - Class FPT: Protection of the TSF
FPT_FLS
375
Fail secure
Family behaviour
The requirements of this family ensure that the TOE will not violate its TSP in the event of identified categories of failures in the TSF.
Component levelling
FPT_FLS Fail secure 1
376
377
378
This family consists of only one component, FPT_FLS.1 Failure with preservation of secure state, which requires that the TSF preserve a secure state in the face of the identified failures.
Management: FPT_FLS.1
There are no management activities foreseen.
Audit: FPT_FLS.1
The following actions should be audited if FAU_GEN Security audit data generation is included in the PP/ST: a) Basic: Failure of the TSF.
FPT_FLS.1
Failure with preservation of secure state
Hierarchical to: No other components.
FPT_FLS.1.1
The TSF shall preserve a secure state when the following types of failures occur: [assignment: list of types of failures in the TSF].
Dependencies: ADV_SPM.1 Informal TOE security policy model
August 1999 Version 2.1
Page 123 of 354

10 - Class FPT: Protection of the TSF Availability of exported TSF data
(FPT_ITA)
FPT_ITA
379
Availability of exported TSF data
Family behaviour
This family defines the rules for the prevention of loss of availability of TSF data moving between the TSF and a remote trusted IT product. This data could, for example, be TSF critical data such as passwords, keys, audit data, or TSF executable code.
Component levelling
FPT_ITA Availability of exported TSF data 1
380
381
This family consists of only one component, FPT_ITA.1 Inter-TSF availability within a defined availability metric. This component requires that the TSF ensure, to an identified degree of probability, the availability of TSF data provided to a remote trusted IT product.
Management: FPT_ITA.1
The following actions could be considered for the management functions in FMT: a) management of the list of types of TSF data that must be available to a remote trusted IT product.
382
Audit: FPT_ITA.1
The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP / ST: a) Minimal: the absence of TSF data when required by a TOE.
FPT_ITA.1
Inter-TSF availability within a defined availability metric
FPT_ITA.1.1
Hierarchical to: No other components.
The TSF shall ensure the availability of [assignment: list of types of TSF data] provided to a remote trusted IT product within [assignment: a defined
availability metric] given the following conditions [assignment: conditions to
ensure availability].
Dependencies: No dependencies
Page 124 of 354 Version 2.1
August 1999

Confidentiality of exported TSF data
(FPT_ITC)
10 - Class FPT: Protection of the TSF
FPT_ITC
383
Confidentiality of exported TSF data
Family behaviour
This family defines the rules for the protection from unauthorised disclosure of TSF data during transmission between the TSF and a remote trusted IT product. This data could, for example, be TSF critical data such as passwords, keys, audit data, or
TSF executable code.
Component levelling
FPT_ITC Confidentiality of exported TSF data 1
384
385
This family consists of only one component, FPT_ITC.1 Inter-TSF confidentiality during transmission, which requires that the TSF ensure that data transmitted between the TSF and a remote trusted IT product is protected from disclosure while in transit.
Management: FPT_ITC.1
There are no management activities foreseen.
386
Audit: FPT_ITC.1
There are no actions identified that should be auditable if FAU_GEN Security audit data generation is included in the PP/ST.
FPT_ITC.1
Inter-TSF confidentiality during transmission
FPT_ITC.1.1
Hierarchical to: No other components.
The TSF shall protect all TSF data transmitted from the TSF to a remote trusted IT product from unauthorised disclosure during transmission.
Dependencies: No dependencies
August 1999 Version 2.1
Page 125 of 354

10 - Class FPT: Protection of the TSF Integrity of exported TSF data (FPT_ITI)
390
391
FPT_ITI
387
388
389
392
Integrity of exported TSF data
Family behaviour
This family defines the rules for the protection, from unauthorised modification, of
TSF data during transmission between the TSF and a remote trusted IT product.
This data could, for example, be TSF critical data such as passwords, keys, audit data, or TSF executable code.
Component levelling
FPT_ITI Integrity of exported TSF data 1 2
FPT_ITI.1 Inter-TSF detection of modification, provides the ability to detect modification of TSF data during transmission between the TSF and a remote trusted IT product, under the assumption that the remote trusted IT product is cognisant of the mechanism used.
FPT_ITI.2 Inter-TSF detection and correction of modification, provides the ability for the remote trusted IT product not only to detect modification, but to correct modified TSF data under the assumption that the remote trusted
IT product is cognisant of the mechanism used.
Management: FPT_ITI.1
There are no management activities foreseen.
Management: FPT_ITI.2
The following actions could be considered for the management functions in FMT: a) management of the types of TSF data that the TSF should try to correct if modified in transit; b) management of the types of action that the TSF could take if TSF data is modified in transit.
Audit: FPT_ITI.1
The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP / ST: a) Minimal: the detection of modification of transmitted TSF data.
b) Basic: the action taken upon detection of modification of transmitted
TSF data.
Page 126 of 354 Version 2.1
August 1999

Integrity of exported TSF data (FPT_ITI) 10 - Class FPT: Protection of the TSF
393
Audit: FPT_ITI.2
The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP / ST: a) Minimal: the detection of modification of transmitted TSF data; b) Basic: the action taken upon detection of modification of transmitted
TSF data.
c) Basic: the use of the correction mechanism.
FPT_ITI.1
Inter-TSF detection of modification
Hierarchical to: No other components.
FPT_ITI.1.1
FPT_ITI.1.2
The TSF shall provide the capability to detect modification of all TSF data during transmission between the TSF and a remote trusted IT product within the following metric: [assignment: a defined modification metric].
The TSF shall provide the capability to verify the integrity of all TSF data transmitted between the TSF and a remote trusted IT product and perform
[assignment: action to be taken] if modifications are detected.
Dependencies: No dependencies
FPT_ITI.2
Inter-TSF detection and correction of modification
Hierarchical to: FPT_ITI.1
FPT_ITI.2.1
FPT_ITI.2.2
FPT_ITI.2.3
The TSF shall provide the capability to detect modification of all TSF data during transmission between the TSF and a remote trusted IT product within the following metric: [assignment: a defined modification metric].
The TSF shall provide the capability to verify the integrity of all TSF data transmitted between the TSF and a remote trusted IT product and perform
[assignment: action to be taken] if modifications are detected.
The TSF shall provide the capability to correct [assignment: type of
modification] of all TSF data transmitted between the TSF and a remote trusted IT product.
Dependencies: No dependencies
August 1999 Version 2.1
Page 127 of 354

10 - Class FPT: Protection of the TSF Internal TOE TSF data transfer (FPT_ITT)
395
396
397
FPT_ITT
394
398
399
Internal TOE TSF data transfer
Family behaviour
This family provides requirements that address protection of TSF data when it is transferred between separate parts of a TOE across an internal channel.
Component levelling
1 2
FPT_ITT Internal TOE TSF data transfer
3
FPT_ITT.1 Basic internal TSF data transfer protection, requires that TSF data be protected when transmitted between separate parts of the TOE.
FPT_ITT.2 TSF data transfer separation, requires that the TSF separate user data from TSF data during transmission.
FPT_ITT.3 TSF data integrity monitoring, requires that the TSF data transmitted between separate parts of the TOE is monitored for identified integrity errors.
Management: FPT_ITT.1
The following actions could be considered for the management functions in FMT: a) management of the types of modification against which the TSF should protect; b) management of the mechanism used to provide the protection of the data in transit between different parts of the TSF.
Management: FPT_ITT.2
The following actions could be considered for the management functions in FMT: a) management of the types of modification against which the TSF should protect; b) management of the mechanism used to provide the protection of the data in transit between different parts of the TSF; c) management of the separation mechanism.
Page 128 of 354 Version 2.1
August 1999

Internal TOE TSF data transfer (FPT_ITT) 10 - Class FPT: Protection of the TSF
400
401
402
Management: FPT_ITT.3
The following actions could be considered for the management functions in FMT: a) management of the types of modification against which the TSF should protect; b) management of the mechanism used to provide the protection of the data in transit between different parts of the TSF; c) management of the types of modification of TSF data the TSF should try to detect; d) management of the actions that will be taken.
Audit: FPT_ITT.1, FPT_ITT.2
There are no actions identified that should be auditable if FAU_GEN Security audit data generation is included in the PP/ST.
Audit: FPT_ITT.3
The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP / ST: a) Minimal: the detection of modification of TSF data; b) Basic: the action taken following detection of an integrity error.
FPT_ITT.1
Basic internal TSF data transfer protection
Hierarchical to: No other components.
FPT_ITT.1.1
The TSF shall protect TSF data from [selection: disclosure, modification] when it is transmitted between separate parts of the TOE.
Dependencies: No dependencies
FPT_ITT.2
TSF data transfer separation
Hierarchical to: FPT_ITT.1
FPT_ITT.2.1
FPT_ITT.2.2
The TSF shall protect TSF data from [selection: disclosure, modification] when it is transmitted between separate parts of the TOE.
The TSF shall separate user data from TSF data when such data is transmitted between separate parts of the TOE.
Dependencies: No dependencies
August 1999 Version 2.1
Page 129 of 354

10 - Class FPT: Protection of the TSF Internal TOE TSF data transfer (FPT_ITT)
FPT_ITT.3
TSF data integrity monitoring
Hierarchical to: No other components.
FPT_ITT.3.1
FPT_ITT.3.2
The TSF shall be able to detect [selection: modification of data, substitution of
data, re-ordering of data, deletion of data, [assignment: other integrity errors]] for TSF data transmitted between separate parts of the TOE.
Upon detection of a data integrity error, the TSF shall take the following actions: [assignment: specify the action to be taken].
Dependencies: FPT_ITT.1 Basic internal TSF data transfer protection
Page 130 of 354 Version 2.1
August 1999

TSF physical protection (FPT_PHP) 10 - Class FPT: Protection of the TSF
406
407
408
409
FPT_PHP
403
404
405
TSF physical protection
Family behaviour
TSF physical protection components refer to restrictions on unauthorised physical access to the TSF, and to the deterrence of, and resistance to, unauthorised physical modification, or substitution of the TSF.
The requirements of components in this family ensure that the TSF is protected from physical tampering and interference. Satisfying the requirements of these components results in the TSF being packaged and used in such a manner that physical tampering is detectable, or resistance to physical tampering is enforced.
Without these components, the protection functions of a TSF lose their effectiveness in environments where physical damage cannot be prevented. This family also provides requirements regarding how the TSF shall respond to physical tampering attempts.
Component levelling
2
FPT_PHP TSF physical protection
1
3
FPT_PHP.1 Passive detection of physical attack, provides for features that indicate when a TSF device or TSF element is subject to tampering. However, notification of tampering is not automatic; an authorised user must invoke a security administrative function or perform manual inspection to determining if tampering has occurred.
FPT_PHP.2 Notification of physical attack, provides for automatic notification of tampering for an identified subset of physical penetrations.
FPT_PHP.3 Resistance to physical attack, provides for features that prevent or resist physical tampering with TSF devices and TSF elements.
Management: FPT_PHP.1
There are no management activities foreseen.
Management: FPT_PHP.2
The following actions could be considered for the management functions in FMT: a) management of the user or role that gets informed about intrusions;
August 1999 Version 2.1
Page 131 of 354

10 - Class FPT: Protection of the TSF TSF physical protection (FPT_PHP)
410
411
412 b) management of the list of devices that should inform the indicated user or role about the intrusion.
Management: FPT_PHP.3
The following actions could be considered for the management functions in FMT: a) management of the automatic responses to physical tampering.
Audit: FPT_PHP.1
The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP / ST: a) Minimal: if detection by IT means, detection of intrusion.
Audit: FPT_PHP.2,
The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP / ST: a) Minimal: detection of intrusion.
Audit: FPT_PHP.3
413 There are no actions identified that should be auditable if FAU_GEN Security audit data generation is included in the PP / ST.
FPT_PHP.1
Passive detection of physical attack
Hierarchical to: No other components.
FPT_PHP.1.1
FPT_PHP.1.2
The TSF shall provide unambiguous detection of physical tampering that might compromise the TSF.
The TSF shall provide the capability to determine whether physical tampering with the TSF’s devices or TSF’s elements has occurred.
Dependencies: FMT_MOF.1 Management of security functions behaviour
FPT_PHP.2
Notification of physical attack
Hierarchical to: FPT_PHP.1
FPT_PHP.2.1
FPT_PHP.2.2
The TSF shall provide unambiguous detection of physical tampering that might compromise the TSF.
The TSF shall provide the capability to determine whether physical tampering with the TSF’s devices or TSF’s elements has occurred.
Page 132 of 354 Version 2.1
August 1999

TSF physical protection (FPT_PHP) 10 - Class FPT: Protection of the TSF
FPT_PHP.2.3
For [assignment: list of TSF devices/elements for which active detection is
required], the TSF shall monitor the devices and elements and notify devices or TSF’s elements has occurred.
Dependencies: FMT_MOF.1 Management of security functions behaviour
FPT_PHP.3
Resistance to physical attack
Hierarchical to: No other components.
FPT_PHP.3.1
The TSF shall resist [assignment: physical tampering scenarios] to the
[assignment: list of TSF devices/elements] by responding automatically such that the TSP is not violated.
Dependencies: No dependencies
August 1999 Version 2.1
Page 133 of 354

10 - Class FPT: Protection of the TSF Trusted recovery (FPT_RCV)
417
418
415
416
FPT_RCV
414
419
420
Trusted recovery
Family behaviour
The requirements of this family ensure that the TSF can determine that the TOE is started up without protection compromise and can recover without protection compromise after discontinuity of operations. This family is important because the start-up state of the TSF determines the protection of subsequent states.
Component levelling
2 3
FPT_RCV Trusted recovery
1
4
FPT_RCV.1 Manual recovery, allows a TOE to only provide mechanisms that involve human intervention to return to a secure state.
FPT_RCV.2 Automated recovery, provides, for at least one type of service discontinuity, recovery to a secure state without human intervention; recovery for other discontinuities may require human intervention.
FPT_RCV.3 Automated recovery without undue loss, also provides for automated recovery, but strengthens the requirements by disallowing undue loss of protected objects.
FPT_RCV.4 Function recovery, provides for recovery at the level of particular SFs, ensuring either successful completion or rollback of TSF data to a secure state.
Management: FPT_RCV.1
The following actions could be considered for the management functions in FMT: a) management of who can access the restore capability within the maintenance mode.
Management: FPT_RCV.2, FPT_RCV.3
The following actions could be considered for the management functions in FMT: a) management of who can access the restore capability within the maintenance mode; b) management of the list of failures/service discontinuities that will be handled through the automatic procedures.
Page 134 of 354 Version 2.1
August 1999

Trusted recovery (FPT_RCV) 10 - Class FPT: Protection of the TSF
421
422
Management: FPT_RCV.4
There are no management activities foreseen.
Audit: FPT_RCV.1, FPT_RCV.2, FPT_RCV.3
The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP / ST: a) Minimal: the fact that a failure or service discontinuity occurred; b) Minimal: resumption of the regular operation;
423 c) Basic: type of failure or service discontinuity.
Audit: FPT_RCV.4
The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP / ST: a) Minimal: if possible, the impossibility to return to a secure state after failure of a security function; b) Basic: if possible, the detection of a failure of a security function.
FPT_RCV.1
Manual recovery
Hierarchical to: No other components.
FPT_RCV.1.1
After a failure or service discontinuity, the TSF shall enter a maintenance mode where the ability to return the TOE to a secure state is provided.
Dependencies: FPT_TST.1 TSF testing
AGD_ADM.1 Administrator guidance
ADV_SPM.1 Informal TOE security policy model
FPT_RCV.2
Automated recovery
Hierarchical to: FPT_RCV.1
FPT_RCV.2.1
When automated recovery from a failure or service discontinuity is not possible, the TSF shall enter a maintenance mode where the ability to return the TOE to a secure state is provided.
FPT_RCV.2.2
For [assignment: list of failures/service discontinuities], the TSF shall ensure the return of the TOE to a secure state using automated procedures.
August 1999 Version 2.1
Page 135 of 354

10 - Class FPT: Protection of the TSF Trusted recovery (FPT_RCV)
Dependencies: FPT_TST.1 TSF testing
AGD_ADM.1 Administrator guidance
ADV_SPM.1 Informal TOE security policy model
FPT_RCV.3
Automated recovery without undue loss
Hierarchical to: FPT_RCV.2
FPT_RCV.3.1
When automated recovery from a failure or service discontinuity is not possible, the
TSF shall enter a maintenance mode where the ability to return the TOE to a secure state is provided.
FPT_RCV.3.2
For [assignment: list of failures/service discontinuities], the TSF shall ensure the return of the TOE to a secure state using automated procedures.
FPT_RCV.3.3
The functions provided by the TSF to recover from failure or service discontinuity shall ensure that the secure initial state is restored without exceeding [assignment: quantification] for loss of TSF data or objects within the TSC.
FPT_RCV.3.4
The TSF shall provide the capability to determine the objects that were or were not capable of being recovered.
Dependencies: FPT_TST.1 TSF testing
AGD_ADM.1 Administrator guidance
ADV_SPM.1 Informal TOE security policy model
FPT_RCV.4
Function recovery
Hierarchical to: No other components.
FPT_RCV.4.1
The TSF shall ensure that [assignment: list of SFs and failure scenarios] have the property that the SF either completes successfully, or for the indicated failure scenarios, recovers to a consistent and secure state.
Dependencies: ADV_SPM.1 Informal TOE security policy model
Page 136 of 354 Version 2.1
August 1999

Replay detection (FPT_RPL) 10 - Class FPT: Protection of the TSF
FPT_RPL
424
Replay detection
Family behaviour
This family addresses detection of replay for various types of entities (e.g.
messages, service requests, service responses) and subsequent actions to correct. In the case where replay may be detected, this effectively prevents it.
Component levelling
FPT_RPL Replay detection 1
425
426
The family consists of only one component, FPT_RPL.1 Replay detection, which requires that the TSF shall be able to detect the replay of identified entities.
Management: FPT_RPL.1
The following actions could be considered for the management functions in FMT: a) management of the list of identified entities for which replay shall be detected;
427 b) management of the list of actions that need to be taken in case of replay.
Audit: FPT_RPL.1
The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP / ST: a) Basic: Detected replay attacks.
b) Detailed: Action to be taken based on the specific actions.
FPT_RPL.1
Replay detection
Hierarchical to: No other components.
FPT_RPL.1.1
The TSF shall detect replay for the following entities: [assignment: list of
identified entities].
FPT_RPL.1.2
The TSF shall perform [assignment: list of specific actions] when replay is detected.
Dependencies: No dependencies
August 1999 Version 2.1
Page 137 of 354

10 - Class FPT: Protection of the TSF Reference mediation (FPT_RVM)
FPT_RVM
428
429
Reference mediation
Family behaviour
The requirements of this family address the “always invoked” aspect of a traditional reference monitor. The goal of this family is to ensure, with respect to a given SFP, that all actions requiring policy enforcement are validated by the TSF against the
SFP. If the portion of the TSF that enforces the SFP also meets the requirements of appropriate components from FPT_SEP (Domain separation) and ADV_INT (TSF internals), then that portion of the TSF provides a “reference monitor” for that SFP.
A TSF that implements a SFP provides effective protection against unauthorised operation if and only if all enforceable actions (e.g. accesses to objects) requested by untrusted subjects with respect to any or all of that SFP are validated by the TSF before succeeding. If an action that could be enforceable by the TSF, is incorrectly enforced or incorrectly bypassed, the overall enforcement of the SFP could be compromised. Subjects could then bypass the SFP in a variety of unauthorised ways
(e.g. circumvent access checks for some subjects or objects, bypass checks for objects whose protection was assumed by applications, retain access rights beyond their intended lifetime, bypass auditing of audited actions, or bypass authentication). Note that some subjects, the so called “trusted subjects” with respect to a specific SFP, might be trusted to enforce the SFP by themselves, and bypass the mediation of the SFP.
Component levelling
FPT_RVM Reference mediation 1
430
431
432
This family consists of only one component, FPT_RVM.1 Non-bypassability of the
TSP, which requires non-bypassability for all SFPs in the TSP.
Management: FPT_RVM.1
There are no management activities foreseen.
Audit: FPT_RVM.1
There are no actions identified that should be auditable if FAU_GEN Security audit data generation is included in the PP/ST.
FPT_RVM.1
Non-bypassability of the TSP
Hierarchical to: No other components.
FPT_RVM.1.1
The TSF shall ensure that TSP enforcement functions are invoked and succeed before each function within the TSC is allowed to proceed.
Page 138 of 354 Version 2.1
August 1999

Reference mediation (FPT_RVM)
Dependencies: No dependencies
10 - Class FPT: Protection of the TSF
August 1999 Version 2.1
Page 139 of 354

10 - Class FPT: Protection of the TSF Domain separation (FPT_SEP)
FPT_SEP
433
434
Domain separation
Family behaviour
The components of this family ensure that at least one security domain is available for the TSF’s own execution and that the TSF is protected from external interference and tampering (e.g. by modification of TSF code or data structures) by untrusted subjects. Satisfying the requirements of this family makes the TSF selfprotecting, meaning that an untrusted subject cannot modify or damage the TSF.
This family requires the following: a) The resources of the TSF’s security domain (“protected domain”) and those of subjects and unconstrained entities external to the domain are separated such that the entities external to the protected domain cannot observe or modify TSF data or TSF code internal to the protected domain.
b) The transfers between domains are controlled such that arbitrary entry to, or return from, the protected domain is not possible. c) The user or application parameters passed to the protected domain by addresses are validated with respect to the protected domain’s address space, and those passed by value are validated with respect to the values expected by the protected domain.
d) The security domains of subjects are distinct except for controlled sharing via the TSF.
Component levelling
FPT_SEP Domain separation 1 2 3
435
436
437
438
Page 140 of 354
FPT_SEP.1 TSF domain separation, provides a distinct protected domain for the
TSF and provides separation between subjects within the TSC.
FPT_SEP.2 SFP domain separation, requires that the TSF be further subdivided, with distinct domain(s) for an identified set of SFPs that act as reference monitors for their policies, and a domain for the remainder of the TSF, as well as domains for the non-TSF portions of the TOE.
FPT_SEP.3 Complete reference monitor, requires that there be distinct domain(s) for TSP enforcement, a domain for the remainder of the TSF, as well as domains for the non-TSF portions of the TOE.
Management: FPT_SEP.1, FPT_SEP.2, FPT_SEP.3
There are no management activities foreseen.
Version 2.1
August 1999

Domain separation (FPT_SEP) 10 - Class FPT: Protection of the TSF
439
Audit: FPT_SEP.1, FPT_SEP.2, FPT_SEP.3
There are no actions identified that should be auditable if FAU_GEN Security audit data generation is included in the PP/ST.
FPT_SEP.1
TSF domain separation
Hierarchical to: No other components.
FPT_SEP.1.1
FPT_SEP.1.2
The TSF shall maintain a security domain for its own execution that protects it from interference and tampering by untrusted subjects.
The TSF shall enforce separation between the security domains of subjects in the TSC.
Dependencies: No dependencies
FPT_SEP.2
SFP domain separation
Hierarchical to: FPT_SEP.1
FPT_SEP.2.1
FPT_SEP.2.2
FPT_SEP.2.3
The unisolated portion of the TSF shall maintain a security domain for its own execution that protects it from interference and tampering by untrusted subjects.
The TSF shall enforce separation between the security domains of subjects in the
TSC.
The TSF shall maintain the part of the TSF related to [assignment: list of
access control and/or information flow control SFPs] in a security domain for their own execution that protects them from interference and tampering by the remainder of the TSF and by subjects untrusted with respect to those SFPs.
Dependencies: No dependencies
FPT_SEP.3
Complete reference monitor
Hierarchical to: FPT_SEP.2
FPT_SEP.3.1
FPT_SEP.3.2
FPT_SEP.3.3
The unisolated portion of the TSF shall maintain a security domain for its own execution that protects it from interference and tampering by untrusted subjects.
The TSF shall enforce separation between the security domains of subjects in the
TSC.
The TSF shall maintain the part of the TSF that enforces the access control and/
or information flow control SFPs in a security domain for its own execution that protects them from interference and tampering by the remainder of the TSF and by subjects untrusted with respect to the TSP.
Dependencies: No dependencies
August 1999 Version 2.1
Page 141 of 354

10 - Class FPT: Protection of the TSF State synchrony protocol (FPT_SSP)
FPT_SSP
440
441
State synchrony protocol
Family behaviour
Distributed systems may give rise to greater complexity than monolithic systems through the potential for differences in state between parts of the system, and through delays in communication. In most cases synchronisation of state between distributed functions involves an exchange protocol, not a simple action. When malice exists in the distributed environment of these protocols, more complex defensive protocols are required.
FPT_SSP establishes the requirement for certain critical security functions of the
TSF to use this trusted protocol. FPT_SSP ensures that two distributed parts of the
TOE (e.g. hosts) have synchronised their states after a security-relevant action.
Component levelling
FPT_SSP State synchrony protocol 1 2
442
443
444
445
FPT_SSP.1 Simple trusted acknowledgement requires only a simple acknowledgment by the data recipient.
FPT_SSP.2 Mutual trusted acknowledgement requires mutual acknowledgment of the data exchange.
Management: FPT_SSP.1, FPT_SSP.2
There are no management activities foreseen.
Audit: FPT_SSP.1, FPT_SSP.2
The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP / ST: a) Minimal: failure to receive an acknowledgement when expected.
FPT_SSP.1
Simple trusted acknowledgement
Hierarchical to: No other components.
FPT_SSP.1.1
The TSF shall acknowledge, when requested by another part of the TSF, the receipt of an unmodified TSF data transmission.
Dependencies: FPT_ITT.1 Basic internal TSF data transfer protection
Page 142 of 354 Version 2.1
August 1999

State synchrony protocol (FPT_SSP) 10 - Class FPT: Protection of the TSF
FPT_SSP.2
Mutual trusted acknowledgement
Hierarchical to: FPT_SSP.1
FPT_SSP.2.1
FPT_SSP.2.2
The TSF shall acknowledge, when requested by another part of the TSF, the receipt of an unmodified TSF data transmission.
The TSF shall ensure that the relevant parts of the TSF know the correct status of transmitted data among its different parts, using acknowledgements.
Dependencies: FPT_ITT.1 Basic internal TSF data transfer protection
August 1999 Version 2.1
Page 143 of 354

10 - Class FPT: Protection of the TSF Time stamps (FPT_STM)
FPT_STM
446
Time stamps
Family behaviour
This family addresses requirements for a reliable time stamp function within a TOE.
Component levelling
FPT_STM Time stamps 1
447
448
This family consists of only one component, FPT_STM.1 Reliable time stamps, which requires that the TSF provide reliable time stamps for TSF functions.
Management: FPT_STM.1
The following actions could be considered for the management functions in FMT:
449 a) management of the time.
Audit: FPT_STM.1
The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP / ST: a) Minimal: changes to the time; b) Detailed: providing a timestamp.
FPT_STM.1
Reliable time stamps
Hierarchical to: No other components.
FPT_STM.1.1
The TSF shall be able to provide reliable time stamps for its own use.
Dependencies: No dependencies
Page 144 of 354 Version 2.1
August 1999

Inter-TSF TSF data consistency
(FPT_TDC)
10 - Class FPT: Protection of the TSF
FPT_TDC
450
Inter-TSF TSF data consistency
Family behaviour
In a distributed or composite system environment, a TOE may need to exchange
TSF data (e.g. the SFP-attributes associated with data, audit information, identification information) with another trusted IT product. This family defines the requirements for sharing and consistent interpretation of these attributes between the TSF of the TOE and a different trusted IT product.
Component levelling
FPT_TDC Inter-TSF TSF data consistency 1
451
FPT_TDC.1 Inter-TSF basic TSF data consistency requires that the TSF provide the capability to ensure consistency of attributes between TSFs.
452
453
Management: FPT_TDC.1
There are no management activities foreseen.
Audit: FPT_TDC.1
The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP / ST: a) Minimal: Successful use of TSF data consistency mechanisms.
b) Basic: Use of the TSF data consistency mechanisms.
c) Basic: Identification of which TSF data have been interpreted.
d) Basic: Detection of modified TSF data.
FPT_TDC.1
Inter-TSF basic TSF data consistency
Hierarchical to: No other components.
FPT_TDC.1.1
The TSF shall provide the capability to consistently interpret [assignment: list
of TSF data types] when shared between the TSF and another trusted IT product.
FPT_TDC.1.2
The TSF shall use [assignment: list of interpretation rules to be applied by the
TSF] when interpreting the TSF data from another trusted IT product.
Dependencies: No dependencies
August 1999 Version 2.1
Page 145 of 354

10 - Class FPT: Protection of the TSF Internal TOE TSF data replication consistency (FPT_TRC)
FPT_TRC
454
Internal TOE TSF data replication consistency
Family behaviour
The requirements of this family are needed to ensure the consistency of TSF data when such data is replicated internal to the TOE. Such data may become inconsistent if the internal channel between parts of the TOE becomes inoperative.
If the TOE is internally structured as a network and parts of the TOE network connections are broken, this may occur when parts become disabled.
Component levelling
FPT_TRC Internal TOE TSF data replication consistency 1
455
456
457
This family consists of only one component, FPT_TRC.1 Internal TSF consistency, which requires that the TSF ensure the consistency of TSF data that is replicated in multiple locations.
Management: for FPT_TRC.1
There are no management activities foreseen.
Audit: for FPT_TRC.1
The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP / ST: a) Minimal: restoring consistency upon reconnection.
b) Basic: Detected inconsistency between TSF data.
FPT_TRC.1
Internal TSF consistency
Hierarchical to: No other components.
FPT_TRC.1.1
The TSF shall ensure that TSF data is consistent when replicated between parts of the TOE.
FPT_TRC.1.2
When parts of the TOE containing replicated TSF data are disconnected, the
TSF shall ensure the consistency of the replicated TSF data upon reconnection before processing any requests for [assignment: list of SFs dependent on TSF
data replication consistency].
Dependencies: FPT_ITT.1 Basic internal TSF data transfer protection
Page 146 of 354 Version 2.1
August 1999

TSF self test (FPT_TST) 10 - Class FPT: Protection of the TSF
FPT_TST
458
459
460
461
462
TSF self test
Family behaviour
The family defines the requirements for the self-testing of the TSF with respect to some expected correct operation. Examples are interfaces to enforcement functions, and sample arithmetical operations on critical parts of the TOE. These tests can be carried out at start-up, periodically, at the request of the authorised user, or when other conditions are met. The actions to be taken by the TOE as the result of self testing are defined in other families.
The requirements of this family are also needed to detect the corruption of TSF executable code (i.e. TSF software) and TSF data by various failures that do not necessarily stop the TOE's operation (which would be handled by other families).
These checks must be performed because these failures may not necessarily be prevented. Such failures can occur either because of unforeseen failure modes or associated oversights in the design of hardware, firmware, or software, or because of malicious corruption of the TSF due to inadequate logical and/or physical protection.
Component levelling
FPT_TST TSF self test 1
FPT_TST.1 TSF testing, provides the ability to test the TSF’s correct operation.
These tests may be performed at start-up, periodically, at the request of the authorised user, or when other conditions are met. It also provides the ability to verify the integrity of TSF data and executable code.
Management: for FPT_TST.1
The following actions could be considered for the management functions in FMT: a) management of the conditions under which TSF self testing occurs, such as during initial start-up, regular interval, or under specified conditions; b) management of the time interval if appropriate.
Audit: for FPT_TST.1
The following actions should be audited if FAU_GEN Security audit data generation is included in the PP/ST: a) Basic: Execution of the TSF self tests and the results of the tests.
August 1999 Version 2.1
Page 147 of 354

10 - Class FPT: Protection of the TSF TSF self test (FPT_TST)
FPT_TST.1
TSF testing
Hierarchical to: No other components.
FPT_TST.1.1
FPT_TST.1.2
FPT_TST.1.3
The TSF shall run a suite of self tests [selection: during initial start-up, periodically during normal operation, at the request of the authorised user, at the
conditions [assignment: conditions under which self test should occur]] to demonstrate the correct operation of the TSF.
The TSF shall provide authorised users with the capability to verify the integrity of TSF data.
The TSF shall provide authorised users with the capability to verify the integrity of stored TSF executable code.
Dependencies: FPT_AMT.1 Abstract machine testing
Page 148 of 354 Version 2.1
August 1999

11 - Class FRU: Resource utilisation
463
Class FRUResource utilisation
This class provides three families that support the availability of required resources such as processing capability and/or storage capacity. The family Fault Tolerance provides protection against unavailability of capabilities caused by failure of the
TOE. The family Priority of Service ensures that the resources will be allocated to the more important or time-critical tasks and cannot be monopolised by lower priority tasks. The family Resource Allocation provides limits on the use of available resources, therefore preventing users from monopolising the resources.
Resource utilisation
FRU_FLT Fault tolerance
FRU_PRS Priority of service
FRU_RSA Resource allocation
1
1
1
2
2
2
Figure 11.1 - Resource utilisation class decomposition
August 1999 Version 2.1
Page 149 of 354

11 - Class FRU: Resource utilisation Fault tolerance (FRU_FLT)
FRU_FLT
464
Fault tolerance
Family behaviour
The requirements of this family ensure that the TOE will maintain correct operation even in the event of failures.
Component levelling
FRU_FLT Fault tolerance 1 2
465
466
467
468
FRU_FLT.1 Degraded fault tolerance requires the TOE to continue correct operation of identified capabilities in the event of identified failures.
FRU_FLT.2 Limited fault tolerance requires the TOE to continue correct operation of all capabilities in the event of identified failures.
Management: FRU_FLT.1, FRU_FLT.2
There are no management activities foreseen.
Audit: FRU_FLT.1
The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST: a) Minimal: Any failure detected by the TSF.
469 b) Basic: All TOE capabilities being discontinued due to a failure.
Audit: FRU_FLT.2
The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST: a) Minimal: Any failure detected by the TSF.
FRU_FLT.1
Degraded fault tolerance
Hierarchical to: No other components.
FRU_FLT.1.1
The TSF shall ensure the operation of [assignment: list of TOE capabilities] when the following failures occur: [assignment: list of type of failures].
Dependencies: FPT_FLS.1 Failure with preservation of secure state
Page 150 of 354 Version 2.1
August 1999

Fault tolerance (FRU_FLT) 11 - Class FRU: Resource utilisation
FRU_FLT.2
Limited fault tolerance
Hierarchical to: FRU_FLT.1
FRU_FLT.2.1
The TSF shall ensure the operation of all the TOE’s capabilities when the following failures occur :[assignment: list of type of failures].
Dependencies: FPT_FLS.1 Failure with preservation of secure state
August 1999 Version 2.1
Page 151 of 354

11 - Class FRU: Resource utilisation Priority of service (FRU_PRS)
FRU_PRS
470
Priority of service
Family behaviour
The requirements of this family allow the TSF to control the use of resources within the TSC by users and subjects such that high priority activities within the TSC will always be accomplished without undue interference or delay caused by low priority activities.
Component levelling
FRU_PRS Priority of service 1 2
471
472
473
FRU_PRS.1 Limited priority of service provides priorities for a subject’s use of a subset of the resources within the TSC.
FRU_PRS.2 Full priority of service provides priorities for a subject’s use of all of the resources within the TSC.
Management: FRU_PRS.1, FRU_PRS.2
The following actions could be considered for the management activities in FMT: a) assignment of priorities to each subject in the TSF.
Audit: FRU_PRS.1, FRU_PRS.2
474 The following actions shall be auditable if FAU_GEN Security audit data generation is included in the PP/ST: a) Minimal: Rejection of operation based on the use of priority within an allocation.
b) Basic: All attempted uses of the allocation function which involves the priority of the service functions.
FRU_PRS.1
Limited priority of service
Hierarchical to: No other components.
FRU_PRS.1.1
The TSF shall assign a priority to each subject in the TSF.
FRU_PRS.1.2
The TSF shall ensure that each access to [assignment: controlled resources] shall be mediated on the basis of the subjects assigned priority.
Dependencies: No dependencies
Page 152 of 354 Version 2.1
August 1999

Priority of service (FRU_PRS) 11 - Class FRU: Resource utilisation
FRU_PRS.2
Full priority of service
Hierarchical to: FRU_PRS.1
FRU_PRS.2.1
The TSF shall assign a priority to each subject in the TSF.
FRU_PRS.2.2
The TSF shall ensure that each access to all shareable resources shall be mediated on the basis of the subjects assigned priority.
Dependencies: No dependencies
August 1999 Version 2.1
Page 153 of 354

11 - Class FRU: Resource utilisation Resource allocation (FRU_RSA)
476
477
FRU_RSA
475
478
479
480
Resource allocation
Family behaviour
The requirements of this family allow the TSF to control the use of resources by users and subjects such that denial of service will not occur because of unauthorised monopolisation of resources.
Component levelling
FRU_RSA Resource allocation 1 2
FRU_RSA.1 Maximum quotas provides requirements for quota mechanisms that ensure that users and subjects will not monopolise a controlled resource.
FRU_RSA.2 Minimum and maximum quotas provides requirements for quota mechanisms that ensure that users and subjects will always have at least a minimum of a specified resource and that they will not be able to monopolise a controlled resource.
Management: FRU_RSA.1
The following actions could be considered for the management activities in FMT: a) specifying maximum limits for a resource for groups and/or individual users and/or subjects by an administrator.
Management: FRU_RSA.2
The following actions could be considered for the management activities in FMT: a) specifying minimum and maximum limits for a resource for groups and/ or individual users and/or subjects by an administrator.
Audit: FRU_RSA.1, FRU_RSA.2
The following actions shall be auditable if FAU_GEN Security audit data generation is included in the PP/ST: a) Minimal: Rejection of allocation operation due to resource limits.
b) Basic: All attempted uses of the resource allocation functions for resources that are under control of the TSF.
Page 154 of 354 Version 2.1
August 1999

Resource allocation (FRU_RSA) 11 - Class FRU: Resource utilisation
FRU_RSA.1
Maximum quotas
Hierarchical to: No other components.
FRU_RSA.1.1
The TSF shall enforce maximum quotas of the following resources:
[assignment: controlled resources] that [selection: individual user, defined
group of users, subjects] can use [selection: simultaneously, over a specified
period of time].
Dependencies: No dependencies
FRU_RSA.2
Minimum and maximum quotas
Hierarchical to: FRU_RSA.1
FRU_RSA.2.1
The TSF shall enforce maximum quotas of the following resources [assignment:
controlled resources] that [selection: individual user, defined group of users] can use [selection: simultaneously, over a specified period of time].
FRU_RSA.2.2
The TSF shall ensure the provision of minimum quantity of each [assignment:
controlled resource] that is available for [selection: an individual user, defined
group of users, subjects] to use [selection: simultaneously, over a specified period
of time]
Dependencies: No dependencies
August 1999 Version 2.1
Page 155 of 354

11 - Class FRU: Resource utilisation Resource allocation (FRU_RSA)
Page 156 of 354 Version 2.1
August 1999

481
482
Class FTATOE access
This family specifies functional requirements for controlling the establishment of a user’s session.
Figure 12.1 shows the decomposition of this class into its constituent components.
TOE access
FTA_LSA Limitation on scope of selectable attributes
FTA_MCS Limitation on multiple concurrent sessions
FTA_SSL Session locking
FTA_TAB TOE access banners
FTA_TAH TOE access history
FTA_TSE TOE session establishment
1
1
1
2
3
1
Figure 12.1 - TOE access class decomposition
1
1 2
August 1999 Version 2.1
Page 157 of 354

12 - Class FTA: TOE access Limitation on scope of selectable attributes
(FTA_LSA)
FTA_LSA
483
Limitation on scope of selectable attributes
Family behaviour
This family defines requirements to limit the scope of session security attributes that a user may select for a session.
Component levelling
FTA_LSA Limitation on scope of selectable attributes 1
484
485
486
FTA_LSA.1 Limitation on scope of selectable attributes provides the requirement for a TOE to limit the scope of the session security attributes during session establishment.
Management: FTA_LSA.1
The following actions could be considered for the management activities in FMT: a) management of the scope of the session security attributes by an administrator.
Audit: FTA_LSA.1
The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST: a) Minimal: All failed attempts at selecting a session security attributes; b) Basic: All attempts at selecting a session security attributes; c) Detailed: Capture of the values of each session security attributes.
FTA_LSA.1
Limitation
Hierarchical to: No other components.
FTA_LSA.1.1
The TSF shall restrict the scope of the session security attributes [assignment:
session security attributes], based on [assignment: attributes].
Dependencies: No dependencies
Page 158 of 354 Version 2.1
August 1999

Limitation on multiple concurrent sessions (FTA_MCS)
12 - Class FTA: TOE access
488
489
FTA_MCS
487
490
491
492
Lim itation on multiple concurrent sessions
Family behaviour
This family defines requirements to place limits on the number of concurrent sessions that belong to the same user.
Component levelling
FTA_MCS Limitation on multiple concurrent sessions 1 2
FTA_MCS.1 Basic limitation on multiple concurrent sessions provides limitations that apply to all users of the TSF.
FTA_MCS.2 Per user attribute limitation on multiple concurrent sessions extends
FTA_MCS.1 by requiring the ability to specify limitations on the number of concurrent sessions based on the related security attributes.
Management: FTA_MCS.1
The following actions could be considered for the management activities in FMT: a) management of the maximum allowed number of concurrent user sessions by an administrator.
Management: FTA_MCS.2
The following actions could be considered for the management activities in FMT: a) management of the rules that govern the maximum allowed number of concurrent user sessions by an administrator.
Audit: FTA_MCS.1, FTA_MCS.2
The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST: a) Minimal: Rejection of a new session based on the limitation of multiple concurrent sessions.
b) Detailed: Capture of the number of currently concurrent user sessions and the user security attribute(s).
August 1999 Version 2.1
Page 159 of 354

12 - Class FTA: TOE access Limitation on multiple concurrent sessions
(FTA_MCS)
FTA_MCS.1
Basic limitation on multiple concurrent sessions
Hierarchical to: No other components.
FTA_MCS.1.1
The TSF shall restrict the maximum number of concurrent sessions that belong to the same user.
FTA_MCS.1.2
The TSF shall enforce, by default, a limit of [assignment: default number] sessions per user.
Dependencies: FIA_UID.1 Timing of identification
FTA_MCS.2
Per user attribute limitation on multiple concurrent sessions
Hierarchical to: FTA_MCS.1
FTA_MCS.2.1
The TSF shall restrict the maximum number of concurrent sessions that belong to the same user according to the rules [assignment: rules for the number of
maximum concurrent sessions].
FTA_MCS.2.2
The TSF shall enforce, by default, a limit of [assignment: default number] sessions per user.
Dependencies: FIA_UID.1 Timing of identification
Page 160 of 354 Version 2.1
August 1999

Session locking (FTA_SSL) 12 - Class FTA: TOE access
494
495
496
FTA_SSL
493
497
498
499
Session locking
Family behaviour
This family defines requirements for the TSF to provide the capability for TSFinitiated and user-initiated locking and unlocking of interactive sessions.
Component levelling
FTA_SSL Session locking
1
2
3
FTA_SSL.1 TSF-initiated session locking includes system initiated locking of an interactive session after a specified period of user inactivity.
FTA_SSL.2 User-initiated locking provides capabilities for the user to lock and unlock the user’s own interactive sessions.
FTA_SSL.3 TSF-initiated termination provides requirements for the TSF to terminate the session after a period of user inactivity.
Management: FTA_SSL.1
The following actions could be considered for the management activities in FMT: a) specification of the time of user inactivity after which lock-out occurs for an individual user; b) specification of the default time of user inactivity after which lock-out occurs; c) management of the events that should occur prior to unlocking the session.
Management: FTA_SSL.2
The following actions could be considered for the management activities in FMT: a) management of the events that should occur prior to unlocking the session.
Management: FTA_SSL.3
The following actions could be considered for the management activities in FMT:
August 1999 Version 2.1
Page 161 of 354

12 - Class FTA: TOE access Session locking (FTA_SSL)
500
501 a) specification of the time of user inactivity after which termination of the interactive session occurs for an individual user; b) specification of the default time of user inactivity after which termination of the interactive session occurs.
Audit: FTA_SSL.1, FTA_SSL.2
The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST: a) Minimal: Locking of an interactive session by the session locking mechanism.
b) Minimal: Successful unlocking of an interactive session.
c) Basic: Any attempts at unlocking an interactive session.
Audit: FTA_SSL.3
The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST: a) Minimal: Termination of an interactive session by the session locking mechanism.
FTA_SSL.1
TSF-initiated session locking
Hierarchical to: No other components.
FTA_SSL.1.1
FTA_SSL.1.2
The TSF shall lock an interactive session after [assignment: time interval of
user inactivity] by: a) clearing or overwriting display devices, making the current contents unreadable; b) disabling any activity of the user’s data access/display devices other than unlocking the session.
The TSF shall require the following events to occur prior to unlocking the session: [assignment: events to occur].
Dependencies: FIA_UAU.1 Timing of authentication
FTA_SSL.2
User-initiated locking
Hierarchical to: No other components.
FTA_SSL.2.1
The TSF shall allow user-initiated locking of the user’s own interactive session, by:
Page 162 of 354 Version 2.1
August 1999

Session locking (FTA_SSL) 12 - Class FTA: TOE access
FTA_SSL.2.2
a) clearing or overwriting display devices, making the current contents unreadable; b) disabling any activity of the user’s data access/display devices other than unlocking the session.
The TSF shall require the following events to occur prior to unlocking the session: [assignment: events to occur].
Dependencies: FIA_UAU.1 Timing of authentication
FTA_SSL.3
TSF-initiated termination
Hierarchical to: No other components.
FTA_SSL.3.1
The TSF shall terminate an interactive session after a [assignment: time
interval of user inactivity].
Dependencies: No dependencies
August 1999 Version 2.1
Page 163 of 354

12 - Class FTA: TOE access TOE access banners (FTA_TAB)
FTA_TAB
502
TOE access banners
Family behaviour
This family defines requirements to display a configurable advisory warning message to users regarding the appropriate use of the TOE.
Component levelling
FTA_TAB TOE access banners 1
503
504
FTA_TAB.1 Default TOE access banners provides the requirement for a TOE
Access Banner. This banner is displayed prior to the establishment dialogue for a session.
Management: FTA_TAB.1
The following actions could be considered for the management activities in FMT: a) maintenance of the banner by the authorised administrator.
505
Audit: FTA_TAB.1
There are no actions identified that should be auditable if FAU_GEN Security audit data generation is included in the PP/ST.
FTA_TAB.1
Default TOE access banners
Hierarchical to: No other components.
FTA_TAB.1.1
Before establishing a user session, the TSF shall display an advisory warning message regarding unauthorised use of the TOE.
Dependencies: No dependencies
Page 164 of 354 Version 2.1
August 1999

TOE access history (FTA_TAH) 12 - Class FTA: TOE access
FTA_TAH
506
TOE access history
Family behaviour
This family defines requirements for the TSF to display to a user, upon successful session establishment, a history of successful and unsuccessful attempts to access the user’s account.
Component levelling
FTA_TAH TOE access history 1
507
FTA_TAH.1 TOE access history provides the requirement for a TOE to display information related to previous attempts to establish a session.
Management: FTA_TAH.1
There are no management activities foreseen.
508
509
Audit: FTA_TAH.1
There are no actions identified that should be auditable if FAU_GEN Security audit data generation is included in the PP/ST.
FTA_TAH.1
TOE access history
Hierarchical to: No other components.
FTA_TAH.1.1
Upon successful session establishment, the TSF shall display the [selection:
date, time, method, location] of the last successful session establishment to the user.
FTA_TAH.1.2
Upon successful session establishment, the TSF shall display the [selection:
date, time, method, location] of the last unsuccessful attempt to session establishment and the number of unsuccessful attempts since the last successful session establishment.
FTA_TAH.1.3
The TSF shall not erase the access history information from the user interface without giving the user an opportunity to review the information.
Dependencies: No dependencies
August 1999 Version 2.1
Page 165 of 354

12 - Class FTA: TOE access TOE session establishment (FTA_TSE)
FTA_TSE
510
TOE session establishment
Family behaviour
This family defines requirements to deny a user permission to establish a session with the TOE.
Component levelling
FTA_TSE TOE session establishment 1
511
512
513
FTA_TSE.1 TOE session establishment provides requirements for denying users access to the TOE based on attributes.
Management: FTA_TSE.1
The following actions could be considered for the management activities in FMT: a) management of the session establishment conditions by the authorised administrator.
Audit: FTA_TSE.1
The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST: a) Minimal: Denial of a session establishment due to the session establishment mechanism.
b) Basic: All attempts at establishment of a user session.
c) Detailed: Capture of the value of the selected access parameters (e.g.
location of access, time of access).
FTA_TSE.1
TOE session establishment
Hierarchical to: No other components.
FTA_TSE.1.1
The TSF shall be able to deny session establishment based on [assignment:
attributes].
Dependencies: No dependencies
Page 166 of 354 Version 2.1
August 1999

514
515
516
517
Class FTPTrusted path/channels
-
-
Families in this class provide requirements for a trusted communication path between users and the TSF, and for a trusted communication channel between the
TSF and other trusted IT products. Trusted paths and channels have the following general characteristics:
The communications path is constructed using internal and external communications channels (as appropriate for the component) that isolate an identified subset of TSF data and commands from the remainder of the TSF and user data.
Use of the communications path may be initiated by the user and/or the TSF
(as appropriate for the component)
The communications path is capable of providing assurance that the user is communicating with the correct TSF, and that the TSF is communicating with the correct user (as appropriate for the component)
In this paradigm, a trusted channel is a communication channel that may be initiated by either side of the channel, and provides non-repudiation characteristics with respect to the identity of the sides of the channel.
A trusted path provides a means for users to perform functions through an assured direct interaction with the TSF. Trusted path is usually desired for user actions such as initial identification and/or authentication, but may also be desired at other times during a user’s session. Trusted path exchanges may be initiated by a user or the
TSF. User responses via the trusted path are guaranteed to be protected from modification by or disclosure to untrusted applications.
Figure 13.1 shows the decomposition of this class into its constituent components.
Trusted path/channels
FTP_ITC Inter-TSF trusted channel
FTP_TRP Trusted path
1
1
Figure 13.1 - Trusted path/channels class decomposition
August 1999 Version 2.1
Page 167 of 354

13 - Class FTP: Trusted path/channels Inter-TSF trusted channel (FTP_ITC)
FTP_ITC
518
Inter-TSF trusted channel
Family behaviour
This family defines requirements for the creation of a trusted channel between the
TSF and other trusted IT products for the performance of security critical operations. This family should be included whenever there are requirements for the secure communication of user or TSF data between the TOE and other trusted IT products.
Component levelling
FTP_ITC Inter-TSF trusted channel 1
519
520
521
FTP_ITC.1 Inter-TSF trusted channel requires that the TSF provide a trusted communication channel between itself and another trusted IT product.
Management: FTP_ITC.1
The following actions could be considered for the management functions in FMT: c) d) a) Configuring the actions that require trusted channel, if supported.
Audit: FTP_ITC.1
a) b)
The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST:
Minimal: Failure of the trusted channel functions.
Minimal: Identification of the initiator and target of failed trusted channel functions.
Basic: All attempted uses of the trusted channel functions.
Basic: Identification of the initiator and target of all trusted channel functions.
FTP_ITC.1
Inter-TSF trusted channel
Hierarchical to: No other components.
FTP_ITC.1.1
The TSF shall provide a communication channel between itself and a remote trusted IT product that is logically distinct from other communication channels and provides assured identification of its end points and protection of the channel data from modification or disclosure.
Page 168 of 354 Version 2.1
August 1999

Inter-TSF trusted channel (FTP_ITC) 13 - Class FTP: Trusted path/channels
FTP_ITC.1.2
FTP_ITC.1.3
The TSF shall permit [selection: the TSF, the remote trusted IT product] to initiate communication via the trusted channel.
The TSF shall initiate communication via the trusted channel for [assignment:
list of functions for which a trusted channel is required].
Dependencies: No dependencies
August 1999 Version 2.1
Page 169 of 354

13 - Class FTP: Trusted path/channels Trusted path (FTP_TRP)
FTP_TRP
522
Trusted path
Family behaviour
This family defines the requirements to establish and maintain trusted communication to or from users and the TSF. A trusted path may be required for any security-relevant interaction. Trusted path exchanges may be initiated by a user during an interaction with the TSF, or the TSF may establish communication with the user via a trusted path.
Component levelling
FTP_TRP Trusted path 1
523
524
525
FTP_TRP.1 Trusted path requires that a trusted path between the TSF and a user be provided for a set of events defined by a PP/ST author. The user and/or the TSF may have the ability to initiate the trusted path.
Management: FTP_TRP.1
c) d)
The following actions could be considered for the management functions in FMT: a) Configuring the actions that require trusted path, if supported.
a) b)
Audit: FTP_TRP.1
The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP / ST:
Minimal: Failures of the trusted path functions.
Minimal: Identification of the user associated with all trusted path failures, if available.
Basic: All attempted uses of the trusted path functions.
Basic: Identification of the user associated with all trusted path invocations, if available.
FTP_TRP.1
Trusted path
Hierarchical to: No other components.
FTP_TRP.1.1
The TSF shall provide a communication path between itself and [selection:
remote, local] users that is logically distinct from other communication paths
Page 170 of 354 Version 2.1
August 1999

Trusted path (FTP_TRP) 13 - Class FTP: Trusted path/channels and provides assured identification of its end points and protection of the communicated data from modification or disclosure.
FTP_TRP.1.2
The TSF shall permit [selection: the TSF, local users, remote users] to initiate communication via the trusted path.
FTP_TRP.1.3
The TSF shall require the use of the trusted path for [selection: initial user
authentication, [assignment: other services for which trusted path is required]].
Dependencies: No dependencies
August 1999 Version 2.1
Page 171 of 354

13 - Class FTP: Trusted path/channels Trusted path (FTP_TRP)
Page 172 of 354 Version 2.1
August 1999

Structure of the notes
527
A.1.1
528
526
A.1.1.1
529
This annex contains informative guidance for the families and components defined in the normative elements of this CC Part 2, which may be required by users, developers or evaluators to use the components. To facilitate finding the appropriate information, the presentation of the classes, families and components in this annex is similar to the presentation within the normative elements. The class, family, and component structures in this annex differ from those found in the main body of this part of the CC, as this annex is concerned with only those sections that are informative.
This clause defines the content and presentation of the notes related to functional requirements of the CC.
Class structure
Figure A.1 below illustrates the functional class structure in this annex.
Functional
Class
Class
Name
Class
Introduction
Key
The Functional Class can contain multiple
Functional Families.
Functional
Families
Figure A.1 - Functional class structure
Class name
This is the unique name of the class defined within the normative elements of this part of the CC.
August 1999 Version 2.1
Page 173 of 354

A - Security functional requirements application notes Structure of the notes
A.1.1.2
530
A.1.2
531
Class introduction
The class introduction in this annex provides information about the use of the families and components of the class. This information is completed with the informative diagram that describes the organisation of each class with the families in each class and the hierarchical relationship between components in each family.
Family structure
Figure A.2 illustrates the functional family structure for application notes in diagrammatic form.
A.1.2.1
532
A.1.2.2
533
A.1.2.3
534
Page 174 of 354
Functional
Family
Key
The Functional Family can contain multiple
Components.
Family name
User notes
Evaluator notes
Components
Figure A.2 - Functional family structure for application notes
Family name
This is the unique name of the family defined within the normative elements of this part of the CC.
User notes
The user notes contain additional information that is of interest to potential users of the family, that is PP, ST and functional package authors, and developers of TOEs incorporating the functional components. The presentation is informative, and might cover warnings about limitations of use and areas where specific attention might be required when using the components.
Evaluator notes
The evaluator notes contain any information that is of interest to developers and evaluators of TOEs that claim compliance with a component of the family. The presentation is informative and can cover a variety of areas where specific attention might be needed when evaluating the TOE. This can include clarifications of meaning and specification of the way to interpret requirements, as well as caveats and warnings of specific interest to evaluators.
Version 2.1
August 1999

Structure of the notes A - Security functional requirements application notes
535
A.1.3
536
These User Notes and Evaluator Notes sections are not mandatory and appear only if appropriate.
Component structure
Figure A.3 illustrates the functional component structure for the application notes.
A.1.3.1
537
A.1.3.2
538
539
A.1.3.3
540
541
Component
Component
Identification
Component
Rationale &
Application notes
Permitted
Operations
Figure A.3 - Functional component structure
Component identification
This is the unique name of the component defined within the normative elements of this part of the CC.
Component rationale and application notes
-
Any specific information related to the component can be found in this section.
The rationale contains the specifics of the rationale that refine the general statements on rationale for the specific level, and should only be used if level specific amplification is required.
The application notes contain additional refinement in terms of narrative qualification as it pertains to a specific component. This refinement can pertain to user notes, and/or evaluator notes as described in Subclause A.1.2.
This refinement can be used to explain the nature of the dependencies (e.g.
shared information, or shared operation).
This section is not mandatory and appears only if appropriate.
Permitted operations
This portion of each component contains advice relating to the permitted operations of the component.
This section is not mandatory and appears only if appropriate.
August 1999 Version 2.1
Page 175 of 354

A - Security functional requirements application notes Dependency table
542
Table A.1 - Dependency table for functional components, shows their direct, indirect and optional dependencies. Each of the components that is a dependency of some functional component is allocated a column. Each functional component is allocated a row. The value in the table cell indicate whether the column label component is directly required (indicated by a cross ‘X’), indirectly required
(indicated by a dash ‘-’), or optionally required (indicated by a ‘o’) by the row label component. An example of a component with optional dependencies is
FDP_ETC.1, which requires either FDP_ACC.1 or FDP_IFC.1 to be present. So if
FDP_ACC.1 is present, FDP_IFC.1 is not necessary and vice versa. If no character is presented, the component is not dependent upon another component.
Table A.1 - Dependency table for functional components
.
1
A
D
M
A
G
D
_
.
1
S
P
M
A
D
V
_
.
1
C
C
A
A
V
A
_
.
1
G
E
N
F
A
U
_
.
3
C
C
A
A
V
A
_
.
1
S
A
R
F
A
U
_
.
1
S
A
A
F
A
U
_
.
1
S
T
G
F
A
U
_
.
2
C
K
M
F
C
S
_
.
1
C
K
M
F
C
S
_
.
4
C
K
M
F
C
S
_
.
1
C
O
P
F
C
S
_
.
1
A
C
F
F
D
P
_
.
1
A
C
C
F
D
P
_
I
F
F
.
1
F
D
P
_
.
1
I
F
C
F
D
P
_
I
T
T
.
1
F
D
P
_
.
1
I
T
C
F
D
P
_
.
1
I
U
T
F
D
P
_
I
T
T
.
2
F
D
P
_
.
1
U
A
U
F
I
A
_
.
1
A
T
D
F
I
A
_
.
1
I
U
D
F
I
A
_
.
1
M
O
F
F
M
T
_
.
2
M
S
A
F
M
T
_
.
1
M
S
A
F
M
T
_
.
1
M
T
D
F
M
T
_
.
3
M
S
A
F
M
T
_
.
1
U
N
O
F
P
R
_
.
1
S
M
R
F
M
T
_
F
L
S
.
1
F
P
T
_
.
1
A
M
T
F
P
T
_
I
T
T
.
1
F
P
T
_
.
1
T
D
C
F
P
T
_
.
1
S
T
M
F
P
T
_
T
S
T
.
1
F
P
T
_
.
1
T
R
P
F
T
P
_
.
1
I
T
C
F
T
P
_
FAU_ARP.1 - x
FAU_GEN.1
FAU_GEN.2
FAU_SAA.1 x x x
-
-
x
FAU_SAA.2
FAU_SAA.3 x
FAU_SAA.4
FAU_SAR.1
FAU_SAR.2
FAU_SAR.3
FAU_SEL.1
FAU_STG.1
FAU_STG.2
FAU_STG.3 x x x x
x
x x
x -
-
-
-
-
-
-
-
Page 176 of 354 Version 2.1
August 1999

Dependency table A - Security functional requirements application notes
Table A.1 - Dependency table for functional components
.
1
A
D
M
A
G
D
_
.
1
S
P
M
A
D
V
_
.
1
C
C
A
A
V
A
_
.
1
G
E
N
F
A
U
_
.
3
C
C
A
A
V
A
_
.
1
S
A
R
F
A
U
_
.
1
S
A
A
F
A
U
_
.
1
S
T
G
F
A
U
_
.
2
C
K
M
F
C
S
_
.
1
C
K
M
F
C
S
_
.
1
C
O
P
F
C
S
_
.
4
C
K
M
F
C
S
_
.
1
A
C
C
F
D
P
_
.
1
I
F
C
F
D
P
_
.
1
A
C
F
F
D
P
_
I
T
.
C
1
F
D
P
_
.
F
I
F
1
F
D
P
_
.
T
I
T
2
F
D
P
_
.
T
I
T
1
F
D
P
_
.
T
I
U
1
F
D
P
_
U
A
.
U
1
F
I
A
_
A
T
.
D
1
F
I
A
_
I
U
.
D
1
F
I
A
_
M
S
.
A
1
F
M
T
_
.
F
M
O
1
F
M
T
_
M
S
.
A
2
F
M
T
_
M
T
.
D
1
F
M
T
_
M
S
.
A
3
F
M
T
_
U
N
.
O
1
F
P
R
_
S
M
.
R
1
F
M
T
_
.
S
F
L
1
F
P
T
_
.
T
A
M
1
F
P
T
_
.
T
I
T
1
F
P
T
_
T
D
.
C
1
F
P
T
_
S
T
.
M
1
F
P
T
_
.
T
T
S
1
F
P
T
_
.
P
T
R
1
F
T
P
_
I
T
.
C
1
F
T
P
_
FAU_STG.4 x -
FCO_NRO.1
FCO_NRO.2
FCO_NRR.1
FCO_NRR.2
FCS_CKM.1
FCS_CKM.2
FCS_CKM.3
FCS_CKM.4
FCS_COP.1
-
-
-
-
-
- o x o - - - - o - x - - - - - o o - x - - - - - o o - - - - - - - o o - x - - - - - o
-
-
x x x x
- x -
- x -
- x -
- x -
- x -
-
-
FDP_ACC.1
FDP_ACC.2
FDP_ACF.1
- x - -
- x - x - - -
-
-
x -
FDP_DAU.1
FDP_DAU.2
FDP_ETC.1
FDP_ETC.2
FDP_IFC.1
FDP_IFC.2
FDP_IFF.1
FDP_IFF.2
FDP_IFF.3
FDP_IFF.4 x x o - o o - o -
- - - x
- - - x
- - x -
- - x -
- - x -
- - x x
-
-
-
-
x -
x -
-
-
August 1999 Version 2.1
Page 177 of 354

A - Security functional requirements application notes Dependency table
Table A.1 - Dependency table for functional components
FDP_RIP.2
FDP_ROL.1
FDP_ROL.2
FDP_SDI.1
FDP_SDI.2
FDP_UCT.1
FDP_UIT.1
FDP_UIT.2
FDP_UIT.3
FIA_AFL.1
FIA_ATD.1
FIA_SOS.1
FIA_SOS.2
FIA_UAU.1
.
1
A
D
M
A
G
D
_
.
1
S
P
M
A
D
V
_
.
1
C
C
A
A
V
A
_
.
1
G
E
N
F
A
U
_
.
3
C
C
A
A
V
A
_
.
1
S
A
R
F
A
U
_
.
1
S
A
A
F
A
U
_
.
1
S
T
G
F
A
U
_
.
2
C
K
M
F
C
S
_
.
1
C
K
M
F
C
S
_
.
4
C
K
M
F
C
S
_
.
1
C
O
P
F
C
S
_
.
1
A
C
F
F
D
P
_
.
1
A
C
C
F
D
P
_
.
F
I
F
1
F
D
P
_
.
1
I
F
C
F
D
P
_
.
T
I
T
1
F
D
P
_
I
T
.
C
1
F
D
P
_
.
T
I
U
1
F
D
P
_
.
T
I
T
2
F
D
P
_
U
A
.
U
1
F
I
A
_
A
T
.
D
1
F
I
A
_
I
U
.
D
1
F
I
A
_
.
F
M
O
1
F
M
T
_
M
S
.
A
2
F
M
T
_
M
S
.
A
1
F
M
T
_
M
T
.
D
1
F
M
T
_
M
S
.
A
3
F
M
T
_
U
N
.
O
1
F
P
R
_
S
M
.
R
1
F
M
T
_
.
S
F
L
1
F
P
T
_
.
T
A
M
1
F
P
T
_
.
T
I
T
1
F
P
T
_
T
D
.
C
1
F
P
T
_
S
T
.
M
1
F
P
T
_
.
T
T
S
1
F
P
T
_
.
P
T
R
1
F
T
P
_
I
T
.
C
1
F
T
P
_
FDP_IFF.5 x - - x -
FDP_IFF.6 x
FDP_ITC.1
FDP_ITC.2
FDP_ITT.1
FDP_ITT.2
FDP_ITT.3
FDP_ITT.4
- - x o - o o - o o - o o - o o - o x o - o x
-
x -
-
-
-
-
x o
FDP_RIP.1 o - o o - o o - o o - o o - o o - o x x x -
-
-
x
-
-
-
-
-
-
-
-
-
-
-
o o o o x x
Page 178 of 354 Version 2.1
August 1999

Dependency table A - Security functional requirements application notes
Table A.1 - Dependency table for functional components
.
1
A
D
M
A
G
D
_
.
1
S
P
M
A
D
V
_
.
1
C
C
A
A
V
A
_
.
1
G
E
N
F
A
U
_
.
3
C
C
A
A
V
A
_
.
1
S
A
R
F
A
U
_
.
1
S
A
A
F
A
U
_
.
1
S
T
G
F
A
U
_
.
2
C
K
M
F
C
S
_
.
1
C
K
M
F
C
S
_
.
1
C
O
P
F
C
S
_
.
4
C
K
M
F
C
S
_
.
1
A
C
C
F
D
P
_
.
1
I
F
C
F
D
P
_
.
1
A
C
F
F
D
P
_
I
T
.
C
1
F
D
P
_
.
F
I
F
1
F
D
P
_
.
T
I
T
2
F
D
P
_
.
T
I
T
1
F
D
P
_
.
T
I
U
1
F
D
P
_
U
A
.
U
1
F
I
A
_
A
T
.
D
1
F
I
A
_
I
U
.
D
1
F
I
A
_
M
S
.
A
1
F
M
T
_
.
F
M
O
1
F
M
T
_
M
S
.
A
2
F
M
T
_
M
T
.
D
1
F
M
T
_
M
S
.
A
3
F
M
T
_
U
N
.
O
1
F
P
R
_
S
M
.
R
1
F
M
T
_
.
S
F
L
1
F
P
T
_
.
T
A
M
1
F
P
T
_
.
T
I
T
1
F
P
T
_
T
D
.
C
1
F
P
T
_
S
T
.
M
1
F
P
T
_
.
T
T
S
1
F
P
T
_
.
P
T
R
1
F
T
P
_
I
T
.
C
1
F
T
P
_
FIA_UAU.2 x
FIA_UAU.3
FIA_UAU.4
FIA_UAU.5
FIA_UAU.6
FIA_UAU.7
FIA_UID.1
FIA_UID.2
FIA_USB.1
FMT_MOF.1
FMT_MSA.1
FMT_MSA.2
FMT_MSA.3
FMT_MTD.1
FMT_MTD.2
FMT_MTD.3
FMT_REV.1
FMT_SAE.1
FMT_SMR.1
FMT_SMR.2
FMT_SMR.3
FPR_ANO.1
FPR_ANO.2 x x o - o o - o -
- - - x x -
-
-
-
-
-
x x x
x
x x
-
x x x x x x x x x
August 1999 Version 2.1
Page 179 of 354

A - Security functional requirements application notes Dependency table
Table A.1 - Dependency table for functional components
FPR_UNO.1
FPR_UNO.2
FPR_UNO.3
FPR_UNO.4
FPT_AMT.1
FPT_FLS.1
FPT_ITA.1
FPT_ITC.1
FPT_ITI.1
FPT_ITI.2
FPT_ITT.1
FPT_ITT.2
FPT_ITT.3
FPT_PHP.1
FPT_PHP.2
FPT_PHP.3
FPT_RCV.1
FPT_RCV.2
FPT_RCV.3
.
1
A
D
M
A
G
D
_
.
1
S
P
M
A
D
V
_
.
1
C
C
A
A
V
A
_
.
1
G
E
N
F
A
U
_
.
3
C
C
A
A
V
A
_
.
1
S
A
R
F
A
U
_
.
1
S
A
A
F
A
U
_
.
1
S
T
G
F
A
U
_
.
2
C
K
M
F
C
S
_
.
1
C
K
M
F
C
S
_
.
4
C
K
M
F
C
S
_
.
1
C
O
P
F
C
S
_
.
1
A
C
F
F
D
P
_
.
1
A
C
C
F
D
P
_
.
F
I
F
1
F
D
P
_
.
1
I
F
C
F
D
P
_
.
T
I
T
1
F
D
P
_
I
T
.
C
1
F
D
P
_
.
T
I
U
1
F
D
P
_
.
T
I
T
2
F
D
P
_
U
A
.
U
1
F
I
A
_
A
T
.
D
1
F
I
A
_
I
U
.
D
1
F
I
A
_
.
F
M
O
1
F
M
T
_
M
S
.
A
2
F
M
T
_
M
S
.
A
1
F
M
T
_
M
T
.
D
1
F
M
T
_
M
S
.
A
3
F
M
T
_
U
N
.
O
1
F
P
R
_
S
M
.
R
1
F
M
T
_
.
S
F
L
1
F
P
T
_
.
T
A
M
1
F
P
T
_
.
T
I
T
1
F
P
T
_
T
D
.
C
1
F
P
T
_
S
T
.
M
1
F
P
T
_
.
T
T
S
1
F
P
T
_
.
P
T
R
1
F
T
P
_
I
T
.
C
1
F
T
P
_
FPR_PSE.1
FPR_PSE.2
FPR_PSE.3
FPR_UNL.1 x x x x x x x x
- x
- x
-
x
-
-
x x x x
Page 180 of 354 Version 2.1
August 1999

Dependency table A - Security functional requirements application notes
Table A.1 - Dependency table for functional components
FPT_SEP.2
FPT_SEP.3
FPT_SSP.1
FPT_SSP.2
FPT_STM.1
FPT_TDC.1
FPT_TRC.1
FPT_TST.1
FRU_FLT.1
FRU_FLT.2
FRU_PRS.1
FRU_PRS.2
FRU_RSA.1
FRU_RSA.2
FTA_LSA.1
FTA_MCS.1
FTA_MCS.2
FTA_SSL.1
FTA_SSL.2
.
1
A
D
M
A
G
D
_
.
1
S
P
M
A
D
V
_
.
1
C
C
A
A
V
A
_
.
1
G
E
N
F
A
U
_
.
3
C
C
A
A
V
A
_
.
1
S
A
R
F
A
U
_
.
1
S
A
A
F
A
U
_
.
1
S
T
G
F
A
U
_
.
2
C
K
M
F
C
S
_
.
1
C
K
M
F
C
S
_
.
1
C
O
P
F
C
S
_
.
4
C
K
M
F
C
S
_
.
1
A
C
C
F
D
P
_
.
1
I
F
C
F
D
P
_
.
1
A
C
F
F
D
P
_
I
T
.
C
1
F
D
P
_
.
F
I
F
1
F
D
P
_
.
T
I
T
2
F
D
P
_
.
T
I
T
1
F
D
P
_
.
T
I
U
1
F
D
P
_
U
A
.
U
1
F
I
A
_
A
T
.
D
1
F
I
A
_
I
U
.
D
1
F
I
A
_
M
S
.
A
1
F
M
T
_
.
F
M
O
1
F
M
T
_
M
S
.
A
2
F
M
T
_
M
T
.
D
1
F
M
T
_
M
S
.
A
3
F
M
T
_
U
N
.
O
1
F
P
R
_
S
M
.
R
1
F
M
T
_
.
S
F
L
1
F
P
T
_
.
T
A
M
1
F
P
T
_
.
T
I
T
1
F
P
T
_
T
D
.
C
1
F
P
T
_
S
T
.
M
1
F
P
T
_
.
T
T
S
1
F
P
T
_
.
P
T
R
1
F
T
P
_
I
T
.
C
1
F
T
P
_
FPT_RCV.4 x
FPT_RPL.1
FPT_RVM.1
FPT_SEP.1
-
x x x x x x x x x x
August 1999 Version 2.1
Page 181 of 354

A - Security functional requirements application notes Dependency table
Table A.1 - Dependency table for functional components
.
1
A
D
M
A
G
D
_
.
1
S
P
M
A
D
V
_
.
1
C
C
A
A
V
A
_
.
1
G
E
N
F
A
U
_
.
3
C
C
A
A
V
A
_
.
1
S
A
R
F
A
U
_
.
1
S
A
A
F
A
U
_
.
1
S
T
G
F
A
U
_
.
2
C
K
M
F
C
S
_
.
1
C
K
M
F
C
S
_
.
4
C
K
M
F
C
S
_
.
1
C
O
P
F
C
S
_
.
1
A
C
F
F
D
P
_
.
1
A
C
C
F
D
P
_
.
F
I
F
1
F
D
P
_
.
1
I
F
C
F
D
P
_
.
T
I
T
1
F
D
P
_
I
T
.
C
1
F
D
P
_
.
T
I
U
1
F
D
P
_
.
T
I
T
2
F
D
P
_
U
A
.
U
1
F
I
A
_
A
T
.
D
1
F
I
A
_
I
U
.
D
1
F
I
A
_
.
F
M
O
1
F
M
T
_
M
S
.
A
2
F
M
T
_
M
S
.
A
1
F
M
T
_
M
T
.
D
1
F
M
T
_
M
S
.
A
3
F
M
T
_
U
N
.
O
1
F
P
R
_
S
M
.
R
1
F
M
T
_
.
S
F
L
1
F
P
T
_
.
T
A
M
1
F
P
T
_
.
T
I
T
1
F
P
T
_
T
D
.
C
1
F
P
T
_
S
T
.
M
1
F
P
T
_
.
T
T
S
1
F
P
T
_
.
P
T
R
1
F
T
P
_
I
T
.
C
1
F
T
P
_
FTA_SSL.3
FTA_TAB.1
FTA_TAH.1
FTA_TSE.1
FTP_ITC.1
FTP_TRP.1
Page 182 of 354 Version 2.1
August 1999

543
The following annexes C through M provide the application notes for the functional classes defined in the main body of this part of the CC.
August 1999 Version 2.1
Page 183 of 354

B - Functional classes, families, and components
Page 184 of 354 Version 2.1
August 1999

544
545
546
547
548
549
550
August 1999
Class FIASecurity audit
CC audit families allow PP/ST authors the ability to define requirements for monitoring user activities and, in some cases, detecting real, potential, or imminent violations of the TSP. The TOE’s security audit functions are defined to help monitor security-relevant events, and act as a deterrent against security violations.
The requirements of the audit families refer to functions that include audit data protection, record format, and event selection, as well as analysis tools, violation alarms, and real-time analysis. The audit trail should be presented in humanreadable format either directly (e.g. storing the audit trail in human-readable format) or indirectly (e.g. using audit reduction tools), or both.
While developing the security audit requirements, the PP/ST author should take note of the inter-relationships among the audit families and components. The potential exists to specify a set of audit requirements that comply with the family/ component dependencies lists, while at the same time resulting in a deficient audit function (e.g. an audit function that requires all security relevant events to be audited but without the selectivity to control them on any reasonable basis such as individual user or object).
Audit requirements in a distributed environment:
The implementation of audit requirements for networks and other large systems may differ significantly from those needed for stand-alone systems. Larger, more complex and active systems require more thought concerning which audit data to collect and how this should be managed, due to lowered feasibility of interpreting
(or even storing) what gets collected. The traditional notion of a time-sorted list or
“trail” of audited events may not be applicable in a global asynchronous network with arbitrarily many events occurring at once.
Also, different hosts and servers on a distributed TOE may have differing naming policies and values. Symbolic names presentation for audit review may require a net-wide convention to avoid redundancies and “name clashes.”
A multi-object audit repository, portions of which are accessible by a potentially wide variety of authorised users, may be required if audit repositories are to serve a useful function in distributed systems.
Finally, misuse of authority by authorised users should be addressed by systematically avoiding local storage of audit data pertaining to administrator actions.
Figure C.1 shows the decomposition of this class into its constituent components.
Version 2.1
Page 185 of 354

C - Security audit (FAU)
Security audit
FAU_ARP Security audit automatic response
FAU_GEN Security audit data generation
FAU_SAA Security audit analysis
FAU_SAR Security audit review
FAU_SEL Security audit event selection
FAU_STG Security audit event storage
1
2
3
1
1
2
1
2
3 4
1
1
3
2
4
Figure C.1 - Security audit class decomposition
Page 186 of 354 2.1
August 1999

Security audit automatic response (FAU_ARP) C - Security audit (FAU)
FIA_ITC
551
Security audit automatic response
The Security audit automatic response family describes requirements for the handling of audit events. The requirement could include requirements for alarms or
TSF action (automatic response). For example, the TSF could include the generation of real time alarms, termination of the offending process, disabling of a service, or disconnection or invalidation of a user account.
552
554
Application notes
An audit event is defined to be an “potential security violation” if so indicated by the FAU_SAA components.
FAU_ARP.1
Security alarms
User application notes
553 An action should be taken for follow up action in the event of an alarm. This action can be to inform the authorised user, to present the authorised user with a set of possible containment actions, or to take corrective actions. The timing of the actions should be carefully considered by the PP/ST author.
Operations
Assignment:
In FAU_ARP.1.1 the PP/ST author should specify the actions to be taken in case of a potential security violation. An example of such a list is: “inform the authorised user, disable the subject that created the potential security violation.” It can also specify that the action to be taken can be specified by an authorised user.
August 1999 Version 2.1
Page 187 of 354

C - Security audit (FAU) Security audit data generation (FAU_GEN)
FAUARP_ITC
555
556
557
558
559
560
Security audit data generation
The Security audit data generation family includes requirements to specify the audit events that should be generated by the TSF for security-relevant events.
This family is presented in a manner that avoids a dependency on all components requiring audit support. Each component has an audit section developed in which the events to be audited for that functional area are listed. When the PP/ST author assembles the PP/ST, the items in the audit area are used to complete the variable in this component. Thus, the specification of what could be audited for a functional area is localised in that functional area.
The list of auditable events is entirely dependent on the other functional families within the PP/ST. Each family definition should therefore include a list of its family-specific auditable events. Each auditable event in the list of auditable events specified in the functional family should correspond to one of the levels of audit event generation specified in this family (i.e. minimal, basic, detailed). This provides the PP/ST author with information necessary to ensure that all appropriate auditable events are specified in the PP/ST. The following example shows how auditable events are to be specified in appropriate functional families:
“The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST: a) Minimal: Successful use of the user security attribute administration functions; b) Basic: All attempted uses of the user security attribute administration functions;
Basic: Identification of which user security attributes have been modified; c) d) Detailed: With the exception of specific sensitive attribute data items (e.g.
passwords, cryptographic keys), the new values of the attributes should be captured.”
For each functional component that is chosen, the auditable events that are indicated in that component, at and below the level indicated in FAU_GEN should be auditable. If, for example, in the previous example ‘Basic’ would be selected in
FAU_GEN, the auditable events mentioned in a), b) and c) should be auditable.
Observe that the categorisation of auditable events is hierarchical. For example, when Basic Audit Generation is desired, all auditable events identified as being either Minimal or Basic, should also 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.
Page 188 of 354 Version 2.1
August 1999

Security audit data generation (FAU_GEN) C - Security audit (FAU)
561
562
563
A PP/ST author may decide to include other auditable events beyond those required for a given audit level. For example, the PP/ST may claim only minimal audit capabilities while including most of the basic capabilities because the few excluded capabilities conflict with other PP/ST constraints (e.g. because they require the collection of unavailable data).
Application notes
The functionality that creates the auditable event should be specified in the PP or
ST as a functional requirement.
e) f) c) d)
The following are examples of the types of the events that should be defined as auditable within each PP/ST functional component: a) b)
Introduction of objects within the TSC into a subject’s address space;
Deletion of objects;
Distribution or revocation of access rights or capabilities;
Changes to subject or object security attributes;
Policy checks performed by the TSF as a result of a request by a subject;
The use of access rights to bypass a policy check; g) h) i)
Use of Identification and Authentication functions;
Actions taken by an operator, and/or authorised user (e.g. suppression of a
TSF protection mechanism as human-readable labels);
Import/export of data from/to removable media (e.g. printed output, tapes, diskettes).
FAU_GEN.1
Audit data generation
User application notes
564
This component defines requirements to identify the auditable events for which audit records should be generated, and the information to be provided in the audit records.
565 FAU_GEN.1 by itself might be used when the TSP does not require that individual user identities be associated with audit events. This could be appropriate when the
PP/ST also contains privacy requirements. If the user identity must be incorporated
FAU_GEN.2 could be used in addition.
August 1999 Version 2.1
Page 189 of 354

C - Security audit (FAU) Security audit data generation (FAU_GEN)
566
567
568
569
Evaluator application notes
There is a dependency on FPT_STM. If correctness of time is not an issue for this
TOE, elimination of this dependency could be justified.
Operations
Selection:
For FAU_GEN.1.1b, the PP/ST author should select the level of auditable events called out in the audit section of other functional components included in the PP/ST. This level could be ‘minimum’,
‘basic’, ‘detailed’ or ‘not specified’. If ‘not specified’ is selected, the PP/
ST author should fill in all desired auditable events in FAU_GEN.1.1c, and this part of the element (item b) can be removed entirely.
Assignment:
For FAU_GEN.1.1c, the PP/ST author should assign a list of other specifically defined auditable events to be included in the list of auditable events. These events could be auditable events of a functional requirement that are of higher audit level than requested in
FAU_GEN.1.1b, as well as the events generated through the use of a specified Application Programming Interface (API).
For FAU_GEN.1.2b, the PP/ST author should assign, for each auditable events included in the PP/ST, a list of other audit relevant information to be included in audit event records.
FAU_GEN.2
User identity association
User application notes
570
571
This component addresses the requirement of accountability of auditable events at the level of individual user identity. This component should be used in addition to
FAU_GEN.1 Audit data generation.
There is a potential conflict between the audit and privacy requirements. For audit purposes it may be desirable to know who performed an action. The user may want to keep his/her actions to himself/herself and not be identified by other persons (e.g.
a site with job offers). Or it might be required in the Organisational Security Policy that the identity of the users must be protected. In those cases the objectives for audit and privacy might contradict each other. Therefore if this requirement is selected and privacy is important, inclusion of the component user pseudonimity might be considered. Requirements on determining the real user name based on its pseudonym are specified in the privacy class.
Page 190 of 354 Version 2.1
August 1999

Security audit analysis (FAU_SAA) C - Security audit (FAU)
FAU_SAA
572
Security audit analysis
This family defines requirements for automated means that analyse system activity and audit data looking for possible or real security violations. This analysis may work in support of intrusion detection, or automatic response to an imminent security violation.
573
574
The action to be performed by the TSF on detection of a possible imminent or potential violation is defined in FAU_ARP Security audit automatic response components.
Application notes
For real-time analysis, audit data could be transformed into a useful format for automated treatment, but into a different useful format for delivery to authorised users for review.
FAU_SAA.1
Potential violation analysis
575
576
User application notes
This component is used to specify the set of auditable events whose occurrence or accumulated occurrence held to indicate a potential violation of the TSP, and any rules to be used to perform the violation analysis.
Operations
Assignment:
For FAU_SAA.1.2.a, the PP/ST author should identify the subset of defined auditable events whose occurrence or accumulated occurrence need to be detected as an indication of a potential violation of the TSP.
577
Assignment:
In FAU_SAA.1.2.b, the PP/ST author should specify any other rules that the TSF should use in its analysis of the audit trail. Those rules could include specific requirements to express the needs for the events to occur in a certain period of time (e.g. period of the day, duration).
FAU_SAA.2
Profile based anomaly detection
578
A profile is a structure that characterises the behaviour of users and/or subjects; it represents how the users/subjects interact with the TSF in a variety of ways.
Patterns of usage are established with respect to the various types of activity the users/subjects engage in (e.g. patterns in exceptions raised, patterns in resource utilisation (when, which, how), patterns in actions performed). The ways in which the various types of activity are recorded in the profile (e.g. resource measures, event counters, timers) are referred to as profile metrics.
August 1999 Version 2.1
Page 191 of 354

C - Security audit (FAU) Security audit analysis (FAU_SAA)
579
580
581
582
583
584
585
Page 192 of 354 a) b)
Each profile represents the expected patterns of usage performed by members of the
profile target group. This pattern may be based on past use (historical patterns) or on normal use for users of similar target groups (expected behaviour). A profile target group refers to one or more users who interact with the TSF. The activity of each member of the profile group is used by the analysis tool in establishing the usage patterns represented in the profile. The following are some examples of profile target groups:
Single user account: one profile per user;
Group ID or Group Account: one profile for all users who possess the same group ID or operate using the same group account; c) d)
Operating Role: one profile for all users sharing a given operating role;
System: one profile for all users of a system.
Each member of a profile target group is assigned an individual suspicion rating that represents how closely that member’s new activity corresponds to the established patterns of usage represented in the group profile.
The sophistication of the anomaly detection tool will largely be determined by the number of target profile groups required by the PP/ST and the complexity of the required profile metrics.
This component is used to specify the set of auditable events whose occurrence or accumulated occurrence indicates a potential violation of the TSP, and any rules to be used to perform the violation analysis. This set of events or rules could be modified by the authorised user, through addition, modification or deletion of events or rules.
The PP/ST author should enumerate specifically what activity should be monitored and/or analysed by the TSF. The PP/ST author should also identify specifically what information pertaining to the activity is necessary to construct the usage profiles.
FAU_SAA.2 requires that the TSF maintain profiles of system usage. The word maintain implies that the anomaly detector is actively updating the usage profile based on new activity performed by the profile target members. It is important here that the metrics for representing user activity are defined by the PP/ST author. For example, there may be a thousand different actions an individual may be capable of performing, but the anomaly detector may choose to monitor a subset of that activity. Anomalous activity gets integrated into the profile just like non-anomalous activity (assuming the tool is monitoring those actions). Things that may have appeared anomalous four months ago, might over time become the norm (and viceversa) as the user’s work duties change. The TSF wouldn't be able to capture this notion if it filtered out anomalous activity from the profile updating algorithms.
Administrative notification should be provided such that the authorised user understands the significance of the suspicion rating.
Version 2.1
August 1999

Security audit analysis (FAU_SAA) C - Security audit (FAU)
586
587
The PP/ST author should define how to interpret suspicion ratings and the conditions under which anomalous activity is indicated to the FAU_ARP mechanism.
Operations
Assignment:
For FAU_SAA.2.1, the PP/ST author should specify the profile target group. A single PP/ST may include multiple profile target groups.
588
For FAU_SAA.2.3, the PP/ST author should specify conditions under which anomalous activity is reported by the TSF. Conditions may include the suspicion rating reaching a certain value, or be based on the type of anomalous activity observed.
FAU_SAA.3
Simple attack heuristics
User application notes
589
In practice, it is at best rare when an analysis tool can detect with certainty when a security violation is imminent. However, there do exist some system events that are so significant that they are always worthy of independent review. Example of such events include the deletion of a key TSF security data file (e.g. the password file) or activity such as a remote user attempting to gain administrative privilege. These events are referred to as signature events in that their occurrence in isolation from the rest of the system activity are indicative of intrusive activity.
590
591
592
593
594
The complexity of a given tool will depend greatly on the assignments defined by the PP/ST author in identifying the base set of signature events.
The PP/ST author should enumerate specifically what events should be monitored by the TSF in order to perform the analysis. The PP/ST author should identify specifically what information pertaining to the event is necessary to determine if the event maps to a signature event.
Administrative notification should be provided such that the authorised user understands the significance of the event and the appropriate possible responses.
An effort was made in the specification of these requirements to avoid a dependency on audit data as the sole input for monitoring system activity. This was done in recognition of the existence of previously developed intrusion detection tools that do not perform their analyses of system activity solely through the use of audit data (examples of other input data include network datagrams, resource/ accounting data, or combinations of various system data).
The elements of FAU_SAA.3 do not require that the TSF implementing the immediate attack heuristics be the same TSF whose activity is being monitored.
Thus, one can develop an intrusion detection component that operates independently of the system whose system activity is being analysed.
August 1999 Version 2.1
Page 193 of 354

C - Security audit (FAU) Security audit analysis (FAU_SAA)
595
Operations
Assignment:
For FAU_SAA.3.1, the PP/ST author should identify a base subset of system events whose occurrence, in isolation from all other system activity, may indicate a violation of the TSP. These include events that by themselves indicate a clear violation to the TSP, or whose occurrence is so significant that they warrant actions.
596 In FAU_SAA.3.2, the PP/ST author should specify the information used to determine system activity. This information is the input data used by the analysis tool to determine the system activity that has occurred on the TOE. This data may include audit data, combinations of audit data with other system data, or may consist of data other than the audit data. The PP/ST author should define precisely what system events and event attributes are being monitored within the input data.
FAU_SAA.4
Complex attack heuristics
User application notes
597
In practice, it is at best rare when an analysis tool can detect with certainty when a security violation is imminent. However, there do exist some system events that are so significant they are always worthy of independent review. Example of such events include the deletion of a key TSF security data file (e.g. the password file) or activity such as a remote user attempting to gain administrative privilege. These events are referred to as signature events in that their occurrence in isolation from the rest of the system activity are indicative of intrusive activity. Event sequences are an ordered set of signature events that might indicate intrusive activity.
598
599
600
601
602
The complexity of a given tool will depend greatly on the assignments defined by the PP/ST author in identifying the base set of signature events and event sequences.
The PP/ST author should define a base set of signature events and event sequences to be represented by the TSF. Additional signature events and event sequences may be defined by the system developer.
The PP/ST author should enumerate specifically what events should be monitored by the TSF in order to perform the analysis. The PP/ST author should identify specifically what information pertaining to the event is necessary to determine if the event maps to a signature event.
Administrative notification should be provided such that the authorised user understands the significance of the event and the appropriate possible responses.
An effort was made in the specification of these requirements to avoid a dependency on audit data as the sole input for monitoring system activity. This was done in recognition of the existence of previously developed intrusion detection tools that do not perform their analyses of system activity solely through the use of
Page 194 of 354 Version 2.1
August 1999

Security audit analysis (FAU_SAA) C - Security audit (FAU)
603
604
605
606 audit data (examples of other input data include network datagrams, resource/ accounting data, or combinations of various system data). Levelling, therefore, requires the PP/ST author to specify the type of input data used to monitor system activity.
The elements of FAU_SAA.4 do not require that the TSF implementing the complex attack heuristics be the same TSF whose activity is being monitored. Thus, one can develop an intrusion detection component that operates independently of the system whose system activity is being analysed.
Operations
Assignment:
For FAU_SAA.4.1, the PP/ST author should identify a base set of list of sequences of system events whose occurrence are representative of known penetration scenarios. These event sequences represent known penetration scenarios. Each event represented in the sequence should map to a monitored system event, such that as the system events are performed, they are bound (mapped) to the known penetration event sequences.
For FAU_SAA.4.1, the PP/ST author should identify a base subset of system events whose occurrence, in isolation from all other system activity, may indicate a violation of the TSP. These include events that by themselves indicate a clear violation to the TSP, or whose occurrence is so significant they warrant action.
In FAU_SAA.4.2, the PP/ST author should specify the information used to determine system activity. This information is the input data used by the analysis tool to determine the system activity that has occurred on the TOE.
This data may include audit data, combinations of audit data with other system data, or may consist of data other than the audit data. The PP/ST author should define precisely what system events and event attributes are being monitored within the input data.
August 1999 Version 2.1
Page 195 of 354

C - Security audit (FAU) Security audit review (FAU_SAR)
FAU_SAR
607
Security audit review
The Security audit review family defines requirements related to review of the audit information.
608
611
612
613
-
-
-
-
These functions should allow pre-storage or post-storage audit selection that includes, for example, the ability to selectively review: the actions of one or more users (e.g. identification, authentication, TOE entry, and access control actions); the actions performed on a specific object or TOE resource; all of a specified set of audited exceptions; or actions associated with a specific TSP attribute.
609
Application notes
The distinction between audit reviews is based on functionality. Audit review
(only) encompasses the ability to view audit data. Selectable review is more sophisticated, and requires the ability to perform searches based on a single criterion or multiple criteria with logical (i.e. and/or) relations, sort audit data, filter audit data, before audit data are reviewed.
FAU_SAR.1
Audit review
User application notes
610
This component is used to specify that users and/or authorised users can read the audit records. These audit records will be provided in a manner appropriate to the user. There are different types of users (human users, machine users) that might have different needs.
The content of the audit records that can be viewed can be specified.
Operations
Assignment:
In FAU_SAR.1.1 the PP/ST author should specify the authorised users that can use this capability. If appropriate the PP/ST author may include security roles (see FMT_SMR.1 Security roles).
In FAU_SAR.1.1 the PP/ST author should specify the type of information the specified user is permitted to obtain from the audit records. Examples are “all”, “subject identity”, “all information belonging to audit records referencing this user”.
Page 196 of 354 Version 2.1
August 1999

Security audit review (FAU_SAR) C - Security audit (FAU)
FAU_SAR.2
Restricted audit review
User application notes
614
This component specifies that any users not identified in FAU_SAR.1 will not be able to read the audit records.
FAU_SAR.3
Selectable audit review
User application notes
615
616
617
This component is used to specify that it should be possible to perform selection of the audit data to be reviewed. If based on multiple criteria, those criteria should be related together with logical (i.e. ‘and’ or ‘or’) relations, and the tools should provide the ability to manipulate audit data (e.g. sort, filter).
Operations
Selection:
For FAU_SAR.3.1 the PP/ST author should select whether searches, sorting and/or ordering can be performed by the TSF.
Assignment:
For FAU_SAR.3.1, the PP/ST author should assign the criteria, possibly with logical relations, to be used to select the audit data for review. The logical relations are intended to specify whether the operation can be on an individual attribute or a collection of attributes.
An example of this assignment could be: “application, user account and/or location”. In this case the operation could be specified using any combination of the three attributes: application, user account and location.
August 1999 Version 2.1
Page 197 of 354

C - Security audit (FAU) Security audit event selection (FAU_SEL)
FAU_SEL
618
Security audit event selection
The Security audit event selection family provides requirements related to the capabilities of identifying which of the possible auditable events are to be audited.
The auditable events are defined in the FAU_GEN Security audit data generation family, but those events should be defined as being selectable in this component to be audited.
619
Application notes
This family ensures that it is possible to keep the audit trail from becoming so large that it becomes useless, by defining the appropriate granularity of the selected security audit events.
FAU_SEL.1
Selective audit
620
User application notes
This component defines the criteria used for the selection of events to be audited.
Those criteria could permit inclusion or exclusion of events from the set of auditable events, based on user attributes, subject attributes, objects attributes, or event types.
621
622
623
624
625
The existence of individual user identities is not assumed for this component. This allows for TOEs such as routers that may not support the notion of users.
For a distributed environment, the host identity could be used as a selection criteria for events to be audited.
The management function FMT_MTD.1 Management of TSF data will handle the rights of authorised users to query or modify the selections.
Operations
Selection:
For FAU_SEL.1.1a, the PP/ST author should select whether the security attributes upon which audit selectivity is based, is related to object identity, user identity, subject identity, host identity, or event type.
Assignment:
For FAU_SEL.1.1b, the PP/ST author should specify any additional attributes upon which audit selectivity is based.
Page 198 of 354 Version 2.1
August 1999

Security audit event storage (FAU_STG) C - Security audit (FAU)
FAU_STG
626
Security audit event storage
The Security audit event storage family describes requirements for storing audit data for later use, including requirements controlling the loss of audit information due to system failure, attack and/or exhaustion of storage space.
FAU_STG.1
Protected audit trail storage
627
628
User application notes
In a distributed environment, as the location of the audit trail is in the TSC, but not necessarily co-located with the function generating the audit data, the PP/ST author could request authentication of the originator of the audit record, or non-repudiation of the origin of the record prior storing this record in the audit trail.
The TSF will protect the audit trail from unauthorised deletion and modification. It is noted that in some systems the auditor (role) might not be authorised to delete the audit records for a certain period of time.
629
Operations
Selection:
In FAU_STG.1.2, the PP/ST author should specify whether the TSF shall prevent or only be able to detect modifications of the audit trail.
FAU_STG.2
Guarantees of audit data availability
630
631
632
633
User application notes
This component allows the PP/ST author to specify to which metrics the audit trail should conform.
In a distributed environment, as the location of the audit trail is in the TSC, but not necessarily co-located with the function generating the audit data, the PP/ST author could request authentication of the originator of the audit record, or non-repudiation of the origin of the record prior storing this record in the audit trail.
Operations
Selection:
In FAU_STG.2.2, the PP/ST author should specify whether the TSF shall prevent or only be able to detect modifications of the audit trail.
In FAU_STG.2.3, the PP/ST author should specify the condition under which the TSF shall still be able to maintain a defined amount of audit data. This condition can be any one of the following: audit storage exhaustion, failure, attack.
August 1999 Version 2.1
Page 199 of 354

C - Security audit (FAU) Security audit event storage (FAU_STG)
634
Assignment:
In FAU_STG.2.3, the PP/ST author should specify the metric that the
TSF must ensure with respect to the audit trail. This metric limits the data loss by enumerating the number of records that must be kept, or the time that records are guaranteed to be maintained. An example of the metric could be “100,000” indicating that 100,000 audit records can be stored.
FAU_STG.3
Action in case of possible audit data loss
User application notes
635
636
637
This component requires that actions will be taken when the audit trail exceeds certain pre-defined limits.
Operations
Assignment:
In FAU_STG.3.1, the PP/ST author should indicate the pre-defined limit. If the management functions indicate that this number might be changed by the authorised user, this value is the default value. The PP/
ST author might choose to let the authorised user define this limit. In that case the assignment can be for example “an authorised user set limit”.
In FAU_STG.3.1, the PP/ST author should specify actions that should be taken in case of imminent audit storage failure indicated by exceeding the threshold. Actions might include informing an authorised user.
FAU_STG.4
Prevention of audit data loss
User application notes
638
This component specifies the behaviour of the TOE if the audit trail is full: either audit records are ignored, or the TOE is frozen such that no auditable events can take place. The requirement also states that no matter how the requirement is instantiated, the authorised user with specific rights to this effect, can continue to generate auditable events (actions). The reason is that otherwise the authorised user could not even reset the system. Consideration should be given to the choice of the action to be taken by the TSF in the case of audit storage exhaustion, as ignoring events, which provides better availability of the TOE, will also permit actions to be performed without being recorded and without the user being accountable.
Page 200 of 354 Version 2.1
August 1999

Security audit event storage (FAU_STG) C - Security audit (FAU)
639
640
Operations
Selection:
In FAU_STG.4.1, the PP/ST author should select whether the TSF shall ignore auditable actions, or whether it should prevent auditable actions from happening, or whether the oldest audit records should be overwritten when the TSF can no longer store audit records.
Assignment:
In FAU_STG.4.1, the PP/ST author should specify other actions that should be taken in case of audit storage failure, such as informing the authorised user.
August 1999 Version 2.1
Page 201 of 354

C - Security audit (FAU) Security audit event storage (FAU_STG)
Page 202 of 354 Version 2.1
August 1999

641
642
643
644
This class describes requirements specifically of interest for TOEs that are used for the transport of information. Families within this class deal with non-repudiation.
Communication
FCO_NRO Non-repudiation of origin
FCO_NRR Non-repudiation of receipt
1
1
2
2
Figure D.1 - Communication class decomposition
Figure D.1 shows the decomposition of this class into its constituent components.
In this class the concept of “information” is used. This information should be interpreted as the object being communicated, and could contain an electronic mail message, a file, or a set of predefined attribute types.
In the literature, the terms ‘proof of receipt’ and ‘proof of origin’ are commonly used terms. However it is recognised that the term ‘proof’ might be interpreted in a legal sense to imply a form of mathematical rationale. The components in this class interpret the de-facto use of the word ‘proof’ in the context of ‘evidence’ that the
TSF demonstrates the non-repudiated transport of types of information.
August 1999 Version 2.1
Page 203 of 354

D - Communication (FCO) Non-repudiation of origin (FCO_NRO)
FCO_NRO
645
Non-repudiation of origin
Non-repudiation of origin defines requirements to provide evidence to users/ subjects about the identity of the originator of some information. The originator cannot successfully deny having sent the information because evidence of origin
(e.g. digital signature) provides evidence of the binding between the originator and the information sent. The recipient or a third party can verify the evidence of origin.
This evidence should not be forgeable.
646
647
648
649
User notes
If the information or the associated attributes are altered in any way, validation of the evidence of origin might fail. Therefore a PP/ST author should consider including integrity requirements such as FDP_UIT.1 Data exchange integrity in the
PP/ST.
In non-repudiation there are several different roles involved, each of which could be combined in one or more subjects. The first role is a subject that requests evidence of origin (only in FCO_NRO.1 Selective proof of origin). The second role is the recipient and/or other subjects to which the evidence is provided (e.g. a notary). The third role is a subject that requests verification of the evidence of origin, for example, a recipient or a third party such as an arbiter.
The PP/ST author must specify the conditions that must be met to be able to verify the validity of the evidence. An example of a condition which could be specified is where the verification of evidence must occur within 24 hours. These conditions, therefore, allow the tailoring of the non-repudiation to legal requirements, such as being able to provide evidence for several years.
In most cases, the identity of the recipient will be the identity of the user who received the transmission. In some instances, the PP/ST author does not want the user identity to be exported. In that case the PP/ST author must consider whether it is appropriate to include this class, or whether the identity of the transport service provider or the identity of the host should be used.
650
In addition to (or instead of) the user identity, a PP/ST author might be more concerned about the time the information was transmitted. For example, requests for proposals must be transmitted before a certain date in order to be considered. In such instances, these requirements can be customised to provide a timestamp indication (time of origin).
FCO_NRO.1
Selective proof of origin
Operations
651
Assignment:
In FCO_NRO.1.1 the PP/ST author should fill in the types of information subject to the evidence of origin function, for example, electronic mail messages.
Page 204 of 354 Version 2.1
August 1999

Non-repudiation of origin (FCO_NRO) D - Communication (FCO)
652
653
654
655
656
657
658
Selection:
In FCO_NRO.1.1 the PP/ST author should specify the user/subject who can request evidence of origin.
Assignment:
In FCO_NRO.1.1 the PP/ST author, dependent on the selection, should specify the third parties that can request evidence of receipt. A third party could be an arbiter, judge or legal body.
In FCO_NRO.1.2 the PP/ST author should fill in the list of the attributes that shall be linked to the information; for example, originator identity, time of origin, and location of origin.
In FCO_NRO.1.2 the PP/ST author should fill in the list of information fields within the information over which the attributes provide evidence of origin, such as the body of a message.
Selection:
In FCO_NRO.1.3 the PP/ST author should specify the user/subject who can verify the evidence of origin.
Assignment:
In FCO_NRO.1.3 the PP/ST author, dependent on the selection, should specify the third parties that can verify the evidence of origin.
In FCO_NRO.1.3 the PP/ST author should fill in the list of limitations under which the evidence can be verified. For example the evidence can only be verified within a 24 hour time interval. An assignment of
‘immediate’ or ‘indefinite’ is acceptable.
FCO_NRO.2
Enforced proof of origin
Operations
659
660
661
Assignment:
In FCO_NRO.2.1 the PP/ST author should fill in the types of information subject to the evidence of origin function, for example, electronic mail messages.
In FCO_NRO.2.2 the PP/ST author should fill in the list of the attributes that shall be linked to the information; for example, originator identity, time of origin, and location of origin.
In FCO_NRO.2.2 the PP/ST author should fill in the list of information fields within the information over which the attributes provide evidence of origin, such as the body of a message.
August 1999 Version 2.1
Page 205 of 354

662
663
664
D - Communication (FCO) Non-repudiation of origin (FCO_NRO)
Selection:
In FCO_NRO.2.3 the PP/ST author should specify the user/subject who can verify the evidence of origin.
Assignment:
In FCO_NRO.2.3 the PP/ST author, dependent on the selection, should specify the third parties that can verify the evidence of origin. A third party could be an arbiter, judge or legal body.
In FCO_NRO.2.3 the PP/ST author should fill in the list of limitations under which the evidence can be verified. For example the evidence can only be verified within a 24 hour time interval. An assignment of ‘immediate’ or
‘indefinite’ is acceptable.
Page 206 of 354 Version 2.1
August 1999

Non-repudiation of receipt (FCO_NRR) D - Communication (FCO)
666
667
FCO_NRR
665
668
669
670
671
Non-repudiation of receipt
Non-repudiation of receipt defines requirements to provide evidence to other users/ subjects that the information was received by the recipient. The recipient cannot successfully deny having received the information because evidence of receipt (e.g.
digital signature) provides evidence of the binding between the recipient attributes and the information. The originator or a third party can verify the evidence of receipt. This evidence should not be forgeable.
User notes
It should be noted that the provision of evidence that the information was received does not necessarily imply that the information was read or comprehended, but only delivered
If the information or the associated attributes are altered in any way, validation of the evidence of receipt with respect to the original information might fail. Therefore a PP/ST author should consider including integrity requirements such as
FDP_UIT.1 Data exchange integrity in the PP/ST.
In non-repudiation, there are several different roles involved, each of which could be combined in one or more subjects. The first role is a subject that requests evidence of receipt (only in FCO_NRR.1 Selective proof of receipt). The second role is the recipient and/or other subjects to which the evidence is provided, (e.g. a notary). The third role is a subject that requests verification of the evidence of receipt, for example, an originator or a third party such as an arbiter.
The PP/ST author must specify the conditions that must be met to be able to verify the validity of the evidence. An example of a condition which could be specified is where the verification of evidence must occur within 24 hours. These conditions, therefore, allow the tailoring of the non-repudiation to legal requirements, such as being able to provide evidence for several years.
In most cases, the identity of the recipient will be the identity of the user who received the transmission. In some instances, the PP/ST author does not want the user identity to be exported. In that case, the PP/ST author must consider whether it is appropriate to include this class, or whether the identity of the transport service provider or the identity of the host should be used.
In addition to (or instead of) the user identity, a PP/ST author might be more concerned about the time the information was received. For example, when an offer expires at a certain date, orders must be received before a certain date in order to be considered. In such instances, these requirements can be customised to provide a timestamp indication (time of receipt).
August 1999 Version 2.1
Page 207 of 354

D - Communication (FCO) Non-repudiation of receipt (FCO_NRR)
FCO_NRR.1
Selective proof of receipt
Operations
672
673
674
675
676
677
678
679
Assignment:
In FCO_NRR.1.1 the PP/ST author should fill in the types of information subject to the evidence of receipt function, for example, electronic mail messages.
Selection:
In FCO_NRR.1.1 the PP/ST author should specify the user/subject who can request evidence of receipt.
Assignment:
In FCO_NRR.1.1 the PP/ST author, dependent on the selection, should specify the third parties that can request evidence of receipt. A third party could be an arbiter, judge or legal body.
In FCO_NRR.1.2 the PP/ST author should fill in the list of the attributes that shall be linked to the information; for example, recipient identity, time of receipt, and location of receipt.
In FCO_NRR.1.2 the PP/ST author should fill in the list of information fields with the fields within the information over which the attributes provide evidence of receipt, such as the body a message.
Selection:
In FCO_NRR.1.3 the PP/ST author should specify the user/subjects who can verify the evidence of receipt.
Assignment:
In FCO_NRR.1.3 the PP/ST author, dependent on the selection, should specify the third parties that can verify the evidence of receipt.
In FCO_NRR.1.3 the PP/ST author should fill in the list of limitations under which the evidence can be verified. For example the evidence can only be verified within a 24 hour time interval. An assignment of
‘immediate’ or ‘indefinite’ is acceptable.
Page 208 of 354 Version 2.1
August 1999

Non-repudiation of receipt (FCO_NRR) D - Communication (FCO)
FCO_NRR.2
Enforced proof of receipt
Operations
680
681
682
683
684
685
Assignment:
In FCO_NRR.2.1 the PP/ST author should fill in the types of information subject to the evidence of receipt function, for example electronic mail messages.
In FCO_NRR.2.2 the PP/ST author should fill in the list of the attributes that shall be linked to the information; for example, recipient identity, time of receipt, and location of receipt.
In FCO_NRR.2.2 the PP/ST author should fill in the list of information fields with the fields within the information over which the attributes provide evidence of receipt, such as the body of a message.
Selection:
In FCO_NRR.2.3 the PP/ST author should specify the user/subjects who can verify the evidence of receipt.
Assignment:
In FCO_NRR.2.3 the PP/ST author, dependent on the selection, should specify the third parties that can verify the evidence of receipt. A third party could be an arbiter, judge or legal body.
In FCO_NRR.2.3 the PP/ST author should fill in the list of limitations under which the evidence can be verified. For example the evidence can only be verified within a 24 hour time interval. An assignment of ‘immediate’ or
‘indefinite’ is acceptable.
August 1999 Version 2.1
Page 209 of 354

D - Communication (FCO) Non-repudiation of receipt (FCO_NRR)
Page 210 of 354 Version 2.1
August 1999

686
687
The TSF may employ cryptographic functionality to help satisfy several high-level security objectives. These include (but are not limited to): identification and authentication, non-repudiation, trusted path, trusted channel and data separation.
This class is used when the TOE implements cryptographic functions, the implementation of which could be in hardware, firmware and/or software.
The FCS class is composed of two families: FCS_CKM Cryptographic key management and FCS_COP Cryptographic operation. The FCS_CKM family addresses the management aspects of cryptographic keys, while the FCS_COP family is concerned with the operational use of those cryptographic keys.
Figure E.1 shows the decomposition of this class into its constituent components.
688
689
690
691
Cryptographic support
FCS_CKM Cryptographic key management
FCS_COP Cryptographic operation
3
4
1
2
1
Figure E.1 - Cryptographic support class decomposition
For each cryptographic key generation method implemented by the TOE, if any, the
PP/ST author should select the FCS_CKM.1 component.
For each cryptographic key distribution method implemented by the TOE, if any, the PP/ST author should select the FCS_CKM.2 component.
For each cryptographic key access method implemented by the TOE, if any, the PP/
ST author should select the FCS_CKM.3 component.
August 1999 Version 2.1
Page 211 of 354

E - Cryptographic support (FCS)
692
693
694
For each cryptographic key destruction method implemented by the TOE, if any, the PP/ST author should select the FCS_CKM.4 component.
For each cryptographic operation (such as digital signature, data encryption, key agreement, secure hash, etc.) performed by the TOE, if any, the PP/ST author should select the FCS_COP.1 component.
Cryptographic functionality may be used to meet objectives specified in class FCO, and in families FDP_DAU, FDP_SDI, FDP_UCT, FDP_UIT, FIA_SOS,
FIA_UAU, to meet a variety of objectives. In the cases where cryptographic functionality is used to meet objectives for other classes, the individual functional components specify the objectives that cryptographic functionality must satisfy.
The objectives in class FCS should be used when cryptographic functionality of the
TOE is sought by consumers.
Page 212 of 354 2.1
August 1999

Cryptographic key management (FCS_CKM) E - Cryptographic support (FCS)
FCS_CKM
695
Cryptographic key management
User notes
Cryptographic keys must be managed throughout their lifetime. The typical events in the lifecycle of a cryptographic key include (but are not limited to): generation, distribution, entry, storage, access (e.g. backup, escrow, archive, recovery) and destruction.
696
697
698
As a minimum, cryptographic keys should at least go through the following stages: generation, storage and destruction. The inclusion of other stages is dependent on the key management strategy being implemented, as the TOE need not be involved in all of the key life-cycle (e.g. the TOE may only generate and distribute cryptographic keys).
This family is intended to support the cryptographic key lifecycle and consequently defines requirements for the following activities: cryptographic key generation, cryptographic key distribution, cryptographic key access and cryptographic key destruction. This family should be included whenever there are functional requirements for the management of cryptographic keys.
If FAU_GEN Security Audit Data Generation is included in the PP/ST then, in the context of the events being audited: a) The object attributes may include the assigned user for the cryptographic key, the user role, the cryptographic operation that the cryptographic key is to be used for, the cryptographic key identifier and the cryptographic key validity period.
699 b) The object value may include the values of cryptographic key(s) and parameters excluding any sensitive information (such as secret or private cryptographic keys).
Typically, random numbers are used to generate cryptographic keys. If this is the case, then FCS_CKM.1 Cryptographic key generation should be used instead of the component FIA_SOS.2 TSF Generation of secrets. In cases where random number generation is required for purposes other than for the generation of cryptographic keys, the component FIA_SOS.2 TSF Generation of secrets should be used.
FCS_CKM.1
Cryptographic key generation
User application notes
700
This component requires the cryptographic key sizes and method used to generate cryptographic keys to be specified, this can be in accordance with an assigned standard. It should be used to specify the cryptographic key sizes and the method
(e.g. algorithm) used to generate the cryptographic keys. Only one instance of the component is needed for the same method and multiple key sizes. The key size could be common or different for the various entities, and could be either the input to or the output from the method.
August 1999 Version 2.1
Page 213 of 354

E - Cryptographic support (FCS) Cryptographic key management (FCS_CKM)
701
702
703
705
706
Operations
Assignment:
In FCS_CKM.1.1, the PP/ST author should specify the cryptographic key generation algorithm to be used.
In FCS_CKM.1.1, the PP/ST author should specify the cryptographic key sizes to be used. The key sizes specified should be appropriate for the algorithm and its intended use.
In FCS_CKM.1.1, the PP/ST author should specify the assigned standard that documents the method used to generate cryptographic keys. The assigned standard may comprise none, one or more actual standards publications, for example, from international, national, industry or organisational standards.
FCS_CKM.2
Cryptographic key distribution
User application notes
704 This component requires the method used to distribute cryptographic keys to be specified, this can be in accordance with an assigned standard.
Operations
Assignment:
In FCS_CKM.2.1, the PP/ST author should specify the cryptographic key distribution method to be used.
In FCS_CKM.2.1, the PP/ST author should specify the assigned standard that documents the method used to distribute cryptographic keys. The assigned standard may comprise none, one or more actual standards publications, for example, from international, national, industry or organisational standards.
FCS_CKM.3
Cryptographic key access
User application notes
707 This component requires the method used to access cryptographic keys be specified, this can be in accordance with an assigned standard.
708
Operations
Assignment:
In FCS_CKM.3.1, the PP/ST author should specify the type of cryptographic key access being used. Examples of types of cryptographic key access include (but are not limited to) cryptographic
Page 214 of 354 Version 2.1
August 1999

Cryptographic key management (FCS_CKM) E - Cryptographic support (FCS)
709
710 key backup, cryptographic key archival, cryptographic key escrow and cryptographic key recovery.
In FCS_CKM.3.1, the PP/ST author should specify the cryptographic key access method to be used.
In FCS_CKM.3.1, the PP/ST author should specify the assigned standard that documents the method used to access cryptographic keys.
The assigned standard may comprise none, one or more actual standards publications, for example, from international, national, industry or organisational standards.
FCS_CKM.4
Cryptographic key destruction
User application notes
711
712
713
This component requires the method used to destroy cryptographic keys be specified, this can be in accordance with an assigned standard.
Operations
Assignment:
In FCS_CKM.4.1, the PP/ST author should specify the key destruction method to be used to destroy cryptographic keys.
In FCS_CKM.4.1, the PP/ST author should specify the assigned standard that documents the method used to destroy cryptographic keys. The assigned standard may comprise none, one or more actual standards publications, for example, from international, national, industry or organisational standards.
August 1999 Version 2.1
Page 215 of 354

E - Cryptographic support (FCS) Cryptographic operation (FCS_COP)
FCS_COP
714
Cryptographic operation
User notes
A cryptographic operation may have cryptographic mode(s) of operation associated with it. If this is the case, then the cryptographic mode(s) must be specified.
Examples of cryptographic modes of operation are cipher block chaining, output feedback mode, electronic code book mode, and cipher feedback mode.
715
716
Cryptographic operations may be used to support one or more TOE security services. The FCS_COP component may need to be iterated more than once depending on: a) b) the user application for which the security service is being used.
the use of different cryptographic algorithms and/or cryptographic key sizes.
the type or sensitivity of the data being operated on.
c)
If FAU_GEN Security audit data generation is included in the PP/ST then, in the context of the cryptographic operation events being audited: a) The types of cryptographic operation may include digital signature generation and/or verification, cryptographic checksum generation for integrity and/or for verification of checksum, secure hash (message digest) computation, data encryption and/or decryption, cryptographic key encryption and/or decryption, cryptographic key agreement and random number generation.
717 b) The subject attributes may include subject role(s) and user(s) associated with the subject. c) The object attributes may include the assigned user for the cryptographic key, user role, cryptographic operation the cryptographic key is to be used for, cryptographic key identifier, and the cryptographic key validity period.
FCS_COP.1
Cryptographic operation
User application notes
This component requires the cryptographic algorithm and key size used to perform specified cryptographic operation(s) which can be based on an assigned standard.
718
Operations
Assignment:
In FCS_COP.1.1, the PP/ST author should specify the cryptographic operations being performed. Typical cryptographic operations include
Page 216 of 354 Version 2.1
August 1999

719
720
721
Cryptographic operation (FCS_COP) E - Cryptographic support (FCS) digital signature generation and/or verification, cryptographic checksum generation for integrity and/or for verification of checksum, secure hash (message digest) computation, data encryption and/or decryption, cryptographic key encryption and/or decryption, cryptographic key agreement and random number generation. The cryptographic operation may be performed on user data or TSF data.
In FCS_COP.1.1, the PP/ST author should specify the cryptographic algorithm to be used. Typical cryptographic algorithms include, but are not limited to, DES, RSA and IDEA.
In FCS_COP.1.1, the PP/ST author should specify the cryptographic key sizes to be used. The key sizes specified should be appropriate for the algorithm and its intended use.
In FCS_COP.1.1, the PP/ST author should specify the assigned standard that documents how the identified cryptographic operation(s) are performed. The assigned standard may comprise none, one or more actual standards publications, for example, from international, national, industry or organisational standards.
August 1999 Version 2.1
Page 217 of 354

E - Cryptographic support (FCS) Cryptographic operation (FCS_COP)
Page 218 of 354 Version 2.1
August 1999

722
723
724
725
726
727
728
729
August 1999
This class contains families specifying requirements for TOE security functions and
TOE security function policies related to protecting user data. This class differs from FIA and FPT in that FDP specifies components to protect user data, FIA specifies components to protect attributes associated with the user, and FPT specifies components to protect TSF information.
The class does not contain explicit requirements for traditional Mandatory Access
Controls (MAC) or traditional Discretionary Access Controls (DAC); however, such requirements may be constructed using components from this class.
FDP does not explicitly deal with confidentiality, integrity, or availability, as all three are most often intertwined in the policy and mechanisms. However, the TOE security policy must adequately cover these three objectives in the PP/ST.
A final aspect of this class is that it specifies access control in terms of “operations”.
An operation is defined as a specific type of access on a specific object. It depends on the level of abstraction of the PP/ST author whether these operations are described as “read” and/or “write” operations, or as more complex operations such as “update the database”.
The access control policies are policies that control access to the information container. The attributes represent attributes of the container. Once the information is out of the container, the accessor is free to modify that information, including writing the information into a different container with different attributes. By contrast, an information flow policies controls access to the information, independent of the container. The attributes of the information, which may be associated with the attributes of the container (or may not, as in the case of a multilevel database) stay with the information as it moves. The accessor does not have the ability, in the absence of an explicit authorisation, to change the attributes of the information.
This class is not meant to be a complete taxonomy of IT access policies, as others can be imagined. Those policies included here are simply those for which current experience with actual systems provides a basis for specifying requirements. There may be other forms of intent that are not captured in the definitions here.
For example, one could imagine a goal of having user-imposed (and user-defined) controls on information flow (e.g. an automated implementation of the NO
FOREIGN handling caveat). Such concepts could be handled as refinements of, or extensions to the FDP components.
Finally, it is important when looking at the components in FDP to remember that these components are requirements for functions that may be implemented by a
Version 2.1
Page 219 of 354

F - User data protection (FDP)
730
731 mechanism that also serves or could serve another purpose. For example, it is possible to build an access control policy (FDP_ACC) that uses labels (FDP_IFF.1) as the basis of the access control mechanism.
A TOE security policy may encompass many security function policies (SFPs), each to be identified by the two policy oriented components FDP_ACC, and
FDP_IFC. These policies will typically take confidentiality, integrity, and availability aspects into consideration as required, to satisfy the TOE requirements.
Care should be taken to ensure that all objects are covered by at least one SFP and that there are no conflicts arising from implementing the multiple SFPs.
Figures F.1 and F.2 show the decomposition of this class into its constituent components.
Page 220 of 354 Version 2.1
August 1999

F - User data protection (FDP)
User data protection
FDP_ACC Access control policy 1 2
FDP_ACF Access control functions
FDP_DAU Data authentication
FDP_ETC Export to outside TSF control
FDP_IFC Information flow control policy
FDP_IFF Information flow control functions
1
FDP_ITC Import from outside TSF control
2
1
FDP_ITT Internal TOE transfer
3
Figure F.1 - User data protection class decomposition
2
4
1
1
1
2
1
2
2
1
3
6
2
4 5
August 1999 Version 2.1
Page 221 of 354

F - User data protection (FDP)
User data protection
FDP_RIP Residual information protection
FDP_ROL Rollback
FDP_SDI Stored data integrity
FDP_UCT Inter-TSF user data confidentiality transfer protection
FDP_UIT Inter-TSF user data integrity transfer protection
1 2
1 2
1 2
1
1
2 3
732
733
734
735
Page 222 of 354
Figure F.2 - User data protection class decomposition (cont.)
When building a PP/ST using components from the FDP class, the following information provides guidance on where to look and what to select from the class.
The requirements in the FDP class are defined in terms of a security function
(abbreviated SF) that will implement a SFP. Since a TOE may implement multiple
SFPs simultaneously, the PP/ST author must specify the name for each SFP, so it can be referenced in other families. This name will then be used in each component selected to indicate that it is being used as part of the definition of requirements for that function. This allows the author to easily indicate the scope for operations such as objects covered, operations covered, authorised users, etc.
Each instantiation of a component can apply to only one SFP. Therefore if an SFP is specified in a component then this SFP will apply to all the elements in this component. The components may be instantiated multiple times within a PP/ST to account for different policies if so desired.
The key to selecting components from this family is to have a well defined TOE security policy to enable proper selection of the components from the two policy components; FDP_ACC and FDP_IFC. In FDP_ACC and FDP_IFC respectively, all access control policies and all information flow control policies are named.
Version 2.1
August 1999

F - User data protection (FDP)
736
Furthermore the scope of control of these components in terms of the subjects, objects and operations covered by this security function. The names of these policies are meant to be used throughout the remainder of the functional components that have an operation that calls for an assignment or selection of an
“access control SFP” or an “information flow control SFP”. The rules that define the functionality of the named access control and information flow control SFPs will be defined in the FDP_ACF and FDP_IFF families (respectively).
f) g)
The following steps are guidance on how this class is applied in the construction of a PP/ST: a) Identify the policies to be enforced from the FDP_ACC, and FDP_IFC families. These families define scope of control for the policy, granularity of control and may identify some rules to go with the policy.
b) c)
Identify the components and perform any applicable operations in the policy components. The assignment operations may be performed generally (such as with a statement “All files”) or specifically (“The files “A”, “B”, etc.) depending upon the level of detail known.
Identify any applicable function components from the FDP_ACF and
FDP_IFF families to address the named policy families from FDP_ACC and FDP_IFC. Perform the operations to make the components define the rules to be enforced by the named policies. This should make the components fit the requirements of the selected function envisioned or to be built.
d) e)
Identify who will have the ability to control and change security attributes under the function, such as only a security administrator, only the owner of the object, etc. Select the appropriate components from Class FMT Security management and perform the operations. Refinements may be useful here to identify missing features, such as that some or all changes must be done via trusted path.
Identify any appropriate components from the Class FMT Security management for initial values for new objects and subjects.
Identify any applicable rollback components from the FDP_ROL family.
Identify any applicable residual information protection requirements from the FDP_RIP family.
h) i)
Identify any applicable import or export components, and how security attributes should be handled during import and export, from the FDP_ITC and FDP_ETC families.
Identify any applicable internal TOE communication components from the
FDP_ITT family.
August 1999 Version 2.1
Page 223 of 354

F - User data protection (FDP) j) k)
Identify any requirements for integrity protection of stored information from the FDP_SDI.
Identify any applicable inter-TSF communication components from the
FDP_UCT or FDP_UIT families.
Page 224 of 354 Version 2.1
August 1999

Access control policy (FDP_ACC) F - User data protection (FDP)
741
742
FDP_ACC
737
738
739
740
Access control policy
This family is based upon the concept of arbitrary controls on the interaction of subjects and objects. The scope and purpose of the controls is based upon the attributes of the accessor (subject), the attributes of the container being accessed
(object), the actions (operations) and any associated access control rules.
User notes
The components in this family are capable of identifying the access control SFPs
(by name) to be enforced by the traditional Discretionary Access Control (DAC) mechanisms. It further defines the subjects, objects and operations that are covered by identified access control SFPs. The rules that define the functionality of an access control SFP will be defined by other families, such as FDP_ACF and
FDP_RIP. The names of the access control SFPs defined in FDP_ACC are meant to be used throughout the remainder of the functional components that have an operation that calls for an assignment or selection of an “access control SFP.”
The access control SFP covers a set of triplets: subject, object, and operations.
Therefore a subject can be covered by multiple access control SFPs but only with respect to a different operation or a different object. Of course the same applies to objects and operations.
A critical aspect of an access control function that enforces an access control SFP is the ability for users to modify the attributes involved in access control decisions.
The FDP_ACC family does not address these aspects. Some of these requirements are left undefined, but can be added as refinements, while others are covered elsewhere in other families and classes such as FMT Class FMT: Security management.
There are no audit requirements in FDP_ACC as this family specifies access control
SFP requirements. Audit requirements will be found in families specifying functions to satisfy the access control SFPs identified in this family.
This family provides a PP/ST author the capability to specify several policies, for example, a fixed access control SFP to be applied to one scope of control, and a flexible access control SFP to be defined for a different scope of control. To specify more than one access control policy, the components from this family can be iterated multiple times in a PP/ST to different subsets of operations and objects.
This will accommodate TOEs that contain multiple policies, each addressing a particular set of operations and objects. In other words, the PP/ST author should specify the required information in the ACC component for each of the access control SFPs that the TSF will enforce. For example, a TOE incorporating three access control SFPs, each covering only a subset of the objects, subjects, and operations within the TOE, will contain one FDP_ACC.1 Subset access control component for each of the three access control SFPs, necessitating a total of three
FDP_ACC.1 components.
August 1999 Version 2.1
Page 225 of 354

F - User data protection (FDP) Access control policy (FDP_ACC)
FDP_ACC.1
Subset access control
User application notes
743
The terms object and subject refer to generic elements in the TOE. For a policy to be implementable, the entities must be clearly identified. For a PP, the objects and operations might be expressed as types such as: named objects, data repositories, observe accesses, etc. For a specific system these generic terms (subject, object) must be refined, e.g. files, registers, ports, daemons, open calls, etc.
744
745
746
This component specifies that the policy cover some well-defined set of operations on some subset of the objects. It places no constraints on any operations outside the set – including operations on objects for which other operations are controlled.
Operations
Assignment:
In FDP_ACC.1.1, the PP/ST author should specify a uniquely named access control SFP to be enforced by the TSF.
In FDP_ACC.1.1, the PP/ST author should specify the list of subjects, objects, and operations among subjects and objects covered by the SFP.
FDP_ACC.2
Complete access control
User application notes
747
This component requires that all possible operations on objects, that are included in the SFP, are covered by an access control SFP.
748
749
750
The PP/ST author must demonstrate that each combination of objects and subjects is covered by an access control SFP.
Operations
Assignment:
In FDP_ACC.2.1, the PP/ST author should specify a uniquely named access control SFP to be enforced by the TSF.
In FDP_ACC.2.1, the PP/ST author should specify the list of subjects and objects covered by the SFP. All operations among those subjects and objects will be covered by the SFP.
Page 226 of 354 Version 2.1
August 1999

Access control functions
(FDP_ACF)
F - User data protection (FDP)
FDP_ACF
751
Access control functions
This family describes the rules for the specific functions that can implement an access control policy named in FDP_ACC which also specifies the scope of control of the policy.
752
753
User notes
This family provides a PP/ST author the capability to describe the rules for access control. This results in a system where the access to objects will not change. An example of such an object is “Message of the Day”, which is readable by all, and changeable only by the authorised administrator. This family also provides the PP/
ST author with the ability to describe rules that provide for exceptions to the general access control rules. Such exceptions would either explicitly allow or deny authorisation to access an object.
There are no explicit components to specify other possible functions such as twoperson control, sequence rules for operations, or exclusion controls. However, these mechanisms, as well as traditional DAC mechanisms, can be represented with the existing components, by careful drafting of the access control rules.
A variety of acceptable access control SFs may be specified in this family such as:
754
-
-
-
Access control lists (ACLs)
Time-based access control specifications
Origin-based access control specifications
Owner-controlled access control attributes
FDP_ACF.1
Security attribute based access control
User application notes
755
This component provides requirements for a mechanism that mediates access control based on security attributes associated with subjects and objects. Each object and subject has a set of associated attributes, such as location, time of creation, access rights (e.g., Access Control Lists (ACLs)). This component allows the PP/ST author to specify the attributes that will be used for the access control mediation. This component allows access control rules, using these attributes, to be specified.
756
757
758
Examples of the attributes that a PP/ST author might assign are presented in the following paragraphs.
An identity attribute may be associated with users, subjects, or objects to be used for mediation. Examples of such attributes might be the name of the program image used in the creation of the subject, or a security attribute assigned to the program image.
A time attribute can be used to specify that access will be authorised during certain times of the day, during certain days of the week, or during a certain calendar year.
August 1999 Version 2.1
Page 227 of 354

F - User data protection (FDP) Access control functions (FDP_ACF)
759
760
761
762
763
764
765
Page 228 of 354
A location attribute could specify whether the location is the location of the request for the operation, the location where the operation will be carried out, or both. It could be based upon internal tables to translate the logical interfaces of the TSF into locations such as through terminal locations, CPU locations, etc.
A grouping attribute allows a single group of users to be associated with an operation for the purposes of access control. If required, the refinement operation should be used to specify the maximum number of definable groups, the maximum membership of a group, and the maximum number of groups to which a user can concurrently be associated.
This component also provides requirements for the access control security functions to be able to explicitly authorise or deny access to an object based upon security attributes. This could be used to provide privilege, access rights, or access authorisations within the TOE. Such privileges, rights, or authorisations could apply to users, subjects (representing users or applications), and objects.
Operations
Assignment:
In FDP_ACF.1.1, the PP/ST author should specify an access control
SFP name that the TSF is to enforce. The name of the access control
SFP, and the scope of control for that policy are defined in components from FDP_ACC.
In FDP_ACF.1.1, the PP/ST author should specify the security attributes and/or named groups of security attributes that the function will use in the specification of the rules. For example, such attributes may be things such as the user identity, subject identity, role, time of day, location, ACLs, or any other attribute specified by the PP/ST author. Named groups of security attributes can be specified to provide a convenient means to refer to multiple security attributes. Named groups could provide a useful way to associate “roles” defined in
FMT_SMR Security management roles, and all of their relevant attributes, with subjects. In other words, each role could relate to a named group of attributes.
In FDP_ACF.1.2, the PP/ST author should specify the SFP rules governing access among controlled subjects and controlled objects using controlled operations on controlled objects. These rules specify when access is granted or denied. It can specify general access control functions (e.g. typical permission bits) or granular access control functions (e.g. ACLs).
In FDP_ACF.1.3, the PP/ST author should specify the rules, based on security attributes, that explicitly authorise access of subjects to objects that will be used to explicitly authorise access. These rules are in addition to those specified in FDP_ACF.1.1. They are included in
FDP_ACF.1.3 as they are intended to contain exceptions to the rules in
FDP_ACF.1.1. An example of rules to explicitly authorise access is
Version 2.1
August 1999

Access control functions
(FDP_ACF)
766
F - User data protection (FDP) based on a privilege vector associated with a subject that always grants access to objects covered by the access control SFP that has been specified. If such a capability is not desired, then the PP/ST author should specify “none”.
In FDP_ACF.1.4, the PP/ST author should specify the rules, based on security attributes, that explicitly deny access of subjects to objects.
These rules are in addition to those specified in FDP_ACF.1.1. They are included in FDP_ACF.1.4 as they are intended to contain exceptions to the rules in FDP_ACF.1.1. An example of rules to explicitly deny access is based on a privilege vector associated with a subject that always denies access to objects covered by the access control SFP that has been specified. If such a capability is not desired, then the PP/ST author should specify “none”.
August 1999 Version 2.1
Page 229 of 354

F - User data protection (FDP) Data authentication (FDP_DAU)
FDP_DAU
767
Data authentication
This family describes specific functions that can be used to authenticate ‘static’ data.
768
User notes
Components in this family are to be used when there is a requirement for ‘static’ data authentication, i.e. where data is to be signed but not transmitted. (Note that the
FCO_NRO family provides for non-repudiation of origin of information received during a data exchange.)
FDP_DAU.1
Basic data authentication
769
User application notes
This component may be satisfied by one-way hash functions (cryptographic checksum, fingerprint, message digest), to generate a hash value for a definitive document that may be used as verification of the validity or authenticity of its information content.
770
771
Operations
Assignment:
In FDP_DAU.1.1, the PP/ST author should specify the list of objects or information types for which the TSF shall be capable of generating data authentication evidence.
In FDP_DAU.1.2, the PP/ST author should specify the list of subjects that will have the ability to verify data authentication evidence for the objects identified in the previous element. The list of subjects could be very specific, if the subjects are known, or it could be more generic and refer to a “type” of subject such as an identified role.
FDP_DAU.2
Data authentication with identity of guarantor
User application notes
772 This component additionally requires the ability to verify the identity of the user that provided the guarantee of authenticity (e.g. a trusted third party).
Page 230 of 354 Version 2.1
August 1999

Data authentication (FDP_DAU) F - User data protection (FDP)
773
774
Operations
Assignment:
In FDP_DAU.2.1, the PP/ST author should specify the list of objects or information types for which the TSF shall be capable of generating data authentication evidence.
In FDP_DAU.2.2, the PP/ST author should specify the list of subjects that will have the ability to verify data authentication evidence for the objects identified in the previous element as well as the identity of the user that
created the data authentication evidence.
August 1999 Version 2.1
Page 231 of 354

F - User data protection (FDP) Export to outside TSF control (FDP_ETC)
FDP_ETC
775
Export to outside TSF control
This family defines functions for exporting user data from the TOE such that its security attributes either can be explicitly preserved or can be ignored once it has been exported. Consistency of these security attributes are addressed by
FPT_TDC Inter-TSF TSF data consistency.
776
777
FDP_ETC is concerned with limitations on export and association of security attributes with the exported user data.
User notes
This family, and the corresponding Import family FDP_ITC, address how the TOE deals with user data transferred into and outside its control. In principle this family is concerned with the export of user data and its related security attributes.
778
780
A variety of activities might be involved here: a) exporting of user data without any security attributes; b) exporting user data including security attributes where the two are associated with one another and the security attributes unambiguously represent the exported user data.
779
If there are multiple SFPs (access control and/or information flow control) then it may be appropriate to iterate these components once for each named SFP.
FDP_ETC.1
Export of user data without security attributes
User application notes
This component is used to specify the export of user data without the export of its security attributes.
Operations
781
Assignment:
In FDP_ETC.1.1, the PP/ST author should specify the access control
SFP(s) and/or information flow control SFP(s) that will be enforced when exporting user data. The user data that this function exports is scoped by the assignment of these SFPs.
FDP_ETC.2
Export of user data with security attributes
782
User application notes
The user data is exported together with its security attributes. The security attributes are unambiguously associated with the user data. There are several ways of achieving this association. One way that this can be achieved is by physically
Page 232 of 354 Version 2.1
August 1999

Export to outside TSF control
(FDP_ETC)
783
784
F - User data protection (FDP) collocating the user data and the security attributes (e.g. the same floppy), or by using cryptographic techniques such as secure signatures to associate the attributes and the user data. FTP_ITC Inter-TSF trusted channel could be used to assure that the attributes are correctly received at the other trusted IT product while
FPT_TDC Inter-TSF TSF data consistency can be used to make sure that those attributes are properly interpreted. Furthermore, FTP_TRP Trusted path could be used to make sure that the export is being initiated by the proper user.
Operations
Assignment:
In FDP_ETC.2.1, the PP/ST author should specify the access control
SFP(s) and/or information flow control SFP(s) that will be enforced when exporting user data. The user data that this function exports is scoped by the assignment of these SFPs.
In FDP_ETC.2.4, the PP/ST author should specify any additional exportation control rules or “none” if there are no additional exportation control rules. These rules will be enforced by the TSF in addition to the access control SFPs and/or information flow control
SFPs selected in FDP_ETC.2.1.
August 1999 Version 2.1
Page 233 of 354

F - User data protection (FDP) Information flow control policy
(FDP_IFC)
FDP_IFC
785
786
787
788
789
790
Page 234 of 354
Information flow control policy
This family covers the identification of information flow control SFPs; and, for each, specifies the scope of control of the SFP.
Examples of security policies that might satisfy this objective are:
-
-
Bell and La Padula Security model [B&L];
Biba Integrity model [Biba];
Non-Interference [Gogu1,Gogu2].
User notes
The components in this family are capable of identifying the information flow control SFPs to be enforced by the traditional Mandatory Access Control mechanisms that would be found in a TOE. However, they go beyond just the traditional MAC mechanisms and can be used to identify and describe noninterference policies and state-transitions. It further defines the subjects under control of the policy, the information under control of the policy, and operations which cause controlled information to flow to and from controlled subjects for each information flow control SFP in the TOE. The functionality that defines the rules of an information flow control SFP will be defined by other families such as FDP_IFF and FDP_RIP. The access control SFPs named here in FDP_IFC are meant to be used throughout the remainder of the functional components that have an operation that calls for an assignment or selection of an “information flow control SFP.”
These components are quite flexible. They allow the domain of flow control to be specified and there is no requirement that the mechanism be based upon labels. The different elements of the information flow control components also permit different degrees of exception to the policy.
Each SFP covers a set of triplets: subject, information, and operations that cause information to flow to and from subjects. Some information flow control policies may be at a very low level of detail and explicitly describe subjects in terms of processes within an operating system. Other information flow control policies may be at a high level and describe subjects in the generic sense of users or input/output channels. If the information flow control policy is at too high a level of detail, it may not clearly define the desired IT security functions. In such cases, it is more appropriate to include such descriptions of information flow control policies as objectives. Then the desired IT security functions can be specified as supportive of those objectives.
In the second component (FDP_IFC.2 Complete information flow control), each information flow control SFP will cover all possible operations that cause information covered by that SFP to flow to and from subjects covered by that SFP.
Furthermore, all information flows will need to be covered by a SFP. Therefore for each action that causes information to flow, there will be a set of rules that define whether the action is allowed. If there are multiple SFPs that are applicable for a given information flow, all involved SFPs must allow this flow before it is permitted to take place.
Version 2.1
August 1999

Information flow control policy
(FDP_IFC)
F - User data protection (FDP)
791
792
795
796
797
An information flow control SFP covers a well-defined set of operations. The SFPs coverage may be “complete” with respect to some information flows, or it may address only some of the operations that affect the information flow.
An access control SFP controls access to the objects that contain information. An information flow control SFP controls access to the information, independent of its container. 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 flows. The accessor does not have the ability, in the absence of an explicit authorisation, to change the attributes of the information.
793
Information flows and operations can be expressed at multiple levels. In the case of a ST, the information flows and operations might be specified at a system-specific level: TCP/IP packets flowing through a firewall based upon known IP addresses.
For a PP, the information flows and operations might be expressed as types: email, data repositories, observe accesses, etc.
794
The components in this family can be applied multiple times in a PP/ST to different subsets of operations and objects. This will accommodate TOEs that contain multiple policies, each addressing a particular set of objects, subjects, and operations.
FDP_IFC.1
Subset information flow control
User application notes
This component requires that an information flow control policy apply to a subset of the possible operations in the TOE.
Operations
Assignment:
In FDP_IFC.1.1, the PP/ST author should specify a uniquely named information flow control SFP to be enforced by the TSF.
In FDP_IFC.1.1, the PP/ST author should specify the list of subjects, information, and operations which cause controlled information to flow to and from controlled subjects covered by the SFP. As mentioned above, the list of subjects could be at various levels of detail depending on the needs of the PP/ST author. It could specify users, machines, or processes for example. Information could refer to data such as email or network protocols, or more specific objects similar to those specified under an access control policy. If the information that is specified is contained within an object that is subject to an access control policy, then both the access control policy and information flow control policy must be enforced before the specified information could flow to or from the object.
August 1999 Version 2.1
Page 235 of 354

F - User data protection (FDP) Information flow control policy
(FDP_IFC)
FDP_IFC.2
Complete information flow control
User application notes
798
This component requires that all possible operations that cause information to flow to and from subjects included in the SFP, are covered by an information flow control SFP.
799
800
801
The PP/ST author must demonstrate that each combination of information flows and subjects is covered by an information flow control SFP.
Operations
Assignment:
In FDP_IFC.2.1, the PP/ST author should specify a uniquely named information flow control SFP to be enforced by the TSF.
In FDP_IFC.2.1, the PP/ST author should specify the list of subjects and information that will be covered by the SFP. All operations that cause that information to flow to and from subjects will be covered by
the SFP. As mentioned above, the list of subjects could be at various levels of detail depending on the needs of the PP/ST author. It could specify users, machines, or processes for example. Information could refer to data such as email or network protocols, or more specific objects similar to those specified under an access control policy. If the information that is specified is contained within an object that is subject to an access control policy, then both the access control policy and information flow control policy must be enforced before the specified information could flow to or from the object.
Page 236 of 354 Version 2.1
August 1999

Information flow control functions
(FDP_IFF)
F - User data protection (FDP)
FDP_IFF
802
Information flow control functions
This family describes the rules for the specific functions that can implement the information flow control SFPs named in FDP_IFC, which also specifies the scope of control of the policies. It consists of two “trees:” one addressing the common information flow control function issues, and a second addressing illicit information flows (i.e. covert channels) with respect to one or more information flow control
SFPs. This division arises because the issues concerning illicit information flows are, in some sense, orthogonal to the rest of an SFP. Illicit information flows are flows in violation of policy; thus they are not a policy issue.
803
User notes
In order to implement strong protection against disclosure or modification in the face of untrusted software, controls on information flow are required. Access controls alone are not sufficient because they only control access to containers, allowing the information they contain to flow, without controls, throughout a system.
804 In this family, the phrase “types of illicit information flows” is used. This phrase may be used to refer to the categorisation of flows as “Storage Channels” or
“Timing Channels”, or it can refer to improved categorisations reflective of the needs of a PP/ST author.
805
The flexibility of these components allows the definition of a privilege policy within FDP_IFF.1 and FDP_IFF.2 to allow the controlled bypass of all or part of a particular SFP. If there is a need for a predefined approach to SFP bypass, the PP/
ST author should consider incorporating a privilege policy.
FDP_IFF.1
Simple security attributes
806
807
808
User application notes
This component requires security attributes on information, and on subjects that cause that information to flow and subjects that act as recipients of that information.
The attributes of the containers of the information should also be considered if it is desired that they should play a part in information flow control decisions or if they are covered by an access control policy. This component specifies the key rules that are enforced, and describes how security attributes are derived. For example, this component should be used when at least one of the information flow control SFPs in the TSP is based on labels as defined in the Bell and LaPadula security policy model [B&L], but these security attributes do not form a hierarchy.
This component does not specify the details of how a security attribute is assigned
(i.e. user versus process). Flexibility in policy is provided by having assignments that allow specification of additional policy and function requirements, as necessary.
This component also provides requirements for the information flow control functions to be able to explicitly authorise and deny an information flow based upon
August 1999 Version 2.1
Page 237 of 354

F - User data protection (FDP) Information flow control functions
(FDP_IFF)
811
812
813
814
809
810
815
Page 238 of 354 security attributes. This could be used to implement a privilege policy that covers exceptions to the basic policy defined in this component.
Operations
Assignment:
In FDP_IFF.1.1, the PP/ST author should specify the information flow control SFPs enforced by the TSF. The name of the information flow control SFP, and the scope of control for that policy are defined in components from FDP_IFC.
In FDP_IFF.1.1 the PP/ST author should specify the minimum number and type of security attributes that the function will use in the specification of the rules. For example, such attributes may be things such as subject identifier, subject sensitivity level, subject clearance level, information sensitivity level, etc. The minimum number of each type of security attribute should be sufficient to support the environmental needs.
In FDP_IFF.1.2 the PP/ST author should specify for each operation, the security attribute-based relationship that must hold between subject and information security attributes that the TSF will enforce.
In FDP_IFF.1.3 the PP/ST author should specify any additional information flow control SFP rules that the TSF is to enforce. If there are no additional rules then the PP/ST author should specify “none”.
In FDP_IFF.1.4 the PP/ST author should specify any additional SFP capabilities that the TSF is to provide. If there are no additional capabilities then the PP/ST author should specify “none”.
In FDP_IFF.1.5, the PP/ST author should specify the rules, based on security attributes, that explicitly authorise information flows. These rules are in addition to those specified in the preceding elements. They are included in FDP_IFF.1.5 as they are intended to contain exceptions to the rules in the preceding elements. An example of rules to explicitly authorise information flows is based on a privilege vector associated with a subject that always grants the subject the ability to cause an information flow for information that is covered by the SFP that has been specified. If such a capability is not desired, then the PP/ST author should specify “none”.
In FDP_IFF.1.6, the PP/ST author should specify the rules, based on security attributes, that explicitly deny information flows. These rules are in addition to those specified in the preceding elements. They are included in FDP_IFF.1.6 as they are intended to contain exceptions to the rules in the preceding elements. An example of rules to explicitly authorise information flows is based on a privilege vector associated with a subject that always denies the subject the ability to cause an information flow for information that is covered by the SFP that has
Version 2.1
August 1999

Information flow control functions
(FDP_IFF)
F - User data protection (FDP) been specified. If such a capability is not desired, then the PP/ST author should specify “none”.
FDP_IFF.2
Hierarchical security attributes
User application notes
816
817
This component requires that all information flow control SFPs in the TSP use hierarchical security attributes that form a lattice.
For example, it should be used when at least one of the information flow control
SFPs in the TSP is based on labels as defined in the Bell and LaPadula security policy model [B&L] and form a hierarchy.
818
819
820
821
822
823
It is important to note that the hierarchical relationship requirements identified in
FDP_IFF.2.5 need only apply to the information flow control security attributes for the information flow control SFPs that have been identified in FDP_IFF.2.1. This component is not meant to apply to other SFPs such as access control SFPs.
Like the preceding component, this component could also be used to implement a privilege policy that covers rules that allow for the explicit authorisation or denial of information flows.
If it is the case that multiple information flow control SFPs are to be specified, and that each of these SFPs will have their own security attributes that are not related to one another, then the PP/ST author should iterate this component once for each of those SFPs. Otherwise a conflict might arise with the sub-items of FDP_IFF.2.5
since the required relationships will not exist.
Operations
Assignment:
In FDP_IFF.2.1, the PP/ST author should specify the information flow control SFPs enforced by the TSF. The name of the information flow control
SFP, and the scope of control for that policy are defined in components from
FDP_IFC.
In FDP_IFF.2.1 the PP/ST author should specify the minimum number and type of security attributes that the function will use in the specification of the rules. For example, such attributes may be things such as subject identifier, subject sensitivity level, subject clearance level, information sensitivity level, etc. The minimum number of each type of security attribute should be sufficient to support the environmental needs.
In FDP_IFF.2.2 the PP/ST author should specify for each operation, the security attribute-based relationship that must hold between subject and information security attributes that the TSF will enforce. These
August 1999 Version 2.1
Page 239 of 354

F - User data protection (FDP) Information flow control functions
(FDP_IFF)
824
825
826
827 relationships should be based upon the ordering relationships between the security attributes.
In FDP_IFF.2.3 the PP/ST author should specify any additional information flow control SFP rules that the TSF is to enforce. If there are no additional rules then the PP/ST author should specify “none”.
In FDP_IFF.2.4 the PP/ST author should specify any additional SFP capabilities that the TSF is to enforce. If there are no additional rules then the PP/ST author should specify “none”.
In FDP_IFF.2.5, the PP/ST author should specify the rules, based on security attributes, that explicitly authorise information flows. These rules are in addition to those specified in the preceding elements. They are included in FDP_IFF.2.5 as they are intended to contain exceptions to the rules in the preceding elements. An example of rules to explicitly authorise information flows is based on a privilege vector associated with a subject that always grants the subject the ability to cause an information flow for information that is covered by the SFP that has been specified. If such a capability is not desired, then the PP/ST author should specify “none”.
In FDP_IFF.2.6, the PP/ST author should specify the rules, based on security attributes, that explicitly deny information flows. These rules are in addition to those specified in the preceding elements. They are included in
FDP_IFF.2.6 as they are intended to contain exceptions to the rules in the preceding elements. An example of rules to explicitly authorise information flows is based on a privilege vector associated with a subject that always denies the subject the ability to cause an information flow for information that is covered by the SFP that has been specified. If such a capability is not desired, then the PP/ST author should specify “none”.
FDP_IFF.3
Limited illicit information flows
User application notes
828
829
830
This component should be used when at least one of the SFPs that requires control of illicit information flows does not require elimination of flows.
For the specified illicit information flows, certain maximum capacities should be provided. In addition a PP/ST author has the ability to specify whether the illicit information flows must be audited.
Operations
Assignment:
In FDP_IFF.3.1 the PP/ST author should specify the information flow control SFPs enforced by the TSF. The name of the information flow
Page 240 of 354 Version 2.1
August 1999

Information flow control functions
(FDP_IFF)
F - User data protection (FDP)
831
832 control SFP, and the scope of control for that policy are defined in components from FDP_IFC.
In FDP_IFF.3.1 the PP/ST author should specify the types of illicit information flows that are subject to a maximum capacity limitation.
In FDP_IFF.3.1 the PP/ST author should specify the maximum capacity permitted for any identified illicit information flows.
FDP_IFF.4
Partial elimination of illicit information flows
User application notes
833
834
835
836
837
This component should be used when all the SFPs that requires control of illicit information flows require elimination of some (but not necessarily all) illicit information flows.
Operations
Assignment:
In FDP_IFF.4.1 the PP/ST author should specify the information flow control SFPs enforced by the TSF. The name of the information flow control
SFP, and the scope of control for that policy are defined in components from
FDP_IFC.
In FDP_IFF.4.1 the PP/ST author should specify the types of illicit information flows which are subject to a maximum capacity limitation.
In FDP_IFF.4.1 the PP/ST author should specify the maximum capacity permitted for any identified illicit information flows.
In FDP_IFF.4.2 the PP/ST author should specify the types of illicit information flows to be eliminated. This list may not be empty as this component requires that some illicit information flows are to be eliminated.
FDP_IFF.5
No illicit information flows
User application notes
838
This component should be used when the SFPs that require control of illicit information flows require elimination of all illicit information flows. However, the
PP/ST author should carefully consider the potential impact that eliminating all illicit information flows might have on the normal functional operation of the TOE.
Many practical applications have shown that there is an indirect relationship between illicit information flows and normal functionality within a TOE and eliminating all illicit information flows may result in less than desired functionality.
August 1999 Version 2.1
Page 241 of 354

F - User data protection (FDP) Information flow control functions
(FDP_IFF)
839
Operations
Assignment:
In FDP_IFF.5.1 the PP/ST author should specify the information flow control SFP for which illicit information flows are to be eliminated. The name of the information flow control SFP, and the scope of control for that policy are defined in components from FDP_IFC.
FDP_IFF.6
Illicit information flow monitoring
User application notes
840
841
842
843
This component should be used when it is desired that the TSF provide the ability to monitor the use of illicit information flows that exceed a specified capacity. If it is desired that such flows be audited, then this component could serve as the source of audit events to be used by components from the FAU_GEN Security audit data generation family.
Operations
Assignment:
In FDP_IFF.6.1 the PP/ST author should specify the information flow control SFPs enforced by the TSF. The name of the information flow control SFP, and the scope of control for that policy are defined in components from FDP_IFC.
In FDP_IFF.6.1 the PP/ST author should specify the types of illicit information flows that will be monitored for exceeding a maximum capacity.
In FDP_IFF.6.1 the PP/ST author should specify the maximum capacity above which illicit information flows will be monitored by the
TSF.
Page 242 of 354 Version 2.1
August 1999

Import from outside TSF control
(FDP_ITC)
F - User data protection (FDP)
846
847
848
849
FDP_ITC
844
845
850
851
August 1999
Im port from outside TSF control
This family defines mechanisms for importing user data from outside the TSC into the TOE such that the user data security attributes can be preserved. Consistency of these security attributes are addressed by FPT_TDC Inter-TSF TSF data consistency.
FDP_ITC is concerned with limitations on import, user specification of security attributes, and association of security attributes with the user data.
User notes
This family, and the corresponding export family FDP_ETC, address how the TOE deals with user data outside its control. This family is concerned with assigning and abstraction of the user data security attributes.
A variety of activities might be involved here: a) importing user data from an unformatted medium (e.g. floppy disk, tape, scanner, video or audit signal), without including any security attributes, and physically marking the medium to indicate its contents; b) c) importing user data, including security attributes, from a medium and verifying that the object security attributes are appropriate; importing user data, including security attributes, from a medium using a cryptographic sealing technique to protect the association of user data and security attributes.
This family is not concerned with the determination of whether the user data may be imported. It is concerned with the values of the security attributes to associate with the imported user data.
There are two possibilities for the import of user data: either the user data is unambiguously associated with reliable object security attributes (values and meaning of the security attributes is not modified), or no reliable security attributes
(or no security attributes at all) are available from the import source. This family addresses both cases.
If there are reliable security attributes available, they may have been associated with the user data by physical means (the security attributes are on the same media), or by logical means (the security attributes are distributed differently, but include unique object identification, e.g. cryptographic checksum).
This family is concerned with importing user data and maintaining the association of security attributes as required by the SFP. Other families are concerned with other import aspects such as consistency, trusted channels, and integrity that are beyond the scope of this family. Furthermore, FDP_ITC is only concerned with the interface to the import medium. FDP_ETC is responsible for the other end point of the medium (the source).
Version 2.1
Page 243 of 354

F - User data protection (FDP) Import from outside TSF control
(FDP_ITC)
852
Some of the well known import requirements are: a) importing of user data without any security attributes; b) importing of user data including security attributes where the two are associated with one another and the security attributes unambiguously represent the information being imported.
853 These import requirements may be handled by the TSF with or without human intervention, depending on the IT limitations and the organisational security policy.
For example, if user data is received on a “confidential” channel, the security attributes of the objects will be set to “confidential”.
854
If there are multiple SFPs (access control and/or information flow control) then it may be appropriate to iterate these components once for each named SFP.
FDP_ITC.1
Import of user data without security attributes
User application notes
855
This component is used to specify the import of user data that does not have reliable
(or any) security attributes associated with it. This function requires that the security attributes for the imported user data be initialised within the TSF. It could also be the case that the PP/ST author specifies the rules for import. It may be appropriate, in some environments, to require that these attributes be supplied via a trusted path or a trusted channel mechanism.
Operations
856
857
Assignment:
In FDP_ITC.1.1, the PP/ST author should specify the access control
SFP and/or information flow control SFP that will be enforced when importing user data from outside of the TSC. The user data that this function imports is scoped by the assignment of these SFPs.
In FDP_ITC.1.3, the PP/ST author should specify any additional importation control rules or “none” if there are no additional importation control rules. These rules will be enforced by the TSF in addition to the access control SFPs and/or information flow control
SFPs selected in FDP_ITC.1.1.
FDP_ITC.2
Import of user data with security attributes
User application notes
858
This component is used to specify the import of user data that has reliable security attributes associated with it. This function relies upon the security attributes that are accurately and unambiguously associated with the objects on the import medium.
Once imported, those objects will have those same attributes. This requires
Page 244 of 354 Version 2.1
August 1999

Import from outside TSF control
(FDP_ITC)
859
860
F - User data protection (FDP)
FPT_TDC to ensure the consistency of the data. It could also be the case that the
PP/ST author specifies the rules for import.
Operations
Assignment:
In FDP_ITC.2.1, the PP/ST author should specify the access control
SFP and/or information flow control SFP that will be enforced when importing user data from outside of the TSC. The user data that this function imports is scoped by the assignment of these SFPs
In FDP_ITC.2.5, the PP/ST author should specify any additional importation control rules or “none” if there are no additional importation control rules. These rules will be enforced by the TSF in addition to the access control SFPs and/or information flow control
SFPs selected in FDP_ITC.2.1.
August 1999 Version 2.1
Page 245 of 354

F - User data protection (FDP) Internal TOE transfer (FDP_ITT)
FDP_ITT
861
Internal TOE transfer
This family provides requirements that address protection of user data when it is transferred between parts of a TOE across an internal channel. This may be contrasted with the FDP_UCT and FDP_UIT family, which provide protection for user data when it is transferred between distinct TSFs across an external channel, and FDP_ETC and FDP_ITC, which address transfer of data to or from outside the
TSF’s Control.
862
863
864
User notes
The requirements in this family allow a PP/ST author to specify the desired security for user data while in transit within the TOE. This security could be protection against disclosure, modification, or loss of availability.
The determination of the degree of physical separation above which this family should apply depends on the intended environment of use. In a hostile environment, there may be risks arising from transfers between parts of the TOE separated by only a system bus. In more benign environments, the transfers may be across more traditional network media.
If there are multiple SFPs (access control and/or information flow control) then it may be appropriate to iterate these components once for each named SFP.
FDP_ITT.1
Basic internal transfer protection
Operations
865
866
Assignment:
In FDP_ITT.1.1, the PP/ST author should specify the access control
SFP(s) and/or information flow control SFP(s) covering the information being transferred.
Selection:
In FDP_ITT.1.1 the PP/ST author should specify the types of transmission errors that the TSF should prevent occuring for user data while in transport. The options are disclosure, modification, loss of use.
FDP_ITT.2
Transmission separation by attribute
867
User application notes
This component could, for example, be used to provide different forms of protection to information with different clearance levels.
868 One of the ways to achieve separation of data when it is transmitted is through the use of separate logical or physical channels.
Page 246 of 354 Version 2.1
August 1999

Internal TOE transfer (FDP_ITT) F - User data protection (FDP)
869
870
871
Operations
Assignment:
In FDP_ITT.2.1, the PP/ST author should specify the access control SFP(s) and/or information flow control SFP(s) covering the information being transferred.
Selection:
In FDP_ITT.2.1 the PP/ST author should specify the types of transmission errors that the TSF should prevent occuring for user data while in transport.
The options are disclosure, modification, loss of use.
Assignment:
In FDP_ITT.2.2, the PP/ST author should specify the security attributes, the values of which the TSF will use to determine when to separate data that is being trasmitted between physically-separated parts of the TOE. An example is that user data associated with the identity of one owner is transmitted separately from the user data associated with the identify of a different owner. In this case, the value of the identity of the owner of the data is what is used to determine when to separate the data for transmission.
FDP_ITT.3
Integrity monitoring
872
User application notes
This component is used in combination with either FDP_ITT.1 or FDP_ITT.2. It ensures that the TSF checks received user data (and their attributes) for integrity.
FDP_ITT.1 or FDP_ITT.2 will provide the data in a manner such that it is protected from modification (so that FDP_ITT.3 can detect any modifications).
873
874
The PP/ST author has to specify the types of errors that must be detected. The PP/
ST author should consider: modification of data, substitution of data, unrecoverable ordering change of data, replay of data, incomplete data, in addition to other integrity errors.
The PP/ST author must specify the actions that the TSF should take on detection of a failure. For example: ignore the user data, request the data again, inform the authorised administrator, reroute traffic for other lines.
August 1999 Version 2.1
Page 247 of 354

F - User data protection (FDP) Internal TOE transfer (FDP_ITT)
875
876
877
Operations
Assignment:
In FDP_ITT.3.1, the PP/ST author should specify the access control
SFP(s) and/or information flow control SFP(s) covering the information being transferred and monitored for integrity errors.
In FDP_ITT.3.1, the PP/ST author should specify the type of possible integrity errors to be monitored during transmission of the user data.
In FDP_ITT.3.2, the PP/ST author should specify the action to be taken by the TSF when an integrity error is encountered. An example might be that the TSF should request the resubmission of the user data. The
SFP(s) specified in FDP_ITT.3.1 will be enforced as the actions are taken by the TSF.
FDP_ITT.4
Attribute-based integrity monitoring
878
This component is used in combination with FDP_ITT.2. It ensures that the TSF checks received user data, that has been transmitted by separate channels (based on values of specified security attributes), for integrity. It allows the PP/ST author to specify actions to be taken upon detection of an integrity error.
879
880
881
882
For example, this component could be used to provide different integrity error detection and action for information at different integrity levels.
The PP/ST author has to specify the types of errors that must be detected. The PP/
ST author should consider: modification of data, substitution of data, unrecoverable ordering change of data, replay of data, incomplete data, in addition to other integrity errors.
The PP/ST author should specify the attributes (and associated transmission channels) that necessitate integrity error monitoring
The PP/ST author must specify the actions that the TSF should take on detection of a failure. For example: ignore the user data, request the data again, inform the authorised administrator, reroute traffic for other lines.
Page 248 of 354 Version 2.1
August 1999

Internal TOE transfer (FDP_ITT) F - User data protection (FDP)
883
884
885
886
Operations
Assignment:
In FDP_ITT.4.1, the PP/ST author should specify the access control SFP(s) and/or information flow control SFP(s) covering the information being transferred and monitored for integrity errors.
In FDP_ITT.4.1, the PP/ST author should specify the type of possible integrity errors to be monitored during transmission of the user data.
In FDP_ITT.4.1, the PP/ST author should specify a list of security attributes that require separate transmission channels. This list is used to determine which user data to monitor for integrity errors., based on its security attributes and its transmission channel. This element is directly related to FDP_ITT.2 Transmission separation by attribute.
In FDP_ITT.4.2, the PP/ST author should specify the action to be taken by the TSF when an integrity error is encountered. An example might be that the TSF should request the resubmission of the user data. The SFP(s) specified in FDP_ITT.3.1 will be enforced as the actions are taken by the
TSF.
August 1999 Version 2.1
Page 249 of 354

F - User data protection (FDP) Residual information protection
(FDP_RIP)
FDP_RIP
887
888
889
890
891
892
893
Page 250 of 354
Residual information protection
This family addresses the need to ensure that deleted information is no longer accessible, and that newly-created objects do not contain information from previously used objects within the TOE. This family does not address objects stored off-line.
User notes
This family requires protection for information that has been logically deleted or released (not available to the user but still within the system and may be recoverable). In particular, this includes information that is contained in an object, as part of the TSF reusable resources, where destruction of the object does not necessarily equate to destruction of the resource or any contents of the resource.
It also applies to resources that are serially reused by different subjects within the system. For example, most operating systems typically rely upon hardware registers
(resources) to support processes within the system. As processes are swapped from a “run” state to a “sleep” state (and vice versa), these registers are serially reused by different subjects. While this “swapping” action may not be considered an allocation or deallocation of a resource, FDP_RIP could apply to such events and resources.
FDP_RIP typically controls access to information that is not part of any currently defined or accessible object; however, in certain cases this may not be true. For example, object “A” is a file and object “B” is the disk upon which that file resides.
If object “A” is deleted, the information from object “A” is under the control of
FDP_RIP even though it is still part of object “B”.
It is important to note that FDP_RIP applies only to on-line objects and not off-line objects such as those backed-up on tapes. For example, if a file is deleted in the
TOE, FDP_RIP can be instantiated to require that no residual information exists upon deallocation; however, the TSF cannot extend this enforcement to that same file that exists on the off-line back-up. Therefore that same file is still available. If this is a concern, then the PP/ST author should make sure that the proper environmental objectives are in place to support administrative guidance to address off-line objects.
FDP_RIP and FDP_ROL can conflict when FDP_RIP is instantiated to require that residual information be cleared at the time the application releases the object to the
TSF (i.e. upon deallocation). Therefore, the FDP_RIP selection of “deallocation” should not be used with FDP_ROL since there would be no information to roll back.
The other selection, “unavailability upon allocation”, may be used with FDP_ROL, but there is the risk that the resource which held the information has been allocated to a new object before the roll back took place. If that were to occur, then the roll back would not be possible.
There are no audit requirements in FDP_RIP because this is not a user-invokable function. Auditing of allocated or deallocated resources would be auditable as part of the access control SFP or the information flow control SFP operations.
Version 2.1
August 1999

Residual information protection
(FDP_RIP)
F - User data protection (FDP)
894
This family should apply to the objects specified in the access control SFP(s) or the information flow control SFP(s) as specified by the PP/ST author.
FDP_RIP.1
Subset residual information protection
User application notes
895
896
897
This component requires that, for a subset of the objects in the TOE, the TSF will ensure that there is no available residual information contained in a resource allocated to those objects or deallocated from those objects.
Operations
Selection:
In FDP_RIP.1.1, the PP/ST author should specify the event, allocation of the resource to or deallocation of the resource from, that invokes the residual information protection function.
Assignment:
In FDP_RIP.1.1, the PP/ST author should specify the list of objects subject to residual information protection.
FDP_RIP.2
Full residual information protection
User application notes
898
This component requires that for all objects in the TOE, the TSF will ensure that there is no available residual information contained in a resource allocated to those objects or deallocated from those objects.
899
Operations
Selection:
In FDP_RIP.2.1, the PP/ST author should specify the event, allocation of the resource to or deallocation of the resource from, that invokes the residual information protection function.
August 1999 Version 2.1
Page 251 of 354

F - User data protection (FDP) Rollback (FDP_ROL)
FDP_ROL
900
Rollback
This family addresses the need to return to a well defined valid state, such as the need of a user to undo modifications to a file or to undo transactions in case of an incomplete series of transaction as in the case of databases.
901
902
905
906
907
908
This family is intended to assist a user in returning to a well defined valid state after the user undoes the last set of actions, or, in distributed databases, the return of all of the distributed copies of the databases to the state before an operation failed.
FDP_RIP and FDP_ROL conflict when FDP_RIP enforces that the contents will be made unavailable at the time that a resource is deallocated from an object.
Therefore, this use of FDP_RIP cannot be combined with FDP_ROL as there would be no information to roll back. FDP_RIP can be used only with FDP_ROL when it enforces that the contents will be unavailable at the time that a resource is allocated to an object. This is because the FDP_ROL mechanism will have an opportunity to access the previous information that may still be present in the TOE in order to successfully roll back the operation.
903 The rollback requirement is bounded by certain limits. For example a text editor typically only allows you roll back up to a certain number of commands. Another example would be backups. If backup tapes are rotated, after a tape is reused, the information can no longer be retrieved. This also poses a bound on the rollback requirement.
FDP_ROL.1
Basic rollback
904
User application notes
This component allows a user or subject to undo a set of operations on a predefined set of objects. The undo is only possible within certain limits, for example up to a number of characters or up to a time limit.
Operations
Assignment:
In FDP_ROL.1.1, the PP/ST author should specify the access control
SFP(s) and/or information flow control SFP(s) that will be enforced when performing rollback operations. This is necessary to make sure that roll back is not used to circumvent the specified SFPs.
In FDP_ROL.1.1 the PP/ST author should specify the list of operations that can be rolled back.
In FDP_ROL.1.1 the PP/ST author should specify the list of objects that are subjected to the rollback policy.
In FDP_ROL.1.2 the PP/ST author should specify the boundary limit to which rollback operations may be performed. The boundary may be
Page 252 of 354 Version 2.1
August 1999

Rollback (FDP_ROL) F - User data protection (FDP) specified as a predefined period of time, for example, operations may be undone which were performed within the past two minutes. Other possible boundaries may be defined as the maximum number of operations allowable or the size of a buffer.
FDP_ROL.2
Advanced rollback
User application notes
909
910
911
912
This component enforces that the TSF provide the capability to rollback all operations; however, the user can choose to rollback only a part of them.
Operations
Assignment:
In FDP_ROL.2.1, the PP/ST author should specify the access control SFP(s) and/or information flow control SFP(s) that will be enforced when performing rollback operations. This is necessary to make sure that roll back is not used to circumvent the specified SFPs.
In FDP_ROL.2.1 the PP/ST author should specify the list of objects that are subjected to the rollback policy.
In FDP_ROL.2.2 the PP/ST author should specify the boundary limit to which rollback operations may be performed. The boundary may be specified as a predefined period of time, for example, operations may be undone which were performed within the past two minutes. Other possible boundaries may be defined as the maximum number of operations allowable or the size of a buffer.
August 1999 Version 2.1
Page 253 of 354

F - User data protection (FDP) Stored data integrity (FDP_SDI)
FDP_SDI
913
Stored data integrity
This family provides requirements that address protection of user data while it is stored within the TSC.
914
915
User notes
Hardware glitches or errors may affect data stored in memory. This family provides requirements to detect these unintentional errors. The integrity of user data while stored on storage devices within the TSC are also addressed by this family.
To prevent a subject from modifying the data, the FDP_IFF or FDP_ACF families are required (rather than this family).
916
This family differs from FDP_ITT Internal TOE transfer that protects the user data from integrity errors while being transferred within the TOE.
FDP_SDI.1
Stored data integrity monitoring
917
918
919
User application notes
This component monitors data stored on media for integrity errors. The PP/ST author can specify different kinds of user data attributes that will be used as the basis for monitoring.
Operations
Assignment:
In FDP_SDI.1.1 the PP/ST author should specify the integrity errors that the TSF will detect.
In FDP_SDI.1.1 the PP/ST author should specify the user data attributes that will be used as the basis for the monitoring.
FDP_SDI.2
Stored data integrity monitoring and action
User application notes
920 This component monitors data stored on media for integrity errors. The PP/ST author can specify which action should be taken in case an integrity error is detected.
Page 254 of 354 Version 2.1
August 1999

Stored data integrity (FDP_SDI) F - User data protection (FDP)
921
922
923
Operations
Assignment:
In FDP_SDI.2.1 the PP/ST author should specify the integrity errors that the
TSF will detect.
In FDP_SDI.2.1 the PP/ST author should specify the user data attributes that will be used as the basis for the monitoring.
In FDP_SDI.2.2 the PP/ST author should specify the actions to be taken in case an integrity error is detected.
August 1999 Version 2.1
Page 255 of 354

F - User data protection (FDP) Inter-TSF user data confidentiality transfer protection (FDP_UCT)
FDP_UCT
924
Inter-TSF user data confidentiality transfer protection
This family defines the requirements for ensuring the confidentiality of user data when it is transferred using an external channel between the TOE and another trusted IT product. Confidentiality is enforced by preventing unauthorised disclosure of user data in transit between the two end points. The end points may be a TSF or a user.
925
User notes
This family provides a requirement for the protection of user data during transit. In contrast, FTP_ITC handles TSF data.
FDP_UCT.1
Basic data exchange confidentiality
926
User application notes
The TSF has the ability to protect from disclosure some user data which is exchanged.
927
928
Operations
Assignment:
In FDP_UCT.1.1, the PP/ST author should specify the access control
SFP(s) and/or information flow control SFP(s) that will be enforced when exchanging user data. The specified policies will be enforced to make decisions about who can exchange data and which data can be exchanged.
Selection:
In FDP_UCT.1.1, the PP/ST author should specify whether this element applies to a mechanism that transmits or receives user data.
Page 256 of 354 Version 2.1
August 1999

Inter-TSF user data integrity transfer protection (FDP_UIT)
F - User data protection (FDP)
FDP_UIT
929
Inter-TSF user data integrity transfer protection
This family defines the requirements for providing integrity for user data in transit between the TSF and another trusted IT product and recovering from detectable errors. At a minimum, this family monitors the integrity of user data for modifications. Furthermore, this family supports different ways of correcting detected integrity errors.
930
User notes
This family defines the requirements for providing integrity for user data in transit; while FPT_ITI handles TSF data.
931
FDP_UIT and FDP_UCT are duals of each other, as FDP_UCT addresses user data confidentiality. Therefore, the same mechanism that implements FDP_UIT could possibly be used to implement other families such as FDP_UCT and FDP_ITC.
FDP_UIT.1
Data exchange integrity
932
933
934
935
936
User application notes
The TSF has a basic ability to send or receive user data in a manner such that modification of the user data can be detected. There is no requirement for a TSF mechanism to attempt to recover from the modification.
Operations
Assignment:
In FDP_UIT.1.1, the PP/ST author should specify the access control
SFP(s) and/or information flow control SFP(s) that will be enforced on the transmitted data or on the received data. The specified policies will be enforced to make decisions about who can transmit or who can receive data, and which data can be transmitted or received.
Selection:
In FDP_UIT.1.1, the PP/ST author should specify whether this element applies to a TSF that is transmitting or receiving objects.
In FDP_UIT.1.1 the PP/ST author should specify whether the data should be protected from modification, deletion, insertion or replay.
In FDP_UIT.1.2 the PP/ST author should specify whether the errors of the type: modification, deletion, insertion or replay are detected.
August 1999 Version 2.1
Page 257 of 354

F - User data protection (FDP) Inter-TSF user data integrity transfer protection (FDP_UIT)
FDP_UIT.2
Source data exchange recovery
User application notes
937
This component provides the ability to recover from a set of identified transmission errors, if required, with the help of the other trusted IT product. As the other trusted
IT product is outside the TSC, the TSF cannot control its behaviour. However, it can provide functions that have the ability to cooperate with the other trusted IT product for the purposes of recovery. For example, the TSF could include functions that depend upon the source trusted IT product to re-send the data in the event that an error is detected. This component deals with the ability of the TSF to handle such an error recovery.
938
939
Operations
Assignment:
In FDP_UIT.2.1, the PP/ST author should specify the access control
SFP(s) and/or information flow control SFP(s) that will be enforced when recovering user data. The specified policies will be enforced to make decisions about which data can be recovered and how it can be recovered.
In FDP_UIT.2.1, the PP/ST author should specify the list of integrity errors from which the TSF, with the help of the source trusted IT product, is be able to recover the original user data.
FDP_UIT.3
Destination data exchange recovery
User application notes
940
941
942
This component provides the ability to recover from a set of identified transmission errors. It accomplishes this task without help from the source trusted IT product. For example, if certain errors are detected, the transmission protocol must be robust enough to allow the TSF to recover from the error based on checksums and other information available within that protocol.
Operations
Assignment:
In FDP_UIT.3.1, the PP/ST author should specify the access control SFP(s) and/or information flow control SFP(s) that will be enforced when recovering user data. The specified policies will be enforced to make decisions about which data can be recovered and how it can be recovered.
In FDP_UIT.3.1, the PP/ST author should specify the list of integrity errors from which the receiving TSF, alone, is able to recover the original user data.
Page 258 of 354 Version 2.1
August 1999

944
945
949
950
946
947
948
951
943
A common security requirement is to unambiguously identify the person and/or entity performing functions in a TOE. This involves not only establishing the claimed identity of each user, but also verifying that each user is indeed who he/she claims to be. This is achieved by requiring users to provide the TSF with some information that is known by the TSF to be associated with the user in question.
Families in this class address the requirements for functions to establish and verify a claimed user identity. Identification and Authentication is required to ensure that users are associated with the proper security attributes (e.g. identity, groups, roles, security or integrity levels).
The unambiguous identification of authorised users and the correct association of security attributes with users and subjects is critical to the enforcement of the security policies.
The FIA_UID family addresses determining the identity of a user.
The FIA_UAU family addresses verifying the identity of a user.
The FIA_AFL family addresses defining limits on repeated unsuccessful authentication attempts.
The FIA_ATD family address the definition of user attributes that are used in the enforcement of the TSP.
The FIA_USB family addresses the correct association of security attributes for each authorised user.
The FIA_SOS family addresses the generation and verification of secrets that satisfy a defined metric.
August 1999 Version 2.1
Page 259 of 354

G - Identification and authentication (FIA)
Identification and authentication (FIA)
FIA_AFL Authentication failures
FIA_ATD User attribute definition
FIA_SOS Specification of secrets
FIA_UAU User authentication
FIA_UID User identification
FIA_USB User-subject binding
1
2
5
6
7
1
3
4
1
1
1
1
2
2
Figure G.1 - Identification and authentication class decomposition
Page 260 of 354 2.1
August 1999

Authentication failures (FIA_AFL) G - Identification and authentication (FIA)
FIA_AFL
952
Authentication failures
This family addresses requirements for defining values for authentication attempts and TSF actions in cases of authentication attempt failure. Parameters include, but are not limited to, the number of attempts and time thresholds.
953
The session establishment process is the interaction with the user to perform the session establishment independent of the actual implementation. If the number of unsuccessful authentication attempts exceeds the indicated threshold, either the user account or the terminal (or both) will be locked. If the user account is disabled, the user cannot log-on to the system. If the terminal is disabled, the terminal (or the address that the terminal has) cannot be used for any log-on. Both of these situations continue until the condition for re-establishment is satisfied.
FIA_AFL.1
Authentication failure handling
954
User application notes
The PP/ST author may define the number of unsuccessful authentication attempts or may choose to let the TOE developer or the authorised user to define this number.
The unsuccessful authentication attempts need not be consecutive, but rather related to an authentication event. Such an authentication event could be the count from the last successful session establishment at a given terminal.
955
956
The PP/ST author could specify a list of actions that the TSF shall take in the case of authentication failure. An authorised administrator could also be allowed to manage the events, if deemed opportune by the PP/ST author. These actions could be, among other things, terminal deactivation, user account deactivation, or administrator alarm. The conditions under which the situation will be restored to normal must be specified on the action.
In order to prevent denial of service, TOEs usually ensure that there is at least one user account that cannot be disabled.
957
958
Further actions for the TSF can be stated by the PP/ST author, including rules for re-enabling the user session establishment process, or sending an alarm to the administrator. Examples of these actions are: until a specified time has lapsed, until the authorised administrator re-enables the terminal/account, a time related to failed previous attempts (every time the attempt fails, the disabling time is doubled).
Operations
Assignment:
In FIA_AFL.1.1, if the PP/ST author should specify the default number of unsuccessful authentication attempts that, when met or surpassed,
August 1999 Version 2.1
Page 261 of 354

G - Identification and authentication (FIA) Authentication failures (FIA_AFL)
959
960 will trigger the events. The PP/ST author may specify that the number is: “an authorised administrator configurable number”.
In FIA_AFL.1.1, the PP/ST author should specify the authentication events. Examples of these authentication events are: the unsuccessful authentication attempts since the last successful authentication for the indicated user identity, the unsuccessful authentication attempts since the last successful authentication for the current terminal, the number of unsuccessful authentication attempts in the last 10 minutes. At least one authentication event must be specified.
In FIA_AFL.1.2, the PP/ST author should specify the actions to be taken in case the threshold is met or surpassed. These actions could be disabling of an account for 5 minutes, disabling the terminal for an increasing amount of time (2 to the power of the number of unsuccessful attempts in seconds), or disabling of the account until unlocked by the administrator and simultaneously informing the administrator. The actions should specify the measures and if applicable the duration of the measure (or the conditions under which the measure will be ended).
Page 262 of 354 Version 2.1
August 1999

User attribute definition (FIA_ATD) G - Identification and authentication (FIA)
FIA_ATD
961
User attribute definition
All authorised users may have a set of security attributes, other than the user’s identity, that are used to enforce the TSP. This family defines the requirements for associating user security attributes with users as needed to support the TSP.
962
User notes
There are dependencies on the individual security policy definitions. These individual definitions should contain the listing of attributes that are necessary for policy enforcement.
FIA_ATD.1
User attribute definition
963
964
User application notes
This component specifies the security attributes that should be maintained at the level of the user. This means that the security attributes listed are assigned to and can be changed at the level of the user. In other words, changing a security attribute in this list associated with a user should have no impact on the security attributes of any other user.
In case security attributes belong to a group of users (such as Capability List for a group), the user will need to have a reference (as security attribute) to the relevant group.
965
Operations
Assignment:
In FIA_ATD.1.1, the PP/ST author should specify the security attributes that are associated to an individual user. An example of such a list is {‘clearance’, ‘group identifier’, ‘rights’}.
August 1999 Version 2.1
Page 263 of 354

G - Identification and authentication (FIA) Specification of secrets (FIA_SOS)
FIA_SOS
966
Specification of secrets
This family defines requirements for mechanisms that enforce defined quality metrics on provided secrets, and generate secrets to satisfy the defined metric.
Examples of such mechanisms may include automated checking of user supplied passwords, or automated password generation.
967
968
972
973
A secret can be generated outside the TOE (e.g. selected by the user and introduced in the system). In such cases, the FIA_SOS.1 component can be used to ensure that the external generated secret adheres to certain standards, for example a minimum size, not present in a dictionary, and/or not previously used.
Secrets can also be generated by the TOE. In those cases, the FIA_SOS.2
component can be used to require the TOE to ensure that the secrets that will adhere to some specified metrics.
969
User notes
Secrets contain the authentication data provided by the user for an authentication mechanism that is based on knowledge the user possesses. When cryptographic keys are employed, the class FCS should be used instead of this family.
FIA_SOS.1
Verification of secrets
User application notes
970
Secrets can be generated by the user. This component ensures that those user generated secrets can be verified to meet a certain quality metric.
971
Operations
Assignment:
In FIA_SOS.1.1, the PP/ST author should provide a defined quality metric. The quality metric specification can be as simple as a description of the quality checks to be performed, or as formal as a reference to a government published standard that defines the quality metrics that secrets must meet. Examples of quality metrics could include a description of the alphanumeric structure of acceptable secrets and/or the space size that acceptable secrets must meet.
FIA_SOS.2
TSF generation of secrets
This component allows the TSF to generate secrets for specific functions such as authentication by means of passwords.
User application notes
When a pseudo-random number generator is used in a secret generation algorithm, it should accept as input random data that would provide output that has a high
Page 264 of 354 Version 2.1
August 1999

Specification of secrets (FIA_SOS) G - Identification and authentication (FIA)
974
975 degree of unpredictability. This random data (seed) can be derived from a number of available parameters such as a system clock, system registers, date, time, etc. The parameters should be selected to ensure that the number of unique seeds that can be generated from these inputs should be at least equal to the minimum number of secrets that must be generated.
Operations
Assignment:
In FIA_SOS.2.1, the PP/ST author should provide a defined quality metric. The quality metric specification can be as simple as a description of the quality checks to be performed or as formal as a reference to a government published standard that defines the quality metrics that secrets must meet. Examples of quality metrics could include a description of the alphanumeric structure of acceptable secrets and/or the space size that acceptable secrets must meet.
In FIA_SOS.2.2, the PP/ST author should provide a list of TSF functions for which the TSF generated secrets must be used. An example of such a function could include a password based authentication mechanism.
August 1999 Version 2.1
Page 265 of 354

G - Identification and authentication (FIA) User authentication (FIA_UAU)
FIA_UAU
976
User authentication
This family defines the types of user authentication mechanisms supported by the
TSF. This family defines the required attributes on which the user authentication mechanisms must be based.
FIA_UAU.1
Timing of authentication
977
User application notes
This component requires that the PP/ST author define the TSF-mediated actions that can be performed by the TSF on behalf of the user before the claimed identity of the user is authenticated. The TSF-mediated actions should have no security concerns with users incorrectly identifying themselves prior to being authenticated.
For all other TSF-mediated actions not in the list, the user must be authenticated before the action can be performed by the TSF on behalf of the user.
978 This component cannot control whether the actions can also be performed before the identification took place. This requires the use of either FIA_UID.1 and
FIA_UID.2 with the appropriate assignments.
979
Operations
Assignment:
In FIA_UAU.1.1, the PP/ST author should specify a list of TSFmediated actions that can be performed by the TSF on behalf of a user before the claimed identity of the user is authenticated. This list cannot be empty. If no actions are appropriate, component FIA_UAU.2 should be used instead. An example of such an action might include the request for help on the login procedure.
FIA_UAU.2
User authentication before any action
980
User application notes
This component requires that users are identified before any TSF-mediated action can take place on behalf of that user.
FIA_UAU.3
Unforgeable authentication
981
User application notes
This component addresses requirements for mechanisms that provide protection of authentication data. Authentication data that is copied from another user, or is in some way constructed should be detected and/or rejected. These mechanisms provide confidence that users authenticated by the TSF are actually who they claim to be.
Page 266 of 354 Version 2.1
August 1999

User authentication (FIA_UAU) G - Identification and authentication (FIA)
982
985
This component may be useful only with authentication mechanisms that are based on authentication data that cannot be shared (e.g. biometrics). It is impossible for a
TSF to detect or prevent the sharing of passwords outside the control of the TSF.
983
984
Operations
Selection:
In FIA_UAU.3.1, the PP/ST author should specify whether the TSF will detect, prevent, or detect and prevent forging of authentication data
In FIA_UAU.3.2, the PP/ST author should specify whether the TSF will detect, prevent, or detect and prevent copying of authentication data
FIA_UAU.4
Single-use authentication mechanisms
User application notes
This component addresses requirements for authentication mechanisms based on single-use authentication data. Single-use authentication data can be something the user has or knows, but not something the user is. Examples of single-use authentication data include single-use passwords, encrypted time-stamps, and/or random numbers from a secret lookup table.
986
The PP/ST author can specify to which authentication mechanism(s) this requirement applies.
Operations
987
Assignment:
In FIA_UAU.4.1, the PP/ST author should specify the list of authentication mechanisms to which this requirement applies. This assignment can be ‘all authentication mechanisms’. An example of this assignment could be “the authentication mechanism employed to authenticate people on the external network”.
FIA_UAU.5
Multiple authentication mechanisms
User application notes
988
The use of this component allows specification of requirements for more than one authentication mechanism to be used within a TOE. For each distinct mechanism, applicable requirements must be chosen from the FIA class to be applied to each mechanism. It is possible that the same component could be selected multiple times in order to reflect different requirements for the different use of the authentication mechanism.
August 1999 Version 2.1
Page 267 of 354

G - Identification and authentication (FIA) User authentication (FIA_UAU)
989
990
The management functions in the class FMT may provide maintenance capabilities for the set of authentication mechanisms, as well as the rules that determine whether the authentication was successful.
To allow anonymous users to be on the system, a ‘none’ authentication mechanism can be incorporated. The use of such access should be clearly explained in the rules of FIA_UAU.5.2.
991
992
993
Operations
Assignment:
In FIA_UAU.5.1, the PP/ST author should define the available authentication mechanisms. An example of such a list could be: “none, password mechanism, biometric (retinal scan), S/key mechanism”.
In FIA_UAU.5.2, the PP/ST author should specify the rules that describe how the authentication mechanisms provide authentication and when each is to be used. This means that for each situation the set of mechanisms that might be used for authenticating the user must be described. An example of a list of such rules is:
“if the user has special privileges a password mechanism and a biometric mechanism both shall be used, with success only if both succeed; for all other users a password mechanism shall be used.”
The PP/ST author might give the boundaries within which the authorised administrator may specify specific rules. An example of a rule is: “the user shall always be authenticated by means of a token; the administrator might specify additional authentication mechanisms that also must be used.” The PP/ST author also might choose not to specify any boundaries but leave the authentication mechanisms and their rules completely up to the authorised administrator.
FIA_UAU.6
Re-authenticating
User application notes
994
995
This component addresses potential needs to re-authenticate users at defined points in time. These may include user requests for the TSF to perform security relevant actions, as well as requests from non-TSF entities for re-authentication (e.g. a server application requesting that the TSF re-authenticate the client it is serving).
Operations
Assignment:
In FIA_UAU.6.1, the PP/ST author should specify the list of conditions requiring re-authentication. This list could include a specified user inactivity period that has elapsed, the user requesting a change in active
Page 268 of 354 Version 2.1
August 1999

User authentication (FIA_UAU) G - Identification and authentication (FIA)
996 security attributes, or the user requesting the TSF to perform some security critical function.
The PP/ST author might give the boundaries within which the reauthentication should occur and leave the specifics to the authorised administrator. An example of such a rule is: “the user shall always be re-authenticated at least once a day; the administrator might specify that the re-authentication should happen more often but not more often than once every 10 minutes.”
FIA_UAU.7
Protected authentication feedback
User application notes
997
This component addresses the feedback on the authentication process that will be provided to the user. In some systems the feedback consists of indicating how many characters have been typed but not showing the characters themselves, in other systems even this information might not be appropriate.
998
999
This component requires that the authentication data is not provided as-is back to the user. In a workstation environment, it could display a ‘dummy’ (e.g. star) for each password character provided, and not the original character.
Operations
Assignment:
In FIA_UAU.7.1, the PP/ST author should specify the feedback related to the authentication process that will be provided to the user. An example of a feedback assignment is “the number of characters typed”, another type of feedback is “the authentication mechanism that failed the authentication”.
August 1999 Version 2.1
Page 269 of 354

G - Identification and authentication (FIA) User identification (FIA_UID)
FIA_UID
1000
User identification
This family defines the conditions under which users are required to identify themselves before performing any other actions that are to be mediated by the TSF and that require user identification.
FIA_UID.1
Timing of identification
1001
1002
User application notes
This component poses requirements for the user to be identified. The PP/ST author can indicate specific actions that can be performed before the identification takes place.
If FIA_UID.1 is used, the TSF-mediated actions mentioned in FIA_UID.1 should also appear in this FIA_UAU.1.
Operations
1003
Assignment:
In FIA_UID.1.1, the PP/ST author should specify a list of TSFmediated actions that can be performed by the TSF on behalf of a user before the user has to identify itself. If no actions are appropriate, component FIA_UID.2 should be used instead. An example of such an action might include the request for help on the login procedure.
FIA_UID.2
User identification before any action
1004
User application notes
In this component users will be identified. A user is not allowed by the TSF to perform any action before being identified.
Page 270 of 354 Version 2.1
August 1999

User-subject binding (FIA_USB) G - Identification and authentication (FIA)
FIA_USB
1005
User-subject binding
An authenticated user, in order to use the TOE, typically activates a subject. The user’s security attributes are associated (totally or partially) with this subject. This family defines requirements to create and maintain the association of the user’s security attributes to a subject acting on the user’s behalf.
FIA_USB.1
User-subject binding
User application notes
1006
The phrase “acting on behalf of” has proven to be a contentious issue in previous criteria. It is intended that a subject is acting on behalf of the user who caused the subject to come into being or to be activated to perform a certain task. Therefore, when a subject is created, that subject is acting on behalf of the user who initiated the creation. In case anonymity is used, the subject is still acting on behalf of a user, but the identity of the user is unknown. A special category are the subjects that serve multiple users (e.g. a server process). In such cases the user that created this subject is assumed to be the ‘owner’.
August 1999 Version 2.1
Page 271 of 354

G - Identification and authentication (FIA) User-subject binding (FIA_USB)
Page 272 of 354 Version 2.1
August 1999

1007
1008
This class specifies the management of several aspects of the TSF: security attributes, TSF data and functions in the TSF. The different management roles and their interaction, such as separation of capability, can also be specified
In an environment where the TOE is made up of multiple physically separated parts that form a distributed system, the timing issues with respect to propagation of security attributes, TSF data, and function modification become very complex, especially if the information is required to be replicated across the parts of the TOE.
This should be considered when selecting components such as
FMT_REV.1 Revocation, or FMT_SAE.1 Time-limited authorisation, where the behaviour might be impaired. In such situations, use of components from FPT_TRC is advisable.
August 1999 Version 2.1
Page 273 of 354

Page 274 of 354
H - Security management (FMT)
.
Security management
FMT_MOF Management of functions in TSF
FMT_MSA Management of security attributes
FMT_MTD Management of TSF data
FMT_REV Revocation
FMT_SAE Security attribute expiration
FMT_SMR Security management roles
1
1
2
3
1
2
3
1
1
1
3
2
Figure H.1 - Security management class decomposition
2.1
August 1999

Management of functions in TSF (FMT_MOF) H - Security management (FMT)
FMT_MOF
1009
1010
Management of functions in TSF
The TSF management functions enable authorised users to set up and control the secure operation of the TOE. These administrative functions typically fall into a number of different categories: a) Management functions that relate to access control, accountability and authentication controls enforced by the TOE. For example, definition and update of user security characteristics (e.g. unique identifiers associated with user names, user accounts, system entry parameters) or definition and update of auditing system controls (e.g. selection of audit events, management of audit trails, audit trail analysis, and audit report generation), definition and update of per-user policy attributes (such as user clearance), definition of known system access control labels, and control and management of user groups.
b) Management functions that relate to controls over availability. For example, definition and update of availability parameters or resource quotas.
c) Management functions that relate to general installation and configuration. For example, TOE configuration, manual recovery, installation of TOE security fixes (if any), repair and reinstallation of hardware.
d) Management functions that relate to routine control and maintenance of
TOE resources. For example, enabling and disabling peripheral devices, mounting of removable storage media, backup and recovery of user and system objects.
Note that these functions need to be present in a TOE based on the families included in the PP or ST. It is the responsibility of the PP/ST author to ensure that adequate functions will be provided to manage the system in a secure fashion.
1011 The TSF might contain functions that can be controlled by an administrator. For example, the auditing functions could be switched off, the time synchronisation could be switchable, and/or the authentication mechanism could be modifiable.
FMT_MOF.1
Management of security functions behaviour
1012
This component allows identified roles to manage the security functions of the TSF.
This might entail obtaining the current status of a security function, disabling or enabling the security function, or modifying the behaviour of the security function.
An example of modifying the behaviour of the security functions is changing of authentication mechanisms.
August 1999 Version 2.1
Page 275 of 354

H - Security management (FMT) Management of functions in TSF (FMT_MOF)
1013
1014
1015
Operations
Selection:
In FMT_MOF.1.1 the PP/ST author should select whether the role can determine the behaviour of, disable, enable, and/or modify the behaviour of the security functions.
Assignment:
In FMT_MOF.1.1 the PP/ST author should specify the functions that can be modified by the identified roles. Examples include auditing and time determination.
In FMT_MOF.1.1 the PP/ST author should specify the roles that are allowed to modify the functions in the TSF. The possible roles are specified in FMT_SMR.1.
Page 276 of 354 Version 2.1
August 1999

Management of security attributes (FMT_MSA) H - Security management (FMT)
FMT_MSA
1016
Management of security attributes
This family defines the requirements on the management of security attributes.
1017
1018
1019
1020
Users, subjects and objects have associated security attributes that will affect the behaviour of the TSF. Examples of such security attributes are the groups to which a user belongs, the roles he/she might assume, the priority of a process (subject), and the rights belonging to a role or a user. These security attributes might need to be managed by the user, a subject or a specific authorised user (a user with explicitly given rights for this management).
It is noted that the right to assign rights to users is itself a security attribute and/or potentially subject to management by FMT_MSA.1.
FMT_MSA.2 can be used to ensure that any accepted combination of security attributes is within a secure state. The definition of what “secure” means is left to the TOE guidance and the TSP model. If the developer provided a clear definition of the secure values and the reason why they should be considered secure, the dependency from FMT_MSA.2 to ADV_SPM.1 can be argued away.
In some instances subjects, objects or user accounts are created. If no explicit values for the related security attributes are given, default values need to be used.
FMT_MSA.1 can be used to specify that these default values can be managed.
FMT_MSA.1
Management of security attributes
1021
This component allows users acting in certain roles to manage identified security attributes. The users are assigned to a role within the component FMT_SMR.1.
1022
The default value of a parameter is the value the parameter takes when it is instantiated without specifically assigned values. An initial value is provided during the instantiation (creation) of a parameter, and overrides the default value.
1023
1024
Operations
Assignment:
In FMT_MSA.1.1, the PP/ST author should list the access control SFP or the information flow control SFP for which the security attributes are applicable.
Selection:
In FMT_MSA.1.1 the PP/ST author should specify the operations that can be applied to the identified security attributes. The PP/ST author can specify that the role can modify the default value (change_default), query, modify the security attribute, delete the security attributes entirely or define their own operation.
August 1999 Version 2.1
Page 277 of 354

H - Security management (FMT) Management of security attributes (FMT_MSA)
1025
1026
1027
1029
Assignment:
In FMT_MSA.1.1, if selected, the PP/ST author should specify which other operations the role could perform. An example of such an operation could be ‘create’.
In FMT_MSA.1.1 the PP/ST author should specify the security attributes that can be operated on by the identified roles. It is possible for the PP/ST author to specify that the default value such as default access-rights can be managed. Examples of these security attributes are user-clearance, priority of service level, access control list, default access rights.
In FMT_MSA.1.1 the PP/ST author should specify the roles that are allowed to operate on the security attributes. The possible roles are specified in FMT_SMR.1.
FMT_MSA.2
Secure security attributes
1028
This component contains requirements on the values that can be assigned to security attributes. The assigned values should be such that the TOE will remain in a secure state.
The definition of what ‘secure’ means is not answered in this component but is left to the development of the TOE (specifically ADV_SPM.1 Informal TOE security policy model) and the resulting information in the guidance. An example could be that if a user account is created, it should have a non-trivial password.
FMT_MSA.3
Static attribute initialisation
User application notes
1030
1031
1032
This component requires that the TSF provide default values for relevant object security attributes, which can be overridden by an initial value. It may still be possible for a new object to have different security attributes at creation, if a mechanism exists to specify the permissions at time of creation.
Operations
Assignment:
In FMT_MSA.3.1,the PP/ST author should list the access control SFP or the information flow control SFP for which the security attributes are applicable.
Selection:
In FMT_MSA.3.1, the PP/ST author should select whether the default property of the access control attribute will be restrictive, permissive, or another property. In case of another property, the PP/ST author should refine this to a specific property.
Page 278 of 354 Version 2.1
August 1999

Management of security attributes (FMT_MSA) H - Security management (FMT)
1033
Assignment:
In FMT_MSA.3.2 the PP/ST author should specify the roles that are allowed to modify the values of the security attributes. The possible roles are specified in FMT_SMR.1.
August 1999 Version 2.1
Page 279 of 354

H - Security management (FMT) Management of TSF data (FMT_MTD)
FMT_MTD
1034
Management of TSF data
This component imposes requirements on the management of TSF data. Examples of TSF data are the current time and the audit trail. So, for example, this family allows the specification of whom can read, delete or create the audit trail.
FMT_MTD.1
Management of TSF data
1035
1036
This component allows users with a certain role to manage values of TSF data. The users are assigned to a role within the component FMT_SMR.1.
The default value of a parameter is the values the parameter takes when it is instantiated without specifically assigned values. An initial value is provided during the instantiation (creation) of a parameter and overrides the default value.
1037
1038
1039
1040
Operations
Selection:
In FMT_MTD.1.1 the PP/ST author should specify the operations that can be applied to the identified TSF data. The PP/ST author can specify that the role can modify the default value (change_default), clear, query or modify the TSF data, or delete the TSF data entirely. If so desired the PP/ST author could specify any type of operation. To clarify “clear
TSF data” means that the content of the TSF data is removed, but that the entity itself remains in the system.
Assignment:
In FMT_MTD.1.1, if selected, the PP/ST author should specify which other operations the role could perform. An example could be ‘create’.
In FMT_MTD.1.1 the PP/ST author should specify the TSF data that can be operated on by the identified roles. It is possible for the PP/ST author to specify that the default value can be managed.
In FMT_MTD.1.1 the PP/ST author should specify the roles that are allowed to operate on the TSF data. The possible roles are specified in
FMT_SMR.1.
FMT_MTD.2
Management of limits on TSF data
1041
This component specifies limits on TSF data, and actions to be taken if these limits are exceeded. This component, for example, will allow limits on the size of the audit trail to be defined, and specification of the actions to be taken when these limits are exceeded.
Page 280 of 354 Version 2.1
August 1999

Management of TSF data (FMT_MTD) H - Security management (FMT)
1042
1043
1044
Operations
Assignment:
In FMT_MTD.2.1 the PP/ST author should specify the TSF data that can have limits, and the value of those limits. An example of such TSF data is the number of users logged-in.
In FMT_MTD.2.1 the PP/ST author should specify the roles that are allowed to modify the limits on the TSF data and the actions to be taken.
The possible roles are specified in FMT_SMR.1.
In FMT_MTD.2.2 the PP/ST author should specify the actions to be taken if the specified limit on the specified TSF data is exceeded. An example of such TSF action is that the authorised user is informed and an audit record is generated.
FMT_MTD.3
Secure TSF data
1045
This component covers requirements on the values that can be assigned to TSF data.
The assigned values should be such that the TOE will remain in a secure state.
1046
The definition of what ‘secure’ means is not answered in this component but is left to the development of the TOE (specifically ADV_SPM.1 Informal TOE security policy model) and the resulting information in the guidance. If the developer provided a clear definition of the secure values and the reason why they should be considered secure, the dependency from FMT_MSA.2 to ADV_SPM.1 can be argued away.
August 1999 Version 2.1
Page 281 of 354

H - Security management (FMT) Revocation (FMT_REV)
FMT_REV
1047
Revocation
This family addresses revocation of security attributes for a variety of entities within a TOE.
FMT_REV.1
Revocation
1048
This component specifies requirements on the revocation of rights. It requires the specification of the revocation rules. Examples are: a) Revocation will take place on the next login of the user; b) Revocation will take place on the next attempt to open the file;
1049
1050
1051 c) Revocation will take place within a fixed time. This might mean that all open connections are re-evaluated every x minutes.
Operations
Selection:
In FMT_REV.1.1, the PP/ST author should specify whether the ability to revoke security attributes from users, subjects, objects, or any other resources shall be provided by the TSF. If the last option is chosen, then the PP/ST author should use the refinement operation to define the resources.
Assignment:
In FMT_REV.1.1 the PP/ST author should specify the roles that are allowed to modify the functions in the TSF. The possible roles are specified in FMT_SMR.1.
In FMT_REV.1.2, the PP/ST author should specify the revocation rules. Examples of these rules could include: “prior to the next operation on the associated resource”, or “for all new subject creations”.
Page 282 of 354 Version 2.1
August 1999

Security attribute expiration (FMT_SAE) H - Security management (FMT)
FMT_SAE
1052
Security attribute expiration
This family addresses the capability to enforce time limits for the validity of security attributes. This family can be applied to specify expiration requirements for access control attributes, identification and authentication attributes, certificates
(key certificates such as ANSI X509 for example), audit attributes, etc.
FMT_SAE.1
Time-limited authorisation
Operations
1053
1054
1055
Assignment:
For FMT_SAE.1.1, the PP/ST author should provide the list of security attributes for which expiration is to be supported. An example of such an attribute might be a user’s security clearance.
In FMT_SAE.1.1 the PP/ST author should specify the roles that are allowed to modify the security attributes in the TSF. The possible roles are specified in FMT_SMR.1.
For FMT_SAE.1.2, the PP/ST author should provide a list of actions to be taken for each security attribute when it expires. An example might be that the user’s security clearance, when it expires, is set to the lowest allowable clearance on the TOE. If immediate revocation is desired by the PP/ST, the action “immediate revocation” should be specified.
August 1999 Version 2.1
Page 283 of 354

H - Security management (FMT) Security management roles (FMT_SMR)
FMT_SMR
1056
Security management roles
This family reduces the likelihood of damage resulting from users abusing their authority by taking actions outside their assigned functional responsibilities. It also addresses the threat that inadequate mechanisms have been provided to securely administer the TSF.
1057
1058
1059
1060
This family requires that information be maintained to identify whether a user is authorised to use a particular security-relevant administrative function.
Some management actions can be performed by users, others only by designated people within the organisation. This family allows the definition of different roles, such as owner, auditor, administrator, daily-management.
The roles as used in this family are security related roles. Each role can encompass an extensive set of capabilities (e.g. root in UNIX), or can be a single right (e.g.
right to read a single object such as the helpfile). This family defines the roles. The capabilities of the role are defined in FMT_MOF, FMT_MSA and FMT_MTD.
Some type of roles might be mutually exclusive. For example the dailymanagement might be able to define and activate users, but might not be able to remove users (which is reserved for the administrator (role)). This class will allow policies such as two-person control to be specified.
FMT_SMR.1
Security roles
1061
This component specifies the different roles that the TSF should recognise. Often the system distinguishes between the owner of an entity, an administrator and other users.
1062
Operations
Assignment:
In FMT_SMR.1.1 the PP/ST author should specify the roles that are recognised by the system. These are the roles that users could occupy with respect to security. Examples are: owner, auditor and administrator.
FMT_SMR.2
Restrictions on security roles
1063
1064
This component specifies the different roles that the TSF should recognise, and conditions on how those roles could be managed. Often the system distinguishes between the owner of an entity, an administrator and other users.
The conditions on those roles specify the interrelationship between the different roles, as well as restrictions on when the role can be assumed by a user.
Page 284 of 354 Version 2.1
August 1999

Security management roles (FMT_SMR) H - Security management (FMT)
1065
1066
1068
Operations
Assignment:
In FMT_SMR.2.1 the PP/ST author should specify the roles that are recognised by the system. These are the roles that users could occupy with respect to security. Examples are: owner, auditor, administrator.
In FMT_SMR.2.3 the PP/ST author should specify the conditions that govern role assignment. Examples of these conditions are: “an account cannot have both the auditor and administrator role” or “a user with the assistant role must also have the owner role”.
FMT_SMR.3
Assuming roles
1067
This component specifies that an explicit request must be given to assume the specific role.
Operations
Assignment:
In FMT_SMR.3.1 the PP/ST author should specify the roles that require an explicit request to be assumed. Examples are: auditor and administrator.
August 1999 Version 2.1
Page 285 of 354

H - Security management (FMT) Security management roles (FMT_SMR)
Page 286 of 354 Version 2.1
August 1999

1069
1070
This class describes the requirements that could be levied to satisfy the users’ privacy needs, while still allowing the system flexibility as far as possible to maintain sufficient control over the operation of the system.
In the components of this class there is flexibility as to whether or not authorised users are covered by the required security functions. For example, a PP/ST author might consider it appropriate not to require protection of the privacy of users against a suitably authorised user.
Privacy
FPR_ANO Anonymity
FPR_PSE Pseudonymity
FPR_UNL Unlinkability
1 2
2
1
3
1
1071
August 1999
FPR_UNO Unobservability
1
3
4
2
Figure I.1 - Privacy class decomposition
This class, together with other classes (such as those concerned with audit, access control, trusted path, and non-repudiation) provides the flexibility to specify the desired privacy behaviour. On the other hand, the requirements in this class might impose limitations on the use of the components of other classes, such as FIA or
FAU. For example, if authorised users are not allowed to see the user identity (e.g.
Version 2.1
Page 287 of 354

I - Privacy (FPR)
1072
1073
1074
1075
1076
Anonymity or Pseudonymity), it will obviously not be possible to hold individual users accountable for any security relevant actions they perform that are covered by the privacy requirements. However, it may still be possible to include audit requirements in a PP/ST, where the fact that a particular security relevant event has occurred is more important than knowing who was responsible for it.
Additional information is provided in the application notes for class FAU, where it is explained that the definition of ‘identity’ in the context of auditing can also be an alias or other information that could identify a user.
This class describes four families: Anonymity, Pseudonymity, Unlinkability and
Unobservability. Anonymity, Pseudonymity and Unlinkability have a complex interrelationship. When choosing a family, the choice should depend on the threats identified. For some types of privacy threats, pseudonymity will be more appropriate than anonymity (e.g. if there is a requirement for auditing). In addition, some types of privacy threats are best countered by a combination of components from several families.
All families assume that a user does not explicitly perform an action that discloses the user’s own identity. For example, the TSF is not expected to screen the user name in electronic messages or databases.
All families in this class have components that can be scoped through operations.
These operations allow the PP/ST author to state the cooperating users/subjects to which the TSF must be resistant. An example of an instantiation of anonymity could be: “The TSF shall ensure that the users and/or subjects are unable to determine the user identity bound to the teleconsulting application”.
It is noted that the TSF should not only provide this protection against individual users, but also against users cooperating to obtain the information. The strength of the protection provided by this class should be described as strength of function as specified in annexes B and C of CC Part 1.
Page 288 of 354 2.1
August 1999

Anonymity (FPR_ANO) I - Privacy (FPR)
FPR_ANO
1077
1078
1079
1080
1081
1082
1083
1084
1085
Anonymity
Anonymity ensures that a subject may use a resource or service without disclosing its user identity.
User notes
The intention of this family is to specify that a user or subject might take action without releasing its user identity to others such as users, subjects, or objects. The family provides the PP/ST author with a means to identify the set of users that cannot see the identity of someone performing certain actions.
Therefore if a subject, using anonymity, performs an action, another subject will not be able to determine either the identity or even a reference to the identity of the user employing the subject. The focus of the anonymity is on the protection of the users identity, not on the protection of the subject identity; hence, the identity of the subject is not protected from disclosure.
Although the identity of the subject is not released to other subjects or users, the
TSF is not explicitly prohibited from obtaining the users identity. In case the TSF is not allowed to know the identity of the user, FPR_ANO.2 could be invoked. In that case the TSF should not request the user information.
The interpretation of “determine” should be taken in the broadest sense of the word.
The PP/ST author might want to use a Strength of Function to indicate how much rigour should be applied.
The component levelling distinguishes between the users and an authorised user.
An authorised user is often excluded from the component, and therefore allowed to retrieve a user’s identity. However, there is no specific requirement that an authorised user must be able to have the capability to determine the user’s identity.
For ultimate privacy the components would be used to say that no user or authorised user can see the identity of anyone performing any action.
Although some systems will provide anonymity for all services that are provided, other systems provide anonymity for certain subjects/operations. To provide this flexibility, an operation is included where the scope of the requirement is defined.
If the PP/ST author wants to address all subjects/operations, the words “all subjects and all operations” could be provided.
Possible applications include the ability to make enquiries of a confidential nature to public databases, respond to electronic polls, or make anonymous payments or donations.
Examples of potential hostile users or subjects are providers, system operators, communication partners and users, who smuggle malicious parts (e.g. Trojan
Horses) into systems. All of these users can investigate usage patterns (e.g. which users used which services) and misuse this information.
August 1999 Version 2.1
Page 289 of 354

I - Privacy (FPR) Anonymity (FPR_ANO)
FPR_ANO.1
Anonymity
User application notes
1086
This component ensures that the identity of a user is protected from disclosure.
There may be instances, however, that a given authorised user can determine who performed certain actions. This component gives the flexibility to capture either a limited or total privacy policy.
Operations
1087
1088
Assignment:
In FPR_ANO.1.1 the PP/ST author should specify the set of users and/ or subjects against which the TSF must provide protection. For example, even if the PP/ST author specifies a single user or subject role, the TSF must not only provide protection against each individual user or subject, but must protect with respect to cooperating users and/or subjects. A set of users, for example, could be a group of users which can operate under the same role or can all use the same process(es).
In FPR_ANO.1.1 the PP/ST author should identify the list of subjects and/or operations and/or objects where the real user name of the subject should be protected, for example, “the voting application”.
FPR_ANO.2
Anonymity without soliciting information
User application notes
1089
1090
1091
1092
This component is used to ensure that the TSF is not allowed to know the identity of the user.
Operations
Assignment:
In FPR_ANO.2.1 the PP/ST author should specify the set of users and/or subjects against which the TSF must provide protection. For example, even if the PP/ST author specifies a single user or subject role, the TSF must not only provide protection against each individual user or subject, but must protect with respect to cooperating users and/or subjects. A set of users, for example, could be a group of users which can operate under the same role or can all use the same process(es).
In FPR_ANO.2.1 the PP/ST author should identify the list of subjects and/ or operations and/or objects where the real user name of the subject should be protected, for example, “the voting application”.
In FPR_ANO.2.2 the PP/ST author should identify the list of services which are subject to the anonymity requirement, for example, “the accessing of job descriptions”.
Page 290 of 354 Version 2.1
August 1999

Anonymity (FPR_ANO)
1093
I - Privacy (FPR)
For FPR_ANO.2.2 the PP/ST author should identify the list of subjects from which the real user name of the subject should be protected when the specified services are provided.
August 1999 Version 2.1
Page 291 of 354

I - Privacy (FPR) Pseudonymity (FPR_PSE)
1095
1096
1097
FPR_PSE
1094
1098
1099
1100
1101
Page 292 of 354
Pseudonymity
Pseudonymity ensures that a user may use a resource or service without disclosing its identity, but can still be accountable for that use. The user can be accountable by directly being related to a reference (alias) held by the TSF, or by providing an alias that will be used for processing purposes, such as an account number.
User notes
In several respects, pseudonymity resembles anonymity. Both pseudonymity and anonymity protect the identity of the user, but in pseudonymity a reference to the user’s identity is maintained for accountability or other purposes.
The component FPR_PSE.1 does not specify the requirements on the reference to the user’s identity. For the purpose of specifying requirements on this reference two sets of requirements are presented: FPR_PSE.2 and FPR_PSE.3.
A way to use the reference is by being able to obtain the original user identifier. For example, in a digital cash environment it would be advantageous to be able to trace the user’s identity when a check has been issued multiple times (i.e. fraud). In general, the user’s identity needs to be retrieved under specific conditions. The PP/
ST author might want to incorporate FPR_PSE.2 Reversible pseudonymity to describe those services.
Another usage of the reference is as an alias for a user. For example, a user who does not wish to be identified, can provide an account to which the resource utilisation should be charged. In such cases, the reference to the user identity is an alias for the user, where other users or subjects can use the alias for performing their functions without ever obtaining the user’s identity (for example, statistical operations on use of the system). In this case, the PP/ST author might wish to incorporate
FPR_PSE.3 Alias pseudonymity to specify the rules to which the reference must conform.
Using these constructs above, digital money can be created using
FPR_PSE.2 Reversible pseudonymity specifying that the user identity will be protected and, if so specified in the condition, that there be a requirement to trace the user identity if the digital money is spent twice. When the user is honest, the user identity is protected; if the user tries to cheat, the user identity can be traced.
A different kind of system could be a digital credit card, where the user will provide a pseudonym that indicates an account from which the cash can be subtracted. In such cases, for example, FPR_PSE.3 Alias pseudonymity could be used. This component would specify that the user identity will be protected and, furthermore, that the same user will only get assigned values for which he/she has provided money (if so specified in the conditions).
It should be realised that the more stringent components potentially cannot be combined with other requirements, such as identification and authentication or audit. The interpretation of “determine the identity” should be taken in the broadest
Version 2.1
August 1999

Pseudonymity (FPR_PSE) I - Privacy (FPR)
1102
1103
1105
1106
1107
1108 sense of the word. The information is not provided by the TSF during the operation, nor can the entity determine the subject or the owner of the subject that invoked the operation, nor will the TSF record information, available to the users or subjects, which might release the user identity in the future.
The intent is that the TSF not reveal any information that would compromise the identity of the user, e.g. the identity of subjects acting on the user’s behalf. The information that is considered to be sensitive depends on the effort an attacker is capable of spending. Therefore, the FPR_PSE Pseudonymity family is subject to
Strength of Function requirements.
Possible applications include the ability to charge a caller for premium rate telephone services without disclosing his or her identity, or to be charged for the anonymous use of an electronic payment system.
1104
Examples of potential hostile users are providers, system operators, communication partners and users, who smuggle malicious parts (e.g. Trojan Horses) into systems.
All of these attackers can investigate which users used which services and misuse this information. Additionally to Anonymity services, Pseudonymity Services contains methods for authorisation without identification, especially for anonymous payment (“Digital Cash”). This helps providers to obtain their payment in a secure way while maintaining customer anonymity.
FPR_PSE.1
Pseudonymity
User application notes
This component provides the user protection against disclosure of identity to other users. The user will remain accountable for its actions.
Operations
Assignment:
In FPR_PSE.1.1 the PP/ST author should specify the set of users and/ or subjects against which the TSF must provide protection. For example, even if the PP/ST author specifies a single user or subject role, the TSF must not only provide protection against each individual user or subject, but must protect with respect to cooperating users and/or subjects. A set of users, for example, could be a group of users which can operate under the same role or can all use the same process(es).
In FPR_PSE.1.1 the PP/ST author should identify the list of subjects and/or operations and/or objects where the real user name of the subject should be protected, for example, ‘the accessing of job offers’.
Note that ‘objects’ includes any other attributes that might enable another user or subject to derive the actual identity of the user.
In FPR_PSE.1.2 the PP/ST author should identify the (one or more) number of aliases the TSF is able to provide.
August 1999 Version 2.1
Page 293 of 354

I - Privacy (FPR) Pseudonymity (FPR_PSE)
1109
1110
1111
In FPR_PSE.1.2 the PP/ST author should identify the list of subjects to whom the TSF is able to provide an alias.
Selection:
In FPR_PSE.1.3 the PP/ST author should specify whether the user alias is generated by the TSF, or supplied by the user.
Assignment:
In FPR_PSE.1.3 the PP/ST author should identify the metric to which the TSF-generated or user-generated alias should conform.
FPR_PSE.2
Reversible pseudonymity
1112
User application notes
In this component, the TSF shall ensure that under specified conditions the user identity related to a provided reference can be determined.
1113
1114
1115
1116
1117
In FPR_PSE.1 the TSF shall provide an alias instead of the user identity. When the specified conditions are satisfied, the user identity to which the alias belong can be determined. An example of such a condition in an electronic cash environment is:
“The TSF shall provide the notary a capability to determine the user identity based on the provided alias only under the conditions that a check has been issued twice.”.
Operations
Assignment:
In FPR_PSE.2.1 the PP/ST author should specify the set of users and/or subjects against which the TSF must provide protection. For example, even if the PP/ST author specifies a single user or subject role, the TSF must not only provide protection against each individual user or subject, but must protect with respect to cooperating users and/or subjects. A set of users, for example, could be a group of users which can operate under the same role or can all use the same process(es).
In FPR_PSE.2.1 the PP/ST author should identify the list of subjects and/or operations and/or objects where the real user name of the subject should be protected, for example, ‘the accessing of job offers’. Note that ‘objects’ includes any other attributes that might enable another user or subject to derive the actual identity of the user.
In FPR_PSE.2.2 the PP/ST author should identify the (one or more) number of aliases the TSF, is able to provide.
In FPR_PSE.2.2 the PP/ST author should identify the list of subjects to whom the TSF is able to provide an alias.
Page 294 of 354 Version 2.1
August 1999

Pseudonymity (FPR_PSE) I - Privacy (FPR)
1118
1119
1120
1121
1122
Selection:
In FPR_PSE.2.3 the PP/ST author should specify whether the user alias is generated by the TSF or supplied by the user.
Assignment:
In FPR_PSE.2.3 the PP/ST author should identify the metric to which the
TSF-generated or user-generated alias should conform.
Selection:
In FPR_PSE.2.4 the PP/ST author should select whether the authorised user and/or trusted subjects can determine the real user name.
Assignment:
In FPR_PSE.2.4 the PP/ST author should identify the list of trusted subjects that can obtain the real user name under a specified condition, for example, a notary or special authorised user.
In FPR_PSE.2.4 the PP/ST author should identify the list of conditions under which the trusted subjects and authorised user can determine the real user name based on the provided reference. These conditions can be conditions such as time of day, or they can be administrative such as on a court order.
FPR_PSE.3
Alias pseudonymity
User application notes
1123
In this component, the TSF shall ensure that the provided reference meets certain construction rules, and thereby can be used in a secure way by potentially insecure subjects.
1124
1125
If a user wants to use disk resources without disclosing its identity, pseudonymity can be used. However, every time the user accesses the system, the same alias must be used. Such conditions can be specified in this component.
Operations
Assignment:
In FPR_PSE.3.1 the PP/ST author should specify the set of users and/or subjects against which the TSF must provide protection. For example, even if the PP/ST author specifies a single user or subject role, the TSF must not only provide protection against each individual user or subject, but must protect with respect to cooperating users and/or subjects. A set of users, for example, could be a group of users which can operate under the same role or can all use the same process(es).
August 1999 Version 2.1
Page 295 of 354

1127
1128
1129
1130
1131
I - Privacy (FPR)
1126
Pseudonymity (FPR_PSE)
In FPR_PSE.3.1 the PP/ST author should identify the list of subjects and/or operations and/or objects where the real user name of the subject should be protected, for example, ‘the accessing of job offers’. Note that ‘objects’ includes any other attributes which might enable another user or subject to derive the actual identity of the user.
In FPR_PSE.3.2 the PP/ST author should identify the (one or more) number of aliases the TSF is able to provide.
In FPR_PSE.3.2 the PP/ST author should identify the list of subjects to whom the TSF is able to provide an alias.
Selection:
In FPR_PSE.3.3 the PP/ST author should specify whether the user alias is generated by the TSF, or supplied by the user.
Assignment:
In FPR_PSE.3.3 the PP/ST author should identify the metric to which the
TSF-generated or user-generated alias should conform.
In FPR_PSE.3.4 the PP/ST author should identify the list of conditions that indicate when the used reference for the real user name shall be identical and when it shall be different, for example, “when the user logs on to the same host” it will use a unique alias.
Page 296 of 354 Version 2.1
August 1999

Unlinkability (FPR_UNL) I - Privacy (FPR)
FPR_UNL
1132
1133
1134
Unlinkability
Unlinkability ensures that a user may make multiple uses of resources or services without others being able to link these uses together. Unlinkability differs from pseudonymity that, although in pseudonymity the user is also not known, relations between different actions can be provided.
User notes
The requirements for unlinkability are intended to protect the user identity against the use of profiling of the operations. For example, when a telephone smart card is employed with a unique number, the telephone company can determine the behaviour of the user of this telephone card. When a telephone profile of the users is known, the card can be linked to a specific user. Hiding the relationship between different invocations of a service or access of a resource will prevent this kind of information gathering.
As a result, a requirement for unlinkability could imply that the subject and user identity of an operation must be protected. Otherwise this information might be used to link operations together.
1135
1136
Unlinkability requires that different operations cannot be related. This relationship can take several forms. For example, the user associated with the operation, or the terminal which initiated the action, or the time the action was executed. The PP/ST author can specify what kind of relationships are present that must be countered.
Possible applications include the ability to make multiple use of a pseudonym without creating a usage pattern that might disclose the user's identity.
1137
1138
Examples for potential hostile subjects and users are providers, system operators, communication partners and users, who smuggle malicious parts, (e.g. Trojan
Horses) into systems, they do not operate but want to get information about. All of these attackers can investigate (e.g. which users used which services) and misuse this information. Unlinkability protects users from linkages, which could be drawn between several actions of a customer. An example is a series of phone calls made by an anonymous customer to different partners, where the combination of the partner's identities might disclose the identity of the customer.
FPR_UNL.1
Unlinkability
User application notes
This component ensures that users cannot link different operations in the system and thereby obtain information.
August 1999 Version 2.1
Page 297 of 354

I - Privacy (FPR) Unlinkability (FPR_UNL)
1139
1140
1141
1142
Operations
Assignment:
In FPR_UNL.1.1 the PP/ST author should specify the set of users and/ or subjects against which the TSF must provide protection. For example, even if the PP/ST author specifies a single user or subject role, the TSF must not only provide protection against each individual user or subject, but must protect with respect to cooperating users and/or subjects. A set of users, for example, could be a group of users which can operate under the same role or can all use the same process(es).
In FPR_UNL.1.1 the PP/ST author should identify the list of operations which should be subjected to the unlinkability requirement, for example, “sending email”.
Selection:
In FPR_UNL.1.1 the PP/ST author should select the relationships that should be obscured. The selection allows either the user identity or an assignment of relations to be specified.
Assignment:
In FPR_UNL.1.1 the PP/ST author should identify the list of relations which should be protected against, for example, “originate from the same terminal”.
Page 298 of 354 Version 2.1
August 1999

Unobservability (FPR_UNO) I - Privacy (FPR)
FPR_UNO
1143
1144
1145
1146
1147
Unobservability
Unobservability ensures that a user may use a resource or service without others, especially third parties, being able to observe that the resource or service is being used.
User notes
Unobservability approaches the user identity from a different direction than the previous families Anonymity, Pseudonymity and Unlinkability. In this case, the intent is to hide the use of a resource or service, rather than to hide the user’s identity.
A number of techniques can be applied to implement unobservability. Examples of techniques to provide unobservability are: a) Allocation of information impacting unobservability: Unobservability relevant information (e.g. information that describes that an operation occurred) can be allocated in several locations within the TOE. The information might be allocated to a single randomly chosen part of the TOE such that an attacker does not know which part of the TOE should be attacked. An alternative system might distribute the information such that no single part of the TOE has sufficient information that, if circumvented, the privacy of the user would be compromised. This technique is explicitly addressed in FPR_UNO.2.
b) Broadcast: When information is broadcast (e.g. ethernet, radio), users cannot determine who actually received and used that information. This technique is especially useful when information should reach receivers which have to fear a stigma for being interested in that information (e.g.
sensitive medical information).
c) Cryptographic protection and message padding: People observing a message stream might obtain information from the fact that a message is transferred and from attributes on that message. By traffic padding, message padding and encrypting the message stream, the transmission of a message and its attributes can be protected.
Sometimes, users should not see the use of a resource, but an authorised user must be allowed to see the use of the resource in order to perform his duties. In such cases, the FPR_UNO.4 could be used, which provides the capability for one or more authorised users to see the usage.
This family makes use of the concept “parts of the TOE”. This is considered any part of the TOE that is either physically or logically separated from other parts of the TOE. In the case of logical separation FPT_SEP may be relevant.
August 1999 Version 2.1
Page 299 of 354

I - Privacy (FPR) Unobservability (FPR_UNO)
1148
Unobservability of communications may be an important factor in many areas, such as the enforcement of constitutional rights, organisational policies, or in defence related applications.
FPR_UNO.1
Unobservability
User application notes
1149 This component requires that the use of a function or resource cannot be observed by unauthorised users. In addition to this component, a PP/ST author might want to incorporate Covert Channel Analysis.
Operations
1150
1151
1152
1153
Assignment:
In FPR_UNO.1.1 the PP/ST author should specify the list of users and/ or subjects against which the TSF must provide protection. For example, even if the PP/ST author specifies a single user or subject role, the TSF must not only provide protection against each individual user or subject, but must protect with respect to cooperating users and/or subjects. A set of users, for example, could be a group of users which can operate under the same role or can all use the same process(es).
For FPR_UNO.1.1 the PP/ST author should identify the list of operations that are subjected to the unobservability requirement.
Other users/subjects will then not be able to observe the operations on a covered object in the specified list (e.g. reading and writing to the object).
For FPR_UNO.1.1 the PP/ST author should identify the list of objects which are covered by the unobservability requirement. An example could be a specific mail server or ftp site.
In FPR_UNO.1.1 the PP/ST author should specify the set of protected users and/or subjects whose unobservability information will be protected. An example could be: “users accessing the system through the internet”.
FPR_UNO.2
Allocation of information impacting unobservability
User application notes
1154
1155
This component requires that the use of a function or resource cannot be observed by specified users or subjects. Furthermore this component specifies that information related to the privacy of the user is distributed within the TOE such that attackers might not know which part of the TOE to target, or they need to attack multiple parts of the TOE.
An example of the use of this component is the use of a randomly allocated node to provide a function. In such a case the component might require that the privacy
Page 300 of 354 Version 2.1
August 1999

Unobservability (FPR_UNO) I - Privacy (FPR)
1160
1161
1162
1156
1157
1158
1159
1163
August 1999 related information shall only be available to one identified part of the TOE, and will not be communicated outside this part of the TOE.
A more complex example can be found in some ‘voting algorithms’. Several parts of the TOE will be involved in the service, but no individual part of the TOE will be able to violate the policy. So a person may cast a vote (or not) without the TOE being able to determine whether a vote has been cast and what the vote happened to be (unless the vote was unanimous).
In addition to this component, a PP/ST author might want to incorporate Covert
Channel Analysis.
Operations
Assignment:
In FPR_UNO.2.1 the PP/ST author should specify the list of users and/or subjects against which the TSF must provide protection. For example, even if the PP/ST author specifies a single user or subject role, the TSF must not only provide protection against each individual user or subject, but must protect with respect to cooperating users and/or subjects. A set of users, for example, could be a group of users which can operate under the same role or can all use the same process(es).
For FPR_UNO.2.1 the PP/ST author should identify the list of operations that are subjected to the unobservability requirement. Other users/subjects will then not be able to observe the operations on a covered object in the specified list (e.g. reading and writing to the object).
For FPR_UNO.2.1 the PP/ST author should identify the list of objects which are covered by the unobservability requirement. An example could be a specific mail server or ftp site.
In FPR_UNO.2.1 the PP/ST author should specify the set of protected users and/or subjects whose unobservability information will be protected. An example could be: “users accessing the system through the internet”.
For FPR_UNO.2.2 the PP/ST author should identify which privacy related information should be distributed in a controlled manner.
Examples of this information could be: IP address of subject, IP address of object, time, used encryption keys.
For FPR_UNO.2.2 the PP/ST author should specify the conditions to which the dissemination of the information should adhere. These conditions should be maintained throughout the lifetime of the privacy related information of each instance. Examples of these conditions could be: “the information shall only be present at a single separated part of the TOE and shall not be communicated outside this part of the
TOE.”, “the information shall only reside in a single separated part of the TOE, but shall be moved to another part of the TOE periodically”,
“the information shall be distributed between the different parts of the
Version 2.1
Page 301 of 354

I - Privacy (FPR) Unobservability (FPR_UNO)
TOE such that compromise of any 5 separated parts of the TOE will not compromise the security policy”.
FPR_UNO.3
Unobservability without soliciting information
User application notes
1164
1165
1166
1167
This component is used to require that the TSF does not try to obtain information that might compromise unobservability when provided specific services. Therefore the TSF will not solicit (i.e. try to obtain from other entities) any information that might be used to compromise unobservability.
Operations
Assignment:
In FPR_UNO.3.1 the PP/ST author should identify the list of services which are subject to the unobservability requirement, for example,
“the accessing of job descriptions”.
For FPR_UNO.3.1 the PP/ST author should identify the list of subjects from which privacy related information should be protected when the specified services are provided.
In FPR_UNO.3.1 the PP/ST author should specify the privacy related information that will be protected from the specified subjects.
Examples include the identity of the subject that used a service and the quantity of a service that has been used such as memory resource utilisation.
FPR_UNO.4
Authorised user observability
User application notes
1168
This component is used to require that there will be one or more authorised users with the rights to view the resource utilisation. Without this component, this review is allowed, but not mandated.
1169
1170
Operations
Assignment:
In FPR_UNO.4.1 the PP/ST author should specify the set of authorised users for which the TSF must provide the capability to observe the resource utilisation. A set of authorised users, for example, could be a group of authorised users which can operate under the same role or can all use the same process(es).
In FPR_UNO.4.1 the PP/ST author should specify the set of resources and/or services that the authorised user must be able to observe.
Page 302 of 354 Version 2.1
August 1999

1171
This class contains families of functional requirements that relate to the integrity and management of the mechanisms that provide the TSF (independent of TSPspecifics), and to the integrity of TSF data (independent of the specific contents of the TSP data). In some sense, families in this class may appear to duplicate components in the FDP (User data protection) class and may even be implemented using the same mechanisms. However, FDP focuses on user data protection, while
FPT focuses on TSF data protection. In fact, components from the FPT class are necessary in order to provide requirements that the SFPs in the TOE cannot be tampered with or bypassed.
August 1999 Version 2.1
Page 303 of 354

J - Protection of the TSF (FPT)
Protection of the TSF
FPT_AMT Underlying abstract achine test
FPT_FLS Fail secure
FPT_ITA Availability of exported TSF data
FPT_ITC Confidentiality of exported TSF data
FPT_ITI Integrity of exported TSF data
FPT_ITT Internal TOE TSF data transfer
FPT_PHP TSF physical protection
FPT_RCV Trusted recovery
1
1
1
3
1
4
3
1
1
1
1
2
2
2
2 3
Figure J.1 - Protection of the TSF class decomposition
Page 304 of 354 2.1
August 1999

J - Protection of the TSF (FPT)
1172
1173
Protection of the TSF
FPT_RPL Replay detection and prevention
FPT_RVM Reference mediation
FPT_SEP Domain separation
FPT_SSP State synchrony protocol
FPT_STM Time stamps
FPT_TDC Inter-TSF TSF data consistency
FPT_TRC Internal TOE TSF data replication consistency
FPT_TST TSF self test
1
1
Figure J.2 - Protection of the TSF class decomposition (Cont.)
1
1
1
1
1
1
2
2
3
From the point of view of this class, there are three significant portions that make up the TSF: a) The TSF's abstract machine, which is the virtual or physical machine upon which the specific TSF implementation under evaluation executes.
b) The TSF's implementation, which executes on the abstract machine and implements the mechanisms that enforce the TSP.
c) The TSF's data, which are the administrative databases that guide the enforcement of the TSP.
All of the families in the FPT class can be related to these areas, and fall into the following groupings:
August 1999 2.1
Page 305 of 354

J - Protection of the TSF (FPT) a) FPT_PHP (TSF physical protection), which provides an authorised user with the ability to detect external attacks on the parts of the TOE that comprise the TSF.
b) FPT_AMT (Underlying abstract machine test) and FPT_TST (TSF self test), which provide an authorised user with the ability to verify the correct operation of the underlying abstract machine and the TSF as well as the integrity of the TSF data and executable code.
c) FPT_SEP (Domain separation) and FPT_RVM (Reference mediation), which protect the TSF during execution and ensure that the TSF cannot be bypassed. When appropriate components from these families are combined with the appropriate components from ADV_INT (TSF internals), the TOE can be said to have what has been traditionally called a “Reference
Monitor.” d) FPT_RCV (Trusted recovery), FPT_FLS (Fail secure), and FPT_TRC
(Internal TOE TSF data replication consistency), which address the behaviour of the TSF when failure occurs and immediately after.
e) FPT_ITA (Availability of exported TSF data), FPT_ITC (Confidentiality of exported TSF data), FPT_ITI (Integrity of exported TSF data), which address the protection and availability of TSF data between the TSF and a remote trusted IT product. f) FPT_ITT (Internal TOE TSF data transfer), which addresses protection of TSF data when it is transmitted between physically-separated parts of the
TOE.
g) FPT_RPL (Replay detection), which addresses the replay of various types of information and/or operations.
h) FPT_SSP (State synchrony protocol), which addresses the synchronisation of states, based upon TSF data, between different parts of a distributed TSF. i) FPT_STM (Time stamps), which addresses reliable timing.
j) FPT_TDC (Inter-TSF TSF data consistency), which addresses the consistency of TSF data shared between the TSF and a remote trusted IT product.
Page 306 of 354 Version 2.1
August 1999

Underlying abstract machine test
(FPT_AMT)
J - Protection of the TSF (FPT)
FPT_AMT
1174
Underlying abstract achine test
This family defines the requirements for the TSF’s testing of security assumptions made about the underlying abstract machine upon which the TSF relies. This
“abstract” machine could be a hardware/firmware platform, or it could be some known and assessed hardware/software combination acting as a virtual machine.
Examples of such testing could be testing hardware page protection, sending sample packets across a network to ensure receipt, and verifying the behaviour of the virtual machine interface. These tests can be carried out either in some maintenance state, at start-up, on-line, or continuously. The actions to be taken by the TOE as the result of testing are defined in FPT_RCV.
1175
1176
User notes
The term “underlying abstract machine” typically refers to the hardware components upon which the TSF has been implemented. However, the phrase can also be used to refer to an underlying, previously evaluated hardware and software combination behaving as a virtual machine upon which the TSF relies.
The tests of the abstract machine may take various forms: a) Power-On Tests. These are tests that ensure the correct operation of the underlying platform. For hardware and firmware, this might include tests of elements such as memory boards, data paths, buses, control logic, processor registers, communication ports, console interfaces, speakers, and peripherals. For software elements (virtual machine), this would include verification of correct initialisation and behaviour.
b) Loadable Tests. These are tests that might be loaded and executed by an authorised user or be activated by specific conditions. This might include processor component stress tests (logic units, calculation units, etc.) and control memory.
1177
Evaluator notes
The tests of the underlying abstract machine should be sufficient to test all of the characteristics of the underlying abstract machine upon which the TSF relies.
FPT_AMT.1
Abstract machine testing
1178
1179
User Application Notes
This component provides support for the periodic testing of the security assumptions of the underlying abstract machine upon which the TSF’s operation depends, by requiring the ability to periodically invoke testing functions.
The PP/ST author may refine the requirement to state whether the function should be available in off-line, on-line or maintenance mode.
August 1999 Version 2.1
Page 307 of 354

J - Protection of the TSF (FPT)
1180
1181
Underlying abstract machine test
(FPT_AMT)
Evaluator application notes
It is acceptable for the functions for periodic testing to be available only in an offline or maintenance mode. Controls should be in place to limit access, during maintenance, to authorised users.
Operations
Selection:
In FPT_AMT.1.1 the PP/ST author should specify when the TSF will execute the abstract machine testing, during initial start-up, periodically during normal operation, at the request of an authorised user, or under other conditions. In the case of the latter option, the PP/
ST author should refine what those conditions are. The PP/ST author, through this selection, has the ability to indicate the frequency with which the self tests will be run. If the tests are run often, then the end users should have more confidence that the TOE is operating correctly then if the tests are run less frequently. However, this need for confidence that the TOE is operating correctly must be balanced with the potential impact on the availability of the TOE, as often times, self tests may delay the normal operation of a TOE.
Page 308 of 354 Version 2.1
August 1999

Fail secure (FPT_FLS) J - Protection of the TSF (FPT)
FPT_FLS
1182
Fail secure
The requirements of this family ensure that the TOE will not violate its TSP in the event of certain types of failures in the TSF.
FPT_FLS.1
Failure with preservation of secure state
User Application Notes
1183
The term “secure state” refers to a state in which the TSF data are consistent and the
TSF continues correct enforcement of the TSP. The “secure state” is defined in the
TSP model. If the developer provided a clear definition of the secure state and the reason why it should be considered secure, the dependency from FPT_FLS.1 to
ADV_SPM.1 can be argued away.
1184
1185
1186
Although it is desirable to audit situations in which failure with preservation of secure state occurs, it is not possible in all situations. The PP/ST author should specify those situations in which audit is desired and feasible.
Failures in the TSF may include “hard” failures, which indicate an equipment malfunction and which may require maintenance, service or repair of the TSF.
Failures in the TSF may also include recoverable “soft” failures, which may only require initialisation or resetting of the TSF.
Operations
Assignment:
For FPT_FLS.1.1, the PP/ST author should list the types of failures in the TSF for which the TSF should “fail secure,” that is, should preserve a secure state and continue to correctly enforce the TSP.
August 1999 Version 2.1
Page 309 of 354

J - Protection of the TSF (FPT) Availability of exported TSF data
(FPT_ITA)
FPT_ITA
1187
Availability of exported TSF data
This family defines the rules for the prevention of loss of availability of TSF data moving between the TSF and a remote trusted IT product. This data could be TSF critical data such as passwords, keys, audit data, or TSF executable code.
1188
User Application Notes
This family is used in a distributed system context where the TSF is providing TSF data to a remote trusted IT product. The TSF can only take the measures at its site and cannot be held responsible for the TSF at the other trusted IT product.
1189
If there are different availability metrics for different types of TSF data, then this component should be iterated for each unique pairing of metrics and types of TSF data.
FPT_ITA.1
Inter-TSF availability within a defined availability metric
1190
1191
1192
Operations
Assignment:
For FPT_ITA.1.1, the PP/ST author should specify the types of TSF data that are subject to the availability metric.
For FPT_ITA.1.1, the PP/ST should specify the availability metric for the applicable TSF data.
For FPT_ITA.1.1, the PP/ST author should specify the conditions under which availability must be ensured. For example: there must be a connection between the TOE and the remote trusted IT product
Page 310 of 354 Version 2.1
August 1999

Confidentiality of exported TSF data
(FPT_ITC)
J - Protection of the TSF (FPT)
FPT_ITC
1193
Confidentiality of exported TSF data
This family defines the rules for the protection from unauthorised disclosure of TSF data moving between the TSF and a remote trusted IT product. Examples of this data are TSF critical data such as passwords, keys, audit data, or TSF executable code.
1194
User Application Notes
This family is used in a distributed system context where the TSF is providing TSF data to a remote trusted IT product. The TSF can only take the measures at its site and cannot be held responsible for the behaviour of the other trusted IT product.
FPT_ITC.1
Inter-TSF confidentiality during transmission
Evaluator application notes
1195 Confidentiality of TSF Data during transmission is necessary to protect such information from disclosure. Some possible implementations that could provide confidentiality include the use of cryptographic algorithms as well as spread spectrum techniques.
August 1999 Version 2.1
Page 311 of 354

J - Protection of the TSF (FPT) Integrity of exported TSF data (FPT_ITI)
FPT_ITI
1196
Integrity of exported TSF data
This family defines the rules for the protection, from unauthorised modification, of
TSF data during transmission between the TSF and a remote trusted IT product.
Examples of this data are TSF critical data such as passwords, keys, audit data, or
TSF executable code.
1197
User notes
This family is used in a distributed system context where the TSF is exchanging
TSF data with a remote trusted IT product. Note that a requirement that addresses modification, detection, or recovery at the remote trusted IT product cannot be specified, as the mechanisms that a remote trusted IT product will use to protect its data cannot be determined in advance. For this reason, these requirements are expressed in terms of the “TSF providing a capability” which the remote trusted IT product can use.
FPT_ITI.1
Inter-TSF detection of modification
1198
1199
User Application Notes
This component should be used in situations where it is sufficient to detect when data have been modified. An example of such a situation is one in which the remote trusted IT product can request the TOE’s TSF to retransmit data when modification has been detected, or respond to such types of request.
The desired strength of modification detection is based upon a specified modification metric that is a function of the algorithm used, which may range from a weak checksum and parity mechanisms that may fail to detect multiple bit changes, to more complicated cryptographic checksum approaches.
1200
1201
Operations
Assignment:
For FPT_ITI.1.1, the PP/ST should specify the modification metric that the detection mechanism must satisfy. This modification metric shall specify the desired strength of the modification detection.
For FPT_ITI.1.2, the PP/ST should specify the actions to be taken if a modification of TSF data has been detected. An example of an action is:
“ignore the TSF data, and request the originating trusted product to send the TSF data again”.
FPT_ITI.2
Inter-TSF detection and correction of modification
User Application Notes
1202
This component should be used in situations where it is necessary to detect or correct modifications of TSF critical data.
Page 312 of 354 Version 2.1
August 1999

Integrity of exported TSF data
(FPT_ITI)
1203
1204
1205
1206
1207
1208
J - Protection of the TSF (FPT)
The desired strength of modification detection is based upon a specified modification metric that is a function of the algorithm used, which may range from a checksum and parity mechanisms that may fail to detect multiple bit changes, to more complicated cryptographic checksum approaches. The metric that needs to be defined can either refer to the attacks it will resist (e.g. only 1 in a 1000 random messages will be accepted), or to mechanisms that are well known in the public literature (e.g. the strength must be conformant to the strength offered by Secure
Hash Algorithm).
The approach taken to correct modification might be done through some form of error correcting checksum.
Evaluator notes
Some possible means of satisfying this requirement involves the use of cryptographic functions or some form of checksum.
Operations
Assignment:
For FPT_ITI.2.1, the PP/ST should specify the modification metric that the detection mechanism must satisfy. This modification metric shall specify the desired strength of the modification detection.
For FPT_ITT.2.2, the PP/ST should specify the actions to be taken if a modification of TSF data has been detected. An example of an action is:
“ignore the TSF data, and request the originating trusted product to send the
TSF data again”.
For FPT_ITI.2.3, the PP/ST author should define the types of modification from which the TSF should be capable of recovering.
August 1999 Version 2.1
Page 313 of 354

J - Protection of the TSF (FPT) Internal TOE TSF data transfer (FPT_ITT)
FPT_ITT
1209
Internal TOE TSF data transfer
This family provides requirements that address protection of TSF data when it is transferred between separate parts of a TOE across an internal channel.
1210
User notes
The determination of the degree of separation (i.e., physical or logical) that would make application of this family useful depends on the intended environment of use.
In a hostile environment, there may be risks arising from transfers between parts of the TOE separated by only a system bus or an inter-process communications channel. In more benign environments, the transfers may be across more traditional network media.
1211
Evaluator notes
One practical mechanism available to a TSF to provide this protection is cryptographically-based.
FPT_ITT.1
Basic internal TSF data transfer protection
1212
Operations
Selection:
In FPT_ITT.1.1, the PP/ST author should specify the desired type of protection to be provided from the choices: disclosure, modification.
FPT_ITT.2
TSF data transfer separation
1213
User Application Notes
One of the ways to achieve separation of TSF data based on SFP-relevant attributes is through the use of separate logical or physical channels.
1214
Operations
Selection:
In FPT_ITT.1.1, the PP/ST author should specify the desired type of protection to be provided from the choices: disclosure, modification.
FPT_ITT.3
TSF data integrity monitoring
Operations
1215
Selection:
In FPT_ITT.3.1, the PP/ST author should specify the desired type of modification that the TSF shall be able to detect. The PP/ST author
Page 314 of 354 Version 2.1
August 1999

Internal TOE TSF data transfer
(FPT_ITT)
1216
1217
J - Protection of the TSF (FPT) should select from: modification of data, substitution of data, reordering of data, deletion of data, or any other integrity errors.
Assignment:
In FPT_ITT.3.1, if the PP/ST author chooses the latter selection noted in the preceding paragraph, then the author should also specify what those other integrity errors are that the TSF should be capable of detecting.
In FPT_ITT.3.2, the PP/ST author should specify the action to be taken when an integrity error is identified.
August 1999 Version 2.1
Page 315 of 354

J - Protection of the TSF (FPT) TSF physical protection (FPT_PHP)
FPT_PHP
1218
TSF physical protection
TSF physical protection components refer to restrictions on unauthorised physical access to the TSF, and to the deterrence of, and resistance to, unauthorised physical modification, or substitution of the TSF.
1219
1220
1221
1222
The requirements in this family ensure that the TSF is protected from physical tampering and interference. Satisfying the requirements of these components results in the TSF being packaged and used in such a manner that physical tampering is detectable, or resistance to physical tampering is measurable based on defined work factors. Without these components, the protection functions of a TSF lose their effectiveness in environments where physical damage cannot be prevented. This component also provides requirements regarding how the TSF must respond to physical tampering attempts.
Examples of physical tampering scenarios include mechanical attack, radiation, changing the temperature.
User notes
It is acceptable for the functions that are available to an authorised user for detecting physical tampering to be available only in an off-line or maintenance mode.
Controls should be in place to limit access during such modes to authorised users.
As the TSF may not be “operational” during those modes, it may not be able to provide normal enforcement for authorised user access. The physical implementation of a TOE might consist of several structures: for example an outer shielding, cards, and chips. This set of “elements” as a whole must protect (protect, notify and resist) the TSF from physical tampering. This does not mean that all devices must provide these features, but the complete physical construct as a whole should.
Although there is only minimal auditing associating with these components, this is solely because there is the potential that the detection and alarm mechanisms may be implemented completely in hardware, below the level of interaction with an audit subsystem (for example, a hardware-based detection system based on breaking a circuit and lighting a light emitting diode (LED) if the circuit is broken when a button is pressed by the authorised user). Nevertheless, a PP/ST author may determine that for a particular anticipated threat environment, there is a need to audit physical tampering. If this is the case, the PP/ST author should include appropriate requirements in the list of audit events. Note that inclusion of these requirements may have implications on the hardware design and its interface to the software.
FPT_PHP.1
Passive detection of physical attack
User Application Notes
1223
FPT_PHP.1 should be used when threats from unauthorised physical tampering with parts of the TOE are not countered by procedural methods. It addresses the threat of undetected physical tampering with the TSF. Typically, an authorised user
Page 316 of 354 Version 2.1
August 1999

TSF physical protection (FPT_PHP) J - Protection of the TSF (FPT) would be given the function to verify whether tampering took place. As written, this component simply provides a TSF capability to detect tampering. The dependency on FMT_MOF.1 is required to specify who can make use of that capability, and how they can make use of that capability. If this function is realised by non-IT mechanisms (e.g. physical inspection) it could be justified that the dependency on
FMT_MOF.1 is not satisfied.
FPT_PHP.2
Notification of physical attack
User Application Notes
1224
FPT_PHP.2 should be used when threats from unauthorised physical tampering with parts of the TOE are not countered by procedural methods, and it is required that designated individuals be notified of physical tampering. It addresses the threat that physical tampering with TSF elements, although detected, may not be noticed.
Operations
1225
1226
Assignment:
For FPT_PHP.2.3, the PP/ST author should provide a list of TSF devices/elements for which active detection of physical tampering is required.
For FPT_PHP.2.3, the PP/ST author should designate a user or role that is to be notified when tampering is detected. The type of user or role may vary depending on the particular security administration component (from the FMT_MOF.1 family) included in the PP/ST.
FPT_PHP.3
Resistance to physical attack
1227
1228
1229
For some forms of tampering, it is necessary that the TSF not only detects the tampering, but actually resists it or delays the attacker.
User Application Notes
This component should be used when TSF devices and TSF elements are expected to operate in an environment where a physical tampering (e.g. observation, analysis, or modification) of the internals of a TSF device or TSF element itself is a threat.
Operations
Assignment:
For FPT_PHP.3.1, the PP/ST author should specify tampering scenarios to a list of TSF devices/elements for which the TSF should resist physical tampering. This list may be applied to a defined subset of the TSF physical devices and elements based on considerations such as technology limitations and relative physical exposure of the device.
Such subsetting should be clearly defined and justified. Furthermore,
August 1999 Version 2.1
Page 317 of 354

J - Protection of the TSF (FPT)
1230
TSF physical protection (FPT_PHP) the TSF should automatically respond to physical tampering. The automatic response should be such that the policy of the device is preserved; for example, with a confidentiality policy, it would be acceptable to physically disable the device so that the protected information may not be retrieved.
For FPT_PHP.3.1, the PP/ST author should specify the list of TSF devices/elements for which the TSF should resist physical tampering in the scenarios that have been identified.
Page 318 of 354 Version 2.1
August 1999

Trusted recovery (FPT_RCV) J - Protection of the TSF (FPT)
FPT_RCV
1231
1232
1233
1234
1235
Trusted recovery
The requirements of this family ensure that the TSF can determine that the TOE is started-up without protection compromise and can recover without protection compromise after discontinuity of operations. This family is important because the start-up state of the TSF determines the protection of subsequent states.
Recovery components reconstruct the TSF secure states, or prevent transitions to insecure states, as a direct response to occurrences of expected failures, discontinuity of operation or start-up. Failures that must be generally anticipated include the following: a) Unmaskable action failures that always result in a system crash (e.g.
persistent inconsistency of critical system tables, uncontrolled transfers within the TSF code caused by transient failures of hardware or firmware, power failures, processor failures, communication failures).
b) Media failures causing part or all of the media representing the TSF objects to become inaccessible or corrupt (e.g. parity errors, disk head crash, persistent read/write failure caused by misaligned disk heads, worn-out magnetic coating, dust on the disk surface).
c) Discontinuity of operation caused by erroneous administrative action or lack of timely administrative action (e.g. unexpected shutdowns by turning off power, ignoring the exhaustion of critical resources, inadequate installed configuration).
Note that recovery may be from either a complete or partial failure scenario.
Although a complete failure might occur in a monolithic operating system, it is less likely to occur in a distributed environment. In such environments, subsystems may fail, but other portions remain operational. Further, critical components may be redundant (disk mirroring, alternative routes), and checkpoints may be available.
Thus, recovery is expressed in terms of recovery to a secure state.
This family identifies a maintenance mode. In this maintenance mode normal operation might be impossible or severely restricted, as otherwise insecure situations might occur. Typically, only authorised users should be allowed access to this mode but the real details of who can access this mode is a function of Class
FMT Security management. If FMT does not put any controls on who can access this mode, then it may be acceptable to allow any user to restore the system if the
TOE enters such a state. However, in practice, this is probably not desirable as the user restoring the system has an opportunity to configure the TOE in such a way as to violate the TSP.
Mechanisms designed to detect exceptional conditions during operation fall under
FPT_TST (TSF self test), FPT_FLS (Fail secure), and other areas that address the concept of “Software Safety.”
August 1999 Version 2.1
Page 319 of 354

J - Protection of the TSF (FPT) Trusted recovery (FPT_RCV)
1236
User notes
Throughout this family, the phrase “secure state” is used. This refers to some state in which the TOE has consistent TSF data and a TSF that can correctly enforce the policy. This state may be the initial “boot” of a clean system, or it might be some checkpointed state. The “secure state” is defined in the TSP model. If the developer provided a clear definition of the secure state and the reason why it should be considered secure, the dependency from FPT_FLS.1 to ADV_SPM.1 can be argued away.
FPT_RCV.1
Manual recovery
1237
In the hierarchy of the trusted recovery family, recovery that requires only manual intervention is the least desirable, for it precludes the use of the system in an unattended fashion.
User Application Notes
1238
This component is intended for use in TOEs that do not require unattended recovery to a secure state. The requirements of this component reduce the threat of protection compromise resulting from an attended TOE returning to an insecure state after recovery from a failure or other discontinuity.
Evaluator application notes
1239 It is acceptable for the functions that are available to an authorised user for trusted recovery to be available only in a maintenance mode. Controls should be in place to limit access during maintenance to authorised users.
FPT_RCV.2
Automated recovery
1240
Automated recovery is considered to be more useful than manual recovery, as it allows the machine to operate in an unattended fashion.
1241
1242
User Application Notes
The component FPT_RCV.2 extends the feature coverage of FPT_RCV.1 by requiring that there be at least one automated method of recovery from failure or service discontinuity. It addresses the threat of protection compromise resulting from an unattended TOE returning to an insecure state after recovery from a failure or other discontinuity.
Evaluator application notes
It is acceptable for the functions that are available to an authorised user for trusted recovery to be available only in a maintenance mode. Controls should be in place to limit access during maintenance to authorised users.
1243 For FPT_RCV.2.1, it is the responsibility of the developer of the TSF to determine the set of recoverable failures and service discontinuities.
Page 320 of 354 Version 2.1
August 1999

Trusted recovery (FPT_RCV) J - Protection of the TSF (FPT)
1244
1245
It is assumed that the robustness of the automated recovery mechanisms will be verified.
Operations
Assignment:
For FPT_RCV.2.2, the PP/ST author should specify the list of failures or other discontinuities for which automated recovery must be possible.
FPT_RCV.3
Automated recovery without undue loss
1246
Automated recovery is considered to be more useful than manual recovery, but it runs the risk of losing a substantial number of objects. Preventing undue loss of objects provides additional utility to the recovery effort.
1247
1248
User Application Notes
The component FPT_RCV.3 extends the feature coverage of FPT_RCV.2 by requiring that there not be undue loss of TSF data or objects within the TSC. At
FPT_RCV.2, the automated recovery mechanisms could conceivably recover by deleting all objects and returning the TSF to a known secure state. This type of drastic automated recovery is precluded in FPT_RCV.3.
This component addresses the threat of protection compromise resulting from an unattended TOE returning to an insecure state after recovery from a failure or other discontinuity with a large loss of TSF data or objects within the TSC.
Evaluator application notes
1249
1250
1251
1252
It is acceptable for the functions that are available to an authorised user for trusted recovery to be available only in a maintenance mode. Controls should be in place to limit access during maintenance to authorised users.
It is assumed that the evaluators will verify the robustness of the automated recovery mechanisms.
Operations
Assignment:
For FPT_RCV.3.2, the PP/ST author should specify the list of failures or other discontinuities for which automated recovery must be possible.
For FPT_RCV.3.3, the PP/ST author should provide a quantification for the amount of loss of TSF data or objects that is acceptable.
August 1999 Version 2.1
Page 321 of 354

J - Protection of the TSF (FPT) Trusted recovery (FPT_RCV)
FPT_RCV.4
Function recovery
1253
Function recovery requires that if there should be some failure in the TSF, that certain SFs in the TSF should either complete successfully or recover to a secure state.
1254
Operations
Assignment:
In FPT_RCV.4.1, the PP/ST author should specify a list the SFs and failure scenarios. In the event that any of the identified failure scenarios happen, the SFs that have been specified must either complete successfully or recover to a consistent and secure state.
Page 322 of 354 Version 2.1
August 1999

Replay detection (FPT_RPL) J - Protection of the TSF (FPT)
FPT_RPL
1255
Replay detection and prevention
This family addresses detection of replay for various types of entities and subsequent actions to correct.
FPT_RPL.1
Replay detection
User Application Notes
1256
The entities included here are, for example, messages, service requests, service responses, or sessions.
1257
1258
Operations
Assignment:
In FPT_RPL.1.1, the PP/ST author should provide a list of identified entities for which detection of replay should be possible. Examples of such entities might include: messages, service requests, service responses, and user sessions.
In FPT_RPL.1.2, the PP/ST author should specify the list of actions to be taken by the TSF when replay is detected. The potential set of actions that can be taken includes: ignoring the replayed entity, requesting confirmation of the entity from the identified source, and terminating the subject from which the re-played entity originated.
August 1999 Version 2.1
Page 323 of 354

J - Protection of the TSF (FPT) Reference mediation (FPT_RVM)
FPT_RVM
1259
1260
1261
1262
Reference mediation
The components of this family address the “always invoked” aspect of a traditional reference monitor. The goal of these components is to ensure, with respect to the
TSC, that all actions requiring policy enforcement invoked by subjects untrusted with respect to any or all of that SFP to objects controlled by that SFP are validated by the TSF against the SFP. If the portion of the TSF that enforces the SFP also meets the requirements of appropriate components from FPT_SEP (Domain separation) and ADV_INT (TSF internals), than that portion of the TSF provides a
“reference monitor” for that SFP.
The Reference Monitor is that portion of the TSF responsible for the enforcement of the TSP; it has the following three characteristics: a) Untrusted subjects cannot interfere with its operation; i.e. it is tamperproof. This is addressed by the components in the FPT_SEP family.
b) Untrusted subjects cannot bypass its checks; i.e. it is always invoked.
This is addressed by the components in the FPT_RVM family.
c) It is simple enough to be analysed and its behaviour understood (i.e. its design is conceptually simple.) This is addressed by the components in the
ADV_INT family.
This component states that, “the TSF shall ensure that TSP enforcement functions are invoked and succeed before each and every function within the TSC is allowed to proceed.” In any system (distributed or otherwise) there are a finite number of functions responsible for enforcing the TSP. There is nothing in this requirement that mandates or prescribes that a single function is invoked to handle security.
Rather, it allows multiple functions to fill the role of reference monitor, and the collection of them responsible for enforcing the TSP are simply called, collectively, the reference monitor. However, this must be balanced by the goal of keeping the
“reference monitor” simple.
A TSF that implements a SFP provides effective protection against unauthorised functions if and only if all enforceable actions (e.g. accesses to objects) requested by subjects untrusted with respect to any or all of that SFP are validated by the TSF before succeeding, If the enforceable action is incorrectly enforced or bypassed, the overall enforcement of the SFP has been compromised. “Untrusted” subjects could then bypass the SFP in a variety of unauthorised ways (e.g. circumvent access checks for some subjects or objects, bypass checks for objects whose protection was assumed by applications, retain access rights beyond their intended lifetime, bypass auditing of audited actions, or bypass authentication). Note that the term “untrusted subjects” refers to subjects untrusted with respect to any or all of the specific SFPs being enforced; a subject may be trusted with respect to one SFP and untrusted with respect to a different SFP.
Page 324 of 354 Version 2.1
August 1999

Reference mediation (FPT_RVM) J - Protection of the TSF (FPT)
FPT_RVM.1
Non-bypassability of the TSP
User Application Notes
1263
In order to obtain the equivalent of a reference monitor, this component must be used with either FPT_SEP.2 (SFP domain separation) or FPT_SEP.3 (Complete reference monitor), and ADV_INT.3 (Minimisation of complexity). Further, if complete reference mediation is required, the components from Class FDP User data protection must cover all objects.
August 1999 Version 2.1
Page 325 of 354

J - Protection of the TSF (FPT) Domain separation (FPT_SEP)
FPT_SEP
1264
Domain separation
The components of this family ensure that at least one security domain is available for the TSF’s own execution, and that the TSF is protected from external interference and tampering (e.g. by modification of TSF code or data structures) by untrusted subjects. Satisfying the requirements of this family makes the TSF selfprotecting, meaning that an untrusted subject cannot modify or damage the TSF.
1265
This family requires the following: a) The resources of the TSF’s security domain (“protected domain”) and those of subjects and unconstrained entities external to the domain are separated such that the entities external to the protected domain cannot observe or modify data structures or code internal to the protected domain.
b) The transfer of subjects between domains are controlled such that arbitrary entry to, or return from, the protected domain is not possible. c) The user or application parameters passed to the protected domain by addresses are validated with respect to the protected domain’s address space, and those passed by value are validated with respect to the values expected by the protected domain.
d) The security domains of subjects are distinct except for controlled sharing via the TSF.
1266
User notes
This family is needed whenever confidence is required that the TSF has not been subverted.
1267
In order to obtain the equivalent of a reference monitor, the components
FPT_SEP.2 (SFP domain separation) or FPT_SEP.3 (Complete reference monitor) from this family must be used in conjunction with FPT_RVM.1 (Non-bypassability of the TSP), and ADV_INT.3 (Minimisation of complexity). Further, if complete reference mediation is required, the components from Class FDP User data protection must cover all objects.
FPT_SEP.1
TSF domain separation
1268
Without a separate protected domain for the TSF, there can be no assurance that the
TSF has not been subjected to any tampering attacks by untrusted subjects. Such attacks may involve modification of the TSF code and/or TSF data structures.
FPT_SEP.2
SFP domain separation
1269
The most important function provided by a TSF is the enforcement of its SFPs. In order to simplify the design and increase the likelihood that those significant SFPs exhibit the characteristics of a reference monitor (RM), in particular, being tamperproof, they must be in a domain distinct from the remainder of the TSF.
Page 326 of 354 Version 2.1
August 1999

Domain separation (FPT_SEP) J - Protection of the TSF (FPT)
1270
1271
1272
Evaluator application notes
It is possible that a reference monitor in a layered design may provide functions beyond those of the SFPs. This arises out of the practical nature of layered software design. The goal should be to minimise the non-SFP related functions.
Note that it is acceptable for the reference monitors for all included SFPs to be in a single distinct reference monitor domain, as well as having multiple reference monitor domains (each enforcing one or more SFPs). If multiple reference monitor domains for SFPs are present, it is acceptable for them to be either peers or in a hierarchical relationship.
For FPT_SEP.2.1, the phrase “unisolated portion of the TSF” refers to that portion of the TSF consisting of those functions in the TSF not covered by FPT_SEP.2.3.
1273
Operations
Assignment:
For FPT_SEP.2.3, the PP/ST author should specify the access control and/or information flow control SFPs in the TSP that should have a separate domain.
FPT_SEP.3
Complete reference monitor
1274
The most important function provided by a TSF is the enforcement of its SFPs. This component builds upon the intentions of the previous component by requiring that
all access control and/or information flow control FSPs be enforced in a domain distinct from the remainder of the TSF. This further simplifies the design and increases the likelihood that the characteristics of a reference monitor (RM), in particular, being tamperproof, are found in the TSF.
Evaluator application notes
1275
1276
It is possible that a reference monitor in a layered design may provide functions beyond those of the SFPs. This arises out of the practical nature of layered software design. The goal should be to minimise the non-SFP related functions.
Note that it is acceptable for the reference monitors for all included SFPs to be in a single distinct reference monitor domain, as well as having multiple reference monitor domains (each enforcing one or more SFPs). If multiple reference monitor domains for SFPs are present, it is acceptable for them to be either peers or in a hierarchical relationship.
August 1999 Version 2.1
Page 327 of 354

J - Protection of the TSF (FPT) State synchrony protocol (FPT_SSP)
FPT_SSP
1277
State synchrony protocol
Distributed systems may give rise to greater complexity than monolithic systems through the potential for differences in state between parts of the system, and through delays in communication. In most cases, synchronisation of state between distributed functions involves an exchange protocol, not a simple action. When malice exists in the distributed environment of these protocols, more complex defensive protocols are required.
1278
FPT_SSP establishes the requirement for certain critical security functions of the
TSF to use a trusted protocol. FPT_SSP ensures that two distributed parts of the
TOE (e.g. hosts) have synchronised their states after a security-relevant action.
1279
User notes
Some states may never be synchronised, or the transaction cost may be too high for practical use; encryption key revocation is an example, where knowing the state after the revocation action is initiated can never be known. Either the action was taken and acknowledgment cannot be sent, or the message was ignored by hostile communication partners and the revocation never occurred. Indeterminacy is unique to distributed systems. Indeterminacy and state synchrony are related, and the same solution may apply. It is futile to design for indeterminate states; the PP/
ST author should express other requirements in such cases (e.g. raise an alarm, audit the event).
FPT_SSP.1
Simple trusted acknowledgement
1280
User Application Notes
In this component, the TSF must supply an acknowledgement to another part of the
TSF when requested. This acknowledgement should indicate that one part of a distributed TOE successfully received an unmodified transmission from a different part of the distributed TOE.
FPT_SSP.2
Mutual trusted acknowledgement
1281
1282
User Application Notes
In this component, in addition to the TSF being able to provide an acknowledgement for the receipt of a data transmission, the TSF must comply with a request from another part of the TSF for an acknowledgement to the acknowledgement.
For example, the local TSF transmits some data to a remote part of the TSF. The remote part of the TSF acknowledges the successful receipt of the data and requests that the sending TSF confirm that it receives the acknowledgement. This mechanism provides additional confidence that both parts of the TSF involved in the data transmission know that the transmission completed successfully.
Page 328 of 354 Version 2.1
August 1999

Time stamps (FPT_STM) J - Protection of the TSF (FPT)
FPT_STM
1283
Time stamps
This family addresses requirements for a reliable time stamp function within a TOE.
1284
User notes
It is the responsibility of the PP/ST author to clarify the meaning of the phrase
“reliable time stamp”, and to indicate where the responsibility lies in determining the acceptance of trust.
FPT_STM.1
Reliable time stamps
1285
User Application Notes
Some possible uses of this component include providing reliable time stamps for the purposes of audit as well as for security attribute expiration.
August 1999 Version 2.1
Page 329 of 354

J - Protection of the TSF (FPT) Inter-TSF TSF data consistency
(FPT_TDC)
FPT_TDC
1285
Inter-TSF TSF data consistency
In a distributed or composite system environment, a TOE may need to exchange
TSF data (e.g. the SFP-attributes associated with data, audit information, identification information) with another trusted IT Product. This family defines the requirements for sharing and consistent interpretation of these attributes between the TSF of the TOE and that of a different trusted IT Product.
1286
1287
1288
User notes
The components in this family are intended to provide requirements for automated support for TSF data consistency when such data is transmitted between the TSF of the TOE and another trusted IT Product. It is also possible that wholly procedural means could be used to produce security attribute consistency, but they are not provided for here.
This family is different from FDP_ETC and FDP_ITC, as those two families are concerned only with resolving the security attributes between the TSF and its import/export medium.
If the integrity of the TSF data is of concern, requirements should be chosen from the FPT_ITI family. These components specify requirements for the TSF to be able to detect or detect and correct modifications to TSF data in transit.
FPT_TDC.1
Inter-TSF basic TSF data consistency
User Application Notes
1289
The TSF is responsible for maintaining the consistency of TSF data used by or associated with the specified function and that are common between two or more trusted systems. For example, the TSF data of two different systems may have different conventions internally. For the TSF data to be used properly (e.g. to afford the user data the same protection as within the TOE) by the receiving trusted IT product, the TOE and the other trusted IT product must use a pre-established protocol to exchange TSF data.
1289
1289
Operations
Assignment:
In FPT_TDC.1.1, the PP/ST author should define the list of TSF data types, for which the TSF shall provide the capability to consistently interpret, when shared between the TSF and another trusted IT product.
In FPT_TDC.1.2, the PP/ST should assign the list of interpretation rules to be applied by the TSF.
Page 330 of 354 Version 2.1
August 1999

Internal TOE TSF data replication consistency (FPT_TRC)
J - Protection of the TSF (FPT)
FPT_TRC
1290
Internal TOE TSF data replication consistency
The requirements of this family are needed to ensure the consistency of TSF data when such data is replicated internal to the TOE. Such data may become inconsistent if an internal channel between parts of the TOE becomes inoperative.
If the TOE is internally structured as a network of parts of the TOE, this can occur when parts become disabled, network connections are broken, and so on.
1291
User notes
The method of ensuring consistency is not specified in this component. It could be attained through a form of transaction logging (where appropriate transactions are
“rolled back” to a site upon reconnection); it could be updating the replicated data through a synchronisation protocol. If a particular protocol is necessary for a PP/ST, it can be specified through refinement.
1292
It may be impossible to synchronise some states, or the cost of such synchronisation may be too high. Examples of this situation are communication channel and encryption key revocations. Indeterminate states may also occur; if a specific behaviour is desired, it should be specified via refinement.
FPT_TRC.1
Internal TSF consistency
1293
Operations
Assignment:
In FPT_TRC.1.2, the PP/ST author should specify the list of SFs dependent on TSF data replication consistency.
August 1999 Version 2.1
Page 331 of 354

J - Protection of the TSF (FPT) TSF self test (FPT_TST)
FPT_TST
1294
TSF self test
The family defines the requirements for the self-testing of the TSF with respect to some expected correct operation. Examples are interfaces to enforcement functions, and sample arithmetical operations on critical parts of the TOE. These tests can be carried out at start-up, periodically, at the request of an authorised user, or when other conditions are met. The actions to be taken by the TOE as the result of self testing are defined in other families.
1295
1296
1299
1300
The requirements of this family are also needed to detect the corruption of TSF executable code (i.e. TSF software) and TSF data by various failures that do not necessarily stop the TOE's operation (which would be handled by other families).
These checks must be performed because these failures may not necessarily be prevented. Such failures can occur either because of unforeseen failure modes or associated oversights in the design of hardware, firmware, or software, or because of malicious corruption of the TSF due to inadequate logical and/or physical protection.
In addition, use of this component may, with appropriate conditions, help to prevent inappropriate or damaging TSF changes being applied to an operational TOE as the result of maintenance activities.
1297
User notes
The term “correct operation of the TSF” refers primarily to the operation of the TSF software and the integrity of the TSF data. The abstract machine upon which the
TSF software is implemented is tested via dependency on FPT_AMT.
FPT_TST.1
TSF testing
User Application Notes
1298
This component provides support for the testing of the critical functions of the
TSF’s operation by requiring the ability to invoke testing functions and check the integrity of TSF data and executable code.
Evaluator application notes
It is acceptable for the functions that are available to the authorised user for periodic testing to be available only in an off-line or maintenance mode. Controls should be in place to limit access during these modes to authorised users.
Operations
Selection:
In FPT_TST.1 the PP/ST author should specify when the TSF will execute the TSF test; during initial start-up, periodically during normal operation, at the request of an authorised user, at other conditions. In
Page 332 of 354 Version 2.1
August 1999

TSF self test (FPT_TST)
1301
J - Protection of the TSF (FPT) the case of the latter option, the PP/ST author should also assign what those conditions are via the following assignment.
Assignment:
In FPT_TST.1.1 the PP/ST author should, if selected, specify the conditions under which the self test should take place.
August 1999 Version 2.1
Page 333 of 354

1302
This class provides three families that support the availability of required resources such as processing capability and/or storage capacity. The family Fault Tolerance provides protection against unavailability of capabilities caused by failure of the
TOE. The family Priority of Service ensures that the resources will be allocated to the more important or time-critical tasks, and cannot be monopolised by lower priority tasks. The family Resource Allocation provides limits on the use of available resources, therefore preventing users from monopolising the resources.
Resource utilisation
FRU_FLT Fault tolerance
FRU_PRS Priority of service
FRU_RSA Resource allocation
1
1
1
Figure K.1 - Resource utilisation class decomposition
2
2
2
August 1999 Version 2.1
Page 334 of 354

Fault tolerance (FRU_FLT) K - Resource utilisation (FRU)
FRU_FLT
1303
Fault tolerance
This family provides requirements for the availability of capabilities even in the case of failures. Examples of such failures are power failure, hardware failure, or software error. In case of these errors, if so specified, the TOE will maintain the specified capabilities. The PP/ST author could specify, for example, that a TOE used in a nuclear plant will continue the operation of the shut-down procedure in the case of power-failure or communication-failure.
1304
1305
1306
User notes
Because the TOE can only continue its correct operation if the TSP is enforced, there is a requirement that the system must remain in a secure state after a failure.
This capability is provided by FPT_FLS.1.
The mechanisms to provide fault tolerance could be active or passive. In case of an active mechanism, specific functions are in place that are activated in case the error occurs. For example, a fire alarm is an active mechanism: the TSF will detect the fire and can take action such as switching operation to a backup. In a passive scheme, the architecture of the TOE is capable of handling the error. For example, the use of a majority voting scheme with multiple processors is a passive solution; failure of one processor will not disrupt the operation of the TOE (although it needs to be detected to allow correction).
For this family, it does not matter whether the failure has been initiated accidentally
(such as flooding or unplugging the wrong device) or intentionally (such as monopolising).
FRU_FLT.1
Degraded fault tolerance
User application notes
1307
This component is intended to specify which capabilities the TOE will still provide after a failure of the system. Since it would be difficult to describe all specific failures, categories of failures may be specified. Examples of general failures are flooding of the computer room, short term power interruption, breakdown of a CPU or host, software failure, or buffer overflow.
1308
1309
Operations
Assignment:
In FRU_FLT.1.1 the PP/ST author should specify the list of TOE capabilities the TOE will maintain during and after a specified failure.
In FRU_FLT.1.1 the PP/ST author should specify the list of type of failures against which the TOE has to be explicitly protected. If a failure in this list occurs, the TOE will be able to continue its operation.
August 1999 Version 2.1
Page 335 of 354

K - Resource utilisation (FRU) Fault tolerance (FRU_FLT)
FRU_FLT.2
Limited fault tolerance
User application notes
1310
1311
This component is intended to specify against what type of failures the TOE must be resistant. Since it would be difficult to describe all specific failures, categories of failures may be specified. Examples of general failures are flooding of the computer room, short term power interruption, breakdown of a CPU or host, software failure, or overflow of buffer.
Operations
Assignment:
In FRU_FLT.2.1 the PP/ST author should specify the list of type of failures against which the TOE has to be explicitly protected. If a failure in this list occurs, the TOE will be able to continue its operation.
Page 336 of 354 Version 2.1
August 1999

Priority of service (FRU_PRS) K - Resource utilisation (FRU)
FRU_PRS
1312
Priority of service
The requirements of this family allow the TSF to control the use of resources within the TSC by users and subjects such that high priority activities within the TSC will always be accomplished without interference or delay due to low priority activities.
In other words, time critical tasks will not be delayed by tasks that are less time critical.
1313
1314
This family could be applicable to several types of resources, for example, processing capacity, and communication channel capacity.
The Priority of Service mechanism might be passive or active. In a passive Priority of Service system, the system will select the task with the highest priority when given a choice between two waiting applications. While using passive Priority of
Service mechanisms, when a low priority task is running, it cannot be interrupted by a high priority task.While using an active Priority of Service mechanisms, lower priority tasks might be interrupted by new high priority tasks.
1315
User notes
The audit requirement states that all reasons for rejection should be audited. It is left to the developer to argue that an operation is not rejected but delayed.
FRU_PRS.1
Limited priority of service
1316
User application notes
This component defines priorities for a subject, and the resources for which this priority will be used. If a subject attempts to take action on a resource controlled by the Priority of Service requirements, the access and/or time of access will be dependent on the subject’s priority, the priority of the currently acting subject, and the priority of the subjects still in the queue.
1317
Operations
Assignment:
For FRU_PRS.1.2, the PP/ST author should specify the list of controlled resources for which the TSF enforces priority of service (e.g.
resources such as processes, disk space, memory, bandwidth).
FRU_PRS.2
Full priority of service
1318
User application notes
This component defines priorities for a subject. All shareable resources in the TSC will be subjected to the Priority of Service mechanism. If a subject attempts to take action on a shareable TSC resource, the access and/or time of access will be dependent on the subject’s priority, the priority of the currently acting subject, and the priority of the subjects still in the queue.
August 1999 Version 2.1
Page 337 of 354

K - Resource utilisation (FRU) Resource allocation (FRU_RSA)
FRU_RSA
1319
Resource allocation
The requirements of this family allow the TSF to control the use of resources within the TSC by users and subjects such that unauthorised denial of service will not take place by means of monopolisation of resources by other users or subjects.
1320
1321
1322
-
-
User notes
Resource allocation rules allow the creation of quotas or other means of defining limits on the amount of resource space or time that may be allocated on behalf of a specific user or subjects. These rules may, for example:
Provide for object quotas that constrain the number and/or size of objects a specific user may allocate.
Control the allocation/deallocation of preassigned resource units where these units are under the control of the TSF.
In general, these functions will be implemented through the use of attributes assigned to users and resources.
The objective of these components is to ensure a certain amount of fairness among the users (e.g. a single user should not allocate all the available space) and subjects.
Since resource allocation often goes beyond the lifespan of a subject (i.e. files often exist longer than the applications that generated them), and multiple instantiations of subjects by the same user should not negatively affect other users too much, the components allow that the allocation limits are related to the users. In some situations the resources are allocated by a subject (e.g. main memory or CPU cycles). In those instances the components allow that the resource allocation be on the level of subjects.
1323
This family imposes requirements on resource allocation, not on the use of the resource itself. The audit requirements therefore, as stated, also apply to the allocation of the resource, not to the use of the resource.
FRU_RSA.1
Maximum quotas
1324
User application notes
This component provides requirements for quota mechanisms that apply to only a specified set of the shareable resources in the TOE. The requirements allow the quotas to be associated with a user, possibly assigned to groups of users or subjects as applicable to the TOE.
1325
Operations
Assignment:
In FRU_RSA.1.1, the PP/ST author should specify the list of controlled resources for which maximum resource allocation limits are required
Page 338 of 354 Version 2.1
August 1999

Resource allocation (FRU_RSA) K - Resource utilisation (FRU)
1326
1327
(e.g. processes, disk space, memory, bandwidth). If all resources in the
TSC need to be included, the words “all TSC resources” can be specified.
Selection:
In FRU_RSA.1.1, the PP/ST author should select whether the maximum quotas apply to individual users, to a defined group of users, or subjects or any combination of these.
In FRU_RSA.1.1, the PP/ST author should select whether the maximum quotas are applicable to any given time (simultaneously), or over a specific time interval.
FRU_RSA.2
Minimum and maximum quotas
User application notes
1328
1329
1330
1331
1332
This component provides requirements for quota mechanisms that apply to a specified set of the shareable resources in the TOE. The requirements allow the quotas to be associated with a user, or possibly assigned to groups of users as applicable to the TOE.
Operations
Assignment:
In FRU_RSA.2.1, the PP/ST author should specify the controlled resources for which maximum and minimum resource allocation limits are required
(e.g. processes, disk space, memory, bandwidth). If all resources in the TSC need to be included, the words “all TSC resources” can be specified.
Selection:
In FRU_RSA.2.1, the PP/ST author should select whether the maximum quotas apply to individual users, to a defined group of users, or subjects or any combination of these.
In FRU_RSA.2.1, the PP/ST author should select whether the maximum quotas are applicable to any given time (simultaneously), or over a specific time interval.
Assignment:
In FRU_RSA.2.2, the PP/ST author should specify the controlled resources for which a minimum allocation limit needs to be set (e.g.
processes, disk space, memory, bandwidth). If all resources in the TSC need to be included the words “all TSC resources” can be specified.
August 1999 Version 2.1
Page 339 of 354

K - Resource utilisation (FRU)
1333
1334
Resource allocation (FRU_RSA)
Selection:
In FRU_RSA.2.2, the PP/ST author should select whether the minimum quotas apply to individual users, to a defined group of users, or subjects or any combination of these.
In FRU_RSA.2.2, the PP/ST author should select whether the minimum quotas are applicable to any given time (simultaneously), or over a specific time interval.
Page 340 of 354 Version 2.1
August 1999

1335
1336
1337
The establishment of a user’s session typically consists of the creation of one or more subjects that perform operations in the TOE on behalf of the user. At the end of the session establishment procedure, provided the TOE access requirements are satisfied, the created subjects bear the attributes determined by the identification and authentication functions. This family specifies functional requirements for controlling the establishment of a user’s session.
A user session is defined as the period starting at the time of the identification/ authentication, or if more appropriate, the start of an interaction between the user and the system, up to the moment that all subjects (resources and attributes) related to that session have been deallocated.
Figure L.1 shows the decomposition of this class into its constituent components.
TOE access
FTA_LSA Limitation on scope of selectable attributes
FTA_MCS Limitation on multiple concurrent sessions
FTA_SSL Limitation on multiple concurrent
FTA_TAB TOE access banners
FTA_TAH TOE access history
FTA_TSE TOE session establishment
Figure L.1 - TOE access class decomposition
1
2
3
1
1
1
1
1 2
August 1999 Version 2.1
Page 341 of 354

L - TOE access (FTA) Limitation on scope of selectable attributes (FTA_LSA)
FTA_LSA
1338
Limitation on scope of selectable attributes
This family defines requirements that will limit the session security attributes a user may select, and the subjects to which a user may be bound, based on: the method of access; the location or port of access; and/or the time (e.g. time-of-day, day-ofweek).
1339
User notes
This family provides the capability for a PP/ST author to specify requirements for the TSF to place limits on the domain of an authorised user’s security attributes based on an environmental condition. For example, a user may be allowed to establish a “secret session” during normal business hours but outside those hours the same user may be constrained to only establishing “unclassified sessions”. The identification of relevant constraints on the domain of selectable attributes can be achieved through the use of the selection operation. These constraints can be applied on an attribute-by-attribute basis. When there exists a need to specify constraints on multiple attributes this component will have to be replicated for each attribute. Examples of attributes that could be used to limit the session security attributes are: a) b)
The method of access can be used to specify in which type of environment the user will be operating (e.g. file transfer protocol, terminal, vtam).
The location of access can be used to constrain the domain of a user’s selectable attributes based on a user’s location or port of access. This capability is of particular use in environments where dial-up facilities or network facilities are available.
c) The time of access can be used to constrain the domain of a user’s selectable attributes. For example, ranges may be based upon time-of-day, day-ofweek, or calendar dates. This constraint provides some operational protection against user actions that could occur at a time where proper monitoring or where proper procedural measures may not be in place.
FTA_LSA.1
Limitation on scope of selectable attributes
1340
1341
Operations
Assignment:
In FTA_LSA.1.1 the PP/ST author should specify the set of session security attributes that are to be constrained. Examples of these session security attributes are user clearance level, integrity level and roles.
In FTA_LSA.1.1 the PP/ST author should specify the set of attributes that can be use to determine the scope of the session security attributes.
Examples of such attributes are user identity, originating location, time of access, and method of access.
Page 342 of 354 Version 2.1
August 1999

Limitation on multiple concurrent sessions (FTA_MCS) L - TOE access (FTA)
FTA_MCS
1342
Lim itation on multiple concurrent sessions
This family defines how many sessions a user may have at the same time
(concurrent sessions). This number of concurrent sessions can either be set for a group of users or for each individual user.
FTA_MCS.1
Basic limitation on multiple concurrent sessions
1343
1345
User application notes
This component allows the system to limit the number of sessions in order to effectively use the resources of the TOE.
1344
Operations
Assignment:
In FTA_MCS.1.2 the PP/ST author should specify the default number of maximum concurrent sessions to be used.
FTA_MCS.2
Per user attribute limitation on multiple concurrent sessions
User application notes
This component provides additional capabilities over those of FTA_MCS.1, by allowing further constraints to be placed on the number of concurrent sessions that users are able to invoke. These constraints are in terms of a user’s security attributes, such as a user’s identity, or membership of a role.
1346
1347
Operations
Assignment:
For FTA_MCS.2.1 the PP/ST author should specify the rules that determine the maximum number of concurrent sessions. An example of a rule is “maximum number of concurrent sessions is one if the user has a classification level of ‘secret’ and five otherwise”.
In FTA_MCS.2.2 the PP/ST author should specify the default number of maximum concurrent sessions to be used.
August 1999 Version 2.1
Page 343 of 354

L - TOE access (FTA) Session locking (FTA_SSL)
FTA_SSL
1348
Limitation on multiple concurrent sessions
This family defines requirements for the TSF to provide the capability for locking and unlocking of interactive sessions (e.g. keyboard locking).
1349
1350
When a user is directly interacting with subjects in the TOE (interactive session), the user’s terminal is vulnerable if left unattended. This family provides requirements for the TSF to disable (lock) the terminal or terminate the session after a specified period of inactivity, and for the user to initiate the disabling (locking) of the terminal. To reactivate the terminal, an event specified by the PP/ST author, such as the user re-authentication must occur.
A user is considered inactive, if he/she has not provided any stimulus to the TOE for a period of time.
1351
A PP/ST author should consider whether FTP_TRP.1 Trusted path should be included. In that case, the function ‘session locking’ should be included in the operation in FTP_TRP.1.
FTA_SSL.1
TSF-initiated session locking
1352
User application notes
FTA_SSL.1 TSF-initiated session locking, provides the capability for the TSF to lock an active user session after a specified period of time. Locking a terminal would prevent any further interaction with an existing active session through the use of the locked terminal.
1353
1354
1355
1356
If display devices are overwritten, the replacement contents need not be static (i.e.
‘screen savers’ are permitted).
This component allows the PP/ST author to specify what events will unlock the session. These events may be related to the terminal (e.g. fixed set of keystrokes to unlock the session), the user (e.g. reauthentication), or time.
Operations
Assignment:
In FTA_SSL.1.1 the PP/ST author should specify the interval of user inactivity that will trigger the locking of an interactive session. If so desired the PP/ST author could, through the assignment, specify that the time interval is left to the authorised administrator or the user. The management functions in the FMT class can specify the capability to modify this time interval, making it the default value.
In FTA_SSL.1.2 the PP/ST author should specify the event(s) that should occur before the session is unlocked. Examples of such an event are: “user re-authentication” or “user enters unlock key-sequence”.
Page 344 of 354 Version 2.1
August 1999

Session locking (FTA_SSL) L - TOE access (FTA)
FTA_SSL.2
User-initiated locking
User application notes
1357
FTA_SSL.2 User-initiated locking, provides the capability for an authorised user to lock and unlock his/her own terminal. This would provide authorised users with the ability to effectively block further use of their active sessions without having to terminate the active session.
1358
If devices are overwritten, the replacement contents need not be static (i.e. ‘screen savers’ are permitted).
Operations
1359
Assignment:
In FTA_SSL.2.2 the PP/ST author should specify the event(s) that should occur before the session is unlocked. Examples of such an event are: “user re-authentication”, or “user enters unlock key-sequence”.
FTA_SSL.3
TSF-initiated termination
User application notes
1360
1361
1362
FTA_SSL.3 TSF-initiated termination, requires that the TSF terminate an interactive user session after a period of inactivity.
The PP/ST author should be aware that a session may continue after the user terminated his/her activity, for example, background processing. This requirement would terminate this background subject after a period of inactivity of the user without regard to the status of the subject.
Operations
Assignment:
In FTA_SSL.3.1 the PP/ST author should specify the interval of user inactivity that will trigger the termination of an interactive session. If so desired, the PP/ST author could, through the assignment, specify that the interval is left to the authorised administrator or the user. The management functions in the FMT class can specify the capability to modify this time interval, making it the default value.
August 1999 Version 2.1
Page 345 of 354

L - TOE access (FTA) TOE access banners (FTA_TAB)
FTA_TAB
1363
TOE access banners
Prior to identification and authentication, TOE access requirements provide the ability for the TOE to display an advisory warning message to potential users pertaining to appropriate use of the TOE.
FTA_TAB.1
Default TOE access banners
1364
This component requires that there is an advisory warning regarding the unauthorised use of the TOE. A PP/ST author could refine the requirement to include a default banner.
Page 346 of 354 Version 2.1
August 1999

TOE access history (FTA_TAH) L - TOE access (FTA)
FTA_TAH
1365
TOE access history
This family defines requirements for the TSF to display to users, upon successful session establishment to the TOE, a history of unsuccessful attempts to access the account. This history may include the date, time, means of access, and port of the last successful access to the TOE, as well as the number of unsuccessful attempts to access the TOE since the last successful access by the identified user.
FTA_TAH.1
TOE access history
1366
1367
1368
1369
This family can provide authorised users with information that may indicate the possible misuse of their user account.
This component request that the user is presented with the information. The user should be able to review the information, but is not forced to do so. If a user so desires he might, for example, create scripts that ignore this information and start other processes.
Operations
Selection:
In FTA_TAH.1.1, the PP/ST author should select the security attributes of the last successful session establishment that will be shown at the user interface. The items are: date, time, method of access (such as ftp), and/or location (e.g. terminal 50).
In FTA_TAH.1.2, the PP/ST author should select the security attributes of the last unsuccessful session establishment that will be shown at the user interface. The items are: date, time, method of access
(such as ftp), and/or location (e.g. terminal 50).
August 1999 Version 2.1
Page 347 of 354

L - TOE access (FTA) TOE session establishment (FTA_TSE)
FTA_TSE
1370
1371
1372
TOE session establishment
This family defines requirements to deny an user permission to establish a session with the TOE based on attributes such as the location or port of access, the user's security attribute (e.g. identity, clearance level, integrity level, membership in a role), ranges of time (e.g. time-of-day, day-of-week, calendar dates) or combinations of parameters.
User notes
This family provides the capability for the PP/ST author to specify requirements for the TOE to place constraints on the ability of an authorised user to establish a session with the TOE. The identification of relevant constraints can be achieved through the use of the selection operation. Examples of attributes that could be used to specify the session establishment constraints are: a) b)
The location of access can be used to constrain the ability of a user to establish an active session with the TOE, based on the user’s location or port of access. This capability is of particular use in environments where dial-up facilities or network facilities are available.
The user’s security attributes can be used to place constraints on the ability of a user to establish an active session with the TOE. For example, these attributes would provide the capability to deny session establishment based on any of the following:
-
-
-
a user's identity; a user's clearance level; a user's integrity level; and a user's membership in a role.
This capability is particularly relevant in situations where authorisation or login may take place at a different location from where TOE access checks are performed.
a) The time of access can be used to constrain the ability of a user to establish an active session with the TOE based on ranges of time. For example, ranges may be based upon time-of-day, day-of-week, or calendar dates. This constraint provides some operational protection against actions that could occur at a time where proper monitoring or where proper procedural measures may not be in place.
FTA_TSE.1
TOE session establishment
Operations
1373
Assignment:
In FTA_TSE.1.1 the PP/ST author should specify the attributes that can be used to restrict the session establishment. Example of possible attributes are user identity, originating location (e.g. no remote
Page 348 of 354 Version 2.1
August 1999

TOE session establishment (FTA_TSE) L - TOE access (FTA) terminals), time of access (e.g. outside hours), or method of access (e.g.
X-windows).
August 1999 Version 2.1
Page 349 of 354

L - TOE access (FTA) TOE session establishment (FTA_TSE)
Page 350 of 354 Version 2.1
August 1999

1374
1375
1376
1377
Users often need to perform functions through direct interaction with the TSF. A trusted path provides confidence that a user is communicating directly with the TSF whenever it is invoked. A user’s response via the trusted path guarantees that untrusted applications cannot intercept or modify the user’s response. Similarly, trusted channels are one approach for secure communication between the TSF and remote IT products.
Figure 1.2 of this part of the CC illustrates the relationships between the various types of communication that may occur within a TOE or network of TOEs (i.e.
Internal TOE transfers, Inter-TSF transfers, and Import/Export Outside of TSF
Control) and the various forms of trusted paths and channels.
Absence of a trusted path may allow breaches of accountability or access control in environments where untrusted applications are used. These applications can intercept user-private information, such as passwords, and use it to impersonate other users. As a consequence, responsibility for any system actions cannot be reliably assigned to an accountable entity. Also, these applications could output erroneous information on an unsuspecting user’s display, resulting in subsequent user actions that may be erroneous and may lead to a security breach.
Figure M.1 shows the decomposition of this class into its constituent components.
Trusted path/channels
FTP_ITC Inter-TSF trusted channel
FTP_TRP Trusted path
1
1
Figure M.1 - Trusted path/channels class decomposition
August 1999 Version 2.1
Page 351 of 354

M - Trusted path/channels (FTP) Inter-TSF trusted channel (FTP_ITC)
FTP_ITC
1378
Inter-TSF trusted channel
This family defines the rules for the creation of a trusted channel connection that goes between the TSF and another trusted IT product for the performance of security critical operations between the products. An example of such a security critical operation is the updating of the TSF authentication database by the transfer of data from a trusted product whose function is the collection of audit data.
FTP_ITC.1
Inter-TSF trusted channel
1379
1380
1381
User Application Notes
This component should be used when a trusted communication channel between the
TSF and another trusted IT product is required.
Operations
Selection:
In FTP_ITC.1.2, the PP/ST author must specify whether the local TSF, the remote trusted IT product, or both shall have the capability to initiate the trusted channel.
Assignment:
In FTP_ITC.1.3, the PP/ST author should specify the functions for which a trusted channel is required. Examples of these functions may include transfer of user, subject, and/or object security attributes and ensuring consistency of TSF data.
Page 352 of 354 Version 2.1
August 1999

Trusted path (FTP_TRP) M - Trusted path/channels (FTP)
FTP_TRP
1382
Trusted path
This family defines the requirements to establish and maintain trusted communication to or from users and the TSF. A trusted path may be required for any security-relevant interaction. Trusted path exchanges may be initiated by a user during an interaction with the TSF, or the TSF may establish communication with the user via a trusted path.
FTP_TRP.1
Trusted path
1383
1384
1385
1386
1387
User Application Notes
This component should be used when trusted communication between a user and the TSF is required, either for initial authentication purposes only or for additional specified user operations.
Operations
Selection:
In FTP_TRP.1.1, the PP/ST author should specify whether the trusted path must be extended to remote and/or local users.
In FTP_TRP.1.2, the PP/ST author should specify whether the TSF, local users, and/or remote users should be able to initiate the trusted path.
In FTP_TRP.1.3, the PP/ST author should specify whether the trusted path is to be used for initial user authentication and/or for other specified services.
Assignment:
In FTP_TRP.1.3, if selected, the PP/ST author should identify other services for which trusted path is required, if any.
August 1999 Version 2.1
Page 353 of 354

M - Trusted path/channels (FTP) Trusted path (FTP_TRP)
Page 354 of 354 Version 2.1
August 1999

Common Criteria for Information Technology
Security Evaluation

Part 3: Security assurance requirements
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:
France:
Germany:
Netherlands:
Communications Security Establishment
Service Central de la Sécurité des Systèmes d’Information
Bundesamt für Sicherheit in der Informationstechnik
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 requirements v
1
1.1
1.2
1.2.1
1.2.2
1.2.3
2.1.6
2.2
2.3
2.4
2.5
2.6
2.6.1
2.6.2
2
2.1
2.1.1
2.1.2
2.1.3
2.1.4
2.1.5
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
August 1999
Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Organisation of CC Part 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
CC assurance paradigm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
CC philosophy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Assurance approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
The CC evaluation assurance scale . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Security assurance requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Class structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Assurance family structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Assurance component structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Assurance elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
EAL structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Relationship between assurances and assurance levels . . . . . . . . . . . . 13
Component taxonomy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Protection Profile and Security Target evaluation criteria class structure . 13
Usage of terms in Part 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Assurance categorisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Assurance class and family overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Class ACM: Configuration management . . . . . . . . . . . . . . . . . . . . . . . 17
Class ADO: Delivery and operation . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Class ADV: Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Class AGD: Guidance documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Class ALC: Life cycle support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Class ATE: Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Class AVA: Vulnerability assessment . . . . . . . . . . . . . . . . . . . . . . . . . 21
Maintenance categorisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Maintenance of assurance class and family overview . . . . . . . . . . . . . . . . 22
Class AMA: Maintenance of assurance . . . . . . . . . . . . . . . . . . . . . . . . 22
Protection Profile and Security Target evaluation criteria . . . . . . . . . . . . 24
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Protection Profile criteria overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Protection Profile evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Relation to the Security Target evaluation criteria . . . . . . . . . . . . . . . . 24
Evaluator tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Security Target criteria overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Security Target evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Relation to the other evaluation criteria in this Part 3 . . . . . . . . . . . . . 25
Evaluator tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Class APE: Protection Profile evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
TOE description (APE_DES) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Security environment (APE_ENV) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Version 2.1
Page iii of viii

Contents Part 3: Security assurance requirements
7
8
8.1
8.2
8.3
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
5
5.1
5.2
5.3
5.4
5.5
5.6
5.7
5.8
4.3
4.4
4.5
4.6
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) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Security objectives (APE_OBJ) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
IT security requirements (APE_REQ) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Explicitly stated IT security requirements (APE_SRE) . . . . . . . . . . . . . . . 36
Class ASE: Security Target evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
TOE description (ASE_DES) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Security environment (ASE_ENV) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
ST introduction (ASE_INT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Security objectives (ASE_OBJ) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
PP claims (ASE_PPC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
IT security requirements (ASE_REQ) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Explicitly stated IT security requirements (ASE_SRE) . . . . . . . . . . . . . . . 49
TOE summary specification (ASE_TSS) . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Evaluation assurance levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Evaluation assurance level (EAL) overview . . . . . . . . . . . . . . . . . . . . . . . 53
Evaluation assurance level details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
EAL1 - functionally tested . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
EAL2 - structurally tested . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
EAL3 - methodically tested and checked . . . . . . . . . . . . . . . . . . . . . . . 58
EAL4 - methodically designed, tested, and reviewed . . . . . . . . . . . . . 60
EAL5 - semiformally designed and tested . . . . . . . . . . . . . . . . . . . . . . 62
EAL6 - semiformally verified design and tested . . . . . . . . . . . . . . . . . 64
EAL7 - formally verified design and tested . . . . . . . . . . . . . . . . . . . . . 66
Assurance classes, families, and components . . . . . . . . . . . . . . . . . . . . . . . . 68
Class ACM: Configuration management . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
CM automation (ACM_AUT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
CM capabilities (ACM_CAP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
CM scope (ACM_SCP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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
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
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
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
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 . . . . . . . . . . . . . . . . . . . . . . . . 38
Figure 8.1 Configuration management class decomposition . . . . . . . . . . . . . . . . . . . . . . . 69
Figure 9.1 Delivery and operation class decomposition . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Figure 10.1 - Development class decomposition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Figure 10.2 - Relationships between TOE representations and requirements . . . . . . . . . . . . 91
Figure 11.1 - Guidance documents class decomposition . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Figure 12.1 - Life-cycle support class decomposition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Figure 13.1 - Tests class decomposition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
Figure 14.1 - Vulnerability assessment class decomposition . . . . . . . . . . . . . . . . . . . . . . . . . 164
Figure 15.1 - Example assurance maintenance cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
Figure 15.2 - Example TOE acceptance approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
Figure 15.3 - Example TOE monitoring approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
Figure 16.1 - Maintenance of assurance class decomposition . . . . . . . . . . . . . . . . . . . . . . . . 193
August 1999 Version 2.1
Page vi of viii

Part 3: Security assurance requirements
Table 2.1 Assurance family breakdown and mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Table 2.2 Maintenance of assurance class decomposition . . . . . . . . . . . . . . . . . . . . . . . . 22
Table 3.1 Protection Profile families - only CC requirements . . . . . . . . . . . . . . . . . . . . . 25
Table 3.2 Protection Profile families - CC extended requirements . . . . . . . . . . . . . . . . . 25
Table 3.3 Security Target families - only CC requirements . . . . . . . . . . . . . . . . . . . . . . . 26
Table 3.4 Security Target families - CC extended requirements . . . . . . . . . . . . . . . . . . . 26
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 . . . . . . . . . . . . . . . 188
Table A.1 Assurance component dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
Table A.2 AMA Internal Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
Table B.1 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 requirements 4 Organisation of CC Part 3
1
2
3
4
5
6
7
8
9
10
1.2.1
11
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.
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.
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.
August 1999 Version 2.1
Page 1 of 208

1 - Scope CC assurance paradigm
16
17
12
1.2.2
13
14
1.2.2.1
15
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) eliminated — that is, active steps should be taken to expose, and remove or neutralise, all exercisable vulnerabilities; b) c) 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.
Page 2 of 208 Version 2.1
August 1999

CC assurance paradigm 1 - Scope
1.2.2.2
18
1.2.2.3
19
1.2.2.4
20 g) h) i) j)
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; c) d) a) b) e) f) 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.
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: 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.
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) 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; c) 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.1.1
24
2.1.1.1
25
26
22
23
2.1.1.2
27
2.1.1.3
28
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.
August 1999 Version 2.1
Page 5 of 208

2 - Security assurance requirements Structures
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
2.1.2
29
Figure 2.1 - Assurance class/family/component/element hierarchy
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
31
2.1.2.2
32
33
2.1.2.3
34
35
2.1.2.4
36
2.1.2.5
37
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.
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
Assurance elements
Dependencies
39
2.1.3.1
40
41
42
2.1.3.2
43
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.
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
Page 8 of 208 Version 2.1
August 1999

Structures 2 - Security assurance requirements
2.1.3.3
44
2.1.3.4
45
46
47
48
2.1.3.5
49
50 that have this subclause, it presents the specific intent of the component and a more detailed explanation of the objectives.
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.
b) c)
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
August 1999 Version 2.1
Page 9 of 208

2 - Security assurance requirements Structures
51
52
53
2.1.4
54
55
56
2.1.5
57
2.1.5.1
58 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.
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.
Page 10 of 208 Version 2.1
August 1999

Structures 2 - Security assurance requirements
59
2.1.5.2
60
2.1.5.3
61
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.
Evaluation assurance level
EAL name
Objectives
Application notes
Assurance component
Component identification
Objectives
Application notes
Dependencies
Assurance element
Assurance elements
Assurance elements
August 1999
Figure 2.3 - EAL structure
Version 2.1
Page 11 of 208

2 - Security assurance requirements Structures
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
Evaluation assurance level
EAL name
Objectives
Application notes
Assurance component
Component identification
Objectives
Application notes
Dependencies
Assurance element
Assurance elements
Assurance elements
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
2.1.6
64
65
66
67
A higher level of assurance than that provided by a given EAL can be achieved by: a) including additional assurance components from other assurance families; or b) replacing an assurance component with a higher level assurance component from the same assurance family.
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.
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
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.
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
76
77
78
74
75
68
69
70
71
72
73
Page 14 of 208
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.
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”
Version 2.1
August 1999

85
86
87
88
83
84
81
82
79
80
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.
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.
August 1999 Version 2.1
Page 15 of 208

2 - Security assurance requirements Assurance categorisation
89
90
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 Class
Class ACM:
Configuration management
Assurance Family
CM automation
CM capabilities
CM scope
Class ADO: Delivery and operation
Delivery
Installation, generation and start-up
Functional specification
High-level design
Implementation representation
TSF internals
Class ADV:
Development
Low-level design
Representation correspondence
Security policy modeling
Class AGD: Guidance documents
Administrator guidance
User guidance
Development security
Class ALC: Life cycle support
Flaw remediation
Life cycle definition
Tools and techniques
Class ATE: Tests
Class AVA:
Vulnerability assessment
Coverage
Depth
Functional tests
Independent testing
Covert channel analysis
Misuse
Strength of TOE security functions
Vulnerability analysis
Abbreviated Name
ACM_AUT
ACM_CAP
ACM_SCP
ADO_DEL
ADO_IGS
ADV_FSP
ADV_HLD
ADV_IMP
ADV_INT
ADV_LLD
ADV_RCR
ADV_SPM
AGD_ADM
AGD_USR
ALC_DVS
ALC_FLR
ALC_LCD
ALC_TAT
ATE_COV
ATE_DPT
ATE_FUN
ATE_IND
AVA_CCA
AVA_MSU
AVA_SOF
AVA_VLA
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.1
92
2.6.1.2
93
2.6.1.3
94
2.6.2
95
2.6.1
91
2.6.2.1
96
2.6.2.2
97
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.
August 1999 Version 2.1
Page 17 of 208

2 - Security assurance requirements Assurance class and family overview
2.6.3
98
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
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
Page 18 of 208 Version 2.1
August 1999

Assurance class and family overview 2 - Security assurance requirements
2.6.4
106
2.6.4.1
107
2.6.4.2
108
2.6.5
109
2.6.5.1
110
2.6.5.2
111 the functional specification, the security policy model, and the security policies that are modelled.
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
August 1999 Version 2.1
Page 19 of 208

2 - Security assurance requirements Assurance class and family overview
2.6.5.3
112
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 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.
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
Page 20 of 208 Version 2.1
August 1999

Maintenance categorisation 2 - Security assurance requirements
2.6.7
119
2.6.7.1
120
2.6.7.2
121
2.6.7.3
122
2.6.7.4
123
124 family adds value by the introduction of tests that are not part of the developers tests.
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.
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
126
2.8.1
127
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 Class
Maintenance of assurance
Assurance Family
Assurance maintenance plan
TOE component categorisation report
Evidence of assurance maintenance
Security impact analysis
Abbreviated Name
AMA_AMP
AMA_CAT
AMA_EVD
AMA_SIA
2.8.1.1
128
2.8.1.2
129
2.8.1.3
130
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.
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
134
135
132
133
136
3.2.1
137
3.2.2
138
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.
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.
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
3.2.3.2
140
Class Family
Protection Profile, TOE description
Class APE:
Protection
Profile evaluation
Protection Profile, Security environment
Protection Profile, PP introduction
Protection Profile, Security objectives
Protection Profile, IT security requirements
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
Class Family
Protection Profile, TOE description
Class APE:
Protection
Profile evaluation
Protection Profile, Security environment
Protection Profile, PP introduction
Protection Profile, Security objectives
Protection Profile, TOE description
Protection Profile, Explicitly stated IT security requirements
Abbreviated Name
APE_DES
APE_ENV
APE_INT
APE_OBJ
APE_DES
APE_SRE
3.3.1
141
3.3.2
142
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
August 1999 Version 2.1
Page 25 of 208

3 - Protection Profile and Security
Target evaluation criteria
Security Target criteria overview
143
3.3.3
3.3.3.1
144 discussed here and in clause 6 while the requirements for TOE evaluations are contained in clauses 7 through 14.
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
Class
Class ASE:
Security
Target evaluation
Family
Security Target, TOE description
Security Target, Security environment
Security Target, ST introduction
Security Target, Security objectives
Security Target, PP claims
Security Target, IT security requirements
Security Target, TOE summary specification
Abbreviated Name
ASE_DES
ASE_ENV
ASE_INT
ASE_OBJ
ASE_PPC
ASE_REQ
ASE_TSS
3.3.3.2
145
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
Security Target, TOE description
Security Target, Security environment
Security Target, ST introduction
Security Target, Security objectives
Security Target, PP claims
Security Target, IT security requirements
Security Target, Explicitly stated IT security requirements
Security Target, TOE summary specification
Abbreviated Name
ASE_DES
ASE_ENV
ASE_INT
ASE_OBJ
ASE_PPC
ASE_REQ
ASE_SRE
ASE_TSS
Page 26 of 208 Version 2.1
August 1999

Security Target criteria overview 4 - Class APE: Protection Profile evaluation
146
147
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.
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 1
APE_REQ: Protection Profile, IT security requirements 1
APE_SRE: Protection Profile, Explicitly stated IT security requirements
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)
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.
APE_DES.1.2E The evaluator shall confirm that the TOE description is coherent and internally consistent.
APE_DES.1.3E The evaluator shall confirm that the TOE description is consistent with the other parts of the PP.
Page 28 of 208 Version 2.1
August 1999

Security environment (APE_ENV) 4 - Class APE: Protection Profile evaluation
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.
APE_ENV.1.2C 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.
APE_ENV.1.3C 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.1E The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
APE_ENV.1.2E The evaluator shall confirm that the statement of TOE security environment is coherent and internally consistent.
August 1999 Version 2.1
Page 29 of 208

4 - Class APE: Protection Profile evaluation
PP introduction (APE_INT)
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.
APE_INT.1.2C The PP introduction shall contain a PP overview which summarises the PP in narrative form.
Evaluator action elements:
APE_INT.1.1E The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
APE_INT.1.2E The evaluator shall confirm that the PP introduction is coherent and internally consistent.
APE_INT.1.3E The evaluator shall confirm that the PP introduction is consistent with the other parts of the PP.
Page 30 of 208 Version 2.1
August 1999

Security objectives (APE_OBJ) 4 - Class APE: Protection Profile evaluation
APE_OBJ
151
Protection Profile, Security objectives
Objectives
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.
APE_OBJ.1.2D The PP developer shall provide the security objectives rationale.
Content and presentation of evidence elements:
APE_OBJ.1.1C The statement of security objectives shall define the security objectives for the
TOE and its environment.
APE_OBJ.1.2C 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.
APE_OBJ.1.3C 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.
APE_OBJ.1.4C The security objectives rationale shall demonstrate that the stated security objectives are suitable to counter the identified threats to security.
APE_OBJ.1.5C The security objectives rationale shall demonstrate that the stated security objectives are suitable to cover all of the identified organisational security policies and assumptions.
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.
APE_OBJ.1.2E The evaluator shall confirm that the statement of security objectives is complete, coherent, and internally consistent.
Page 32 of 208 Version 2.1
August 1999

IT security requirements (APE_REQ) 4 - Class APE: Protection Profile evaluation
APE_REQ
152
Protection Profile, IT security requirements
Objectives
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.
153
154
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
155
156
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”.
157
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.
APE_REQ.1
Protection Profile, IT security requirements, Evaluation requirements
Dependencies:
APE_OBJ.1 Protection Profile, Security objectives, Evaluation requirements
Developer action elements:
APE_REQ.1.1D The PP developer shall provide a statement of IT security requirements as part of the PP.
APE_REQ.1.2D The PP developer shall provide the security requirements rationale.
Content and presentation of evidence elements:
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.
APE_REQ.1.3C The statement of TOE security assurance requirements should include an
Evaluation Assurance Level (EAL) as defined in CC Part 3.
APE_REQ.1.4C The evidence shall justify that the statement of TOE security assurance requirements is appropriate.
APE_REQ.1.5C The PP shall, if appropriate, identify any security requirements for the IT environment.
APE_REQ.1.6C All completed operations on IT security requirements included in the PP shall be identified.
APE_REQ.1.7C Any uncompleted operations on IT security requirements included in the PP shall be identified.
APE_REQ.1.8C Dependencies among the IT security requirements included in the PP should be satisfied.
APE_REQ.1.9C The evidence shall justify why any non-satisfaction of dependencies is appropriate.
APE_REQ.1.10C 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.
APE_REQ.1.11C The PP shall identify any specific TOE security functional requirements for which an explicit strength of function is appropriate, together with the specific metric.
APE_REQ.1.12C 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.
APE_REQ.1.13C The security requirements rationale shall demonstrate that the IT security requirements are suitable to meet the security objectives.
APE_REQ.1.14C The security requirements rationale shall demonstrate that the set of IT security requirements together forms a mutually supportive and internally consistent whole.
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)
APE_SRE
158
159
160
161
162
Protection Profile, Explicitly stated IT security requirements
Objectives
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
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.
163 The term “IT security requirements” refers to “TOE security requirements” and the optionally included “security requirements for the IT environment”.
164
The term “TOE security requirements” refers to “TOE security functional requirements” and/or “TOE security assurance requirements”.
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.
APE_SRE.1.2D The PP developer shall provide the security requirements rationale.
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.
APE_SRE.1.2C All security requirements for the IT environment that are explicitly stated without reference to the CC shall be identified.
APE_SRE.1.3C The evidence shall justify why the security requirements had to be explicitly stated.
APE_SRE.1.4C The explicitly stated IT security requirements shall use the CC requirements components, families and classes as a model for presentation.
APE_SRE.1.5C 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.
APE_SRE.1.6C The explicitly stated IT security \requirements shall be clearly and unambiguously expressed.
APE_SRE.1.7C 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.1E The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
APE_SRE.1.2E The evaluator shall determine that all of the dependencies of the explicitly stated IT security requirements have been identified.
August 1999 Version 2.1
Page 37 of 208

5 - Class ASE: Security Target evaluation
Explicitly stated IT security requirements
(APE_SRE)
165
166
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.
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 1
ASE_SRE: Security Target, Explicitly stated IT security requirements
1
ASE_TSS: Security Target, TOE summary specification 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
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.
ASE_DES.1.2E The evaluator shall confirm that the TOE description is coherent and internally consistent.
ASE_DES.1.3E The evaluator shall confirm that the TOE description is consistent with the other parts of the ST.
August 1999 Version 2.1
Page 39 of 208

5 - Class ASE: Security Target evaluation
Security environment (ASE_ENV)
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.
ASE_ENV.1.2C 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.
ASE_ENV.1.3C 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.1E The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
ASE_ENV.1.2E The evaluator shall confirm that the statement of TOE security environment is coherent and internally consistent.
Page 40 of 208 Version 2.1
August 1999

ST introduction (ASE_INT) 5 - Class ASE: Security Target evaluation
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.
ASE_INT.1
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.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.
ASE_INT.1.2C The ST introduction shall contain an ST overview which summarises the ST in narrative form.
ASE_INT.1.3C 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.1E The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
ASE_INT.1.2E The evaluator shall confirm that the ST introduction is coherent and internally consistent.
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
ASE_OBJ
170
Security Target, Security objectives
Objectives
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.
ASE_OBJ.1.2D The developer shall provide the security objectives rationale.
Content and presentation of evidence elements:
ASE_OBJ.1.1C The statement of security objectives shall define the security objectives for the
TOE and its environment.
ASE_OBJ.1.2C 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.
ASE_OBJ.1.3C 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.
ASE_OBJ.1.4C The security objectives rationale shall demonstrate that the stated security objectives are suitable to counter the identified threats to security.
ASE_OBJ.1.5C The security objectives rationale shall demonstrate that the stated security objectives are suitable to cover all of the identified organisational security policies and assumptions.
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.
ASE_OBJ.1.2E The evaluator shall confirm that the statement of security objectives is complete, coherent, and internally consistent.
Page 44 of 208 Version 2.1
August 1999

PP claims (ASE_PPC) 5 - Class ASE: Security Target evaluation
ASE_PPC
171
172
Security Target, PP claims
Objectives
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
The family applies only in the case of a PP claim. In all other cases, no developer action and no evaluator action is necessary.
173 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.
ASE_PPC.1
S ecurity Target, PP claims, Evaluation requirements
Dependencies:
ASE_OBJ.1 Security Target, Security objectives, Evaluation requirements
ASE_REQ.1 Security Target, IT security requirements, Evaluation requirements
Developer action elements:
ASE_PPC.1.1D The developer shall provide any PP claims as part of the ST.
ASE_PPC.1.2D 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.
ASE_PPC.1.2C 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.
ASE_PPC.1.3C 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.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
ASE_REQ
174
Security Target, IT security requirements
Objectives
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.
175
176
177
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
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”.
178
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.
ASE_REQ.1
Security Target, IT security requirements, Evaluation requirements
Dependencies:
ASE_OBJ.1 Security Target, Security objectives, Evaluation requirements
Developer action elements:
ASE_REQ.1.1D The developer shall provide a statement of IT security requirements as part of the ST.
ASE_REQ.1.2D The developer shall provide the security requirements rationale.
Content and presentation of evidence elements:
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.
ASE_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.
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.
ASE_REQ.1.4C The evidence shall justify that the statement of TOE security assurance requirements is appropriate.
ASE_REQ.1.5C The ST shall, if appropriate, identify any security requirements for the IT environment.
ASE_REQ.1.6C Operations on IT security requirements included in the ST shall be identified and performed.
ASE_REQ.1.7C Dependencies among the IT security requirements included in the ST should be satisfied.
ASE_REQ.1.8C The evidence shall justify why any non-satisfaction of dependencies is appropriate.
ASE_REQ.1.9C 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.
ASE_REQ.1.10C The ST shall identify any specific TOE security functional requirements for which an explicit strength of function is appropriate, together with the specific metric.
ASE_REQ.1.11C 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.
ASE_REQ.1.12C The security requirements rationale shall demonstrate that the IT security requirements are suitable to meet the security objectives.
ASE_REQ.1.13C The security requirements rationale shall demonstrate that the set of IT security requirements together forms a mutually supportive and internally consistent whole.
Evaluator action elements:
ASE_REQ.1.1E The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
ASE_REQ.1.2E The evaluator shall confirm that the statement of IT security requirements is complete, coherent, and internally consistent.
Page 48 of 208 Version 2.1
August 1999

Explicitly stated IT security requirements (ASE_SRE)
5 - Class ASE: Security Target evaluation
ASE_SRE
179
180
181
182
183
Security Target, Explicitly stated IT security requirements
Objectives
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
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.
184 The term “IT security requirements” refers to “TOE security requirements” and the optionally included “security requirements for the IT environment”.
185
The term “TOE security requirements” refers to “TOE security functional requirements” and/or “TOE security assurance requirements”.
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.
ASE_SRE.1.2D The developer shall provide the security requirements rationale.
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.
ASE_SRE.1.2C All security requirements for the IT environment that are explicitly stated without reference to the CC shall be identified.
ASE_SRE.1.3C The evidence shall justify why the security requirements had to be explicitly stated.
ASE_SRE.1.4C The explicitly stated IT security requirements shall use the CC requirements components, families and classes as a model for presentation.
ASE_SRE.1.5C 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.
ASE_SRE.1.6C The explicitly stated IT security requirements shall be clearly and unambiguously expressed.
ASE_SRE.1.7C 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.1E The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
ASE_SRE.1.2E The evaluator shall determine that all of the dependencies of the explicitly stated IT security requirements have been identified.
Page 50 of 208 Version 2.1
August 1999

TOE summary specification (ASE_TSS) 5 - Class ASE: Security Target evaluation
ASE_TSS
186
187
Security Target, TOE sum mary specification
Objectives
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
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.
188
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.
189
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.
ASE_TSS.1
Security Target, TOE summary specification, Evaluation requirements
Dependencies:
ASE_REQ.1 Security Target, IT security requirements, Evaluation requirements
Developer action elements:
ASE_TSS.1.1D The developer shall provide a TOE summary specification as part of the ST.
ASE_TSS.1.2D 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.
ASE_TSS.1.3C The IT security functions shall be defined in an informal style to a level of detail necessary for understanding their intent.
ASE_TSS.1.4C 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.
ASE_TSS.1.5C The TOE summary specification rationale shall demonstrate that the IT security functions are suitable to meet the TOE security functional requirements.
ASE_TSS.1.6C 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.
ASE_TSS.1.7C 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.
ASE_TSS.1.8C The TOE summary specification rationale shall demonstrate that the assurance measures meet all assurance requirements of the TOE.
ASE_TSS.1.9C The TOE summary specification shall identify all IT security functions that are realised by a probabilistic or permutational mechanism, as appropriate.
ASE_TSS.1.10C 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.1E
The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
ASE_TSS.1.2E The evaluator shall confirm that the TOE summary specification is complete, coherent, and internally consistent.
Page 52 of 208 Version 2.1
August 1999

Part 3: Security assurance requirements 67
190
191
192
193
194
195 overview
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.
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.
August 1999 Version 2.1
Page 53 of 208

6 - Evaluation assurance levels Evaluation assurance level details
196
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
Class
Class ACM:
Configuration
management
Assurance
Family
Assurance Components by
Evaluation Assurance Level
EAL1 EAL2 EAL3 EAL4 EAL5 EAL6 EAL7
ACM_AUT
ACM_CAP 1 2 3
1
4
1
4
2
5
2
5
ACM_SCP
ADO_DEL 1
1
1
2
2
3
2
3
2
3
3 Class ADO:
Delivery and operation
ADO_IGS 1
Class ADV:
Development
ADV_FSP
ADV_HLD
ADV_IMP
ADV_INT
1
ADV_LLD
ADV_RCR 1
ADV_SPM
AGD_ADM 1 Class AGD:
Guidance documents
AGD_USR
Class ALC:
Life cycle support
Class ATE:
Tests
Class AVA:
Vulnerability assessment
ALC_DVS
ALC_FLR
ALC_LCD
ALC_TAT
ATE_COV
ATE_DPT
ATE_FUN
ATE_IND
AVA_CCA
AVA_MSU
AVA_SOF
AVA_VLA
1
1
1
1
1
1
1
1
1
1
2
1
1
1
1
2
1
1
1
1
2
1
1
2
1
1
1
1
2
2
1
1
1
1
1
1
1
1
1
2
1
1
2
2
1
2
1
3
3
2
1
1
2
3
1
1
1
2
2
2
2
1
2
1
2
1
3
1
3
4
3
2
2
2
3
1
1
2
2
3
3
2
2
2
2
3
1
4
1
3
2
3
1
4
3
3
3
3
2
2
3
3
1
3
3
4
5
1
2
Page 54 of 208 Version 2.1
August 1999

Evaluation assurance level details 6 - Evaluation assurance levels
6.2.1
197
198
199
200
201
202
Evaluation assurance level 1 (EAL1) - functionally tested
Objectives
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
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
Assurance class
Class ACM: Configuration management
Class ADO: Delivery and operation
Class ADV: Development
Class AGD: Guidance documents
Class ATE: Tests
Assurance components
ACM_CAP.1 Version numbers
ADO_IGS.1 Installation, generation, and start-up procedures
ADV_FSP.1 Informal functional specification
ADV_RCR.1 Informal correspondence demonstration
AGD_ADM.1 Administrator guidance
AGD_USR.1 User guidance
ATE_IND.1 Independent testing - conformance
August 1999 Version 2.1
Page 55 of 208

6 - Evaluation assurance levels Evaluation assurance level details
207
208
205
206
6.2.2
203
204
Evaluation assurance level 2 (EAL2) - structurally tested
Objectives
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
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.
Page 56 of 208 Version 2.1
August 1999

Evaluation assurance level details 6 - Evaluation assurance levels
Table 6.3 - EAL2
Assurance class
Class ACM: Configuration management
Class ADO: Delivery and operation
Class ADV: Development
Class AGD: Guidance documents
Class ATE: Tests
Class AVA: Vulnerability assessment
Assurance components
ACM_CAP.2 Configuration items
ADO_DEL.1 Delivery procedures
ADO_IGS.1 Installation, generation, and start-up procedures
ADV_FSP.1 Informal functional specification
ADV_HLD.1 Descriptive high-level design
ADV_RCR.1 Informal correspondence demonstration
AGD_ADM.1 Administrator guidance
AGD_USR.1 User guidance
ATE_COV.1 Evidence of coverage
ATE_FUN.1 Functional testing
ATE_IND.2 Independent testing - sample
AVA_SOF.1 Strength of TOE security function evaluation
AVA_VLA.1 Developer vulnerability analysis
August 1999 Version 2.1
Page 57 of 208

6 - Evaluation assurance levels Evaluation assurance level details
209
210
211
212
213
214
6.2.3
Evaluation assurance level 3 (EAL3) - methodically tested and checked
Objectives
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
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.
Page 58 of 208 Version 2.1
August 1999

Evaluation assurance level details 6 - Evaluation assurance levels
Table 6.4 - EAL3
Assurance class
Class ACM: Configuration management
Class ADO: Delivery and operation
Class ADV: Development
Class AGD: Guidance documents
Class ALC: Life cycle support
Assurance components
ACM_CAP.3 Authorisation controls
ACM_SCP.1 TOE CM coverage
ADO_DEL.1 Delivery procedures
ADO_IGS.1 Installation, generation, and start-up procedures
ADV_FSP.1 Informal functional specification
ADV_HLD.2 Security enforcing high-level design
ADV_RCR.1 Informal correspondence demonstration
AGD_ADM.1 Administrator guidance
AGD_USR.1 User guidance
ALC_DVS.1 Identification of security measures
Class ATE: Tests
Class AVA: Vulnerability assessment
ATE_COV.2 Analysis of coverage
ATE_DPT.1 Testing: high-level design
ATE_FUN.1 Functional testing
ATE_IND.2 Independent testing - sample
AVA_MSU.1 Examination of guidance
AVA_SOF.1 Strength of TOE security function evaluation
AVA_VLA.1 Developer vulnerability analysis
August 1999 Version 2.1
Page 59 of 208

6 - Evaluation assurance levels Evaluation assurance level details
219
220
6.2.4
215
216
217
218
Evaluation assurance level 4 (EAL4) - methodically designed, tested, and reviewed
Objectives
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
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.
Page 60 of 208 Version 2.1
August 1999

Evaluation assurance level details 6 - Evaluation assurance levels
Table 6.5 - EAL4
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.1 Partial CM automation
ACM_CAP.4 Generation support and acceptance procedures
ACM_SCP.2 Problem tracking CM coverage
ADO_DEL.2 Detection of modification
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
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
AGD_USR.1 User guidance
ALC_DVS.1 Identification of security measures
ALC_LCD.1 Developer defined life-cycle model
ALC_TAT.1 Well-defined development tools
ATE_COV.2 Analysis of coverage
ATE_DPT.1 Testing: high-level design
ATE_FUN.1 Functional testing
ATE_IND.2 Independent testing - sample
AVA_MSU.2 Validation of analysis
AVA_SOF.1 Strength of TOE security function evaluation
AVA_VLA.2 Independent vulnerability analysis
August 1999 Version 2.1
Page 61 of 208

6 - Evaluation assurance levels Evaluation assurance level details
225
226
6.2.5
221
222
223
224
Evaluation assurance level 5 (EAL5) - semiformally designed and tested
Objectives
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
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.
Page 62 of 208 Version 2.1
August 1999

Evaluation assurance level details 6 - Evaluation assurance levels
Table 6.6 - EAL5
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.1 Partial CM automation
ACM_CAP.4 Generation support and acceptance procedures
ACM_SCP.3 Development tools CM coverage
ADO_DEL.2 Detection of modification
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
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
AGD_USR.1 User guidance
ALC_DVS.1 Identification of security measures
ALC_LCD.2 Standardised life-cycle model
ALC_TAT.2 Compliance with implementation standards
ATE_COV.2 Analysis of coverage
ATE_DPT.2 Testing: low-level design
ATE_FUN.1 Functional testing
ATE_IND.2 Independent testing - sample
AVA_CCA.1 Covert channel analysis
AVA_MSU.2 Validation of analysis
AVA_SOF.1 Strength of TOE security function evaluation
AVA_VLA.3 Moderately resistant
August 1999 Version 2.1
Page 63 of 208

6 - Evaluation assurance levels Evaluation assurance level details
227
228
6.2.6
229
230
231
232
Evaluation assurance level 6 (EAL6) - semiformally verified design and tested
Objectives
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
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.
Page 64 of 208 Version 2.1
August 1999

Evaluation assurance level details 6 - Evaluation assurance levels
Table 6.7 - EAL6
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.2 Detection of modification
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
ADV_INT.2 Reduction of complexity
ADV_LLD.2 Semiformal low-level design
ADV_RCR.2 Semiformal 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.2 Standardised life-cycle model
ALC_TAT.3 Compliance with implementation standards - all parts
ATE_COV.3 Rigorous analysis of coverage
ATE_DPT.2 Testing: low-level design
ATE_FUN.2 Ordered functional testing
ATE_IND.2 Independent testing - sample
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 65 of 208

6 - Evaluation assurance levels Evaluation assurance level details
6.2.7
233
234
235
236
237
Evaluation assurance level 7 (EAL7) - formally verified design and tested
Objectives
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
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.
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
238
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
239
240
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.
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)
ACM_AUT
241
CM automation
Objectives
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
243
244
The components in this family are levelled on the basis of the set of configuration items that are controlled through automated means.
Application notes
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.
245
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.
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
The developer shall use a CM system.
ACM_AUT.1.2D
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.
ACM_AUT.1.2C
The CM system shall provide an automated means to support the generation of the TOE.
ACM_AUT.1.3C
The CM plan shall describe the automated tools used in the CM system.
ACM_AUT.1.4C
The CM plan shall describe how the automated tools are used in the CM system.
Evaluator action elements:
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
248
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:
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.
ACM_AUT.2.1C
Content and presentation of evidence elements:
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.
ACM_AUT.2.2C
The CM system shall provide an automated means to support the generation of the
TOE.
ACM_AUT.2.3C
The CM plan shall describe the automated tools used in the CM system.
ACM_AUT.2.4C
The CM plan shall describe how the automated tools are used in the CM system.
ACM_AUT.2.5C
The CM system shall provide an automated means to ascertain the changes between the TOE and its preceding version.
ACM_AUT.2.6C
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.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
254
255
252
253
ACM_CAP
249
250
251
256
CM capabilities
Objectives
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
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
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
August 1999 Version 2.1
Page 73 of 208

8 - Class ACM: Configuration management CM capabilities (ACM_CAP)
257 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.
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.
ACM_CAP.1.1C
Content and presentation of evidence elements:
The reference for the TOE shall be unique to each version of the TOE.
ACM_CAP.1.2C
The TOE shall be labelled with its reference.
ACM_CAP.1.1E
Evaluator action elements:
The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
ACM_CAP.2 Configuration items
Objectives
259
260
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.
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
The developer shall provide a reference for the TOE.
ACM_CAP.2.2D
The developer shall use a CM system.
ACM_CAP.2.3D
The developer shall provide CM documentation.
Content and presentation of evidence elements:
ACM_CAP.2.1C
The reference for the TOE shall be unique to each version of the TOE.
ACM_CAP.2.2C
The TOE shall be labelled with its reference.
ACM_CAP.2.3C
The CM documentation shall include a configuration list.
ACM_CAP.2.4C
The configuration list shall describe the configuration items that comprise the
TOE.
ACM_CAP.2.5C
The CM documentation shall describe the method used to uniquely identify the configuration items.
ACM_CAP.2.6C
The CM system shall uniquely identify all configuration items.
Evaluator action elements:
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.
262
263
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.
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
The developer shall provide a reference for the TOE.
ACM_CAP.3.2D
The developer shall use a CM system.
ACM_CAP.3.3D
The developer shall provide CM documentation.
Content and presentation of evidence elements:
ACM_CAP.3.1C
The reference for the TOE shall be unique to each version of the TOE.
ACM_CAP.3.2C
The TOE shall be labelled with its reference.
ACM_CAP.3.3C
The CM documentation shall include a configuration list and a CM plan.
ACM_CAP.3.4C
The configuration list shall describe the configuration items that comprise the TOE.
ACM_CAP.3.5C
The CM documentation shall describe the method used to uniquely identify the configuration items.
ACM_CAP.3.6C
The CM system shall uniquely identify all configuration items.
ACM_CAP.3.7C
The CM plan shall describe how the CM system is used.
ACM_CAP.3.8C
The evidence shall demonstrate that the CM system is operating in accordance with the CM plan.
ACM_CAP.3.9C
The CM documentation shall provide evidence that all configuration items have been and are being effectively maintained under the CM system.
ACM_CAP.3.10C
The CM system shall provide measures such that only authorised changes are made to the configuration items.
ACM_CAP.3.1E
Evaluator action elements:
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
265
266
267 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.
Dependencies:
ACM_SCP.1 TOE CM coverage
ALC_DVS.1 Identification of security measures
Developer action elements:
ACM_CAP.4.1D
The developer shall provide a reference for the TOE.
ACM_CAP.4.2D
The developer shall use a CM system.
ACM_CAP.4.3D
The developer shall provide CM documentation.
Content and presentation of evidence elements:
ACM_CAP.4.1C
The reference for the TOE shall be unique to each version of the TOE.
ACM_CAP.4.2C
The TOE shall be labelled with its reference.
ACM_CAP.4.3C
The CM documentation shall include a configuration list, a CM plan, and an acceptance plan.
ACM_CAP.4.4C
The configuration list shall describe the configuration items that comprise the TOE.
ACM_CAP.4.5C
The CM documentation shall describe the method used to uniquely identify the configuration items.
ACM_CAP.4.6C
The CM system shall uniquely identify all configuration items.
ACM_CAP.4.7C
The CM plan shall describe how the CM system is used.
ACM_CAP.4.8C
The evidence shall demonstrate that the CM system is operating in accordance with the CM plan.
ACM_CAP.4.9C
The CM documentation shall provide evidence that all configuration items have been and are being effectively maintained under the CM system.
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.
ACM_CAP.4.11C
The CM system shall support the generation of the TOE.
ACM_CAP.4.12C
The acceptance plan shall describe the procedures used to accept modified or newly created configuration items as part of the TOE.
ACM_CAP.4.1E
Evaluator action elements:
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.
269
270
271
272
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.
273
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:
ACM_CAP.5.1D
The developer shall provide a reference for the TOE.
ACM_CAP.5.2D
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
The reference for the TOE shall be unique to each version of the TOE.
ACM_CAP.5.2C
The TOE shall be labelled with its reference.
ACM_CAP.5.3C
The CM documentation shall include a configuration list, a CM plan, an acceptance plan, and integration procedures.
ACM_CAP.5.4C
The configuration list shall describe the configuration items that comprise the TOE.
ACM_CAP.5.5C
The CM documentation shall describe the method used to uniquely identify the configuration items.
ACM_CAP.5.6C
The CM system shall uniquely identify all configuration items.
ACM_CAP.5.7C
The CM plan shall describe how the CM system is used.
ACM_CAP.5.8C
The evidence shall demonstrate that the CM system is operating in accordance with the CM plan.
ACM_CAP.5.9C
The CM documentation shall provide evidence that all configuration items have been and are being effectively maintained under the CM system.
ACM_CAP.5.10C
The CM system shall provide measures such that only authorised changes are made to the configuration items.
ACM_CAP.5.11C
The CM system shall support the generation of the TOE.
ACM_CAP.5.12C
The acceptance plan shall describe the procedures used to accept modified or newly created configuration items as part of the TOE.
ACM_CAP.5.13C
The integration procedures shall describe how the CM system is applied in the
TOE manufacturing process.
ACM_CAP.5.14C
The CM system shall require that the person responsible for accepting a configuration item into CM is not the person who developed it.
ACM_CAP.5.15C
The CM system shall clearly identify the configuration items that comprise the
TSF.
ACM_CAP.5.16C
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.
ACM_CAP.5.17C
The CM system shall be able to identify the master copy of all material used to generate the TOE.
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.
ACM_CAP.5.19C
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.
ACM_CAP.5.20C
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.
ACM_CAP.5.21C
The CM documentation shall justify that the acceptance procedures provide for an adequate and appropriate review of changes to all configuration items.
ACM_CAP.5.1E
Evaluator action elements:
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
278
279
280
ACM_SCP
274
275
276
277
CM scope
Objectives
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
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
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.
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
ACM_SCP.1.1D
ACM_SCP.1.1C
Developer action elements:
The developer shall provide CM documentation.
Content and presentation of evidence elements:
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.
ACM_SCP.1.2C
ACM_SCP.1.1E
The CM documentation shall describe how configuration items are tracked by the CM system.
Evaluator action elements:
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.
283 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
Page 82 of 208 Version 2.1
August 1999

CM scope (ACM_SCP) 8 - Class ACM: Configuration management
ACM_SCP.2.1D
Developer action elements:
The developer shall provide CM documentation.
ACM_SCP.2.1C
Content and presentation of evidence elements:
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.
ACM_SCP.2.2C
ACM_SCP.2.1E
The CM documentation shall describe how configuration items are tracked by the
CM system.
Evaluator action elements:
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.
285
286
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:
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)
ACM_SCP.3.1C
ACM_SCP.3.2C
ACM_SCP.3.1E
Content and presentation of evidence elements:
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:
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
287
288
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.
Class ADO: Delivery and operation
ADO_DEL Delivery 1 2 3
ADO_IGS Installation, generation and start-up 1
Figure 9.1 -Delivery and operation class decomposition
2
August 1999 Version 2.1
Page 85 of 208

9 - Class ADO: Delivery and operation Delivery (ADO_DEL)
ADO_DELDelivery
289
290
Objectives
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
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
ADO_DEL.1.2D
ADO_DEL.1.1C
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:
The delivery documentation shall describe all procedures that are necessary to maintain security when distributing versions of the TOE to a user’s site.
ADO_DEL.1.1E
Evaluator action elements:
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
ADO_DEL.2.2D
The developer shall document procedures for delivery of the TOE or parts of it to the user.
The developer shall use the delivery procedures.
Page 86 of 208 Version 2.1
August 1999

Delivery (ADO_DEL) 9 - Class ADO: Delivery and operation
ADO_DEL.2.1C
Content and presentation of evidence elements:
The delivery documentation shall describe all procedures that are necessary to maintain security when distributing versions of the TOE to a user’s site.
ADO_DEL.2.2C
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.
ADO_DEL.2.3C
ADO_DEL.2.1E
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:
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
ADO_DEL.3.2D
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.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.
ADO_DEL.3.2C
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.
ADO_DEL.3.3C
ADO_DEL.3.1E
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:
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)
ADO_IGS
291
Installation, generation and start-up
Objectives
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
293
294
295
The components in this family are levelled on the basis of whether the TOE generation options are logged.
Application notes
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.
296
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.
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
ADO_IGS.1.1D
ADO_IGS.1.1C
ADO_IGS.1.1E
Developer action elements:
The developer shall document procedures necessary for the secure installation, generation, and start-up of the TOE.
Content and presentation of evidence elements:
The documentation shall describe the steps necessary for secure installation, generation, and start-up of the TOE.
Evaluator action elements:
The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
ADO_IGS.1.2E
The evaluator shall determine that the installation, generation, and start-up procedures result in a secure configuration.
ADO_IGS.2 Generation log
Dependencies:
AGD_ADM.1 Administrator guidance
Developer action elements:
ADO_IGS.2.1D
ADO_IGS.2.1C
ADO_IGS.2.2C
ADO_IGS.2.1E
ADO_IGS.2.2E
The developer shall document procedures necessary for the secure installation, generation, and start-up of the TOE.
Content and presentation of evidence elements:
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:
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.
August 1999 Version 2.1
Page 89 of 208

297
298
299
August 1999
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 1 2 3 4
ADV_HLD High-level design 1 2 3 4 5
ADV_IMP Implementation representation
ADV_INT TSF internals
ADV_LLD Low-level design
ADV_RCR Representation correspondence
1
1
1
1
2
2
2
2
3
3
3
3
ADV_SPM Security policy modeling 1 2 3
Figure 10.1 - Development class decomposition
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
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.
Source corresponds to target.
Environment
APE/ASE_OBJ
Security
Objectives
APE/ASE_REQ
Functional
Requirements/TSP
ASE_TSS
TOE Summary
Specification
ADV_FSP
ADV_RCR
Functional
Specification
ADV_RCR
ADV_HLD
High-level Design
ADV_RCR
ADV_LLD
Low-level Design
ADV_IMP
ADV_RCR
Implementation
Representation
ADV_SPM
Source is refined in target.
TSP Model
ADV_SPM
300
Figure 10.2 - Relationships between TOE representations and requirements
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
301
302
303
304
305
Page 92 of 208 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.
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
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.
Version 2.1
August 1999

10 - Class ADV: Development
306
307
308
309
310
311
312
August 1999
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
Version 2.1
Page 93 of 208

10 - Class ADV: Development
313 to be shown to be satisfied by the formal specification. Pointers and references to other documents may also be used.
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
ADV_FSP
314
315
316
317
318
319
Functional specification
Objectives
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
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
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.
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
ADV_FSP.1.1C
ADV_FSP.1.2C
ADV_FSP.1.3C
The developer shall provide a functional specification.
Content and presentation of evidence elements:
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.
ADV_FSP.1.4C
ADV_FSP.1.1E
ADV_FSP.1.2E
The functional specification shall completely represent the TSF.
Evaluator action elements:
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 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
ADV_FSP.2.2C
ADV_FSP.2.3C
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.
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
ADV_FSP.2.1E
ADV_FSP.2.2E
The functional specification shall completely represent the TSF.
The functional specification shall include rationale that the TSF is completely represented.
Evaluator action elements:
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 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
ADV_FSP.3.2C
ADV_FSP.3.3C
ADV_FSP.3.4C
ADV_FSP.3.5C
ADV_FSP.3.1E
ADV_FSP.3.2E
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:
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.
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
ADV_FSP.4.1C
ADV_FSP.4.2C
ADV_FSP.4.3C
ADV_FSP.4.4C
The developer shall provide a functional specification.
Content and presentation of evidence elements:
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.
ADV_FSP.4.5C
ADV_FSP.4.1E
ADV_FSP.4.2E
The functional specification shall include rationale that the TSF is completely represented.
Evaluator action elements:
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.
Page 98 of 208 Version 2.1
August 1999

High-level design (ADV_HLD) 10 - Class ADV: Development
325
326
ADV_HLD
320
321
322
323
324
High-level design
Objectives
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
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
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” refers to 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
August 1999 Version 2.1
Page 99 of 208

10 - Class ADV: Development High-level design (ADV_HLD)
327 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.
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.
328
ADV_HLD.1.1D
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.
ADV_HLD.1 Descriptive high-level design
Dependencies:
ADV_FSP.1 Informal functional specification
ADV_RCR.1 Informal correspondence demonstration
Developer action elements:
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
ADV_HLD.1.4C
ADV_HLD.1.5C
ADV_HLD.1.6C
ADV_HLD.1.7C
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.
Page 100 of 208 Version 2.1
August 1999

High-level design (ADV_HLD) 10 - Class ADV: Development
ADV_HLD.1.1E
Evaluator action elements:
The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
ADV_HLD.1.2E
The evaluator shall determine that the high-level design is an accurate and complete instantiation of the TOE security functional requirements.
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
The presentation of the high-level design shall be informal.
ADV_HLD.2.2C
The high-level design shall be internally consistent.
ADV_HLD.2.3C
The high-level design shall describe the structure of the TSF in terms of subsystems.
ADV_HLD.2.4C
The high-level design shall describe the security functionality provided by each subsystem of the TSF.
ADV_HLD.2.5C
ADV_HLD.2.6C
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.
ADV_HLD.2.7C
The high-level design shall identify which of the interfaces to the subsystems of the
TSF are externally visible.
ADV_HLD.2.8C
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.
ADV_HLD.2.9C
The high-level design shall describe the separation of the TOE into TSPenforcing and other subsystems.
August 1999 Version 2.1
Page 101 of 208

10 - Class ADV: Development High-level design (ADV_HLD)
ADV_HLD.2.1E
ADV_HLD.2.2E
Evaluator action elements:
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 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
ADV_HLD.3.5C
ADV_HLD.3.6C
ADV_HLD.3.7C
ADV_HLD.3.8C
ADV_HLD.3.9C
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.
Page 102 of 208 Version 2.1
August 1999

High-level design (ADV_HLD) 10 - Class ADV: Development
ADV_HLD.3.1E
Evaluator action elements:
The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
ADV_HLD.3.2E
The evaluator shall determine that the high-level design is an accurate and complete instantiation of the TOE security functional requirements.
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
The presentation of the high-level design shall be semiformal.
ADV_HLD.4.2C
The high-level design shall be internally consistent.
ADV_HLD.4.3C
The high-level design shall describe the structure of the TSF in terms of subsystems.
ADV_HLD.4.4C
The high-level design shall describe the security functionality provided by each subsystem of the TSF.
ADV_HLD.4.5C
ADV_HLD.4.6C
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.
ADV_HLD.4.7C
The high-level design shall identify which of the interfaces to the subsystems of the
TSF are externally visible.
ADV_HLD.4.8C
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.4.9C
The high-level design shall describe the separation of the TOE into TSP-enforcing and other subsystems.
ADV_HLD.4.10C
The high-level design shall justify that the identified means of achieving separation, including any protection mechanisms, are sufficient to ensure a
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.
ADV_HLD.4.1E
Evaluator action elements:
The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
ADV_HLD.4.2E
The evaluator shall determine that the high-level design is an accurate and complete instantiation of the TOE security functional requirements.
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
ADV_HLD.5.1C
ADV_HLD.5.2C
ADV_HLD.5.3C
The developer shall provide the high-level design of the TSF.
Content and presentation of evidence elements:
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.
ADV_HLD.5.4C
ADV_HLD.5.5C
ADV_HLD.5.6C
ADV_HLD.5.7C
ADV_HLD.5.8C
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.
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.
ADV_HLD.5.10C
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.
ADV_HLD.5.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.5.1E
The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
ADV_HLD.5.2E
The evaluator shall determine that the high-level design is an accurate and complete instantiation of the TOE security functional requirements.
August 1999 Version 2.1
Page 105 of 208

10 - Class ADV: Development Implementation representation (ADV_IMP)
ADV_IMP
329
330
Implementation representation
Objectives
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
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.
332
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.
ADV_IMP.1 Subset of the implementation of the TSF
Application notes
333
334
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
Page 106 of 208 Version 2.1
August 1999

Implementation representation (ADV_IMP) 10 - Class ADV: Development
ADV_IMP.1.1D
ADV_IMP.1.1C
ADV_IMP.1.2C
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:
The developer shall provide the implementation representation for a selected subset of the TSF.
Content and presentation of evidence elements:
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.
ADV_IMP.1.1E
Evaluator action elements:
The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
ADV_IMP.1.2E
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.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)
ADV_IMP.2.1D
ADV_IMP.2.1C
ADV_IMP.2.2C
ADV_IMP.2.3C
ADV_IMP.2.1E
Developer action elements:
The developer shall provide the implementation representation for the entire TSF.
Content and presentation of evidence elements:
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:
The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
ADV_IMP.2.2E
The evaluator shall determine that the implementation representation is an accurate and complete instantiation of the TOE security functional requirements.
ADV_IMP.3 Structured implementation of the TSF
Application notes
336
ADV_IMP.3.1D
ADV_IMP.3.1C
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:
The developer shall provide the implementation representation for the entire TSF.
Content and presentation of evidence elements:
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
ADV_IMP.3.4C
ADV_IMP.3.1E
ADV_IMP.3.2E
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:
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.
August 1999 Version 2.1
Page 109 of 208

10 - Class ADV: Development TSF internals (ADV_INT)
ADV_INT
337
338
339
340
341
342
343
344
TSF internals
Objectives
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
The components in this family are levelled on the basis of the amount of structure and minimisation required.
Application notes
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
Page 110 of 208 Version 2.1
August 1999

TSF internals (ADV_INT) 10 - Class ADV: Development
345 demonstrate that these mutual interactions are necessary and cannot reasonably be avoided.
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.
346
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.
ADV_INT.1 Modularity
Dependencies:
ADV_IMP.1 Subset of the implementation of the TSF
ADV_LLD.1 Descriptive low-level design
ADV_INT.1.1D
ADV_INT.1.2D
ADV_INT.1.1C
ADV_INT.1.2C
ADV_INT.1.3C
ADV_INT.1.1E
Developer action elements:
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:
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:
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
ADV_INT.2.1D
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:
The developer shall design and structure the TSF in a modular fashion that avoids unnecessary interactions between the modules of the design.
ADV_INT.2.2D
ADV_INT.2.3D
ADV_INT.2.4D
ADV_INT.2.1C
ADV_INT.2.2C
ADV_INT.2.3C
ADV_INT.2.4C
ADV_INT.2.5C
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:
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.
Page 112 of 208 Version 2.1
August 1999

TSF internals (ADV_INT) 10 - Class ADV: Development
ADV_INT.2.6C
ADV_INT.2.1E
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:
The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
ADV_INT.2.2E
The evaluator shall determine that both the low-level design and the implementation representation are in compliance with the architectural description.
ADV_INT.3 Minimisation of complexity
Application notes
348
ADV_INT.3.1D
ADV_INT.3.2D
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:
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.
ADV_INT.3.3D
ADV_INT.3.4D
ADV_INT.3.5D
ADV_INT.3.6D
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.
August 1999 Version 2.1
Page 113 of 208

10 - Class ADV: Development TSF internals (ADV_INT)
ADV_INT.3.1C
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
ADV_INT.3.2E
ADV_INT.3.3E
Content and presentation of evidence elements:
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:
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.
Page 114 of 208 Version 2.1
August 1999

Low-level design (ADV_LLD) 10 - Class ADV: Development
352
353
ADV_LLD
349
350
351
354
355
356
Low-level design
Objectives
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
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
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.
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
ADV_LLD.1.1D
Developer action elements:
The developer shall provide the low-level design of the TSF.
ADV_LLD.1.1C
ADV_LLD.1.2C
ADV_LLD.1.3C
Content and presentation of evidence elements:
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.
ADV_LLD.1.4C
ADV_LLD.1.5C
ADV_LLD.1.6C
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.
ADV_LLD.1.7C
ADV_LLD.1.8C
ADV_LLD.1.1E
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.
ADV_LLD.1.9C
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.
ADV_LLD.1.10C
The low-level design shall describe the separation of the TOE into TSPenforcing and other modules.
Evaluator action elements:
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
ADV_LLD.2.1D
Developer action elements:
The developer shall provide the low-level design of the TSF.
ADV_LLD.2.1C
ADV_LLD.2.2C
ADV_LLD.2.3C
Content and presentation of evidence elements:
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.
ADV_LLD.2.4C
ADV_LLD.2.5C
ADV_LLD.2.6C
ADV_LLD.2.7C
ADV_LLD.2.8C
ADV_LLD.2.9C
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.
ADV_LLD.2.10C
The low-level design shall describe the separation of the TOE into TSP-enforcing and other modules.
Evaluator action elements:
ADV_LLD.2.1E
ADV_LLD.2.2E
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.
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.
ADV_LLD.3.6C
ADV_LLD.3.7C
ADV_LLD.3.1E
ADV_LLD.3.2E
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.
ADV_LLD.3.8C
The low-level design shall identify which of the interfaces to the modules of the
TSF are externally visible.
ADV_LLD.3.9C
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.
ADV_LLD.3.10C
The low-level design shall describe the separation of the TOE into TSP-enforcing and other modules.
Evaluator action elements:
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.
Page 118 of 208 Version 2.1
August 1999

Representation correspondence (ADV_RCR) 10 - Class ADV: Development
ADV_RCR
358
359
360
361
362
363
Representation correspondence
Objectives
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
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
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
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
ADV_RCR.1.1C
The developer shall provide an analysis of correspondence between all adjacent pairs of TSF representations that are provided.
Content and presentation of evidence elements:
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.
ADV_RCR.2.1D
ADV_RCR.2.1C
ADV_RCR.2.2C
Developer action elements:
The developer shall provide an analysis of correspondence between all adjacent pairs of TSF representations that are provided.
Content and presentation of evidence elements:
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.
Page 120 of 208 Version 2.1
August 1999

Representation correspondence (ADV_RCR) 10 - Class ADV: Development
ADV_RCR.2.1E
Evaluator action elements:
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.
ADV_RCR.3.1D
Developer action elements:
The developer shall provide an analysis of correspondence between all adjacent pairs of TSF representations that are provided.
ADV_RCR.3.2D
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.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.
ADV_RCR.3.2C
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.
ADV_RCR.3.3C
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.1E
The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
ADV_RCR.3.2E
The evaluator shall determine the accuracy of the proofs of correspondence by selectively verifying the formal analysis.
August 1999 Version 2.1
Page 121 of 208

10 - Class ADV: Development Security policy modeling (ADV_SPM)
ADV_SPM
365
Security policy modeling
Objectives
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
367
368
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
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”.
369
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.
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
ADV_SPM.1.1D
Developer action elements:
The developer shall provide a TSP model.
ADV_SPM.1.2D
The developer shall demonstrate correspondence between the functional specification and the TSP model.
Content and presentation of evidence elements:
ADV_SPM.1.1C
The TSP model shall be informal.
ADV_SPM.1.2C
The TSP model shall describe the rules and characteristics of all policies of the
TSP that can be modeled.
ADV_SPM.1.3C
The TSP model shall include a rationale that demonstrates that it is consistent and complete with respect to all policies of the TSP that can be modeled.
ADV_SPM.1.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.
Evaluator action elements:
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
ADV_SPM.2.1D
Developer action elements:
The developer shall provide a TSP model.
ADV_SPM.2.2D
The developer shall demonstrate correspondence between the functional specification and the TSP model.
Content and presentation of evidence elements:
ADV_SPM.2.1C
The TSP model shall be semiformal.
ADV_SPM.2.2C
The TSP model shall describe the rules and characteristics of all policies of the TSP that can be modeled.
ADV_SPM.2.3C
The TSP model shall include a rationale that demonstrates that it is consistent and complete with respect to all policies of the TSP that can be modeled.
August 1999 Version 2.1
Page 123 of 208

10 - Class ADV: Development Security policy modeling (ADV_SPM)
ADV_SPM.2.4C
ADV_SPM.2.5C
ADV_SPM.3.1D
ADV_SPM.3.2D
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.
ADV_SPM.2.1E
Evaluator action elements:
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:
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
ADV_SPM.3.3C
ADV_SPM.3.4C
ADV_SPM.3.5C
ADV_SPM.3.6C
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.
Page 124 of 208 Version 2.1
August 1999

Security policy modeling (ADV_SPM) 10 - Class ADV: Development
ADV_SPM.3.1E
Evaluator action elements:
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

370
371
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.
Class AGD: Guidance documents
AGD_ADM Administrator guidance 1
AGD_USR User guidance 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
AGD_ADM
372
Administrator guidance
Objectives
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
374
This family contains only one component.
Application notes
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.
375
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.
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.
AGD_ADM.1.2C
The administrator guidance shall describe how to administer the TOE in a secure manner.
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.
AGD_ADM.1.4C
The administrator guidance shall describe all assumptions regarding user behaviour that are relevant to secure operation of the TOE.
AGD_ADM.1.5C
The administrator guidance shall describe all security parameters under the control of the administrator, indicating secure values as appropriate.
AGD_ADM.1.6C
The administrator guidance shall describe each type of security-relevant event relative to the administrative functions that need to be performed, including changing the security characteristics of entities under the control of the TSF.
AGD_ADM.1.7C
The administrator guidance shall be consistent with all other documentation supplied for evaluation.
AGD_ADM.1.8C
The administrator guidance shall describe all security requirements for the IT environment that are relevant to the administrator.
Evaluator action elements:
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
AGD_USR
376
377
User guidance
Objectives
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.
378
379
Component levelling
This family contains only one component.
Application notes
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.
380
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.
AGD_USR.1 User guidance
AGD_USR.1.1D
Dependencies:
ADV_FSP.1 Informal functional specification
Developer action elements:
The developer shall provide user guidance.
Content and presentation of evidence elements:
AGD_USR.1.1C
AGD_USR.1.2C
AGD_USR.1.3C
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.
Page 130 of 208 Version 2.1
August 1999

Part 3: Security assurance requirements 11 - Class AGD: Guidance documents
AGD_USR.1.4C
AGD_USR.1.5C
AGD_USR.1.6C
AGD_USR.1.1E
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:
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

381
382
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.
Class ALC: Life cycle support
ALC_DVS Development security
ALC_FLR Flaw remediation
ALC_LCD Life cycle definition
1
1
1
2
2
2
3
3
ALC_TAT Tools and techniques 1 2
Figure 12.1 -Life-cycle support class decomposition
3
August 1999 Version 2.1
Page 133 of 208

12 - Class ALC: Life cycle support Development security (ALC_DVS)
ALC_DVS
383
Development security
Objectives
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
385
386
The components in this family are levelled on the basis of whether justification of the sufficiency of the security measures is required.
Application notes
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.
387
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.
ALC_DVS.1 Identification of security measures
Dependencies:
No dependencies.
ALC_DVS.1.1D
ALC_DVS.1.1C
ALC_DVS.1.2C
Developer action elements:
The developer shall produce development security documentation.
Content and presentation of evidence elements:
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.
Page 134 of 208 Version 2.1
August 1999

Development security (ALC_DVS) 12 - Class ALC: Life cycle support
ALC_DVS.1.1E
ALC_DVS.2.1D
Evaluator action elements:
The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
ALC_DVS.1.2E
The evaluator shall confirm that the security measures are being applied.
ALC_DVS.2 Sufficiency of security measures
Dependencies:
No dependencies.
Developer action elements:
The developer shall produce development security documentation.
Content and presentation of evidence elements:
ALC_DVS.2.1C
ALC_DVS.2.2C
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.2.3C
ALC_DVS.2.1E
ALC_DVS.2.2E
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:
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.
August 1999 Version 2.1
Page 135 of 208

12 - Class ALC: Life cycle support Flaw remediation (ALC_FLR)
ALC_FLR
388
Flaw remediation
Objectives
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
390
391
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
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.
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
ALC_FLR.1.2C
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.
Page 136 of 208 Version 2.1
August 1999

Flaw remediation (ALC_FLR) 12 - Class ALC: Life cycle support
ALC_FLR.1.3C
ALC_FLR.1.4C
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.1E
The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
ALC_FLR.2 Flaw reporting procedures
ALC_FLR.2.1D
Dependencies:
No dependencies.
Developer action elements:
The developer shall document the flaw remediation procedures.
ALC_FLR.2.2D
ALC_FLR.2.1C
ALC_FLR.2.2C
ALC_FLR.2.3C
ALC_FLR.2.4C
ALC_FLR.2.5C
ALC_FLR.2.6C
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:
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.
August 1999 Version 2.1
Page 137 of 208

12 - Class ALC: Life cycle support Flaw remediation (ALC_FLR)
ALC_FLR.2.1E
Evaluator action elements:
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
ALC_FLR.3.3D
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.1C
ALC_FLR.3.2C
ALC_FLR.3.3C
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.
ALC_FLR.3.4C
ALC_FLR.3.5C
ALC_FLR.3.6C
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.3.7C
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.
Page 138 of 208 Version 2.1
August 1999

Flaw remediation (ALC_FLR) 12 - Class ALC: Life cycle support
ALC_FLR.3.1E
Evaluator action elements:
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)
397
398
399
ALC_LCD
392
393
394
395
396
Life cycle definition
Objectives
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
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
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.
Page 140 of 208 Version 2.1
August 1999

Life cycle definition(ALC_LCD) 12 - Class ALC: Life cycle support
ALC_LCD.1.1D
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:
The developer shall establish a life-cycle model to be used in the development and maintenance of the TOE.
ALC_LCD.1.2D
ALC_LCD.1.1C
The developer shall provide life-cycle definition documentation.
Content and presentation of evidence elements:
The life-cycle definition documentation shall describe the model used to develop and maintain the TOE.
ALC_LCD.1.2C
The life-cycle model shall provide for the necessary control over the development and maintenance of the TOE.
ALC_LCD.1.1E
Evaluator action elements:
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.
ALC_LCD.2.1D
Developer action elements:
The developer shall establish a life-cycle model to be used in the development and maintenance of the TOE.
ALC_LCD.2.2D
ALC_LCD.2.3D
ALC_LCD.2.1C
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:
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
ALC_LCD.2.3C
ALC_LCD.2.4C
ALC_LCD.2.5C
ALC_LCD.2.1E
ALC_LCD.3.1C
ALC_LCD.3.2C
ALC_LCD.3.3C
ALC_LCD.3.4C
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:
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.
ALC_LCD.3.2D
ALC_LCD.3.3D
ALC_LCD.3.4D
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:
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.
Page 142 of 208 Version 2.1
August 1999

Life cycle definition(ALC_LCD) 12 - Class ALC: Life cycle support
ALC_LCD.3.5C
ALC_LCD.3.6C
ALC_LCD.3.1E
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:
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)
ALC_TAT
400
Tools and techniques
Objectives
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
402
ALC_TAT.1.1D
ALC_TAT.1.2D
ALC_TAT.1.1C
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
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.
403
404
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.
ALC_TAT.1 Well-defined development tools
Dependencies:
ADV_IMP.1 Subset of the implementation of the TSF
Developer action elements:
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:
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
ALC_TAT.1.3C
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.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.
ALC_TAT.2.3D
ALC_TAT.2.1C
ALC_TAT.2.2C
The developer shall describe the implementation standards to be applied.
Content and presentation of evidence elements:
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.
ALC_TAT.2.3C
The documentation of the development tools shall unambiguously define the meaning of all implementation-dependent options.
Evaluator action elements:
ALC_TAT.2.1E
ALC_TAT.2.2E
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 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)
ALC_TAT.3.1D
ALC_TAT.3.2D
ALC_TAT.3.3D
ALC_TAT.3.1C
ALC_TAT.3.2C
ALC_TAT.3.3C
ALC_TAT.3.1E
ALC_TAT.3.2E
Developer action elements:
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:
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:
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.
Page 146 of 208 Version 2.1
August 1999

405
406
407
408
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.
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
1
1
1
2
2
2
3
3
ATE_IND Independent testing 1 2
Figure 13.1 -Tests class decomposition
3
Page 148 of 208 Version 2.1
August 1999

Coverage (ATE_COV) 13 - Class ATE: Tests
ATE_COV
410
Coverage
Objectives
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
413
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
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.
414 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:
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)
ATE_COV.1.1C
Content and presentation of evidence elements:
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
415
416
ATE_COV.2.1D
ATE_COV.2.1C
ATE_COV.2.2C
Objectives
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
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:
The developer shall provide an analysis of the test coverage.
Content and presentation of evidence elements:
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.
Page 150 of 208 Version 2.1
August 1999

Coverage (ATE_COV) 13 - Class ATE: Tests
ATE_COV.2.1E
Evaluator action elements:
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.
418
Application notes
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
ATE_COV.3.1D
Developer action elements:
The developer shall provide an analysis of the test coverage.
ATE_COV.3.1C
Content and presentation of evidence elements:
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.
ATE_COV.3.2C
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.3.3C
ATE_COV.3.1E
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:
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)
423
424
425
ATE_DPT
419
420
421
422
Page 152 of 208
Depth
Objectives
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
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
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.
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
ATE_DPT.1.1D
ATE_DPT.1.1C
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:
The developer shall provide the analysis of the depth of testing.
Content and presentation of evidence elements:
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
429
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.
August 1999 Version 2.1
Page 153 of 208

13 - Class ATE: Tests Depth (ATE_DPT)
430
431
ATE_DPT.2.1D
ATE_DPT.2.1C
Application notes
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:
The developer shall provide the analysis of the depth of testing.
Content and presentation of evidence elements:
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.
ATE_DPT.2.1E
Evaluator action elements:
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
433
434
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.
Page 154 of 208 Version 2.1
August 1999

Depth (ATE_DPT) 13 - Class ATE: Tests
435
436
437
ATE_DPT.3.1D
ATE_DPT.3.1C
ATE_DPT.3.1E
Application notes
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:
The developer shall provide the analysis of the depth of testing.
Content and presentation of evidence elements:
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:
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)
ATE_FUN
438
439
440
441
442
443
444
Functional tests
Objectives
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
This family contains two components, the higher requiring that ordering dependencies are analysed.
Application notes
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.
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
ATE_FUN.1.1C
The developer shall test the TSF and document the results.
The developer shall provide test documentation.
Content and presentation of evidence elements:
The test documentation shall consist of test plans, test procedure descriptions, expected test results and actual test results.
ATE_FUN.1.2C
ATE_FUN.1.3C
ATE_FUN.1.4C
ATE_FUN.1.5C
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.1E
446
The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
ATE_FUN.2 Ordered functional testing
Objectives
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
448
ATE_FUN.2.1D
ATE_FUN.2.2D
ATE_FUN.2.1C
ATE_FUN.2.2C
ATE_FUN.2.3C
ATE_FUN.2.4C
ATE_FUN.2.5C
ATE_FUN.2.6C
ATE_FUN.2.1E
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
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:
The developer shall test the TSF and document the results.
The developer shall provide test documentation.
Content and presentation of evidence elements:
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:
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
ATE_IND
449
450
451
452
453
454
Independent testing
Objectives
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
Levelling is based upon the amount of test documentation, test support and the amount of evaluator testing.
Application notes
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.
August 1999 Version 2.1
Page 159 of 208

13 - Class ATE: Tests Independent testing (ATE_IND)
455
456
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.
457
458
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.
459
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.
ATE_IND.1 Independent testing - conformance
Objectives
460
461
ATE_IND.1.1D
In this component, the objective is to demonstrate that the security functions perform as specified.
Application notes
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:
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
ATE_IND.1.1C
ATE_IND.1.1E
Content and presentation of evidence elements:
The TOE shall be suitable for testing.
Evaluator action elements:
The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
ATE_IND.1.2E
The evaluator shall test a subset of the TSF as appropriate to confirm that the
TOE operates as specified.
ATE_IND.2 Independent testing - sample
Objectives
462
463
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
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.
464
ATE_IND.2.1D
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:
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)
ATE_IND.2.1C
ATE_IND.2.2C
ATE_IND.2.1E
ATE_IND.2.2E
Content and presentation of evidence elements:
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:
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.2.3E
The evaluator shall execute a sample of tests in the test documentation to verify the developer test results.
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
467
ATE_IND.3.1D
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:
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
ATE_IND.3.1C
ATE_IND.3.2C
ATE_IND.3.1E
ATE_IND.3.2E
ATE_IND.3.3E
Content and presentation of evidence elements:
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:
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.
August 1999 Version 2.1
Page 163 of 208

468
469
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.
Class AVA: Vulnerability assessment
AVA_CCA Covert channel analysis
AVA_MSU Misuse
AVA_SOF Strength of TOE security functions
1
1
1
2
2
3
3
AVA_VLA Vulnerability analysis 1 2
Figure 14.1 -Vulnerability assessment class decomposition
3 4
August 1999 Version 2.1
Page 164 of 208

Covert channel analysis (AVA_CCA) 14 - Class AVA: Vulnerability assessment
AVA_CCA
470
Covert channel analysis
Objectives
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.
471
472
473
474
475
The assurance requirements address the threat that unintended and exploitable signalling paths exist that may be exercised to violate the SFP.
Component levelling
The components are levelled on increasing rigour of covert channel analysis.
Application notes
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.
476
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.
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)
AVA_CCA.1.1D
AVA_CCA.1.2D
AVA_CCA.1.1C
AVA_CCA.1.2C
AVA_CCA.1.3C
AVA_CCA.1.4C
AVA_CCA.1.5C
Developer action elements:
The developer shall conduct a search for covert channels for each information flow control policy.
The developer shall provide covert channel analysis documentation.
Content and presentation of evidence elements:
The analysis documentation shall identify covert channels and estimate their capacity.
The analysis documentation shall describe the procedures used for determining the existence of covert channels, and the information needed to carry out the covert channel analysis.
The analysis documentation shall describe all assumptions made during the covert channel analysis.
The analysis documentation shall describe the method used for estimating channel capacity, based on worst case scenarios.
The analysis documentation shall describe the worst case exploitation scenario for each identified covert channel.
Evaluator action elements:
AVA_CCA.1.1E
AVA_CCA.1.2E
AVA_CCA.1.3E
The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
The evaluator shall confirm that the results of the covert channel analysis show that the TOE meets its functional requirements.
The evaluator shall selectively validate the covert channel analysis through testing.
AVA_CCA.2 Systematic covert channel analysis
Objectives
478
The objective is to identify covert channels that are identifiable, through a systematic search for covert channels.
Application notes
479
Performing a covert channel analysis in a systematic way requires that the developer identify covert channels in a structured and repeatable way, as opposed to identifying covert channels in an ad-hoc fashion.
Page 166 of 208 Version 2.1
August 1999

Covert channel analysis (AVA_CCA) 14 - Class AVA: Vulnerability assessment
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
Developer action elements:
AVA_CCA.2.1D
The developer shall conduct a search for covert channels for each information flow control policy.
AVA_CCA.2.2D
The developer shall provide covert channel analysis documentation.
Content and presentation of evidence elements:
AVA_CCA.2.1C
The analysis documentation shall identify covert channels and estimate their capacity.
AVA_CCA.2.2C
The analysis documentation shall describe the procedures used for determining the existence of covert channels, and the information needed to carry out the covert channel analysis.
AVA_CCA.2.3C
The analysis documentation shall describe all assumptions made during the covert channel analysis.
AVA_CCA.2.4C
The analysis documentation shall describe the method used for estimating channel capacity, based on worst case scenarios.
AVA_CCA.2.5C
The analysis documentation shall describe the worst case exploitation scenario for each identified covert channel.
AVA_CCA.2.6C
The analysis documentation shall provide evidence that the method used to identify covert channels is systematic.
Evaluator action elements:
AVA_CCA.2.1E
The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
AVA_CCA.2.2E
The evaluator shall confirm that the results of the covert channel analysis show that the TOE meets its functional requirements.
AVA_CCA.2.3E
The evaluator shall selectively validate the covert channel analysis through testing.
August 1999 Version 2.1
Page 167 of 208

14 - Class AVA: Vulnerability assessment Covert channel analysis (AVA_CCA)
AVA_CCA.3 Exhaustive covert channel analysis
Objectives
480
The objective is to identify covert channels that are identifiable, through an exhaustive search for covert channels.
Application notes
481
Performing a covert channel analysis in an exhaustive way requires that additional evidence be provided that the plan that was followed for identifying covert channels is sufficient to ensure that all possible ways for covert channel exploration have been exercised.
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
AVA_CCA.3.1D
AVA_CCA.3.2D
Developer action elements:
The developer shall conduct a search for covert channels for each information flow control policy.
The developer shall provide covert channel analysis documentation.
Content and presentation of evidence elements:
AVA_CCA.3.1C
AVA_CCA.3.2C
AVA_CCA.3.3C
AVA_CCA.3.4C
AVA_CCA.3.5C
The analysis documentation shall identify covert channels and estimate their capacity.
The analysis documentation shall describe the procedures used for determining the existence of covert channels, and the information needed to carry out the covert channel analysis.
The analysis documentation shall describe all assumptions made during the covert channel analysis.
The analysis documentation shall describe the method used for estimating channel capacity, based on worst case scenarios.
The analysis documentation shall describe the worst case exploitation scenario for each identified covert channel.
AVA_CCA.3.6C
The analysis documentation shall provide evidence that the method used to identify covert channels is exhaustive.
Page 168 of 208 Version 2.1
August 1999

Covert channel analysis (AVA_CCA) 14 - Class AVA: Vulnerability assessment
AVA_CCA.3.1E
Evaluator action elements:
The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
AVA_CCA.3.2E
The evaluator shall confirm that the results of the covert channel analysis show that the TOE meets its functional requirements.
AVA_CCA.3.3E
The evaluator shall selectively validate the covert channel analysis through testing.
August 1999 Version 2.1
Page 169 of 208

14 - Class AVA: Vulnerability assessment Misuse (AVA_MSU)
486
487
489
490
AVA_MSU
482
483
484
485
488
Misuse
Objectives
Misuse investigates whether the TOE can be configured or used in a manner that is insecure but that an administrator or user of the TOE would reasonably believe to be secure.
The objectives are: a) to minimise the probability of configuring or installing the TOE in a way that is insecure, without the user or administrator being able to detect it; b) to minimise the risk of human or other errors in operation that may deactivate, disable, or fail to activate security functions, resulting in an undetected insecure state.
Component levelling
The components are levelled on the increasing evidence to be provided by the developer and the increasing rigour of analysis.
Application notes
Conflicting, misleading, incomplete or unreasonable guidance may result in a user of the TOE believing that the TOE is secure when it is not, and can result in vulnerabilities.
An example of conflicting guidance would be two guidance instructions that imply different outcomes when the same input is supplied.
An example of misleading guidance would be the description of a single guidance instruction that could be parsed in more than one way, one of which may result in an insecure state.
An example of incomplete guidance would be a list of significant physical security requirements that omitted an important item, resulting in this item being overlooked by the administrator who believed the list to be complete.
An example of unreasonable guidance would be a recommendation to follow a procedure that imposed an unduly onerous administrative burden.
Guidance documentation is required. This may be contained in existing User or
Administration documentation, or may be provided separately. If provided separately, the evaluator should confirm that the documentation is supplied with the
TOE.
Page 170 of 208 Version 2.1
August 1999

Misuse (AVA_MSU) 14 - Class AVA: Vulnerability assessment
AVA_MSU.1 Examination of guidance
Objectives
491
The objective is to ensure that misleading, unreasonable and conflicting guidance is absent from the guidance documentation, and that secure procedures for all modes of operation have been addressed. Insecure states should be easy to detect.
Dependencies:
ADO_IGS.1 Installation, generation, and start-up procedures
ADV_FSP.1 Informal functional specification
AGD_ADM.1 Administrator guidance
AGD_USR.1 User guidance
AVA_MSU.1.1D
Developer action elements:
The developer shall provide guidance documentation.
AVA_MSU.1.1C
Content and presentation of evidence elements:
The guidance documentation shall identify all possible modes of operation of the TOE (including operation following failure or operational error), their consequences and implications for maintaining secure operation.
AVA_MSU.1.2C
The guidance documentation shall be complete, clear, consistent and reasonable.
AVA_MSU.1.3C
The guidance documentation shall list all assumptions about the intended environment.
AVA_MSU.1.4C
The guidance documentation shall list all requirements for external security measures (including external procedural, physical and personnel controls).
AVA_MSU.1.1E
Evaluator action elements:
The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
AVA_MSU.1.2E
The evaluator shall repeat all configuration and installation procedures to confirm that the TOE can be configured and used securely using only the supplied guidance documentation.
AVA_MSU.1.3E
The evaluator shall determine that the use of the guidance documentation allows all insecure states to be detected.
August 1999 Version 2.1
Page 171 of 208

14 - Class AVA: Vulnerability assessment Misuse (AVA_MSU)
AVA_MSU.2 Validation of analysis
Objectives
492
The objective is to ensure that misleading, unreasonable and conflicting guidance is absent from the guidance documentation, and that secure procedures for all modes of operation have been addressed. Insecure states should be easy to detect.
In this component, an analysis of the guidance documentation by the developer is required to provide additional assurance that the objective has been met.
Dependencies:
ADO_IGS.1 Installation, generation, and start-up procedures
ADV_FSP.1 Informal functional specification
AGD_ADM.1 Administrator guidance
AGD_USR.1 User guidance
AVA_MSU.2.1D
Developer action elements:
The developer shall provide guidance documentation.
AVA_MSU.2.2D
The developer shall document an analysis of the guidance documentation.
AVA_MSU.2.1C
Content and presentation of evidence elements:
The guidance documentation shall identify all possible modes of operation of the
TOE (including operation following failure or operational error), their consequences and implications for maintaining secure operation.
AVA_MSU.2.2C
The guidance documentation shall be complete, clear, consistent and reasonable.
AVA_MSU.2.3C
The guidance documentation shall list all assumptions about the intended environment.
AVA_MSU.2.4C
The guidance documentation shall list all requirements for external security measures (including external procedural, physical and personnel controls).
AVA_MSU.2.5C
The analysis documentation shall demonstrate that the guidance documentation is complete.
AVA_MSU.2.1E
Evaluator action elements:
The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
AVA_MSU.2.2E
The evaluator shall repeat all configuration and installation procedures, and other
procedures selectively, to confirm that the TOE can be configured and used securely using only the supplied guidance documentation.
Page 172 of 208 Version 2.1
August 1999

Misuse (AVA_MSU) 14 - Class AVA: Vulnerability assessment
AVA_MSU.2.3E
The evaluator shall determine that the use of the guidance documentation allows all insecure states to be detected.
AVA_MSU.2.4E
The evaluator shall confirm that the analysis documentation shows that guidance is provided for secure operation in all modes of operation of the TOE.
AVA_MSU.3 Analysis and testing for insecure states
Objectives
493 The objective is to ensure that misleading, unreasonable and conflicting guidance is absent from the guidance documentation, and that secure procedures for all modes of operation have been addressed. Insecure states should be easy to detect.
In this component, an analysis of the guidance documentation by the developer is required to provide additional assurance that the objective has been met, and this analysis is validated and confirmed through testing by the evaluator.
494
Application notes
In this component the evaluator is required to undertake testing to ensure that if and when the TOE enters an insecure state this may easily be detected. This testing may be considered as a specific aspect of penetration testing.
Dependencies:
ADO_IGS.1 Installation, generation, and start-up procedures
ADV_FSP.1 Informal functional specification
AGD_ADM.1 Administrator guidance
AGD_USR.1 User guidance
Developer action elements:
AVA_MSU.3.1D
The developer shall provide guidance documentation.
AVA_MSU.3.2D
The developer shall document an analysis of the guidance documentation.
AVA_MSU.3.1C
Content and presentation of evidence elements:
The guidance documentation shall identify all\ possible modes of operation of the
TOE (including operation following failure or operational error), their consequences and implications for maintaining secure operation.
AVA_MSU.3.2C
The guidance documentation shall be complete, clear, consistent and reasonable.
AVA_MSU.3.3C
The guidance documentation shall list all assumptions about the intended environment.
AVA_MSU.3.4C
The guidance documentation shall list all requirements for external security measures (including external procedural, physical and personnel controls).
August 1999 Version 2.1
Page 173 of 208

14 - Class AVA: Vulnerability assessment Misuse (AVA_MSU)
AVA_MSU.3.5C
The analysis documentation shall demonstrate that the guidance documentation is complete.
Evaluator action elements:
AVA_MSU.3.1E
The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
AVA_MSU.3.2E
The evaluator shall repeat all configuration and installation procedures, and other procedures selectively, to confirm that the TOE can be configured and used securely using only the supplied guidance documentation.
AVA_MSU.3.3E
The evaluator shall determine that the use of the guidance documentation allows all insecure states to be detected.
AVA_MSU.3.4E
The evaluator shall confirm that the analysis documentation shows that guidance is provided for secure operation in all modes of operation of the TOE.
AVA_MSU.3.5E
The evaluator shall perform independent testing to determine that an administrator or user, with an understanding of the guidance documentation, would reasonably be able to determine if the TOE is configured and operating in a manner that is insecure.
Page 174 of 208 Version 2.1
August 1999

Strength of TOE security functions (AVA_SOF) 14 - Class AVA: Vulnerability
AVA_SOF
495
Strength of TOE security functions
Objectives
Even if a TOE security function cannot be bypassed, deactivated, or corrupted, it may still be possible to defeat it because there is a vulnerability in the concept of its underlying security mechanisms. For those functions a qualification of their security behaviour can be made using the results of a quantitative or statistical analysis of the security behaviour of these mechanisms and the effort required to overcome them. The qualification is made in the form of a strength of TOE security function claim.
496
Component levelling
There is only one component in this family.
Application notes
497
498
Security functions are implemented by security mechanisms. For example, a password mechanism can be used in the implementation of the identification and authentication security function.
The strength of TOE security function evaluation is performed at the level of the security mechanism, but its results provide knowledge about the ability of the related security function to counter the identified threats.
499
The strength of TOE security function analysis should consider at least the contents of all the TOE deliverables, including the ST, for the targeted evaluation assurance level.
AVA_SOF.1 Strength of TOE security function evaluation
AVA_SOF.1.1D
AVA_SOF.1.1C
Dependencies:
ADV_FSP.1 Informal functional specification
ADV_HLD.1 Descriptive high-level design
Developer action elements:
The developer shall perform a strength of TOE security function analysis for each mechanism identified in the ST as having a strength of TOE security function claim.
Content and presentation of evidence elements:
For each mechanism with a strength of TOE security function claim the strength of TOE security function analysis shall show that it meets or exceeds the minimum strength level defined in the PP/ST.
August 1999 Version 2.1
Page 175 of 208

14 - Class AVA: Vulnerability assessment Strength of TOE security functions
AVA_SOF.1.2C
AVA_SOF.1.1E
AVA_SOF.1.2E
For each mechanism with a specific strength of TOE security function claim the strength of TOE security function analysis shall show that it meets or exceeds the specific strength of function metric defined in the PP/ST.
Evaluator action elements:
The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
The evaluator shall confirm that the strength claims are correct.
Page 176 of 208 Version 2.1
August 1999

Vulnerability analysis (AVA_VLA) 14 - Class AVA: Vulnerability assessment
AVA_VLA
500
501
502
503
504
505
506
507
Vulnerability analysis
Objectives
Vulnerability analysis is an assessment to determine whether vulnerabilities identified, during the evaluation of the construction and anticipated operation of the
TOE or by other methods (e.g. by flaw hypotheses), could allow users to violate the
TSP.
Vulnerability analysis deals with the threats that a user will be able to discover flaws that will allow unauthorised access to resources (e.g. data), allow the ability to interfere with or alter the TSF, or interfere with the authorised capabilities of other users.
Component levelling
Levelling is based on an increasing rigour of vulnerability analysis by the developer and the evaluator.
Application notes
A vulnerability analysis is performed by the developer in order to ascertain the presence of security vulnerabilities, and should consider at least the contents of all the TOE deliverables including the ST for the targeted evaluation assurance level.
The developer is required to document the disposition of identified vulnerabilities to allow the evaluator to make use of that information if it is found useful as a support for the evaluator's independent vulnerability analysis.
The intent of the developer analysis is to confirm that no identified security vulnerabilities can be exploited in the intended environment for the TOE and that the TOE is resistant to obvious penetration attacks.
Obvious vulnerabilities are considered to be those that are open to exploitation that requires a minimum of understanding of the TOE, skill, technical sophistication, and resources. These might be suggested by the TSF interface description. Obvious vulnerabilities include those in the public domain, details of which should be known to a developer or available from an evaluation authority.
Performing a search for vulnerabilities in a systematic way requires that the developer identify those vulnerabilities in a structured and repeatable way, as opposed to identifying them in an ad-hoc fashion. The associated evidence that the search for vulnerabilities was systematic should include identification of all TOE documentation upon which the search for flaws was based.
Independent vulnerability analysis goes beyond the vulnerabilities identified by the developer. The main intent of the evaluator analysis is to determine that the TOE is resistant to penetration attacks performed by an attacker possessing a low (for
AVA_VLA.2), moderate (for AVA_VLA.3) or high (for AVA_VLA.4) attack potential. To accomplish this intent, the evaluator first assesses the exploitability of
August 1999 Version 2.1
Page 177 of 208

14 - Class AVA: Vulnerability assessment Vulnerability analysis (AVA_VLA) all identified vulnerabilities. This is accomplished by conducting penetration testing. The evaluator should assume the role of an attacker with a low (for
AVA_VLA.2), moderate (for AVA_VLA.3) or high (for AVA_VLA.4) attack potential when attempting to penetrate the TOE. Any exploitation of vulnerabilities by such an attacker should be considered by the evaluator to be “obvious penetration attacks” (with respect to the AVA_VLA.*.2C elements) in the context of the components AVA_VLA.2 through AVA_VLA.4.
AVA_VLA.1 Developer vulnerability analysis
Objectives
508
509
A vulnerability analysis is performed by the developer to ascertain the presence of obvious security vulnerabilities, and to confirm that they cannot be exploited in the intended environment for the TOE.
Application notes
The evaluator should consider performing additional tests as a result of potential exploitable vulnerabilities identified during other parts of the evaluation.
AVA_VLA.1.1D
AVA_VLA.1.2D
AVA_VLA.1.1C
AVA_VLA.1.1E
AVA_VLA.1.2E
Dependencies:
ADV_FSP.1 Informal functional specification
ADV_HLD.1 Descriptive high-level design
AGD_ADM.1 Administrator guidance
AGD_USR.1 User guidance
Developer action elements:
The developer shall perform and document an analysis of the TOE deliverables searching for obvious ways in which a user can violate the TSP.
The developer shall document the disposition of obvious vulnerabilities.
Content and presentation of evidence elements:
The documentation shall show, for all identified vulnerabilities, that the vulnerability cannot be exploited in the intended environment for the TOE.
Evaluator action elements:
The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
The evaluator shall conduct penetration testing, building on the developer vulnerability analysis, to ensure obvious vulnerabilities have been addressed.
Page 178 of 208 Version 2.1
August 1999

Vulnerability analysis (AVA_VLA) 14 - Class AVA: Vulnerability assessment
AVA_VLA.2 Independent vulnerability analysis
Objectives
510
A vulnerability analysis is performed by the developer to ascertain the presence of security vulnerabilities, and to confirm that they cannot be exploited in the intended environment for the TOE.
511 The evaluator performs independent penetration testing, supported by the evaluator’s independent vulnerability analysis, to determine that the TOE is resistant to penetration attacks performed by attackers possessing a low attack potential.
Dependencies:
ADV_FSP.1 Informal functional specification
ADV_HLD.2 Security enforcing high-level design
ADV_IMP.1 Subset of the implementation of the TSF
ADV_LLD.1 Descriptive low-level design
AGD_ADM.1 Administrator guidance
AGD_USR.1 User guidance
AVA_VLA.2.1D
Developer action elements:
The developer shall perform and document an analysis of the TOE deliverables searching for ways in which a user can violate the TSP.
AVA_VLA.2.2D
The developer shall document the disposition of identified vulnerabilities.
Content and presentation of evidence elements:
AVA_VLA.2.1C
The documentation shall show, for all identified vulnerabilities, that the vulnerability cannot be exploited in the intended environment for the TOE.
AVA_VLA.2.2C
AVA_VLA.2.1E
The documentation shall justify that the TOE, with the identified vulnerabilities, is resistant to obvious penetration attacks.
Evaluator action elements:
The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
AVA_VLA.2.2E
AVA_VLA.2.3E
The evaluator shall conduct penetration testing, building on the developer vulnerability analysis, to ensure the identified vulnerabilities have been addressed.
The evaluator shall perform an independent vulnerability analysis.
August 1999 Version 2.1
Page 179 of 208

14 - Class AVA: Vulnerability assessment Vulnerability analysis (AVA_VLA)
AVA_VLA.2.4E
The evaluator shall perform independent penetration testing, based on the independent vulnerability analysis, to determine the exploitability of additional identified vulnerabilities in the intended environment.
AVA_VLA.2.5E
The evaluator shall determine that the TOE is resistant to penetration attacks performed by an attacker possessing a low attack potential.
AVA_VLA.3 Moderately resistant
Objectives
512
513
AVA_VLA.3.1D
A vulnerability analysis is performed by the developer to ascertain the presence of security vulnerabilities, and to confirm that they cannot be exploited in the intended environment for the TOE.
The evaluator performs independent penetration testing, supported by the evaluator’s independent vulnerability analysis, to determine that the TOE is resistant to penetration attacks performed by attackers possessing a moderate attack potential.
Dependencies:
ADV_FSP.1 Informal functional specification
ADV_HLD.2 Security enforcing high-level design
ADV_IMP.1 Subset of the implementation of the TSF
ADV_LLD.1 Descriptive low-level design
AGD_ADM.1 Administrator guidance
AGD_USR.1 User guidance
Developer action elements:
The developer shall perform and document an analysis of the TOE deliverables searching for ways in which a user can violate the TSP.
AVA_VLA.3.2D
AVA_VLA.3.1C
AVA_VLA.3.2C
AVA_VLA.3.3C
The developer shall document the disposition of identified vulnerabilities.
Content and presentation of evidence elements:
The documentation shall show, for all identified vulnerabilities, that the vulnerability cannot be exploited in the intended environment for the TOE.
The documentation shall justify that the TOE, with the identified vulnerabilities, is resistant to obvious penetration attacks.
The evidence shall show that the search for vulnerabilities is systematic.
Page 180 of 208 Version 2.1
August 1999

Vulnerability analysis (AVA_VLA) 14 - Class AVA: Vulnerability assessment
AVA_VLA.3.1E
AVA_VLA.3.2E
Evaluator action elements:
The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
The evaluator shall conduct penetration testing, building on the developer vulnerability analysis, to ensure the identified vulnerabilities have been addressed.
AVA_VLA.3.3E
AVA_VLA.3.4E
AVA_VLA.3.5E
The evaluator shall perform an independent vulnerability analysis.
The evaluator shall perform independent penetration testing, based on the independent vulnerability analysis, to determine the exploitability of additional identified vulnerabilities in the intended environment.
The evaluator shall determine that the TOE is resistant to penetration attacks performed by an attacker possessing a moderate attack potential.
AVA_VLA.4 Highly resistant
Objectives
514
A vulnerability analysis is performed by the developer to ascertain the presence of security vulnerabilities, and to confirm that they cannot be exploited in the intended environment for the TOE.
515 The evaluator performs independent penetration testing, supported by the evaluator’s independent vulnerability analysis, to determine that the TOE is resistant to penetration attacks performed by attackers possessing a high attack potential.
Dependencies:
ADV_FSP.1 Informal functional specification
ADV_HLD.2 Security enforcing high-level design
ADV_IMP.1 Subset of the implementation of the TSF
ADV_LLD.1 Descriptive low-level design
AGD_ADM.1 Administrator guidance
AGD_USR.1 User guidance
Developer action elements:
AVA_VLA.4.1D
The developer shall perform and document an analysis of the TOE deliverables searching for ways in which a user can violate the TSP.
AVA_VLA.4.2D
The developer shall document the disposition of identified vulnerabilities.
August 1999 Version 2.1
Page 181 of 208

14 - Class AVA: Vulnerability assessment Vulnerability analysis (AVA_VLA)
AVA_VLA.4.1C
AVA_VLA.4.2C
Content and presentation of evidence elements:
The documentation shall show, for all identified vulnerabilities, that the vulnerability cannot be exploited in the intended environment for the TOE.
The documentation shall justify that the TOE, with the identified vulnerabilities, is resistant to obvious penetration attacks.
AVA_VLA.4.3C
AVA_VLA.4.4C
AVA_VLA.4.1E
AVA_VLA.4.2E
AVA_VLA.4.3E
AVA_VLA.4.4E
AVA_VLA.4.5E
The evidence shall show that the search for vulnerabilities is systematic.
The analysis documentation shall provide a justification that the analysis completely addresses the TOE deliverables.
Evaluator action elements:
The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
The evaluator shall conduct penetration testing, building on the developer vulnerability analysis, to ensure the identified vulnerabilities have been addressed.
The evaluator shall perform an independent vulnerability analysis.
The evaluator shall perform independent penetration testing, based on the independent vulnerability analysis, to determine the exploitability of additional identified vulnerabilities in the intended environment.
The evaluator shall determine that the TOE is resistant to penetration attacks performed by an attacker possessing a high attack potential.
Page 182 of 208 Version 2.1
August 1999

Introduction
516
517
518
519
520
521
This clause provides the discourse on an assurance maintenance paradigm that is supported by the Maintenance of assurance class (AMA). As such it provides helpful information to understand one possible approach to applying the AMA requirements.
Maintenance of assurance is a concept intended to be applied after a TOE has been evaluated and certified against the criteria in clauses 4-5 and 8-14. The maintenance of assurance requirements are aimed at assuring that the TOE will continue to meet its security target as changes are made to the TOE or its environment. Such changes include the discovery of new threats or vulnerabilities, changes in user requirements, the correction of bugs found in the certified TOE, and other updates to the functionality provided.
One way to determine that assurance has been maintained is by a re-evaluation of the TOE. The term ‘re-evaluation’ here refers to an evaluation of a new version of the TOE that addresses all security relevant changes made to the certified version of the TOE and re-uses previous evaluation results where these are still valid.
However, in many cases it is unlikely to be practical to perform a re-evaluation of every new version of the TOE in order to ensure that assurance continues to be maintained.
The main goal of class AMA is therefore to define a set of requirements which can be applied to provide confidence that the assurance established in a TOE is being maintained, without always requiring a formal re-evaluation of new versions of the
TOE. Class AMA does not remove entirely the need for re-evaluation. In some cases, changes may be so significant that only a re-evaluation can be relied upon to ensure that assurance has been maintained. The requirements of this class thus have a secondary goal of supporting cost-effective re-evaluation of a TOE when this is necessary.
It should be noted that it is possible to re-evaluate any new version of a TOE against the criteria in clauses 4-5 and 8-14 without any of the AMA requirements having been satisfied. However, class AMA includes requirements which can be used in support of any such re-evaluation.
Maintenance developer and evaluator actions are intended to be applied after the
TOE has been evaluated and certified although, as described below, some requirements can be applied at the time of the evaluation. For clarity, the following terms are used in this paradigm description: a) the certified version of the TOE refers to the version that has been evaluated and certified;
August 1999 Version 2.1
Page 183 of 208

15 - Assurance maintenance paradigm Assurance maintenance cycle
522
523
524
525
526 b)
-
the current version of the TOE refers to a version that differs in some respect from the certified version; this could be, for example: a new release of the TOE the certified version with patches applied to correct subsequently discovered bugs
the same basic version of the TOE, but on a different hardware or software platform.
The developer and evaluator roles in this class are as described in CC Part 1.
However, it is not necessarily the case that the evaluator referred to in the requirements of this class will be the same as that which evaluated the certified version of the TOE.
In order to allow assurance to be maintained in a TOE without always requiring a formal re-evaluation, the requirements in this class place an obligation on the developer to maintain evidence that shows that the TOE continues to satisfy its security target (e.g. evidence of developer testing).
This subclause describes one possible approach to the use of the assurance maintenance families and components, intended to illustrate use of the concepts.
The example is modeled on an ‘assurance maintenance cycle’ that may be divided into the following three phases: a) the acceptance phase, at the start of a cycle, in which the developer’s plans and procedures for assurance maintenance during the cycle are established by the developer and independently validated by an evaluator; b) c) the monitoring phase, in which the developer provides at one or more points during the cycle evidence that the assurance in the TOE is being maintained in accordance with the established plans and procedures, this evidence of assurance maintenance being independently checked by an evaluator; the re-evaluation phase, completing the cycle, in which an updated version of the TOE is submitted for a re-evaluation based on the changes affecting the TOE since the certified version.
The families within AMA address primarily the first two of these phases, while providing support for the third. These phases are introduced here simply to help describe the application of the assurance maintenance requirements. There is no intention to mandate an assurance maintenance scheme which formally incorporates these phases.
The assurance maintenance cycle is illustrated in Figure 15.1 below.
Page 184 of 208 Version 2.1
August 1999

Assurance maintenance cycle 15 - Assurance maintenance paradigm
527
528
TOE
Evaluation
In this example, a TOE can enter the monitoring phase only when the acceptance phase has been successfully concluded (i.e. the developer’s plans and procedures for assurance maintenance have been accepted). If the developer makes changes to these plans or procedures during the monitoring phase then the TOE will need to reenter the acceptance phase to get the changes accepted.
During the monitoring phase the developer follows the assurance maintenance plans and procedures, conducting an analysis of the security impact of changes affecting the TOE (security impact analysis). At certain points during this phase, an evaluator independently checks (by means of an audit) the developer’s work. The developer is required to ensure that the plans and procedures are followed, and that security impact analysis is performed correctly.
TOE
Acceptance
TOE
Monitoring
TOE
Re-evaluation
529
530
Figure 15.1 - Example assurance maintenance cycle
Therefore, once a TOE is in the monitoring phase, it becomes possible to have confidence that the assurance in the TOE has been maintained for new versions of the TOE produced by the developer.
A TOE that is subject to change would not continue in the monitoring phase for an indefinite period: at some point a re-evaluation of the TOE would be necessary. The decision as to when a re-evaluation would be required is dependent on cumulative changes to the TOE as well as especially significant changes. For example, a large number of minor changes could have an impact on assurance equivalent to that of a major change. The developer’s assurance maintenance plan defines the scope of the changes that may be made to the TOE during the monitoring phase (see subclause 15.3.1 below).
August 1999 Version 2.1
Page 185 of 208

15 - Assurance maintenance paradigm Assurance maintenance cycle
531
532
15.2.1
533
In a similar way, it would not possible to ‘uprate’ a TOE (i.e. increase the assurance level) during the monitoring phase: this could only be achieved by means of an evaluation of the TOE (making appropriate reuse of previous evaluation results).
The assurance maintenance status of the TOE will have to be reviewed if it is discovered that the assurance maintenance procedures are not being followed, and that as a result assurance in the TOE is undermined. In some cases the developer may be required to submit the TOE for re-evaluation, and afterwards start a new assurance maintenance cycle.
TOE acceptance
In the example, the TOE acceptance phase of the assurance maintenance cycle can be refined into the following, which uses the assurance maintenance plan and TOE component categorisation report families from the AMA class.
Develop
Assurance
Maintenance
Plan
Develop TOE
Component
Categorisation
Report
Assurance
Maintenance
Plan
TOE
Component
Categorisation
Report
Accept
TOE into
Maintenance
Figure 15.2 - Example TOE acceptance approach
Accepted
Assurance
Maintenance
Plan
Page 186 of 208 Version 2.1
August 1999

Assurance maintenance cycle 15 - Assurance maintenance paradigm
15.2.2
534
TOE monitoring
The TOE monitoring phase of the assurance maintenance cycle would be refined into the following, which uses the Evidence of assurance maintenance and Security impact analysis families of the AMA Class.
Accepted
Assurance
Maintenance
Plan
TOE
Component
Categorisation
Report
Develop
Evidence of
Maintenance
Perform
Security
Impact
Analysis
535
(pass audit)
Conduct
Assurance
Maintenance
Audit
(fail audit)
Continue in TOE
Maintenance
Evidence of
Assurance
Maintenance
Reapply for TOE
Maintenance
Figure 15.3 - Example TOE monitoring approach
The third phase of this example maintenance cycle is the re-evaluation phase, in which the evaluator makes use of the impact analysis and evidence of assurance maintenance to re-examine parts of the TOE, using the assurance components applicable for the target assurance level.
August 1999 Version 2.1
Page 187 of 208

15 - Assurance maintenance paradigm Assurance maintenance class and families
536
Re-evaluation activities would be scheduled in the AM Plan, or could be required in response to unforseen significant changes to the TOE or its environment for which assurance maintenance activities were considered inappropriate.
537
To support assurance maintenance approaches the class AMA has been developed, and comprises four families as shown in Table 15.1
Table 15.1 - Maintenance of assurance family breakdown and mapping
Assurance Class Assurance Family
Assurance maintenance plan
Class AMA: Maintenance of assurance
TOE component categorisation report
Evidence of assurance maintenance
Security impact analysis
Abbreviated Name
AMA_AMP
AMA_CAT
AMA_EVD
AMA_SIA
15.3.1
538
539
540
541
Assurance maintenance plan
The AM Plan provides a clear identification of the baseline for assurance maintenance, in terms of the evaluation results and the definition of the categorisation of TOE components.
The Assurance Maintenance Plan (AM Plan) identifies the plans and procedures a developer implements in order to ensure that the assurance that was established in the certified TOE is maintained as changes are made to the TOE or its environment.
An AM Plan covers one assurance maintenance cycle.
The AM Plan defines the scope of changes that can be made to the TOE without triggering a re-evaluation. The specific approach to be followed is scheme dependent, but the following types of change are likely to be outside the scope of the AM Plan and thus might only be addressed by means of a re-evaluation: a) significant changes to the security target (i.e. significant changes to the security environment, security objectives or security functional requirements, or any increase in the assurance requirements); b) c) significant changes to external TSF interfaces categorised as TSPenforcing;
(where the assurance requirements include ADV_HLD.1 or higher components) significant changes to TSF subsystems categorised as TSPenforcing.
It should be noted that the approach to changes made under maintenance may be influenced by any functions provided by the TOE that help support automated
Page 188 of 208 Version 2.1
August 1999

542
543
Assurance maintenance class and families
544
545
15 - Assurance maintenance paradigm validation of the security of the evaluated configuration. Such functions may prevent inappropriate or damaging changes being applied to an operational TOE.
A more precise specification of the rules is outside the scope of the CC, not least because the definition of what constitutes a significant change will be dependent on the type of TOE evaluated, and on the content of the security target.
The AM Plan is required to define or reference the procedures that will be applied to ensure that assurance in the TOE is maintained during the assurance maintenance cycle. Four types of procedure are identified that should be applied: a) configuration management procedures, controlling and recording changes to the TOE in support of the developer’s security impact analysis, as well as supporting documentation (including the AM Plan itself); b) c) d) procedures to maintain ‘assurance evidence’ (i.e. the maintenance of documentary evidence as required by the appropriate assurance requirements), a key aspect of which is functional testing of the security functions of the TOE, and the developer’s regression testing policy in particular; procedures governing the security impact analysis of changes affecting the
TOE (Note that this includes changes within the TOE environment, such as new threats or attack methods that may need to be identified and tracked), and the maintenance of the TOE component categorisation report as changes are made; flaw remediation procedures, covering the tracking and correction of reported security flaws (as required by ALC_FLR.1).
The AM Plan is expected to remain valid until completion of the assurance maintenance cycle (i.e. completion of the scheduled re-evaluation), after which a new AM Plan will be required. The AM Plan is expected to be invalidated if the developer does not follow the plan, or makes changes to the TOE that are outside the scope of the plan, or has to make such changes in order for the TOE to remain effective within its environment. An updated AM Plan should be re-submitted and accepted before a TOE enters a new monitoring phase.
The AM Plan requires the developer to identify a developer security analyst whose responsibility is to monitor the assurance maintenance process. The role may be filled by more than one individual. The developer security analyst is required to be familiar with the TOE, the evaluation results and applicable assurance requirements as an essential prerequisite for fulfilling the role. The requirements do not specify how this level of knowledge and experience should be gained; however, it is likely that a prospective developer security analyst will have to undergo some form of training programme to address any deficiencies in his or her knowledge and experience. The developer security analyst needs to have sufficient authority within the developer’s organisation to ensure that the requirements of the AM Plan and its associated procedures are followed.
August 1999 Version 2.1
Page 189 of 208

15 - Assurance maintenance paradigm Assurance maintenance class and families
15.3.2
546
547
548
549
550
551
15.3.3
552
TOE component categorisation report
The aim of the TOE component categorisation report is to complement the AM Plan by providing 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, and also for the subsequent re-evaluation of the TOE.
The checking of the TOE component categorisation report occurs during the acceptance phase; the evaluator checks are applied only in respect of the version of the report for the certified version of the TOE. While the assurance maintenance procedures identified in the AM Plan require the developer to update the TOE component categorisation report as changes are made to the TOE, the evaluators are not required to re-review the document; however, any such updates are likely to be inspected during the monitoring phase.
The TOE component categorisation report covers all TSF representations for the level of assurance being maintained. The TOE component categorisation report also identifies: a) any hardware, firmware or software components that are external to the
TOE (e.g. hardware or software platforms), and that satisfy IT security requirements as defined in the ST; b) any development tools that, if modified, will have an impact on the required assurance that the TOE satisfies its ST.
The TOE component categorisation report also provides a description of the approach used for the categorisation of TOE components. As a minimum, TOE components are required to be categorised as either TSP-enforcing or non-TSPenforcing. The description of the categorisation scheme is intended to enable the developer security analyst to decide the category to which any new TOE component should be assigned, and also when to change the category of an existing TOE component following changes to the TOE or its ST.
The initial categorisation of the components of the TOE will be based on evidence provided by the developer in support of the evaluation of the TOE, independently validated by the evaluators. Although maintenance of the document is the responsibility of the developer security analyst, its initial contents may be based on the results of the evaluation of the TOE.
It may be useful for the ST to include AMA_CAT.1 where there is a requirement that assurance be maintained in future versions of the TOE. This applies irrespective of whether assurance maintenance is to be achieved by application of the requirements in this class, or by periodic re-evaluations of the TOE.
Evidence of assurance maintenance
Confidence needs to be established that the assurance in the TOE is being maintained by the developer, in accordance with the AM Plan. This is achieved
Page 190 of 208 Version 2.1
August 1999

Assurance maintenance class and families
15 - Assurance maintenance paradigm
553
554
555
556
15.3.4
557
558 through the provision of evidence that demonstrates that the assurance in the TOE has been maintained, which is independently checked by an evaluator. This check
(termed an ‘AM audit’) would typically be applied periodically during the monitoring phase of the TOE’s assurance maintenance cycle.
AM audits are conducted in accordance with the schedule defined in the AM Plan.
The developer and evaluator actions required by AMA_EVD.1 will therefore be invoked one or more times during the monitoring phase of the assurance maintenance cycle. The evaluators may need to visit the TOE development environment to examine the required evidence, but other ways of performing the checks are not precluded.
a) b)
The developer is required to provide evidence that the assurance maintenance procedures referred to in the AM Plan are being followed. This will include: configuration management records; documentation referenced by the security impact analysis, including the current version of the TOE component categorisation report, and evidence for all applicable assurance requirements such as design updates, test documentation, new versions of guidance documents, and so on; c) evidence of the tracking of security flaws.
The evaluator’s check of the developer’s security impact analysis (required by
AMA_SIA.1 on which AMA_EVD.1 depends) will act as a focus for the AM audit.
The AM audit will, in turn, provide corroboration of the developer’s analysis (and hence confidence in the quality of the analysis), thereby serving to validate the developer’s claim that assurance has been maintained in the current version of the
TOE.
An AM audit requires the evaluators to confirm that functional testing has been performed on the current version of the TOE. This is highlighted as a separate check because test documentation provides firm evidence that the TOE security functions continue to operate as specified. The evaluators sample the test documentation to confirm that the developer testing shows that the security functions operate as specified, and that the coverage and depth of testing is commensurate with the level of assurance being maintained.
Security impact analysis
The aim of the security impact analysis is to provide 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 certified. These requirements may be applied during a monitoring phase or a re-evaluation phase.
The developer’s security impact analysis is based on the TOE component categorisation report: changes to TSP-enforcing TOE components may have an impact on the assurance that the TOE continues to meet its ST following the
August 1999 Version 2.1
Page 191 of 208

559
560
561
15 - Assurance maintenance paradigm
562
Assurance maintenance class and families changes. All such changes therefore require an analysis of their security impact to show that they do not undermine assurance in the TOE.
The components in this family may be used in support of either a subsequent AM audit or a re-evaluation of the TOE.
For an AM audit, the evaluators’ review of the security impact analysis should act as a focus for the subsequent audit activities, which should in turn provide corroboration of the developer’s analysis.
The security impact analysis identifies the changes from the certified version of the
TOE, in terms of the TOE components which are either new, or which have been modified. The evaluators check the accuracy of this information during either the associated AM audit, or the associated re-evaluation of the TOE.
Provision of the security impact analysis in support of a re-evaluation should reduce the level of evaluator effort needed to establish the required level of assurance in the TOE. Application of AMA_SIA.2, which requires a full examination of the security impact analysis, is likely to provide maximum benefit to the re-evaluation.
The precise detailed conditions under which an evaluation authority might wish the security impact analysis to be used in practice in a re-evaluation are beyond the scope of the CC.
Page 192 of 208 Version 2.1
August 1999

563
564
The maintenance of assurance class provides requirements that are intended to be applied after a TOE has been certified against the CC. These requirements are aimed at assuring that the TOE will continue to meet its security target as changes are made to the TOE or its environment. Such changes include the discovery of new threats or vulnerabilities, changes in user requirements, and the correction of bugs found in the certified TOE.
The class comprises four families, and the hierarchy of components within, as shown in Figure 16.1:
Class AMA: Maintenance of assurance
AMA_AMP Assurance maintenance plan
AMA_CAT TOE component categorisation report
1
1
AMA_EVD Evidence of assurance maintenance 1
AMA_SIA Security impact analysis
Figure 16.1 - Maintenance of assurance class decomposition
1 2
August 1999 Version 2.1
Page 193 of 208

16 - Class AMA: Maintenance of assurance
Assurance maintenance plan (AMA_AMP)
AMA_AMP
565
566
567
568
569
570
571
Assurance maintenance plan
Objectives
The Assurance Maintenance Plan (AM Plan) identifies the plans and procedures a developer must implement in order to ensure that the assurance that was established in the certified TOE is maintained as changes are made to the TOE or its environment. The AM Plan is specific to the TOE, and is tailored to the developer’s own practices and procedures.
Component levelling
This family contains only one component.
Application notes
An AM Plan covers one assurance maintenance cycle, this being the period from the completion of the most recent evaluation of the TOE to the completion of the next planned re-evaluation.
The requirements AMA_AMP.1.2C and AMA_AMP.1.3C serve to provide a clear identification of the baseline for assurance maintenance, in terms of the evaluation results and the definition of the categorisation of TOE components. The TOE component categorisation report is subject to the requirements of the AMA_CAT family, and provides the basis for the security impact analysis performed by the developer security analyst.
The definition of the scope of changes covered by the plan, as required by
AMA_AMP.1.4C, should be in terms of the category of components of the TOE that may be changed and the representational level at which changes can occur
(referencing the TOE component categorisation report where appropriate).
AMA_AMP.1.5C requires a description of the developer’s current plans for any new releases of the TOE. These plans may be subject to change, and hence require an update to the AM Plan. It should be noted, however, that in this context the term
new release does not, for example, include minor (‘unplanned’) releases of the TOE to incorporate bug fixes.
AMA_AMP.1.6C requires a definition of the planned schedule for AM audits (see the AMA_EVD family below) and the targeted re-evaluation of the TOE, together with a justification of the proposed schedules. The schedules may be defined in terms of elapsed time (e.g. annual AM audits), or they may be linked to specific new releases of the TOE. The planned schedules should take into account the expected changes to the TOE during the period, and also any elapsed period between the evaluation of the TOE and the establishment of the AM Plan. In particular, any changes outside the scope of the AM Plan will trigger a re-evaluation.
Page 194 of 208 Version 2.1
August 1999

Assurance maintenance plan
(AMA_AMP)
16 - Class AMA: Maintenance of assurance
AMA_AMP.1 Assurance maintenance plan
Dependencies:
ACM_CAP.2 Configuration items
ALC_FLR.1 Basic flaw remediation
AMA_CAT.1 TOE component categorisation report
Developer action elements:
AMA_AMP.1.1D
The developer shall provide an AM Plan.
Content and presentation of evidence elements:
AMA_AMP.1.1C
The AM Plan shall contain or reference a brief description of the TOE, including the security functionality it provides.
AMA_AMP.1.2C
The AM Plan shall identify the certified version of the TOE, and shall reference the evaluation results.
AMA_AMP.1.3C
The AM Plan shall reference the TOE component categorisation report for the certified version of the TOE.
AMA_AMP.1.4C
The AM Plan shall define the scope of changes to the TOE that are covered by the plan.
AMA_AMP.1.5C
The AM Plan shall describe the TOE life-cycle, and shall identify the current plans for any new releases of the TOE, together with a brief description of any planned changes that are likely to have a significant security impact.
AMA_AMP.1.6C
The AM Plan shall describe the assurance maintenance cycle, stating and justifying the planned schedule of AM audits and the target date of the next reevaluation of the TOE.
AMA_AMP.1.7C
The AM Plan shall identify the individual(s) who will assume the role of developer security analyst for the TOE.
AMA_AMP.1.8C
The AM Plan shall describe how the developer security analyst role will ensure that the procedures documented or referenced in the AM Plan are followed.
AMA_AMP.1.9C
The AM Plan shall describe how the developer security analyst role will ensure that all developer actions involved in the analysis of the security impact of changes affecting the TOE are performed correctly.
AMA_AMP.1.10C
The AM Plan shall justify why the identified developer security analyst(s) have sufficient familiarity with the security target, functional specification and
(where appropriate) high-level design of the TOE, and with the evaluation results and all applicable assurance requirements for the certified version of the TOE.
August 1999 Version 2.1
Page 195 of 208

16 - Class AMA: Maintenance of assurance
Assurance maintenance plan (AMA_AMP)
AMA_AMP.1.11C
The AM Plan shall describe or reference the procedures to be applied to maintain the assurance in the TOE, which as a minimum shall include the procedures for configuration management, maintenance of assurance evidence, performance of the analysis of the security impact of changes affecting the TOE, and flaw remediation.
Evaluator action elements:
AMA_AMP.1.1E
The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
AMA_AMP.1.2E
The evaluator shall confirm that the proposed schedules for AM audits and reevaluation of the TOE are acceptable and consistent with the proposed changes to the TOE.
Page 196 of 208 Version 2.1
August 1999

TOE component categorisation report
(AMA_CAT)
16 - Class AMA: Maintenance of assurance
AM A_CAT
572
573
574
575
576
TOE com ponent categorisation report
Objectives
The aim of the TOE component categorisation report is to complement the AM Plan by providing 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, and also for the subsequent re-evaluation of the TOE.
Component levelling
This family contains only one component.
Application notes
The term “least abstract TSF representation” in AMA_CAT.1.1 refers to the least abstract representation of the TSF that was provided for the level of assurance that is being maintained. For example, if the TOE is to be maintained at an assurance level of EAL3, then the least abstract TSF representation is the high-level design, and the following TOE components must be categorised: a) all external TSF interfaces identifiable in the functional specification; b) all TSF subsystems identifiable in the high-level design.
While AMA_CAT requires at least two categories to be defined, it may be appropriate (dependent on the type of TOE) to further subdivide the TSP-enforcing category in order to help focus the developer’s security impact analysis. For example, TSP-enforcing components could be categorised as either security critical or security supporting where: a) security critical TOE components are those which are directly responsible for the enforcement of at least one IT security function defined in the security target; b) security supporting TOE components are those which are not directly responsible for the enforcement of any IT security function (and hence are not security critical), but which are nonetheless relied upon to uphold the IT security functions; this category may in turn include two distinct types of TOE component:
-
those that provide services to security critical TOE components, and hence are relied upon to function correctly; those that do not provide any such service, but which nonetheless have to be trusted not to behave in a malicious manner (i.e.
introducing a vulnerability).
AMA_CAT.1.3C requires an identification of any development tools that, if modified, will have an impact on the assurance that the TOE satisfies its security target (e.g. the compiler used to create the object code).
August 1999 Version 2.1
Page 197 of 208

16 - Class AMA: Maintenance of assurance
TOE component categorisation report
(AMA_CAT)
AMA_CAT.1 TOE component categorisation report
Dependencies:
ACM_CAP.2 Configuration items
Developer action elements:
AMA_CAT.1.1D
The developer shall provide a TOE component categorisation report for the certified version of the TOE.
Content and presentation of evidence elements:
AMA_CAT.1.1C
The TOE component categorisation report shall categorise each component of the TOE, identifiable in each TSF representation from the most abstract to the least abstract, according to its relevance to security; as a minimum, TOE components must be categorised as one of TSP-enforcing or non-TSPenforcing.
AMA_CAT.1.2C
The TOE component categorisation report shall describe the categorisation scheme used, so that it can be determined how to categorise new components introduced into the TOE, and also when to re-categorise existing TOE components following changes to the TOE or its security target.
AMA_CAT.1.3C
The TOE component categorisation report shall identify any tools used in the development environment that, if modified, will have an impact on the assurance that the TOE satisfies its security target.
Evaluator action elements:
AMA_CAT.1.1E
The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
AMA_CAT.1.2E
The evaluator shall confirm that the categorisation of TOE components and tools, and the categorisation scheme used, are appropriate and consistent with the evaluation results for the certified version.
Page 198 of 208 Version 2.1
August 1999

Evidence of assurance maintenance
(AMA_EVD)
16 - Class AMA: Maintenance of assurance
AM A_EVD
577
578
579
580
581
582
Evidence of assurance maintenance
Objectives
The aim of this family of requirements is to establish confidence that the assurance in the TOE is being maintained by the developer, in accordance with the AM Plan.
This is achieved through the provision of evidence which demonstrates that the assurance in the TOE has been maintained, which is independently checked by an evaluator. This check, termed an ‘AM audit’, is periodically applied during the lifetime of the AM Plan.
Component levelling
This family contains only one component.
Application notes
This family includes some evidence requirements that are similar to assurance requirements defined in the ACM, ATE and AVA classes. However, the AM audit does not require the evaluators to examine the evidence to the same extent as required by the components in these classes; rather, it requires a sampling approach to establish confidence that the assurance maintenance procedures are being followed correctly.
As part of the AM audit, the evaluators check (by sampling) that the configuration list and security impact analysis are consistent for the current version of the TOE, in terms of their identification of the TOE components that have changed from the certified version of the TOE.
AMA_EVD.1.3C requires the provision of evidence that the assurance maintenance procedures in the AM Plan are being followed. This covers all procedures referred to in AMA_AMP.1.11C, i.e. evidence of application of procedures relating to configuration management, maintenance of assurance evidence, performance of security impact analysis, and flaw remediation.
The evidence required in AMA_EVD.1.4C includes the provision of a list of identified vulnerabilities in the current version of the TOE. This is highlighted as a separate requirement because of the importance of ensuring, to a level consistent with the original evaluation assurance requirements, that the current version contains no security weakness that are exploitable within the TOE environment.
The list in AMA_EVD.1.4C should include vulnerabilities arising from: a) the developer’s analysis required by AVA_VLA.1, or higher component (if required for the certified version of the TOE); b) any other reported security flaws handled by the flaw remediation procedures required by ALC_FLR.1(or ALC_FLR.2 if required for the certified version of the
TOE).
August 1999 Version 2.1
Page 199 of 208

16 - Class AMA: Maintenance of assurance
Evidence of assurance maintenance
(AMA_EVD)
583
AMA_EVD.1.5E requires the evaluators to confirm that functional testing has been performed on the current version of the TOE, and that the coverage and depth of testing is commensurate with the level of assurance being maintained. This check is performed by sampling the test documentation for the current version of the TOE.
AMA_EVD.1 Evidence of maintenance process
Dependencies:
AMA_AMP.1 Assurance maintenance plan
AMA_SIA.1 Sampling of security impact analysis
AMA_EVD.1.1D
Developer action elements:
The developer security analyst shall provide AM documentation for the
current version of the TOE.
Content and presentation of evidence elements:
AMA_EVD.1.1C
The AM documentation shall include a configuration list and a list of identified vulnerabilities in the TOE.
AMA_EVD.1.2C
The configuration list shall describe the configuration items that comprise the current version of the TOE.
AMA_EVD.1.3C
The AM documentation shall provide evidence that the procedures documented or referenced in the AM Plan are being followed.
AMA_EVD.1.4C
The list of identified vulnerabilities in the current version of the TOE shall show, for each vulnerability, that the vulnerability cannot be exploited in the intended environment for the TOE.
Evaluator action elements:
AMA_EVD.1.1E
The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
AMA_EVD.1.2E
The evaluator shall confirm that the procedures documented or referenced in the AM Plan are being followed.
AMA_EVD.1.3E
The evaluator shall confirm that the security impact analysis for the current version of the TOE is consistent with the configuration list.
AMA_EVD.1.4E
The evaluator shall confirm that all changes documented in the security impact analysis for the current version of the TOE are within the scope of changes covered by the AM Plan.
AMA_EVD.1.5E
The evaluator shall confirm that functional testing has been performed on the current version of the TOE, to a degree commensurate with the level of assurance being maintained.
Page 200 of 208 Version 2.1
August 1999

Security impact analysis (AMA_SIA) 16 - Class AMA: Maintenance of assurance
AM A_SIA
584
585
Security impact analysis
Objectives
The aim of the security impact analysis is to provide 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 certified.
Component levelling
This family consists of two components, levelled according to the degree to which an evaluator validates the developer’s security impact analysis.
Application notes
586
587
AMA_SIA.1.2C
AMA_SIA.1.3C
AMA_SIA.1 requires a sampling approach to validate the developer’s security impact analysis. In some cases, AMA_SIA.2 may be preferred where a sampling approach is not considered sufficient to establish confidence that assurance has been maintained in the current version of the TOE, but where a formal re-evaluation is not considered necessary.
Both components in this family require the security impact analysis to identify all new and modified TOE components in the current version of the TOE (as compared with the certified version). The accuracy of this information is checked during either the associated AM audit (by sampling), or the associated re-evaluation of the
TOE when the configuration list is checked under ACM_CAP.
AMA_SIA.1 Sampling of security impact analysis
Dependencies:
AMA_CAT.1 TOE component categorisation report
AMA_SIA.1.1D
AMA_SIA.1.1C
Developer action elements:
The developer security analyst shall, for the current version of the TOE, provide a security impact analysis that covers all changes affecting the TOE as compared with the certified version.
Content and presentation of evidence elements:
The security impact analysis shall identify the certified TOE from which the current version of the TOE was derived.
The security impact analysis shall identify all new and modified TOE components that are categorised as TSP-enforcing.
The security impact analysis shall, for each change affecting the security target or TSF representations, briefly describe the change and any effects it has on lower representation levels.
August 1999 Version 2.1
Page 201 of 208

16 - Class AMA: Maintenance of assurance
Security impact analysis (AMA_SIA)
AMA_SIA.1.4C
AMA_SIA.1.5C
AMA_SIA.1.6C
AMA_SIA.1.7C
AMA_SIA.2.1C
AMA_SIA.2.2C
The security impact analysis shall, for each change affecting the security target or TSF representations, identify all IT security functions and all TOE components categorised as TSP-enforcing that are affected by the change.
The security impact analysis shall, for each change which results in a modification of the implementation representation of the TSF or the IT environment, identify the test evidence that shows, to the required level of assurance, that the TSF continues to be correctly implemented following the change.
The security impact analysis shall, for each applicable assurance requirement in the configuration management (ACM), life cycle support (ALC), delivery and operation (ADO) and guidance documents (AGD) assurance classes, identify any evaluation deliverables that have changed, and provide a brief description of each change and its impact on assurance.
The security impact analysis shall, for each applicable assurance requirement in the vulnerability assessment (AVA) assurance class, identify which evaluation deliverables have changed and which have not, and give reasons for the decision taken as to whether or not to update the deliverable.
AMA_SIA.1.1E
Evaluator action elements:
The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
AMA_SIA.1.2E
The evaluator shall check, by sampling, that the security impact analysis documents changes to an appropriate level of detail, together with appropriate justifications that assurance has been maintained in the current version of the
TOE.
AMA_SIA.2 Examination of security impact analysis
Dependencies:
AMA_CAT.1 TOE component categorisation report
AMA_SIA.2.1D
Developer action elements:
The developer security analyst shall, for the current version of the TOE, provide a security impact analysis that covers all changes affecting the TOE as compared with the certified version.
Content and presentation of evidence elements:
The security impact analysis shall identify the certified TOE from which the current version of the TOE was derived.
The security impact analysis shall identify all new and modified TOE components that are categorised as TSP-enforcing.
Page 202 of 208 Version 2.1
August 1999

Security impact analysis (AMA_SIA) 16 - Class AMA: Maintenance of assurance
AMA_SIA.2.3C
AMA_SIA.2.4C
AMA_SIA.2.5C
AMA_SIA.2.6C
AMA_SIA.2.7C
AMA_SIA.2.1E
AMA_SIA.2.2E
The security impact analysis shall, for each change affecting the security target or
TSF representations, briefly describe the change and any effects it has on lower representation levels.
The security impact analysis shall, for each change affecting the security target or
TSF representations, identify all IT security functions and all TOE components categorised as TSP-enforcing that are affected by the change.
The security impact analysis shall, for each change which results in a modification of the implementation representation of the TSF or the IT environment, identify the test evidence that shows, to the required level of assurance, that the TSF continues to be correctly implemented following the change.
The security impact analysis shall, for each applicable assurance requirement in the configuration management (ACM), life cycle support (ALC), delivery and operation (ADO) and guidance documents (AGD) assurance classes, identify any evaluation deliverables that have changed, and provide a brief description of each change and its impact on assurance.
The security impact analysis shall, for each applicable assurance requirement in the vulnerability assessment (AVA) assurance class, identify which evaluation deliverables have changed and which have not, and give reasons for the decision taken as to whether or not to update the deliverable.
Evaluator action elements:
The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
The evaluator shall check that the security impact analysis documents all changes to an appropriate level of detail, together with appropriate justifications that assurance has been maintained in the current version of the TOE.
August 1999 Version 2.1
Page 203 of 208

588
The dependencies documented in the components of clauses 8-14 and clause 16, are the direct dependencies between the assurance components. Table A.1 summarises both the direct dependencies and the indirect dependencies. The indirect dependencies are the cumulative result of iteratively including all the dependencies of each component identified as being a dependency.
Table A.1 - Assurance component dependencies a
Comp.
Names
AUT.1-2
CAP.1-2
CAP.3-4
CAP.5
SCP.1-3
DEL.1
DEL.2-3
IGS.1-2
FSP.1-4
HLD.1-2
HLD.3-4
HLD.5
IMP.1-2
IMP.3
INT.1-2
INT.3
LLD.1
LLD.2
LLD.3
RCR.1-3
SPM.1-3
ADM.1
USR.1
A
U
T
C
A
P
S
C
P
D
E
L
I
G
S
3 1
3
1
1
3 1
F
S
P
H
L
D
I
M
P
I
N
T
L
L
D
R
C
R
S
P
M
A
D
M
U
S
R
D
V
S
F
L
R
L
C
D
T
A
T
C
O
V
D
P
T
F
U
N
I
N
D
C
C
A
M
S
U
S
O
F
V
L
A
1
1
1
3
4
1 2
1 2
1 2 1
1 2 2
1 2
3 3
4 5
1
1
1
1
1
1
2
3
1 1
1 1 1
1 1
1 1
1
2
3
1
1
1
1
1
2
1
1
1
1
1
1
August 1999 Version 2.1
Page 204 of 208

A - Cross reference of assurance component dependencies
Comp.
Names
Table A.1 - Assurance component dependencies a
A
U
T
C
A
P
S
C
P
D
E
L
I
G
S
F
S
P
H
L
D
I
M
P
I
N
T
L
L
D
R
C
R
S
P
M
A
D
M
U
S
R
D
V
S
F
L
R
L
C
D
T
A
T
C
O
V
D
P
T
F
U
N
I
N
D
C
C
A
M
S
U
S
O
F
V
L
A
DVS.1-2
FLR.1-3
LCD.1-3
TAT.1-3
COV.1-3
DPT.1
DPT.2
DPT.3
FUN.1-2
IND.1
IND.2-3
CCA.1-3
MSU.1-3
SOF.1
VLA.1
VLA.2-4
AMP.1
CAT.1
EVD.1
SIA.1-2
2
2
1 2 1
1
1 1
1 2
1 2 2
1
1
2 2 2
1 1
1 1
1 1
1 2 1
1 1
1
1
1 1
1 1
1
1
1 1
1
1
1
1 1
1 1
1 1
1 1
1 1
1 1
1 1
1
1
1
1
1
1
1
1
1 a. In Table A.1, the left column represents groupings of specific components (using only the last three digits of the component name and an indicator of component number or range of numbers). Each non-empty box in the table indicates a specific component, identified by its name at the top of the column and the number in the box, on which the component in the left column is dependent. Bold numbers represent direct dependencies. Italicised numbers represent indirect dependencies.
Dark shading represents the intersection of a component with itself. Dependencies from AMA components to assurance components are included in Table A.1, while
AMA internal dependencies are shown in Table A.2 below. There are no dependencies from any non-AMA components to those in AMA, and so Table A.1
has no columns representing the AMA families.
August 1999 Version 2.1
Page 205 of 208

A - Cross reference of assurance component dependencies
Table A.2 - AMA Internal Dependencies
AMA
Comp.
Names
A
M
P
AMP.1
1
CAT.1
EVD.1
1 1
SIA.1-2 1
C
A
T
E
V
D
S
I
A
1
Page 206 of 208 Version 2.1
August 1999

589
Table B.1 describes the relationship between the evaluation assurance levels and the assurance classes, families and components.
Table B.1 - Evaluation assurance level summary
Assurance
Class
Configuration
management
Delivery and operation
Development
Guidance documents
Life cycle support
Tests
Vulnerability assessment
Assurance
Family
Assurance Components by
Evaluation Assurance Level
EAL1 EAL2 EAL3 EAL4 EAL5 EAL6 EAL7
ACM_AUT
ACM_CAP 1 2 3
1
4
1
4
2
5
2
5
ACM_SCP
ADO_DEL
ADO_IGS
ADV_FSP
ADV_HLD
ADV_IMP
ADV_INT
1
1
1
1
1
1
1
1
1
1
2
2
2
1
2
2
1
3
2
1
3
3
2
1
3
2
1
3
4
3
2
3
3
1
4
5
3
3
ADV_LLD
ADV_RCR 1
ADV_SPM
AGD_ADM 1
AGD_USR 1
ALC_DVS
ALC_FLR
1
1
1
1
1
1
1
1
1
1
1
1
1
1
2
3
1
1
1
2
2
3
1
1
2
3
1
1
2
2
3
ALC_LCD
ALC_TAT
ATE_COV
ATE_DPT
ATE_FUN
ATE_IND
AVA_CCA
AVA_MSU
AVA_SOF
AVA_VLA
1
1
1
2
1
1
2
1
1
2
1
1
1
1
1
2
1
1
2
2
1
2
2
2
2
2
1
2
1
2
1
3
2
3
3
2
2
2
2
3
1
4
3
2
3
1
4
3
3
3
3
2
August 1999 Version 2.1
Page 207 of 208

Annex B - EALs and components Part 3: Security assurance requirements
Page 208 of 208 Version 2.1
August 1999