In this Recommendation, the expression "Administration" is used for conciseness to indicate both a telecommunication administration and a recognized operating agency.
Compliance with this Recommendation is voluntary. However, the Recommendation may contain certain mandatory provisions (to ensure, e.g., interoperability or applicability) and compliance with the Recommendation is achieved when all of these mandatory provisions are met. The words "shall" or some other obligatory language such as "must" and the negative equivalents are used to express requirements. The use of such words does not suggest that compliance with the Recommendation is required of any party.
This International Standard specifies the non-invasive attack mitigation test metrics for determining conformance to the requirements specified in ISO/IEC 19790 for Security Levels 3 and 4. The test metrics are associated with the security functions specified in ISO/IEC 19790. Testing will be conducted at the defined boundary of the cryptographic module and I/O available at its defined boundary.
The ISO/IEC 15946 series specifies public-key cryptographic techniques based on elliptic curves described in ISO/IEC 15946-1.
This document defines elliptic curve generation techniques useful for implementing the elliptic curve based mechanisms defined in ISO/IEC 29192-4, ISO/IEC 9796-3, ISO/IEC 11770-3, ISO/IEC 14888-3 and ISO/IEC 18033-2.
This part of ISO/IEC 15946 describes the mathematical background and general techniques necessary for implementing the elliptic curve cryptography mechanisms defined in ISO/IEC 15946-5, ISO/IEC 9796-3, ISO/IEC 11770-3, ISO/IEC 14888-3, ISO/IEC 18033-2 and other ISO/IEC standards.
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 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.
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 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).
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:
store data (either in their existing business stores, or in dedicated stores of data); and
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.
