ETSI NFV-SEC EG: an important driver of security in telco standardization
- There is an industry-wide and general lack of interoperable security mechanisms and specifications in the area of virtualization
- ETSI NFV-SEC EG addresses security aspects unique to virtualized environments and deployments, filling gaps that are not considered elsewhere in the industry.
- There are currently seven prominent security topics subject to ETSI NFV-SEC specifications.
While great progress has been made in container-based deployments and orchestration over the past several years, there is an industry-wide and general lack of interoperable security mechanisms and specifications for this area. The specifications developed by the European Telecommunications Standards Institute (ETSI) Network Functions Virtualization (NFV) Security (SEC), or ETSI NFV-SEC for short, handle security aspects for virtualized environments and deployments that are not addressed elsewhere in the industry.
The NFV-SEC specifications are, for the most part, independent of the chosen orchestration solution (thus not dependent on the adoption of an NFV-MANO solution in Operations Support Systems (OSS). This makes ETSI NFV-SEC particularly relevant, and we are key contributors to this important security work.
ETSI NFV-SEC work is positioned in the context of standardization of OSS aspects, an area that is quite wide. This is especially true for interactions between OSS and cloud, with several standardization bodies – including ETSI NFV and Open RAN (O-RAN) – covering these infrastructures with additional support from opensource initiatives. Many projects hosted under Linux Foundation have become “de facto” standards, especially around cloud-native orchestration solutions and related tools based on Kubernetes®.
Before we outline the seven most prominent security topics currently subject to ETSI NFV-SEC specifications, let’s first define the subject matter.
What is Network Function Virtualization?
NFV transformation allows network operators to flexibly manage and expand network capabilities on-demand, on a virtualized infrastructure, using any virtualization technology such as virtual machines or containers.
For the telco domain, 3GPP defines the Network Function (NF) as a “3GPP adopted or 3GPP defined processing function in a network, which has defined functional behavior and 3GPP defined interfaces”. It can be hardware-based (as a network element), software-based (running on dedicated hardware), or virtualized (instantiated on an appropriate platform such as cloud infrastructure).
Virtualization is the primary implementation method of 5G networks. As with most systems, security is a core dimension that must be developed from early stages in standards.
What is ETSI NFV?ETSI NFV is an Industry Specification Group (ISG). Since its creation in November 2012, it has delivered a series of specifications, from release 1 in 2013 to release 6 planned for 2024 and onwards. ETSI NFV started with the mission to “softwarize” the telecom network by decoupling software and hardware, and automating telecom NF lifecycle management. This process would be independent of NF functionality or hardware, and involved the addition of a virtualization layer. Initially, this layer relied heavily on virtual machines (VMs) created and run by hypervisors. Since then, other virtualization technologies, such as container-based environments, have been incorporated. |
Orchestration aspects apply to various layers (end-to-end, service-level orchestration, function-level orchestration, or more granular at micro-service/sub-function level) and are extensively addressed in the industry. However, the security and lawful intercept aspects for the orchestration stack, as well as the cloud management layer interacting with OSS orchestration, cannot be neglected. These aspects are addressed in ETSI NFV in a dedicated Expert Group: the NFV-SEC EG.
We consider that the security solutions have a broader applicability than the NFV Management and Orchestration (NFV-MANO) architecture. In most cases, the mechanisms are general security solutions that can be applied regardless of the chosen orchestration solution (such as certificate management, security management, virtual resources isolation or quarantining, and containers security).
How is the ETSI NFV-SEC work organized?
Within ETSI NFV-SEC, the Security Expert Group (EG) is a collaboration between security experts representing operators, vendors, governmental organizations, and others. Their task is to produce group specifications and reports for different security areas relevant to NFV. The group also works closely with other ETSI NFV working groups.
In the ETSI NFV architectural framework1, the specified NFV-MANO provides an overview of the functional blocks and functions to realize the management and orchestration layer, as well as the corresponding architecture published in the ETSI GS NFV 006 specification2. Ericsson served as rapporteur for this. The basic NFV-MANO architecture initially targeted VM-based deployments and introduced the Network Functions Virtualization Orchestrator (NFVO), Virtualized Network Function Manager (VNFM), and Virtualized Infrastructure Manager (VIM).
NF deployments are done on the NFV Infrastructure (NFVI) which consists of the virtualized platform running on HW and the HW infrastructure. It may also include wide area networks that connect different points of presence. For containerized deployments, new architectural entities were added to illustrate the reuse of “de facto” Kubernetes®-based solutions for Container Infrastructure Services (CIS), CIS Management, Container Images Registry (CIR), and Container Cluster Management (CCM). In container-based environments, CIS is considered part of the NFVI.
The applications run on the NFVI and are deployed by NFV-MANO as Virtualized Network Functions (VNFs) on any virtualization technology (VMs or containers). Nested virtualization scenarios, such as containers on VMs, are also included as possible virtualization technologies, in addition to support for containers on baremetal.
The 3GPP NFs for the telecom industry are examples of applications that can run on NFVI. Consequently, 3GPP SA5 specifications reference ETSI NFV standards. “Security is embedded in the NFV DNA”3, making it synonymous with robustness when all layers are jointly considered. This includes security technologies, policies, processes, and best practices throughout all lifecycle stages of standards, product, and network developments.
References in this section
1. ETSI NFV Architectural Framework (ETSI GS NFV 002)
2. Management and Orchestration: Architectural Framework Specification (ETSI GS NFV 006)
Security areas undergoing specification work at ETSI NFV-SEC
Security area 1: Secure NFV-MANO
An initial threat analysis of the NFV-MANO blocks (NFVO, VNFM, VIM) and corresponding reference points has been published4 and includes a set of mitigation requirements. Such a threat analysis could also be applicable to orchestration solutions that do not rely on a standard compliant ETSI NFV-MANO architecture (in other words, where components other than NFVO, VNFM and VIM exchange orchestration information).
The analysis is conducted according to the so-called ‘pro forma of security and regulatory concerns for use in ETSI ISG NFV’ and published in a report5.
Implementing an authentication and authorization framework with secure communications across the specified ETSI NFV interfaces6 can fulfil several of the listed requirements. Notably, the various OSS orchestration entities (like NFV-MANO) are expected to communicate over secure channels which TLS (over which HTTP is expected to run) can provide. In addition, TLS profiles are being aligned to those in 3GPP 5G security.
End-point mutual authentication with certificates is being promoted, aligning well with 5G SBA architecture and remaining relevant even when orchestration solutions other than NFV-MANO is used. HTTP basic authentication (with login and password) is also no longer recommended.
The specification also covers authorization using OAuth 2.0. OAuth 2.0 roles have been mapped to NFV-MANO roles in7, which conducts a risk analysis based on the IETF RFC 6819 threat model. It also proposes a new JSON Web Token format with additional NFV metadata. Additional requirements, like binding tokens to certificates, are suggested to mitigate risks associated with the access tokens. Quite naturally, many of these security provisions and requirements are adopted as normative text by the specifications.
References in this section
4. Security Specification for MANO Components and Reference points (ETSI GS NFV-SEC 014)
5. Report on Security Aspects and Regulatory Concerns (ETSI GS NFV-SEC 006)
6. NFV-SOL Specification of common aspects for Restful NFV MANO APIs (ETSI GS NFV-SOL 013)
7. Access Token Specification for API Access (ETSI GS NFV-SEC 022)
Security area 2: Security management
An important outcome of NFV-SEC is the Security Management and Monitoring specification8. Published in 2017, it proposes an architecture for the monitoring and security management of NFV systems and will be replaced by the Security Management Specification9. Two relevant documents for security management have also been published since its release:
- Architecture enhancement for Security Management Specification10 which defines the Security Manager entity and introduces requirements to support NFV-SEC security management and monitoring aspects.
- Interface and Information Model Specification11 which shows how the new Security Manager reference points can be realized by reusing existing NFV-MANO interfaces consumed by the Security Manager.
While the upcoming Security Management Specification9 reuses concepts from the above specifications, it proposes a simpler architecture compared to the 2017 publication. It will also clarify existing topics such as VNF secure bootstrap protocol with remote attestation and hardware-mediated execution enclaves. These updates will not only cover VM- but also container-based deployments, alongside several fixes to improve protocol security.
References in this section
8. Security Management and Monitoring specification (ETSI GS NFV-SEC 013)
9. Security Management Specification ETSI GS NFV-SEC 024 (ongoing draft)
10. Architecture Enhancement for Security Management Specification (ETSI GS NFV-IFA 026)
11. Interface and Information Model Specification (ETSI GS NFV-IFA 033)
Security area 3: VNF package security
To ensure public-key based authenticity and integrity for the whole VNF package, providers are expected to follow one of two methods identified in the VNF Package specification12 (aspects on artefacts confidentiality are also addressed). To validate VNF packages at onboarding by the service provider, the solution requires a root certificate from a trusted CA that is pre-installed in the NFVO.
The requirements at both VNF package onboarding and VNF instantiation have just been published in a new specification release13. For example:
- At onboarding, the VNF provider’s signature on individual artifacts shall be stored by NFV-MANO.
- At VNF instantiation, all available signatures are checked, and the artefacts must have a signature from the VNF provider before being used.
Requirements like these will be further refined in the Container Security Specification14.
What is a VNF package?A VNF package is defined as an “archive that includes a VNF Descriptor (VNFD), the software image(s) associated with the VNF, as well as additional artefacts to, for example, check the integrity and prove the validity of the archive”. In the NFV-MANO architecture, the NFVO supports the verification of the VNF Package’s integrity and authenticity. |
Note: The VNF Package specification12 assumes ETSI VNFD is included. However, other standardization bodies, such as O-RAN, also refer to12 as a standardized, interoperable packaging solution allowing for different Deployment Descriptors. The applicable security aspects remain consistent, regardless of the VNF Package's descriptors and content.
References in this section
12. VNF Package and PNFD Archive specification (ETSI GS NFV-SOL 004)
13. VNF Package security specification (ETSI GS NFV-SEC 021)
Security area 4: Container security
The initial focus on VM-based deployments has since evolved towards container technologies. Currently an open draft, the Container Security Specification14 will include:
- A threat analysis for container-based NFV deployments.
- Requirements to securely run container-based VNFs (be it on baremetal or in VMs).
It is worth recalling that the NFV-MANO architectural framework introduces new functions (not functional blocks) to support containerized deployments. Following the publication of the first normative specification for “Cloud-native VNFs and Container Infrastructure management” at ETSI NFV, Ericsson wrote a summary of the NFV-MANO enhancements for the ETSI blog.
The latest Container Security specification draft14 considers alignment with existing NFV-IFA specifications. It already includes a threat analysis and descriptions of attacks related to container image management, container escape, and the orchestration layer. It also offers software solutions for container isolation.
It furthermore includes requirements for container image management during VNF package onboarding and VNF instantiation. In addition, it discusses the use of a hardware-based trusted execution environment in the software supply chain. The draft offers an alternative solution applicable to attestation-capable environments to validate container software integrity during VNF instantiation. The goal is to bind the container image from the post-build stage by the VNF provider to the container instantiation stage (e.g. by the service provider or tenant).
The analysis, resulting requirements, and applicability of ETSI GS NFV-SEC 02314 is independent of whether the NFV-MNAO stack is used for orchestration or something else. The assumed container-based technology is based on the Kubernetes® APIs15, making it applicable to Kubernetes® based solutions in general.
References in this section
14. Container Security Specification ETSI GS NFV-SEC 023 (ongoing draft)
15. Profiling specification of protocol and data model solutions for OS Container management and orchestration (ETSI GS NFV-SOL 018)
Security area 5: Certificate management
Certificate management was one of the early topics addressed by NFV-SEC with the first report published in 201916 (in addition to more generic work on trust17). IETF work was used to introduce general considerations on PKI, including the description of a typical certificate validation algorithm. Specific to NFV, the report introduces:
- Several use-cases requiring certificates.
- Certificate categories to be handled in an NFV deployment.
- Alternatives to illustrate the initial process of acquiring credentials by end-entities.
- Certificate enrolment flows with CMPv2.
- A high level discussion on certificate lifecycle management.
An updated report has since been published18 with several notable amendments:
- EST protocol (IETF RFC 7030) is exemplified in VNFCI certificate enrolment sequence flows.
- A new set of recommendations for subsequent normative work (specifications) on certificate management.
- A new clause with characteristics related to container-based VNFs.
Driven by NFV-SEC, the normative work on certificate management has been formally proposed to the NFV-IFA working group as an IFA “feature enhancement”. The proposal is based on, but not limited to, the recommendations from the NFV-SEC report18 in generating requirements. Similar to previous reports19, finding a solution to synchronizing lifecycle management (LCM) operations for certificates with VNF LCM was identified as a particular gap.
The first specifications to include normative work on the certificate management area in ETSI NFV have recently been published:
- Security Architecture20: introduces the certificate management function (CMF) to mediate various related operations such as end-entity registration to the CA, two certificate management modes (direct- and delegation-mode, with Ericsson having contributed heavily on the former), several use-cases, a security comparison between the two modes, etc.
- Security interfaces21: showing how CMF interface with NFV-MANO is realized in both direct- and delegation-mode.
These certificate management specifications apply to any orchestration entity in OSS, whether NFV-MANO based or not.
References in this section
16. Report on Certificate Management (ETSI GR NFV-SEC 005, v1.1.1)
17. Security and Trust Guidance report (ETSI GR NFV-SEC 003)
18. Report on Certificate Management (ETSI GR NFV-SEC 005, v1.2.1)
19. Report on further NFV support for 5G (ETSI GR NFV-IFA 037)
20. Architecture enhancement for Security Management Specification (ETSI GS NFV-IFA 026)
21. Interface and Information Model Specification (ETSI GS NFV-IFA 033)
Security area 6: Secure end-to-end management, isolation and trust domains
An ongoing draft, the Secure End-to-End VNF and NS Management Specification22 will introduce a threat analysis for both VNF and network service (NS) throughout their lifecycle (onboarding, instantiation, configuration, run-time and termination).
The latest draft specifies requirements for VNF/NS onboarding and VNF instantiation. An important contribution will be a set of enhancements to the NFVI platform capability registry. It will also propose additional security features on the NFVI platform to be added in this registry, as some VNF suppliers use the underlying NFVI platform capabilities to accelerate performance and optimize throughput of their VNF products” (e.g., accelerators).
The Isolation and trust domain specification23 (ongoing draft) addresses key security issues in multi-tenancy scenarios. This upcoming specification will outline requirements and solutions for the NFV system to enhance network functions and services isolation between tenants. The latest draft also includes a threat analysis for the multi-tenancy scenarios described in the NFV-EVE report24 and proposes comprehensive mitigation requirements. It will continue with more requirements on trust domain separation, memory protection and access control, hypervisor trust portioning, escape protection, and key management systems.
In the context of identity management and in relation to the security management specification, the NFV-SEC group is currently studying how identities are securely lifecycle managed, verified and trusted25.
References in this section
22. Secure End-to-End VNF and NS management specification ETSI GS NFV-SEC 025 (ongoing draft)
23. Isolation and trust domain specification ETSI GS NFV-SEC 026 (ongoing draft)
24. Report on Multi-tenancy in NFV ETSI GR NFV-EVE 018 (ongoing draft)
25. Identity Management and Security Specification ETSI GS NFV-SEC 020 (ongoing draft)
Security area 7: Security assurance
Security assurance is an area that has, in the last few years, increased in importance to provide tenants with a comprehensive approach in their deployments. The first edition of the Security Assurance Specification (SCAS) for NFV-MANO26 was recently published. Leveraging the security assurance methodology introduced in 3GPP, it provides security requirements and test cases to evaluate the security of generic MANO products.
Given its genericity, this specification is expected to apply to other orchestration functions in OSS, whether MANO-based or not. Three new SCAS specifications have also just been started in NFV-SEC to specifically address MANO entities: SCAS for NFVO, SCAS for VNFM, and SCAS for VIM.
References in this section
26. Security Assurance Specification (SCAS) for NFV-MANO (ETSI GS NFV-SEC 028)
ETSI NFV-SEC: enhanced telco security for virtualized deployments
While NFV brings clear benefits to CSPs, it also poses challenges when compared to legacy networks.
The ETSI NFV-SEC EG specifications are generally applicable to telecom orchestration solutions on cloud, using either VMs or container-based technologies. This makes them especially useful for CSPs. In the containerized deployments area, the specifications face competition from de facto cloud-native solutions. ETSI NFV-SEC promotes security best practices and telecom-grade requirements on security and lawful intercept. In addition, the specifications are generally applicable to orchestration and deployments on virtualized cloud systems, regardless of the orchestration solution used.
ETSI NFV-SEC EG collaborates with other industry groups that are active in the NFV arena, aligning with other relevant organizations such as 3GPP, IETF, and NIST. Where applicable, it also includes considerations and references to Linux Foundation CNCF projects. This helps to close identified gaps and produce specifications relevant to 5G security and for the areas of virtualized deployments orchestration.
In conclusion, the ETSI NFV-SEC EG work addresses security aspects unique to virtualized environments and deployments, filling gaps that are not considered elsewhere in the industry. The specifications are largely agnostic to the choice of orchestration solution, eliminating the need to adopt an NFV-MANO solution in OSS. Our active involvement as key contributor underscores our commitment to advancing security in this domain.
Learn more
RELATED CONTENT
Like what you’re reading? Please sign up for email updates on your favorite topics.
Subscribe nowAt the Ericsson Blog, we provide insight to make complex ideas on technology, innovation and business simple.