Cloud computing

Trust, as defined in ETSI GR NFV-SEC 003, 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 mutually agreed between the vendor and operator. An examples of 3rd a party assurance programme is Common Criteria (defined in ISO/IEC 15408).
 
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.

In NFV network, network services and network functions can be deployed dynamically. The present document specifies functional and security requirements for automated, dynamic security policy management and security function lifecycle management, and Security Monitoring of NFV systems.
 
The main objectives of the present document are to:

• Identify use cases for NFV Security Lifecycle Management across Security Planning, Security Enforcement, and Security Monitoring.
• Establish NFV Security Lifecycle Management and Security Monitoring requirements and architecture.

Ultimate goal of this work: Scope of this activity is to study and investigate NFV security monitoring and management use cases and establish security requirements. The present document investigates passive and active monitoring of subscriber and management information flows, where subscriber information includes signalling and content.
 
Security Management and Monitoring are key components towards successful deployment of NFV. The requirements and results from the present document will act as catalyst towards rapid deployment of NFV.
 
Goals of the present document: The present document will recommend potential methodologies and placement of security visibility and control elements for fulfilling the requirements identified in the present document. The present document will be useful to VNF and VNFI providers, network operators and research community.
 
Non-goal: The present document does not address Lawful Intercept (LI). It may be applicable to performance and reliability monitoring for NFV systems.
 
Intended audience: VNF and NFVI providers, Network Operators, Service Providers, NFV Software Communities, SDOs (e.g. 3GPP, ETSI SC TC Cyber), Security experts and Researchers.

The present document provides the results of a simplified threat analysis for NFV-MANO functional blocks (NFVO, VNFM, VIM) and reference points Or-Vnfm, Vi-Vnfm, Or-Vi based on the guidance given in ETSI GS NFV-SEC 006.
 
The present document is structured such that clause 4 identifies the scope of the analysis, in the form of a target of evaluation, whilst the results of the threat analysis in the form of identified requirements that when implemented will counter or mitigate the threats are given in clause 5 of the present document. A summary is provided in clause 6 of the impact when the requirements are implemented. Threat analysis is a continual process and should be reviewed regularly.

The present document is designed to support Retained Data functionality. For the present document, "Retained Data functionality" is defined as situations in which CSPs, or their equivalent in NFV provisioning architectures, are performing the following tasks:

1. store data (either in their existing business stores, or in dedicated stores of data); and
2. at a later point, when presented with an appropriate request, make available the data that meets the request to the appropriate authority.

The present document is not a legal document. It does not define when or whether these tasks should take place, nor does it define what counts as an appropriate request or appropriate authority. The definition of what is or is not a "Communications Service Provider" (from the point of view of Retained Data) is out of scope. It is a pre-requisite to the present document that Retained Data functionality is in line with appropriate and relevant legislation on privacy and data protection.
 
The term "Data" in the present document is used to describe information which is collected, stored or queried as part of Retained Data functionality.
 
NOTE: In some jurisdictions, Retained Data may include "customer or subscriber data" (i.e. records with information about the customer (e.g. name, address) and their subscription) and "usage data" (i.e. records describing how the service was used). This note is included for background information but is not a definition.

The present document addresses multi-layer administration use cases and technical approaches, an issue identified in the Security Problem Statement, ETSI GS NFV-SEC 001. Multi-layer administration seeks to provide methods, capabilities, procedures and assurances - of various strengths based on requirements and available technologies and techniques - that safeguard Virtual Machines or Containers running on a virtualisation host ("hosted applications") - from interference (of various types) by the host system or platform ("hosting service”).
 
The scope of the present document is generally the system comprising the hosting service, associated hardware (including TPM, GPU, etc.), software and configuration, and the hosted application. Some requirements and measures outside this context are also considered, but not necessarily in equal depth.

The present document is a guide to developers of NFV related documents and applications in means to address the security aspects and regulatory concerns as they impact the security of deployed networks that conform with 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 pro forma template for use in ETSI ISG NFV documents to capture the security concerns and mitigations that apply.

The present document provides a problem statement on implementing LI in NFV and identifies the necessary capabilities to be provided in NFV to meet the requirements outlined for telecommunications capabilities in general in ETSI TS 101 331.
 
The present document identifies the challenges of providing LI in an NFV. The present document is intended to give guidance to the NFV community and to the wider LI community on the provision of LI in an NFV.

The present document has been developed to describe the security and trust guidance that is unique to NFV development, architecture and operation. Guidance consists of items to consider that may be unique to the environment or deployment. Supplied guidance does not consist of prescriptive requirements or specific implementation details, which should be built from the considerations supplied.
 
Guidance is based on defined use cases, included in the present document, that are derived from the Security Problem Statement and are unique to NFV. Relevant external guidance will be referenced, where available.

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.

The present document specifies the interface requirements, the interfaces and the necessary information elements enabling the fault, configuration and information, performance, state and log management of NFV-MANO functional entities.
 
In addition, the present document also describes the framework to support the management of NFV-MANO functional entities.
 
The different aspects specified in the present document have been analysed firstly in ETSI GR NFV-IFA 021