ISO/IEC 15408-1:2009

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

ISO/IEC 15408-1:2009 establishes the general concepts and principles of IT security evaluation and specifies the general model of evaluation given by various parts of ISO/IEC 15408 which in its entirety is meant to be used as the basis for evaluation of security properties of IT products. It provides an overview of all parts of ISO/IEC 15408. It describes the various parts of ISO/IEC 15408; defines the terms and abbreviations to be used in all parts ISO/IEC 15408; establishes the core concept of a Target of Evaluation (TOE); the evaluation context; and describes the audience to which the evaluation criteria are addressed. An introduction to the basic security concepts necessary for evaluation of IT products is given. It defines the various operations by which the functional and assurance components given in ISO/IEC 15408-2 and ISO/IEC 15408-3 may be tailored through the use of permitted operations. The key concepts of protection profiles (PP), packages of security requirements and the topic of conformance are specified and the consequences of evaluation and evaluation results are described. ISO/IEC 15408-1:2009 gives guidelines for the specification of Security Targets (ST) and provides a description of the organization of components throughout the model. General information about the evaluation methodology is given in ISO/IEC 18045 and the scope of evaluation schemes is provided.

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

La présente partie de l'ISO/IEC 15408 établit les concepts et principes généraux de l'évaluation de la sécurité des technologies de l'information (TI). Elle spécifie le modèle général d'évaluation donné par les différentes parties de la norme qui, dans son intégralité, est destinée à servir de base à l'évaluation des propriétés de sécurité des produits TI. La Partie 1 fournit une vue d'ensemble de toutes les parties de la norme ISO/IEC 15408. Elle décrit les différentes parties de la norme, définit les termes et abréviations à utiliser dans toutes les parties de la norme, établit le concept fondamental d'une cible d'évaluation (TOE, de l'anglais Target of Evaluation), spécifie le contexte d'une évaluation et décrit le public à qui s'adressent les critères d'évaluation. Elle fournit en outre une introduction aux concepts de sécurité de base nécessaires pour l'évaluation de produits TI. Elle définit les diverses opérations dans le cadre desquelles les composants fonctionnels et d'assurance décrits dans l'ISO/IEC 15408‑2 et dans l'ISO/IEC 15408‑3 peuvent être adaptés par l'utilisation d'opérations autorisées. Elle spécifie les concepts clés de profils de protection (PP), les ensembles d'exigences de sécurité et le sujet de la conformité, et décrit les conséquences d'une évaluation ainsi que les résultats d'une évaluation. La présente partie de l'ISO/IEC 15408 donne des lignes directrices pour la spécification de cibles de sécurité (ST, de l'anglais Security Targets) et fournit une description de l'organisation des composants sur l'ensemble du modèle. Des informations générales sur la méthodologie d'évaluation sont données dans l'ISO/IEC 18045 et le domaine d'application des plans d'évaluation est fourni.

General Information

• Status: Withdrawn
• Publication Date: 02-Dec-2009
• 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: 09-Aug-2022
• Completion Date: 30-Oct-2025

Relations

• Revised: ISO/IEC 15408-1:2022 - Information security, cybersecurity and privacy protection - Evaluation criteria for IT security - Part 1: Introduction and general model
• Effective Date: 17-Dec-2016
• Revises: 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
Third edition
2009-12-15
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
©
ISO/IEC 2009
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but
shall not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In
downloading this file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat
accepts no liability in this area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation
parameters were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In
the unlikely event that a problem relating to it is found, please inform the Central Secretariat at the address given below.

©  ISO/IEC 2009
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 either ISO at the address below or
ISO's member body in the country of the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail [e-mail]
Web www.iso.org
Published in Switzerland
ii © ISO/IEC 2009 – All rights reserved

Contents Page
Foreword .iv
Introduction.v
1 Scope.1
2 Normative references.1
3 Terms and definitions .1
3.1 Terms and definitions common in ISO/IEC 15408 .2
3.2 Terms and definitions related to the ADV class.9
3.3 Terms and definitions related to the AGD class .13
3.4 Terms and definitions related to the ALC class.13
3.5 Terms and definitions related to the AVA class.17
3.6 Terms and definitions related to the ACO class .17
4 Abbreviated terms .18
5 Overview.19
5.1 General .19
5.2 The TOE.19
5.3 Target audience of ISO/IEC 15408 .20
5.4 The different parts of ISO/IEC 15408 .21
5.5 Evaluation context.22
6 General model.23
6.1 Introduction to the general model .23
6.2 Assets and countermeasures .23
6.3 Evaluation.27
7 Tailoring Security Requirements .27
7.1 Operations.27
7.2 Dependencies between components .30
7.3 Extended components.30
8 Protection Profiles and Packages .31
8.1 Introduction.31
8.2 Packages .31
8.3 Protection Profiles.31
8.4 Using PPs and packages.34
8.5 Using Multiple Protection Profiles.35
9 Evaluation results.35
9.1 Introduction.35
9.2 Results of a PP evaluation.36
9.3 Results of an ST/TOE evaluation .36
9.4 Conformance claim .36
9.5 Use of ST/TOE evaluation results.37
Annex A (informative) Specification of Security Targets.38
Annex B (informative) Specification of Protection Profiles.54
Annex C (informative) Guidance for Operations.60
Annex D (informative) PP conformance .63
Bibliography.65

© ISO/IEC 2009 – All rights reserved iii

Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are members of
ISO or IEC participate in the development of International Standards through technical committees
established by the respective organization to deal with particular fields of technical activity. ISO and IEC
technical committees collaborate in fields of mutual interest. Other international organizations, governmental
and non-governmental, in liaison with ISO and IEC, also take part in the work. In the field of information
technology, ISO and IEC have established a joint technical committee, ISO/IEC JTC 1.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of the joint technical committee is to prepare International Standards. Draft International
Standards adopted by the joint technical committee are circulated to national bodies for voting. Publication as
an International Standard requires approval by at least 75 % of the national bodies casting a vote.
Attention is drawn to the possibility that some of the elements of this part of ISO/IEC 15408 may be the
subject of patent rights. ISO and IEC shall not be held responsible for identifying any or all such patent rights.
ISO/IEC 15408-1 was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 27, IT Security techniques. The identical text of ISO/IEC 15408 is published by the
Common Criteria Project Sponsoring Organisations as Common Criteria for Information Technology Security
Evaluation. The common XML source for both publications can be found at http://www.oc.ccn.cni.es/xml
This third edition cancels and replaces the second edition (ISO/IEC 15408-1:2005), which has been
technically revised.
ISO/IEC 15408 consists of the following parts, under the general title Information technology — Security
techniques — Evaluation criteria for IT security:
⎯ Part 1: Introduction and general model
⎯ Part 2: Security functional components
⎯ Part 3: Security assurance components
iv © ISO/IEC 2009 – All rights reserved

Introduction
This part of ISO/IEC 15408 permits comparability between the results of independent security evaluations.
ISO/IEC 15408 does so by providing a common set of requirements for the security functionality of IT products
and for assurance measures applied to these IT products during a security evaluation. These IT products may
be implemented in hardware, firmware or software.
The evaluation process establishes a level of confidence that the security functionality of these IT products
and the assurance measures applied to these IT products meet these requirements. The evaluation results
may help consumers to determine whether these IT products fulfil their security needs.
ISO/IEC 15408 is useful as a guide for the development, evaluation and/or procurement of IT products with
security functionality.
ISO/IEC 15408 is intentionally flexible, enabling a range of evaluation methods to be applied to a range of
security properties of a range of IT products. Therefore users of this International Standard are cautioned to
exercise care that this flexibility is not misused. For example, using ISO/IEC 15408 in conjunction with
unsuitable evaluation methods, irrelevant security properties, or inappropriate IT products, may result in
meaningless evaluation results.
Consequently, the fact that an IT product has been evaluated has meaning only in the context of the security
properties that were evaluated and the evaluation methods that were used. Evaluation authorities are advised
to carefully check the products, properties and methods to determine that an evaluation will provide
meaningful results. Additionally, purchasers of evaluated products are advised to carefully consider this
context to determine whether the evaluated product is useful and applicable to their specific situation and
needs.
ISO/IEC 15408 addresses protection of assets 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. ISO/IEC 15408 may also be applicable to aspects of IT security outside
of these three. ISO/IEC 15408 is applicable to risks arising from human activities (malicious or otherwise) and
to risks arising from non-human activities. Apart from IT security, ISO/IEC 15408 may be applied in other
areas of IT, but makes no claim of applicability in these areas.
Certain topics, because they involve specialized techniques or because they are somewhat peripheral to
IT security, are considered to be outside the scope of ISO/IEC 15408. Some of these are identified below.
a) ISO/IEC 15408 does not contain security evaluation criteria pertaining to administrative security
measures not related directly to the IT security functionality. However, it is recognised that significant
security can often be achieved through or supported by administrative measures such as organizational,
personnel, physical, and procedural controls.
b) The evaluation of some 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.
c) ISO/IEC 15408 does not address the evaluation methodology under which the criteria should be applied.
This methodology is given in ISO/IEC 18045.
d) ISO/IEC 15408 does not address the administrative and legal framework under which the criteria may be
applied by evaluation authorities. However, it is expected that ISO/IEC 15408 will be used for evaluation
purposes in the context of such a framework.
e) The procedures for use of evaluation results in accreditation are outside the scope of ISO/IEC 15408.
Accreditation is the administrative process whereby authority is granted for the operation of an IT product
(or collection thereof) in its full operational environment including all of its non-IT parts. The results of the
© ISO/IEC 2009 – All rights reserved v

evaluation process are an input to the accreditation process. However, as other techniques are more
appropriate for the assessments of non-IT related properties and their relationship to the IT security parts,
accreditors should make separate provisions for those aspects.
f) The subject of criteria for the assessment of the inherent qualities of cryptographic algorithms is not
covered in ISO/IEC 15408. Should independent assessment of mathematical properties of cryptography
be required, the evaluation scheme under which ISO/IEC 15408 is applied must make provision for such
assessments.
ISO terminology, such as “can”, “informative”, “may”, “normative”, “shall” and “should” used throughout the
document are defined in the ISO/IEC Directives, Part 2. Note that the term “should” has an additional meaning
applicable when using this International Standard. See the note below. The following definition is given for the
use of “should” in ISO/IEC 15408.
should
within normative text, “should” indicates “that among several possibilities one is recommended as particularly
suitable, without mentioning or excluding others, or that a certain course of action is preferred but not
necessarily required” (ISO/IEC Directives, Part 2)
NOTE ISO/IEC 15408 interprets “not necessarily required” to mean that the choice of another possibility requires a
justification of why the preferred option was not chosen.

vi © ISO/IEC 2009 – All rights reserved

INTERNATIONAL STANDARD ISO/IEC 15408-1:2009(E)

Information technology — Security techniques — Evaluation
criteria for IT security —
Part 1:
Introduction and general model
1 Scope
This part of ISO/IEC 15408 establishes the general concepts and principles of IT security evaluation and
specifies the general model of evaluation given by various parts of the International Standard which in its
entirety is meant to be used as the basis for evaluation of security properties of IT products.
It provides an overview of all parts of ISO/IEC 15408. It describes the various parts of the standard; defines
the terms and abbreviations to be used in all parts of the International Standard; establishes the core concept
of a Target of Evaluation (TOE); the evaluation context; and describes the audience to which the evaluation
criteria are addressed. An introduction to the basic security concepts necessary for evaluation of IT products
is given.
It defines the various operations by which the functional and assurance components given in ISO/IEC 15408-2
and ISO/IEC 15408-3 may be tailored through the use of permitted operations.
The key concepts of protection profiles (PP), packages of security requirements and the topic of conformance
are specified and the consequences of evaluation and evaluation results are described. This part of
ISO/IEC 15408 gives guidelines for the specification of Security Targets (ST) and provides a description of the
organization of components throughout the model. General information about the evaluation methodology is
given in ISO/IEC 18045 and the scope of evaluation schemes is provided.
2 Normative references
The following referenced documents are indispensable for the application of this part of ISO/IEC 15408. For
dated references, only the edition cited applies. For undated references, the latest edition of the referenced
document (including any amendments) applies.
ISO/IEC 15408-2, Information technology — Security techniques — Evaluation criteria for IT security — Part 2:
Security functional components
ISO/IEC 15408-3, Information technology — Security techniques — Evaluation criteria for IT security — Part 3:
Security assurance components
ISO/IEC 18045, Information technology — Security techniques — Methodology for IT security evaluation
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
NOTE This clause contains only those terms which are used in a specialized way throughout ISO/IEC 15408. Some
combinations of common terms used in ISO/IEC 15408, while not meriting inclusion in this clause, are explained for clarity
in the context where they are used.
© ISO/IEC 2009 – All rights reserved 1

3.1 Terms and definitions common in ISO/IEC 15408
3.1.1
adverse actions
actions performed by a threat agent on an asset
3.1.2
assets
entities that the owner of the TOE presumably places value upon
3.1.3
assignment
specification of an identified parameter in a component (of ISO/IEC 15408) or requirement
3.1.4
assurance
grounds for confidence that a TOE meets the SFRs
3.1.5
attack potential
measure of the effort to be expended in attacking a TOE, expressed in terms of an attacker's expertise,
resources and motivation
3.1.6
augmentation
addition of one or more requirement(s) to a package
3.1.7
authentication data
information used to verify the claimed identity of a user
3.1.8
authorised user
TOE user who may, in accordance with the SFRs, perform an operation
3.1.9
class
set of ISO/IEC 15408 families that share a common focus
3.1.10
coherent
logically ordered and having discernible meaning
NOTE 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.
3.1.11
complete
property where all necessary parts of an entity have been provided
NOTE 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.
3.1.12
component
smallest selectable set of elements on which requirements may be based
2 © ISO/IEC 2009 – All rights reserved

3.1.13
composed assurance package
assurance package consisting of requirements drawn from ISO/IEC 15408-3 (predominately from the ACO
class), representing a point on ISO/IEC 15408 predefined composition assurance scale
3.1.14
confirm
declare that something has been reviewed in detail with an independent determination of sufficiency
NOTE The level of rigour required depends on the nature of the subject matter. This term is only applied to evaluator
actions.
3.1.15
connectivity
property of the TOE allowing interaction with IT entities external to the TOE
NOTE This includes exchange of data by wire or by wireless means, over any distance in any environment or
configuration.
3.1.16
consistent
relationship between two or more entities such that there are no apparent contradictions between these
entities
3.1.17
counter, verb
meet an attack where the impact of a particular threat is mitigated but not necessarily eradicated
3.1.18
demonstrable conformance
relation between an ST and a PP, where the ST provides a solution which solves the generic security problem
in the PP
NOTE The PP and the ST may contain entirely different statements that discuss different entities, use different
concepts etc. Demonstrable conformance is also suitable for a TOE type where several similar PPs already exist, thus
allowing the ST author to claim conformance to these PPs simultaneously, thereby saving work.
3.1.19
demonstrate
provide a conclusion gained by an analysis which is less rigorous than a “proof”
3.1.20
dependency
relationship between components such that if a requirement based on the depending component is included in
a PP, ST or package, a requirement based on the component that is depended upon must normally also be
included in the PP, ST or package
3.1.21
describe
provide specific details of an entity
3.1.22
determine
affirm a particular conclusion based on independent analysis with the objective of reaching a particular
conclusion
NOTE The usage of this term implies a truly independent analysis, usually in the absence of any previous analysis
having been performed. Compare with the terms “confirm” or “verify” which imply that an analysis has already been
performed which needs to be reviewed
© ISO/IEC 2009 – All rights reserved 3

3.1.23
development environment
environment in which the TOE is developed
3.1.24
element
indivisible statement of a security need
3.1.25
ensure
guarantee a strong causal relationship between an action and its consequences
NOTE When this term is preceded by the word “help” it indicates that the consequence is not fully certain, on the
basis of that action alone.
3.1.26
evaluation
assessment of a PP, an ST or a TOE, against defined criteria
3.1.27
evaluation assurance level
set of assurance requirements drawn from ISO/IEC 15408-3, representing a point on the ISO/IEC 15408
predefined assurance scale, that form an assurance package
3.1.28
evaluation authority
body that sets the standards and monitors the quality of evaluations conducted by bodies within a specific
community and implements ISO/IEC 15408 for that community by means of an evaluation scheme
3.1.29
evaluation scheme
administrative and regulatory framework under which ISO/IEC 15408 is applied by an evaluation authority
within a specific community
3.1.30
exhaustive
characteristic of a methodical approach taken to perform an analysis or activity according to an unambiguous
plan
NOTE This term is used in ISO/IEC 15408 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.
3.1.31
explain
give argument accounting for the reason for taking a course of action
NOTE 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.
3.1.32
extension
addition to an ST or PP of functional requirements not contained in ISO/IEC 15408-2 and/or assurance
requirements not contained in ISO/IEC 15408-3
3.1.33
external entity
human or IT entity possibly interacting with the TOE from outside of the TOE boundary
NOTE An external entity can also be referred to as a user.
4 © ISO/IEC 2009 – All rights reserved

3.1.34
family
set of components that share a similar goal but differ in emphasis or rigour
3.1.35
formal
expressed in a restricted syntax language with defined semantics based on well-established mathematical
concepts
3.1.36
guidance documentation
documentation that describes the delivery, preparation, operation, management and/or use of the TOE
3.1.37
identity
representation uniquely identifying entities (e.g. a user, a process or a disk) within the context of the TOE
NOTE An example of such a representation is a string. For a human user, the representation can be the full or
abbreviated name or a (still unique) pseudonym.
3.1.38
informal
expressed in natural language
3.1.39
inter TSF transfers
communicating data between the TOE and the security functionality of other trusted IT products
3.1.40
internal communication channel
communication channel between separated parts of the TOE
3.1.41
internal TOE transfer
communicating data between separated parts of the TOE
3.1.42
internally consistent
no apparent contradictions exist between any aspects of an entity
NOTE In terms of documentation, this means that there can be no statements within the documentation that can be
taken to contradict each other.
3.1.43
iteration
use of the same component to express two or more distinct requirements
3.1.44
justification
analysis leading to a conclusion
NOTE “Justification” 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.
3.1.45
object
passive entity in the TOE, that contains or receives information, and upon which subjects perform operations
© ISO/IEC 2009 – All rights reserved 5

3.1.46
operation
〈on a component of ISO/IEC 15408〉 modification or repetition of a component
NOTE Allowed operations on components are assignment, iteration, refinement and selection.
3.1.47
operation
〈on an object〉 specific type of action performed by a subject on an object
3.1.48
operational environment
environment in which the TOE is operated
3.1.49
organizational security policy
set of security rules, procedures, or guidelines for an organization
NOTE A policy may pertain to a specific operational environment.
3.1.50
package
named set of either security functional or security assurance requirements
NOTE An example of a package is “EAL 3”.
3.1.51
Protection Profile evaluation
assessment of a PP against defined criteria
3.1.52
Protection Profile
implementation-independent statement of security needs for a TOE type
3.1.53
prove
show correspondence by formal analysis in its mathematical sense
NOTE It is completely rigorous 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.
3.1.54
refinement
addition of details to a component
3.1.55
role
predefined set of rules establishing the allowed interactions between a user and the TOE
3.1.56
secret
information that must be known only to authorised users and/or the TSF in order to enforce a specific SFP
3.1.57
secure state
state in which the TSF data are consistent and the TSF continues correct enforcement of the SFRs
6 © ISO/IEC 2009 – All rights reserved

3.1.58
security attribute
property of subjects, users (including external IT products), objects, information, sessions and/or resources
that is used in defining the SFRs and whose values are used in enforcing the SFRs
3.1.59
security function policy
set of rules describing specific security behaviour enforced by the TSF and expressible as a set of SFRs
3.1.60
security objective
statement of an intent to counter identified threats and/or satisfy identified organization security policies and/or
assumptions
3.1.61
security problem
statement which in a formal manner defines the nature and scope of the security that the TOE is intended to
address
NOTE This statement consists of a combination of:
⎯ threats to be countered by the TOE,
⎯ the OSPs enforced by the TOE, and
⎯ the assumptions that are upheld for the TOE and its operational environment.
3.1.62
security requirement
requirement, stated in a standardized language, which is meant to contribute to achieving the security
objectives for a TOE
3.1.63
Security Target
ST
implementation-dependent statement of security needs for a specific identified TOE
3.1.64
selection
specification of one or more items from a list in a component
3.1.65
semiformal
expressed in a restricted syntax language with defined semantics
3.1.66
specify
provide specific details about an entity in a rigorous and precise manner
3.1.67
strict conformance
hierarchical relationship between a PP and an ST where all the requirements in the PP also exist in the ST
NOTE This relation can be roughly defined as “the ST shall contain all statements that are in the PP, but may contain
more”. Strict conformance is expected to be used for stringent requirements that are to be adhered to in a single manner.
3.1.68
ST evaluation
assessment of an ST against defined criteria
© ISO/IEC 2009 – All rights reserved 7

3.1.69
subject
active entity in the TOE that performs operations on objects
3.1.70
TOE
target of evaluation
set of software, firmware and/or hardware possibly accompanied by guidance
3.1.71
threat agent
entity that can adversely act on assets
3.1.72
TOE evaluation
assessment of a TOE against defined criteria
3.1.73
TOE resource
anything useable or consumable in the TOE
3.1.74
TOE security functionality
combined functionality of all hardware, software, and firmware of a TOE that must be relied upon for the
correct enforcement of the SFRs
3.1.75
trace, verb
perform an informal correspondence analysis between two entities with only a minimal level of rigour
3.1.76
transfers outside of the TOE
TSF mediated communication of data to entities not under the control of the TSF
3.1.77
translation
describes the process of describing security requirements in a standardized language
NOTE Use of the term translation in this context is not literal and does not imply that every SFR expressed in
standardized language can also be translated back to the security objectives.
3.1.78
trusted channel
a means by which a TSF and another trusted IT product can communicate with necessary confidence
3.1.79
trusted IT product
IT product, other than the TOE, which has its security functional requirements administratively coordinated
with the TOE and which is assumed to enforce its security functional requirements correctly
NOTE An example of a trusted IT product would be one that has been separately evaluated.
3.1.80
trusted path
means by which a user and a TSF can communicate with the necessary confidence
3.1.81
TSF data
data for the operation of the TOE upon which the enforcement of the SFR relies
8 © ISO/IEC 2009 – All rights reserved

3.1.82
TSF interface
means by which external entities (or subjects in the TOE but outside of the TSF) supply data to the TSF,
receive data from the TSF and invoke services from the TSF
3.1.83
user data
data for the user, that does not affect the operation of the TSF
3.1.84
verify
rigorously review in detail with an independent determination of sufficiency
NOTE Also see “confirm” (3.1.14). The term “verify” has more rigorous connotations. It is used in the context of
evaluator actions where an independent effort is required of the evaluator.
3.2 Terms and definitions related to the ADV class
NOTE The following terms are used in the requirements for software internal structuring. Some of these are derived
from the IEEE Std 610.12-1990, Standard glossary of software engineering terminology, Institute of Electrical and
Electronics Engineers.
3.2.1
administrator
entity that has a level of trust with respect to all policies implemented by the TSF
NOTE Not all PPs or STs assume the same level of trust for administrators. Typically administrators are assumed to
adhere at all times to the policies in the ST of the TOE. Some of these policies may be related to the functionality of the
TOE, others may be related to the operational environment.
3.2.2
call tree
identifies the modules in a system in diagrammatic form showing which modules call one another
NOTE Adapted from IEEE Std 610.12-1990.
3.2.3
cohesion
module strength
manner and degree to which the tasks performed by a single software module are related to one another
[IEEE Std 610.12-1990]
NOTE Types of cohesion include coincidental, communicational, functional, logical, sequential, and temporal. These
types of cohesion are described by the relevant term entry.
3.2.4
coincidental cohesion
module with the characteristic of performing unrelated, or loosely related, activities
[IEEE Std 610.12-1990]
NOTE See also cohesion (3.2.3).
© ISO/IEC 2009 – All rights reserved 9

3.2.5
communicational cohesion
module containing functions that produce output for, or use output from, other functions within the module
[IEEE Std 610.12-1990]
NOTE 1 See also cohesion (3.2.3).
NOTE 2 An example of a communicationally cohesive module is an access check module that includes mandatory,
discretionary, and capability checks.
3.2.6
complexity
measure of how difficult software is to understand, and thus to analyse, test, and maintain
[IEEE Std 610.12-1990]
NOTE Reducing complexity is the ultimate goal for using modular decomposition, layering and minimization.
Controlling coupling and cohesion contributes significantly to this goal.
A good deal of effort in the software engineering field has been expended in attempting to develop metrics to measure the
complexity of source code. Most of these metrics use easily computed properties of the source code, such as the number
of operators and operands, the complexity of the control flow graph (cyclomatic complexity), the number of lines of source
code, the ratio of comments to executable code, and similar measures. Coding standards have been found to be a useful
tool in generating code that is more readily understood.
The TSF internals (ADV_INT) family calls for a complexity analysis in all components. It is expected that the developer will
provide support for the claims that there has been a sufficient reduction in complexity. This support could include the
developer's programming standards, and an indication that all modules meet the standard (or that there are some
exceptions that are justified by software engineering arguments). It could include the results of tools used to measure
some of the properties of the source code, or it could include other support that the developer finds appropriate.
3.2.7
coupling
manner and degree of interdependence between software modules
[IEEE Std 610.12-1990]
NOTE Types of coupling include call, common and content coupling. These are characterised below.
3.2.8
call coupling
relationship between two modules communicating strictly through their documented function calls
NOTE Examples of call coupling are data, stamp and control.
3.2.9
call coupling
〈data〉 relationship between two modules communicating strictly through the use of call parameters that
represent single data items
NOTE See also call coupling (3.2.8).
3.2.10
call coupling
〈stamp〉 relationship between two modules communicating through the use of call parameters that comprise
multiple fields or that have meaningful internal structures
NOTE See also call coupling (3.2.8).
10 © ISO/IEC 2009 – All rights reserved

3.2.11
call coupling
〈control〉 relationship between two modules if one passes information that is intended to influence the internal
logic of the other
NOTE See also call coupling (3.2.8).
3.2.12
common coupling
relationship between two modules sharing a common data area or other common system resource
NOTE Global variables indicate that modules using those global variables are common coupled. Common coupling
through global variables is generally allowed, but only to a limited degree.
For example, variables that are placed into a global area, but are used by only a single module, are inappropriately placed,
and should be removed. Other factors that need to be considered in assessing the suitability of global variables are:
The number of modules that modify a global variable: In general, only a single module should be allocated the
responsibility for controlling the contents of a global variable, but there may be situations in which a second module may
share that responsibility; in such a case, sufficient justification must be provided. It is unacceptable for this responsibility to
be shared by more than two modules. (In making this assessment, care should be given to determining the module
actually responsible for the contents of the variable; for example, if a single routine is used to modify the variable, but that
routine simply performs the modification requested by its caller, it is the calling module that is responsible, and there may
be more than one such module). Further, as part of the complexity determination, if two modules are responsible for the
contents of a global variable, there should be clear indications of how the modifications are coordinated between them.
The number of modules that reference a global variable: Although there is generally no limit on the number of modules
that reference a global variable, cases in which many modules make such a reference should be examined for validity and
necessity.
3.2.13
content coupling
relationship between two modules where one makes direct reference to the internals of the other
NOTE Examples include modifying code of, or referencing labels internal to, the other module. The result is that
some or all of the content of one module are effectively included in the other. Content coupling can be thought of as using
unadvertised module interfaces; this is in contrast to call coupling, which uses only advertised module interfaces.
3.2.14
domain separation
security architecture property whereby the TSF defines separate security domains for each user and for the
TSF and ensures that no user process can affect the contents of a security domain of another user or of
the TSF
3.2.15
functional cohesion
functional property of a module which performs activities related to a single purpose
[IEEE Std 610.12-1990]
NOTE A functionally cohesive module transforms a single type of input into a single type of output, such as a stack
manager or a queue manager. See also cohesion (3.2.3).
3.2.16
interaction
general communication-based activity between entities
3.2.17
interface
means of interaction with a component or module
© ISO/IEC 2009 – All rights reserved 11

3.2.18
layering
design technique where separate groups of modules (the layers) are hierarchically organized to have separate
responsibilities such that one layer depends only on layers below it in the hierarchy for services, and provides
its services only to the layers above it
NOTE Strict layering adds the constraint that each layer receives services only from the layer immediately beneath it,
and provides services only to the layer immediately above it.
3.2.19
logical cohesion
procedural cohesion
characteristics of a module performing similar activities on different data structures
NOTE A module exhibits logical cohesion if its functions perform related, but different, operations on different inputs.
See also cohesion (3.2.3).
3.2.20
modular decomposition
process of breaking a system into components to facilitate design, development and evaluation
[IEEE Std 610.12-1990]
3.2.21
non-bypassability
〈of the TSF〉 security architecture property whereby all SFR-related actions are mediated by the TSF
3.2.22
security domain
collection of resources to which an active entity has access privileges
3.2.23
sequential cohesion
module containing functions each of whose output is input for the following function in the module
[IEEE Std 610.12-1990]
NOTE An example of a sequentially cohesive module is one that contains the functions to write audit records and to
maintain a running count of the accumulated number of audit violations of a specified type.
3.2.24
software engineering
application of a systematic, disciplined, quantifiable approach to the development and maintenance of
software; that is, the application of engineering to software
[IEEE Std 610.12-1990]
NOTE As with engineering practices in general, some amount of judgement must be used in applying engineering
principles. Many factors affect choices, not just the application of measures of modular decomposition, layering, and
minimization. For example, a developer may design a system with future applications in mind that will not be implemented
initially. The developer may choose to include some logic to handle these future applications without fully implementing
them; further, the developer may include some calls to as-yet unimplemented modules, leaving call stubs. The developer's
justification for such deviations from well-structured programs will have to be assessed using judgement, as well as the
application of good software engineering discipline.
12 © ISO/IEC 2009 – All rights reserved

3.2.25
temporal cohesion
characteristics of a module containing functions that need to be executed at about the same time
NOTE 1 Adapted from [IEEE Std 610.12-1990].
NOTE 2 Examples of temporally cohesive modules include initialization, recovery, and shutdown modules.
3.2.26
TSF self-protection
security architecture property whereby the TSF cannot be corrupted by non-TSF code or entities
3.3 Terms and definitions related to the AGD class
3.3.1
installation
procedure performed by a human user embedding the TOE in its operational environment and putting it into
an operational state
NOTE This operation is normally performed only once, after receipt and acceptance of the TOE. The TOE is
expected to be progressed to a configuration allowed by the ST. If similar processes have to be performed by the
developer they are denoted as “generation” throughout ALC: Life-cycle support. If the TOE requires an initial start-up that
does not need to be repeated regularly, this process would be classified as installation.
3.3.2
operation
usage phase of the TOE including “normal usage”, administration
...

INTERNATIONAL ISO/IEC
STANDARD 15408-1
Third edition
2009-12-15
Corrected version
2014-01-15
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
©
ISO/IEC 2009
©  ISO/IEC 2009
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 either ISO at the address below or
ISO's member body in the country of the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail [e-mail]
Web www.iso.org
Published in Switzerland
ii © ISO/IEC 2009 – All rights reserved

Contents Page
Foreword . v
Introduction . vi
2 Normative references . 1
3 Terms and definitions . 1
3.1 Terms and definitions common in ISO/IEC 15408 . 2
3.2 Terms and definitions related to the ADV class . 9
3.3 Terms and definitions related to the AGD class . 13
3.4 Terms and definitions related to the ALC class . 13
3.5 Terms and definitions related to the AVA class . 17
3.6 Terms and definitions related to the ACO class . 17
4 Abbreviated terms . 18
5 Overview. 19
5.1 General . 19
5.2 The TOE . 19
5.3 Target audience of ISO/IEC 15408 . 20
5.4 The different parts of ISO/IEC 15408 . 21
5.5 Evaluation context . 22
6 General model . 22
6.1 Introduction to the general model . 22
6.2 Assets and countermeasures . 23
6.3 Evaluation . 27
7 Tailoring Security Requirements . 27
7.1 Operations . 27
7.2 Dependencies between components . 30
7.3 Extended components . 30
8 Protection Profiles and Packages . 31
8.1 Introduction . 31
8.2 Packages . 31
8.3 Protection Profiles. 31
8.4 Using PPs and packages . 34
8.5 Using Multiple Protection Profiles . 34
9 Evaluation results . 34
9.1 Introduction . 34
9.2 Results of a PP evaluation . 35
9.3 Results of an ST/TOE evaluation . 35
9.4 Conformance claim . 35
© ISO/IEC 2009 – All rights reserved iii

9.5 Use of ST/TOE evaluation results . 36
Annex A (informative) Specification of Security Targets . 38
Annex B (informative) Specification of Protection Profiles . 54
Annex C (informative) Guidance for Operations . 59
Annex D (informative) PP conformance . 62
Bibliography . 64

iv © ISO/IEC 2009 – All rights reserved

Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are members of
ISO or IEC participate in the development of International Standards through technical committees
established by the respective organization to deal with particular fields of technical activity. ISO and IEC
technical committees collaborate in fields of mutual interest. Other international organizations, governmental
and non-governmental, in liaison with ISO and IEC, also take part in the work. In the field of information
technology, ISO and IEC have established a joint technical committee, ISO/IEC JTC 1.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of the joint technical committee is to prepare International Standards. Draft International
Standards adopted by the joint technical committee are circulated to national bodies for voting. Publication as
an International Standard requires approval by at least 75 % of the national bodies casting a vote.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. ISO and IEC shall not be held responsible for identifying any or all such patent rights.
ISO/IEC 15408-1 was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 27, IT Security techniques. The identical text of ISO/IEC 15408 is published by the
Common Criteria Project Sponsoring Organisations as Common Criteria for Information Technology Security
Evaluation. The common XML source for both publications can be found at
http://www.commoncriteriaportal.org/cc/
This third edition cancels and replaces the second edition (ISO/IEC 15408-1:2005), which has been
technically revised.
ISO/IEC 15408 consists of the following parts, under the general title Information technology — Security
techniques — Evaluation criteria for IT security:
 Part 1: Introduction and general model
 Part 2: Security functional components
 Part 3: Security assurance components
This corrected version of ISO/IEC 15408-1:2009 incorporates miscellaneous editorial corrections related to
the following:
 terminology: correction for the terms "security problem" and "security domains";
 clause 8.3: explanation of strict conformance, removal of former Figure 4.
© ISO/IEC 2009 – All rights reserved v

Introduction
ISO/IEC 15408 permits comparability between the results of independent security evaluations. ISO/IEC 15408
does so by providing a common set of requirements for the security functionality of IT products and for
assurance measures applied to these IT products during a security evaluation. These IT products may be
implemented in hardware, firmware or software.
The evaluation process establishes a level of confidence that the security functionality of these IT products
and the assurance measures applied to these IT products meet these requirements. The evaluation results
may help consumers to determine whether these IT products fulfil their security needs.
ISO/IEC 15408 is useful as a guide for the development, evaluation and/or procurement of IT products with
security functionality.
ISO/IEC 15408 is intentionally flexible, enabling a range of evaluation methods to be applied to a range of
security properties of a range of IT products. Therefore users of the standard are cautioned to exercise care
that this flexibility is not misused. For example, using ISO/IEC 15408 in conjunction with unsuitable evaluation
methods, irrelevant security properties, or inappropriate IT products, may result in meaningless evaluation
results.
Consequently, the fact that an IT product has been evaluated has meaning only in the context of the security
properties that were evaluated and the evaluation methods that were used. Evaluation authorities are advised
to carefully check the products, properties and methods to determine that an evaluation will provide
meaningful results. Additionally, purchasers of evaluated products are advised to carefully consider this
context to determine whether the evaluated product is useful and applicable to their specific situation and
needs.
ISO/IEC 15408 addresses protection of assets 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. ISO/IEC 15408 may also be applicable to aspects of IT security outside
of these three. ISO/IEC 15408 is applicable to risks arising from human activities (malicious or otherwise) and
to risks arising from non-human activities. Apart from IT security, ISO/IEC 15408 may be applied in other
areas of IT, but makes no claim of applicability in these areas.
Certain topics, because they involve specialised techniques or because they are somewhat peripheral to IT
security, are considered to be outside the scope of ISO/IEC 15408. Some of these are identified below.
a) ISO/IEC 15408 does not contain security evaluation criteria pertaining to administrative security
measures not related directly to the IT security functionality. However, it is recognised that significant
security can often be achieved through or supported by administrative measures such as organisational,
personnel, physical, and procedural controls.
b) The evaluation of some 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.
c) ISO/IEC 15408 does not address the evaluation methodology under which the criteria should be applied.
This methodology is given in ISO/IEC 18045.
d) ISO/IEC 15408 does not address the administrative and legal framework under which the criteria may be
applied by evaluation authorities. However, it is expected that ISO/IEC 15408 will be used for evaluation
purposes in the context of such a framework.
vi © ISO/IEC 2009 – All rights reserved

e) The procedures for use of evaluation results in accreditation are outside the scope of ISO/IEC 15408.
Accreditation is the administrative process whereby authority is granted for the operation of an IT product
(or collection thereof) in its full operational environment including all of its non-IT parts. The results of the
evaluation process are an input to the accreditation process. However, as other techniques are more
appropriate for the assessments of non-IT related properties and their relationship to the IT security parts,
accreditors should make separate provisions for those aspects.
f) The subject of criteria for the assessment of the inherent qualities of cryptographic algorithms is not
covered in ISO/IEC 15408. Should independent assessment of mathematical properties of cryptography
be required, the evaluation scheme under which ISO/IEC 15408 is applied must make provision for such
assessments.
ISO terminology, such as "can", "informative", "may", "normative", "shall" and "should" used throughout the
document are defined in the ISO/IEC Directives, Part 2. Note that the term "should" has an additional meaning
applicable when using this standard. See the note below. The following definition is given for the use of
“should” in ISO/IEC 15408.
should
within normative text, “should” indicates “that among several possibilities one is recommended as particularly
suitable, without mentioning or excluding others, or that a certain course of action is preferred but not
necessarily required.” (ISO/IEC Directives, Part 2).
NOTE ISO/IEC 15408 interprets “not necessarily required” to mean that the choice of another possibility requires a
justification of why the preferred option was not chosen.

© ISO/IEC 2009 – All rights reserved vii

INTERNATIONAL STANDARD ISO/IEC 15408-1:2009(E)

Information technology — Security techniques — Evaluation
criteria for IT security —
Part 1:
Introduction and general model
1 Scope
This part of ISO/IEC 15408 establishes the general concepts and principles of IT security evaluation and
specifies the general model of evaluation given by various parts of the standard which in its entirety is meant
to be used as the basis for evaluation of security properties of IT products.
Part one provides an overview of all parts of ISO/IEC 15408 standard. It describes the various parts of the
standard; defines the terms and abbreviations to be used in all parts of the standard; establishes the core
concept of a Target of Evaluation (TOE); the evaluation context and describes the audience to which the
evaluation criteria are addressed. An introduction to the basic security concepts necessary for evaluation of IT
products is given.
It defines the various operations by which the functional and assurance components given in ISO/IEC 15408-2
and ISO/IEC 15408-3 may be tailored through the use of permitted operations.
The key concepts of protection profiles (PP), packages of security requirements and the topic of conformance
are specified and the consequences of evaluation, evaluation results are described. This part of ISO/IEC
15408 gives guidelines for the specification of Security Targets (ST) and provides a description of the
organization of components throughout the model. General information about the evaluation methodology are
given in ISO/IEC 18045 and the scope of evaluation schemes is provided.
2 Normative references
The following referenced documents are indispensable for the application of ISO/IEC 15408 part 1. For dated
references, only the edition cited applies. For undated references, the latest edition of the referenced
document (including any amendments) applies.
ISO/IEC 15408-2, Information technology — Security techniques — Evaluation criteria for IT security —
Part 2: Security functional components
ISO/IEC 15408-3, Information technology — Security techniques — Evaluation criteria for IT security —
Part 3: Security assurance components
ISO/IEC 18045, Information technology — Security techniques — Methodology for IT security evaluation
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
NOTE This clause contains only those terms which are used in a specialized way throughout ISO/IEC 15408. Some
combinations of common terms used in ISO/IEC 15408, while not meriting inclusion in this clause, are explained for clarity
in the context where they are used.
© ISO/IEC 2009 – All rights reserved 1

3.1 Terms and definitions common in ISO/IEC 15408
3.1.1
adverse actions
actions performed by a threat agent on an asset
3.1.2
assets
entities that the owner of the TOE presumably places value upon
3.1.3
assignment
specification of an identified parameter in a component (of ISO/IEC 15408) or requirement
3.1.4
assurance
grounds for confidence that a TOE meets the SFRs
3.1.5
attack potential
measure of the effort to be expended in attacking a TOE, expressed in terms of an attacker's expertise,
resources and motivation
3.1.6
augmentation
addition of one or more requirement(s) to a package
3.1.7
authentication data
information used to verify the claimed identity of a user
3.1.8
authorised user
TOE user who may, in accordance with the SFRs, perform an operation
3.1.9
class
set of ISO/IEC 15408 families that share a common focus
3.1.10
coherent
logically ordered and having discernible meaning
NOTE 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.
3.1.11
complete
property where all necessary parts of an entity have been provided
NOTE 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.
3.1.12
component
smallest selectable set of elements on which requirements may be based
2 © ISO/IEC 2009 – All rights reserved

3.1.13
composed assurance package
assurance package consisting of requirements drawn from ISO/IEC 15408-3 (predominately from the ACO
class), representing a point on ISO/IEC 15408 predefined composition assurance scale
3.1.14
confirm
declare that something has been reviewed in detail with an independent determination of sufficiency
NOTE The level of rigour required depends on the nature of the subject matter. This term is only applied to evaluator
actions.
3.1.15
connectivity
property of the TOE allowing interaction with IT entities external to the TOE
NOTE This includes exchange of data by wire or by wireless means, over any distance in any environment or
configuration.
3.1.16
consistent
relationship between two or more entities such that there are no apparent contradictions between these
entities
3.1.17
counter, verb
meet an attack where the impact of a particular threat is mitigated but not necessarily eradicated
3.1.18
demonstrable conformance
relation between an ST and a PP, where the ST provides a solution which solves the generic security problem
in the PP
NOTE The PP and the ST may contain entirely different statements that discuss different entities, use different
concepts etc. Demonstrable conformance is also suitable for a TOE type where several similar PPs already exist, thus
allowing the ST author to claim conformance to these PPs simultaneously, thereby saving work.
3.1.19
demonstrate
provide a conclusion gained by an analysis which is less rigorous than a “proof”
3.1.20
dependency
relationship between components such that if a requirement based on the depending component is included in
a PP, ST or package, a requirement based on the component that is depended upon must normally also be
included in the PP, ST or package
3.1.21
describe
provide specific details of an entity
3.1.22
determine
affirm a particular conclusion based on independent analysis with the objective of reaching a particular
conclusion
NOTE The usage of this term implies a truly independent analysis, usually in the absence of any previous analysis
having been performed. Compare with the terms “confirm” or “verify” which imply that an analysis has already been
performed which needs to be reviewed
© ISO/IEC 2009 – All rights reserved 3

3.1.23
development environment
environment in which the TOE is developed
3.1.24
element
indivisible statement of a security need
3.1.25
ensure
guarantee a strong causal relationship between an action and its consequences
NOTE When this term is preceded by the word “help” it indicates that the consequence is not fully certain, on the
basis of that action alone.
3.1.26
evaluation
assessment of a PP, an ST or a TOE, against defined criteria
3.1.27
evaluation assurance level
set of assurance requirements drawn from ISO/IEC 15408-3, representing a point on the ISO/IEC 15408
predefined assurance scale, that form an assurance package
3.1.28
evaluation authority
body that sets the standards and monitors the quality of evaluations conducted by bodies within a specific
community and implements ISO/IEC 15408 for that community by means of an evaluation scheme
3.1.29
evaluation scheme
administrative and regulatory framework under which ISO/IEC 15408 is applied by an evaluation authority
within a specific community
3.1.30
exhaustive
characteristic of a methodical approach taken to perform an analysis or activity according to an unambiguous
plan
NOTE This term is used in ISO/IEC 15408 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.
3.1.31
explain
give argument accounting for the reason for taking a course of action
NOTE 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.
3.1.32
extension
addition to an ST or PP of functional requirements not contained in ISO/IEC 15408-2 and/or assurance
requirements not contained in ISO/IEC 15408-3
3.1.33
external entity
human or IT entity possibly interacting with the TOE from outside of the TOE boundary
NOTE An external entity can also be referred to as a user.
4 © ISO/IEC 2009 – All rights reserved

3.1.34
family
set of components that share a similar goal but differ in emphasis or rigour
3.1.35
formal
expressed in a restricted syntax language with defined semantics based on well-established mathematical
concepts
3.1.36
guidance documentation
documentation that describes the delivery, preparation, operation, management and/or use of the TOE
3.1.37
identity
representation uniquely identifying entities (e.g. a user, a process or a disk) within the context of the TOE
NOTE An example of such a representation is a string. For a human user, the representation can be the full or
abbreviated name or a (still unique) pseudonym.
3.1.38
informal
expressed in natural language
3.1.39
inter TSF transfers
communicating data between the TOE and the security functionality of other trusted IT products
3.1.40
internal communication channel
communication channel between separated parts of the TOE
3.1.41
internal TOE transfer
communicating data between separated parts of the TOE
3.1.42
internally consistent
no apparent contradictions exist between any aspects of an entity
NOTE In terms of documentation, this means that there can be no statements within the documentation that can be
taken to contradict each other.
3.1.43
iteration
use of the same component to express two or more distinct requirements
3.1.44
justification
analysis leading to a conclusion
NOTE “Justification” 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.
3.1.45
object
passive entity in the TOE, that contains or receives information, and upon which subjects perform operations
© ISO/IEC 2009 – All rights reserved 5

3.1.46
operation
〈on a component of ISO/IEC 15408〉 modification or repetition of a component
NOTE Allowed operations on components are assignment, iteration, refinement and selection.
3.1.47
operation
〈on an object〉 specific type of action performed by a subject on an object
3.1.48
operational environment
environment in which the TOE is operated
3.1.49
organizational security policy
set of security rules, procedures, or guidelines for an organization
NOTE A policy may pertain to a specific operational environment.
3.1.50
package
named set of either security functional or security assurance requirements
NOTE An example of a package is “EAL 3”.
3.1.51
Protection Profile evaluation
assessment of a PP against defined criteria
3.1.52
Protection Profile
implementation-independent statement of security needs for a TOE type
3.1.53
prove
show correspondence by formal analysis in its mathematical sense
NOTE It is completely rigorous 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.
3.1.54
refinement
addition of details to a component
3.1.55
role
predefined set of rules establishing the allowed interactions between a user and the TOE
3.1.56
secret
information that must be known only to authorised users and/or the TSF in order to enforce a specific SFP
3.1.57
secure state
state in which the TSF data are consistent and the TSF continues correct enforcement of the SFRs
6 © ISO/IEC 2009 – All rights reserved

3.1.58
security attribute
property of subjects, users (including external IT products), objects, information, sessions and/or resources
that is used in defining the SFRs and whose values are used in enforcing the SFRs
3.1.59
security function policy
set of rules describing specific security behaviour enforced by the TSF and expressible as a set of SFRs
3.1.60
security objective
statement of an intent to counter identified threats and/or satisfy identified organization security policies and/or
assumptions
3.1.61
security problem
statement which in a formal manner defines the nature and scope of the security that the TOE is intended to
address
NOTE This statement consists of a combination of:
 threats to be countered by the TOE and its operational environment,
 the OSPs enforced by the TOE and its operational environment, and
 the assumptions that are upheld for the operational environment of the TOE.
3.1.62
security requirement
requirement, stated in a standardised language, which is meant to contribute to achieving the security
objectives for a TOE
3.1.63
Security Target
implementation-dependent statement of security needs for a specific identified TOE
3.1.64
selection
specification of one or more items from a list in a component
3.1.65
semiformal
expressed in a restricted syntax language with defined semantics
3.1.66
specify
provide specific details about an entity in a rigorous and precise manner
3.1.67
strict conformance
hierarchical relationship between a PP and an ST where all the requirements in the PP also exist in the ST
NOTE This relation can be roughly defined as “the ST shall contain all statements that are in the PP, but may contain
more”. Strict conformance is expected to be used for stringent requirements that are to be adhered to in a single manner.
3.1.68
ST evaluation
assessment of an ST against defined criteria
© ISO/IEC 2009 – All rights reserved 7

3.1.69
subject
active entity in the TOE that performs operations on objects
3.1.70
target of evaluation
set of software, firmware and/or hardware possibly accompanied by guidance
3.1.71
threat agent
entity that can adversely act on assets
3.1.72
TOE evaluation
assessment of a TOE against defined criteria
3.1.73
TOE resource
anything useable or consumable in the TOE
3.1.74
TOE security functionality
combined functionality of all hardware, software, and firmware of a TOE that must be relied upon for the
correct enforcement of the SFRs
3.1.75
trace, verb
perform an informal correspondence analysis between two entities with only a minimal level of rigour
3.1.76
transfers outside of the TOE
TSF mediated communication of data to entities not under the control of the TSF
3.1.77
translation
describes the process of describing security requirements in a standardised language.
NOTE Use of the term translation in this context is not literal and does not imply that every SFR expressed in
standardised language can also be translated back to the security objectives.
3.1.78
trusted channel
a means by which a TSF and another trusted IT product can communicate with necessary confidence
3.1.79
trusted IT product
IT product, other than the TOE, which has its security functional requirements administratively coordinated
with the TOE and which is assumed to enforce its security functional requirements correctly
NOTE An example of a trusted IT product would be one that has been separately evaluated.
3.1.80
trusted path
means by which a user and a TSF can communicate with the necessary confidence
3.1.81
TSF data
data for the operation of the TOE upon which the enforcement of the SFR relies
8 © ISO/IEC 2009 – All rights reserved

3.1.82
TSF interface
means by which external entities (or subjects in the TOE but outside of the TSF) supply data to the TSF,
receive data from the TSF and invoke services from the TSF
3.1.83
user data
data for the user, that does not affect the operation of the TSF
3.1.84
verify
rigorously review in detail with an independent determination of sufficiency
NOTE Also see “confirm”. This term has more rigorous connotations. The term “verify” is used in the context of
evaluator actions where an independent effort is required of the evaluator.
3.2 Terms and definitions related to the ADV class
NOTE The following terms are used in the requirements for software internal structuring. Some of these are derived
from the IEEE Std 610.12-1990, Standard glossary of software engineering terminology, Institute of Electrical and
Electronics Engineers.
3.2.1
administrator
entity that has a level of trust with respect to all policies implemented by the TSF
NOTE Not all PPs or STs assume the same level of trust for administrators. Typically administrators are assumed to
adhere at all times to the policies in the ST of the TOE. Some of these policies may be related to the functionality of the
TOE, others may be related to the operational environment.
3.2.2
call tree
identifies the modules in a system in diagrammatic form showing which modules call one another
NOTE Adapted from IEEE Std 610.12-1990.
3.2.3
cohesion
module strength
manner and degree to which the tasks performed by a single software module are related to one another
[IEEE Std 610.12-1990]
NOTE Types of cohesion include coincidental, communicational, functional, logical, sequential, and temporal. These
types of cohesion are described by the relevant term entry.
3.2.4
coincidental cohesion
module with the characteristic of performing unrelated, or loosely related, activities
[IEEE Std 610.12-1990]
NOTE See also cohesion (3.2.3).
© ISO/IEC 2009 – All rights reserved 9

3.2.5
communicational cohesion
module containing functions that produce output for, or use output from, other functions within the module
[IEEE Std 610.12-1990]
NOTE 1 See also cohesion (3.2.3).
NOTE 2 An example of a communicationally cohesive module is an access check module that includes mandatory,
discretionary, and capability checks.
3.2.6
complexity
measure of how difficult software is to understand, and thus to analyse, test, and maintain
[IEEE Std 610.12-1990]
NOTE Reducing complexity is the ultimate goal for using modular decomposition, layering and minimization.
Controlling coupling and cohesion contributes significantly to this goal.
A good deal of effort in the software engineering field has been expended in attempting to develop metrics to measure the
complexity of source code. Most of these metrics use easily computed properties of the source code, such as the number
of operators and operands, the complexity of the control flow graph (cyclomatic complexity), the number of lines of source
code, the ratio of comments to executable code, and similar measures. Coding standards have been found to be a useful
tool in generating code that is more readily understood.
The TSF internals (ADV_INT) family calls for a complexity analysis in all components. It is expected that the developer will
provide support for the claims that there has been a sufficient reduction in complexity. This support could include the
developer's programming standards, and an indication that all modules meet the standard (or that there are some
exceptions that are justified by software engineering arguments). It could include the results of tools used to measure
some of the properties of the source code, or it could include other support that the developer finds appropriate.
3.2.7
coupling
manner and degree of interdependence between software modules
[IEEE Std 610.12-1990]
NOTE Types of coupling include call, common and content coupling. These are characterised below.
3.2.8
call coupling
relationship between two modules communicating strictly through their documented function calls
NOTE Examples of call coupling are data, stamp and control.
3.2.9
call coupling
〈data〉 relationship between two modules communicating strictly through the use of call parameters that
represent single data items
NOTE See also call coupling (3.2.8).
3.2.10
call coupling
〈stamp〉 relationship between two modules communicating through the use of call parameters that comprise
multiple fields or that have meaningful internal structures
NOTE See also call coupling (3.2.8).
10 © ISO/IEC 2009 – All rights reserved

3.2.11
call coupling
〈control〉 relationship between two modules if one passes information that is intended to influence the internal
logic of the other
NOTE See also call coupling (3.2.8).
3.2.12
common coupling
relationship between two modules sharing a common data area or other common system resource
NOTE Global variables indicate that modules using those global variables are common coupled. Common coupling
through global variables is generally allowed, but only to a limited degree.
For example, variables that are placed into a global area, but are used by only a single module, are inappropriately placed,
and should be removed. Other factors that need to be considered in assessing the suitability of global variables are:
The number of modules that modify a global variable: In general, only a single module should be allocated the
responsibility for controlling the contents of a global variable, but there may be situations in which a second module may
share that responsibility; in such a case, sufficient justification must be provided. It is unacceptable for this responsibility to
be shared by more than two modules. (In making this assessment, care should be given to determining the module
actually responsible for the contents of the variable; for example, if a single routine is used to modify the variable, but that
routine simply performs the modification requested by its caller, it is the calling module that is responsible, and there may
be more than one such module). Further, as part of the complexity determination, if two modules are responsible for the
contents of a global variable, there should be clear indications of how the modifications are coordinated between them.
The number of modules that reference a global variable: Although there is generally no limit on the number of modules
that reference a global variable, cases in which many modules make such a reference should be examined for validity and
necessity.
3.2.13
content coupling
relationship between two modules where one makes direct reference to the internals of the other
NOTE Examples include modifying code of, or referencing labels internal to, the other module. The result is that
some or all of the content of one module are effectively included in the other. Content coupling can be thought of as using
unadvertised module interfaces; this is in contrast to call coupling, which uses only advertised module interfaces.
3.2.14
domain separation
security architecture property whereby the TSF defines separate security domains for each user and for the
TSF and ensures that no user process can affect the contents of a security domain of another user or of
the TSF
3.2.15
functional cohesion
functional property of a module which performs activities related to a single purpose
[IEEE Std 610.12-1990]
NOTE A functionally cohesive module transforms a single type of input into a single type of output, such as a stack
manager or a queue manager. See also cohesion (3.2.3).
3.2.16
interaction
general communication-based activity between entities
3.2.17
interface
means of interaction with a component or module
© ISO/IEC 2009 – All rights reserved 11

3.2.18
layering
design technique where separate groups of modules (the layers) are hierarchically organised to have separate
responsibilities such that one layer depends only on layers below it in the hierarchy for services, and provides
its services only to the layers above it
NOTE Strict layering adds the constraint that each layer receives services only from the layer immediately beneath it,
and provides services only to the layer immediately above it.
3.2.19
logical cohesion
procedural cohesion
characteristics of a module performing similar activities on different data structures
NOTE A module exhibits logical cohesion if its functions perform related, but different, operations on different inputs.
See also “cohesion”.
3.2.20
modular decomposition
process of breaking a system into components to facilitate design, development and evaluation
[IEEE Std 610.12-1990]
3.2.21
non-bypassability
〈of the TSF〉 security architecture property whereby all SFR-related actions are mediated by the TSF
3.2.22
security domains
environments provided by the TSF for the use by untrusted entities in such a way that these environments are
isolated and protected from each other
3.2.23
sequential cohesion
module containing functions each of whose output is input for the following function in the module
[IEEE Std 610.12-1990]
NOTE An example of a sequentially cohesive module is one that contains the functions to write audit records and to
maintain a running count of the accumulated number of audit violations of a specified type.
3.2.24
software engineering
application of a systematic, disciplined, quantifiable approach to the development and maintenance of
software; that is, the application of engineering to software
[IEEE Std 610.12-1990]
NOTE As with engineering practices in general, some amount of judgement must be used in applying engineering
principles. Many factors affect choices, not just the application of measures of modular decomposition, layering, and
minimization. For example, a developer may design a system with future applications in mind that will not be implemented
initially. The developer may choose to include some logic to handle these future applications without fully implementing
them; further, the developer may include some calls to as-yet unimplemented modules, leaving call stubs. The developer's
justification for such deviations from well-structured programs will have to be assessed using judgement, as well as the
application of good software engineering discipline.
12 © ISO/IEC 2009 – All rights reserved

3.2.25
temporal cohesion
characteristics of a module containing functions that need to be executed at about the same time
NOTE 1 Adapted from [IEEE Std 610.12-1990].
NOTE 2 Examples of temporally cohesive modules include initialization, recovery, and shutdown modules.
3.2.26
TSF self-protection
security architecture property whereby the TSF cannot be corrupted by non-TSF code or entities
3.3 Terms and definitions related to the AGD class
3.3.1
installation
procedure performed by a human user embedding the TOE in its operational environment and putting it into
an operational state
NOTE This operation is performed normally only once, after receipt and acceptance of the TOE. The TOE is expected
to be progressed to a configuration allowed by the ST. If similar processes have to be performed by the developer they are
denoted as “generation” throughout ALC: Life-cycle support. If the TOE requires an initial start-up that does not need to
be repeated regularly, this process would be classified as installation.
3.3.2
operation
usage phase of the TOE including “normal usage”, administration and maintenance of the TOE after delivery
and preparation
3.3.3
preparation
activity in the life-cycle phase of a product, comprising the customer's acceptance of the delivered TOE and its
installation which may include such things as booting, initialisation, start-up and progressing the TOE to a
state ready for operation
3.4 Terms and definitions related to the A
...

NORME ISO/IEC
INTERNATIONALE 15408-1
Troisième édition
2009-12-15
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
Information technology — Security techniques — Evaluation criteria
for IT security —
Part 1: Introduction and general model
Numéro de référence
©
ISO/IEC 2009
DOCUMENT PROTÉGÉ PAR COPYRIGHT
© ISO/IEC 2009
Tous droits réservés. Sauf prescription différente ou nécessité dans le contexte de sa mise en œuvre, aucune partie de cette
publication ne peut être reproduite ni utilisée sous quelque forme que ce soit et par aucun procédé, électronique ou mécanique,
y compris la photocopie, ou la diffusion sur l’internet ou sur un intranet, sans autorisation écrite préalable. Une autorisation peut
être demandée à l’ISO à l’adresse ci-après ou au comité membre de l’ISO dans le pays du demandeur.
ISO copyright office
Case postale 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Genève
Tél.: [phone]
Fax: [phone]
E-mail: [e-mail]
Web: www.iso.org
Publié en Suisse
ii © ISO/IEC 2009 – Tous droits réservés

Sommaire Page
Avant-propos .v
Introduction .vi
1 Domaine d'application . 1
2 Références normatives . 1
3 Termes et définitions . 2
3.1 Termes et définitions communs à l'ISO/IEC 15408 . 2
3.2 Termes et définitions relatifs à la classe ADV . 9
3.3 Termes et définitions relatifs à la classe AGD .14
3.4 Termes et définitions relatifs à la classe ALC .14
3.5 Termes et définitions relatifs à la classe AVA .18
3.6 Termes et définitions relatifs à la classe ACO .19
4 Abréviations .19
5 Vue d'ensemble .20
5.1 Généralités .20
5.2 La TOE.20
5.2.1 Différentes représentations de la TOE .21
5.2.2 Différentes configurations de la TOE.21
5.3 Public visé par l'ISO/IEC 15408 .22
5.3.1 Consommateurs .22
5.3.2 Développeurs .22
5.3.3 Évaluateurs .22
5.3.4 Autres .22
5.4 Les différentes parties de l'ISO/IEC 15408 .23
5.5 Contexte d'évaluation .24
6 Modèle général .24
6.1 Introduction au modèle général.24
6.2 Biens sensibles et contremesures .25
6.2.1 Suffisance des contremesures .27
6.2.2 Exactitude de la TOE .28
6.2.3 Exactitude de l'environnement opérationnel .28
6.3 Évaluation .29
7 Adaptation des exigences de sécurité .30
7.1 Opérations .30
7.1.1 L'opération d'itération .30
7.1.2 L'opération d'affectation .31
7.1.3 L'opération de sélection .31
7.1.4 L'opération de raffinement .32
7.2 Dépendances entre les composants .32
7.3 Composants étendus .33
8 Profils de protection et paquets .33
8.1 Introduction .33
8.2 Paquets .33
8.3 Profils de protection .34
8.4 Utilisation des PP et des paquets .36
8.5 Utilisation de plusieurs profils de protection .36
9 Résultats d'évaluation .37
9.1 Introduction .37
9.2 Résultats d'une évaluation de PP .38
9.3 Résultats d'une évaluation de ST/TOE .38
9.4 Revendication de conformité .38
9.5 Utilisation des résultats d'évaluation de la ST/TOE .39
© ISO/IEC 2009 – Tous droits réservés iii

Annexe A (informative) Spécification des cibles de sécurité .40
Annexe B (informative) Spécification des profils de protection .57
Annexe C (informative) Recommandations relatives aux opérations .63
Annexe D (informative) Conformité au PP .66
Bibliographie .68
iv © ISO/IEC 2009 – Tous droits réservés

Avant-propos
L'ISO (Organisation internationale de normalisation) et l'IEC (Commission électrotechnique
internationale) forment le système spécialisé de la normalisation mondiale. Les organismes
nationaux membres de l'ISO ou de l'IEC participent au développement de Normes internationales
par l'intermédiaire des comités techniques créés par l'organisation concernée afin de s'occuper des
domaines particuliers de l'activité technique. Les comités techniques de l'ISO et de l'IEC collaborent
dans des domaines d'intérêt commun. D'autres organismes internationaux, gouvernementaux et non
gouvernementaux, en liaison avec l'ISO et le IEC participent également aux travaux. Dans le domaine
des technologies de l'information, l'ISO et l'IEC ont créé un comité technique mixte, l'ISO/IEC JTC 1.
Les Normes internationales sont rédigées conformément aux règles données dans les Directives ISO/
IEC, Partie 2.
La tâche principale du comité technique mixte est d'élaborer les Normes internationales. Les projets de
Normes internationales adoptés par le comité technique mixte sont soumis aux organismes nationaux
pour vote. Leur publication comme Normes internationales requiert l'approbation de 75 % au moins
des organismes nationaux votants.
L'attention est attirée sur le fait que certains des éléments du présent document peuvent faire l'objet
de droits de propriété intellectuelle ou de droits analogues. L'ISO et l'IEC ne sauraient être tenues pour
responsables de ne pas avoir identifié de tels droits de propriété et averti de leur existence.
L'ISO/IEC 15408-1 a été élaborée par le comité technique mixte ISO/IEC JTC 1, Technologies de
l'information, sous-comité SC 27, Techniques de sécurité des technologies de l'information. Le texte
identique de l'ISO/IEC 15408 est publié par les organisations commanditaires du projet Critères
communs sous le titre Common Criteria for Information Technology Security Evaluation (Critères
Communs pour l'évaluation de la sécurité des technologies de l'information). La source XML commune
aux deux publications peut être obtenue à l'adresse http:// www .commoncriteriaportal .org/ cc/ .
Cette troisième édition annule et remplace la deuxième édition (ISO/IEC 15408-1:2005), qui a fait l'objet
d'une révision technique.
L'ISO/IEC 15408 comprend les parties suivantes, présentées sous le titre général 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;
— Partie 2: Composants fonctionnels de sécurité;
— Partie 3: Exigences d'assurance de sécurité.
La présente version corrigée de l'ISO/IEC 15408-1:2009 incorpore diverses corrections éditoriales
portant sur:
— la terminologie: correction des termes «problème de sécurité» et «domaines de sécurité»;
— le paragraphe 8.3: explication de la notion de conformité stricte et suppression de l'ancienne
Figure 4.
© ISO/IEC 2009 – Tous droits réservés v

Introduction
L'ISO/IEC 15408 autorise une comparabilité entre les résultats d'évaluations de sécurité indépendantes.
À cet effet, l'ISO/IEC 15408 propose un ensemble commun d'exigences applicables aux fonctionnalités
de sécurité des produits de technologies de l'information (TI) et aux mesures d'assurance appliquées à
ces produits TI au cours d'une évaluation de sécurité. Ces produits TI peuvent être mis en œuvre dans
du matériel, des microprogrammes ou des logiciels.
Le processus d'évaluation établit un niveau de confiance quant à la capacité des fonctionnalités
de sécurité de ces produits TI et des mesures d'assurance qui leur sont appliquées à satisfaire à ces
exigences. Les résultats d'évaluation peuvent aider les consommateurs à déterminer si ces produits TI
répondent à leurs besoins de sécurité.
L'ISO/IEC 15408 constitue un guide utile pour le développement, l'évaluation et/ou l'acquisition de
produits TI dotés de fonctionnalités de sécurité.
L'ISO/IEC 15408 est volontairement souple pour permettre d'appliquer diverses méthodes d'évaluation
à différentes propriétés de sécurité d'une vaste gamme de produits TI. Il est par conséquent
recommandé aux utilisateurs de la présente norme de prendre toutes les précautions nécessaires pour
éviter d'utiliser une telle flexibilité à mauvais escient. Par exemple, l'utilisation de l'ISO/IEC 15408
combinée à des méthodes d'évaluation inappropriées, à des propriétés de sécurité inadaptées ou à des
produits TI incompatibles peut conduire à des résultats d'évaluation dénués de sens.
Ainsi, le fait qu'un produit TI ait été évalué n'a de sens que dans le contexte des propriétés de sécurité qui
ont été effectivement évaluées et des méthodes d'évaluation qui ont été employées. Il est recommandé
aux autorités d'évaluation de vérifier soigneusement les produits, propriétés et méthodes afin de
déterminer si une évaluation produira des résultats pertinents. Par ailleurs, les acheteurs de produits
évalués sont invités à tenir compte scrupuleusement de ce contexte pour déterminer si le produit évalué
est utile et s'il s'applique à leur situation et à leurs besoins spécifiques.
L'ISO/IEC 15408 traite de la protection des biens sensibles contre toute divulgation, modification
ou perte d'usage non autorisée. Les catégories de protection relatives à ces trois types de faille de
sécurité sont communément désignées par les termes de confidentialité, d'intégrité et de disponibilité,
respectivement. L'ISO/IEC 15408 peut également s'appliquer à des aspects de la sécurité TI ne relevant
pas de ces trois catégories. L'ISO/IEC 15408 s'applique aux risques liés à des activités humaines
(malveillantes ou autres) ainsi qu'aux risques qui ne relèvent pas des activités humaines. Au-delà de la
sécurité TI, l'ISO/IEC 15408 peut être appliquée dans d'autres aspects des technologies de l'information,
bien qu'elle ne revendique aucune applicabilité dans ces domaines.
Il est établi que certains sujets n'entrent pas dans le domaine d'application de l'ISO/IEC 15408 parce
qu'ils impliquent des techniques spécialisées ou parce qu'ils relèvent dans une certaine mesure
d'aspects annexes à la sécurité TI. Certains d'entre eux sont identifiés ci-dessous.
a) L'ISO/IEC 15408 ne contient aucun critère d'évaluation de la sécurité relevant de mesures de
sécurité administratives qui ne sont pas directement liées à des fonctionnalités de sécurité TI. Il
est cependant établi que l'utilisation ou l'appui de mesures administratives, telles que des contrôles
organisationnels ou physiques, l'intervention de personnel ou l'application de procédures, peut
souvent contribuer à obtenir une sécurité significative.
b) L'évaluation de certains aspects physiques techniques de la sécurité TI, tels que le contrôle des
émanations électromagnétiques, n'est pas spécifiquement couverte, bien que de nombreux concepts
abordés dans le présent document s'appliquent à ce domaine.
c) L'ISO/IEC 15408 ne couvre pas la méthodologie d'évaluation qu'il convient d'utiliser pour appliquer
les critères. Cette méthodologie est décrite dans l'ISO/IEC 18045.
d) De même, l'ISO/IEC 15408 ne traite pas du cadre administratif et juridique dans lequel les autorités
d'évaluation peuvent appliquer ces critères. Il est cependant prévu que l'ISO/ 15408 soit utilisée à
des fins d'évaluation dans le contexte d'un tel cadre.
vi © ISO/IEC 2009 – Tous droits réservés

e) Les procédures d'utilisation des résultats d'évaluation dans le cadre d'une accréditation ne
relèvent pas du domaine d'application de l'ISO/IEC 15408. Une accréditation désigne le processus
administratif consistant à accorder l'autorisation d'exploiter un produit TI (ou un ensemble de tels
produits) dans son environnement opérationnel, y compris pour l'ensemble de ses composants ne
relevant pas des technologies de l'information. Les résultats du processus d'évaluation servent
de données d'entrée au processus d'accréditation. Cependant, puisque d'autres techniques se
révèlent plus adaptées pour l'appréciation des propriétés qui ne relèvent pas des technologies
de l'information ainsi que de leur relation avec les composants de sécurité TI, il convient que les
organismes d'accréditation formulent des dispositions distinctes pour traiter de ces aspects.
f) Le sujet des critères pour l'appréciation des qualités inhérentes des algorithmes cryptographiques
n'est pas abordé dans l'ISO/IEC 15408. Dans l'éventualité où une appréciation indépendante des
propriétés mathématiques de cryptographie serait nécessaire, le schéma d'évaluation en vertu
duquel est appliquée l'ISO/IEC 15408 doit prévoir des dispositions à cet égard.
La terminologie ISO, telle que «peut/peuvent», «informative», «normative», «doit/doivent» ou «il
convient de/que», telle qu'elle est utilisée dans le présent document, est définie dans les Directives ISO/
IEC, Partie 2. Noter que le terme «il convient» possède un sens supplémentaire qui s'applique dans le
cadre de l'utilisation de la présente norme. Voir la note ci-dessous. La définition suivante est donnée
pour l'utilisation de la locution «il convient» dans l'ISO/IEC 15408.
il convient
Dans un texte normatif, «il convient» est utilisé pour indiquer «qu'entre plusieurs possibilités, l'une
est recommandée car particulièrement appropriée, sans mentionner ni exclure les autres, ou qu'une
certaine manière de faire est préférée sans être nécessairement exigée.» (Directives ISO/IEC, Partie 2).
NOTE Dans l'ISO/IEC 15408, «sans être nécessairement exigée» est interprété dans le sens où le choix d'une
autre possibilité exige de justifier la raison pour laquelle l'option préférée n'a pas été retenue.
© ISO/IEC 2009 – Tous droits réservés vii

NORME INTERNATIONALE ISO/IEC 15408-1:2009(F)
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
1 Domaine d'application
La présente partie de l'ISO/IEC 15408 établit les concepts et principes généraux de l'évaluation de la
sécurité des technologies de l'information (TI). Elle spécifie le modèle général d'évaluation donné par
les différentes parties de la norme qui, dans son intégralité, est destinée à servir de base à l'évaluation
des propriétés de sécurité des produits TI.
La Partie 1 fournit une vue d'ensemble de toutes les parties de la norme ISO/IEC 15408. Elle décrit les
différentes parties de la norme, définit les termes et abréviations à utiliser dans toutes les parties de la
norme, établit le concept fondamental d'une cible d'évaluation (TOE, de l'anglais Target of Evaluation),
spécifie le contexte d'une évaluation et décrit le public à qui s'adressent les critères d'évaluation. Elle
fournit en outre une introduction aux concepts de sécurité de base nécessaires pour l'évaluation de
produits TI.
Elle définit les diverses opérations dans le cadre desquelles les composants fonctionnels et d'assurance
décrits dans l'ISO/IEC 15408-2 et dans l'ISO/IEC 15408-3 peuvent être adaptés par l'utilisation
d'opérations autorisées.
Elle spécifie les concepts clés de profils de protection (PP), les ensembles d'exigences de sécurité et
le sujet de la conformité, et décrit les conséquences d'une évaluation ainsi que les résultats d'une
évaluation. La présente partie de l'ISO/IEC 15408 donne des lignes directrices pour la spécification
de cibles de sécurité (ST, de l'anglais Security Targets) et fournit une description de l'organisation des
composants sur l'ensemble du modèle. Des informations générales sur la méthodologie d'évaluation
sont données dans l'ISO/IEC 18045 et le domaine d'application des plans d'évaluation est fourni.
2 Références normatives
Les documents de référence suivants sont indispensables pour l'application de l'ISO/IEC 15408, Partie 1.
Pour les références datées, seule l'édition citée s'applique. Pour les références non datées, la dernière
édition du document de référence s'applique (y compris les éventuels amendements).
ISO/IEC 15408-2, Technologies de l'information — Techniques de sécurité — Critères d'évaluation pour la
sécurité TI — Partie 2: Composants fonctionnels de sécurité
ISO/IEC 15408-3, Technologies de l'information — Techniques de sécurité — Critères d'évaluation pour la
sécurité TI — Partie 3: Composants d'assurance de sécurité
ISO/IEC 18045, Technologies de l'information — Techniques de sécurité — Méthodologie pour l'évaluation
de sécurité TI
© ISO/IEC 2009 – Tous droits réservés 1

3 Termes et définitions
Pour les besoins du présent document, les termes et définitions suivants s'appliquent.
NOTE Le présent article contient uniquement les termes qui sont employés dans un sens spécifique
dans l'ensemble des normes ISO/IEC 15408. Certaines combinaisons de termes communs utilisées dans
l'ISO/IEC 15408, bien qu'elles ne méritent pas de figurer dans le présent article, sont explicitées pour des raisons
de clarté étant donné le contexte dans lequel elles sont utilisées.
3.1 Termes et définitions communs à l'ISO/IEC 15408
3.1.1
actions indésirables
actions exécutées par un agent menaçant sur un bien sensible
3.1.2
biens sensibles
entités auxquelles le propriétaire de la TOE accorde vraisemblablement de la valeur
3.1.3
affectation
spécification d'un paramètre identifié dans un composant (de l'ISO/IEC 15408) ou une exigence
3.1.4
assurance
fondements de la confiance dans le fait qu'une TOE satisfait à ses SFR
3.1.5
potentiel d'attaque
mesure de l'effort à déployer lors de l'attaque d'une TOE, exprimée en termes d'expertise, de ressources
et de motivation d'un attaquant
3.1.6
augmentation
ajout d'une ou de plusieurs exigences à un paquet
3.1.7
données d'authentification
informations utilisées pour vérifier l'identité annoncée d'un utilisateur
3.1.8
utilisateur autorisé
utilisateur d'une TOE qui a le droit d'effectuer une opération, en accord avec les SFR
3.1.9
classe
groupement de familles ISO/IEC 15408 qui partagent un thème commun
3.1.10
compréhensible
ordonné de manière logique et ayant un sens perceptible
Note 1 à l'article: à l'article Pour la documentation, cela couvre à la fois le texte réel et la structure du document,
en des termes qui soient compréhensibles pour le public cible.
3.1.11
complet
propriété confirmant que toutes les parties nécessaires d'une entité ont été fournies
Note 1 à l'article: à l'article Sur le plan de la documentation, cela signifie que toutes les informations pertinentes
sont traitées dans la documentation, avec un niveau de détail tel qu'elles ne nécessitent aucune explication
supplémentaire à ce niveau d'abstraction.
2 © ISO/IEC 2009 – Tous droits réservés

3.1.12
composant
le plus petit ensemble sélectionnable d'éléments sur lequel des exigences peuvent être fondées
3.1.13
paquet d'assurance composé
paquet d'assurance constitué des exigences dérivées de l'ISO/IEC 15408-3 (essentiellement de
la classe ACO), représentant un point sur une échelle d'assurance de composition prédéfinie par
l'ISO/IEC 15408
3.1.14
confirmer
déclarer que quelque chose a été examiné en détail avec un niveau de suffisance déterminé
indépendamment
Note 1 à l'article: à l'article Le niveau de rigueur dépend de la nature du sujet. Ce terme s'applique uniquement
aux actions de l'évaluateur.
3.1.15
connectivité
propriété d'une TOE qui permet des interactions avec des entités TI externes à la TOE
Note 1 à l'article: à l'article Cela comprend les échanges de données par liaison filaire ou non, sur une distance,
dans un environnement ou dans une configuration quelconque.
3.1.16
cohérent
relation entre deux entités ou plus qui ne révèle aucune contradiction apparente entre ces entités
3.1.17
contrer
réagir à une attaque de sorte que l'impact d'une menace donnée est atténué mais pas nécessairement
éradiqué
3.1.18
conformité démontrable
relation entre une ST et un PP, dans laquelle la ST fournit une solution au problème de sécurité générique
dans le PP
Note 1 à l'article: à l'article Le PP et la ST peuvent contenir des instructions totalement différentes qui traitent
d'entités différentes, utilisent des entités différentes, etc. Le concept de conformité démontrable convient
également pour un type de TOE impliquant l'existence de plusieurs PP similaires, ce qui permet à l'auteur de la ST
de revendiquer la conformité à ces PP de façon simultanée, réduisant ainsi la charge de travail.
3.1.19
démontrer
fournir une conclusion tirée d'une analyse moins rigoureuse qu'une «preuve»
3.1.20
dépendance
relation entre des composants, telle que si une exigence basée sur le composant dépendant d'un autre
composant est incluse dans un PP, une ST ou un paquet, une exigence basée sur cet autre composant
doit normalement être également incluse dans le PP, la ST ou le paquet
3.1.21
décrire
fournir des détails spécifiques d'une entité
© ISO/IEC 2009 – Tous droits réservés 3

3.1.22
déterminer
affirmer une conclusion particulière sur la base d'une analyse indépendante, dans l'objectif de parvenir
à une conclusion donnée
Note 1 à l'article: à l'article L'emploi de ce terme implique une analyse véritablement indépendante, en général en
l'absence de toute analyse antérieure. À distinguer des termes «confirmer» ou «vérifier», qui impliquent qu'une
analyse a déjà été effectuée et qu'elle nécessite une vérification.
3.1.23
environnement de développement
environnement dans lequel la TOE est développée
3.1.24
élément
énoncé indivisible d'un besoin de sécurité
3.1.25
(s')assurer
garantir une solide relation causale entre une action et ses conséquences
Note 1 à l'article: à l'article Lorsque ce terme est précédé du mot «aider», cela indique que la conséquence n'est
pas totalement certaine, sur la base de cette seule action.
3.1.26
évaluation
appréciation d'un PP, d'une ST ou d'une TOE par rapport aux critères définis
3.1.27
niveau d'assurance de l'évaluation
ensemble d'exigences d'assurance dérivées de l'ISO/IEC 15408-3, représentant un point sur l'échelle
d'assurance prédéfinie par l'ISO/IEC 15408, et qui constituent un paquet d'assurance
3.1.28
autorité d'évaluation
organisation qui définit les normes et surveille la qualité des évaluations menées par des organisations
au sein d'une communauté spécifique, et qui met en œuvre l'ISO/IEC 15408 pour les besoins de cette
communauté au moyen d'un schéma d'évaluation
3.1.29
schéma d'évaluation
cadre administratif et réglementaire dans lequel est appliquée l'ISO/IEC 15408 par une autorité
d'évaluation au sein d'une communauté spécifique
3.1.30
exhaustif
caractéristique d'une approche méthodique adoptée pour effectuer une analyse ou une activité
conformément à un plan univoque
Note 1 à l'article: à l'article Ce terme est utilisé dans l'ISO/IEC 15408 en ce qui concerne la conduite d'une
analyse ou d'une autre activité. Il est lié au terme «systématique», mais dans un sens considérablement plus fort
puisqu'il indique non seulement qu'une approche méthodique a été adoptée pour effectuer l'analyse ou l'activité
conformément à un plan univoque, mais également que le plan suivi est suffisant pour s'assurer que toutes les
voies possibles ont été exploitées.
3.1.31
expliquer
donner un argument justifiant l'adoption d'un plan d'action
Note 1 à l'article: à l'article Ce terme a un sens différent des termes «décrire» et «démontrer». Il vise à répondre
à la question «pourquoi?», sans tenter réellement de défendre l'idée que le plan d'action qui a été entrepris était
nécessairement optimal.
4 © ISO/IEC 2009 – Tous droits réservés

3.1.32
extension
ajout à une ST ou à un PP d'exigences fonctionnelles ne figurant pas dans l'ISO/IEC 15408-2 et/ou
d'exigences d'assurance ne figurant pas dans l'ISO/IEC 15408-3
3.1.33
entité externe
entité humaine ou TI qui interagit éventuellement avec la TOE en dehors des frontières de la TOE
Note 1 à l'article: à l'article Une entité externe peut également être appelée un utilisateur.
3.1.34
famille
groupement de composants ayant en commun un objectif similaire mais qui diffèrent en termes
d'importance ou de rigueur
3.1.35
formel
exprimé dans un langage syntaxique restreint doté d'une sémantique définie basée sur des concepts
mathématiques bien établis
3.1.36
guide (d'orientation)
documentation qui décrit la livraison, la préparation, l'exploitation, la gestion et/ou l'utilisation de la TOE
3.1.37
identité
représentation qui identifie de façon unique des entités (par exemple, un utilisateur, un processus ou
un disque) dans le contexte de la TOE
Note 1 à l'article: à l'article Une telle représentation peut être une chaîne, par exemple. Dans le cas d'un utilisateur
humain, la représentation peut être le nom entier ou abrégé ou un pseudonyme (toujours unique).
3.1.38
informel
exprimé à l'aide d'un langage naturel
3.1.39
transferts inter-TSF
données de communication entre la TOE et les fonctions de sécurité d'autres produits TI de confiance
3.1.40
canal de communication interne
canal de communication qui relie des parties séparées de la TOE
3.1.41
transfert interne à la TOE
données de communication entre parties séparées de la TOE
3.1.42
intrinsèquement cohérent
sans contradictions apparentes entre les différents aspects d'une entité
Note 1 à l'article: à l'article Sur le plan de la documentation, cela signifie que la documentation ne peut pas
contenir d'énoncés pouvant être interprétés comme étant mutuellement contradictoires.
3.1.43
itération
utilisation du même composant pour exprimer deux exigences distinctes ou plus
© ISO/IEC 2009 – Tous droits réservés 5

3.1.44
justification
analyse conduisant à une conclusion
Note 1 à l'article: à l'article Une «justification» est plus rigoureuse qu'une démonstration. Ce terme sous-entend
une grande rigueur dans l'explication soigneuse et approfondie de chaque étape d'un argument logique.
3.1.45
objet
entité passive dans la TOE, qui contient ou reçoit des informations et sur laquelle les sujets effectuent
des opérations
3.1.46
opération
〈sur un composant de l'ISO/IEC 15408〉 modification ou répétition d'un composant
Note 1 à l'article: à l'article Les opérations autorisées sur des composants sont l'affectation, l'itération, le
raffinement et la sélection.
3.1.47
opération
〈sur un objet〉 type spécifique d'action effectuée par un sujet sur un objet
3.1.48
environnement opérationnel
environnement dans lequel la TOE est exploitée
3.1.49
politique de sécurité organisationnelle
ensemble de règles, procédures ou lignes directrices de sécurité pour un organisme
Note 1 à l'article: à l'article Une politique peut être attachée à un environnement opérationnel spécifique.
3.1.50
paquet
ensemble nommé d'exigences fonctionnelles de sécurité ou d'exigences d'assurance de sécurité
Note 1 à l'article: «EAL 3» est un exemple de paquet.
3.1.51
évaluation du profil de protection
appréciation d'un PP par rapport aux critères définis
3.1.52
profil de protection
énoncé des besoins de sécurité indépendant de l'implémentation pour un type de TOE
3.1.53
prouver
montrer une correspondance à l'aide d'une analyse formelle au sens mathématique du terme
Note 1 à l'article: à l'article Cette action est totalement rigoureuse à tous points de vue. En règle générale,
le terme «prouver» est utilisé lorsqu'il existe une volonté de montrer une correspondance entre deux
représentations de TSF à un niveau de rigueur élevé.
3.1.54
raffinement
ajout de détails à un composant
3.1.55
rôle
ensemble prédéfini de règles établissant les interactions autorisées entre un utilisateur et la TOE
6 © ISO/IEC 2009 – Tous droits réservés

3.1.56
secret
informations qui ne doivent être connues que par des utilisateurs autorisés et/ou par la TSF afin
d'appliquer une SFP spécifique
3.1.57
état sécurisé
état dans lequel les données de la TSF sont cohérentes et où la TSF continue d'appliquer correctement
les SFR
3.1.58
attribut de sécurité
propriété de sujets, d'utilisateurs (y compris de produits TI externes), d'objets, d'informations, de
sessions et/ou de ressources, qui est utilisée pour définir les SFR et dont les valeurs sont utilisées pour
appliquer les SFR
3.1.59
politique de sécurité fonctionnelle
ensemble de règles décrivant un comportement de sécurité spécifique appliqué par la TSF et exprimable
sous forme d'ensemble de SFR
3.1.60
objectif de sécurité
expression de l'intention de contrer des menaces identifiées et/ou de satisfaire à des politiques de
sécurité organisationnelles et/ou à des hypothèses
3.1.61
problème de sécurité
déclaration qui définit de manière formelle la nature et le périmètre de la sécurité que la TOE vise à couvrir
Note 1 à l'article: à l'article Cette déclaration se compose d'une combinaison:
— de menaces devant être contrées par la TOE et son environnement opérationnel;
— des OSP appliquées par la TOE et son environnement opérationnel; et
— des hypothèses retenues pour l'environnement opérationnel de la TOE.
3.1.62
exigence de sécurité
exigence, formulée dans un langage normalisé, qui est supposée contribuer à atteindre les objectifs de
sécurité d'une TOE
3.1.63
cible de sécurité
énoncé des besoins de sécurité dépendant de l'implémentation pour une TOE spécifique identifiée
3.1.64
sélection
spécification d'un ou de plusieurs éléments à partir d'une liste au sein d'un composant
3.1.65
semi-formel
exprimé à l'aide d'un langage syntaxique restreint utilisant une sémantique définie
3.1.66
spécifier
fournir des détails spécifiques concernant une entité d'une manière rigoureuse et précise
© ISO/IEC 2009 – Tous droits réservés 7

3.1.67
conformité stricte
relation hiérarchique entre un PP et une ST dans laquelle toutes les exigences du PP existent également
dans la ST
Note 1 à l'article: à l'article Cette relation peut être grossièrement définie comme signifiant que «la ST doit
contenir toutes les indications qui se trouvent dans le PP, mais peut en contenir davantage». Une conformité
stricte est destinée à être utilisée pour des exigences rigoureuses qui doivent être respectées d'une manière
spécifique.
3.1.68
évaluation de la ST
appréciation d'une ST par rapport aux critères définis
3.1.69
sujet
entité active au sein de la TOE qui exécute des opérations sur des objets
3.1.70
cible d'évaluation
ensemble de logiciels, de microprogrammes et/ou de matériels éventuellement accompagnés de
recommandations
3.1.71
agent menaçant
entité qui peut agir de manière indésirable sur des biens sensibles
3.1.72
évaluation de la TOE
appréciation d'une TOE par rapport aux critères définis
3.1.73
ressource de TOE
tout élément utilisable ou consommable dans la TOE
3.1.74
fonctionnalité de sécurité de la TOE
fonctionnalités combinées de tous les matériels, logiciels et microprogrammes d'une TOE devant être
prises en compte pour l'application correcte des SFR
3.1.75
relier
effectuer une analyse de correspondance informelle entre deux entités avec un niveau de rigueur minimal
3.1.76
transferts externes à la TOE
communication de données, par l'intermédiaire de la TSF, à des entités qui ne sont pas placées sous le
contrôle de la TSF
3.1.77
traduction
processus consistant à décrire des exigences de sécurité dans un langage normalisé
Note 1 à l'article: à l'article Dans ce contexte, l'utilisation du terme «traduction» n'est pas littéral et n'implique
pas que chaque SFR exprimée dans un langage normalisé peut également être retraduite en objectifs de sécurité.
3.1.78
canal de confiance
moyen par lequel une TSF et un autre produit TI de confiance peuvent communiquer avec la confiance
nécessaire
8 © ISO/IEC 2009 – Tous droits réservés

3.1.79
produit TI de confiance
produit TI, autre que la TOE, dont les exigences fonctionnelles de sécurité sont coordonnées sur le plan
administratif avec la TOE et qui est supposé appliquer correctement ses exigences fonctionnelles de
sécurité
Note 1 à l'article: à l'article Un exemple de produit TI de confiance serait un produit TI qui a fait l'objet d'une
évaluation distincte.
3.1.80
chemin de confiance
moyen par lequel un utilisateur et une TSF peuvent communiquer avec la confiance nécessaire
3.1.81
données de la TSF
données d'exploitation de la TOE sur lesquelles repose l'application de la SFR
3.1.82
interface de la TSF
moyen par lequel des entités externes (ou des sujets internes à la TOE mais externes à la TSF) fournissent
des données à la TSF, reçoivent des données de la TSF et appellent des services à partir de la TSF
3.1.83
données utilisateur
données de l'utilisateur qui n'affectent pas le fonctionnement de la TSF
3.1.84
vérifier
examiner rigoureusement en détail avec un niveau de suffisance déterminé indépendamment
Note 1 à l'article: à l'article Voir également «confirmer». Ce terme possède des connotations très rigoureuses.
Le terme «vérifier» est utilisé dans le contexte des actions d'un évaluateur qui nécessitent de sa part un effort
indépendant.
3.2 Termes et définitions relatifs à la classe ADV
NOTE Les termes suivants sont utilisés dans les exigences applicables à la structuration interne d'un logiciel.
Certains sont dérivés de l'IEEE Std 610.12-1990, Standard glossary of software engineering terminology, Institute of
Electrical and Electronics Engineers.
3.2.1
administrateur
entité qui a un niveau de confiance à l'égard de toutes les politiques implémentées par une TSF
Note 1 à l'article: à l'article Tous les PP ou toutes les ST n'ont pas le même niveau de confiance pour les
administrateurs. En règle générale, les administrateurs sont supposés respecter en toutes circonstances les
politiques figurant dans la ST de la TOE. Certaines de ces politiques peuvent être liées à la fonctionnalité de la
TOE, tandis que d'autres peuvent être associées à l'environnement opérationnel.
3.2.2
graphe d'appel
identifie les modules dans un système sous la forme d'un diagramme montrant quels modules
s'appellent mutuellement
Note 1 à l'article: à l'article Adapté de l'IEEE Std 610.12-1990.
© ISO/IEC 2009 – Tous droits réservés 9

3.2.3
cohésion
force du module
mode et degré de relation mutuelle entre les tâches exécutées par un module logiciel unique
[SOURCE: IEEE Std 610.12-1990]
Note 1 à l'article: à l'article Les cohésions sont de type contingent, communicationnel, fonctionnel, logique,
séquentiel et temporel. Ces types de cohésion sont décrits par le terme correspondant.
3.2.4
cohésion contingente
module ayant la caractéristique d'exécuter des activités sans lien, ou avec un vague lien, entre elles
[SOURCE: IEEE Std 610.12-1990]
Note 1 à l'article: à l'article Voir également «cohésion» (3.2.3).
3.2.5
cohésion communicationnelle
module contenant des fonctions qui produisent des données de sortie pour d'autres fonctions au sein du
module, ou qui utilisent des données de sortie d'autres fonctions au sein du module
[SOURCE: IEEE Std 610.12-1990]
Note 1 à l'article: à l'article Voir également «cohésion» (3.2.3).
Note 2 à l'article: à l'article Un exemple de module à cohésion communicationnelle est un module de contrôle
d'accès qui intègre des contrôles obligatoires, discrétionnaires et de capacité.
3.2.6
complexité
mesure du degré de difficulté à comprendre un logiciel, et donc de la difficulté à l'analyser, le soumettre
à essai et le tenir à jour
[SOURCE: IEEE Std 610.12-1990]
Note 1 à l'article: à l'article L'utilisation de la décomposition modulaire, de l'organisation en couches et de la
minimisation a pour objectif ultime de réduire la complexité. Le contrôle du couplage et de la cohésion contribue
de façon significative à cet objectif.
Dans le domaine du génie logiciel, d'importants efforts ont été déployés pour tenter de développer des indicateurs
permettant de mesurer la complexité du code source. La plupart de ces indicateurs utilisent des propriétés du
code source qu'il est facile de calculer, comme le nombre d'opérateurs et d'opérandes, la complexité du graphe de
flot de contrôle (complexité cyclomatique), le nombre de lignes du code source, le rapport entre commentaires
et code exécutable et d'autres mesures similaires. Les normes de codage sont considérées comme un outil utile
pour générer du code plus facile à comprendre.
La famille des internes de la TSF (ADV_INT) impose une analyse de la complexité dans to
...