Guide on the production
of Protection Profiles
Reference:
ISO/IEC TR 15446 Information technology - Security
techniques - Guide on the production of protection profiles
and security targets (Editor’s Report)
1
TM8104 IT Security Evaluation
Autumn 2009
Outline
Introduction
The Protection Profile (PP)
The development process
Guidance on producing a Protection Profile
2
TM8104 IT Security Evaluation
Autumn 2009
Definitions and abbreviations
DBMS – Database Management System
EAL – Evaluation Assurance Level
ISO/IEC 15408 – ”Common Criteria”
OSP – Organisational Security Policies
PP
– Protection Profile
SAR – Security Assurance Requirements
SFR – Security Functional Requirements
SOF – Strength of Function
ST
– Security Target
TOE – Target of Evaluation
TTP – Trusted Third Party
3
TM8104 IT Security Evaluation
Autumn 2009
Introduction
The purpose of a Protection Profile (PP) is to state a
security problem rigorously for a given collection of
systems or product – known as Target of Evaluation (TOE)
– and to specify implementation-independent security
requirements to address that issue.
The Guide provides detailed guidance relating to the
various parts of a PP or ST, and how they interrelate.
This presentation, will focus on Protection Profiles and
NOT Security Targets. However, the guidance for a ST is
very similar to the PP guidance.
4
TM8104 IT Security Evaluation
Autumn 2009
The Protection Profile (PP)
5
TM8104 IT Security Evaluation
Autumn 2009
The development process
PPs are often developed in a logical ”top-down” manner
1. identify the security concerns
2. state the security objectives
3. develop the IT security requirements
During an iterative development process, new requirements
might surface, due to:
- new threats may be identified
- organisational security policies may change
- cost and time constraints may impose changes in
division of responsibility between the TOE and its
environment
- changes in intended attack potential
The TOE might be an already developed type of product –>
”bottom-up” approach.
6
TM8104 IT Security Evaluation
Autumn 2009
The Protection Profile (PP)
7
TM8104 IT Security Evaluation
Autumn 2009
The TOE security environment
Purpose: ”define the nature and scope of the definition of the
environment in which the TOE is intended to be used and the
manner in which it is expected to be employed”
8
TM8104 IT Security Evaluation
Autumn 2009
Identify and specify the assumptions
”What assumptions can be made about the TOE security
environment and the scope of the security concerns?”
•
•
•
•
Aspects relating to the intended usage of the TOE
Environmental protection of any part of the TOE
Connectivity aspects
Personal aspects
It is unlikely that you will completely identify all
assumptions in a single attempt!
9
TM8104 IT Security Evaluation
Autumn 2009
The TOE security environment
10
TM8104 IT Security Evaluation
Autumn 2009
Identify and specify the threats
ISO/IEC 15408: the PP must contain a
description of any threat to the asset against
which protection will be required
However the statement of threats may be omitted
if the security objectives is derived solely from
the OSP and assumptions
Risk analysis may be/is an important tool!
11
TM8104 IT Security Evaluation
Autumn 2009
Identifying the threats
Definition of ”threat” (ISO/IEC 15408):
an undesirable event, which is characterised in
terms of a threat agent, a presumed attack
method, any vulnerabilities that are the
foundation for the attack and identification of the
asset under attack
We need to identify
- the assets
- the threat agents
- the attack methods
12
TM8104 IT Security Evaluation
Autumn 2009
Identifying the assets
Definition of ”assets” (ISO/IEC 15408):
information and resources to be protected by the
countermeasures of a TOE
Assets typically take the form of information
which is stored, processed and transmitted by ITsystems
Assets may be external to the TOE (eg. firewalls)
13
TM8104 IT Security Evaluation
Autumn 2009
Identifying the threat agents
Threat agents may either be human or non-human
To identify a human threat agent, consider:
• who might want to compromise the assets and for
what reasons
• who could gain access to the IT-system
• their possible level of technical expertise,
opportunities, resources and motivation
Non-human sources of threats and threats arising
from human sources unintentionally should also be
considered.
14
TM8104 IT Security Evaluation
Autumn 2009
Identifying the attack methods
Will be based on knowledge about the TOE
security environment
Potential vulnerabilities to the assets which a
threat agent could exploit
The capabilities of attackers who have access
to the TOE security environment
A vulnerability analysis of the TOE security
environment can be useful. However, it may not
identify all vulnerabilities.
15
TM8104 IT Security Evaluation
Autumn 2009
Risk analysis
Risk analysis may be helpful for threat
identification.
Such methods may consider the probability and
consequence of compromise of the assets,
taking into account:
- the possible attack methods identified
- the likelihood of the attack to succeed
- the consequences of any damage that may be
caused
Other constraints, eg. legal requirements and cost
16
TM8104 IT Security Evaluation
Autumn 2009
Specifying the threats 1 (2)
The specification of threats in a PP should be clear:
- include the threat agent
- include the asset subject to the attack
- include the attack method employed
Eg: An authorised user of the TOE might gain
unauthorized access to information by
impersonating another authorised user
17
TM8104 IT Security Evaluation
Autumn 2009
Specifying the threats 2 (2)
The specification of threats in a PP should be
concise:
– the threat descriptions should be disjoint
– specify all threats at the same level of detail
– each threat should be unique labelled for ease of
reference
18
TM8104 IT Security Evaluation
Autumn 2009
Completing the statement of threats
The threats that are of principal interest are those that will
be countered by the TOE
However, for completeness, the PP may need to include
some threats that are not adressed by the TOE, eg:
- physical attack against the TOE
- abuse of trust by highly privileged users
- improper administration and operation of the TOE
The PP author can choose whether to include these in the
enviromental assumptions or in the statement of threats
19
TM8104 IT Security Evaluation
Autumn 2009
The TOE security environment
20
TM8104 IT Security Evaluation
Autumn 2009
Identify and specify the Organisational
Security Policies (OSP)
An OSP is defined as one or more rules, procedures and practices
imposed by an organisation
The OSP may be omitted if the security objectives are derived
soley from the threats and assumptions
Or a combination can be used
(but be careful not to restate the same threats)
General rule:
• Specify OSPs where the TOE is intended for use by a specific type
of organisation
• There is a need for the TOE to implement a set of rules that cannot
be sensibly included within or implied by a threat description (eg.
identification of acces control rules or information flow control rules)
21
TM8104 IT Security Evaluation
Autumn 2009
The Protection Profile (PP)
22
TM8104 IT Security Evaluation
Autumn 2009
The security objectives
The security objectives provide a concise
statement of the intended response to the security
problem
•Security objectives for the TOE
•Security objectives for the environment
23
TM8104 IT Security Evaluation
Autumn 2009
Security objectives for the TOE (1)
...states what the responsibility of the TOE is in countering the
threats and in supporting the OSP.
• The security objective is intended to be concise. To ”reach” an
appropriate level of detail, you need a strict balance between:
• The security objectives for the TOE should be implementationindependent
• Ensure that the defined security objectives do not just repeat the
information contained within the threats and the OSP
When you construct the rationale for the security objectives and
the IT security requirements, you will see if you have
succeeded.
24
TM8104 IT Security Evaluation
Autumn 2009
Security objectives for the TOE (2)
Three types of security objective can be identified to address the
identified threats:
• preventive objectives (prevent or limit threats)
• detective objectives (detect and monitor events)
• corrective objectives (take action on undesirable events)
An example of a preventive security objective is:
The TOE will ensure that each user is uniquely identified and
that the claimed identity is authenticated, before the user is
granted accesss to the TOE facilities.
25
TM8104 IT Security Evaluation
Autumn 2009
Security objectives for the
environment (1)
...will have to be identified to address those aspects of security
concerns that the TOE will not (or cannot) be expected to do
• counter threats that are not countered by the TOE
• help satisfy OSPs that are not fully satisfied by the TOE
• ensure that the environmental assumptions are satisfied
Eg. non-IT security objective for the environment:
• objectives for education and training of administrators and users
Eg. IT security objective for the environment:
• a security objective for an underlying operating system to
identify and authenticate TOE users.
26
TM8104 IT Security Evaluation
Autumn 2009
Security objectives for the environment
(2)
An appropriate starting point would be to compile a list of security
objectives by taking each threat, OSP and assumption that is
not fully addressed by the TOE and
Add a new security objective for the environment , or
If an appropriate one already has been identified, map an existing
security object to that aspect
The list should be redefined when you formulate the security
objectives rationale.
The statement of security objective should be reviewed to ensure
that the division of responsibilities between the TOE and its
environment is appropriate.
27
TM8104 IT Security Evaluation
Autumn 2009
The Protection Profile (PP)
28
TM8104 IT Security Evaluation
Autumn 2009
The security requirements
SFR – identify the requirements for security functions which the
TOE must provide to ensure that its security objectives are
achieved
SAR – identify the required level of assurance in the
implementation of the SFRs
SR IT-environment – define any functional and assurance
requirements to be satisfied by the IT-environment (optional)
29
TM8104 IT Security Evaluation
Autumn 2009
Security functional requirements
Having defined the security objectives for the TOE
in response to the identified security concerns,
you need to elaborate how these security
objectives are met. This is done by selecting
appropriate SFR at a component level.
30
In the selection process it will be helpful to
distinguish between
principal SFRs – which directly satisfies the
identified security objectives for the TOE
supporting SFRs – to provide support for the
principal SFRs
Autumn 2009
TM8104 IT Security Evaluation
Selecting SFRs
For each security objective for the TOE, identify the principle SFRs
which directly satisfy them
Once a complete set of principle SFRs has been establish, an
iterative process is used to identify a complete set of supporting
SFRs.
All SFRs should (where possible) be expressed using functional
components from Part 2 of ISO/IEC 15408.
31
TM8104 IT Security Evaluation
Autumn 2009
Identifying supporting SFRs
Three stages when identifying the complete set of supporting SFRs
Identify the additional SFRs needed to satisfy the dependencies of all
principal SFRs
Identify any additional SFRs that are necessary to ensure that the security
objectives for the TOE are achieved
Identify the SFRs needed to satisfy the dependencies of those supporting
SFRs selected during stage 2 and 3 (?)
This is usually an iterative process!
Eg. The PP includes a security objective for the TOE to response on
detection of events indicating security violation
a principal SFR based on FAU_ARP.1 (Security Alarms) component
FAU_ARP.1 has a dependency on FAU_SAA.1 (Potential Violation
Analysis) which should also be included as a supporting SFR
FAU_SAA.1 has a dependency on FAU_GEN.1 (Audit Data Generation)
and so on.......
32
TM8104 IT Security Evaluation
Autumn 2009
Operations on SFRs
Permitted operations on SFRs:
Assignment – specification of an identified parameter
Iteration – multiple use of the same functional component to
express different requirements
Selection – specification of one or more elements from a given list
Refinement – addition of details to the security requirements
For ”assignment” and ”selection” the guidance suggest that the
operations should be partially completed.
The ”iteration” can be used where the clarity of the PP can be
enhanched, eg. to break down a complex SFR into distinct
functional requirements
33
TM8104 IT Security Evaluation
Autumn 2009
Additional advices on SFRs
The guide also give advices on:
How to specify audit requirements
How to specify management requirements
How to specify SOF (Strength of Function)
How to specify SFRs not included in part 2 of
ISO/IEC 15408
and so on....
34
TM8104 IT Security Evaluation
Autumn 2009
Security Assurance Requirements
The selection of SARs will require the balancing if several
factors, e.g: the value of the assets to be protected and the
perceived risk of compromising those assets
• technical feasability
• likely development and evaluation costs
• perceived market requirement (in the case of products)
The selection of the SARs will be relatively straight-forward if
choosing an appropriate assurance packet (eg. an EAL). It is
possible to include augmented SARs to the packet in order to
ensure that the security objectives are satisfied.
35
TM8104 IT Security Evaluation
Autumn 2009
Additional advices on SARs
The guide also gives advices on:
How to perform operations on SARs (iterations
and refinements)
How to specify SARs not included in Part 3 of
ISO/IEC 15408 in a PP
36
TM8104 IT Security Evaluation
Autumn 2009
TOE environment
SR on the IT environment:
These should be specified, where feasible, using
ISO/IEC 15408 functional and assurance
components
SR for the non-IT environment (optional):
The guidance do not provide any clear
reommendations
37
TM8104 IT Security Evaluation
Autumn 2009
The Protection Profile (PP)
38
TM8104 IT Security Evaluation
Autumn 2009
PP rationale
Purpose:
” to demonstrate that a conformant TOE provides an effective set of
IT security countermeasures within the TOE security environment”
39
TM8104 IT Security Evaluation
Autumn 2009
Security objectives rationale
First, show that the security objectives are necessary by (eg):
Cross-reference the threats, OSPs and assumptions against the
security objectives which are intended to adress them. It should be
evident that:
Each security objective covers at least one threat, OSP or assumption
Each threat, OSP and assumption is covered by at least one security
objective
Secondly, demonstrate that the security objectives are sufficient to
meet the security concerns by providing informal arguments to
supplement the cross-reference information
For each threat, give informal arguments why the identified security
objectives will provide for effective countermeasures (detected and
recovered, prevented or reduced) towards the threats
Similarily, for each identified OSP or assumption, give informal
arguments…
40
TM8104 IT Security Evaluation
Autumn 2009
Security requirements rationale
Show that the IT security requirements (in particular the SFRs)
are suitable to meet the identified security objectives and
thereby address the security concerns.
As with the security objectives, you need to demonstrate that
the security requirements are both necessary and sufficient.
Cross-reference each security objective for the TOE against the
SFR which satisfies it and check that
- each SFR addresses at least one security objective
- each security objective for the TOE is adressed by at least one
SFR
Supplement the cross reference-information with informal
arguments for the sufficiency.
41
TM8104 IT Security Evaluation
Autumn 2009
Security requirements rationale
It is necessary to show that the assurance requirements (SAR) are
appropriate for the TOE, ie:
sufficient to address the security objectives and thus meet the
security concerns
not excessive (given the statement of security
objectives/concerns)
attainable (it should be technically feasible for the TOE to attain
the defined assurance requirements)
It should also be shown that:
The strength of functions (SOF) are appropriate
The security requirements (in particular the SFRs) are mutually
supportive
The assurance measures satisfy the assurance requirements
(SAR)
The IT security functions satisfy the SFR
42
TM8104 IT Security Evaluation
Autumn 2009
The guide also includes
PPs for composite and component TOEs
Functional packages
Assurance packages
Appendices
- A summary in form of a checklist
- Example threats, OSPs, assumptions and security objectives and
identifies appropriate ISO/IEC 15408 functional components
- Special guidance for PPs which implement cryptographic
functionality
- Application of the guidance in various of contexts, using worked
examples for different types of TOE (firewall, DBMS, TTP)
43
TM8104 IT Security Evaluation
Autumn 2009
TM8104 Assignments 2009:
• CEM Ver. 3.1 Ch.8, Evaluation Process and Related Tasks
– Mohamed, 2009-10-22
• CEM, Ver. 3.1 Chapter 10: Security Target Evaluation
– Pern, 2009-10-29
• CEM, Ver. 3.1 Annex A, General Evaluation Guidance and
Annex B, Vulnerability Assessment
– Jostein, 2009-11-05
• Network Intrusion Prevention System PP, V1.1
– Åsmund, 2009-11-26
• Firewall Protection Profile V2.0
– Mark, 2009-12-03
• Electronic signature Creation Application PP
– Benedikt, 2009-12-17
44
TM8104 IT Security Evaluation
Autumn 2009