ISO/IEC TR 15443-1:2005

TECHNICAL ISO/IEC
REPORT TR
15443-1
First edition
2005-02-01
Information technology — Security
techniques — A framework for IT security
assurance —
Part 1:
Overview and framework
Technologies de l'information — Techniques de sécurité — Un canevas
pour l'assurance de la sécurité dans les technologies de l'information —
Partie 1: Vue d'ensemble et canevas

Reference number
©
ISO/IEC 2005
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 2005
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 copyright@iso.org
Web www.iso.org
Published in Switzerland
ii © ISO/IEC 2005 – All rights reserved

Contents Page
Foreword. iv
Introduction . v
1 Scope. 1
1.1 Purpose. 1
1.2 Approach . 1
1.3 Application. 1
1.4 Field of Application. 1
1.5 Limitations . 1
2 Terms and definitions. 1
3 Abbreviated terms. 6
4 Concepts. 7
4.1 Why do we need assurance?. 8
4.2 Assurance is distinguishable from confidence . 8
4.3 What is a deliverable? . 8
4.4 Stakeholders. 9
4.5 Assurance requirements. 9
4.6 Assurance methods applicability to IT security . 10
4.7 Assurance schemes . 10
4.8 Quantifying assurance risk and mechanism strength. 11
4.9 Assurance reduces security risk. 11
4.10 Quantifying assurance . 11
4.11 Assurance authority . 11
5 Selecting security assurance . 12
5.1 Assurance requirements specification. 13
5.2 Economical aspects. 13
5.3 Organisational aspects. 14
5.4 Type of assurance. 14
5.5 Technical aspects . 15
5.6 Optimisation considerations . 15
6 Framework . 16
6.1 Assurance approach. 16
6.2 Assurance methods. 16
6.3 Life cycle aspects . 17
6.4 Correctness versus effectiveness assurance. 18
6.5 Categorisation of assurance methods. 19
6.6 Composite assurance. 20
6.7 Assurance rating. 20

© ISO/IEC 2005 – 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.
In exceptional circumstances, the joint technical committee may propose the publication of a Technical Report
of one of the following types:
 type 1, when the required support cannot be obtained for the publication of an International Standard,
despite repeated efforts;
 type 2, when the subject is still under technical development or where for any other reason there is the
future but not immediate possibility of an agreement on an International Standard;
 type 3, when the joint technical committee has collected data of a different kind from that which is
normally published as an International Standard (“state of the art”, for example).
Technical Reports of types 1 and 2 are subject to review within three years of publication, to decide whether
they can be transformed into International Standards. Technical Reports of type 3 do not necessarily have to
be reviewed until the data they provide are considered to be no longer valid or useful.
ISO/IEC TR 15443-1, which is a Technical Report of type 3, was prepared by Joint Technical Committee
ISO/IEC JTC 1, Information technology, Subcommittee SC 27, IT Security techniques.
ISO/IEC TR 15443 consists of the following parts, under the general title Information technology — Security
techniques — A framework for IT security assurance:
 Part 1: Overview and framework
 Part 2: Assurance methods
Analysis of assurance methods will form the subject of a future Part 3.

iv © ISO/IEC 2005 – All rights reserved

Introduction
At the plenary meeting of ISO/IEC JTC 1/SC 27 in November 1994, a study group was set up to consider the
question of testing and assessment methods which contribute to assurance that IT products and systems
conform to security standards from SC 27 and elsewhere (e.g. SC 21 and ETSI; and some Internet standards
contain security aspects). In parallel, the Common Criteria project created a working group on assurances
approaches in early 1996. ISO/IEC TR 15443 resulted from these two activities.
The objective of ISO/IEC TR 15443 is to present a variety of assurance methods, and to guide the IT Security
Professional in the selection of an appropriate assurance method (or combination of methods) to achieve
confidence that a given deliverable satisfies its stated IT security assurance requirements. This report
examines assurance methods and approaches proposed by various types of organisations whether they are
approved or de-facto standards.
In pursuit of this objective, ISO/IEC TR 15443 comprises the following:
a) a framework model to position existing assurance methods and to show their relationships;
b) a collection of assurance methods, their description and reference;
c) a presentation of common and unique properties specific to assurance methods;
d) qualitative, and where possible, quantitative comparison of existing assurance methods;
e) identification of assurance schemes currently associated with assurance methods;
f) a description of relationships between the different assurance methods; and
g) guidance to the application, composition and recognition of assurance methods.
ISO/IEC TR 15443 is organised in three parts to address the assurance approach, analysis, and relationships
as follows:
Part 1 Overview and Framework provides an overview of the fundamental concepts and a general description
of assurance methods. This material is aimed at understanding Part 2 and the future Part 3 of
ISO/IEC TR 15443. Part 1 targets IT security managers and others responsible for developing a security
assurance program, determining the security assurance of their deliverable, entering an assurance
assessment audit (e.g. ISO 9000, SSE-CMM (ISO/IEC 21827), ISO/IEC 15408-3), or other assurance
activities.
Part 2 Assurance Methods describes a variety of assurance methods and approaches and relates them to the
security assurance framework model of Part 1. The emphasis is to identify qualitative properties of the
assurance methods that contribute to assurance. This material is catering to an IT security professional for the
understanding of how to obtain assurance in a given life cycle stage of deliverable.
The future Part 3 Analysis of Assurance Methods will analyse the various assurance methods with respect to
their assurance properties. The analysis will aid the Assurance Authority in deciding the relative value of each
Assurance Approach and determining the assurance approach(s) that will provide the assurance results most
appropriate to their needs within the specific context of their operating environment. Furthermore, the analysis
will also aid the Assurance Authority to use the assurance results to achieve the desired confidence of the
deliverable. The material in this part targets the IT security professional who must select assurance methods
and approaches.
ISO/IEC TR 15443 analyses assurance methods that may not be unique to IT security; however, guidance
given in ISO/IEC TR 15443 will be limited to IT security requirements. Similarly, additional terms and concepts
defined in other International standardisation initiatives (i.e. CASCO) and International guides (e.g., ISO/IEC
Guide 2) will be incorporated; however, guidance will be provided specific to the field of IT security and is not
intended for general quality management and assessment, or IT conformity.
© ISO/IEC 2005 – All rights reserved v

TECHNICAL REPORT ISO/IEC TR 15443-1:2005(E)

Information technology — Security techniques — A framework
for IT security assurance —
Part 1:
Overview and framework
1 Scope
1.1 Purpose
The purpose of this part of ISO/IEC TR 15443 is to introduce, relate and categorise security assurance
methods to a generic life cycle model in a manner enabling an increased level of confidence to be obtained in
the security functionality of a deliverable.
1.2 Approach
The approach adopted throughout this part of ISO/IEC TR 15443 presents an overview of the basic assurance
concepts and terms required for understanding and applying assurance methods through a framework of
identifying various assurance approaches and assurance stages.
1.3 Application
Using the categorisation obtained through this part of ISO/IEC TR 15443, Part 2 and the future Part 3 will
guide the reader in the selection, and possible combination, of the assurance method(s) suitable for
application to a given deliverable.
1.4 Field of Application
This part of ISO/IEC TR 15443 provides guidance for the categorisation of assurance methods including those
not unique to IT security. It may be used in areas outside of IT security where criticality warrants assurance.
1.5 Limitations
This part of ISO/IEC TR 15443 applies to deliverables (refer to Clause 4.3) and their related organisational
security issues only.
2 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
NOTE The terms and definitions have been developed to be as generic as possible to support the assurance model
developed in this part of ISO/IEC TR 15443. The assurance model, being applicable to a broad spectrum of assurance
approaches, requires non-specific terminology to be applicable to a broad spectrum of assurance approaches.
Defining terms for a generic assurance model is a difficult task owing to the myriad of assurance terms that exist to satisfy
the available assurance approaches. Furthermore, similar terms have different definitions and many are unique to a
particular assurance approach making it difficult to construct a generic language for the assurance model. Owing to these
© ISO/IEC 2005 – All rights reserved 1

difficulties, terms and definitions have been crafted to ensure the neutrality of the assurance framework and applicability to
a wide range of assurance methods. Relevant ISO standards are used wherever possible, in particular to maintain
compatibility to ISO/IEC TR 15408 Parts 1 - 3 and ISO 9000 series.
The next difficulty was how to address the multiple definitions that existed for the same term and definitions that were not
used, as they were not generic enough for the model. Should these terms be ignored or maintained for reference
purposes? Ignoring definitions posed the problem of confusing readers when discussing the assurance approach from
which they came. Maintaining definitions specific to a unique assurance approach added a level of formatting complexity
to ISO/IEC TR 15443; however, the appropriate definition could then be used within the correct context. It was decided to
maintain the previous definitions and to present them in a clear manner. Where multiple definitions exist for the same term,
the principal definition for the purpose of ISO/IEC TR 15443 is listed first. Alternate definitions, bulleted and denoted in
italics, are only applicable when cited in the context of their source.
2.1
accreditation
Procedure by which an authoritative body gives formal recognition, approval, and acceptance of the
associated residual risk:
a) for the operation of an automated system in a particular security mode using a particular set of
safeguards [adapted from AGCA];
b) that a security body or person is competent to carry out specific tasks [adapted from
ISO/IEC Guide 2]; and
c) that a security service is suitable for the target environment.
2.2
approach
The method used or steps taken in setting about a task or problem.
2.3
assessment
Verification of a deliverable against a standard using the corresponding method to establish compliance and
determine the assurance.
2.4
assurance
Performance of appropriate activities or processes to instil confidence that a deliverable meets its security
objectives.
a) Grounds for confidence that an entity meets its security objectives [ISO/IEC 15408–1].
2.5
assurance approach
A grouping of assurance methods according to the aspect examined.
2.6
assurance argument
A set of structured assurance claims, supported by evidence and reasoning, that demonstrate clearly how
assurance needs have been satisfied.
2.7
assurance assessment
Verification and recording of the overall types and amounts of assurance associated with the deliverable
(entered into the assurance argument).
2 © ISO/IEC 2005 – All rights reserved

2.8
assurance authority
A person or organisation delegated the authority for decisions (i.e. selection, specification, acceptance,
enforcement) related to a deliverable’s assurance that ultimately leads to the establishment of confidence in
the deliverable.
NOTE In specific schemes or organisations, the term for assurance authority may be different such as evaluation
authority.
2.9
assurance evidence
Work products resulting from the assurance analysis of the deliverable (including summary reports or other
justification) that supports the assurance claim.
2.10
assurance level
The amount of assurance obtained according to the specific scale used by the assurance method.
NOTE 1 The assurance level may not be measurable in quantitative terms.
NOTE 2 The amount of assurance obtained is generally related to the effort expended on the activities performed.
2.11
assurance method
A recognised specification for obtaining reproducible assurance results.
2.12
assurance property
A characteristic of an assurance method that contributes to the assurance result.
2.13
assurance result
Documented numerical or qualitative assurance statement pertaining to a deliverable.
2.14
assurance scheme
The administrative and regulatory framework under which an assurance method is applied by an assurance
authority within a specific community or organisation.
a) The administrative and regulatory framework under which the Common Criteria is applied by an
evaluation authority within a specific community [ISO/IEC 15408–1].
2.15
assurance stage
The deliverable life cycle stage on which a given assurance method is focused. The overall deliverable
assurance takes into account the results of the assurance methods applied throughout the deliverable life
cycle.
2.16
assurance evidence
Workproducts or any items generated from the assurance analysis of the deliverable including reports
(justification) to support the assurance claim.
2.17
certification
Procedure by which a formal assurance statement is given that a deliverable conforms to specified
requirements. Certification may be performed by a third party or self-certified [adapted from
ISO/IEC Guide 2:1996].
© ISO/IEC 2005 – All rights reserved 3

a) The issue of a formal statement confirming the results of an evaluation, and that the evaluation
criteria used where correctly applied [ITSEC].
b) The certification process is the independent inspection of the results of the evaluation leading to the
production of the final certificate or approval [ISO/IEC 15408–1].
c) The comprehensive assessment of the technical and non-technical security features of an
information technology system, made in support of accreditation that establishes the extent to which
a system satisfies a specified security policy [AGCA].
2.18
confidence
A belief that a deliverable will perform in the way expected or claimed (i.e. properly, trustworthy, enforce
security policy, reliably, effectively).
2.19
deliverable
An IT security product, system, service, process, or environmental factor (i.e. personnel, organisation) or the
object of an assurance assessment. An object may be a Protection Profile (PP) or Security Target (ST) as
defined by ISO/IEC 15408-1.
Note: ISO 9000:2000 holds that a service is a type of product and “product and/or service" when used in the ISO 9000
family of standards.
2.20
evaluation
Assessment of a deliverable against defined criteria (adapted from ISO/IEC 15408–1).
a) Systematic examination (quality evaluation) of the extent to which an entity is capable of fulfilling
specified requirements [ISO/IEC 14598-1].
2.21
guarantee
Refer to the definition for Warranty in clause 2.36.
2.22
IT security product
A package of IT software, firmware and/or hardware, providing functionality designed for use or incorporation
within a multiplicity of systems [ISO/IEC 15408–1].
2.23
life cycle stage
An instance within the deliverable life cycle that relates to the state of the deliverable.
a) A period within the system life cycle that relates to the state of the system description and/or the
system itself [ISO/IEC 15288].
2.24
pedigree
Informal recognition of the vendor’s consistent repeatability to provide deliverables that satisfy its security
policy or to perform as claimed (pedigree is an environmental factor associated with the vendor or deliverable).
2.25
process
An organised set of activities which uses resources to transform inputs to outputs [ISO 9000: 2000]
2.26
process assurance
Assurance derived from an assessment of activities of a process.
4 © ISO/IEC 2005 – All rights reserved

2.27
product
Refer to the definition of deliverable.
2.28
scheme
Set of rules defining the environment, including criteria and methodology required to conduct an assessment
[adapted from ISO/IEC 18045 (Common Evaluation Methodology)].
2.29
security
All aspects related to defining, achieving, and maintaining confidentiality, integrity, availability, accountability,
authenticity, and reliability [ISO/IEC 13335-1].
NOTE A product, system, or service is considered to be secure to the extent that its users can rely that it functions
(or will function) in the intended way. This is usually considered in the context of an assessment of actual or perceived
threats.
a) The capability of the software product to protect information and data so that unauthorised persons or
systems cannot read or modify them and authorised persons or systems are not denied access to
them [ISO/IEC 9126-1].
2.30
security assessment
Verification of a security deliverable against a security standard using the corresponding security method to
establish compliance and determine the security assurance.
a) The last stage of the product evaluation process [ISO/IEC 14598-1].
2.31
security element
An indivisible security requirement.
2.32
service
A security process or task performed by a deliverable, organisation, or person.
2.33
stakeholder
A party having a right, share, or an asset at risk in a deliverable or in its possession of characteristics that
meet the party’s needs and expectations.
a) A party having a right, share, or claim asset in a system or in its possession of characteristics that
meet the party’s needs and expectations [ISO/IEC 15288].
2.34
system
A specific IT installation, with a particular purpose and operational environment [ISO/IEC 15408–1].
a) A combination of interacting elements organized to achieve one or more stated purposes
[ISO/IEC 15288].
NOTE 1 A system may be considered as a product and/or as the services it provides [ISO/IEC 15288].
NOTE 2 In practice, the interpretation of its meaning is frequently clarified by the use of an associative noun, e.g.
aircraft system. Alternatively the word system may be substituted simply by a context dependent synonym, e.g. aircraft,
though this may then obscure a system principles perspective [ISO/IEC 15288].
© ISO/IEC 2005 – All rights reserved 5

2.35
system life cycle
The evolution with time of the system from conception through to disposal [ISO/IEC 15288].
2.36
warranty
A security service to correct or mitigate the deliverable’s operation (deployment, performance, or delivery) if it
does not satisfy its security policy.
2.37
work product
All items (i.e. documents, reports, files, data, etc.) generated in the course of performing any process for
developing and supplying the deliverable [SSE-CMM (ISO/IEC 21827)].
a) Result of a system of activities, which use resources to transform inputs into outputs [ISO 9001].
3 Abbreviated terms
AST
Abstract Security Target
BSI
Bundesamt für Sicherheit in der Informationstechnik (German Information Security Agency)
CASCO
ISO Committee on conformity assessment
CEM
Common Evaluation Methodology (precursor of, and equivalent to NP N2729r1 Methodology for IT security
evaluation)
CMM
Capability Maturity Model
CSE
Communications Security Establishment (Canadian IT Security Agency)
CTCPEC
Canadian Trusted Computer Product Evaluation Criteria (edited by CSE)
HCD
Human Centered Design
IEC
International Electrotechnical Commission
ISO
International Organization for Standardization
IT
Information Technology
ITSEC
Information Technology Security Evaluation Criteria (Office for Official Publications of the European
Communities)
6 © ISO/IEC 2005 – All rights reserved

ITSEM
Information Technology Security Evaluation Methodology (Office for Official Publications of the European
Communities)
NSA
National Security Agency (Government Agency of the USA)
PP
Protection Profile (defined in ISO/IEC 15408-1)
RAMP
Ratings And Maintenance Phase (NSA process following TCSEC evaluations)
RM
Ratings and Maintenance phase (CSE process following CTCPEC evaluations)
SCT
Strict (Security) Conformance Testing
SE-CMM
System Engineering Capability Maturity Model (Capability Maturity Model is a Trade Mark of Carnegie-
Mellon University)
ST
Security Target (defined in ISO/IEC 15408-1)

SSAM
SSE-CMM Appraisal Methodology (promoted by Support Organization), an entity within the International
Systems Security Engineering Association (ISSEA)

SSE-CMM
System Security Engineering - Capability Maturity Model ISO/IEC 21827 (submitted to ISO as a publicly
available standard by the Support Organization of the International Systems Security Engineering Association
(ISSEA)
TCSEC
Trusted Computer System Evaluation Criteria (edited by NSA)
TOE
Target of Evaluation (Term specific to ISO/IEC 15408 and defined in ISO/IEC 15408-1)
TPEP
Trusted Product Evaluation Program (TCSEC and CTCPEC)
TRA
Threat and Risk Assessment
4 Concepts
This clause introduces the concepts of assurance and aims to differentiate the applicability of assurance
concepts between general IT assurance and IT security assurance. The concepts are broad and should not
be applied specifically to IT security or conformity assessments.
© ISO/IEC 2005 – All rights reserved 7

4.1 Why do we need assurance?
IT systems are prone to failure and security violations due to errors and vulnerabilities. These errors and
vulnerabilities can be caused by rapidly changing technology, human error, poor requirement specifications,
poor development processes or as a result of underestimating the threat. In addition, system modifications,
new flaws, and new attacks are frequently introduced contributing to increased vulnerabilities, failures, and
security violations throughout the IT system life cycle.
Due to human error or oversight, component or equipment failure, and due to imperfection of the opposing
security mechanisms, error-free, failure-free and risk-free operation is not usually achievable within acceptable
cost and time constraints over the deliverable of the IT system life cycle. This situation makes it almost
impossible to guarantee an error-free, risk-free, and secure IT system.
From the above paragraphs, it can be seen that errors, vulnerabilities and risks will probably always exist and
may change over the deliverable’s life cycle. Therefore, the errors, vulnerabilities and risks will have to be
managed over the deliverable’s life cycle within acceptable parameters otherwise the deliverable assurance
will change. The task of IT security engineering and management is to manage the security risk by mitigating
the vulnerabilities and threats with technological and organisational security measures to achieve a
deliverable with acceptable assurance. IT security management has an additional task of establishing
acceptable assurance and risk objectives. In this way, the stakeholders of an IT system will achieve
reasonable confidence that the deliverable performs in the way intended or claimed with acceptable risk and
within budget. From a security standpoint, this translates into confidence that the deliverable enforces the
applicable security policy.
4.2 Assurance is distinguishable from confidence
It is important to point out that assurance and confidence are not identical and cannot be used in place of one
another. Too often, these terms are used incorrectly as they are closely related. It is important for the reader
to understand the distinction between these two terms. Confidence, from the perspective of an individual, is
related to the belief that one has in the assurance of the deliverable whereas assurance is related to the
demonstrated ability of the deliverable to perform its security objectives. Therefore, confidence is not a
certainty but an expression of trust and belief created through assurance.
Assurance is determined from the evidence produced by the assessment process of the deliverable. The
evidence, usually composed of an assurance argument, documentation, and other related work products,
substantiates the claimed assurance based on the security engineering and assessment activities.
Confidence is subject to the individual’s perception of their specific security requirements and to the
knowledge gained in assessment processes that the deliverable will perform in the way expected or claimed.
This includes the knowledge of the assurance criteria, method, scheme, and assessment process used.
Furthermore, the reputation of the assessors and operators is a significant factor in establishing confidence of
the deliverable as their qualifications and experience may or may not be acceptable. As a consequence, by
their individual perception, stakeholders may have different degrees of confidence after the performance of a
given assurance method by a given person or organisation.
4.3 What is a deliverable?
Traditionally, assurance has only been associated with IT products and systems composed of hardware or
software and referred to as product or system assurance. It is now recognized that to address a wider range
of risks, there is a need for assurance of other security objectives such as a security service, process,
personnel, organisation, or other environmental factors. To address this new requirement, the term
“deliverable” is used to refer to the objective of the security assessment.
The broad definition of “deliverable” encompasses the security items listed on a contract to be delivered or
performed (i.e. service) for the client as the case may be. Contract items may include IT security products,
services, and any other tangible or intangible security item sold (whether one-of-a-kind or mass produced),
leased, trained, or contracted out. Furthermore, this includes any deliverable whether provided as a service,
shareware, freeware, sample, or by other means and whether supplied directly or indirectly (warranty,
guaranty, pedigree, etc.) or assumed by the consumer (pedigree, warranty, etc). Deliverables have
8 © ISO/IEC 2005 – All rights reserved

measurable security attributes that can be verified to meet their security policy. For example, the deliverable
may refer to a Threat and Risk Assessment (TRA) service performed by an organisation or it may refer to the
certification of personnel qualified to perform evaluations using the ISO/IEC15408 criteria. Personnel
performing a security service or task are also considered to be deliverables. For example, those being trained
to become evaluators, have a contract with the training organisation and are measured or graded on their
abilities to acquire the knowledge and perform specific activities. Similarly, security consultants performing a
service or task are also under contract.
Some assurance deliverables do not always appear as line items although they provide varying levels of
confidence to Assurance Authorities and therefore must be factored into the security assessment. For
instance, warranties and guarantees are specific services provided by the vendor either as stand-alone or as
an additional feature bundled with the deliverable supplied. Warranty services serve to correct or mitigate the
deliverable’s operation (deployment, performance, or delivery) if it does not satisfy its security policy. A
pedigree is an environmental factor associated with the vendor or deliverable, which although somewhat
vague, cannot be discounted due to a recognized history of special performance such as consistent and
repeated performance to meet its security policy or to meet the vendor claims.
Note: This definition of deliverable is similar to the term TOE defined in ISO/IEC 15408-1 except that deliverable has a
broader application.
4.4 Stakeholders
Assurance may be sought by the stakeholders of a deliverable who are the ones having assets at risk through
the deliverable. Therefore, the determination of an acceptable assurance method and level of assurance may
be required/and or influenced by the stakeholders some of whom are listed below:
a) standard bodies;
b) national and international laws and regulations;
c) specific communities (such as government or the banking industry);
d) authorised units within an organisation;
e) policy (security, personnel, procurement, marketing, certificate policy, etc.) owners;
f) system owners;
g) system accreditors;
h) end users; and
i) the general public.
4.5 Assurance requirements
In terms of IT security, adequate assurance signifies that specific predefined security assurance requirements
have been satisfied by performing appropriate assurance processes and activities, i.e. as prescribed by a
chosen assurance method. Assurance requirements are determined from the security requirements and other
driving factors.
Security assurance requirements are determined by analysing the security requirements for the deliverable,
influencers, security requirements (policies), business drivers and the target environment for the deliverable.
Influencers are any considerations that need to be addressed as they might affect the deliverable assurance
requirements. The influence can have any origin and may not even be tangible such as politics, culture, local
laws, and mandated requirements. A Risk Assessment is performed to provide an in-depth look at the asset
sensitivity, vulnerabilities, and threats to determine the residual risk and recommendations for existing and
proposed safeguards. The recommendations implemented are factored into the original security requirements
to revise the security assurance requirements.
General guidance on security management and for performing a risk analysis can be found in ISO/IEC 13335
and ISO/IEC 17799. ISO/IEC 15408 contains information on security functional and assurance requirements
for IT products and systems specific to traditional IT security evaluations.
© ISO/IEC 2005 – All rights reserved 9

Assurance requirements are unique to each environment due to the myriad of business and security
requirements of each environment. Therefore, the same deliverable may not be suitable to other environments
without modifications as different assurance requirements will usually need to be satisfied.
4.6 Assurance methods applicability to IT security
This clause expands on the assurance definition in Clause 2.4. It discusses different aspects of assurance in
order to demonstrate how the different aspects of assurance might be applied to IT security.
From the assurance definition in Clause 2.4, it is seen that the application of appropriate assurance activities
is what establishes confidence that the deliverable satisfies its security objectives. The confidence is realised
by reviewing the assurance evidence gained through assessment processes and activities during
development, deployment and operation, and through experience in actual usage of the deliverable. Any
activities that can reduce the uncertainty by producing evidence attesting to the correctness, effectiveness,
and quality of the deliverable’s attributes is useful in determining security assurance. Recognising that some
types of evidence more clearly establish the claims they support than other types, the key is creating a
comprehensive assurance argument that firmly establishes the type and amount of assurance gained from the
applied assurance methods. There are many existing assurance methods with only a small number specific to
IT security. However, non-IT security assurance methods may also contain certain assurance properties
relevant to IT security assurance. Due to the small number of security specific assurance methods available, it
is important to recognise the value of all assurance methods since many non-security assurance methods are
used throughout the IT industry. Assurance evidence is frequently in the form of documentation developed
during the normal course of IT engineering activities. Anything that can be used to construct an assurance
argument and thereby reduce the uncertainty (risk) associated with a particular deliverable is of considerable
importance.
The intent here is to communicate the value of non-IT security assurance methods and not downplay the
value of IT security specific assurance methods. The latter is clearly preferable; however, some assurance
can be obtained from many sources and should not be discounted simply because it does not come from a
recognised security assurance method. Having said this, it is very important to recognise the source of the
evidence and take that into account when developing the assurance argument. Furthermore, one must be
familiar with their security and assurance requirements and understand the value of the evidence and its
source to ensure that it satisfies their needs.
For example, while ISO 9000 is a quality assurance standard originally made for manufacturing organisations,
it also contains process assurance properties applicable to software, and as such to IT security software
products and systems. By contrast, the SSE-CMM (ISO/IEC 21827) is a security assurance method although
not a traditional assurance method. This method produces assurance evidence by assessing the
organisation’s security engineering processes and not the deliverable directly.
Certain assurance methods specifically focus on defining consistent and complete sets of security features,
which often reflect a standardised threat scenario or good practices. Different assurance methods may have
some components or aspects of assurance in common.
All these factors will have an impact on the assurance framework, and in particular on the definition of metrics.
The relationship between assurance methods will take account of these factors.
4.7 Assurance schemes
A specific assurance method that may be implemented in a way that emphasises the context within which the
method is executed is called an assurance scheme. Recognised facilities and assessors might ensure a
higher degree of assurance gained by using the respective assurance method. Such an assurance scheme
may also provide a basis for acceptance of results or verdicts achieved by the assurance method in a broader
audience.
10 © ISO/IEC 2005 – All rights reserved

4.8 Quantifying assurance risk and mechanism strength
Assurance does not “add” any safeguards or services to the deliverable. Thus it is sometimes difficult for non-
security personnel to understand what benefit they are receiving from the investment of resources in
assurance. For example, with respect to an IT security product, it has been argued that assurance contributes
to the “strength” of a security mechanism; however, the assurance actually contributes to the confidence that
one has in the mechanism strength by reducing the uncertainty (or probability) of a threat occurrence causing
a security breach. For example, Two-Factor authentication is often mistaken as having more assurance than a
simple password mechanism, where in reality it is only a stronger authentication mechanism. Two-Factor
authentication is a stronger mechanism since it verifies two user attributes versus one attribute in a password
mechanism. This in itself does not offer assurance since it is the assurance activities in the development of
the mechanism that contributes to the assurance of the mechanism.
It is important to understand that assurance does not automatically imply good security: only that it meets its
security objectives (security policy). In other words, the assurance provides confidence that the deliverable
enforces its security objectives without examining if the security objectives appropriately address the risks and
threats. For example, while a high assurance IT product can be trusted to meet its security objectives, it
depends on the nature of these objectives whether or not the product behaves in a secure manner. In contrast,
a low assurance product with mor
...