ETSI GS NFV-SEC 012 V3.1.1 (2017-01)

Network Functions Virtualisation (NFV) Release 3; Security; System architecture specification for execution of sensitive NFV components

DGS/NFV-SEC012

General Information

• Status: Published
• Publication Date: 05-Jan-2017
• Technical Committee: NFV SEC - Security
• Current Stage: 12 - Completion
• Due Date: 17-Jan-2017
• Completion Date: 06-Jan-2017

Standards Content (Sample)

ETSI GS NFV-SEC 012 V3.1.1 (2017-01)






GROUP SPECIFICATION
Network Functions Virtualisation (NFV)
Release 3;
Security;
System architecture specification
for execution of sensitive NFV components
Disclaimer
The present 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.

---------------------- Page: 1 ----------------------
2 ETSI GS NFV-SEC 012 V3.1.1 (2017-01)



Reference
DGS/NFV-SEC012
Keywords
architecture, 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/standards-search
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
https://portal.etsi.org/TB/ETSIDeliverableStatus.aspx
If you find errors in the present document, please send your comment to one of the following services:
https://portal.etsi.org/People/CommiteeSupportStaff.aspx
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 2017.
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

---------------------- Page: 2 ----------------------
3 ETSI GS NFV-SEC 012 V3.1.1 (2017-01)
Contents
Intellectual Property Rights . 4
Foreword . 4
Modal verbs terminology . 4
1 Scope . 5
2 References . 5
2.1 Normative references . 5
2.2 Informative references . 5
3 Definitions and abbreviations . 6
3.1 Definitions . 6
3.2 Abbreviations . 6
4 Principles . 7
4.1 Introduction . 7
5 Platform requirements . 7
5.1 Core hardware requirements. 7
5.2 Core software requirements . 8
6 Lifecycle . 9
6.1 Trusted Computing Base . 9
6.2 Workload provisioning . 9
6.3 Runtime checks . 10
6.4 Entropy and random numbers . 10
6.5 Cryptographic primitives . 11
6.6 Installed software and configurations on host system . 12
6.7 De-provisioning workloads . 12
6.8 Dealing with failure . 13
6.8.0 General points . 13
6.8.1 Requirements relating to failure conditions . 13
7 External dependencies . 13
8 Architecture section . 13
8.0 System hardening techniques . 13
8.1 Secure logging . 14
8.2 OS-level access and confinement control . 14
8.3 Physical controls and alarms . 14
8.4 Authentication controls . 14
8.5 Access controls . 14
8.6 Communications security . 15
8.7 Boot . 15
8.8 Attestation . 15
8.9 Hardware-mediated execution enclaves . 15
8.10 Hardware-Based Root of Trust (HBRT) . 15
8.11 Self-encrypting storage . 15
8.12 Direct access to memory . 16
8.13 Hardware Security Modules . 16
8.14 Software integrity protection and verification . 16
History . 17

ETSI

---------------------- Page: 3 ----------------------
4 ETSI GS NFV-SEC 012 V3.1.1 (2017-01)
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 (https://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", "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

---------------------- Page: 4 ----------------------
5 ETSI GS NFV-SEC 012 V3.1.1 (2017-01)
1 Scope
The present document defines requirements for host system elements on which sensitive workloads are to be run. The
present document defines requirements to ensure isolation of sensitive workloads from non-sensitive workloads sharing
a platform. The present document discusses a wide range of different technologies which aim to increase the security of
a host system for the workloads which will be executing on it.
2 References
2.1 Normative 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
https://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.
The following referenced documents are necessary for the application of the present document.
[1] ETSI TS 133 310: "Universal Mobile Telecommunications System (UMTS); LTE; Network
Domain Security (NDS); Authentication Framework (AF) (3GPP TS 33.310)".
[2] ETSI TS 133 210: "Digital cellular telecommunications system (Phase 2+) (GSM); Universal
Mobile Telecommunications System (UMTS); LTE; 3G security; Network Domain Security
(NDS); IP network layer security (3GPP TS 33.210)".
[3] ISO/IEC 18031:2001: "Information technology -- Security techniques -- Random bit generation or
equivalent specification".
2.2 Informative 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.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
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] NIST Publication (SP) 800-90B: "Recommendation for the Entropy Sources Used for Random Bit
Generation".
[i.2] NIST Publication (SP) 800-88 revision 1: "Guidelines for Media Sanitization".
[i.3] ETSI GS NFV-SEC 009: "Network Functions Virtualisation (NFV); NFV Security; Report on use
cases and technical approaches for multi-layer host administration".
[i.4] Greg Hoglund, Gary McGraw (2007): "Exploiting Online Games: Cheating Massively Distributed
Systems", Addison-Wesley, New Jersey.
[i.5] ETSI TS 103 487 "CYBER; Baseline security requirements regarding sensitive functions for NFV
and related platforms".
[i.6] ETSI TR 103 309: "CYBER; Secure by Default - platform security technology".
ETSI

---------------------- Page: 5 ----------------------
6 ETSI GS NFV-SEC 012 V3.1.1 (2017-01)
[i.7] NIST SP800-123: "Guide to General Server Security".
[i.8] NIST SP800-125: "Guide to Security for Full Virtualization Technologies".
[i.9] ISO/IEC 15408: "Information technology -- Security techniques -- Evaluation criteria for IT
security -- Part 1: Introduction and general model".
[i.10] ETSI GR NFV-SEC 003: "Network Functions Virtualisation (NFV); NFV Security; Security and
Trust Guidance".
[i.11] ETSI GS NFV-INF 004 (V1.1.1): "Network Functions Virtualisation (NFV); Infrastructure;
Hypervisor Domain".
[i.12] TCG: "Virtualized Trusted Platform Architecture Specification", Version 1.0, Revision 0.26.
[i.13] NIST SP 800-162: "Guide to Attribute Based Access Control (ABAC) Definition and
Considerations".
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the following terms and definitions apply:
host system: collection of hardware, software and firmware making up the system which executes workloads
NOTE 1: When the host system is part of the NFVI, it is the "hypervisor" and "host" as defined by ETSI
NFV-INF 004 (V1.1.1) [i.11]. In the case of virtualisation of workloads within the MANO
domain, there is no corresponding definition available.
NOTE 2: The definition in ETSI NFV-INF 004 [i.11] specifically excludes containers, but the present
document does not.
workload: component of the NFV architecture that is virtualised in the context of a particular deployment
3.2 Abbreviations
For the purposes of the present document, the following abbreviations apply:
ABAC Attribute-Based Access Control
DH Diffie-Hellman
DHE Diffie-Hellman Exchange
DSA Digital Signature Algorithm
ECDH Elliptic Curve Diffie-Hellman
ECDHE Elliptic Curve Diffie-Hellman Exchange
ECDSA Elliptic Curve Digital Signature Algorithm
ECP Elliptic Curve modulo a Prime
GMAC Galois Message Authentication Mode
HBRT Hardware-Based Root of Trust
HMEE Hardware-Mediated Execution Enclave
ICV Integrity Check Value
HSM Hardware Security Module
IOMMU Input-Output Memory Management Unit
MANO MANagement and Orchestration
MODP More mODular exPonential
NIST National Institute of Standards and Technology
PKI Public Key Infrastructure
PRF Pseudo-Random Function
RNG Random Number Generator
RSA Rivest-Shamir-Adleman
ETSI

---------------------- Page: 6 ----------------------
7 ETSI GS NFV-SEC 012 V3.1.1 (2017-01)
SSL Secure Sockets Layer
TCB Trusted Computing Base
TCG Trusted Platform Group
TLS Transport Layer Security
TPM Trusted Platform Module
4 Principles
4.1 Introduction
Trust, as defined in ETSI GR NFV-SEC 003 [i.10], is an important component of security. One weakness of software as
opposed to hardware, is that software can be copied in whole or in part. Trust that is rooted in software may be less
reliable than trust rooted in hardware, quickly, easily, and any number of times. For the particular case of sensitive
workloads that have to be trusted, only the highest assurance in the root of trust is considered acceptable, thus for the
purposes of the present document the root of trust shall be provided in hardware.
There is, however, a concomitant concern that when a device is subject to black box testing, it is impossible to
determine if the responses to interrogation come from hardware or software. To counter this, a NFVI vendor shall be
able to provide evidence on demand that the root of trust is a hardware element. The means by which the vendor
provides such evidence is not considered in the present document but should be mutually agreed between the vendor
and operator.
A vendor shall be able to provide evidence on demand to authorized parties of the security claims for the root of trust.
The means by which the vendor provides such evidence is not considered in the present document, but should be
rd
a party assurance programme is Common Criteria
mutually agreed between the vendor and operator. An examples of 3
(defined in ISO/IEC 15408 [i.9]).
The host system, acting as a black box (closed) environment, shall provide access to authorized external entities only to
those capabilities identified in the authorization agreement.
5 Platform requirements
5.1 Core hardware requirements
1) The host system shall implement a Hardware-Based Root of Trust (HBRT) as Initial Root of Trust with the
following requirements:
- The HBRT shall be both physically and electronically tamper-resistant.
- The HBRT shall be both physically and electronically tamper-evident.
- The HBRT physical and software interfaces between the HBRT and other hardware components of the
host system to which it directly communicates shall be protected from eavesdropping, manipulation,
replay or similar attacks.
- The level of resistance against attacks of the HBRT shall be verifiable and trustable using a certification
process.
- It shall be possible to restrict the booting procedure if assistance from the HBRT is not available or the
HBRT currently does not contain valid cryptographic material.
- Any tampering to the HBRT should lead to detectable degradation of its function.
- The HBRT shall be physically protected such that any attempts to remove or replace the HBRT shall
cause physical damage to both the HBRT and host system hardware to which the HBRT is attached,
rendering both inoperable.
ETSI

---------------------- Page: 7 ----------------------
8 ETSI GS NFV-SEC 012 V3.1.1 (2017-01)
- The HBRT shall be (physically and/or logically) bound to the host system, so that any attempt to remove
the HBRT will be detected and prevent normal operation of the host system.
- The HBRT shall include an Immutable Unique Identification value physically linked to the physical root
of trust that can be used as identification of the platform. This value shall be stored in a shielded location
protected from unauthorized use and disclosure.
- The HBRT shall provide capabilities to allow itself to be part of an attestation function.
- The host system shall have a mechanism to discover the tampered/non-tampered status of the HBRT.
- The host system shall have an interface to provide authorized external services with information about
the tampered/non-tampered status of the HBRT.
- The host system shall provide a mechanism to report to authorized external services when tamper events
occur.
- The HBRT shall implement a key management function with the requirements in the following bullet 2.
2) The host system shall implement a key management system which includes key generation, key storage, key
deletion and cryptographic processing with the following requirements:
- The cryptographic material shall be stored in a shielded location, protected against eavesdropping and
physical and environmental tampering.
- The key generation processing shall be protected against eavesdropping and physical and environmental
tampering.
- The key management system shall include an access right management to the sensitive data.
- The key management system shall ensure a complete deletion of outdated keys under deletion request.
- The key management system shall be scalable and ensure a high availability service.
- The key management system shall be remo
...