Cloud computing

The present document defines the access tokens and related metadata for RESTful protocols and data model for ETSI NFV management and orchestration (MANO) interfaces. It defines also the process for the token verification by the API Producer.
 
For this aim, the present document:

• Analyses the security threat arising from the misuse of the access token and defines the security requirements associated to access token.
• Analyses existing specifications related to access token for API access and their compliancy with the requirements defined.
• Defines the token request and generation profile, the token format and associated metadata considering the result of existing access token specifications analysis.
• Defines the token verification procedures for the API Producer.

The present document outlines the requirements for integrity and authenticity protection by signing VNF Package artifacts and verifying these artifacts during instantiation. The present document also considers the confidentiality of VNF Package artifacts and outlines a process for the service provider to provide confidentiality during onboarding. The present document expands on requirements for security and integrity of a VNF Package that is defined in ETSI GS NFV-IFA 011, clause 6.2.4 and ETSI GS NFV-SOL 004, clause 5.
 
VNF Package security validation check during the onboarding is a crucial factor for the successful deployment of VNFs. During the onboarding, the authenticity and integrity of the VNF Package is verified against the signature provided by the VNF provider. There are more potential ways to exploit the VNF Packages while it is in the NFV- MANO domain (i.e. while the VNF package is stored within different NFV-MANO catalogues). The existing methods do not ensure that the operator has the opportunity and means to authorize VNF Packages for deployment on their network (e.g. avoid a VNF intended for one deployment scenario with a valid VNF provider certificate being loaded by an attacker into another network operator's catalogue). Furthermore, some operators might wish to undertake additional security validation of the VNF Package during the onboarding process and operator's signing could be used to certify the VNF as authorized to onboard into the operator's network.

The present document outlines the requirements for integrity and authenticity protection by signing VNF Package artifacts and verifying these artifacts during instantiation. The present document also considers the confidentiality of VNF Package artifacts and outlines a process for the service provider to provide confidentiality during onboarding. The present document expands on requirements for security and integrity of a VNF Package that is defined in ETSI GS NFV-IFA 011, clause 6.2.4 and ETSI GS NFV-SOL 004, clause 5.
 
VNF Package security validation check during the onboarding is a crucial factor for the successful deployment of VNFs. During the onboarding, the authenticity and integrity of the VNF Package is verified against the signature provided by the VNF provider. There are more potential ways to exploit the VNF Packages while it is in the NFV- MANO domain (i.e. while the VNF package is stored within different NFV-MANO catalogues). The existing methods do not ensure that the operator has the opportunity and means to authorize VNF Packages for deployment on their network (e.g. avoid a VNF intended for one deployment scenario with a valid VNF provider certificate being loaded by an attacker into another network operator's catalogue). Furthermore, some operators might wish to undertake additional security validation of the VNF Package during the onboarding process and operator's signing could be used to certify the VNF as authorized to onboard into the operator's network.

The present document specifies a data model for NFV descriptors, using the TOSCA Simple Profile in YAML, fulfilling the requirements specified in ETSI GS NFV-IFA 011 and ETSI GS NFV-IFA 014 for a Virtualised Network Function Descriptor (VNFD), a Network Service Descriptor (NSD) and a Physical Network Function Descriptor (PNFD). The present document also specifies requirements on the VNFM and NFVO specific to the handling of NFV descriptors based on the TOSCA Simple Profile in YAML specification.

The present document defines the protocol and data model for the following interfaces used over the Ve-Vnfm reference point, in the form of RESTful Application Programming Interfaces (APIs) specifications:

• VNF Lifecycle Management interface (as produced by the VNFM towards the EM/VNF).
• VNF Performance Management interface (as produced by the VNFM towards the EM).
• VNF Fault Management interface (as produced by the VNFM towards the EM).
• VNF Indicator interface (as produced by the EM/VNF towards the VNFM).
• VNF Configuration interface (as produced by the VNF towards the VNFM). Table 4.1-1 lists the versions of the APIs defined in the present document.

The present document specifies the structure and format of a VNF package file and its constituents, fulfilling the requirements specified in ETSI GS NFV-IFA 011 for a VNF package.
 
The present document also specifies the structure and format of a PNFD archive file and its constituents, fulfilling the requirements specified in ETSI GS NFV-IFA 014 for a PNFD archive.

The present document defines the protocol and data model for the following interfaces, in the form of RESTful Application Programming Interface (APIs) specifications:

• NSD Management interface (as produced by the NFVO towards the OSS/BSS)
• NS Lifecycle Management interface (as produced by the NFVO towards the OSS/BSS)
• NS Performance Management interface (as produced by the NFVO towards the OSS/BSS)
• NS Fault Management interface (as produced by the NFVO towards the OSS/BSS)
• VNF Package Management interface (as produced by the NFVO towards the OSS/BSS)

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 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.