ETSI GS SEC 006 V0.0.7 (2015-07)
GROUP SPECIFICATION
Network Functions Virtualization (NFV);
Security Report:
Security Aspects and Regulatory Concerns Guide
Disclaimer: This DRAFT is a working document of ETSI ISG NFV. It is
provided for information only and is still under development within
ETSI ISG NFV. DRAFTS may be updated, deleted, replaced, or
obsoleted by other documents at any time.
ETSI and its Members accept no liability for any further
use/implementation of the present DRAFT.
Disclaimer
Do not use as reference material.
This document has been produced and approved by the Open Radio equipment Interface (ORI) ETSI Industry Specification
Do not cite this document other than as "work in progress".
Group (ISG) and represents the views of those members who participated in this ISG.
It does
not necessarily
represent
the views of the entire ETSI membership.
- ETSI NFV public
DRAFTS
are available
in: http://docbox.etsi.org/ISG/NFV/Open/Drafts/
-
Report FEEDBACK via the NFV issue tracker: http://nfvwiki.etsi.org/index.php?title=NFV_Issue_Tracker
Approved and PUBLISHED deliverables shall be obtained via the ETSI Standards search page at:
http://www.etsi.org/standards-search
Disclaimer
This document has been produced and approved by the Network Feature Virtualisation (NFV) ETSI Industry Specification
Group (ISG) and represents the views of those members who participated in this ISG.
It does not necessarily represent the views of the entire ETSI membership.

2
ETSI GS SEC 006 V0.0.7 (2015-07)
Reference
DGS/NFV-SEC006
Keywords
<keywords>
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE
Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16
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
The present document can be downloaded from:
http://www.etsi.org
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the only prevailing document is the
print of the Portable Document Format (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
Reproduction is only permitted for the purpose of standardization work undertaken within ETSI.
The copyright and the foregoing restriction extend to reproduction in all media
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying
and microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.
© European Telecommunications Standards Institute 2015.
All rights reserved.
DECTTM, PLUGTESTSTM, UMTSTM and the ETSI logo are Trade Marks of ETSI registered for the benefit of its Members.
3GPPTM and LTE™ are Trade Marks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
ETSI
GSM® and the GSM logo are Trade Marks registered
and owned by the GSM Association.
3
ETSI GS SEC 006 V0.0.7 (2015-07)
Contents
Intellectual Property Rights ................................................................................................................................ 5
Foreword............................................................................................................................................................. 5
Modal verbs terminology ................................................................................................................................... 5
1
Scope ........................................................................................................................................................... 6
2
References ................................................................................................................................................... 6
2.1
2.2
3
3.1
3.2
3.3
4
Normative references ............................................................................................................................................... 6
Informative references ............................................................................................................................................. 6
Definitions, symbols and abbreviations ...................................................................................................... 8
Definitions ............................................................................................................................................................... 8
Symbols ................................................................................................................................................................... 8
Abbreviations ........................................................................................................................................................... 8
Security and Regulatory Concerns Guidelines.......................................................................................... 14
4.1 Overview and introduction ...................................................................................... Error! Bookmark not defined.
4.2 Domains of Attack .................................................................................................. Error! Bookmark not defined.
4.2.1 Social Engineering ............................................................................................... Error! Bookmark not defined.
4.2.1.1 Social Information Gathering Attacks............................................................... Error! Bookmark not defined.
4.2.1.2 Information Elicitation via Social Engineering ................................................. Error! Bookmark not defined.
4.2.1.3 Target Influence via Social Engineering ........................................................... Error! Bookmark not defined.
4.2.2 Supply Chain ........................................................................................................ Error! Bookmark not defined.
4.2.2.1 Integrity Modification During Manufacture ..................................................... Error! Bookmark not defined.
4.2.2.2 Integrity Modification During Distribution....................................................... Error! Bookmark not defined.
4.2.2.3 Integrity Modification During Deployed Use ................................................... Error! Bookmark not defined.
4.2.2.4 Malicious Logic Inserted Into Product .............................................................. Error! Bookmark not defined.
4.2.3 Communications .................................................................................................. Error! Bookmark not defined.
4.2.3.1 Interception ....................................................................................................... Error! Bookmark not defined.
4.2.3.2 Protocol Manipulation....................................................................................... Error! Bookmark not defined.
4.2.4 Software ............................................................................................................... Error! Bookmark not defined.
4.2.4.1 Brute Force........................................................................................................ Error! Bookmark not defined.
4.2.4.2 Authentication Abuse ........................................................................................ Error! Bookmark not defined.
4.2.4.3 Authentication Bypass ...................................................................................... Error! Bookmark not defined.
4.2.4.4 Excavation......................................................................................................... Error! Bookmark not defined.
4.2.4.5 Buffer Manipulation .......................................................................................... Error! Bookmark not defined.
4.2.4.6 Flooding ............................................................................................................ Error! Bookmark not defined.
4.2.4.7 Path Traversal ................................................................................................... Error! Bookmark not defined.
4.2.4.8 Integer Attacks .................................................................................................. Error! Bookmark not defined.
4.2.4.9 Pointer Attack ................................................................................................... Error! Bookmark not defined.
4.2.4.10 Excessive Allocation ....................................................................................... Error! Bookmark not defined.
4.2.4.11 Resource Leak Exposure ................................................................................. Error! Bookmark not defined.
4.2.4.12 Parameter Injection ......................................................................................... Error! Bookmark not defined.
4.2.4.13 Content Spoofing ............................................................................................ Error! Bookmark not defined.
4.2.4.14 Identity Spoofing ............................................................................................ Error! Bookmark not defined.
4.2.4.15 Resource Location Spoofing ........................................................................... Error! Bookmark not defined.
4.2.4.16 Footprinting..................................................................................................... Error! Bookmark not defined.
4.2.4.17 Action Spoofing .............................................................................................. Error! Bookmark not defined.
4.2.4.18 Code Inclusion ................................................................................................ Error! Bookmark not defined.
4.2.4.19 Reverse Engineering ....................................................................................... Error! Bookmark not defined.
4.2.4.20 Functionality Misuse ....................................................................................... Error! Bookmark not defined.
4.2.4.21 Fingerprinting ................................................................................................. Error! Bookmark not defined.
4.2.4.22 Sustained Client Engagement ......................................................................... Error! Bookmark not defined.
4.2.4.23 Code Injection ................................................................................................. Error! Bookmark not defined.
4.2.4.24 Command Injection ......................................................................................... Error! Bookmark not defined.
4.2.5 Physical Security .................................................................................................. Error! Bookmark not defined.
4.2.5.1 Bypassing Physical Security ............................................................................. Error! Bookmark not defined.
4.2.5.2 Physical Theft ................................................................................................... Error! Bookmark not defined.
4.2.5.3 Physical Destruction of Device or Component ................................................. Error! Bookmark not defined.
ETSI
4
ETSI GS SEC 006 V0.0.7 (2015-07)
4.2.6 Hardware .............................................................................................................. Error! Bookmark not defined.
4.2.6.1 Footprinting....................................................................................................... Error! Bookmark not defined.
4.2.6.2 Hacking Hardware Devices or Components ..................................................... Error! Bookmark not defined.
4.3 Regulatory Concerns ............................................................................................... Error! Bookmark not defined.
4.3.1 Lawful Intercept ................................................................................................... Error! Bookmark not defined.
4.3.1.1 Isolation ............................................................................................................ Error! Bookmark not defined.
4.3.1.2 Privacy .............................................................................................................. Error! Bookmark not defined.
4.3.1.3 Completeness .................................................................................................... Error! Bookmark not defined.
4.3.1.4 Correlation ........................................................................................................ Error! Bookmark not defined.
4.3.1.5 Subject Transparency ........................................................................................ Error! Bookmark not defined.
4.3.1.6 Cross-Agency Transparency ............................................................................. Error! Bookmark not defined.
4.3.1.7 Confidentiality .................................................................................................. Error! Bookmark not defined.
4.3.1.8 Integrity ............................................................................................................. Error! Bookmark not defined.
4.3.1.9 Non-Repudiation ............................................................................................... Error! Bookmark not defined.
4.3.1.10 Record Retention ............................................................................................ Error! Bookmark not defined.
4.3.1.11 Encryption ....................................................................................................... Error! Bookmark not defined.
4.3.1.12 Delivery .......................................................................................................... Error! Bookmark not defined.
4.3.1.13 Notification ..................................................................................................... Error! Bookmark not defined.
4.3.1.14 Jurisdictions .................................................................................................... Error! Bookmark not defined.
4.3.1.15 Locality ........................................................................................................... Error! Bookmark not defined.
4.3.1.16 Subject Location ............................................................................................. Error! Bookmark not defined.
4.3.2 Retention of data for law enforcement support .................................................... Error! Bookmark not defined.
4.3.2.1 Compliance ....................................................................................................... Error! Bookmark not defined.
4.3.2.2 Locality ............................................................................................................. Error! Bookmark not defined.
4.3.3 Data Protection..................................................................................................... Error! Bookmark not defined.
4.3.4 Data and user Privacy .......................................................................................... Error! Bookmark not defined.
Annex A (normative): Proforma of Security and Regulatory Concerns for use in ETSI ISG NFV
GSs .................................................................................................................. 15
Annex <E> (informative): Authors & contributors .................................................................................... 29
Annex F (informative): Bibliography ........................................................................................................... 30
Annex G (informative): Change History .......................................................... Error! Bookmark not defined.
History .............................................................................................................................................................. 31
ETSI
5
ETSI GS SEC 006 V0.0.7 (2015-07)
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 nonmembers, 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 Group Specification (GS) has been produced by ETSI Industry Specification Group Network
Functions Virtualisation (NFV).
Modal verbs terminology
In the present document "shall", "shall not", "should", "should not", "may", "may not", "need",
"need not", "will", "will not", "can" and "cannot" are to be interpreted as described in clause 3.2 of
the ETSI Drafting Rules (Verbal forms for the expression of provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.
ETSI
6
1
ETSI GS SEC 006 V0.0.7 (2015-07)
Scope
The present document is a guide to developers of NFV related documents and applications in means to
address the security aspects and regulatory concerns of these documents and applications. The
present document contains detailed descriptions of security concerns, attacks, as well as an overview
of regulatory concerns and how they can be treated in system design to give the highest level of
assurance that the resultant system is secure and complies with current regulation and best practice.
The present document is intended for use by developers of NFV documents and the guidance is given
in a manner that assists non-experts in security and regulation to prepare such documents.
In addition to the guidance and explanatory text the present document contains, in Annex A, a
proforma template to be completed in all ETSI ISG NFV documents to capture the security concerns
and mitigations that apply.
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:
2.1
While any hyperlinks included in this clause were valid at the time of publication, ETSI
cannot guarantee their long term validity.
Normative references
The following referenced documents are necessary for the application of the present document.
[1]
NOTE:
2.2
Domains of Attack list and descriptions
Obtained from: http://www.mitre.org. Please consult this website for detailed
descriptions of each attack: http://capec.mitre.org/data/graphs/3000.html
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]
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"
[i.2]
ETSI TR 187 011 "Telecommunications and Internet converged Services and
Protocols for Advanced Networking (TISPAN); NGN Security; Application of ISO15408-2 requirements to ETSI standards - guide, method and application with
examples"
[i.3]
ISO/IEC 15408-2: "Information technology - Security techniques - Evaluation
criteria for IT security - Part 2: Security functional requirements"
ETSI
7
ETSI GS SEC 006 V0.0.7 (2015-07)
[i.4]
ETSI EG 202 387: "Telecommunications and Internet converged Services and
Protocols for Advanced Networking (TISPAN); Security Design Guide; Method for
application of Common Criteria to ETSI deliverables"
[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, OJ L 281, 23.11.1995, p. 31.
[i.6]
ISO/IEC 15408-1: "Information technology - Security techniques - Evaluation
criteria for IT security - Part 1: Introduction and general model"
[i.7]
ITU-T X.509 “Information technology - Open systems interconnection - The
Directory: Public-key and attribute certificate frameworks”
[i.8]
ISO/IEC 27001:2005: “Information technology -- Security techniques -- Information
security management systems – Requirements”
[i.9]
Auguste Kerckhoffs, "La cryptographie militaire" Journal des sciences militaires, vol.
IX, pp. 5–83, January 1883, pp. 161–191, February 1883.
[i.10]
Shannon, Claude E. (July/October 1948). "A Mathematical Theory of
Communication". Bell System Technical Journal 27 (3): 379–423.
[i.11]
Computer Misuse Act 1990
NOTE:
[i.12]
NOTE:
From: http://www.legislation.gov.uk/ukpga/1990/18/contents
Privacy Impact Assessment Handbook (2009)
From: http://www.piawatch.eu/node/48
[i.13]
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), OJ L 201, 31.07.2002, p. 37
[i.14]
52003DC0265: Report from the Commission - First Report on the implementation of
the Data Protection Directive (95/46/EC), COM (2003) 265(01), 15.5.2003
[i.15]
COUNCIL DIRECTIVE 2008/114/EC of 8 December 2008 on the identification and
designation of European critical infrastructures and the assessment of the need to
improve their protection
[i.16]
ITU-T X.1520: SERIES X: DATA NETWORKS, OPEN SYSTEM COMMUNICATIONS AND
SECURITY; Cybersecurity information exchange – Vulnerability/state exchange;
Common vulnerabilities and exposures (January 2014)
ETSI
8
ETSI GS SEC 006 V0.0.7 (2015-07)
3
Definitions, symbols and abbreviations
3.1
Definitions
For the purposes of the present document, the [following] terms and definitions [given in ... and the
following] apply:
<defined term>: <definition>
3.2
Symbols
For the purposes of the present document, the [following] symbols [given in ... and the following]
apply:
<1st symbol><1st Explanation>
<2nd symbol><2nd Explanation>
<3rd symbol><3rd Explanation>
3.3
Abbreviations
For the purposes of the present document, the [following] abbreviations [given in ... and the following]
apply:
<1st ACRONYM><Explanation>
<2nd ACRONYM><Explanation>
<3rd ACRONYM><Explanation>
4
Security design guide
4.1
Overview and introduction
Security cannot be an afterthought, and must be considered throughout the
planning/development/deployment/runtime lifecycle. Unfortunately effective security design is not
trivial and there is a constant tension between functionality and security that inherently couples the
two. A significant danger is that in progressing functionality it will become harder and harder to
provide deeply rooted security in system designs. As with design of any type there are a number of
ways to approach security in system design. The primary starting point in much of security is to
identify an attack and pair it with a means to thwart the attack, such that a tuple of {issue, mitigation}
will exist across the system.
ETSI
9
ETSI GS SEC 006 V0.0.7 (2015-07)
Figure 1: Illustration of a threat tree to identify forms of threat in systems
Whilst an understanding of threat trees (see Figure 1) is useful it is not sufficient and has to be
mapped to a wider understanding of countermeasures. For example the tuple {masquerade,
authentication} suggest that if the authentication element is implemented properly it will counter
masquerade, but the pre-requisites of authentication include identity management and credential
management. If authentication is a cryptographic process further issues arise that include the viability
of the authentication algorithms over time (and associated cryptographic strength).
In the regulatory domain the mind-map shown in Figure 1 identifies some of the relationships
between protection technology and attack types, and the relationship between privacy and regulation
is highlighted. The latter is important as regulation exists to protect the obligation or right to privacy
as identified in a number of acts and laws, however there are a number of exceptions to the right to
privacy identified by the same broad set of acts and laws that generally give rights for law enforcement
to have reasonable rights to protect the whole. Such exceptions include the need to provide for Lawful
Interception, and to retain data in the network in support of law enforcement.
ETSI
10
ETSI GS SEC 006 V0.0.7 (2015-07)
Figure 2: Mind-map illustrating complexity of privacy and privacy protection
For example, when two functions share a host, a Denial of Service attack on one may affect the other.
The mitigation may be to not co-host high-priority functions with low-priority functions.
4.2
Risk, risk analysis, and risk management
Designing for the effective security of a system cannot be done without a reasonable understanding of
risk, there are a large number ways of modelling security in systems that look variously at the process
(Identify, Mitigate, Monitor as a continuous loop), and at the interactions of assets. The model given in
ETSI TS 102 165-1 [] and copied below makes a number of assumptions including:

Systems are compositions of a set of assets;

Assets may have inherent vulnerabilities;

A vulnerability when discovered with a viable threat becomes a weakness;

Exploitation of a weakness leads to something unwanted in the system (unwanted incident);
and,

Threat agents are used to enact threats and many threat agents may work together to exploit a
weakness.
ETSI
11
ETSI GS SEC 006 V0.0.7 (2015-07)
Figure 3: Generic security TVRA model from TS 102 165-1 []
There are a number of questions that arise from the generic model shown in Figure 3 and these
include:

What are the assets of my system?

How do I determine the vulnerabilities and when they become exploitable weaknesses?

How do I protect my system?
The present document is part of the process in the identification of assets and their vulnerabilities by
recommending a set of topics to be considered in every deliverable of ISG NFV.
Threats are potential events that can cause a system to respond in an unexpected or damaging way. It
is useful to categorize threats to determine effective and deployable mitigation strategies. The
identification and analysis of NFV relevant security threats (general and application specific) should
include the following categories:

Spoofing of identity (masquerade).

Tampering with data (manipulation).

Inappropriate information disclosure.

Denial of service.

Improper elevation of privileges.
The following subclauses describe a number of strategies for identifying the threats in general terms in
the NFV context.
4.3
Design for assurance
The Design for Assurance paradigm is closely aligned to the design for test paradigm. The aim of these
paradigms is to ensure that when designing a system an independent tester can validate that the
system actually performs to the design specification. The primary difference between design for test
and design for assurance is that in the latter there are specific security claims are being made and
verified.
ETSI
12
ETSI GS SEC 006 V0.0.7 (2015-07)
Figure 4: ETSI’s Design for Assurance document suite
The existing cPPs (published in February 2015) covering the following core technologies: Full Disk
Encryption (FDE) Encryption Engine (EE), FDE Authorization Acquisition (AA), Network Device, and
Firewall. It is almost certain that all of these technologies will be deployed an NFV environment thus it
would be prudent, at least, to ensure that ISG NFV acknowledges their existence and works with the
Common Criteria organisations to ensure that our standards work in the iTC and cPP space to allow
vendors, and ultimately integrators, to use these technologies effectively.
4.4
Secure by default
The secure by default initiative documented in ETSI TR 103 309 [] is a philosophy in which real
business problems are identified and security solutions to the problems are solved at root cause,
ETSI
13
ETSI GS SEC 006 V0.0.7 (2015-07)
rather than by applying patches or 'stop-gap' measures to address particular issues. The emphasis is
therefore on security mechanisms embedded in core device functions; supplied literally 'by default' in
products instead of being added afterwards via updates or complex configuration.
New features of this nature require fundamental changes to devices, hence development can take time.
Promoting adoption may require that technical solutions be identified when they are still maturing;
prototypes exist to verify the concept, however market support is required in order to justify
investment in refining a product.
Finally it is clear that simply developing technical components is almost never sufficient to solve
problems in the real world. Practical guidance is needed to ensure these components can be integrated
appropriately into deployed systems. As well as identifying technologies, it is necessary to point out
relevant good practice guidance where it exists
4.5
Domain of Attack model
The domain of attack model [1] is simple in theory and divides attack vectors into sets:

Social Engineering
-

Supply Chain
-

Software is the backbone of the ISG NFV and software is one of the assets of the system
that tends to exhibit a number of core vulnerabilities that when exploited lead to a
number of forms of unwanted incident. The set of checks against software design to
mitigate potential vulnerabilities are extensive and form the core of the checklist of the
present document. Attack vectors will also often be software based and may attack on
multiple paths including through operating systems, programming languages and their
associated compile and link facilities.
Physical Security
-

The model of establishment of communication between 2 parties has to meet certain
goals of confidentiality, availability and authenticity. Attacks against communication may
attack the confidentiality by intercepting the communication, or attack the availability by
disturbing the protocol in some way.
Software
-

Everything and anything brought into the system is part of the supply chain. The supply
chain has to be trusted sufficiently that when an asset is introduced to the system it can
be trusted to work. This requires understanding of not just software and hardware
products, but wider issues of distribution, support, tools and so forth. Failures in the
supply chain, or attacks introduced through the supply chain, have to be considered in the
general security model and means to give supply chain assurance and validation defined.
Communications
-

The manipulation and exploitation of people to attack the system or to gather information
about the system and its operation in order to perform future attacks. In most cases the
adversary never comes face-to-face with the victim
Often refers to the premises and to access control for the installed NFV hardware.
Hardware
-
Breaking the hardware will break the NFV and anything built on it.
ETSI
14
ETSI GS SEC 006 V0.0.7 (2015-07)
As the ISG NFV initiative involves hardware, software and communications this checklist of attack
vectors is a useful tool to verify that all reasonable steps have been taken in managing the security and
privacy risks.
The “Domains of Attack” list and descriptions has been obtained from: http://www.mitre.org [1] and
reviewed in the present document against the NFV context with specific guidance given for an NFV
application.
4.6
Regulatory and conformance issues
Security measures often have to be implemented to give assurance of conformance to regulation. In
security there are a number of regulations and restrictions that have to be borne in mind and these
include (the list is indicative as national legislation may extend the items that an NFV user/deployer
may have to show conformance to):

Lawful Interception

Data protection

Privacy protection

Retention of data

Export controls of dual use technologies (i.e. cryptographic material including algorithms)
Of these issues a number of concerns arise that require particular care in defining the security
solution. For LI there is a clear need for unobservability of the LI measure by unauthorised parties and
this requires a multi-tier security system. For data protection and privacy protection the current
legislation identifies roles of data controller and data processor in the system with explicit
responsibilities to manage the processing of private data (and by inference Personal Identifying
Information) with rules for accountability and for non-repudiation implicit in the requirements.
5
Security and Regulatory Concerns Guidelines
ETSI
15
ETSI GS SEC 006 V0.0.7 (2015-07)
Annex A (normative):
Proforma of Security and Regulatory Concerns for use in
ETSI ISG NFV GSs
A.1
Risk analysis and assessment
<<This section to essentially mimic the proforma from TS 102 165-1 with any essential updates –
could be replaced by a reference to TS 102 165-1 though.>>
Notwithstanding the provisions of the copyright clause related to the text of the present document,
ETSI grants that users of the present document may freely reproduce the TVRA definition proforma in
this annex so that it can be used for its intended purposes and may further publish the completed
TVRA definition.
ETSI
16
ETSI GS SEC 006 V0.0.7 (2015-07)
A Security Environment
a.1
Assumptions
Text of assumption
a.1.1
a.1.2
Citation for full text
a.2
Assets
Short text describing asset
a.2.1
a.2.2
Citation for full text
a.3
Threat agents
Short text describing threat agent
a.3.1
a.3.2
Citation for full text
a.4
Threats
Short text describing threat
a.4.1
a.4.2
Citation for full text
a.5
Security policies (OPTIONAL)
Short text describing security policy
a.5.1
a.5.2
Citation for full text
B Security Objectives
b.1
Security objectives for the asset
Short text describing objective for the asset
b.1.1
b.1.2
Citation for full text
b.2
Security objectives for the environment
Short text describing objective for the requirement
b.2.1
b.2.2
Citation for full text
C IT Security Requirements
c.1
asset security requirements
c.1.1 asset security functional requirements
Short text describing security functional requirement
ISO15408 class
c.1.1.1
c.1.1.2
Citation for full text
c.1.2 asset security assurance requirements
Short text describing security assurance requirement
c.1.2.1
c.1.2.2
ISO15408 class
Citation for full text
c.2
Environment security requirements (OPTIONAL)
Short text describing security environment requirement
c.2.1
c.2.2
ISO15408 class
Citation for full text
D Application notes (OPTIONAL)
E Rationale
The TVRA should define the full rational, if this is true only a citation (reference) to the full text is required
ETSI
17
A.2
Countermeasure deployment
A.2.1
Identity management
A.2.2
Integrity protection and verification
A.2.3
Confidentiality
A.2.4
Availability and resilience
A.3
Regulatory conformance
A.3.1
Data protection and Privacy
A.3.2
Data Retention
A.3.3
Lawful Interception
A.3.4
Others
<Text>.
ETSI
ETSI GS SEC 006 V0.0.7 (2015-07)
18
ETSI GS SEC 006 V0.0.7 (2015-07)
Annex B (informative):
Summary of attack vectors as applied in NFV
<< SCOTT: I intend to move a lot of the detail from the domains of attack model to here with some
simplifications thrown in >>
5.1
Domains of Attack
5.1.1
Social Engineering
As stated above social engineering attacks work to manipulate and exploit people to attack the system
or to gather information about the system and its operation in order to perform future attacks. In the
NFV context, and in particular the standards development context for NFV, there is little to do to
explicitly mitigate attacks on this vector. In practical systems operation operators need to ensure that
staff are trained to recognise such attacks and to report them. In addition credentials required to
access the system should be maintained under strict access control and logs maintained of access both
for exceptional and regular use.
5.1.2
Supply Chain
The role of the supply chain in NFV is considerable as the components are software and instantiated at
very short notice. The integrity of the supply chain itself should be considered with the modification of
the definition of integrity found in IT security (a principle that makes sure that information and
systems are not maliciously or accidentally modified) to extended to address consistency of actions,
values, methods, measures, principles, expectations and outcome is achieved (see ENISA report []).
5.1.2.1
Integrity Modification During Manufacture
An attacker modifies a technology, product, or component during a stage in its manufacture for the
purpose of carrying out an attack against some entity involved in the supply chain lifecycle. There are
an almost limitless number of ways an attacker can modify a technology when they are involved in its
manufacture, as the attacker has potential inroads to the software composition, hardware design and
assembly, firmware, or basic design mechanics. Additionally, manufacturing of key components is
often outsourced with the final product assembled by the primary manufacturer. The greatest risk,
however, is deliberate manipulation of design specifications to produce malicious hardware or
devices. There are billions of transistors in a single integrated circuit and studies have shown that
fewer than 10 transistors are required to create malicious functionality. NFV depends on both
hardware and software integrity thus the adoption of trusted platforms (hardware) and trusted
software will be essential for the overall security of the customer facing elements of any network built
on NFV capabilities.
5.1.2.2
Integrity Modification During Distribution
An attacker undermines the integrity of a product, software, or technology at some stage of the
distribution channel. The core threat of modification or manipulation during distribution arise from
the many stages of distribution, as a product may traverse multiple suppliers and integrators as the
final asset is delivered. Components and services provided from a manufacturer to a supplier may be
tampered with during integration or packaging.
ETSI
19
5.1.2.3
ETSI GS SEC 006 V0.0.7 (2015-07)
Integrity Modification During Deployed Use
An attacker modifies a technology, product, component, or sub-component during its deployed use at
the victim location for the purpose of carrying out an attack. After deployment, it is not uncommon for
upgrades and replacements to occur involving firmware, software, hardware, replaceable parts etc.
These upgrades and replacements are intended to correct defects, provide additional features, replace
broken or worn-out parts, and are considered an important part of the lifecycle of a deployed piece of
technology. As the upgrade and replacement part of the lifecycle can involve multiple manufacturers
and suppliers, subcontractors, and cross international boundaries, there are multiple points of
disruption for the attacker.
5.1.2.4
Malicious Logic Inserted Into Product
An attacker inserts malicious logic into a product at some point during the supply chain lifecycle,
typically in the form of a traditional virus or trojan backdoor.
5.1.3
5.1.3.1
Communications
Interception
An attacker monitors data streams to or from a target in order to gather information. This attack may
be undertaken to gather information to support a later attack or the data collected may be the end goal
of the attack. This attack usually involves sniffing network traffic, but may include observing other
types of data streams, such as radio. In most varieties of this attack, the attacker is passive and simply
observes regular communication, however in some variants the attacker may attempt to initiate the
establishment of a data stream or influence the nature of the data transmitted. However, in all variants
of this attack, and distinguishing this attack from other data collection methods, the attacker is not the
intended recipient of the data stream. Unlike some other data leakage attacks, the attacker is
observing explicit data channels (e.g. network traffic) and reading the content. This differs from
attacks that collect more qualitative information, such as communication volume, or other information
not explicitly communicated via a data stream.
5.1.3.2
Protocol Manipulation
An adversary subverts a communications protocol to perform an attack. This type of attack can allow
an adversary to impersonate others, discover sensitive information, control the outcome of a session,
or perform other attacks. This type of attack targets invalid assumptions that may be inherent in
implementers of the protocol, incorrect implementations of the protocol, or vulnerabilities in the
protocol itself.
5.1.4
5.1.4.1
Software
Brute Force
In this attack, some asset (information, functionality, identity, etc.) is protected by a finite secret value.
The attacker attempts to gain access to this asset by using trial-and-error to exhaustively explore all
the possible secret values in the hope of finding the secret (or a value that is functionally equivalent)
that will unlock the asset. Examples of secrets can include, but are not limited to, passwords,
encryption keys, database lookup keys, and initial values to one-way functions.
The key factor in this attack is the attackers' ability to explore the possible secret space rapidly. This,
in turn, is a function of the size of the secret space and the computational power the attacker is able to
bring to bear on the problem. If the attacker has modest resources and the secret space is large, the
challenge facing the attacker is intractable. While the defender cannot control the resources available
to an attacker, they can control the size of the secret space. Creating a large secret space involves
ETSI
20
ETSI GS SEC 006 V0.0.7 (2015-07)
selecting one's secret from as large a field of equally likely alternative secrets as possible and ensuring
that an attacker is unable to reduce the size of this field using available clues or cryptanalysis. Doing
this is more difficult than it sounds since elimination of patterns (which, in turn, would provide an
attacker clues that would help them reduce the space of potential secrets) is difficult to do using
deterministic machines, such as computers. Assuming a finite secret space, a brute force attack will
eventually succeed. The defender must rely on making sure that the time and resources necessary to
do so will exceed the value of the information. For example, a secret space that will likely take
hundreds of years to explore is likely safe from raw-brute force attacks.
5.1.4.2
Authentication Abuse
An attacker obtains unauthorized access to an application, service or device either through knowledge
of the inherent weaknesses of an authentication mechanism, or by exploiting a flaw in the
authentication scheme's implementation. In such an attack an authentication mechanism is
functioning but a carefully controlled sequence of events causes the mechanism to grant access to the
attacker. This attack may exploit assumptions made by the target's authentication procedures, such as
assumptions regarding trust relationships or assumptions regarding the generation of secret values.
This attack differs from Authentication Bypass attacks in that Authentication Abuse allows the
attacker to be certified as a valid user through illegitimate means, while Authentication Bypass allows
the user to access protected material without ever being certified as an authenticated user. This attack
does not rely on prior sessions established by successfully authenticating users, as relied upon for the
"Exploitation of Session Variables, Resource IDs and other Trusted Credentials" attack patterns.
5.1.4.3
Authentication Bypass
An attacker gains access to application, service, or device with the privileges of an authorized or
privileged user by evading or circumventing an authentication mechanism. The attacker is therefore
able to access protected data without authentication ever having taken place. This refers to an attacker
gaining access equivalent to an authenticated user without ever going through an authentication
procedure. This is usually the result of the attacker using an unexpected access procedure that does
not go through the proper checkpoints where authentication should occur. For example, a web site
might assume that all users will click through a given link in order to get to secure material and simply
authenticate everyone that clicks the link. However, an attacker might be able to reach secured web
content by explicitly entering the path to the content rather than clicking through the authentication
link, thereby avoiding the check entirely. This attack pattern differs from other authentication attacks
in that attacks of this pattern avoid authentication entirely, rather than faking authentication by
exploiting flaws or by stealing credentials from legitimate users.
5.1.4.4
Excavation
An attacker probes the target in a manner that is designed to solicit information relevant to system
security. This is achieved by sending data that is syntactically invalid or non-standard relative to a
given service, protocol, or expected-input, or by exploring the target via ordinary interactions for the
purpose of gathering intelligence about the target. As a result the attacker is able to obtain information
from the target that aids the attacker in making inferences about its security, configuration, or
potential vulnerabilities. Some exchanges with the target may trigger unhandled exceptions or verbose
error messages. When this happens error messages may reveal information like stack traces,
configuration information, path information, or database messages. This type of attack also includes
manipulation of query strings in a URI, such as by attempting to produce invalid SQL queries or by
trying alternative path values, in the hope that the server will return useful information. This attack
differs from Data Interception and other data collection attacks in that the attacker actively queries the
target rather than simply watching for the target to reveal information.
ETSI
21
5.1.4.5
ETSI GS SEC 006 V0.0.7 (2015-07)
Buffer Manipulation
An adversary manipulates an application's interaction with a buffer in an attempt to read or modify
data they shouldn't have access to. Buffer attacks are distinguished in that it is the buffer space itself
that is the target of the attack rather than any code responsible for interpreting the content of the
buffer. In virtually all buffer attacks the content that is placed in the buffer is immaterial. Instead, most
buffer attacks involve retrieving or providing more input than can be stored in the allocated buffer,
resulting in the reading or overwriting of other unintended program memory.
5.1.4.6
Flooding
An attacker consumes the resources of a target by rapidly engaging in a large number of interactions
with the target. This type of attack generally exposes a weakness in rate limiting or flow control in
management of interactions. Since each request consumes some of the target's resources, if a
sufficiently large number of requests must be processed at the same time then the target's resources
can be exhausted.
The degree to which the attack is successful depends upon the volume of requests in relation to the
amount of the resource the target has access to, and other mitigating circumstances such as the
target's ability to shift load or acquired additional resources to deal with the depletion. The more
protected the resource and the greater the quantity of it that must be consumed, the more resources
the attacker may need to have at their disposal. A typical TCP/IP flooding attack is a Distributed
Denial-of-Service attack where many machines simultaneously make a large number of requests to a
target. Against a target with strong defenses and a large pool of resources, many tens of thousands of
attacking machines may be required.
When successful this attack prevents legitimate users from accessing the service and can cause the
target to crash. This attack differs from resource depletion through leaks or allocations in that the
latter attacks do not rely on the volume of requests made to the target but instead focus on
manipulation of the target's operations. The key factor in a flooding attack is the number of requests
the attacker can make in a given period of time. The greater this number, the more likely an attack is to
succeed against a given target.
5.1.4.7
Path Traversal
An adversary uses path manipulation methods to exploit insufficient input validation of a target to
obtain access to data that should be not be retrievable by ordinary well-formed requests. A typical
variety of this attack involves specifying a path to a desired file together with dot-dot-slash characters,
resulting in the file access API or function traversing out of the intended directory structure and into
the root file system. By replacing or modifying the expected path information the access function or
API retrieves the file desired by the attacker. These attacks either involve the attacker providing a
complete path to a targeted file or using control characters (e.g. path separators (/ or \) and/or dots
(.)) to reach desired directories or files.
5.1.4.8
Integer Attacks
An attacker takes advantage of the structure of integer variables to cause these variables to assume
values that are not expected by an application. For example, adding one to the largest positive integer
in a signed integer variable results in a negative number. Negative numbers may be illegal in an
application and the application may prevent an attacker from providing them directly, but the
application may not consider that adding two positive numbers can create a negative number do to the
structure of integer storage formats.
ETSI
22
5.1.4.9
ETSI GS SEC 006 V0.0.7 (2015-07)
Pointer Attack
This attack involves an attacker manipulating a pointer within a target application resulting in the
application accessing an unintended memory location. This can result in the crashing of the
application or, for certain pointer values, access to data that would not normally be possible or the
execution of arbitrary code. Since pointers are simply integer variables, Integer Attacks may often be
used in Pointer Attacks.
5.1.4.10
Excessive Allocation
An attacker causes the target to allocate excessive resources to servicing the attackers' request,
thereby reducing the resources available for legitimate services and degrading or denying services.
Usually, this attack focuses on memory allocation, but any finite resource on the target could be the
attacked, including bandwidth, processing cycles, or other resources. This attack does not attempt to
force this allocation through a large number of requests (that would be Resource Depletion through
Flooding) but instead uses one or a small number of requests that are carefully formatted to force the
target to allocate excessive resources to service this request(s). Often this attack takes advantage of a
bug in the target to cause the target to allocate resources vastly beyond what would be needed for a
normal request. For example, using an Integer Attack, the attacker could cause a variable that controls
allocation for a request to hold an excessively large value. Excessive allocation of resources can render
a service degraded or unavailable to legitimate users and can even lead to crashing of the target.
5.1.4.11
Resource Leak Exposure
An attacker utilizes a resource leak on the target to deplete the quantity of the resource available to
service legitimate requests. Resource leaks most often come in the form of memory leaks where
memory is allocated but never released after it has served its purpose, however, theoretically, any
other resource that can be reserved can be targeted if the target fails to release the reservation when
the reserved resource block is no longer needed. In this attack, the attacker determines what activity
results in leaked resources and then triggers that activity on the target. Since some leaks may be small,
this may require a large number of requests by the attacker. However, this attack differs from a
flooding attack in that the rate of requests is generally not significant. This is because the lost
resources due to the leak accumulate until the target is reset, usually by restarting it. Thus, a resourcepoor attacker who would be unable to flood the target can still utilize this attack.
Resource depletion through leak differs from resource depletion through allocation in that, in the
former, the attacker may not be able to control the size of each leaked allocation, but instead allows
the leak to accumulate until it is large enough to affect the target's performance. When depleting
resources through allocation, the allocated resource may eventually be released by the target so the
attack relies on making sure that the allocation size itself is prohibitive of normal operations by the
target.
5.1.4.12
Parameter Injection
An attacker exploits weaknesses in input validation by manipulating the content of request
parameters for the purpose of undermining the security of the target. Some parameter encodings use
text characters as separators. For example, parameters in a HTTP GET message are encoded as namevalue pairs separated by an ampersand (&). If an attacker can supply text strings that are used to fill in
these parameters, then they can inject special characters used in the encoding scheme to add or
modify parameters. For example, if user input is fed directly into an HTTP GET request and the user
provides the value "myInput&new_param=myValue", then the input parameter is set to myInput, but a
new parameter (new_param) is also added with a value of myValue. This can significantly change the
meaning of the query that is processed by the server. Any encoding scheme where parameters are
ETSI
23
ETSI GS SEC 006 V0.0.7 (2015-07)
identified and separated by text characters is potentially vulnerable to this attack - the HTTP GET
encoding used above is just one example.
5.1.4.13
Content Spoofing
An attacker modifies content to make it contain something other than what the original content
producer intended while keeping the apparent source of the content unchanged. The term content
spoofing is most often used to describe modification of web pages hosted by a target to display the
attackers' content instead of the owner's content. However, any content can be spoofed, including the
content of email messages, file transfers, or the content of other network communication protocols.
Content can be modified at the source (e.g. modifying the source file for a web page) or in transit (e.g.
intercepting and modifying a message between the sender and recipient). Usually, the attacker will
attempt to hide the fact that the content has been modified, but in some cases, such as with web site
defacement, this is not necessary. Content Spoofing can lead to malware exposure, financial fraud if the
content governs financial transactions, privacy violations, and other results.
5.1.4.14
Identity Spoofing
Identity Spoofing refers to the action of assuming (i.e., taking on) the identity of some other entity
(human or non-human) and then using that identity to accomplish a goal. An adversary may craft
messages that appear to come from a different principle or use stolen / spoofed authentication
credentials. Alternatively, an attacker may intercept a message from a legitimate sender and attempt
to make it look like the message comes from them without changing its content. The latter form of this
attack can be used to hijack credentials from legitimate users. Identity Spoofing attacks need not be
limited to transmitted messages - any resource that is associated with an identity (for example, a file
with a signature) can be the target of an attack where the adversary attempts to change the apparent
identity. This attack differs from Content Spoofing attacks where the adversary does not wish to
change the apparent identity of the message but instead wishes to change what the message says. In an
Identity Spoofing attack, the adversary is attempting to change the identity of the content.
5.1.4.15
Resource Location Spoofing
An adversary, in an attempt to leverage an alternate of malicious resource, causes an application to
look for a resource in an unintended location. This differs from a resource manipulation attack in
which the contents of the resource are affected or where the resources themselves are physically
altered or moved. Instead, this attack simply concerns itself with the paths used to find or create
resources.
5.1.4.16
Footprinting
An attacker engages in probing and exploration activity to identify constituents and properties of the
target. Footprinting is a general term to describe a variety of information gathering techniques, often
used by attackers in preparation for some attack. It consists of using tools to learn as much as possible
about the composition, configuration, and security mechanisms of the targeted application, system or
network. Information that might be collected during a footprinting effort could include open ports,
applications and their versions, network topology, and similar information. While footprinting is not
intended to be damaging (although certain activities, such as network scans, can sometimes cause
disruptions to vulnerable applications inadvertently) it may often pave the way for more damaging
attacks.
5.1.4.17
Action Spoofing
An attacker is able to disguise one action for another and therefore trick a user into initiating one type
of action when they intend to initiate a different action. For example, a user might be led to believe that
clicking a button will submit a query, but in fact it downloads software. Attackers may perform this
ETSI
24
ETSI GS SEC 006 V0.0.7 (2015-07)
attack through social means, such as by simply convincing a victim to perform the action or relying on
a user's natural inclination to do so, or through technical means, such as a clickjacking attack where a
user sees one interface but is actually interacting with a second, invisible, interface.
5.1.4.18
Code Inclusion
An attacker exploits a weakness in input validation on the target to force arbitrary code to be retrieved
from a remote location and executed. This differs from code injection in that code injection involves
the direct inclusion of code while code inclusion involves the addition or replacement of a reference to
a code file, which is subsequently loaded by the target and used as part of the code of some application.
One example of this sort of attack is PHP file include attacks where the parameter of an include()
function is set by a variable that an attacker is able to control. The result is that arbitrary code could be
loaded into the PHP application and executed.
5.1.4.19
Reverse Engineering
An attacker discovers the structure, function, and composition of an object, resource, or system by
using a variety of analysis techniques to effectively determine how the analyzed entity was
constructed or operates. The goal of reverse engineering is often to duplicate the function, or a part of
the function, of an object in order to duplicate or "back engineer" some aspect of its functioning.
Reverse engineering techniques can be applied to mechanical objects, electronic devices or
components, or to software, although the methodology and techniques involved in each type of
analysis differ widely.
5.1.4.20
Functionality Misuse
An adversary misuses the functionality of an application in order to achieve a negative technical
impact.
5.1.4.21
Fingerprinting
An adversary compares output from a target system to known "fingerprints" that uniquely identify
specific details about the target. Fingerprinting by itself is not usually detrimental to the target.
However, the information gathered through fingerprinting often enables an adversary to discover
existing weaknesses in the target.
5.1.4.22
Sustained Client Engagement
An adversary attempts to deny legitimate users access to a resource by continually engaging a specific
resource in an attempt to keep the resource tied up as long as possible. The adversary's primary goal is
not to crash or flood the target, which would alert defenders; rather it is to repeatedly perform actions
or abuse algorithmic flaws such that a given resource is tied up and not available to a legitimate user.
By carefully crafting a requests that keep the resource engaged through what is seemingly benign
requests, legitimate users are limited or completely denied access to the resource. The degree to which
the attack is successful depends upon the adversary's ability to sustain resource requests over time
with a volume that exceeds the normal usage by legitimate users, as well as other mitigating
circumstances such as the target's ability to shift load or acquire additional resources to deal with the
depletion. This attack differs from a flooding attack as it is not entirely dependent upon large volumes
of requests, and it differs from resource leak exposures which tend to exploit the surrounding
environment needed for the resource to function. The key factor in a sustainment attack are the
repeated requests that take longer to process than usual.
5.1.4.23
Code Injection
An adversary exploits a weakness in input validation on the target to inject new code into that which is
currently executing. This differs from code inclusion in that code inclusion involves the addition or
ETSI
25
ETSI GS SEC 006 V0.0.7 (2015-07)
replacement of a reference to a code file, which is subsequently loaded by the target and used as part
of the code of some application.
5.1.4.24
Command Injection
The target application must accept input from the user. In virtually all cases, this must be string input.
The target application must fail to adequately filter the user input against the insertion of instructions.
5.1.5
5.1.5.1
Physical Security
Bypassing Physical Security
Facilities often used layered models for physical security such as traditional locks, Electronic-based
card entry systems, coupled with physical alarms. Hardware security mechanisms range from the use
of computer case and cable locks as well as RFID tags for tracking computer assets. This layered
approach makes it difficult for random physical security breaches to go unnoticed, but is less effective
at stopping deliberate and carefully planned break-ins. Avoiding detection begins with evading
building security and surveillance and methods for bypassing the electronic or physical locks which
secure entry points.
5.1.5.2
Physical Theft
An adversary gains physical access to a system or device through theft of the item. Possession of a
system or device enables a number of unique attacks to be executed and often provides the adversary
with an extended timeframe for which to perform an attack. Most protections put in place to secure
sensitive information can be defeated when an adversary has physical access and enough time.
5.1.5.3
Physical Destruction of Device or Component
An adversary conducts a physical attack a device or component, destroying it such that it no longer
functions as intended.
5.1.6
5.1.6.1
Hardware
Footprinting
An attacker engages in probing and exploration activity to identify constituents and properties of the
target. Footprinting is a general term to describe a variety of information gathering techniques, often
used by attackers in preparation for some attack. It consists of using tools to learn as much as possible
about the composition, configuration, and security mechanisms of the targeted application, system or
network. Information that might be collected during a footprinting effort could include open ports,
applications and their versions, network topology, and similar information. While footprinting is not
intended to be damaging (although certain activities, such as network scans, can sometimes cause
disruptions to vulnerable applications inadvertently) it may often pave the way for more damaging
attacks.
5.1.6.2
Hacking Hardware Devices or Components
An attacker exploits weaknesses in the physical hardware of a machine in order to gain unauthorized
access to the device or system. Hacking hardware devices falls into several broad categories depending
upon the relative sophistication of the attacker and the type of systems that are targeted. Attacks
against hardware devices differ from software attacks in that hardware-based attacks target the chips,
ETSI
26
ETSI GS SEC 006 V0.0.7 (2015-07)
circuit boards, device ports, or other components that comprise a computer system or embedded
system. The most common hardware devices which are attacked are computer systems such as
laptops, desktops and server platforms. Sophisticated attacks may involve adding or removing
jumpers to an exposed system, or applying sensors to portions of the motherboard to read data as it
traverses the system bus.
5.2
Regulatory Concerns
Provision of Lawful Interception and Data Retention capability in an active network is a condition of
licensing in most countries.
5.2.1
Lawful Interception
Lawful Interception is activated against single targets at a time. Consider the following concerns:
5.2.1.1
Isolation
Will deploying this function affect the ability of the service provider to isolate the target service?
5.2.1.2
Privacy
Will deploying this function affect the privacy of information not authorized for interception?
5.2.1.3
Completeness
Will deploying this function affect the completeness of Lawful Interception? Will it cause interception
drop-outs?
5.2.1.4
Correlation
Will deploying this function affect the service provider’s ability to correlate Intercept Related
Information (IRI) with Content of Communication (CC)?
5.2.1.5
Subject Transparency
Will deploying this function affect service parameters (e.g., bandwidth, latency, availability) or cause
any other service change? Can the subject detect it?
5.2.1.6
Cross-Agency Transparency
Will deploying this function affect transparency across law enforcement agencies?
5.2.1.7
Confidentiality
Will the deployment of the function allow non-authorized employees to detect a Lawful Interception?
5.2.1.8
Integrity
Will the deployment of the function affect the service provider’s abilty to verify Lawful Interception
integrity (e.g., using hashing)?
5.2.1.9
Non-Repudiation
Will deploying this function affect the subject’s ability to repudiate their actions? Will it affect the chain
of evidence?
ETSI
27
5.2.1.10
ETSI GS SEC 006 V0.0.7 (2015-07)
Record Retention
Will deploying this function affect the service provider’s ability to create and retain Lawful
Interception records?
5.2.1.11
Encryption
Will deploying this function affect the ability of the service provider to provide law enforcement with
non-encrypted (or decrypted, or decryptable) intercepts?
5.2.1.12
Delivery
Will deploying this function affect the service provider’s ability to deliver the intercept to law
enforcement expeditiously and reliably?
5.2.1.13
Notification
Will deploying this function affect the service provider’s ability to provide law enforcement with
Lawful Interception activation/deactivation/modification notifications? Also consider that Data
Retention requirements apply to this item as well.
5.2.1.14
Jurisdictions
Will deploying this function affect the service provider’s ability to comply with local laws in multiple
markets?
5.2.1.15
Locality
Will deploying this function affect the service provider’s ability to provision correct Points of
Interception (PoI)?
5.2.1.16
Subject Location
Will deploying this function affect the service provider’s ability to provide subject location when
required?
5.2.2
Retention of data for law enforcement support
Retention of data is required against the entire user population and may be used in support of law
enforcement under specific authorisations.
5.2.2.1
Compliance
Will deploying this function affect the service provider’s ability to perform retention of data?
5.2.2.2
Locality
Will deploying this function affect the service provider’s ability to provision correct Points of
Retention (PoR)?
5.2.3
Data Protection
…
5.2.4
Data and user Privacy
…
ETSI
28
B.1
ETSI GS SEC 006 V0.0.7 (2015-07)
Interception attacks
Mitigation of interception is classically treated by encryption in order that if a channel or path is
intercepted that any material gained cannot be used by an attacker to exploit the transmission content.
In other words even if interception is possible the attacker cannot gain any advantage from the attack
as the content will be indecipherable.
B.2
Manipulation attacks
Mitigation of manipulation is classically treated by the use of checksums or message hashes. In this
case a fixed length output is created from an arbitrary length input with key cryptographic properties
as follows:

One way function requirement
-

Collision resistance requirement
-

if 1 bit in message m changes all other bits should change with 50% probability
Bit Independence Criterion
-
B.3
Given an input m1 it should be difficult to find another input m2 such that m1 ≠ m2 and
hash(m1) = hash(m2)..
Strict Avalanche Criterion
-

Given a hash h it should be difficult to find any message m such that h = hash(m).
output bits j and k should change independently when any single input bit i is inverted, for
all i, j and k
Identity based attacks
ETSI
29
Annex E (informative):
Authors & contributors
The following people have contributed to this specification:
Rapporteur:
Mr Scott Cadzow, Cadzow Communications Consulting Ltd.
Other contributors:
Title, Firstname, Lastname, company
ETSI
ETSI GS SEC 006 V0.0.7 (2015-07)
30
Annex F (informative):
Bibliography
ETSI
ETSI GS SEC 006 V0.0.7 (2015-07)
31
ETSI GS SEC 006 V0.0.7 (2015-07)
History
Document history
0.01
November
2014
First draft
0.0.2
February 2015 Updated with initial text on model and revision of scope. Input to NFVSEC#45 at NFV#9 in Prague
0.0.3
February 2015 Output of NFV-SEC#45 at NFV#9 in Prague
0.0.4
May 2015
Input to NFV-SEC#50 at NFV#10 in Sanya (China)
0.0.5
July 2015
Input to NFV-SC#54 at NFV#11 in San Jose (California)
0.0.6
July 2015
Revised and updated input to NFV-SEC#54 at NFV#11 in San Jose
(California)
0.0.7
July 2015
Output from NFV-SEC#54 at NFV#11
ETSI