ETSI GS NFV-SEC 026 V5.1.1 (2025-07)

Network Functions Virtualisation (NFV) Release 5; Security; Isolation and trust domain specification

DGS/NFV-SEC026

General Information

• Status: Not Published
• Technical Committee: NFV SEC - Security
• Current Stage: 12 - Completion
• Due Date: 04-Aug-2025
• Completion Date: 29-Jul-2025

Standards Content (Sample)

GROUP SPECIFICATION
Network Functions Virtualisation (NFV) Release 5;
Security;
Isolation and trust domain 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 026 V5.1.1 (2025-07)

Reference
DGS/NFV-SEC026
Keywords
access control, cybersecurity, NFV, NFVI,
security, trust
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 2025.
All rights reserved.
ETSI
3 ETSI GS NFV-SEC 026 V5.1.1 (2025-07)
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 Analysis of threat models in a multi-tenant NFV infrastructure . 8
4.1 Introduction . 8
4.2 Threat analysis . 9
4.2.1 Use Case #0: Provide Isolation of two VNFs of a single NS . 9
4.2.1.1 Description . 9
4.2.1.2 Threat analysis . 10
4.2.2 Use Case #1: Two users with own NFVO on shared NFVI . 10
4.2.2.1 Description . 10
4.2.2.2 Threat analysis . 11
4.2.3 Use Case #2: Two users share the same NFV environment . 11
4.2.3.1 Description . 11
4.2.3.2 Threat analysis . 11
4.2.4 Use Case #3: Network slicing by a single user . 12
4.2.4.1 Description . 12
4.2.4.2 Threat analysis . 12
4.2.5 Use Case #4: Nested network services . 13
4.2.5.1 Description . 13
4.2.5.2 Threat analysis . 13
4.2.6 Use Case #6: Two users with own MANO stack managed by provider MANO . 14
4.2.6.1 Description . 14
4.2.6.2 Threat analysis . 15
4.2.7 Use Case #7: Provide Isolation on different levels . 15
4.2.7.1 Description . 15
4.2.7.2 Threat analysis . 16
4.2.8 Use Case #8: Isolation of containerized VNF instances . 17
4.2.8.1 Description . 17
4.2.9 Use Case #9: Multiple NMTs use the same entity . 17
4.2.9.1 Description . 17
4.2.9.2 Threat analysis . 18
4.3 Requirements . 19
5 Trust domain separation at resource level . 22
5.1 Introduction . 22
5.2 Resource separation . 23
5.3 Data protection . 23
5.3.1 Introduction. 23
5.3.2 Protection of data in transit . 24
5.3.3 Protection of data at rest using transparent encryption . 25
5.3.4 Protection of data in use . 28
5.3.5 Protection of Software images . 31
6 Hypervisor partitioning . 36
6.1 Introduction . 36
6.2 Solution description . 36
ETSI
4 ETSI GS NFV-SEC 026 V5.1.1 (2025-07)
6.2.0 Introduction. 36
6.2.1 Spatial partitioning . 36
6.2.1.0 Introduction . 36
6.2.1.1 Memory Partitioning . 36
6.2.1.2 Memory partition encryption . 36
6.2.1.3 Cache Partitioning . 37
6.2.1.4 I/O Partitioning . 37
6.2.1.5 CPU Partitioning . 37
6.2.1.6 Hardware resources Partitioning . 37
6.2.1.7 Key vault Partitioning . 37
6.2.1.8 Static Memory allocation . 37
6.2.1.9 Interrupt Partitioning . 38
6.2.2 Temporal partitioning . 38
6.2.2.0 Introduction . 38
6.2.2.1 Fixed Cyclic Scheduling . 38
6.2.2.2 CPU registers reuse . 38
6.2.2.3 Memory Bandwidth Reservation . 38
6.2.2.4 Priority-based Scheduling . 38
6.2.2.5 Worst-case execution time . 38
6.2.2.6 Interrupt Management . 38
6.2.2.7 Resource Reservation . 38
6.2.3 Fault partitioning . 38
6.2.3.0 Introduction . 38
6.2.3.1 Resource Isolation . 39
6.2.3.2 Memory Protection. 39
6.2.3.3 Error Detection and Handling . 39
6.2.3.4 Fault Containment . 39
6.2.3.5 Redundancy and Checkpointing . 39
7 Containerized VNF escape protection . 39
7.1 Introduction . 39
7.2 Solutions description . 39
8 Key Management and access control . 41
8.1 Introduction . 41
8.2 Strong cryptographic algorithms . 41
8.3 Secure key storage . 41
8.4 Separation encrypted data and encryption keys. 42
8.5 Regular key rotation . 42
8.6 Access controls and auditing . 42
8.7 Disaster recovery and high availability . 42
8.8 Key management approaches . 43
8.8.1 Introduction. 43
8.8.2 Bring Your Own Key (BYOK) . 43
8.8.3 Hold Your Own Key (HYOK) . 43
8.8.4 Bring Your Own Encryption (BYOE) . 43
8.8.5 Key management approaches selection . 43
8.9 Centralized Key management . 44
9 Conclusion . 45
Annex A (informative): Change history . 46
History . 47

ETSI
5 ETSI GS NFV-SEC 026 V5.1.1 (2025-07)
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 026 V5.1.1 (2025-07)
1 Scope
The present document defines the requirements and solutions for the NFV System to enhance network functions and
services isolation between tenants.
For this aim, the present document includes in particular:
• Analysis of the threat models.
• Trust domain separation (multi-tenant NFVI, traffic and resource separation, tenant-dependant resource
management and access control).
• Memory protection and access control (protection against memory introspection, confidentiality of sensitive
data and credentials).
• Hypervisor trust partitioning.
• The Virtualization Container (e.g. Virtual Machine and OS container) Escape protection (e.g. protection
against VNF compromising its local host OS, taking control of the hypervisor and then gaining access to
private and sensitive data of co-resident Virtualization Containers).
• Associated key management system for all above items.
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-SOL 004: "Network Functions Virtualisation (NFV) Release 5; Protocols and Data
Models; VNF Package and PNFD Archive specification".
[2] IETF RFC 9334: "Remote ATtestation procedureS (RATS) Architecture".
[3] OASIS KMIP: "Key Management Interoperability Protocol Specification Version 2.1".
[4] ETSI GS NFV-SEC 021: "Network Functions Virtualisation (NFV); Security; VNF Package
Security Specification".
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 026 V5.1.1 (2025-07)
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.
ETSI GR NFV-EVE 018: "Network Functions Virtualisation (NFV); Evolution and Ecosystem;
[i.1]
Report on Multi-tenancy in NFV".
[i.2] ETSI GS NFV-IFA 011: "Network Functions Virtualisation (NFV) Release 5; Management and
Orchestration; VNF Descriptor and Packaging Specification".
[i.3] ETSI GS NFV-IFA 014: "Network Functions Virtualisation (NFV) Release 5; Management and
Orchestration; Network Service Templates Specification".
[i.4] ETSI GS NFV 003: "Network Functions Virtualisation (NFV); Terminology for Main Concepts in
NFV".
3 Definition of terms, symbols and abbreviations
3.1 Terms
For the purposes of the present document, the terms given in ETSI GS NFV 003 [i.4] apply.
3.2 Symbols
Void.
3.3 Abbreviations
For the purposes of the present document, the abbreviations given in ETSI GS NFV 003 [i.4] and the following apply:
ABAC Attribute Based Access Control
AI Artificial Intelligence
BYOE Bring Your Own Encryption
BYOK Bring Your Own Key
CC Common Criteria
CCA Confidential Compute Architecture
CSP Communications Service Provider
DEK Data Encryption Key
EAL4 Evaluation Assurance Level 4
ECC Elliptic Curve Cryptography
FIPS Federal Information Processing Standards
GPU Graphics Processing Unit
GSM Global System for Mobile communications
HMEE Hardware Mediated Execution Enclave
HSM Hardware Security Module
HW Hardware
HYOK Hold Your Own Key
IBAC Identity-Based Access Control
ID Identifier
KDF Key Derivation Function
KDK Key Derivation Key
KEK Key Encryption Key
KMIP Key Management Interoperability Protocol
KMS Key Management System
MANO-P MANO for the Provider
MANO-T MANO for the Tenant
MFA Multi Factor Authentication
MLA Management Level Agreement
NFVO-P NFVO for the Provider
ETSI
8 ETSI GS NFV-SEC 026 V5.1.1 (2025-07)
NFVO-T NFVO for the Tenant
NMT NFV-MANO Tenants
NS-SLA Network Service - Service Level Agreement
RAN Radio Access Network
RATS Remote ATtestation procedureS
RBAC Role Based Access Control
REQ Requirement
REQ-ID Requirement Identifier
RoT Root of Trust
SEV Secure Encrypted Virtualization
SGX Software Guard eXtensions
SNP Secure Nested Paging
SW Software
TDX Trust Domain Extension
TEE Trusted Execution Environment
TLS Transport Layer Security
vHSM virtual Hardware Security Module
VIM-P VIM for the Provider
VIM-T VIM for the Tenant
VNFM-T VNFM for the Tenant
vTPM virtual Trusted Platform Module
4 Analysis of threat models in a multi-tenant NFV
infrastructure
4.1 Introduction
A service provider may provide a network service for which some sensitive VNFs require a strict isolation with the
other VNFs. This is a first use case that this present document analyses:
• Use Case #0: Provide Isolation of two VNFs of a single NS
The multi-tenancy is another case where protection and isolation is required.
Multi-tenancy in NFV is analysed in the report ETSI GR NFV-EVE 018 [i.1]. ETSI GR NFV-EVE 018 [i.1] focuses on
use-cases where multiple users consume services from the same NFV-MANO or virtual resources from a same NFVI.
ETSI GR NFV-EVE 018 [i.1] analyses the need of protection and isolation for the multi-tenancy for several use cases.
It identifies as well the solutions or the holes in the specifications of the different reference points to ensure the
identification of such protection and isolation needs for the network services or network resources, and the solutions
provided by these specifications to implement protection and isolation.
The use cases analysed in ETSI GR NFV-EVE 018 [i.1] are:
• Use Case #1: Two users with own NFVO on shared NFVI
• Use Case #2: Two users share the same NFV environment
• Use Case #3: Network slicing by a single user
• Use Case #4: Nested network services
• Use Case #5: Tenants of a service provider
• Use Case #6: Two users with own MANO stack managed by provider MANO
• Use Case #7: Provide Isolation on different levels
• Use Case #8: Isolation of containerized VNF instances
• Use Case #9: Multiple NMTs use the same entity
ETSI
9 ETSI GS NFV-SEC 026 V5.1.1 (2025-07)
Protection and isolation could be of different types. There could be a management isolation, or resources isolation.
The resources isolation could be of different types: Resource usage, resource information, resource usage monitoring,
traffic access, resource availability.
The threat analysis of this clause will analyse in details each use cases and identifies the specific threats for each, and
the requirements to mitigate these threats.
4.2 Threat analysis
4.2.1 Use Case #0: Provide Isolation of two VNFs of a single NS
4.2.1.1 Description
Security isolation may be required for some critical VNFs within a single NS or for some components of a VNF to
make sure that the resources of these VNFs/VNFCs are not affected by the other VNFs/VNFCs.
This use case analyses the virtual resources isolation at different level in the NFVI for two VNFs/VNFCs that require a
security isolation:
a) Virtual resources of the two VNFs/VNFCs can share the same physical resource. In this case, isolation needs
to be guaranteed by the virtualization layer, i.e. the hypervisor, or by the physical hardware resources, e.g. use
of HMEE in case of compute resources, or encryption of storage resources, or traffic encryption for network
resources.
b) Virtual resources of the two VNFs/VNFCs can use different physical resource. In this case, isolation is
guaranteed by separated hardware. However, physical servers may still share some network equipment.
c) The hardware in NFVI-PoPs may be organized in multiple zones. The entities within a zone may share
physical environment, air-conditioning, power or networking (e.g. switches).
d) Virtual resources may be deployed in different NFVI-PoPs that adds additional security isolation over NFVI-
PoPs. This could be required for geo-redundancy in case of disaster recovery, security compromise of a data
centre or very high level of isolation for critical components.
The anti-affinity groups defined in ETSI NFV-IFA specifications provide a mechanism to tell the VIM necessary
isolation needs. Affinity and anti-affinity rules can be defined for the constituents of VNFs as described in ETSI
GS NFV-IFA 011 [i.2] and for the constituents of NSs and NS instances by the service provider when designing the
network services, see ETSI GS NFV-IFA 014 [i.3]. Clause 5.7.2.2 of ETSI GR NFV-EVE 018 [i.1] explains how the
affinity and anti-affinity groups can be used for virtual resource isolation.
The mechanism to tell the VIM necessary need of security isolation at the physical resource level using for example
HMEE, data and traffic encryption is not described at this stage in the ETSI NFV-IFA specifications.
ETSI
10 ETSI GS NFV-SEC 026 V5.1.1 (2025-07)
4.2.1.2 Threat analysis
Table 4.2.1.2-1: Threats for the use-case #0
Threat-Id Description of threat Assets concerned Mitigation Requirements:
REQ-ID
Use Case A malicious software in the NFV-MANO, modifies VNF package data, REQ-4; REQ-5; REQ-7;
#0.1 the affinity and anti-affinity rules for the NS Descriptors, REQ-8; REQ-16; REQ-17;
constituents of VNFs/NS in the catalogue or VNF REQ-18; REQ-22; REQ-24;
during an instantiation operation requested to the Descriptors,VNFs REQ-29
VIM, modifying the virtual resource isolation resources
needs for these VNFCs/VNFs and enabling
further attacks.
Use Case A malicious software in the NFV-MANO, modifies VNF package data, REQ-4; REQ-5; REQ-7;
#0.2 the information enabling the isolation at physical NS Descriptors, REQ-8; REQ-16; REQ-17;
resource level for the constituents of VNFs in the VNF REQ-18; REQ-22; REQ-24;
catalogue or during LCM operation requested to Descriptors,VNFs REQ-29
the VIM, modifying the physical resource resources
isolation needs for these VNFs and enabling
further attacks.
Use Case An attacker is able to exploit vulnerabilities on VNFs resources, REQ-9; REQ-10; REQ-11;
#0.3 hypervisor and mount through malicious VM or VNF application REQ-12; REQ-13; REQ-30;
vulnerable VM (which becomes compromised) a data REQ-33; REQ-34
VM escape attack.
Use Case An attacker is able to exploit vulnerabilities of the VNFs resources, REQ-9; REQ-10; REQ-11;
#0.4 container environment and mount through VNF application REQ-12; REQ-13; REQ-31;
malicious container or vulnerable container data REQ-33; REQ-34
(which becomes compromised) a container
escape attack.
Use Case An attacker is able to exploit a vulnerability of the VNFs resources, REQ-9; REQ-10; REQ-11;
#0.5 virtualized system and mount a privilege VNF application REQ-12; REQ-13; REQ-32;
escalation attack enabling to perform host data REQ-33; REQ-34
privilege operations, and gain access to
unauthorized hardware resources.
Use Case A malicious VNF overwhelms the virtual memory VNFs resources; REQ-3
#0.6 of vSwitch by sending fake requests , provoking Legal agreements
a Denial of Service in the other VNFs, and for the (SLA)
NS.
4.2.2 Use Case #1: Two users with own NFVO on shared NFVI
4.2.2.1 Description
The clause 5.1 of ETSI GR NFV-EVE 018 [i.1] gives details on this use case. A high-level description is given
hereafter for convenience.
In this use case, two users uses their own NFVO and VNFM but allocates resources on the same NFVI-PoP(s) to build
their NSs. It is assumed for this use case that a NFVI-PoP is managed by a single VIM and that the NSs of the different
users are not sharing physical resources.
For this use case, the on-boarding of NSs is done on a tenant-specific NFVO. The relevant descriptors NSD and VNFD
are then isolated from the descriptors of other tenants.
The threats on isolation starts when the NFVO or the VNFM request resources for the VNFs instantiation to the VIM.
ETSI
11 ETSI GS NFV-SEC 026 V5.1.1 (2025-07)
4.2.2.2 Threat analysis
Table 4.2.2.2-1: Threats for the use-case #1
Threat-Id Description of threat Assets Mitigation Requirements:
concerned REQ-ID
Use Case A malicious NFVO or VNFM request instantiation of a VNF application REQ-1; REQ-2
#1.1 VNF on behalf of a legitimate tenant, using the Or-Vi data, VNF
or Vnfm-Vi interface respectively. This malicious sensitive
NFVO or VNFM uses for the instantiation of the VNF parameters,
the resourceGroupId of the legitimate tenant. This VNF Lawful
VNF sharing the domain of other VNFs of the Interception
legitimate tenant may access to the resources of the data
legitimate VNFs.
Use Case A malicious NFVO or VNFM request reservation of NS SLA, VNF REQ-1; REQ-2; REQ-3
#1.2 resources (compute, storage, network) using Or-Vi or Instance virtual
Vnfm-Vi interface respectively, to jeopardize the NFVI resources
resources available. This malicious NFVO or VNFM
uses its own resourceGroupId or the resourceGroupId
of the legitimate tenant.
Use Case A malicious NFVO uses the Or-Vi software image VNF Software REQ-4; REQ-5; REQ-6
#1.3 interface on behalf of a legitimate tenant authorized to images.
access the VIM, to add, delete, update or to query
information of Software images from the VIM.
Use Case A malicious VNFM uses the Vnfm-Vi software image VNF Software REQ-5; REQ-6; REQ-7
#1.4 interface on behalf of a legitimate tenant authorized to images
access the VIM, to query information of Software
images from the VIM.
Use Case VNF instantiated in the NFVI accesses to the VNF application REQ8; REQ-9; REQ-10;
#1.5 resources reserved for another tenant and not data REQ-11
sharable.
Use Case A malicious tenant accesses in the WIM to data VNF application REQ-13
#1.6 transiting between another tenant's two VNF data
instances instantiated in two different NFVI-PoPs.
4.2.3 Use Case #2: Two users share the same NFV environment
4.2.3.1 Description
The clause 5.2 of ETSI GR NFV-EVE 018 [i.1] gives details on this use case. A high-level description is given
hereafter for convenience.
In this use case, two service providers use the same NFV environment (NFVO and other FBs) to create their own NSs
built with resources of the same NFVI-PoP(s).
For this use case, the service providers use the same NFV-MANO service to deploy their NS instances. It is assumed
for this use case that a NFVI-PoP is managed by a single VIM and that the NSs of the different users are not sharing
physical resources.
4.2.3.2 Threat analysis
The threats of the use-case #1 applies also for this use-case. The additional threats linked to the fact that the service
providers uses the same NFVO and VNFM are listed in table 4.2.2.2-1.
ETSI
12 ETSI GS NFV-SEC 026 V5.1.1 (2025-07)
Table 4.2.3.2-1: Threats for the use-case #2
Threat-Id Description of threat Assets Mitigation Requirements:
concerned REQ-ID
Use Case A legitimate tenant 1 uses the Os-ma-nfvo interface to Network REQ-14, REQ-15, REQ-16,
#2.1 read the NS information of another tenant 2 sharing topology, VNF REQ-17, REQ-18
the NFVO. The tenant 1 may get sensitive information package data
on the NS topology for a NS of a competitor (tenant
2).
Use Case A malicious tenant on-boards unused NS/VNF just to NS-SLA, NS REQ-19
#2.2 consume on-boarding resources (e.g. fill the NS and availability
VNF registries or software image repository) to limit
the space available for other tenant.
Use Case A malicious tenant uses the Os-ma-nfvo interface to NS-SLA, NS REQ-20, REQ-21, REQ-22,
#2.3 manage the NSs of another tenant. For example, this availability, REQ-23, REQ-24
malicious tenant may scale down the NS of a VNFs
competitor to get more resources for his own NS or resources
scale up to increase resource cost of another tenant.

4.2.4 Use Case #3: Network slicing by a single user
4.2.4.1 Description
The clause 5.3 of ETSI GR NFV-EVE 018 [i.1] gives details on this use case. A high-level description is given
hereafter for convenience.
In this use case, a service provider uses network slicing and creates two slice subnets by creating network service
instances on the same NFV environment (i.e. the same NFVO and other FBs ) and thus being built with resources of the
same NFVI-PoP(s). In difference to use-case #2, the same service provider manages both NS instances and expects
isolation of the slice subnets.
In this use case it is assumed that the NS instances of the different slice subnets can be deployed on different resources
within the NFVI. For sharing of NFVI resources see other use cases.
The different slice subnets may be created using different NS or using different instances of the same NS, Each slice
subnet may also contain different NS instances. In this latter case, the isolation applies for the slice subnets (i.e. the NS
instances belonging to different slice subnets) but not for the NS instances constituents of a single slice subnet.
4.2.4.2 Threat analysis
For this use case, the NFV-MANO is not multi-tenant, and manages and orchestrates network services of a single
service provider. In this case isolation shall be effective on the resources used for the different slice subnets but not on
the management of the slice subnets.
The use-case #1.5 threat of the use-case #1 applies also for this use-case except that there are not different tenant in this
case but different isolated slice subnets of a same tenant. Inside the NFVI, this could be managed in the same way using
the resource Group Id as identifier of the trust domain.
Table 4.2.4.2-1: Threats for the use-case #3
Threat-Id Description of threat Assets Mitigation Requirements:
concerned REQ-ID
Use A compromised (intentionally or simply misconfigured) VNF application REQ8; REQ-9; REQ-10;
Case VNF instantiated in one slice subnet is able to access data REQ-12
#3.1 resources of another slice subnet.

ETSI
13 ETSI GS NFV-SEC 026 V5.1.1 (2025-07)
4.2.5 Use Case #4: Nested network services
4.2.5.1 Description
The clause 5.4 of ETSI GR NFV-EVE 018 [i.1] gives details on this use case. A high-level description is given
hereafter for convenience.
In this use case, service provider 1 uses a network service NS1 with a nested network service NS3. Another service
provider 2 uses a network service NS2 with a nested network service NS4. NS3 and NS4 are managed by the same
NFVO, NFVO3. NS1 and NS2 are managed by two other NFVOs, NFVO1 and NFVO2 respectively. NS1 and NS3
may share resources. NS2 and NS4 may share resources. Isolation is needed between the even and odd numbered NSs
and their constituents and resources. NS3 and NS4, managed by the same NFVO, need isolation both for their
management access and for their resources. NS3 and NS4 may share a VNF using the same VNF package in NFVO3,
but isolation is needed for their respective VNF instances.
In this use case, NS3 is instantiated through the Or-Or reference point between NFVO1 and NFVO3. In the same way,
NS4 is instantiated through the Or-Or reference point between NFVO2 and NFVO3. The isolation of NS3 and NS4 is
similar to that of use-case #2, however the difference in this case is due to the reference point that manages the NS. In
use-case #2, the NS is managed solely through the Os-Ma-Nfvo reference point, but in this current use case, the
management of the NS is initiated bn the Os-Ma-Nfvo but processed through an Or-Or reference point.
It is assumed that for this use case the VNFs of different network services may be either instantiated in the same or
different NFVI-PoPs, but are managed by the same VIM.
The detailed flows for instantiation of the NS and their nested NS are described in clause 5.4 of ETSI
GR NFV-EVE 018 [i.1].
The VNF package on-boarded in the NFVO is signed and may be encrypted with the service provider credentials as
defined in ETSI GS NFV-SEC 021 [4] and ETSI GS NFV-SOL 004 [1]. When a Nested NS is on-boarded in an
external NFVO, the protection of the sensitive artifact is done as described in clause 5.5 of ETSI GS NFV-SOL 004 [1].
In case of asymmetric encryption, the key used to encrypt the sensitive artifact is the public key of the external NFVO.
The external NFVO uses its own private key to decrypt the encrypted artifact.
In case of symmetric encryption, the public key of the external NFVO is used to encrypt a key generated by the VNF
provider. This latter key is used to encrypt the sensitive artifact. The encrypted form of this key is included in the
package to be shared with the external NFVO. The external NFVO decrypts the shared key with its own private key and
then uses the obtained shared key to decrypt the artifact.
4.2.5.2 Threat analysis
For this use case the NFV-MANOs, including the NFVO3, are multi-tenant and shall ensure the isolation between these
tenants. The VIM is also multi-tenant and shall ensure the isolation of resources for the VNF instances of different
service providers and shall be aware of this multi-tenancy.
The threats of the use-case #2 apply also for this use-case except that the interface used is the Or-Or reference point.
The resource Group Id may be used as identifier of the trust domain for managing the isolation in NFVO3, VNFM3,
VIM, and NFVI.
ETSI
...