ISO/IEC 15408-1:1999

Information technology - Security techniques - Evaluation criteria for IT security - Part 1: Introduction and general model

Technologies de l'information — Techniques de sécurité — Critères d'évaluation pour la sécurité TI — Partie 1: Introduction et modèle général

General Information

• Status: Withdrawn
• Publication Date: 15-Dec-1999
• Withdrawal Date: 15-Dec-1999
• ICS: 35.030 - IT Security
• ICS: 35.040 - Information coding
• Technical Committee: ISO/IEC JTC 1/SC 27 - Information security, cybersecurity and privacy protection
• Drafting Committee: ISO/IEC JTC 1/SC 27/WG 3 - Security evaluation, testing and specification
• Current Stage: 9599 - Withdrawal of International Standard
• Start Date: 22-Sep-2005
• Completion Date: 30-Oct-2025

Relations

• Revised: ISO/IEC 15408-1:2005 - Information technology - Security techniques - Evaluation criteria for IT security - Part 1: Introduction and general model
• Effective Date: 15-Apr-2008

Standards Content (Sample)

INTERNATIONAL ISO/IEC
STANDARD 15408-1
First edition
1999-12-01
Information technology — Security
techniques — Evaluation criteria for IT
security —
Part 1:
Introduction and general model
Technologies de l'information — Techniques de sécurité — Critères
d'évaluation pour la sécurité TI —
Partie 1: Introduction et modèle général
Reference number
bc
©  ISO/IEC 1999
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means, electronic
or mechanical, including photocopying and microfilm, without permission in writing from the publisher.
ISO/IEC Copyright Office • Case postale 56 • CH-1211 Genève 20 • Switzerland
Printed in Switzerland
ii
4.5.3 TOE evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.6 Assurance maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5 Common Criteria requirements and evaluation results . . . . . . . . . . . . . . . 29
5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.2 Requirements in PPs and STs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.2.1 PP evaluation results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.3 Requirements in TOE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.3.1 TOE evaluation results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.4 Caveats on evaluation results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.5 Use of TOE evaluation results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Annex A The Common Criteria project (informative) . . . . . . . . . . . . . . . . . . . . . . . . 33
A.1 Background to the Common Criteria project . . . . . . . . . . . . . . . . . . . . . . . 33
A.2 Development of the Common Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
A.3 Common Criteria project sponsoring organisations . . . . . . . . . . . . . . . . . . 34
Annex B Specification of Protection Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
B.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
B.2 Content of Protection Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
B.2.1 Content and presentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
B.2.2 PP introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
B.2.3 TOE description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
B.2.4 TOE security environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
B.2.5 Security objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
B.2.6 IT security requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
B.2.7 Application notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
B.2.8 Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Annex C Specification of Security Targets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
C.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
C.2 Content of Security Target . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
C.2.1 Content and presentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
C.2.2 ST introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
C.2.3 TOE description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
C.2.4 TOE security environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
C.2.5 Security objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
C.2.6 IT security requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
C.2.7 TOE summary specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
C.2.8 PP claims . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
C.2.9 Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Annex D Bibliography (informative) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
iv
© ISO/IEC ISO/IEC 15408-1:1999(E)
List of Figures
Figure 3.1 - Evaluation context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Figure 4.1 - Security concepts and relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Figure 4.2 - Evaluation concepts and relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Figure 4.3 - TOE development model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Figure 4.4 - TOE evaluation process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Figure 4.5 - Derivation of requirements and specifications . . . . . . . . . . . . . . . . . . . . . . . . . 20
Figure 4.6 - Organisation and construction of requirements . . . . . . . . . . . . . . . . . . . . . . . . 24
Figure 4.7 - Use of security requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Figure 5.1 - Evaluation results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Figure 5.2 - Use of TOE evaluation results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Figure B.1 - Protection Profile content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Figure C.1 - Security Target content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
v
List of Tables
Table 3.1 - Roadmap to the Common Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
vi
the TOE are treated as secure usage assumptions where these have an impact on the
ability of the IT security measures to counter the identified threats.
b) 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.
c) 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.
d) 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.
e) 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.
© ISO/IEC ISO/IEC 15408-1:1999(E)
2 Definitions
2.1 Common abbreviations
The following abbreviations are common to more than one part of the CC:
CC Common Criteria, the name used historically for this multipart standard
ISO/IEC 15408 in lieu of its official ISO name of “Evaluation criteria for
information technology security”
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
TOE Security Functions
TSF
TSFI TSF Interface
TSP TOE Security Policy
2.2 Scope of glossary
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 ISO/IEC
15408-2 and ISO/IEC 15408-3 can be found in their respective “paradigm” subclauses.
2.3 Glossary
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.
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.
© ISO/IEC ISO/IEC 15408-1:1999(E)
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.
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.
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.
© ISO/IEC ISO/IEC 15408-1:1999(E)
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.
© ISO/IEC ISO/IEC 15408-1:1999(E)
3 Overview
This clause introduces the main concepts of the CC. It identifies the target audience, evaluation
context, and the approach taken to present the material.
3.1 Introduction
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.
3.2 Target audience of the CC
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.
3.2.1 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 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.
3.2.2 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 implementation-dependent 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.
3.2.3 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.
3.2.4 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) system custodians and system security officers responsible for determining and
meeting organisational IT security policies and requirements;
b) auditors, both internal and external, responsible for assessing the adequacy of the
security of a system;
c) security architects and designers responsible for the specification of the security
content of IT systems and products;
d) accreditors responsible for accepting an IT system for use within a particular
environment;
e) sponsors of evaluation responsible for requesting and supporting an evaluation; and
© ISO/IEC ISO/IEC 15408-1:1999(E)
f) evaluation authorities responsible for the management and oversight of IT security
evaluation programmes.
3.3 Evaluation context
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.
Evaluation
Criteria
(the CC)
Evaluation
Methodology
Evaluation
Scheme
Final
List of
Approve/
Certificates/
Evaluate Evaluation
Certify
Register
Results
Figure 3.1 - Evaluation context
3.4 Organisation of Common Criteria
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) 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.
c) 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).
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 Developers Evaluators
Use for background informa- Use for background informa- Use for background informa-
Part 1
tion and reference purposes. tion and reference for the tion and reference purposes.
Guidance structure for PPs. development of requirements Guidance structure for PPs
and formulating security and STs.
specifications for TOEs.
Use for guidance and Use for reference when Use as mandatory statement
Part 2
reference when formulating interpreting statements of of evaluation criteria when
statements of requirements functional requirements and determining whether a TOE
for security functions. formulating functional effectively meets claimed
specifications for TOEs. security functions.
Use for guidance when Use for reference when Use as mandatory statement
Part 3
determining required levels interpreting statements of of evaluation criteria when
of assurance. assurance requirements and determining the assurance of
determining assurance TOEs and when evaluating
approaches of TOEs. PPs and STs.
© ISO/IEC ISO/IEC 15408-1:1999(E)
4 General model
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.
4.1 Security context
4.1.1 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.
value
Owners
wish to minimise
impose
to reduce
countermeasures
that may
that may be possess
reduced by
vulnerabilities
may be aware of
leading to
that
exploit
Threat agents risk
give
that increase
to
rise to
threats assets
to
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.
Assurance
Evaluation
Techniques
gives evidence of
produce
assurance
giving
Owners
require
confidence
that
countermeasures
risk
minimise
assets.
to
Figure 4.2 - Evaluation concepts and relationships
© ISO/IEC ISO/IEC 15408-1:1999(E)
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.
4.1.2 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.
4.2 Common Criteria approach
Confidence in IT security can be gained through actions that may be taken during the processes of
development, evaluation, and operation.
4.2.1 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 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.
Security
requirements
Functional
Design and
specification
implementation
refinement
High-level
design
Correspondence
analysis and
Source code/
Hardware
integration testing
drawings
Implementatio
n
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
© ISO/IEC ISO/IEC 15408-1:1999(E)
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:
a) 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);
b) 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.
Evaluation
criteria
Security
Evaluation
Develop
requirements
Methodology
TOE
(PP and ST)
Evaluation
Scheme
TOE and
Evaluation Evaluate
Evidence TOE
Evaluation
Operate
Results
TOE
Feedback
Figure 4.4 - TOE evaluation process
4.2.2 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:
a) the set of TOE evidence, which includes the evaluated ST as the basis for TOE
evaluation;
b) the TOE for which the evaluation is required;
c) 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.
4.2.3 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 re-evaluation, including reuse of
evaluation results, are outside the scope of the CC.
4.3 Security concepts
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.
© ISO/IEC ISO/IEC 15408-1:1999(E)
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.
Assets requiring
protection TOE purpose
TOE physical
environment
Security
Establish
Environment
security
material (PP/ST)
environment
Assumptions Organisational
Threats
security policies
Establish
security
objectives
Security
Security Objectives
objectives
CC requirements
material (PP/ST)
catalogue
Establish
security
requirements
Security
Requirements for Requirements
Functional Assurance
the environment
requirements requirements
material (PP/ST)
Establish
TOE summary
specification
Security
TOE summary
Specification
specification
material (ST)
Figure 4.5 - Derivation of requirements and specifications
4.3.1 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 the context in which the TOE is
© ISO/IEC ISO/IEC 15408-1:1999(E)
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) 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;
c) 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 perm
...