ETSI GS NFV-SEC 001 V1.1.1 (2014-10)

Network Functions Virtualisation (NFV); NFV Security; Problem Statement

DGS/NFV-SEC001

General Information

• Status: Published
• Publication Date: 05-Oct-2014
• Technical Committee: NFV SEC - Security
• Current Stage: 12 - Completion
• Due Date: 06-Oct-2014
• Completion Date: 06-Oct-2014

Standards Content (Sample)

GROUP SPECIFICATION
Network Functions Virtualisation (NFV);
NFV Security;
Problem Statement
Disclaimer
This document has been produced and approved by the Network Functions 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 NFV-SEC 001 V1.1.1 (2014-10)

Reference
DGS/NFV-SEC001
Keywords
NFV, security
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
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
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 2014.
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 GS NFV-SEC 001 V1.1.1 (2014-10)
Contents
Intellectual Property Rights . 5
Foreword . 5
Modal verbs terminology . 5
1 Scope . 6
2 References . 6
2.1 Normative references . 6
2.2 Informative references . 6
3 Definitions and abbreviations . 8
3.1 Definitions . 8
3.2 Abbreviations . 9
4 Industry Context . 10
5 Security Reference Framework . 11
5.1 Deployment Scenarios . 11
5.2 Threat Surface . 12
5.3 Attacker Profiles . 13
6 Potential Areas of Concern . 15
6.1 Topology Validation & Enforcement . 15
6.1.1 Topology Validation Example . 15
6.1.2 Validating the Topology of Virtualised Network Functions . 17
6.1.3 Validating the Topology of the Infrastructure Network. 18
6.1.3.1 SDN-specific issues . 18
6.1.3.1.1 Hierarchies of control . 19
6.1.3.1.2 Additional layers of hierarchy . 20
6.1.3.1.3 Further issues . 20
6.1.3.2 Issues specific to distributed (non-SDN) routing . 20
6.1.3.3 Related issues . 21
6.1.4 Topology Policy Validation & Enforcement . 21
6.2 Availability of Management Support Infrastructure . 21
6.3 Secured Boot . 23
6.3.1 Background . 23
6.3.2 Secure Boot and Trusted Boot Technology . 24
6.3.3 Secured Boot Summary . 25
6.4 Secure crash . 25
6.5 Performance isolation . 26
6.5.1 Network and I/O partitioning . 27
6.5.2 Shared core partitioning . 27
6.5.3 Acceleration hardware partitioning . 27
6.5.4 Shared memory partitioning . 28
6.5.5 Attacks on the resources of the virtualisation infrastructure . 28
6.6 User/Tenant Authentication, Authorization and Accounting . 29
6.7 Authenticated Time Service . 30
6.8 Private Keys within Cloned Images . 31
6.9 Back-Doors via Virtualised Test & Monitoring Functions . 31
6.9.1 Operational Test, Monitoring and Fault Tracing . 31
6.9.2 Developer's debug and test interfaces . 32
6.9.2.1 Industry Experience Example 1 . 32
6.9.2.2 Industry Experience Example 2 . 33
6.9.2.3 Guidance for the NFV ISG working groups: . 33
6.10 Multi-Administrator Isolation . 33
7 General Concerns . 33
7.1 Safety vs. Complexity . 33
ETSI
4 ETSI GS NFV-SEC 001 V1.1.1 (2014-10)
7.2 Altered Norms and Procedures . 34
7.2.1 Broken Procedure . 34
7.2.2 Software Vulnerabilities . 34
Annex A (informative): Authors & contributors . 36
History . 37

ETSI
5 ETSI GS NFV-SEC 001 V1.1.1 (2014-10)
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 Group Specification (GS) has been produced by ETSI Industry Specification Group (ISG) 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 ETSI GS NFV-SEC 001 V1.1.1 (2014-10)
1 Scope
The present document aims to:
• To identify potential security vulnerabilities of NFV and to determine whether they are new problems, or just
existing problems in different guises.
• To provide a reference framework within which these vulnerabilities can be defined.
Out of scope: To list vulnerabilities that NFV suffers from that are no different from pre-existing vulnerabilities of
networking and virtualisation technologies and are not altered by the virtualisation of network functions.
Intended audience: Security experts wanting to deploy NFV but needing to identify and solve potential security issues
and then to attain security accreditation for systems.
Ultimate goal of the NFV Security Expert Group: Identify and propose solutions to any new vulnerabilities that
result from the introduction of NFV. To enable checks for these vulnerabilities to be incorporated into processes for
security accreditation of products based on NFV.
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] Homomorphic Encryption.
NOTE: http://en.wikipedia.org/wiki/Homomorphic_encryption.
[i.2] Trusted Computing Group.
NOTE: http://www.trustedcomputinggroup.org/.
[i.3] Unified Extensible Firmware Interface (UEFI) forum.
NOTE: http://www.uefi.org/home/.
[i.4] ISO/IEC 11889-1 (March 2009(en)): "Trusted Platform Module - Part 1: Overview".
[i.5] CERT Vulnerability Note VU#362332 (August 2010).
[i.6] NIST SP 800-147 (April 2011): "Basic Input/Output System (BIOS) Protection Guidelines".
ETSI
7 ETSI GS NFV-SEC 001 V1.1.1 (2014-10)
[i.7] NIST SP 800-155 (December 2011): "DRAFT BIOS Integrity Measurement Guidelines".
[i.8] TPM Main Specification (March 2011).
NOTE: http://www.trustedcomputinggroup.org/resources/tpm_main_specification.
[i.9] Virtualized Trusted Platform Architecture Specification (September 2011).
NOTE: http://www.trustedcomputinggroup.org/resources/tpm_main_specification.
[i.10] NIST SP 800-147b (July 2012): "DRAFT BIOS Protection Guidelines for Servers".
[i.11] NFV White paper (October 2012): "Network Functions Virtualisation, An Introduction, Benefits,
Enablers, Challenges & Call for Action. Issue 1".
NOTE: http://portal.etsi.org/NFV/NFV_White_Paper.pdf.
[i.12] ETSI GS NFV 002: "Network Functions Virtualisation (NFV); Architectural Framework".
[i.13] ETSI GS NFV 001: "Network Functions Virtualisation (NFV); Use Cases".
[i.14] ETSI GS NFV INF 001-1 (V0.3.8 April 2014): "Network Functions Virtualisation; Infrastructure
Architecture; Sub-part 1: Overview", (work in progress).
[i.15] ETSI GS NFV 003: "Network Functions Virtualisation (NFV); Terminology for Main Concepts in
NFV".
[i.16] David Kleidermacher and Mike Kleidermacher: "Embedded Systems Security", Newnes, April
2012.
[i.17] Rowan Klöti, Vasileios Kotronis and Paul Smith: "OpenFlow: A Security Analysis". In Proc.
Wkshp on Secure Network Protocols (NPSec). IEEE, October 2013.
[i.18] Diego Kreutz, Fernando M.V. Ramos and Paulo Verissimo: "Towards secure and dependable
software-defined networks". In Proc. 2nd ACM SIGCOMM workshop on Hot topics in software
defined networks, HotSDN '13, pages 55-60, New York, NY, USA, 2013. ACM.
[i.19] ONF Security Discussion Group.
NOTE: https://www.opennetworking.org/working-groups/discussion-groups.
[i.20] OpenFlow Switch Specification.
NOTE: Available via http://archive.openflow.org/wp/documents/.
[i.21] Recommendation ITU-T Y.3500 (July 2014) | International Standard ISO/IEC 17788 "Information
technology - Cloud computing - Overview and Vocabulary".
[i.22] Thomas Ristenpart, Eran Tromer, Hovav Shacham and Stefan Savage: "Hey, You, Get Off of My
Cloud! Exploring Information Leakage in Third-Party Compute Clouds". In Proc. Conference on
Computer and Communications Security (CCS'09), pages 199--212. ACM, November 2009.
[i.23] Dawn Song, David Wagner and Adrian Perrig: "Search on Encrypted Data". In Proc. IEEE
Symposium on Security and Privacy, May 2000.
[i.24] IETF draft-mrw-sdnsec-openflow-analysis-02 (April 2013): "Security Analysis of the Open
Networking Foundation (ONF) OpenFlow Switch Specification", Margaret Wasserman and Sam
Hartman, (work in progress).
[i.25] IEEE 802.1ah: "Provider Backbone Bridges".
[i.26] IEEE 802.1ad: "Provider Bridges".
[i.27] IETF draft-mahalingam-dutt-dcops-vxlan-09 (April 2014): "VXLAN: A Framework for
Overlaying Virtualized Layer 2 Networks over Layer 3 Networks", M. Mahalingam and others,
(work in progress).
ETSI
8 ETSI GS NFV-SEC 001 V1.1.1 (2014-10)
[i.28] IETF draft-davie-stt-06 (April 2014): "A Stateless Transport Tunneling Protocol for Network
Virtualization (STT)", Bruce Davie and Jesse Gross, (work in progress).
[i.29] IETF draft-sridharan-virtualization-nvgre-04 (February 2014): "NVGRE: Network Virtualization
using Generic Routing Encapsulation", Murari Sridharan and others, (work in progress).
[i.30] IETF RFC 3031 (January 2001): "Multiprotocol Label Switching Architecture", Eric Rosen, Arun
Viswanathan and Ross Callon.
[i.31] ETSI/TC LI#35 LI(14)P35037r2 "NFV LI Considerations".
[i.32] NFV White paper (October 2013): "Network Functions Virtualisation, Network Operator
Perspectives on Industry Progress".
NOTE: http://portal.etsi.org/NFV/NFV_White_Paper2.pdf.
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the terms and definitions given in ETSI GS NFV 003 [i.15] and the following
apply:
Forwarding Function: provides forwarding connectivity between multiple (two or more) network interfaces
NOTE 1: This distinguishes a Forwarding Function from just any networked application. A Forwarding Function
receives data at any of the interfaces, processes it, then outputs some transformation of the original to
other network interface(s).
EXAMPLE: Message routing or the filtering provided by a firewall. Some examples of other network functions
are shown in Figure 1.
NOTE 2: 'Some transformation' is necessarily vague. It is meant to preclude server applications that might take in
requests on one interface and send out responses on another. But it is meant to include, say, deep packet
inspection or a packet filter that takes in data packets on one interface and forwards most to an output
interface, but discards or re-orders some packets in the process. It also includes switches or network
address translators that largely forward the data unchanged, but make a few focused changes to addresses.
It even includes meters that take a packet flow as input and output a stream of measurement data that
summarises the characteristics of the input flows.
NOTE 3: Although a Forwarding Function is defined by its multiple data interfaces, the definition does not
preclude other interfaces for control (e.g. routing messages) and management - and these are certainly
within scope of security problem analysis.
NOTE 4: All Forwarding Functions are Network Functions, but some Network Functions do not involve
forwarding. For instance, most directory, control or management functions are Network Functions but not
Forwarding Functions.
hypervisor: computer software, firmware or hardware running on a host computer that creates, runs and monitors guest
virtual machines.
NOTE: A hypervisor enables multiple instances of a variety of guest operating systems to share the virtualised
hardware resources of the host.
ETSI
9 ETSI GS NFV-SEC 001 V1.1.1 (2014-10)
3.2 Abbreviations
For the purposes of the present document, the abbreviations given in ETSI GS NFV 003 [i.15] and the following apply:
AAA Authentication, Authorization and Accounting
API Application Programming Interface
ASIC Application-Specific Integrated Circuit
BGP Border Gateway Protocol (IETF)
BIOS Basic Input/Output System
CA Certification Authorities
CPU Central Processing Unit
DMA Direct Memory Access
ECDSA Elliptic Curve Digital Signature Algorithm
FB Functional Block
FTP File Transfer Protocol (IETF)
GRE Generic Routing Encapsulation (IETF)
GS Group Specification (ETSI)
I/O Input/Output
IDS Intrusion Detection System
IETF Internet Engineering Task Force
IOMMU I/O Memory Management Unit
ISG Industry Specification Group (ETSI)
IS-IS Intermediate System to Intermediate System (IETF)
ISO International Organisation for Standardization
IT Information Technology
JTAG Joint Test Action Group
LAN Local Area Network
LI Lawful Interception (ETSI TC)
LOM Lights-Out Management
MAC Medium/Media Access Control
MANO Management & Orchestration
MMU Memory Management Unit
MPLS Multi-Protocol Label Switching (IETF)
NAT Network Address Translator
NFV Network Functions Virtualisation
NFVIaaS NFV Infrastructure as a Service
NIST National (US) Institute of Standards and Technology
NOC Network Operations Centre
NV-GRE Network Virtualisation using GRE
ONF Open Networking Foundation
OS Operating System
OSPF Open Shortest Path First (IETF)
PCI Peripheral Component Interconnect
QoS Quality of Service
RSA Rivest-Shamir-Adleman
SDN Software Defined Network
SMMU System MMU (ARM)
SR-IOV Single Root I/O Virtualisation (a PCI special interest group standard)
STT Stateless Transport Tunnelling
TC Technical Committee
TCG Trusted Computing Group
TLS Transport Layer Security (IETF)
TPM Trusted Platform Module (TCG)
UEFI The Unified Extensible Firmware Interface forum
VLAN Virtual Local Area Network
VM Virtual Machine
VNF Virtualised Network Function
VNFaaS VNF as a Service
VNPaaS Virtualised Network Platform as a Service
VPN Virtual Private Network
VT-c Virtualisation Technology for connectivity (Intel)
ETSI
10 ETSI GS NFV-SEC 001 V1.1.1 (2014-10)
VT-d Virtualisation Technology for directed I/O (Intel's IOMMU)
VXLAN Virtual eXtensible LAN
4 Industry Context
Traditionally, Network Functions have been bundled into bespoke hardware appliances. In contrast, network functions
virtualisation (or NFV) is the deployment of these services as software modules that run on common off-the-shelf
generic hardware [i.11] over a hypervisor or container that controls access to the hardware devices.
Network function virtualisation has become economic because the sheer scale of the data centre market has drawn
investment and skills towards generic server technology; 9 million IT servers are bought globally each year, but only
180 thousand edge routers. It is safe to predict that a network equipment facility will become physically the same as a
data centre. Virtualised network functions will also be managed in common with IT management processes - as
orchestrated remote software installations deployed independently to hardware upgrades.
The transition towards network functions virtualisation will be incremental. As each bespoke appliance reaches the end
of its life it will be replaced by a software equivalent. Independently, more server blades, storage or network interface
cards will be plugged in to existing racks to provide the necessary hardware resources. For further information, see
[i.11] and for an update on industry activity on NFV see [i.32].
Network Functions Virtualisation
Approach
Independent
Session Border
Message
Software Vendors
Controller
Router WAN
Acceleration
CDN
Carrier
DPI
Grade NAT
Orchestrated,
automatic
Tester/QoE
Firewall
remote install
monitor
SGSN/GGSN
Generic High Volume Servers
BRAS
Radio Network
PE Router Controller
Generic High Volume Storage
Classical Network Appliance
Generic High Volume
Approach
Ethernet Switches
Figure 1: Examples of Network Functions showing the Incremental Process of Virtualisation
NOTE 1: Network functions virtualisation should not be confused with virtual networks like virtual local area
networks (VLANs) or virtual private networks (VPNs) - the two concepts are orthogonal. Another term
for virtual networks is overlay networks, and again NFV is orthogonal to overlays. A virtual network is a
logical partition carved out of a physical network by ensuring its logical connectivity is isolated from
other virtual networks. In contrast, NFV only concerns whether the functions of the nodes of a network
are implemented as software on generic hardware and hypervisor technology, rather than on bespoke
hardware.
NOTE 2: The scope of this problem statement does not include cases where there is no hypervisor or container. In
other words, network functions running as software over a monolithic operating system, even if on
industry-standard hardware are out of scope of the present document, given that bare metal introduces no
security changes relative to the baseline (which is bare metal).
ETSI
11 ETSI GS NFV-SEC 001 V1.1.1 (2014-10)
5 Security Reference Framework
5.1 Deployment Scenarios
Figure 2 illustrates the elements with potentially separate security responsibility in different deployment scenarios: the
building, the host compute hardware, the hypervisors and the guest virtual network functions within their virtual
machines.
Guest
Building
Virtualised
Network
Functions
Hypervisor Hypervisor
Host Hardware Host Hardware
Figure 2: Deployment scenario elements
Below some deployment scenarios are described that are likely in realistic contractual arrangements.
For convenience they are summarised in Table 1. The right-most column also identifies which NFV deployment
scenarios are similar to the common deployment models used in cloud computing, as identified by the ITU-T [i.21]. It
can be seen that the cloud computing industry uses deployment models that sometimes, but not always, relate to those
expected for NFV. The ITU-T document [i.21] also defines Cloud Service Models (Infrastructure, Platform and
Software as a Service). It is possible that virtualisation of network functions might eventually become commoditised
into a set of similar service models, but the NFV industry needs to be allowed to mature before jumping to conclusions
on popular service models.
Table 1: Some realistic deployment scenarios
Deployment Scenario Building Host Hyper- Guest VNF cf. ITU-T
Hard- visor Cloud
ware Vocabulary
Monolithic Operator N N N N Private Cloud
Network Operator Hosting Virtual Network Operators N N N N, N1, N2 Hybrid Cloud
Hosted Network Operator H H H N
Hosted Communications Providers H H H N1, N2, N3 Community
Cloud
Hosted Communications and Application Providers H H H N1, N2, N3, P Public Cloud
Managed Network Service on Customer Premises C N N N
Managed Network Service on Customer Equipment C C N N
NOTE: The different letters represent different companies or organisations, and are chosen to represent different roles,
H = hosting provider, N = network operator, P = public, C = customer.

Monolithic Operator: The same organisation that operates the virtualised network functions deploys and controls the
hardware and hypervisors they run on and physically secures the premises in which they are located.
ETSI
12 ETSI GS NFV-SEC 001 V1.1.1 (2014-10)
Network Operator Hosting Virtual Network Operators: Based on the 'Monolithic Operator' model, except as well as
hosting itself, the network operator hosts other virtual network operators within the same facility. It would probably
isolate each virtual operator on separate hardware. However, in theory, the virtual machines of different virtual network
operators could run alongside each other over the same hypervisor.
Hosted Network Operator: An IT services organisation operates the compute hardware, infrastructure network and
hypervisors on which a separate network operator runs virtualised network functions. The premises including cable
chambers, patch panels, etc. are physically secured by the IT services organisation.
Hosted Communications Providers: Similar to 'Hosted Network Operator', except the IT services organisation hosts
multiple communications providers. Alternatively, the IT services organisation may host one (or many) wholesale
network operators, which in turn host multiple virtual retail communications providers. In this latter case the IT services
organisation would give controlled rights to run virtualised network functions to the wholesaler, which could in turn
delegate rights to the virtualised retailers.
Hosted Communications and Application Providers: Similar to 'Hosted Communications Providers' except servers in
a data centre facility are offered to the public for deploying virtualised applications (Cloud) while in the same physical
facility network operators and communications providers deploy virtualised network functions on the same type of
generic hardware platforms (probably not sharing the same server hardware, but in blades and racks alongside and
sharing the same data centre network).
Managed Network Service on Customer Premises: A network operator runs virtualised network functions on its own
generic server hardware located on a customer's premises and physically secured by the customer.
This model could be in a residential or enterprise scenario, for example, respectively, a remotely managed home
gateway or remotely managed VPN gateways, firewalls, etc.
Managed Network Service on Customer Premises Equipment: Similar to 'Managed Network Service on Customer
Premises', except the compute hardware is supplied and operated by the customer not the network operator. The
customer allocates a blade to the network operator, which runs a hypervisor on this blade, and in turn runs all the
necessary network functions within virtual machines over this hypervisor.
This model does not involve the customer running virtual machines on the same hypervisor and hardware as the
network operator, although this would be another valid scenario (similar to 'Hosted Network Operator' except the
customer both hosts the virtual network functions of the network operator and runs guest applications in virtual
machines alongside them).
In general, in order to determine the security implications of a deployment scenario, the two main factors are:
1) The different parties that operate each of the levels (building, host hardware, hypervisor, guest VNF).
2) Whether the party at any one layer has exclusive or non-exclusive use of the resources of the lower layers and,
if non-exclusive, are the resources available to all other parties or only to a restricted set (e.g. only allied
operators? competing operators? the general public?)
5.2 Threat Surface
This problem statement focuses solely on threats that are specific to NFV (as compared to the known generic
virtualisation threats or known generic networking threats). With proper securing of the infrastructure, NFV could
actually offer security benefits by improving the inherent security properties of network functions.
Since a VNF is but a network function running on a virtual machine, the set of all the security threats to a network
comprising VNFs, at the first approximation, is a union of:
1) all the generic virtualisation threats (e.g. memory leakage, interrupt isolation);
2) the threats specific to the system of physical network functions prior to virtualisation (e.g. flooding attacks,
routing security);
3) new threats due to combining virtualisation technology with networking. These new threats are shown as the
intersection of the two sets in Figure 3, which is the focus of this problem statement.
ETSI
13 ETSI GS NFV-SEC 001 V1.1.1 (2014-10)
This observation can be corrected though when taking into account a major security benefit of virtualisation: the
hypervisor can eliminate some and mitigate other threats inherent to non-virtualised network functions through the use
of hypervisor introspection and other techniques. In other words, virtualisation offers the real possibility of
virtualisation improving the security of a given network compared to its physical counterpart, as represented by the hole
in the intersection of the sets in Figure 3.
Hypervisor-
mitigated threats
generic generic
virtualisation networking
NFV-specific
threats threats
threats
Figure 3: Visualisation of the NFV threat surface
Hence the duality of NFV security-the introduction of new threats due to virtualisation also gives rise to new
opportunities.
It follows that the approach to improving security of a network of VNFs will be two-pronged so as to combine 1)
"shrinking" as much as possible the intersection between the sets by securing the NFV infrastructure and 2) "carving" as
large a "hole" as possible out of the intersection by applying appropriate hypervisor-based security techniques.
The problems identified in this NFV Security Problem Statement outline threats identified so far at the intersection of
virtualisation and networking, which, when contained,should bring the NFV infrastructure to a sufficiently secure level
to be deployable.
5.3 Attacker Profiles
It is traditional to profile attackers by means, motive and opportunity. For instance, attackers could be profiled by their
degree of co-ordination and motivation:
• Disaffected or criminal members of the general public.
• Co-ordinated small groups, such as criminal gangs or terrorist organisations.
• Co-ordinated large organisations with a political, religious or commercial agenda, e.g. government agencies,
corporations.
Introducing NFV makes little difference to such pre-existing motives, but it does alter the means and opportunity to
exploit a vulnerability, to a degree that depends on the technical and contractual position of an organisation in relation
to others in the supply of NFV. Therefore, we define a contractual hierarchy of types of organisations or individuals in
the supply of NFV technology:
• End-customers of retail network operators.
• Retail network operators (sometimes called virtual network operators, but we will avoid that term here because
it is confusing in an NFV context where both real and virtual network operators use virtualised machines).
• Wholesale network operators (in some markets there may be no wholesale/retail split, in other markets there
may be multiple levels of wholesaling).
ETSI
14 ETSI GS NFV-SEC 001 V1.1.1 (2014-10)
• Hypervisor operator - usually the same party as either the infrastructure operator or the wholesale network
operator.
• Infrastructure operators - the party that operates the compute, storage and infrastructure network.
• Facilities manager - the party that secures the physical building, racking, power, cabling, etc.
The last three parties listed above map directly to the lowest three levels of figure 2, while there is sufficient flexibility
within the guest Network Functions in figure 2 to allow the higher levels of the hierarchy to be created in all manner of
different arrangements to suit market conditions. A party at one level voluntarily contracts with the parties operating
lower levels to provide hosted service. This implies that the hosted party places at least a degree of trust in its
underlying hosts (e.g. those operating the security of the building facilities, those with operational access to the
hardware).
Therefore, attacks of initial interest are likely to be confined to those:
1) from a higher level, e.g. an end-customer attacking her network operator or another operator;
2) across from the same level, e.g. a network operator extracting information about a competitor sharing the same
facilities, or one end-customer perverting their network service in order to attack another end-customer;
3) from inside, e.g. a disgruntled employee of a network operator.
Nonetheless, we cannot preclude 'upward' attacks on a guest by its own hosting provider. A hosting company could
mount nearly any attack on its own guests, but it would be unlikely to attempt any attack that degraded its own service,
for obvious reasons of reputation. A hosting provider might however be tempted to mount an attack that its guest would
not be aware of, such as exploiting or selling confidential information like customer records. Alternatively, an insider
within the hosting company might degrade a guest network operator's service in more subtle ways, perhaps in order to
enable a secondary attack. For instance, an insider within the hosting company might open a hole in a guest's firewall,
or suppress certain intrusion detection messages.
Intellectual Property related threats also exists in the NFV environment. Various providers of NFV functions will run
proprietary algorithms, images, static and runtime configuration files and signatures, that they would want to be
protected. Reverse engineering and side channel attacks need to be mitigated to protect the intellectual property of
various vendors running on the same platform from each other and from the platform operator.
Technology is readily available (discussed further in clause 6.3 ) that enables a guest to store keys that it trusts and to do
limited processing within a tamper-resistant module on the host computer. This can provide a technological basis to
underpin the contractual trust that a guest places in its hosting service. However, it is generally infeasible for all of a
guest's computing functions to be concealed from the host within such a secure element, given its limited memory,
processing and I/O resources. An alternative is partial homomorphic cryptography, which is becoming practical for
certain very specific functions without too much overhead (e.g. a guest can ask a hosting service to search through
encrypted data for an encrypted search term and return an encrypted result, so the hosting service never holds the data in
the clear even within its processors [i.23]). Extending applicability from single specific functions to any function would
require fully homomorphic encryption, which has been implemented as an early proof of concept but the outputs
degrade as the number of processing steps increases. Although advances are being made rapidly, it is unknown how
soon (if ever) practical implementations will become feasible [i.1].
ETSI
15 ETSI GS NFV-SEC 001 V1.1.1 (2014-10)
6 Potential Areas of Concern
The key issues submitted by participants in the first ETSI NFV industry specification group (ISG) meeting have been
analysed to identify those related to security. They and additional issues identified within the NFV Security Expert
Group are consolidated into the present document.
Table 2 lists these issues and the identified subsequent clauses describe each issue.
Table 2: Summary of Potential Areas of Concern
Clause Key Issue
6.1 Topology Validation & Enforcement
6.2 Availability of Management Support Infrastructure
6.3 Secured Boot
6.4 Secure crash
6.5 Performance isolation
6.6 User/Tenant Authentication, Authorization and
Accounting
6.7 Authenticated Time Service
6.8 Private Keys within Cloned Images
6.9 Back-Doors via Virtualised Test & Monitoring
Functions
6.10 Multi-Administrator Isolation

6.1 Topology Validation & Enforcement
6.1.1 Topology Validation Example
Figure 4 presents part of a network operator's infrastructure that we will use as an example to explain the topology
validation problem. Figure 5 shows the same infrastructure, but with a representation of some virtualised Forwarding
Functions running on each server. A Forwarding Function is defined in clause 3.1. It can be seen that these particular
virtualised Forwarding Functions do not use all the physical interfaces configured in the hardware. Nonetheless, if
demand required, the unused network interfaces could be powered up and rapidly connected within the vSwitch.
In Figure 4, the hardware switch has been configured to group subsets of the interfaces into different VLANs, each
represented by dashed connecting lines of different colours. The 'no-entry' signs emphasise that the infrastructure has
been configured to provide no connectivity between the customer networks, and also no connectivity between the front
interface on each server and the rear three interfaces (when viewed as a 3-dimensional picture). Therefore, without any
virtualised Forwarding Functions running, each customer network and the core network are all partitioned from each
other. This is an example of the requirement for disconnectedness between many parts of an infrastructure network (see
clause 7.3 of ETSI GS NFV INF 001 [i.14]).
ETSI
16 ETSI GS NFV-SEC 001 V1.1.1 (2014-10)
general-purpose
server blades
compute
infrastructure
core
network
infrastructure
network
customer
networks
NOTE: The 'no entry' signs represent 'default-off' routing between partitioned infrastructure networks.

Figure 4: Example compute and network infrastructure
general-purpose
server blades
core
network
customer
networks
NOTE: For clarity hypervisors are not shown.

Figure 5: Example virtualised network functions running on the compute infrastructure of Figure 4
ETSI
17 ETSI GS NFV-SEC 001 V1.1.1 (2014-10)
Nonetheless, once all the virtualised Forwarding Functions are running (Figure 5) they connect together all the
otherwise partitioned networks. However, the connectivity is conditional on meeting the criteria imposed by each
virtualised Forwarding Function - in this case each vSwitch is configured to require all communication to pass through
a firewall, each firewall will only allow communication if it complies with its own rule-set and if it has not been flagged
as a suspected attack by the IDS. Further, even if a communication passes these tests, its traffic rate has to fit within the
limits imposed by the policer.
To be concrete, the example infrastructure above uses Ethernet VLANs, but it is not important which virtual network
technology is used, and the specific virtualised network functions chosen for the example are also unimportant. Of
course, this toy example represents only a small part of a larger network. For simplicity it only shows data plane
Forwarding Functions, although in reality, the topology of at least 2 types of network would need to be validated:
• data plane (the network over which the packets that provide the user services pass), including:
- intra-host paths (between VNF components and/or VNFs on the same hypervisor)
- inter-host paths (possibly between different hypervisors)
- paths between hosts and bespoke equipment providing physi
...