ETSI TR 187 023 V1.1.1 (2012-03)

Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); Security Assurance Profile for Secured Telecommunications Operations Statement of needs for security assurance measurement in operational telecom infrastructures;

DTR/TISPAN-07049-NGN

General Information

• Status: Published
• Publication Date: 14-Mar-2012
• Technical Committee: TISPAN 7 - TISPAN Security
• Current Stage: 12 - Completion
• Due Date: 16-Mar-2012
• Completion Date: 15-Mar-2012

Standards Content (Sample)

Technical Report
Telecommunications and Internet converged Services and
Protocols for Advanced Networking (TISPAN);
Security Assurance Profile for
Secured Telecommunications Operations;
Statement of needs for security assurance measurement
in operational telecom infrastructures

2 ETSI TR 187 023 V1.1.1 (2012-03)

Reference
DTR/TISPAN-07049-NGN
Keywords
assurance, security, trust services
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88

Important notice
Individual copies of the present document can be downloaded from:
http://www.etsi.org
The present document may be made available in more than one electronic version or in print. In any case of existing or
perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF).
In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive
within ETSI Secretariat.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
http://portal.etsi.org/tb/status/status.asp
If you find errors in the present document, please send your comment to one of the following services:
http://portal.etsi.org/chaircor/ETSI_support.asp
Copyright Notification
No part may be reproduced except as authorized by written permission.
The copyright and the foregoing restriction extend to reproduction in all media.

© European Telecommunications Standards Institute 2012.
All rights reserved.
TM TM TM
DECT , PLUGTESTS , UMTS and the ETSI logo are Trade Marks of ETSI registered for the benefit of its Members.
TM
3GPP and LTE™ are Trade Marks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
GSM® and the GSM logo are Trade Marks registered and owned by the GSM Association.
ETSI
3 ETSI TR 187 023 V1.1.1 (2012-03)
Contents
Intellectual Property Rights . 5
Foreword . 5
Introduction . 5
1 Scope . 6
2 References . 6
2.1 Normative references . 6
2.2 Informative references . 6
3 Definitions and abbreviations . 7
3.1 Definitions . 7
3.2 Abbreviations . 7
4 Risk, Trust and Assurance . 8
4.1 Operational Security Assurance . 8
4.2 Concepts . 10
4.2.1 The Target of Measurement (TOM) . 10
4.2.2 The Security Assurance Views (SAV) . 10
4.3 General use of Assurance Profiles . 11
4.3.1 How an AP should be used . 11
4.3.2 What an AP is not intended to provide . 11
4.4 Implementing an assurance program using Assurance Profiles . 12
4.4.1 Assurance program definition . 12
4.4.2 Assurance program implementation methodology . 12
4.4.3 Use of Assurance Profile . 14
5 Building an Assurance Profile . 15
6 Assurance Profile components . 17
6.1 Assurance profile reference . 17
6.2 Target of Measurement . 18
6.2.1 Dependencies . 18
6.2.2 Component requirements . 18
6.2.3 Explanation . 18
6.2.4 Example of application . 19
6.3 Security Problem Definition . 20
6.3.1 Dependencies . 20
6.3.2 Component requirements . 20
6.3.3 Explanation . 20
6.3.4 Example of application . 20
6.4 Compliance Claims . 21
6.4.1 Dependencies . 21
6.4.2 Component requirements . 21
6.4.3 Explanation . 21
6.4.4 Example of application . 22
6.5 Security Objectives. 22
6.5.1 Dependencies . 22
6.5.2 Component requirements . 22
6.5.3 Explanation . 22
6.5.4 Example of application . 22
6.6 Security Requirements . 23
6.6.1 Dependencies . 23
6.6.2 Component requirements . 23
6.6.3 Explanation . 23
6.6.4 Example of application . 24
6.7 Measurement Objectives . 24
6.7.1 Dependencies . 24
ETSI
4 ETSI TR 187 023 V1.1.1 (2012-03)
6.7.2 Component requirements . 24
6.7.3 Explanation . 24
6.7.4 Example of application . 25
6.8 Measurement Requirements . 25
6.8.1 Dependencies . 25
6.8.2 Component requirements . 25
6.8.3 Explanation . 25
6.8.4 Example of application . 26
6.9 Security Assurance Views . 27
6.9.1 Dependencies . 27
6.9.2 Component requirements . 27
6.9.3 Explanation . 27
6.9.4 SAV Objects . 27
6.9.5 Metrics . 28
6.9.6 Example of application . 28
7 Claiming compliance with an Assurance Profile . 28
History . 30

ETSI
5 ETSI TR 187 023 V1.1.1 (2012-03)
Intellectual Property Rights
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (http://ipr.etsi.org).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Foreword
This Technical Report (TR) has been produced by ETSI Technical Committee Telecommunications and Internet
converged Services and Protocols for Advanced Networking (TISPAN).
Introduction
An Assurance Profile (AP) document is a formalization of needs in which equipment vendors, solution providers,
service integrators, operators and service providers or even final users can define a common set of security assurance
measurement requirements for a service infrastructure. An Assurance Profile gives a means of referring to this set,
and facilitates future evaluation against these needs.
ETSI
6 ETSI TR 187 023 V1.1.1 (2012-03)
1 Scope
The present document presents the structure of the Assurance Profiles.
2 References
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references,only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
Referenced documents which are not found to be publicly available in the expected location might be found at
http://docbox.etsi.org/Reference.
NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee
their long term validity.
2.1 Normative references
The following referenced documents are necessary for the application of the present document.
Not applicable.
2.2 Informative references
The following referenced documents are not necessary for the application of the present document but they assist the
user with regard to a particular subject area.
[i.1] ISO/IEC 15408: "Information technology -- Security techniques -- Evaluation criteria for IT
security (also known as Common Criteria)".
[i.2] ETSI TS 187 016: "Telecommunications and Internet converged Services and Protocols for
Advanced Networking (TISPAN); NGN Security; Identity Protection (Protection Profile)".
[i.3] ETSI TR 187 002: "Telecommunications and Internet converged Services and Protocols for
Advanced Networking (TISPAN); TISPAN NGN Security (NGN-SEC); Threat, Vulnerability and
Risk Analysis".
[i.4] ISO 27005: " Information technology -- Security techniques -- Information security risk
management".
[i.5] Directive 95/46/EC of the European Parliament and of the Council of 24 October 1995 on the
protection of individuals with regard to the processing of personal data and on the free movement
of such data.
[i.6] Directive 2002/58/EC of the European Parliament and of the Council of 12 July 2002 concerning
the processing of personal data and the protection of privacy in the electronic communications
sector (Directive on privacy and electronic communications).
[i.7] Directive 2006/24/EC of the European Parliament and of the Council of 15 March 2006 on the
retention of data generated or processed in connection with the provision of publicly available
electronic communications services or of public communications networks and amending
Directive 2002/58/EC.
[i.8] COM 96/C 329/01: Council Resolution of 17 January 1995 on the lawful interception of
telecommunications.
[i.9] ETSI TS 102 165-1: "Telecommunications and Internet converged Services and Protocols for
Advanced Networking (TISPAN); Methods and protocols; Part 1: Method and proforma for
Threat, Risk, Vulnerability Analysis".
ETSI
7 ETSI TR 187 023 V1.1.1 (2012-03)
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the following terms and definitions apply:
operational security assurance: ground for confidence that security controls are running as expected in an operational
system.
security assurance measurement requirements: elements of evidence that need to be measured within a service
infrastructure to gain assurance that the security controls are running as expected
Security Assurance View (SAV): specifically focused representation of the security assurance measurement results.
Target of Measurement (TOM): minimal part of a service infrastructure where security controls are implemented and
for which continuous security assurance measurement is required
3.2 Abbreviations
For the purposes of the present document, the following abbreviations apply:
AAA Authentication, Authorization and Accounting
AP Assurance Profile
AP_SSO Assurance Profile_Security
CC Common Criteria
CCL Compliance Claims
CPE Customers Premises Equipment
CPE Customers Premises Equipment
ECN Electronic Communication Network
ECN Electronic Communication Network
ECS Electronic Communication Service
ECS Electronic Communication Service
HR Human Resources
IO Infrastructure Object 4 General concepts and use of Assurance Profiles
IPTV Internet Protocol TeleVision
IP-VPN Internet Protocol-Virtual Private Network
MR Measurement Requirement
NGN Next Generation Network
NGN-R NGN-Release
NOC Network Operations Center
NT Network Termination
NT Network Termination
OS Operating System
OSR Operational Security Requirements
SAV Security Assurance View
SAV Security Assurance Views
SLA Service Level Agreement
SOC Security Operations Center
SPD Security Problem Definition
SSO System Security Objectives
TOE Target of Evaluation
TOM Target of Measurement
TSF ToE Security Function
TVRA Threat Vulnerability Risk Analysis
ETSI
miminniimmiizzee tthathat t thhee
MMeeaassuurreemmeenntt
tthahat tht thrreeaatteen tn thhee
8 ETSI TR 187 023 V1.1.1 (2012-03)
4 Risk, Trust and Assurance
An assurance profile is the expression of requirements to deploy a security assurance program in order to measure,
monitor and maintain security assurance of a telecommunications infrastructure for a particular service.
Such a program can be illustrated in the following diagram where assurance management is a continuation of risk
management and an input for trust management. We address in the present document security assurance by
measurement: infrastructures measured by metrics that generate evidence that leads to assurance.
InInffrraasstrtruucctuturreess
AsAssusurarannccee
MMaananagegemmeentnt
MeMettrriiccss RiRisskkss
RRiisskk M Maananagegemmeentnt
EvEviiddeennccee CCountounteerrmmeeaassurureess
TTrrusustt m maananagegemmeentnt
AsAsssuurraannccee
ConConffideidennccee
whwhiicchh g giivveess
Figure 1: Risk, Assurance and Trust
4.1 Operational Security Assurance
We define operational security assurance, as ground for confidence that security controls are running as expected in an
operational system; this is illustrated in figure 2.
ETSI
MMoonniittoorriinngg
memeaasusureredd b byy
AAssssiissttaancncee
wwhhiicchh lleeaaddssttoo that generate
that generate
9 ETSI TR 187 023 V1.1.1 (2012-03)
Inherent Risks
Risks
Known/identified Risks
Management
Security Objectives / Security Policy
ISO 27005
Residual risks
Design
TVRA
Implementation
Security Controls (Security Architecture)
Implementation drift ISO 15408
Deployment
Common Criteria
Deployed Security Controls
Deployment drift
Operational Security
Running Security Controls
Assurance
System Operational drift
Operation
Operational Security Assurance:
Are Security Controls running as expected?
OK OK OK OK OK OK NOK NOK
Target of Measurement
Figure 2: Operational Security Assurance definition
Operational security assurance is the last step in the overall security life cycle process. Figure 2 presents the different
steps and how security assurance is related to all of them. Figure 2 also shows how some of the most relevant standards
are related to these different steps.
The first step is called risk management. A service infrastructure is exposed to threats and is subject to vulnerabilities
(inherent risks). Managing risks consists in first identifying those risks (risk assessment) and then deciding the ones that
can be covered by security objectives and those that are considered residual risks (risk treatment and risk acceptance).
There are several standards concerned with risk management e.g. ISO 27005 [i.4] and ETSI TVRA [i.9] are some of the
most appropriate and used standards related to IT and telecommunications infrastructures.
The second step is the design and implementation of security controls that will lead to the security architecture. The
drift that can occur is called implementation drift and can be measured with ISO 15408 standards [i.1] that brings
assurance that the implemented system achieves expected security objectives.
The third step is the deployment phase where security architecture is deployed and configured. During this step,
implemented security controls can be deactivated or modified by configuration. Drift that can occur is called
deployment drift.
ETSI
10 ETSI TR 187 023 V1.1.1 (2012-03)
The last step is the operational phase. In this phase, an operational drift can occur: procedures could not be applied,
configuration of equipments could be modified, equipments could be down, services could be unavailable, etc. The
implementation of a security assurance program allows the evaluation (with more or less precision depending on the
assurance level) of this operational drift. To achieve and quantify this drift, measures are performed on the target of
measurement.
4.2 Concepts
4.2.1 The Target of Measurement (TOM)
An Assurance Profile (AP) refers to a particular service infrastructure. It defines a Target of Measurement (TOM) as the
minimal part of this infrastructure that needs to be measured continuously in order to evaluate the operational security
assurance for the service.
The Target of Measurement is in general the minimal set of elements that enforce or contributes to the security of the
service.
4.2.2 The Security Assurance Views (SAV)
The Assurance Profile introduces the concept of Security Assurance View (SAV). Each Security Assurance View,
defined in an Assurance Profile, gives a particular representation of the measurement results (i.e. information on the
operational security assurance of the service). An Assurance Profile contains one or several Security Assurance Views.
Each Security Assurance View has a specific focus (e.g. a regulation, a standard, a security policy or list of
requirements, etc.). Recommendations for Security Assurance Views are (but not limited to):
• A functional security assurance view: This type of view will represent operational security assurance
function by function (identification, authentication, access control, etc.). A functional security assurance view
can combine various functions or only focus on one function.
• A security policies assurance view: This type of view will represent operational security assurance policy by
policy (e.g. mandatory access control policy, personal authentication policies, secret distribution policy, etc.)
A security policy assurance view can combine different policies or only focus on one policy.
• A regulation/standard security assurance view: This type of view will represent assurance of compliance
for a specific regulation or standard. If the infrastructure is subject to several regulations/standards, the AP
may present one combined view of all regulation or a view by regulation.
• A geographical security assurance view: This type of view will present operational security assurance by
geographical area such as sites, country etc. This depends on the type of service and infrastructure deployment.
• A set of equipments security assurance view: This type of view will focus on a particular set of equipment
that need special attention or if, for example, the service infrastructure is so complex that it will be easier to
regroup equipment under different simpler view rather than a complex one.
• An application security assurance view: In this case, the AP will focus on a specific application of the
service infrastructure. For example in an IPTV service infrastructure, a specific view can be made for Video
On Demand application.
Figure 3 depicts the concepts of Target of Measurement and Security Assurance Views, showing the views as a
hierarchical structure. It should be noted that this is an illustrative example. The present document does not define any
mandatory way to describe Security Assurance Views.
ETSI
11 ETSI TR 187 023 V1.1.1 (2012-03)
Runs on
1. Service
2. Service infrastructure
Cr
A itica
P l In
fra
stru
ctu
re
Obj
ect
s
T
3. Target of Measurement ar
ge
t
Of
Me
a
sur
em
e
nt
SSSSAAAA
SSSSAAAAVVVVVVVV
SS
MMMMM AAVV::
SSeecc
uurrii
MMMMM ttyy AA
ssssuurr
MMMMM aanncc
ee VV
iieeww
MMMMM ss
MMMMM
SSSSAAAA
SSSSAAAAVVVVVVVV
SSSSSSSSAAAAAAAAVVVV
VVVV
MMMMM
MMMMM MMMMM
MMMMM
MMMMM
MMMMM
SAV: SecSAV: Secuurity rity AssAssuurarancence Vi Viewsews
MMMMM MMMMM
SASASASAVVVV
SASASASAVVVV
MMMMM
MMMMM
MMMMM
MMMMM MMMMM MMMMM
SASASASAVVVV
SASASASAVVVV
MMMMM MMMMM
MMMMM
SASASASAVVVV
SASASASAVVVV
MMMMM MMMMM
Assurance Profile
MMMMM
MMMMM MMMMM MMMMM
MMMMM MMMMM MMMMM
MMMMM
4. Security Assurance Views
Figure 3: Target of Measurement and Security Assurance Views
4.3 General use of Assurance Profiles
4.3.1 How an AP should be used
An AP is typically a statement of operational security assurance measurement needs implemented by a defined and
common set of measurement requirements. The use may differ between different actors.
An AP is a statement of needs in which equipment vendors, solution providers, service integrators and operators define
a common set of security assurance measurement requirements on an agreed Target of Measurement. An AP gives a
means of referring to this set, and facilitates future evaluation against these needs.
An AP can be considered as one or several specific angles of view for measuring the security assurance of a service
infrastructure. Then, an entity (e.g. an operator or a corporate) may choose to implement different monitoring views of
the security assurance of a service infrastructure, which may relate to several different Assurance Profiles.
An AP is therefore typically used as:
• Part of requirement specification for a specific consumer or group of consumers, who will only consider
buying a specific type of service if it matches the AP.
• Part of a regulation from a specific regulatory entity, who will only allow a specific type of Service to be used
if it matches the AP.
• A baseline defined by a group of service providers, who then agree that concerned provided services will
conform to the agreed AP.
Though, this does not preclude other uses.
4.3.2 What an AP is not intended to provide
Three roles (among many) that an AP is not intended to provide:
• A security guarantee: An AP cannot be enough to guarantee that a Target of Measurement provides enough
security if the AP is used to deploy, manage and monitor the Target of Measurement.
ETSI
12 ETSI TR 187 023 V1.1.1 (2012-03)
• A detailed infrastructure specification: An AP is designed to provide guidelines in designing security assured
infrastructures. Compliance with an AP will not guarantee that the Target of Measurement is properly
designed and secured.
• A complete specification of assurance measurement needs: An AP is designed to help the definition of
assurance models and metrics for a TOM, not to be an exhaustive specification of assurance needs and
measurements. An AP represents a common and coherent understanding on how security assurance should be
addressed for a Service and measured within the Target of Measurement.
4.4 Implementing an assurance program using Assurance
Profiles
The general use of an Assurance Profile is to help defining and establishing an assurance program and to deploy an
associated measurement infrastructure.
4.4.1 Assurance program definition
An assurance program is a process to be implemented in order to be able to evaluate continuously operational security
assurance for a service.
4.4.2 Assurance program implementation methodology
To implement an assurance program, the following inputs are necessary:
• Security best practices and expert knowledge: A generic risk analysis, in case of an abstract TOM (i.e. a
generic architecture of a service), or a specific risk analysis, for an operational TOM, together with the
necessary knowledge (e.g. system administration, security best practices and modeling) required to design and
instantiate a relevant model.
• Compliance needs: Lists of laws or standards the system or class of system has to be compliant with.
• A System and its Services: The operational system running the targeted service to be evaluated.
The relevance of the security control realizations is accepted as the starting point of the assurance program, for which
the risk analysis and the conformance claims are the justification.
The implementation of an assurance program is decomposed into 6 steps.

Figure 4: Assurance program 6-steps methodology
ETSI
13 ETSI TR 187 023 V1.1.1 (2012-03)
Step 1 (Service Modeling)
I) Security Objectives and Security Requirements: the security controls to be evaluated are defined from known
threats and security objectives for the service and the system providing this service. These are the security
mechanisms expected to be present and running correctly in the system to fulfill the security objectives and
counter the chosen risks, e.g. traffic filtering, configuration files access control, compliant of a specified
function with standards, etc. Each security mechanism is decomposed and projected onto the different
(abstract) infrastructure objects of the system by formalizing security requirements. The architecture
combining the set of (abstract) infrastructure objects on which exists security requirements constitutes the
TOM. Classically, infrastructure objects can be of three types: humans (e.g. security guard, HR employee,
etc.), cyber (e.g. OS, firewall, anti-virus software, hard drive, log files, database, AAA, etc.) or physical
(e.g. doors, locks, fences, etc.).
II) Assurance Measurement Objectives and Assurance Measurement Requirements: for each security requirement
Assurance Measurement Objectives are defined as a high level metric demonstrating that the security
requirement is satisfied. Each measurement objective is then further decomposed into one or more Assurance
measurement requirements which measure the different dimensions of the corresponding (abstract)
infrastructure objects and demonstrate the related security requirement satisfaction. Measurement requirements
may be further refined and formalized in (abstract) derived measures by specifying at the lowest possible level
the expected result of a base measure to be instantiated in the step 2 by the operational system. Also at this
point, contrary to an offline evaluation, the impact of some evolutions over time have to be included in
measurement requirements.
III) Security Assurance Views and Metrics: based on the (abstract) derived measures specified in the measurement
requirements we may construct different abstract assurance metrics and security assurance views. Security
assurance views are compositions of those metrics used to highlight some specific points of the security
assurance evaluation. Various aggregation and composition models may combine their results differently in
order to present the result of the assurance evaluation.
Step 2 (Metric Selection)
As opposed to step 1, step 2 is rather bottom-up and aims at instanciating the established model by identifying the
system's raw data (i.e. base measures) required to evaluate the derived measures. Those base measures may be extracted
from appropriate available data of the system found in Network Operations Center (NOC) or Security Operation Center
(SOC) logs, OS files, etc. For data not directly available, dedicated probes should be defined.
The metric selection phase has an important impact on the assurance evaluation, that adds to the difficulty of having
generic models which take into account the possible lack of some measurements (due to dynamics, policies or technical
constraints). This need for the abstract model to take into account those real measurement constraints constitutes a
fundamental difference to the off-line assurance.
Step 3 (Measurement)
I) The required system probes are installed and activated along with the other measurement framework entities.
Probes fetch base measures, while the measurement framework makes this data available for the
corresponding processing engine, i.e. the one that manages the assurance model to be evaluated.
II) Operational assurance has to face all the inherent problem of operational systems, and dynamic measurements
in systems. The framework then requires constant management to maintain the proper access to the required
derived measures. For a valid assurance assessment at any time, any systems part - just as the targeted security
mechanisms - that may change, malfunction, move, crash, be removed, be under management, disappear, slow
down, become unavailable, and so on, has to be handled properly by the framework.
Step 4 and 5 (Aggregation and Evaluation)
Each derived measures and metric produces an assurance result, indicating whether the infrastructure object relating to
the base measure on the measured device is conformed to the expected result, and an assurance level (called metric
capability), correlated to extrinsic (e.g. rigor of base measure interpretation, coverage of relating measurement
requirements) and intrinsic (e.g. probe measurement frequency, probe precision, etc.) properties of the measurement
framework that produces the results.
ETSI
14 ETSI TR 187 023 V1.1.1 (2012-03)
Dynamism such as devices appearance/disappearance and mobility in the system (laptops changing locations, mobile
terminals) are addressed by the model and the measurement framework, allowing their corresponding derived measures
and base measures to also appear/disappear and move inside the system while being still correctly handled.
Among handled dynamism, the evolutions over time of the used probe set (state changes, updates, etc.), which may
influence the level of confidence (i.e. assurance level) of the assurance results has to be considered.
Step 6 (Presentation)
This step consists of providing to the users the security assurance evaluation results in relevant views of the system.
These views provides, at a central management point, some hints to managers on how the protection mechanisms of the
system evolve. From this information, the managers can decide how to adapt or modify the security mechanism to
enhance the system and its services.
With the concept of Security Assurance Views, different presentations of the assurance evaluation regarding different
security challenges (e.g. network view, files right management view, etc.) are enable, but also the post treatment of the
gathered data (e.g. average of measures and/or metrics evaluated to true/false, frequency of measures results changes,
alarms based on metric results, etc.).
4.4.3 Use of Assurance Profile
The Assurance Profile as pictured in figure 5 is addressing preparatory steps of assurance programs.
Assurance Profile
Service infrastructure for this service
(TOM + SAVs)
Cri
A tica
P l In
fra
stru
ctu
re
Obj
ect
s
T
a
rge
t
Of
M
ea
su
re
me
nt
SSSSAAAA
SSSSAAAAVVVVVVVV
SS
AAVV
MMMMM :: SSee
ccuurr
MMMMM iittyy
AAssssuu
rraann
MMMMM ccee
VViieeww
MMMMM ss
MMMMM
SSSSSSSSAAAAAAAAVVVV
VVVV SSSSSSSSAAAAVVVV
AAAAVVVV
MMMMM
MMMMM MMMMM
MMMMM
MMMMM
MMMMM
MMMMM
MMMMM
MMMMM
MMMMM
MMMMM
Figure 5: General use of Assurance Profile
When an operator, a service integrator or a group of users or consumers want to establish such a program, they should
first look if there is an existing Assurance Profile corresponding to their service. To perform this, they have to check if
the deployed infrastructure satisfies applicability requirements for the Target of Measurement. Those applicability
requirements may be, for example, specific security architecture for the infrastructure.
ETSI
15 ETSI TR 187 023 V1.1.1 (2012-03)
Cri
AP tical I
nfras
truc
ture O
bjec
ts
Tar
get
Of
Mea
sur
eme
nt
SSSSSSSSAAAAAAAAVVVVVVVV
MMMMM SSAAVV::
SSeeccuurr
MMMMM iittyy AAss
ssuurraa
MMMMM nnccee VVii
MMMMM eewwss
SSSS MMMMM
SSSSAAAAAAAAVVVVVVVV
SSSSSSSSAAAAAAAAVVVVVVVV
MMMMM
MMMMM MMMMM TOM APPLICABILIY and AP COMPLIANCE
MMMMM
MMMMM
MMMMM
MMMMM
MMMMM
MMMMM
MMMMM MMMMM
Applicability Requirements
satisfied ?
Use AP as support tool only but
NO
No compliance can be claimed
YES
Specific service deployment
Use AP to
deploy assurance program
Contract
SLAs
Certification
Accreditation
C
AP ritical
Infrastr
ucture
Objects
Targ
et Of
Mea
MMMM surem
MMMM MMMM ent
SSSSSSSSAAAAAAAAVVVV
VVVV
MMMMM SSAAVV:: SSee
MMMMM ccuurritityy AA
MMMMM ssssuurraanncc
MMMMM ee VViieewwss
SSSSSSSSAAAAAAAAVVVVVVVV MMMMM
SSSSSSSSAAAAAAAAVVVVVVVV
MMMMM
MMMMM MMMMM
MMMMM MMMMM
MMMM MMMMM
MMMMM MMMMM
MMMMM
MMMMM MMMMM AP compliance
(Objective level,
Requirements level
Views level)
Figure 6: Applicability and compliance
If the infrastructure satisfies the applicability requirements, the Assurance Profile can be used and a compliance with
the AP can be claimed. How to state this compliance is explained in clause 7. The operation to be done to use an
Assurance Profile is called "Assurance Profile instantiation".
If the applicability requirements are not satisfied, the Assurance Profile can only be used as guidance to build the
assurance program but no compliance can be claimed.
5 Building an Assurance Profile
Figure 7 illustrates how an Assurance Profile is articulated and how to build it. It also shows dependencies and
operations to gather information.
ETSI
16 ETSI TR 187 023 V1.1.1 (2012-03)
Services/business Security Problem Definition Compliance Claim
Service Infrastructure
Security Objectives
Security Requirements Measurement Objectives
Target of Measurement Measurement Requirements
Security Assurance Views
Cr
A itic
P al I
nfr
ast
ruc
ture
O
bje
cts
SASAV:V: S Seeccuurriittyy A Assussurrance ance ViViewewss
T
ar SASASASAVVVV
ge SASASASAVVVV
t
Of
M
ea
su
re
m MMMMM MMMMM MMMMM
en
t
SSSSSSSSAAAAAAAAVVVV
VVVV
SASASASAVVVV
SSAA SASASASAVVVV
MMMMM VV::
SSeecc
uurrii
MMMMM ttyy AA MMMMM MMMMM
ssssuu
rraann
MMMMM ccee MMMMM
VViieeww
MMMMM ss
Infrastructure related
MMMMM
SSSSSSSSAAAAVVVV
AAAAVVVV SSSS
SSSSAAAAAAAAVVVVVVVV SASASASAVVVV
SASASASAVVVV
Components MMMMM MMMMM
MMMMM
MMMMM MMMMM
MMMMM
MMMMM
MMMMM
MMMMM
MMMMM
MMMMM
MMMMM MMMMM MMMMM
MMMMM
MMMMM
MMMMM MMMMM MMMMM
Security related Components MMMMM
MMMMM
Assurance related components
Figure 7: Assurance Profile's structure
The structure of an Assurance Profile is composed of three types of components:
1) infrastructure related components;
2) security related components; and
3) assurance related components.
All these components are described in detail in the next sections.
The structure of an Assurance Profile is top down, from the service to a target of measurement associated with a set of
security assurance views.
The entry point of the Assurance Profile is a telecommunication service or a specific business associated with this
telecommunication service - e.g. IP-VPN service of a large company or the specific business associated with the VoIP
service in the triple-play offer of a Carrier. This service is running on an infrastructure. In order to reduce the
complexity, the Assurance Profile will focus only on critical components of this infrastructure on which security
safeguards are deployed. The set of critical infrastructure objects that will be measured, defines the Target of
Measurement as defined previously.
Concerning security related components, the Assurance Profile provides a presentation of the security problem that
the service is facing and the security requirements that should be deployed to address those problems. This is addressed
in the "Security Problem Definition" component. This component is refined into Security Objectives. Those Security
Objectives may also be derived from the claimed compliance to standards or regulations. Those Security Objectives are
then refined into Security Requirements.
Concerning assurance related components, the Assurance Profile is providing first a compliance claims which
describe which standards, regulations, or any specific document that is relevant to the security assurance for the service.
Those compliance claims are derived into Measurement Objectives which also depend on Security Requirements.
Measurement objectives are then derived into Measurement Requirements.
ETSI
17 ETSI TR 187 023 V1.1.1 (2012-03)
Having defined measurement requirements, they are selected and combined to constitute different security assurance
views related to the concerned service. All these security assurance views will fully describe what need to be deployed
and measured on the TOM to obtain service security assurance.
Creation of a new Assurance Profile that inherits from an existing one is expected to be a common scenario. They are
many reasons for why this is likely to occur. For example, evolution of a service infrastructure or a new regulation or
even change of the security problem definition can be addressed this way. Basically inheritance consists in reusing
components of an existing Assurance profile. If the reuse is massive, the compliance of an AP with another AP can be
claimed.
6 Assurance Profile components
This clause defines the Assurance Profile content, i.e. component requirements. All components have one mandatory
requirement and one optional requirement. It is recommended to satisfy optional requirements as much as possible.
Indeed, providing additional information then provides enhanced
...