ETSI GS NFV-SEC 023 V5.4.1 (2026-04)

Network Functions Virtualisation (NFV) Release 5; Security; Container Security Specification

DGS/NFV-SEC023

General Information

• Status: Not Published
• Technical Committee: NFV SEC - Security
• Current Stage: 12 - Completion
• Due Date: 03-Apr-2026
• Completion Date: 02-Apr-2026

Standards Content (Sample)

GROUP SPECIFICATION
Network Functions Virtualisation (NFV) Release 5;
Security;
Container Security Specification
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.

2 ETSI GS NFV-SEC 023 V5.4.1 (2026-04)

Reference
DGS/NFV-SEC023
Keywords
container, cyber security, NFV, security

ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - APE 7112B
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° w061004871

Important notice
The present document can be downloaded from the
ETSI Search & Browse Standards application.
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 prevailing version of an ETSI
deliverable is the one made publicly available in PDF format on ETSI deliver repository.
Users should be aware that the present document may be revised or have its status changed,
this information is available in the Milestones listing.
If you find errors in the present document, please send your comments to
the relevant service listed under Committee Support Staff.
If you find a security vulnerability in the present document, please report it through our
Coordinated Vulnerability Disclosure (CVD) program.
Notice of disclaimer & limitation of liability
The information provided in the present deliverable is directed solely to professionals who have the appropriate degree of
experience to understand and interpret its content in accordance with generally accepted engineering or
other professional standard and applicable regulations.
No recommendation as to products and services or vendors is made or should be implied.
No representation or warranty is made that this deliverable is technically accurate or sufficient or conforms to any law
and/or governmental rule and/or regulation and further, no representation or warranty is made of merchantability or fitness
for any particular purpose or against infringement of intellectual property rights.
In no event shall ETSI be held liable for loss of profits or any other incidental or consequential damages.

Any software contained in this deliverable is provided "AS IS" with no warranties, express or implied, including but not
limited to, the warranties of merchantability, fitness for a particular purpose and non-infringement of intellectual property
rights and ETSI shall not be held liable in any event for any damages whatsoever (including, without limitation, damages
for loss of profits, business interruption, loss of information, or any other pecuniary loss) arising out of or related to the use
of or inability to use the software.
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.

© ETSI 2026.
All rights reserved.
ETSI
3 ETSI GS NFV-SEC 023 V5.4.1 (2026-04)
Contents
Intellectual Property Rights . 5
Foreword . 5
Modal verbs terminology . 5
1 Scope . 6
2 References . 6
2.1 Normative references . 6
2.2 Informative references . 6
3 Definition of terms, symbols and abbreviations . 7
3.1 Terms . 7
3.2 Symbols . 7
3.3 Abbreviations . 7
4 NFV container deployments . 8
4.1 Introduction . 8
4.2 Assumptions . 8
4.2.1 Introduction. 8
4.2.2 Assumptions on modelling the containerized workloads . 8
4.2.3 General assumptions on the CIS infrastructure . 9
4.3 Deployment Options. 9
4.3.1 Container Platform . 9
4.3.1.1 Introduction . 9
4.3.1.2 Container Infrastructure Services on bare metal . 9
4.3.1.3 Container Infrastructure Services Nested within VMs . 10
4.3.1.4 Container Infrastructure Services both on bare-metal and in VMs . 10
4.3.2 Orchestration and Management . 10
4.3.2.1 Introduction . 10
4.3.2.2 CISM embedded in the VIM or as a stand-alone functional block . 10
4.3.2.3 CISM embedded into VNF . 11
5 Security Threats . 11
5.1 Introduction . 11
5.2 Risk Analysis and Requirements . 11
5.3 Threat Descriptions . 14
5.3.1 Compromised Container OS Image . 14
5.3.2 Image Management. 15
5.3.3 Containerized Workload Exploitation . 15
5.3.4 Container Escape Attacks . 15
5.3.5 Orchestration. 16
6 Security Requirements . 16
6.1 Introduction . 16
6.2 Software Development Life Cycle . 17
6.3 Platform Security Hardening . 17
6.3.1 Operating System Hardening . 17
6.3.2 Namespaces . 18
6.3.3 Control Groups . 18
6.3.4 Linux Capabilities . 19
6.3.5 Secure computing mode . 19
6.3.6 Mandatory Access Control . 19
6.4 Storage . 20
6.5 Secure communication . 20
6.6 Operational Security . 20
6.6.1 Account Management . 20
6.6.2 Account Authentication . 20
6.6.3 Container Image Registry Protection . 21
6.6.4 Image Management. 21
ETSI
4 ETSI GS NFV-SEC 023 V5.4.1 (2026-04)
6.6.4.1 Validation of the containerized VNF Package during onboarding and instantiation . 21
6.6.4.1.1 Introduction . 21
6.6.4.1.2 Validation of the containerized VNF Package during onboarding . 21
6.6.4.1.3 Validation of the MCIOP file artifacts and OS container images during instantiation . 22
6.6.4.1.4 OS container image software integrity validation at instantiation with attestation. 22
6.6.5 Segregation and Isolation . 25
6.6.5.1 Network Segregation . 25
6.6.5.2 Workload Segregation and Isolation . 26
6.6.5.3 Confidential Computing Support . 26
6.7 Deployment Design . 26
Annex (informative): Change history . 27
History . 28

ETSI
5 ETSI GS NFV-SEC 023 V5.4.1 (2026-04)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The declarations
pertaining to these essential IPRs, if any, are 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 IPR online database.
Pursuant to the ETSI Directives including the ETSI IPR Policy, no investigation regarding the essentiality of IPRs,
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.
Trademarks
The present document may include trademarks and/or tradenames which are asserted and/or registered by their owners.
ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no
right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does
not constitute an endorsement by ETSI of products, services or organizations associated with those trademarks.
DECT™, PLUGTESTS™, UMTS™ and the ETSI logo are trademarks of ETSI registered for the benefit of its
Members. 3GPP™, LTE™ and 5G™ logo are trademarks of ETSI registered for the benefit of its Members and of the
3GPP Organizational Partners. oneM2M™ logo is a trademark of ETSI registered for the benefit of its Members and of ®
the oneM2M Partners. GSM and the GSM logo are trademarks registered and owned by the GSM Association.
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
6 ETSI GS NFV-SEC 023 V5.4.1 (2026-04)
1 Scope
The present document specifies the security and hardening requirements for running NFV software (e.g. VNFs) in
containerized environments. The present document provides a threat analysis for a container-based NFV deployment
and a state of the art on container security. The present document proposes a set of requirements and solutions for attack
surface reduction and privilege limitation and analyses existing solutions for resource limitations (cgroups); Hardware
protections (HMEE); Container hardening (including patching); Containers in VMs and containers on bare metal.
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 in the
ETSI docbox.
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 GS NFV-IFA 040: "Network Functions Virtualisation (NFV) Release 5; Management and
Orchestration; Requirements for service interfaces and object model for OS container management
and orchestration specification".
[2] ETSI GS NFV-SEC 021: "Network Functions Virtualisation (NFV) Release 4; Security; VNF
Package Security Specification".
[3] ETSI GS NFV-SOL 004: "Network Functions Virtualisation (NFV) Release 5; Protocols and Data
Models; VNF Package and PNFD Archive specification".
[4] ETSI GS NFV-IFA 011: "Network Functions Virtualisation (NFV) Release 5; Management and
Orchestration; VNF Descriptor and Packaging Specification".
[5] ETSI GS NFV-SEC 012: "Network Functions Virtualisation (NFV) Release 5; Security; System
architecture specification for execution of sensitive NFV components".
[6] Common Vulnerability Scoring System v4.0: Specification Document.
[7] ETSI GS NFV-SEC 026: "Network Functions Virtualisation (NFV) Release 5; Security; Isolation
and trust domain specification".
[8] ETSI GS NFV-SOL 013: "Network Functions Virtualisation (NFV) Release 5; Protocols and Data
Models; Specification of common aspects for RESTful NFV MANO APIs".
[9] ETSI GS NFV-SEC 022: "Network Functions Virtualisation (NFV) Release 4; Security; Access
Token Specification for API Access".
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.
ETSI
7 ETSI GS NFV-SEC 023 V5.4.1 (2026-04)
The following referenced documents may be useful in implementing an ETSI deliverable or add to the reader's
understanding, but are not required for conformance to the present document.
[i.1] ETSI GR NFV 003: "Network Functions Virtualisation (NFV); Terminology for Main Concepts in
NFV".
[i.2] ETSI GR NFV-IFA 029: "Network Functions Virtualisation (NFV) Release 3; Architecture;
Report on the Enhancements of the NFV architecture towards "Cloud-native" and "PaaS"".
[i.3] OCI™ Image Format Specification v1.0.1.
[i.4] ETSI GS NFV-SOL 018: "Network Functions Virtualisation (NFV) Release 5; Protocols and Data
Models; Profiling specification of protocol and data model solutions for OS Container
management and orchestration".
[i.5] ETSI GS NFV-IFA 036: "Network Functions Virtualisation (NFV) Release 5; Management and
Orchestration; Requirements for service interfaces and object model for container cluster
management and orchestration specification". ®
[i.6] MITRE ATT&CK : "Containers Matrix". ®
[i.7] Microsoft : "Threat Matrix for Kubernetes".
[i.8] ETSI GS NFV-SEC 014: "Network Functions Virtualisation (NFV) Release 3; NFV Security;
Security Specification for MANO Components and Reference points".
[i.9] ETSI GS NFV-SEC 006: "Network Functions Virtualisation (NFV); Security Guide; Report on
Security Aspects and Regulatory Concerns".
[i.10] NIST Special Publication 800-190: "Application Container Security Guide".
3 Definition of terms, symbols and abbreviations
3.1 Terms
For the purposes of the present document, the terms given in ETSI GR NFV 003 [i.1] apply.
3.2 Symbols
For the purposes of the present document, the symbols given in ETSI GR NFV 003 [i.1] apply.
3.3 Abbreviations
For the purposes of the present document, the abbreviations given in ETSI GR NFV 003 [i.1] and the following apply:
ASLR Address Space Layout Randomization
AVS Attestation Verifier Service
BPF Berkeley Packet Filter
CI/CD Continuous Integration / Continuous Delivery or Deployment
DAC Discretionary Access Control
DMZ Demilitarized Zone
DoS Denial of Service
DRTM Dynamic Root of Trust Measurement
eBPF Extended Berkley Packet Filter
eDRTM External Dynamic Root of Trust Measurement
HMEE Hardware Mediated Execution Enclave
iDRTM Internetal Dynamic Root of Trust Measurement
MAC Mandatory Access Control
MCS Multi-Category Security
ETSI
8 ETSI GS NFV-SEC 023 V5.4.1 (2026-04)
MFA Multi-factor Authentication
OTP One Time PIN or Passcode
RAVS Remote Attestation Verifier Service
RTR Root of Trust for Reporting
RTS Root of Trust for Storage
SDLC Software Development Life Cycle
SLO Service Level Objective
4 NFV container deployments
4.1 Introduction
A VNF or VNFC designed to be deployed and managed on Container Infrastructure Service instances (CIS) is
represented by a containerized workload running on OS containers. The management and orchestration of OS
containers require the services of the following two functions:
• Container Infrastructure Service Management (CISM) ; and
• Container Image Registry (CIR).
Requirements on the list of services to be offered by architectural elements providing the CISM and CIR functions and
requirements on the interfaces to expose these services to various consumers are specified in ETSI
GS NFV-IFA 040 [1].
The study ETSI GR NFV-IFA 029 [i.2] identified several possible container deployment scenarios. These include:
Nested Container Infrastructure Services in VMs, Container Infrastructure Services on bare-metal, or NFVI providing
Container Infrastructure Services on bare-metal and in VMs. Additionally, different mapping options of the CISM
function to NFV-MANO are presented. The characteristics, particularly those important for security aspects, of these
deployment configurations are described in the following sub-clauses.
4.2 Assumptions
4.2.1 Introduction
The assumptions in the present clause are general and applicable to any deployment option or scenario in the
subsequent clauses. They relate to:
a) modelling the containerized workloads; and
b) general assumptions on the CIS infrastructure.
4.2.2 Assumptions on modelling the containerized workloads
Existing de-facto standard container infrastructure management systems consider managing containerized workloads at
a granularity which is higher than on a single container level. A set of OS containers that are tightly coupled to run in
the same execution environment (i.e. on the same CIS instance) and designed to be scheduled together, is defined as the
smallest manageable workload object. A VNFC instance is assumed to be 1:1 mapped to such the smallest manageable
unit of a containerized workload.
The CISM manages and exposes Managed Container Infrastructure Objects (MCIOs). An MCIO whose declarative
descriptor specifies compute/storage infrastructure resource requests represents such smallest manageable unit and is
assumed to be 1:1 mapped to a VNFC.
The MCIOs are assumed to be specified agnostic to the possible container infrastructure deployment scenario.
ETSI
9 ETSI GS NFV-SEC 023 V5.4.1 (2026-04)
As described in ETSI GS NFV-IFA 040 [1], clause 5.2.5, the OS container image is an abstract NFV object for OS
container management and orchestration, representing a software image for an OS container. OS container images are
referenced in the declarative descriptors of MCIOs. The MCIOs, which are built from OS container images, are created
by deploying their OS containers from their respective images. The OS container images are typically pulled by the CIS
instances from the CIR based on the image names and CIR URLs. Dependent on the delivery method of the VNF
software, the VNF Package may include the OS container images as artifacts (e.g. as archive files). OS container
images are referenced in the declarative descriptors of the MCIOs.
An OS container image is assumed to consist of several components, one of them supporting the image content
description and addressability of other image components. Existing de-facto standard image formats refer to such
component as image manifest, which typically enables image content-addressability. An image manifest may point to
other components necessary for the OS container runtime filesystem to be built. Existing de-facto standard image
formats refer to such components as image layers. One or several layers may be required to create a complete OS
container filesystem. The necessary ordered set of layers is also expected to be described in the image manifest. The
image layers themselves can add, modify or remove files when applied on top of another image layer.
NOTE: The OCI™ Image Format Specification v1.0.1 [i.3] is identified to map to the OS container image of the
NFV object model, as described in ETSI GS NFV-SOL 018 [i.4], clause 5.5. The OCI™ image consists
of several components: manifest, image index, filesystem layers, configuration.
4.2.3 General assumptions on the CIS infrastructure
A CISM instance manages multiple containerized workloads in a cluster of CIS instances. The cluster operator is
assumed to follow the general principle of least privilege for namespace definition and namespace quota assignment,
and for access policy definition.
NOTE: In a multi-namespace environment, particular CISM internal services may be exposed to all namespaces.
4.3 Deployment Options
4.3.1 Container Platform
4.3.1.1 Introduction
ETSI GR NFV-IFA 029 [i.2] clauses 5.3.2 to 5.3.6 detail a number of deployment use cases for VNFs or VNF
components that utilize container-based virtualisation depending on the capabilities of the NFVI. Clause 4.3 lists
security considerations for the various deployment options.
NOTE: The option for Container-based NFV Micro-Services within the VNF is not considered as, in this option,
the VNFC uses its own internal container technology to execute the VNF components, all running within
VMs. This is equivalent to the traditional VM based operation, as neither NFV-MANO nor NFVI provide
any container infrastructure services.
4.3.1.2 Container Infrastructure Services on bare metal
In this deployment option, the VNF runs entirely within OS level containers, which are provided by the CIS as depicted
in ETSI GR NFV-IFA 029 [i.2], clause 5.3.3. Whether each single VNF component runs in its own container is
dependent on the VNF and on how the managed container infrastructure object models are configured. The key aspects
are that the NFVI provides the virtualisation layer that holds the container runtime environment as well as the OS for
each container running directly on all NFVI hosts. The NFVI also provides the network for communications among
VNFCs between NFVI hosts.
The LCM for VNFCs is performed by NFV-MANO using the usual templates such as VNFDs and VDUs. NFV-MANO
however, consumes interfaces from the CISM with the latter doing all the necessary virtual resource allocation and
management for the container infrastructure.
Due to VNFs running purely in OS containers without the use of VMs, this option is open to the general threats for
containerized workloads that are described in clause 5.3. This includes vulnerabilities to the container runtime, such as
privilege escalation, escape attacks, information loss through side channel attacks, and remote code execution.
ETSI
10 ETSI GS NFV-SEC 023 V5.4.1 (2026-04)
Furthermore, as NFV-MANO entities make use of CISM northbound interfaces, the system is subject to CISM specific
software and API vulnerabilities.
4.3.1.3 Container Infrastructure Services Nested within VMs
In this deployment option, the VNF runs within OS level containers, which in turn are executed within VMs as depicted
in ETSI GR NFV-IFA 029 [i.2] clauses 5.3.4 and 5.3.5. Whether each VNF component runs in a single container or
requires multiple containers is dependent on the VNF and on how the managed container infrastructure object models
are configured. The key aspects are that the NFVI provides the virtualisation layer with hypervisors supporting
container infrastructure services running within VMs, as well as the OS for each VM on all NFVI hosts. The NFVI also
provides the networks for communications among VNFCs within and between VMs across NFVI hosts.
The LCM for VNFCs is performed by NFV-MANO using the usual templates such as VNFDs and VDUs. The VIM
manages all the necessary virtual resource allocation for VMs when the container infrastructure is set up. NFV-MANO
consumes interfaces from the CISM for managing containers which are also responsible for managing container-related
resources.
Due to VNFs running in OS containers nested within VMs, in terms of security, this option gains the isolation that VMs
provide, and the ability to follow affinity and anti-affinity rules for VNFC placement in VMs and NFVI nodes in
addition to container-level security mechanisms. While this option is also open to the general threats for containerized
workloads that are described in clause 5.3, the scope and surface area of these threats are reduced to the set of
containers contained in each VM. As NFV-MANO entities make use of CISM northbound interfaces, this option is
subject to CISM-specific software and API vulnerabilities.
4.3.1.4 Container Infrastructure Services both on bare-metal and in VMs
In this deployment option, the VNF runs within OS level containers, some of which are executed within VMs and some
of which are run directly on hosts, as depicted in ETSI GR NFV-IFA029 [i.2], clauses 5.3.6. Whether each VNF
component runs in a container bare-metal, or in a container within a VM is dependent on the VNF and on how the
managed container infrastructure object models are configured. The key aspects are that the NFVI provides the
virtualisation layer with hypervisors supporting container infrastructure services running within VMs, support for
containers running directly on bare-metal, and the OS for each container or VM on all NFVI hosts. The NFVI also
provides the virtual network for communications among VNFCs within and between VMs and containers across NFVI
hosts.
The LCM for VNFCs is performed by NFV-MANO using the usual templates such as VNFDs and VDUs. The VIM
manages all the necessary virtual resource allocation for VMs when the container infrastructure is set up. NFV-MANO
consumes interfaces from the CISM for managing containers, which is also responsible for managing container-related
resources.
This option, being a combination of containers over bare-metal and containers within VMs, inherits the security aspects
of both. Containers running on bare-metal are open to the general threats for containerized workloads that are described
in clause 5.3. And containers running within VMs gain the isolation that VMs provide, and the ability to follow affinity
and anti-affinity rules for VNFC placement in VMs and NFVI nodes in addition to container level security mechanisms.
And finally, as NFV-MANO entities make use of CISM northbound interfaces, this option is subject to CISM specific
software and API vulnerabilities.
4.3.2 Orchestration and Management
4.3.2.1 Introduction
ETSI GR NFV-IFA 029 [i.2], clause 7.2.4 presents several options for mapping the CISM functionality to
NFV-MANO. Two of the options (clauses 7.2.4.3 option #2 and clause 7.2.4.5 option #4) are excluded from the target
architecture. Of the remaining options, two (clauses 7.2.4.6 option #5 and 7.2.4.7 option #6) are essentially the same,
but with and without support for shared container services. This clause lists security considerations for the various
deployment options.
4.3.2.2 CISM embedded in the VIM or as a stand-alone functional block
As detailed in ETSI GR NFV-IFA 029 [i.2], clauses 7.2.4.2 and 7.2.4.4, the CISM functionality could be embedded
within the VIM or as a new NFV-MANO functional block.
ETSI
11 ETSI GS NFV-SEC 023 V5.4.1 (2026-04)
In this deployment the containerized workloads (VNF or VNFC) are separated from the management functions not only
logically but most commonly physically (NFV-MANO components running on separate compute nodes to workloads).
This isolates management functionality in case of a containerized workload being attacked and the attacker being able
to escape the container runtime. An attacker would be able to attack other containerized workloads on the CIS cluster
node or attacking the CISM via the APIs exposed between the management function (CISM) and CIS cluster.
Within ETSI GS NFV-IFA 036 [i.5], clause 4.2.1, it states that CIS cluster nodes can be used as control nodes and
therefore host the CISM management functionality. In this deployment option, the physical separation between the
management functionality / CISM and the containerized workloads is removed. If the CIS cluster node itself is hosting
both containerized workloads and the CISM, namespace separation may be the only mechanism protecting the CISM
from a compromised containerized workload and complete cluster takeover.
4.3.2.3 CISM embedded into VNF
ETSI GR NFV-IFA 029 [i.2], clauses 7.2.4.6 and 7.2.4.7 detail the option of CISM being embedded into the VNF itself.
The VNF may provide shared container services to one or more consumer, container-based, VNF instances (ETSI
GR NFV-IFA 029 [i.2], clause 7.2.4.6).
In this deployment a compromised containerized workload may not only be able to attack other containerized
workloads of the same VNF but also of other VNFs or the CISM depending on how the CIS cluster is physically and
logically constructed. Where a CIS cluster node, either VM or bare-metal, hosts container workloads from different
VNFs/VNFCs namespace separation may be the only mechanism protecting one containerized VNF/VNFC from
another. As with clause 4.3.2.2 above, if the CIS cluster node hosts both a containerized workload and the CISM
namespace separation may be the only mechanism protecting the CISM and complete cluster takeover.
5 Security Threats
5.1 Introduction
Clause 5 contains a structured method (based on ETSI GS NFV-SEC 006 [i.9]) to derive security requirements based on
the assets that need to be protected, actors that may have an interest in attacking them, the attacks themselves, and the ®
resulting requirements and mitigations that result. Both MITRE ATT&CK in their Container Threat Matrix [i.6] and
® ®
Microsoft in their Kubernetes Threat Matrix [i.7] have conducted detailed analysis of threats against containerized ®
functions and MANO functional blocks. The analysis below takes the work done by MITRE ATT&CK and ®
Microsoft into account.
5.2 Risk Analysis and Requirements
As depicted in Figure 5.2-1 (blue highlights), the security threats and requirements presented in this clause focus on OS
Container management functional blocks (CISM, CIR, CCM), the CIS cluster infrastructure, the associated
NFV-MANO reference points and any known means of implementing or mapping reference points to corresponding
interfaces. Security threats (T) and their associated security requirements (R) are identified. For all threat scenarios, the
assumption is that the attackers are attached to the network and have access to the NFV-MANO functional blocks,
reference points and MCIO exposed interfaces and services. The present document does not include threat analysis and
requirements for other NFV-MANO functional blocks and reference points; more details can be found in ETSI
GS NFV-SEC 014 [i.8].
ETSI
12 ETSI GS NFV-SEC 023 V5.4.1 (2026-04)

Figure 5.2-1: NFV-MANO Scope (blue highlights)
Although the code itself of software applications is an asset that needs to be protected, the reason this code is attached is
to get to data manipulated by the code, which has inherent value that can be of benefit to the attacker outside the
system. The threat analysis in Table 5.2-1 is based on the format found in Annex A of ETSI GS NFV-SEC 006 [i.9].
Table 5.2-1: Risk analysis and assessment
A Security Environment
a.1 Assumptions
a.1.1 Internal attackers have access to the network
NFV-MANO functional blocks and reference points support NFV
a.1.2
management entities
a.1.3 Internal attackers have access to the CCM
a.1.4 Internal attackers have access to the CISM
a.1.5 CISM supports NFV OS container package operations
a.1.6 CCM supports CIS management operations
NFVO supports Network service instances and VNF instances
a.1.7
operations
a.1.8 NFV-MANO manages many OS Container MCIOs
a.1.9 An NFVI is managed by only one NFV-MANO
The CISM and CIS cluster may be virtualised entities created by CCM
a.1.10
on demand
a.2 Assets
a.2.1 OS Container management functional blocks and reference points
The credentials of authorized systems with legitimate access to the OS
a.2.2
Container management functional blocks and reference points
The credentials of authorized administrators with legitimate access to
a.2.3
the CCM
The credentials of authorized administrators with legitimate access to
a.2.4
the CISM
The credentials of authorized administrators with legitimate access to
a.2.5
the CIR
The credentials of authorized administrators with legitimate access to
a.2.6
the CIS cluster
a.2.7 The OS Container MCIO and exposed interfaces/services
a.2.8 OS Container image
ETSI
13 ETSI GS NFV-SEC 023 V5.4.1 (2026-04)
a.3 Threat agent
Malicious users or administrators with access the NFV-MANO OS
a.3.1
Container functional blocks and reference points
Malicious users with access to the containerized workload exposed
a.3.2
interfaces/services
a.3.3 Compromised containerized workload
Malicious server with access to the NFV-MANO OS Container
a.3.4
functional blocks and reference points

a.4 Threats
a.4.1 Exploit Externally-Facing containerized workload See clause 5.3.3
a.4.2 Exploit Externally-Facing Interfaces/Services See clause 5.3.5
a.4.3 Exploit Valid Accounts See clause 5.3.5
a.4.4 Compromised OS Container Image See clause 5.3.1
a.4.5 Instantiation of unauthorized containerized workload See clause 5.3.5
a.4.6 Exploit OS Container management Interfaces See clause 5.3.5
a.4.7 Compromise of administrators See clause 5.3.5
a.4.8 Credential Manipulation See clause 5.3.5
a.4.9 Containerized Workload Escape See clause 5.3.4
Masquerade of NFVO to OS Container management function blocks
a.4.10 See clause 5.3.5
(CCM, CISM, CIR)
Masquerade of VNFM to OS Container management function blocks
a.4.11 See clause 5.3.5
(CISM, CIR)
a.4.12 Masquerade of CCM to CISM See clause 5.3.5
a.4.13 Masquerade of CCM to CIS cluster See clause 5.3.5
a.4.14 Masquerade of CISM to CIR See clause 5.3.5
a.4.15 Masquerade of CISM to CIS cluster See clause 5.3.5
a.4.16 Masquerade of CIS cluster to CIR See clause 5.3.2

B Security Objectives
b.1 Security objectives for the asset
Ensure that there is a secure software development lifecycle for the
b.1.1 c.1.1.1
containerized VNF
c.1.1.2
c.1.1.3
Ensure that the CIS infrastructure, CISM and CIS platforms have
c.1.1.4
b.1.2 hardened secure configuration in accordance with industry best
c.1.1.5
practice
c.1.1.6
c.1.1.7
Ensure that hardware security capabilities are utilized to protect
b.1.3 c.1.1.8
sensitive VNFs
b.1.4 Ensure that the storage used by containerized VNFs is secure c.1.1.9
b.1.5 Ensure that the transmission of sensitive containerized VNFs is secure c.1.1.10
c.1.1.11
c.1.1.12
Ensure that OS container management and orchestration is operated
b.1.6 c.1.1.13
in a secure manner
c.1.1.14
c.1.1.15
c.1.1.16
b.1.7 Ensure that workloads are segregated appropriately
c.1.1.17
Ensure the threats and risks to the CIS management and orchestration
b.1.8 c.1.1.18
function are taken into account during the deployment design

ETSI
14 ETSI GS NFV-SEC 023 V5.4.1 (2026-04)
C Security Requirements
c.1 Asset security requirements
c.1.1 Asset security functional requirements
c.1.1.1 Secure the software development lifecycle See clause 6.2
c.1.1.2 Security harden the CIS cluster host operating system See clause 6.3.1
c.1.1.3 Configure namespace separation See clause 6.3.2 ®
Isolate and control access to resources using Linux (see note) control
c.1.1.4 See clause 6.3.3
groups ®
Restrict or drop unneeded Linux capabilities from OS container
c.1.1.5 See clause 6.3.4
workloads
Define and restrict which system call which an OS container workloads
c.1.1.6 See clause 6.3.5
can access during runtime
c.1.1.7 Enable Mandatory Access Controls See clause 6.3.6
For sensitive containerized VNFs instantiate the OS container within an
c.1.1.8 See clause 6.6.5.3
HMEE
c.1.1.9 Secure the storage for sensitive OS container images See clause 6.4
c.1.1.10 Secure the transmission of sensitive OS container images See clause 6.5
c.1.1.11 Account management See clause 6.6.1
c.1.1.12 Account authentication See clause 6.6.2
c.1.1.13 Secure the Container Image Repository See clause 6.6.3
Validate the containerized VNF packages during onboarding and
c.1.1.14 See clause 6.6.4.1
instantiation
c.1.1.15 Segregate OS container workload network connectivity See clause 6.6.5.1
c.1.1.16 Segregate OS container workloads of differing sensitivity levels See clause 6.6.5.2
See clause 6.3.5
c.1.1.17 Protect the CISM from potential OS container escape See clause 6.3.6
See clause 6.4
c.1.1.8 Deployment design See clause 6.7 ®
NOTE: Linux is the registered trademark of Linus Torvalds in the U.S. and other countries.

5.3 Threat Descriptions
5.3.1 Compromised Container OS Image
The primary source of vulnerabilities in containerized environments is in application and container images themselves.
A common risk with containers is the usage of an image that contains vulnerabilities for generating a new container. A
malicious container OS image can compromise the CIS cluster. Gaining access to the CIR can allow an attacker to
install their own compromised images in the registry.
Container image configuration flaws: a common vulnerability in images is to create standard users with unnecessary
high privileges. This kind of common configuration weakness increases the attack surface of the entire system.
Keys encoded in images: every administrator or user that has access to the image may gain an unauthorized access to all
the information that is encoded in the image. Encoding sensitive information like passwords, private keys like SSH
private keys or X.509 private keys exposes the whole system to internal and external attacks.
Use of third-party images: portability of containers encourages developers to build new container images from existing
ones making the usage of
...