ISO/IEC TR 15446:2009

TECHNICAL ISO/IEC
REPORT TR
Second edition
2009-03-01
Information technology — Security
techniques — Guide for the production of
Protection Profiles and Security Targets
Technologies de l'information — Techniques de sécurité — Guide pour
la production de profils de protection et de cibles de sécurité

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

Contents Page
Foreword .vii
Introduction.viii
1 Scope.1
2 Normative references.1
3 Terms and definitions .1
4 Abbreviations.1
5 Purpose and structure of this technical report .2
6 An overview of PPs and STs .3
6.1 Introduction.3
6.2 Audience .3
6.3 The use of PPs and STs.3
6.3.1 Introduction.3
6.3.2 Specification-based purchasing processes .4
6.3.3 Selection-based purchasing processes.7
6.3.4 Other uses of PPs.8
6.4 The PP/ST development process.9
6.5 Reading and understanding PPs and STs.9
6.5.1 Introduction.9
6.5.2 Reading the TOE overview .10
6.5.3 Reading the TOE description .11
6.5.4 Security objectives for the operational environment .12
6.5.5 Reading the conformance claim.12
6.5.6 Conformance to Protection Profiles.13
6.5.7 EALs and other assurance issues .13
6.5.8 Summary.14
6.5.9 Further reading .15
7 Specifying the PP/ST introduction.15
8 Specifying conformance claims.15
9 Specifying the security problem definition.16
9.1 Introduction.16
9.2 Identifying the informal security requirement .18
9.2.1 Introduction.18
9.2.2 Sources of information .18
9.2.3 Documenting the informal requirement .20
9.3 How to identify and specify threats .21
9.3.1 Introduction.21
9.3.2 Deciding on a threat analysis methodology .21
9.3.3 Identifying participants .22
9.3.4 Applying the chosen threat analysis methodology .26
9.3.5 Practical advice.27
9.4 How to identify and specify policies.28
9.5 How to identify and specify assumptions.29
9.6 Finalising the security problem definition .31
10 Specifying the security objectives.32
10.1 Introduction.32
10.2 Structuring the threats, policies and assumptions.34
10.3 Identifying the non-IT operational environment objectives .34
10.4 Identifying the IT operational environment objectives .35
10.5 Identifying the TOE objectives .36
10.6 Producing the objectives rationale.39
iv © ISO 2009 – All rights reserved

11 Specifying extended component definitions.40
12 Specifying the security requirements .43
12.1 Introduction.43
12.2 The security paradigms in ISO/IEC 15408 .45
12.2.1 Explanation of the security paradigms and their usage for modelling the security
functionality .45
12.2.2 Controlling access to and use of resources and objects .45
12.2.3 User management .49
12.2.4 TOE self protection .50
12.2.5 Securing communication .51
12.2.6 Security audit.52
12.2.7 Architectural requirements .53
12.3 How to specify security functional requirements in a PP or ST.54
12.3.1 How should security functional requirements be selected? .54
12.3.2 Selecting SFRs from ISO/IEC 15408-2.57
12.3.3 How to perform operations on security functional requirements.59
12.3.4 How should the audit requirements be specified?.61
12.3.5 How should management requirements be specified?.62
12.3.6 How should SFRs taken from a PP be specified? .63
12.3.7 How should SFRs not in a PP be specified? .63
12.3.8 How should SFRs not included in Part 2 of ISO/IEC 15408 be specified? .64
12.3.9 How should the SFRs be presented?.64
12.3.10 How to develop the security requirements rationale.65
12.4 How to specify assurance requirements in a PP or ST.66
12.4.1 How should security assurance requirements be selected? .66
12.4.2 How to perform operations on security assurance requirements .67
12.4.3 How should SARs not included in Part 3 of ISO/IEC 15408 be specified in a PP or ST? .67
12.4.4 Security assurance requirements rationale .68
13 The TOE summary specification.68
14 Specifying PP/STs for composed and component TOEs.69
14.1 Composed TOEs.69
14.2 Component TOEs .72
15 Special cases .72
15.1 Low assurance Protection Profiles and Security Targets.72
15.2 Conforming to national interpretations.73
15.3 Functional and assurance packages.73
16 Use of automated tools.73
Annex A (informative) Example for the definition of an extended component.75
Bibliography.78
Index .79

vi © ISO 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.
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.
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 TR 15446, 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.
This second edition cancels and replaces the first edition (ISO/IEC TR 15446:2004), which has been
technically revised.
Introduction
This Technical Report is an adjunct to ISO/IEC 15408 Information technology — Security techniques —
Evaluation criteria for IT security. ISO/IEC 15408 introduces the concepts of Protection Profiles (PPs) and
Security Targets (STs). A Protection Profile is an implementation-independent statement of security needs for
a type of IT product that can then be evaluated against ISO/IEC 15408, whereas a Security Target is a
statement of security needs for a specific ISO/IEC 15408 target of evaluation (TOE).
Unlike previous editions, the third edition of ISO/IEC 15408 provides a comprehensive explanation of what
needs to go into a PP or ST. However, the third edition of ISO/IEC 15408 still does not provide any
explanation or guidance of how to go about creating a PP or ST, or how to use a PP or ST in practice when
specifying, designing or implementing secure systems.
This Technical Report is intended to fill that gap. It represents the collective experience over many years from
leading experts in ISO/IEC 15408 evaluation and the development of secure IT products.

viii © ISO 2009 – All rights reserved

TECHNICAL REPORT ISO/IEC TR 15446:2009(E)

Information technology — Security techniques — Guide for the
production of Protection Profiles and Security Targets
1 Scope
This Technical Report provides guidance relating to the construction of Protection Profiles (PPs) and Security
Targets (STs) that are intended to be compliant with the third edition of ISO/IEC 15408. It is also applicable to
PPs and STs compliant with Common Criteria Version 3.1 [1], a technically identical standard published by the
Common Criteria Management Board, a consortium of governmental organizations involved in IT security
evaluation and certification.
This Technical Report is not intended as an introduction to evaluation using ISO/IEC 15408. Readers who
seek such an introduction should read Part 1 of ISO/IEC 15408.
This Technical Report does not deal with associated tasks beyond PP and ST specifications such as PP
registration and the handling of protected intellectual property.
2 Normative references
The following referenced documents are indispensable for the application of this document. For dated
references, only the edition cited applies. For undated references, the latest edition of the referenced
document (including any amendments) applies.
1)
ISO/IEC 15408-1:— , Information technology — Security techniques — Evaluation criteria for IT security —
Part 1: Introduction and general model
ISO/IEC 15408-2:2008, Information technology — Security techniques — Evaluation criteria for IT security —
Part 2: Security functional components
ISO/IEC 15408-3:2008, Information technology — Security techniques — Evaluation criteria for IT security —
Part 3: Security assurance components
ISO/IEC 18045:2008, Information technology — Security techniques — Methodology for IT security evaluation
3 Terms and definitions
1)
For the purposes of this document, the terms and definitions given in ISO/IEC 15408-1:— apply.
4 Abbreviations
1)
For the purposes of this document, the abbreviations given in ISO/IEC 15408-1:— and the following apply.
COTS Commercial Off The Shelf

1) To be published. Technical revision of ISO/IEC 15408-1:2005.
CRL  Certificate Revocation List
LDAP Lightweight Directory Access Protocol
SPD Security Problem Definition
SSL  Secure Sockets Layer
TLS  Transport Layer Security
5 Purpose and structure of this technical report
This Technical Report is intended to help people who have to prepare Protection Profiles (PPs) or Security
Targets (STs) for use in evaluation against the third edition of ISO/IEC 15408. It provides detailed guidance
relating to the various parts of a PP or ST, and how they interrelate.
This Technical Report applies only to the third edition of ISO/IEC 15408. Earlier versions of ISO/IEC 15408
have different and incompatible technical requirements. However, the strategies proposed in this Technical
Report will, in the main, also be applicable to earlier versions of ISO/IEC 15408.
This Technical Report is primarily aimed at those who are involved in the development of PPs and STs. It will
also be of interest to consumers and users of PPs and STs who wish to understand the contents of PPs and
STs developed by others, and wish to confirm the relevance and accuracy of the information that they contain.
It is also likely to be useful to evaluators of PPs and STs and to those who are responsible for monitoring PP
and ST evaluation.
It is assumed that readers of this Technical Report are familiar with ISO/IEC 15408-1, and in particular
Annexes A and B which describe STs and PPs respectively. PP and ST authors will (of course) need to
become familiar with the other parts of ISO/IEC 15408 as described in this Report, including introductory
material such as the functional requirements paradigm described in ISO/IEC 15408-2:2008, Clause 5.
This Technical Report is intended for guidance only. It should not be cited as a Standard on the content or
structure for the evaluation of PPs and STs. It is intended to be fully consistent with ISO/IEC 15408; however,
in the event of any inconsistency between this Technical Report and ISO/IEC 15408, the latter as a normative
Standard takes precedence.
Clauses 1 to 4 contain introductory and reference material, and are followed by this overview clause (Clause
5).
Clause 6 provides an introduction to Protection Profiles and Security Targets – what they are, when and why
they might be used. This clause also discusses the relationship between PPs and STs and issues relating to
the PP/ST development process.
Clauses 7 to 13 provide information on how to specify the seven mandatory parts of the contents of a PP or
ST, following the order outlined in ISO/IEC 15408-1:—, clauses A.2 and B.2.
Clause 14 examines the issues specific to PPs and STs for composed TOEs, i.e. TOEs that are composed of
two or more component TOEs, each of which has its own PP or ST.
Clause 15 deals with some special cases, namely low assurance reduced PP/ST contents, conforming to
national restrictions and interpretations and the use of functional and assurance packages.
Clause 16 discusses the topic of use of automated tools in PP/ST development.
2 © ISO 2009 – All rights reserved

6 An overview of PPs and STs
6.1 Introduction
This clause provides an overview of the roles of PPs and STs in information security evaluation using
ISO/IEC 15408.
6.2 Audience
This Technical Report is intended for use by two distinct audiences:
a) IT professionals with security knowledge (e.g. security officers/architects with an understanding of a
security requirement) but who are not experts in information security evaluation, and who have no prior
knowledge of ISO/IEC 15408;
b) Experts in information security with good knowledge of ISO/IEC 15408, who are engaged in developing
PPs and STs as part of their professional activities.
If you fall into the former category, this clause should provide you with the information you need to understand
the purpose and structure of PPs and STs. It should also provide you with the background information you
will need to read and understand PPs and STs, and to identify their relevance and correctness with respect to
your particular circumstances. Following clauses will explain the contents of each part of PPs and STs in
detail, but are oriented towards the production of such documents and assume knowledge of ISO/IEC 15408.
If you are an expert, you should already be familiar with the contents of this clause. Subsequent clauses will
provide you with methodologies, techniques and practical tips that you can use to prepare PPs and STs in an
efficient yet consistent manner.
If you are not an expert in information security, and you need to produce a PP or ST, this Technical Report will
help you do so. However, you will also need to find, read and understand published examples of PPs or STs
similar to your requirement. You should also consider calling on the services of others who do have the
necessary specialist knowledge and experience.
6.3 The use of PPs and STs
6.3.1 Introduction
The main use of ISO/IEC 15408 is to assess the security of IT products. The term “IT product” is never
actually defined in ISO/IEC 15408; however, it can be understood to cover any type of entity built using
information technology, whether a complete IT system used exclusively by one organisation, or a COTS
package created by a product manufacturer for sale to many different and unrelated customers. In this
Technical Report, when we talk about IT products, or just products, our advice is intended to apply to all such
entities. Where the scope of our advice is limited to a particular type of product, we talk about systems, or
COTS products, or some other explicitly specific wording.
As IT products may be used in many ways, and in many types of environment, the notion of security will vary
with the product. The end result of an ISO/IEC 15408 evaluation is therefore never “this IT product is secure”,
but is always “this IT product meets this security specification”.
ISO/IEC 15408 has standardised security specifications to (among others):
- mandate specific content needed to assess a product against the security specification;
- allow comparison of security specifications of different products.
ISO/IEC 15408 recognises two different types of security specifications: Protection Profiles (PPs) and Security
Targets (STs). The difference between these two is best explained by the roles they are intended to play in a
typical product purchasing process, where a customer seeks to buy a product from a developer.
The notions of customer, developer and product are deliberately kept abstract. A customer is someone who
wants to buy a product. It can be a single individual, an organization, a group of organizations, a government
department etc. A developer is someone who wants to sell a product. It can be a single programmer, a small
company, a large company, a group of companies working together etc. Finally, a product could be anything
from a small software application or a smart card to a large operating system or a complete computer system
containing hundreds of distinct components.
When our customer wishes to buy a product, he has essentially two possibilities:
- The customer contacts a developer, specifies his needs, and the developer creates a product that is
specifically targeted towards that customer and exactly fulfils the demands of that customer. This may be
expensive but the customer gets what he wants. In the remainder of this section, we will call this a
specification-based purchasing process.
- The customer selects a product from a number of existing products. This is probably cheaper, but the
resulting product may or may not exactly fulfil the customer’s needs. In the remainder of this section we
will call this a selection-based purchasing process.
When IT security is important, these purchasing processes have an added difficulty. For the average
customer it is:
- hard to define what kind of IT security he needs;
- harder to determine whether the IT security that a given product claims to have is useful or sufficient to
meet his needs;
- and even harder to determine that if a product claims to have security properties, that these claims are
true.
To assist a customer through a purchasing process and address the difficulties listed above, an evaluation of
the product using ISO/IEC 15408 may be useful, and in this case, Protection Profiles and Security Targets
play an important role. In the next two subsections, we will show how an evaluation may assist each type of
process: specification-based and selection-based.
Of course, IT products do not work in isolation. The product is used by the customer in an operational
environment, which may contain security measures of its own. Sometimes the product will make assumptions
that certain types of security features exist within that operational environment. These assumptions will also
form part of the PP or ST.
6.3.2 Specification-based purchasing processes
6.3.2.1 Overview
In a specification-based purchasing process, a customer writes a specification, provides this specification to a
developer, and the developer then creates a product based on this specification. In more detail, the following
steps must be performed:
a) The customer must determine his security requirements informally;
b) The customer must transform these informal security requirements into a more formal specification
suitable for use by a developer;
c) The developer must build a product based on this specification.
4 © ISO 2009 – All rights reserved

In the end, the customer wants to know that “this product is useful for me”. Therefore the quality of each of
these steps is important.
6.3.2.2 Informal security requirements
The process of determining informal security requirements, that is determining “what is my security problem,
and how should I address it?” is outside the scope of ISO/IEC 15408 and therefore outside the scope of this
Technical Report. However, this does not mean that this is unimportant or easy by any means.
Nevertheless, ISO/IEC 15408 assumes that the customer is capable of defining his or her informal security
requirements. If this is done incorrectly, the product that is purchased in the end may not meet the true
security requirements.
Customer requirements, once written down, often have a number of problems associated with them,
especially in the area of security. Customer requirements are typically:
a) Incomplete (not all the requirements are present). For example, important threats that the product should
counter are missing;
b) Not embedded: They are insufficiently tuned to the specific environment in which the product has to
function, or do not describe this environment clearly enough.
c) Implicit: Some product requirements have consequences, but these consequences are themselves not
included. The developer may not take these implicit requirements into account;
d) Not testable: The requirements are phrased ambiguously, so that it is not possible to verify whether a
product meets the requirement or not;
e) Too detailed: The implementation has in fact already been written down but not the reason why this was
chosen. If, in a later stage, the requirements change it is often unclear how these changes should be
made;
f) Filled with ambiguous terms: like "the communication shall be secure" without defining what "secure"
means;
g) Inconsistent: The requirements are internally self-contradictory.
Providing these customer requirements to a developer in a raw form will generally lead to problems, as the
developer may misunderstand them. Security evaluation may lead to even more problems, since evaluators
may interpret requirements differently from both the customer and the developer.
For these reasons, an important step in the whole specification-based purchasing process is the formalising of
customer requirements. For security requirements based on ISO/IEC 15408, this formalisation takes place
using a so-called Protection Profile (PP). A PP is in essence a document that defines the customer’s security
requirements in a formalised, standardised way.
6.3.2.3 Using PPs as specifications
PPs are typically written by large organizations, groups of organizations, government departments, etc. as
they require a significant investment of effort.
A PP contains many sections, but as a security specification, the most important is the “security functional
requirements”. Using ISO/IEC 15408, it is mandatory to write these requirements in a special language,
defined within that International Standard. Use of this language ensures that the Protection Profile is:
a) not ambiguous: the language contains well defined terms, so that a developer can understand the
requirements and interpret them correctly.
b) testable: the language is defined to contain only testable terms. Thus, it will be possible to assess in a
later stage whether the product actually fulfils the PP.
c) not too detailed: the language enforces a certain level of abstraction. This closely follows what should be
the consumer requirements: the consumer wants something to be done but does not want to worry how
this is accomplished.
d) more complete: the language contains several constructions ("if this functionality is required then this
other functionality is also required") to help ensure that implicit requirements are included.
6.3.2.4 Building a product from a PP
The customer can now give the PP, i.e. his formalised requirements, to one or more developers. Each
developer uses this PP as a starting point for the development of a product. As a first step in this process he
writes a Security Target (ST).
An ST used for this purpose is very similar to a PP, but where a PP defines the customer requirements and is
in principle written by the customer, the ST is a product specification and written by the developer.
The developer can of course not deliver an arbitrary ST as a reaction to the customer’s PP: his ST has to
conform to the PP. This means that the product has to cover all the customer requirements, but:
- The ST may specify more than the PP: the product will offer more security functionality than the customer
requirements (note: this extra functionality is not allowed to be incompatible with the PP), because, for
example, the product will be sold to several customers, each with similar but slightly different
requirements, or because the product is derived from an existing, standard product.
- The ST contains more detail than the PP: while the PP explains “what” shall be secured, the ST also
explains “how”: the developer points out, in general terms, how he will implement the customer
requirements.
A PP may permit the ST author flexibility to offer something that is equivalent but different in terms of security
functionality provided – for more details, see 6.5.6.
The ST defines for the developer the security functionality his product should deliver and serves as a
“Specification of Security Requirements” for the rest of the development process.
The result of the development process should be a product that can be delivered to the customer, who in turn
can install it and use it. Naturally, this product should perform as described in the ST.
6.3.2.5 The role of evaluation in a specification-based purchasing process
Until now, we have only described the role of the customer and the role of the developer in this process.
Based on this process, the developer could simply say to the customer (without further evidence):
a) my ST complies with your PP;
b) my product complies with my ST;
c) therefore, my product complies with your PP and meets your requirements.
If the customer accepts these statements, the process ends here.
However, if a customer requires independent verification of these statements, he can enlist a third party (an
evaluation facility) to check these claims of compliance by performing an ISO/IEC 15408 security evaluation.
In this process, an evaluation facility uses the PP, the ST, the product and ISO/IEC 15408 to assess two
statements:
6 © ISO 2009 – All rights reserved

a) the ST complies with the PP;
b) the product complies with the ST.
Note that two issues are still left open, despite evaluation.
a) The translation of the customer's informal security requirements to a Protection Profile. As said earlier,
this process falls outside the scope of ISO/IEC 15408, but if this is not done correctly, the PP will not
match the customer's requirements and therefore the product will likely also not match the customer's
requirements.
b) Evaluation does not “prove” compliance. An ISO/IEC 15408 evaluation will never provide an absolute
guarantee that the product meets the PP, it can only deliver a certain degree of assurance depending on
the depth and scope of evaluation as specified in the PP or ST.
6.3.3 Selection-based purchasing processes
6.3.3.1 Overview
The previous subsection discussed a customer delivering a specification and a developer implementing that
specification. This subsection discusses the situation where a customer does not have the luxury of having a
product made for him: he has to select from existing products. Therefore the purchase is no longer based on
compliance to a formalised statement of customer requirements (i.e. a PP), but on comparison of existing
products by the customer.
In a selection-based purchasing process of an IT product:
a) a developer must produce a product and a specification of this product and provide the specification to
the customer.
b) the customer must determine from the specification (perhaps by comparing the specification to
specifications from other developers) whether the specified product is the most suitable product for him to
purchase.
As the customer in the end wants to know that “this product is suitable for me”, the quality of each of these
steps is important.
6.3.3.2 Using a specification provided by the developer
In selection-based purchasing processes, the customer has to use a specification provided by the developer.
If this specification is informal, the same potential disadvantages hold as for the informal customer
requirements discussed in 6.3.2.2. For this reason, this specification needs to be formalised as well. For this
purpose ISO/IEC 15408 uses the Security Target (ST) as already discussed in 6.3.2.4. The ST here is
identical to the ST discussed in 6.3.2.4, with one obvious difference: since it is not based on a customer’s PP,
it cannot claim compliance to such a PP (it may claim compliance to other types of PP – see 6.3.4 below).
Because the developer does not know a specific customer’s requirements, he will have to make an estimate
of what the market wants and codify this in the ST. This does therefore not necessarily match with any
customer’s specific requirements.
The developer builds his product according to the ST: this process is similar to that described for specification-
based purchasing processes.
6.3.3.3 Comparing Security Targets by the developer
The customer can now compare the STs of a number of products and select the one that best matches his
requirements (probably also considering non-security requirements such as price). This means that he will
still somehow have to find out what his informal security requirements are (see 6.3.2.2) and compare these
with the STs offered to him. If one or more products match his requirements, he is done. If this is not the
case, he will either have to choose the “closest” product or find some other solution (i.e. change his
requirements).
As already stated in 6.3.2, the process of deriving informal customer security requirements falls outside the
scope of ISO/IEC 15408 and this Technical Report. Comparing requirements and an ST also falls outside the
scope of ISO/IEC 15408, although guidance on this topic will be found in later clauses of this Technical
Report.
6.3.3.4 The role of evaluation in a selection-based purchasing process
Similar to the specification-based purchase process, the developer could simply claim that his product meets
the ST and if the customer accepts this claim, the process ends here.
However, it is customary for the developer to offer a certificate confirming that an independent third party (an
evaluation facility) has validated the ST, and then performed an ISO/IEC 15408 security evaluation to confirm
that the product indeed meets the ST. It is even possible for the customer to commission the evaluation if he
or she believes it to be essential and the developer has not done so.
Note that using evaluated products still leaves two issues open:
a) Proving equivalence of the customer’s informal security requirements and the Security Target. As said
earlier, this process falls outside the scope of ISO/IEC 15408, but if it is not done correctly, the ST may
not match the customer's requirements, and therefore the product may not match the customer’s
requirements either.
b) Evaluation does not “prove” compliance. A ISO/IEC 15408 evaluation will never provide a perfect
guarantee that the product meets the ST, it can only deliver a certain degree of assurance depending on
the depth and scope of evaluation as specified in the ST.
6.3.4 Other uses of PPs
Protection Profiles have other uses. For example, standards bodies or vendor associations may specify PPs
as best practice minimum security standards for specific types of applications. Governments and trade
associations may mandate their use. Where these exist, both customers and developers are likely to require
compliance with such PPs, as well as requiring or offering additional security functionality to meet their own
specific needs.
Organisations specifying or mandating PPs for such purposes have an onerous responsibility to ensure that
such PPs are minimal (they ask for no more than is absolutely necessary) and realistic (they do not ask for
functionality or assurances that are not achievable by developers).
A PP may also be developed to express the need for a certain type of security product, even though it is
recognised that at the time of publication, no such products (yet) exist. If you are a product developer, treat
such PPs with caution. By the time you have developed a suitable product, the requirement may be obsolete
or the sponsors of the PP may no longer want to buy your product because they have found other ways to
meet their requirements.
Finally, PPs are security requirement specifications. Beware of their attempted misuse to specify other types
of requirements which, i
...