1 O-RAN.WG11.O-CLOUD-Security-TR.0-R003-v06.

00
2 Technical Report

4 O-RAN Work Group 11 (Security Work Group)

5

6 Study on Security for O-Cloud

1

Copyright © 2024 by the O-RAN ALLIANCE e.V.

The copying or incorporation into any other work of part or all of the material available in this specification in any form without the prior
written permission of O-RAN ALLIANCE e.V. is prohibited, save that you may print or download extracts of the material of this
specification for your personal use, or copy the material of this specification for the purpose of sending to individual third parties for their
information provided that you acknowledge O-RAN ALLIANCE as the source of the material and that you inform the third party that these
conditions apply to them and that they must comply with them.

O-RAN ALLIANCE e.V., Buschkauler Weg 27, 53347 Alfter, Germany

________________________________________________________________________________________________

© 2024 by the O-RAN ALLIANCE e.V. Your use is subject to the copyright statement on the cover page of this specification. 2
 O-RAN.WG11.O-CLOUD-Security-TR.0-R004-v06.00

1 Contents
2 List of figures......................................................................................................................................................

3 List of tables........................................................................................................................................................

4 Foreword.............................................................................................................................................................

5 Modal verbs terminology....................................................................................................................................

6 Introduction.........................................................................................................................................................

7 1 Scope.........................................................................................................................................................

8 2 References.................................................................................................................................................

9 2.1 Informative references.........................................................................................................................................

10 3 Definition of terms, symbols and abbreviations.....................................................................................

11 3.1 Terms.................................................................................................................................................................

12 3.2 Symbols.............................................................................................................................................................

13 3.3 Abbreviations.....................................................................................................................................................

14 4 O-Cloud Architecture.............................................................................................................................

15 4.1 Components.......................................................................................................................................................

16 4.1.1 SMO.............................................................................................................................................................14

17 4.1.2 O-Cloud management components..............................................................................................................14

18 4.1.3 Hardware resources......................................................................................................................................15

19 4.1.4 Operating System (OS)................................................................................................................................15

20 4.1.5 Virtualization Layer.....................................................................................................................................15

21 4.1.6 NFs Layer.....................................................................................................................................................15

22 4.1.7 O-Cloud images repository..........................................................................................................................15

23 4.2 Interfaces...........................................................................................................................................................

24 4.3 Critical services.................................................................................................................................................

25 4.3.1 SERV#01 SMO-O-Cloud O2 services.........................................................................................................18

26 4.3.2 SERV#02 O-Cloud images service..............................................................................................................19

________________________________________________________________________________________________

© 2024 by the O-RAN ALLIANCE e.V. Your use is subject to the copyright statement on the cover page of this specification. 3
 O-RAN.WG11.O-CLOUD-Security-TR.0-R003-v06.00

1 4.3.3 SERV#03 O-Cloud monitoring service.......................................................................................................19

2 4.3.4 SERV#04 O-Cloud provisioning service.....................................................................................................19

3 4.3.5 SERV#05 O-Cloud software management service......................................................................................20

4 4.3.6 SERV#06 O-Cloud fault management service............................................................................................20

5 4.3.7 SERV#07 O-Cloud performance service.....................................................................................................21

6 4.3.8 SERV#08 O-Cloud Admission Control Service..........................................................................................21

7 5 Cloud deployment scenarios...................................................................................................................

8 5.1 Main actors........................................................................................................................................................

9 5.2 Cloud service models.........................................................................................................................................

10 5.2.1 Infrastructure as a Service (IaaS).................................................................................................................22

11 5.2.2 Platform as a Service (PaaS)........................................................................................................................23

12 5.2.3 Software as a Service (SaaS).......................................................................................................................23

13 5.3 Cloud deployment types....................................................................................................................................

14 5.3.1 Private cloud................................................................................................................................................24

15 5.3.2 Community Cloud........................................................................................................................................25

16 5.3.3 Public Cloud.................................................................................................................................................27

17 5.3.4 Hybrid Cloud...............................................................................................................................................27

18 5.4 High-Level risk assessment...............................................................................................................................

19 6 Roles and responsibilities.......................................................................................................................

20 7 Security Problem Definition...................................................................................................................

21 7.1 Assets.................................................................................................................................................................

22 7.2 Threats...............................................................................................................................................................

23 7.2.1 Threat and impact types...............................................................................................................................42

24 7.2.2 Attack surface..............................................................................................................................................43

25 7.2.3 Vulnerabilities..............................................................................................................................................44

26 7.2.4 Threat events................................................................................................................................................45

27 8 Recommendations and best practices.....................................................................................................

28 8.1 REC-CM Certificate management.....................................................................................................................

________________________________________________________________________________________________

© 2024 by the O-RAN ALLIANCE e.V. Your use is subject to the copyright statement on the cover page of this specification. 4
 O-RAN.WG11.O-CLOUD-Security-TR.0-R003-v06.00

1 8.2 REC-NS Network Segmentation & Filter Network Traffic..............................................................................

2 8.3 REC-IAM Identity, Authentication and Access Management..........................................................................

3 8.4 REC-VHPM Vulnerability Handling and Patch Management..........................................................................

4 8.5 REC-SCONF Security Configuration...............................................................................................................

5 8.6 REC-SDLC Secure Development Lifecycle.....................................................................................................

6 8.7 REC-SNFLC Security App/VNF/CNF lifecycle...............................................................................................

7 8.8 REC-IMGP Image Protection............................................................................................................................

8 8.9 REC-LOG Logging, Monitoring and Alerting..................................................................................................

9 8.10 REC-SB Secure Boot.........................................................................................................................................

10 8.11 REC-ISO Strong Isolation.................................................................................................................................

11 8.12 REC-AUD Security Audit.................................................................................................................................

12 8.13 REC-SS Secure Storage.....................................................................................................................................

13 8.14 REC-PHY Physical Security Protection............................................................................................................

14 8.15 REC-RA Remote Attestation.............................................................................................................................

15 8.16 REC-SDD Secure data deletion.........................................................................................................................

16 8.17 REC-IDM O-Cloud ID secure management.....................................................................................................

17 8.18 REC-IDM Identity management for O-Cloud elements....................................................................................

18 9 Risk Assessment.....................................................................................................................................

19 Annex A (informative): Best practices from some of existing main security guidance..................................

20 A.1 CISA/NSA Kubernetes security hardening best practices.................................................................................

21 A.2 CIS Docker security best practices....................................................................................................................

22 A.3 ONAP VNFs security best practices...............................................................................................................

23 Revision History..............................................................................................................................................

24 History.............................................................................................................................................................

25

26

________________________________________________________________________________________________

© 2024 by the O-RAN ALLIANCE e.V. Your use is subject to the copyright statement on the cover page of this specification. 5
 O-RAN.WG11.O-CLOUD-Security-TR.0-R003-v06.00

1 List of figures
2 Figure 4-1 : O-CLOUD architecture..............................................................................................................................14
3 Figure 4-2 : AAL Architecture and interfaces (Source [i.52])......................................................................................18
4 Figure 4-3 : Parallel reporting & Alarm correlation [i.1]............................................................................................20
5 Figure 5-1 : IaaS cloud service model.............................................................................................................................23
6 Figure 5-2 : PaaS cloud service model............................................................................................................................23
7 Figure 5-3 : SaaS cloud service model............................................................................................................................24
8 Figure 5-4 : On-site private cloud...................................................................................................................................24
9 Figure 5-5 : Outsourced private cloud............................................................................................................................25
10 Figure 5-6 : On-site community cloud............................................................................................................................26
11 Figure 5-7 : Outsourced community cloud....................................................................................................................26
12 Figure 5-8 : Public cloud..................................................................................................................................................27
13 Figure 5-9 : Hybrid cloud................................................................................................................................................28
14 Figure 7-1 : Cartography of assets..................................................................................................................................36
15 Figure 7-2 : Attack vectors..............................................................................................................................................44
16 Figure 7-3 : Vulnerabilities within O-Cloud..................................................................................................................44
17 Figure 7-4 : Illustration of the VM/Container escape attack.......................................................................................53
18 Figure 7-5 : Illustration of the migration flooding attack.............................................................................................55
19 Figure 7-6 : Illustration of the false resource advertising attack.................................................................................55
20 Figure 7-7 : Illustration of the migration MITM attack...............................................................................................55
21 Figure 7-8 : Illustration of the Theft-of-Service/DoS Attack........................................................................................57
22 Figure 7-9 : Illustration of the VM/Container hyperjacking attack............................................................................61
23 Figure 7-10 : Illustration of a cross VM/Container side channel attack.....................................................................65
24
25
26
27
28
29

30 List of tables
31 Table 4-1 : O-Cloud interfaces........................................................................................................................................19
32 Table 5-1 : High level security risk assessment of cloud deployment models.............................................................34
33 Table 6-1 : List of Users...................................................................................................................................................36
34 Table 7-1 : List of Assets..................................................................................................................................................42
35

36

37

________________________________________________________________________________________________

© 2024 by the O-RAN ALLIANCE e.V. Your use is subject to the copyright statement on the cover page of this specification. 6
 O-RAN.WG11.O-CLOUD-Security-TR.0-R003-v06.00

1 Foreword
2 This Technical Report (TR) has been produced by the O-RAN Alliance.

3 Modal verbs terminology

4 In the present document "shall", "shall not", "should", "should not", "may", "need not", "will", "will not", "can" and
5 "cannot" are to be interpreted as described in clause 3.2 of the O-RAN Drafting Rules (Verbal forms for the expression
6 of provisions).

7 "must" and "must not" are NOT allowed in O-RAN deliverables except when used in direct citation.

8 Introduction
9 This technical report provides the threat model for the O-Cloud. The report identifies threats, security requirements and
10 recommends potential security controls to protect against identified threats.

________________________________________________________________________________________________

© 2024 by the O-RAN ALLIANCE e.V. Your use is subject to the copyright statement on the cover page of this specification. 7
 O-RAN.WG11.O-CLOUD-Security-TR.0-R003-v06.00

1 1 Scope
2 The steps of the threat modelling process are as follows:

3 1. Identify assets: Identify the valuable assets that the O-Cloud must protect.

4 2. Identify the threats: Identify the threats that could affect O-Cloud

5 3. Document the threats: Document each threat using a common threat template that defines a core set of
6 attributes to capture for each threat.

7 4. Rate the threats: Rate the threats to prioritize and address the most significant threats first. The rating process
8 weighs the probability of the threat against damage that could result should an attack occur.

9 5. Define potential mitigations to counter the identified threats and reduce their risks.

10 The structure of the document is divided into clauses and annexure(s):

11  Clause 4 describes the Cloud architecture in terms of components, interfaces, and critical services.

12  Clause 5 explores the different deployment types and models. In addition, it provides a high-level risk
13 assessment of those cloud deployment models.

14  Clause 6 highlights the main actors of the O-Cloud in terms of roles and responsibilities.

15  Clause 7 outlines the security problem definition in terms of assets, attack vectors, vulnerabilities and threats.

16  Clause 8 defines recommendations and best practices to mitigate the identified threats.

17  Clause 9 figures out the risk assessment of the identified threats in terms of impact and likelihood.

18  Annex A provides best practices from some of the main security guidance on cloud, virtualization and
19 containerization.

20 2 References

21 2.1 Informative references

22 References are either specific (identified by date of publication and/or edition number or version number) or
23 non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
24 referenced document (including any amendments) applies.

25 NOTE: While any hyperlinks included in this clause were valid at the time of publication, O-RAN cannot
26 guarantee their long-term validity.

27 The following referenced documents are not necessary for the application of the present document, but they assist the
28 user with regard to a particular subject area.

29 [i.1] O-RAN ALLIANCE TS: “O-RAN O2 Interface General Aspects and Principles”

30 [i.2] O-RAN ALLIANCE TS: “O-RAN Cloudification and Orchestration Use Cases and Requirements for O-RAN
31 Virtualized RAN”

32 [i.3] CISA/NSA - Kubernetes Hardening Guidance – August 2021

________________________________________________________________________________________________

© 2024 by the O-RAN ALLIANCE e.V. Your use is subject to the copyright statement on the cover page of this specification. 8
 O-RAN.WG11.O-CLOUD-Security-TR.0-R003-v06.00

1 https://media.defense.gov/2021/Aug/03/2002820425/-1/-1/1/CTR_KUBERNETESHARDENINGGUIDANCE.PDF

2 [i.4] MITRE ATT&CK containers matrix

3 https://attack.mitre.org/matrices/enterprise/containers/

4 [i.5] ENISA Threat Landscape for 5G Networks: Threat assessment for the fifth generation of mobile
5 telecommunications networks (5G); November 2019

6 [i.6] ETSI GS NFV-SEC 025 "work in progress." Network Functions Virtualisation (NFV) Release 4; Security;
7 Secure End-to-End VNF and NS management specification

8 [i.7] O-RAN ALLIANCE TS: “O-RAN O2dms Interface Specification”

9 [i.8] O-RAN ALLIANCE TS: “O-RAN O2ims Interface Specification”

10 [i.9] IETF RFC 3647: "Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices
11 Framework"

12 [i.10] ETSI GR NFV-SEC 005 Network Functions Virtualisation (NFV); Trust; Report on Certificate Management

13 [i.11] IETF RFC 6749: "The OAuth 2.0 Authorization Framework".

14 [i.12] ETSI GS NFV-SEC 022 Network Functions Virtualisation (NFV) Release 2; Security; Access Token
15 Specification for API Access

16 [i.13] ETSI GR NFV-SEC 018 Network Functions Virtualisation (NFV); Security; Report on NFV Remote
17 Attestation Architecture

18 [i.14] Ludovic Jacquin, Antonio Lioy, Diego R. Lopez, Adrian L. Shaw, and Tao Su “The trust problem in modern
19 network infrastructures”

20 https://security.polito.it/doc/public/trust_modern_network_2015.pdf

21 [i.15] ETSI GR NFV-SEC 007 Network Functions Virtualisation (NFV); Trust; Report on Attestation
22 Technologies and Practices for Secure Deployments

23 [i.16] 3GPP TR 33.848 “Study on security impacts of virtualisation”

24 [i.17] OWASP Container Security Verification Standard

25 https://owasp.org/www-project-container-security-verification-standard/migrated_content

26 [i.18] CIS Docker Benchmark Securing Docker

27 https://www.cisecurity.org/benchmark/docker/

28 [i.19] NIST Special Publication 800-190 Application Container Security Guide

29 [i.20] OWASP Docker Security Cheat Sheet

30 https://cheatsheetseries.owasp.org/cheatsheets/Docker_Security_Cheat_Sheet.html

31 [i.21] OWASP Kubernetes Security Cheat Sheet

32 https://cheatsheetseries.owasp.org/cheatsheets/Kubernetes_Security_Cheat_Sheet.html

33 [i.22] NIST SP 800-145: The NIST Definition of Cloud Computing

34 [i.23] NIST SP 500-322: Evaluation of Cloud Computing Services Based on NIST 800-145

________________________________________________________________________________________________

© 2024 by the O-RAN ALLIANCE e.V. Your use is subject to the copyright statement on the cover page of this specification. 9
 O-RAN.WG11.O-CLOUD-Security-TR.0-R003-v06.00

1 [i.24] ONAP VNF Development Requirements – VNF Security

2 https://docs.onap.org/projects/onap-vnfrqts-requirements/en/latest/Chapter4/Security.html

3 [i.25] GSMA NG.126 - Cloud Infrastructure Reference Model

4 https://www.gsma.com/newsroom/wp-content/uploads//NG.126-v1.0-2.pdf

5 [i.26] Aqua Top 20 Docker Security Best Practices: Ultimate Guide

6 https://blog.aquasec.com/docker-security-best-practices

7 [i.27] “Security Impacts of Virtualization on a Network Testbed”, Software Security and Reliability (SERE), 2012
8 IEEE Sixth International Conference

9 https://www.researchgate.net/publication/261059755_Security_Impacts_of_Virtualization_on_a_Network_Testbed

10 [i.28] Beniel Dennyson W, Dr. S. Prabakaran “Detecting Hyperjacking in cloud based virtual environment”

11 https://www.google.com/url?
12 sa=t&rct=j&q=&esrc=s&source=web&cd=&ved=2ahUKEwi92Zeznun0AhULHxoKHXO6AkgQFnoECAgQAQ&url=
13 https%3A%2F%2Fsiteproxy.ruqli.workers.dev%3A443%2Fhttp%2Fsersc.org%2Fjournals%2Findex.php%2FIJAST%2Farticle%2Fdownload
14 %2F15440%2F7789%2F&usg=AOvVaw3THwuT_S_WyKr6miOiJ7GS

15 [i.29] Muhammad Kazim “Security Aspects of Virtualization in Cloud Computing”

16 https://www.researchgate.net/publication/273950406_Security_Aspects_of_Virtualization_in_Cloud_Computing

17 [i.30] Anita Choudhary “ A critical survey of live virtual machine migration techniques “

18 https://journalofcloudcomputing.springeropen.com/track/pdf/10.1186/s13677-017-0092-1.pdf

19 [i.31] Svetlana Kolesnikova, Roman Kulikov, Yuriy Gatchin, Daniil Melnik “Hypervisor Security Analyses Based
20 on Ishikawa Methodology”

21 https://www.researchgate.net/publication/
22 323838205_Hypervisor_Security_Analyses_Based_on_Ishikawa_Methodology?enrichId=rgreq-
23 bf37d66002988b1ad9ef24fb09198313-
24 XXX&enrichSource=Y292ZXJQYWdlOzMyMzgzODIwNTtBUzo2MDg0MzY3NTI0ODIzMDVAMTUyMjA3NDAz
25 NDM4NQ%3D%3D&el=1_x_3&_esc=publicationCoverPdf

26 [i.32] Mehiar Dabbagh, Ammar Rayes “Internet of Things Security and Privacy”

27 https://www.researchgate.net/publication/309375790_Internet_of_Things_Security_and_Privacy?enrichId=rgreq-
28 69e8c33eb9fc28fccec64fbdad0a91d0-
29 XXX&enrichSource=Y292ZXJQYWdlOzMwOTM3NTc5MDtBUzo1NTYxNDY2NDI2OTAwNDhAMTUwOTYwN
30 zEwMDM0OA%3D%3D&el=1_x_3&_esc=publicationCoverPdf

31 [i.33] Changwei Liu, Anoop Singhal, Duminda Wijesekera “A Layered Graphical Model for Cloud Forensic
32 Mission Attack Impact Analysis”

33 https://www.researchgate.net/publication/
34 327314423_A_Layered_Graphical_Model_for_Cloud_Forensic_Mission_Attack_Impact_Analysis_14th_IFIP_WG_11
35 9_International_Conference_New_Delhi_India_January_3-5_2018_Revised_Selected_Papers?enrichId=rgreq-
36 b9ce99f09429d1a36256442e04006d0f-
37 XXX&enrichSource=Y292ZXJQYWdlOzMyNzMxNDQyMztBUzo3NTM0MDM2Mzg1ODMzMDFAMTU1NjYzNj
38 gzMzI4Nw%3D%3D&el=1_x_3&_esc=publicationCoverPdf

________________________________________________________________________________________________

© 2024 by the O-RAN ALLIANCE e.V. Your use is subject to the copyright statement on the cover page of this specification. 10
 O-RAN.WG11.O-CLOUD-Security-TR.0-R003-v06.00

1 [i.34] Docker Best practices for scanning images

2 https://docs.docker.com/develop/scan-images/

3 [i.35] Shankar Lal, Tarik Taleb, and Ashutosh Dutta “NFV: Security Threats and Best Practices”

4 http://anastacia-h2020.eu/publications/NFV_Security_Threats_and_Best_Practices.pdf

5 [i.36] NSA/CISA Mitigating Cloud Vulnerabilities

6 https://media.defense.gov/2020/Jan/22/2002237484/-1/-1/0/CSI-MITIGATING-CLOUD-
7 VULNERABILITIES_20200121.PDF

8 [i.37] Fraunhofer AISEC report: Threat analysis of container-as-a-service for network function virtualization

9 https://www.aisec.fraunhofer.de/content/dam/aisec/Dokumente/Publikationen/Studien_TechReports/englisch/
10 caas_threat_analysis_wp.pdf

11 [i.38] CSA. The treacherous 12: Cloud computing top threats in 2016. Technical report, Cloud Security Alliance,
12 2016. 12, 14, 15, 16, 17, 27

13 [i.39] ETSI GS NFV-SOL 013 Network Functions Virtualisation (NFV) Release 2; Protocols and Data Models;
14 Specification of common aspects for RESTful NFV MANO APIs

15 [i.40] CISA Cloud Security Technical Reference Architecture

16 https://www.cisa.gov/sites/default/files/publications/CISA%20Cloud%20Security%20Technical%20Reference
17 %20Architecture_Version%201.pdf

18 [i.41] Guide ANSSI - Hardware security requirements for x86 platforms

19 https://www.ssi.gouv.fr/uploads/2019/11/anssi-guide-hardware_security_requirements.pdf

20 [i.42] O-RAN ALLIANCE TS: “O-RAN Security Requirements and Controls Specifications”

21 [i.43] O-RAN ALLIANCE TS: “O-RAN Operations and Maintenance Architecture”

22 [i.44] NSA/CISA Security Guidance for 5G Cloud Infrastructures

23 https://www.cisa.gov/news/2021/10/28/nsa-and-cisa-provide-cybersecurity-guidance-5g-cloud-infrastructures

24 [i.45] O-RAN ALLIANCE TS: “O-RAN Security Protocols Specifications”

25 [i.46] ETSI GS NFV-SOL 004 Network Functions Virtualisation (NFV) Release 3; Protocols and Data Models;
26 VNF Package and PNFD Archive specification

27 [i.47] ETSI GS NFV-SEC 021 Network Functions Virtualisation (NFV) Release 2; Security; VNF Package
28 Security Specification

29 [i.48] NIST SP 800-88 ”Guidelines for Media Sanitization”

30 https://csrc.nist.gov/publications/detail/sp/800-88/rev-1/final

31 [i.49] DoD 5220.22-M wiping standard

32 [i.50] O-RAN ALLIANCE TR: “O-RAN Security Threat Modeling and Risk Assessment”

33 [i.51] O-RAN ALLIANCE TS: “O-RAN Acceleration Abstraction Layer Common API”

34 [i.52] O-RAN ALLIANCE TS: “O-RAN Acceleration Abstraction Layer General Aspects and Principles”

________________________________________________________________________________________________

© 2024 by the O-RAN ALLIANCE e.V. Your use is subject to the copyright statement on the cover page of this specification. 11
 O-RAN.WG11.O-CLOUD-Security-TR.0-R003-v06.00

1 [i.53] Solving the Bottom Turtle - a SPIFFE Way to Establish Trust in Your Infrastructure via Universal Identity

2 https://spiffe.io/pdf/Solving-the-bottom-turtle-SPIFFE-SPIRE-Book.pdf

3 [i.54] SPIRE Concepts: An overview of SPIRE’s architecture and fundamentals

4 https://spiffe.io/docs/latest/spire-about/spire-concepts/

5 [i.55] Kubernetes Documentation: PKI certificates and requirements

6 https://kubernetes.io/docs/setup/best-practices/certificates/

7 [i.56] Agent plugin: WorkloadAttestor "k8s"

8 https://github.com/spiffe/spire/blob/v1.7.0/doc/plugin_agent_workloadattestor_k8s.md

9 [i.57] SPIFFE-ID

10 https://github.com/spiffe/spiffe/blob/master/standards/SPIFFE-ID.md

11 [i.58] NIST Special Publication 800-207A

12 https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-207A.pdf

13 [i.59] CWE-524, "Use of Cache Containing Sensitive Information"

14 https://cwe.mitre.org/data/definitions/524.html

15 [i.60] CAPEC-204, “Lifting Sensitive Data Embedded in Cache”

16 https://capec.mitre.org/data/definitions/204.html

17 [i.61] Infiltrating Corporate Intranet Like NSA

18 https://i.blackhat.com/USA-19/Wednesday/us-19-Tsai-Infiltrating-Corporate-Intranet-Like-NSA.pdf

19

20 3 Definition of terms, symbols and abbreviations

21 3.1 Terms
22 For the purposes of the present document, the terms and definitions given in 3GPP TR 21.905 and the following apply:
23 A1: Interface between non-RT RIC and Near-RT RIC to enable policy-driven guidance of Near-RT RIC
24 applications/functions, and support AI/ML workflow.
25 A1 Enrichment information: Information utilized by near-RT RIC that is collected or derived at SMO/non-RT RIC
26 either from non-network data sources or from network functions themselves.

27 A1 policy: Type of declarative policies expressed using formal statements that enable the non-RT RIC function in the
28 SMO to guide the near-RT RIC function, and hence the RAN, towards better fulfilment of the RAN intent.

29 Deployment ID: Correlation Identity created by the O-Cloud for the SMO to relate to its inventory and manage.

________________________________________________________________________________________________

© 2024 by the O-RAN ALLIANCE e.V. Your use is subject to the copyright statement on the cover page of this specification. 12
 O-RAN.WG11.O-CLOUD-Security-TR.0-R003-v06.00

1 E2: Interface connecting the Near-RT RIC and one or more O-CU-CPs, one or more O-CU-UPs, and one or more O-
2 DUs.
3 E2 Node: A logical node terminating E2 interface. In this version of the specification, O-RAN nodes terminating E2
4 interface are:

5 - for NR access: O-CU-CP, O-CU-UP, O-DU or any combination;

6 - for E-UTRA access: O-eNB.

7 FCAPS: Fault, Configuration, Accounting, Performance, Security.

8 Intents: A declarative policy to steer or guide the behavior of RAN functions, allowing the RAN function to calculate
9 the optimal result to achieve stated objective.
10 Near-RT RIC: O-RAN near-real-time RAN Intelligent Controller: a logical function that enables real-time control and
11 optimization of RAN elements and resources via fine-grained data collection and actions over E2 interface.
12 NF Deployment:An O-Cloud NF Deployment is a deployment of a cloud native Network Function (all or partial),
13 resources shared within a NF Function, or resources shared across network functions. The NF Deployment configures
14 and assembles user-plane resources required for the cloud native construct used to establish the NF Deployment and
15 manage its life cycle from creation to deletion.
16 NF Deployment Descriptor: A completed data model which provides an O-Cloud the necessary information to create a
17 deployment.
18 Non-RT RIC: O-RAN non-real-time RAN Intelligent Controller: a logical function that enables non-real-time control
19 and optimization of RAN elements and resources, AI/ML workflow including model training and updates, and policy-
20 based guidance of applications/features in Near-RT RIC.
21 O-Cloud instance ID: The O-Cloud instance ID is a unique identifier assigned to components within the O-Cloud
22 platform, including VMs, pods, containers, nodes, and compute pools (i.e., a cluster in Kubernetes). This ensures
23 uniqueness across the entire O-Cloud environment, irrespective of the component type. For instance, a VM, a pod, a
24 container, a node, and a cluster will each have a distinct O-Cloud instance ID within the platform, ensuring that there is
25 no ambiguity in identification.
26 O-Cloud Node: An O-Cloud Node is exposed over O2ims as an Abstracted Resource. It is a collection of CPUs, Mem,
27 Storage, NICs, Accelerators, BIOSes, BMCs, etc., and can be thought of as a server.
28 O-CU: O-RAN Central Unit: a logical node hosting O-CU-CP and O-CU-UP
29 O-CU-CP: O-RAN Central Unit – Control Plane: a logical node hosting the RRC and the control plane part of the
30 PDCP protocol.
31 O-CU-UP: O-RAN Central Unit – User Plane: a logical node hosting the user plane part of the PDCP protocol and the
32 SDAP protocol.
33 O-DU: O-RAN Distributed Unit: a logical node hosting RLC/MAC/High-PHY layers based on a lower layer functional
34 split.
35 O-RU: O-RAN Radio Unit: a logical node hosting Low-PHY layer and RF processing based on a lower layer functional
36 split. This is similar to 3GPP’s “TRP” or “RRH” but more specific in including the Low-PHY layer (FFT/iFFT,
37 PRACH extraction).
38 O1: Interface between management entities (NMS/EMS/MANO) and O-RAN managed elements, for operation and
39 management, by which FCAPS management, Software management, File management shall be achieved.
40 RAN: Generally referred as Radio Access Network. In terms of this document, any component below Near-RT RIC per
41 O-RAN architecture, including O-CU/O-DU/O-RU.
42 Service Provider: A network provider who is planning to deploy applications into their network.

________________________________________________________________________________________________

© 2024 by the O-RAN ALLIANCE e.V. Your use is subject to the copyright statement on the cover page of this specification. 13
 O-RAN.WG11.O-CLOUD-Security-TR.0-R003-v06.00

1 Solution Provider: An application developer who delivers applications to Service Providers.

2 NOTE: For the purposes of the present document, the AAL terms and definitions given in [i.52] apply.

3 3.2 Symbols
4 void

5 3.3 Abbreviations
6 For the purposes of the present document, the abbreviations given in 3GPP TR 21.905 and the following apply:
7 AAL Acceleration Abstraction Layer
8 AALI Acceleration Abstraction Layer Interface
9 AALI-C Acceleration Abstraction Layer Interface-Common
10 AALI-C-App Acceleration Abstraction Layer Interface-Common-Application
11 AALI-C-Mgmt Acceleration Abstraction Layer Interface-Common-Management
12 AALI-P Acceleration Abstraction Layer Interface-Profile
13 AI/ML Artificial Intelligence/Machine Learning
14 CNF Cloud-native Network Function (NOTE: same as Containerized Network Function or Cloudified
15 Network Function)
16 DMS O-Cloud Deployment Management Services
17 eNB eNodeB (applies to LTE)
18 FOCOM Federated O-Cloud Orchestration & Management
19 FTP File Transfer Protocol
20 FTPS File Transfer Protocol Secure
21 gNB gNodeB (applies to NR)
22 IMS O-Cloud Infrastructure Management Services
23 IPSEC Internet Protocol Security
24 KPI Key Performance Indicator
25 KQI Key Quality Indicator
26 LBT Listen Before Talk
27 LCM Life Cycle Management
28 LLS Lower Layer Split
29 MIMO Multiple Input, Multiple Output
30 MNO Mobile Network Operator
31 NETCONF Network Configuration Protocol
32 NF Network Function
33 NFO Network Function Orchestration
34 NFV Network Function Virtualisation

________________________________________________________________________________________________

© 2024 by the O-RAN ALLIANCE e.V. Your use is subject to the copyright statement on the cover page of this specification. 14
 O-RAN.WG11.O-CLOUD-Security-TR.0-R003-v06.00

1 NFVI Network Function Virtualization Infrastructure

2 O-CU O-RAN Central Unit as defined by O-RAN ALLIANCE
3 O-CU-CP O-CU Control Plane
4 O-CU-UP O-CU User Plane
5 O-DU O-RAN Distributed Unit (uses Lower-level Split)
6 O-RU O-RAN Radio Unit
7 PDCP Packet Data Convergence Protocol
8 PNF Physical Network Function
9 PRB Physical Resource Block
10 PTP Precision Timing Protocol
11 QoE Quality of Experience
12 RAN Radio Access Network
13 RASP Runtime Application Self-Protection
14 RBAC Role-based Access Control
15 RIC O-RAN RAN Intelligent Controller
16 SDN Software Defined Network
17 SIEM Security information and event management
18 SINR Signal-to-Interference-plus-Noise Ratio
19 SMO Service Management and Orchestration
20 SSH Secure Shell
21 TLS Transport Layer Security
22 UAV Unmanned Aerial Vehicle
23 V2X Vehicle to Everything
24 VM Virtual machine
25 VNF Virtualised Network Function
26
27
28
29
30
31
32
33
34
35
36
________________________________________________________________________________________________

© 2024 by the O-RAN ALLIANCE e.V. Your use is subject to the copyright statement on the cover page of this specification. 15
 O-RAN.WG11.O-CLOUD-Security-TR.0-R003-v06.00

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

27 4 O-Cloud Architecture
28 The O-Cloud architecture is depicted in the following figure:

29

________________________________________________________________________________________________

© 2024 by the O-RAN ALLIANCE e.V. Your use is subject to the copyright statement on the cover page of this specification. 16
 O-RAN.WG11.O-CLOUD-Security-TR.0-R003-v06.00

2 Figure 4-1 : O-CLOUD architecture

4 4.1 Components
5 The following clauses describe the functional blocks identified in Figure 4-1 [i.1], [i.2]:

6 4.1.1 SMO
7 The SMO components managing and orchestrating the O-Cloud software are:

8  Federated O-Cloud Orchestration and Management (FOCOM): The FOCOM is responsible for
9 accounting and asset management of the resources in the cloud. The FOCOM is the primary consumer of
10 services provided by the IMS. The FOCOM has information about the O-Cloud resources management.
11 Specifically, the FOCOM needs to know whether the services are within the operator domain or external.

12  Network Function Orchestrator (NFO): The NFO is responsible for orchestrating the assembly of the
13 network functions as a composition of NF Deployments in the O-Cloud. It may also utilize OAM Functions in
14 order to access the O1 interface to the NF once it is deployed. Its use of the O1 is not germane to the O2 and is
15 only mentioned here for completeness. The NFO is the primary consumer of the DMS.

________________________________________________________________________________________________

© 2024 by the O-RAN ALLIANCE e.V. Your use is subject to the copyright statement on the cover page of this specification. 17
 O-RAN.WG11.O-CLOUD-Security-TR.0-R003-v06.00

1 4.1.2 O-Cloud management components

2 The O-Cloud components providing management services for consumption of SMO are:

3  Infrastructure Management Services (IMS): The IMS is responsible for management of the O-Cloud
4 resources and the software which is used to manage those resources. The IMS generally provides services for
5 consumption by the FOCOM.

6  Deployment Management Services (DMS): The DMS is responsible for management of NF Deployments
7 into the O-Cloud. It provides the ability to instantiate, monitor, and terminate NF Deployments. The DMS
8 generally provides services for consumption by the NFO.

9 4.1.3 Hardware resources

10  A Computer System is defined to be a physical or composed system capable of performing computations that
11 is Underlay-Network connected. A Computer System can run any major Operating System with or without
12 Virtualization and/or Container support functionality.

13 NOTE: A computer system in the context of a cloudified network and usage in cluster requires a network
14 connectivity. For example, a server in a data center connected to an underlay network.

15  An underlay network is a physically connected network enabling Computer Systems to communicate with
16 each other and with the gateway(s) connected to networks outside of the data center.

17  Hardware accelerator manager: It is an acceleration management function, that provides management

18 capabilities for the HW Accelerator(s) in the O-Cloud Node. Management capabilities include but not limited
19 to lifecycle management, configuration, updates/upgrades and failure handling. Hardware Accelerators include
20 ASIC, FPGA, DSP and GPU.

21 4.1.4 Operating System (OS)

22 An Operating system is a software platform that manages and abstracts the Computer System hardware and software
23 resources as well as provides common services for NFs such as scheduling and network connectivity.

24 4.1.5 Virtualization Layer

25  Hypervisor (VMs): An hypervisor is an OS that includes the ability to offer multiple Virtual Machines, each
26 acting as a well-separated Computer System.

27  Container Engine: A Container Engine is an OS that include the ability to offer multiple separated name
28 spaces, quotas, and management for Containers.

29 4.1.6 NFs Layer

30 The following are three deployment scenarios of a NF:

31 1. Bare Metal Container Cluster – A Bare Metal Container Cluster is a set of network-connected computer
32 systems with their individual operating system instances that supports containers in a cluster configuration.

33 2. VM-based Container Cluster – A VM-based Container Cluster is a set of network-connected Virtual

34 Machines with their individual guest operating system instance that supports containers in a clustered
35 configuration.

________________________________________________________________________________________________

© 2024 by the O-RAN ALLIANCE e.V. Your use is subject to the copyright statement on the cover page of this specification. 18
 O-RAN.WG11.O-CLOUD-Security-TR.0-R003-v06.00

1 3. VM Cluster – A VM Cluster is a set of network-connected Computer Systems with their individual operating
2 instance that supports virtual machines in a cluster configuration.

3 4.1.7 O-Cloud images repository

4 The repository containing the Software Images of O-RAN Network Functions.

5 4.2 Interfaces
6 O-Cloud interfaces are illustrated in the following table:

Interface Security
Interfaces Exposure Description
between protection

It is responsible for the deployment management

services of the NF Deployment. It offers the
following services APIs [i.7]:
SMO and O-
 O2dms_DeploymentInventory Services
Cloud
O2dms Deployment External  O2dms_DeploymentProvisioning Services TLS 1.2/1.3
Management
Services (DMS)  O2dms_DeploymentFault Services

 O2dms_DeploymentPerformance Services

 O2dms_DeploymentLifecycle Services

O2ims SMO and O- External It is responsible for infrastructure management TLS 1.2/1.3
Cloud services for O-Cloud Nodes. It offers the
Infrastructure following services APIs [i.8]:
Management
Services (IMS)  O2ims_InfrastuctureInventory Services:
Service for querying the O-Cloud resources
and management services.

 O2ims_InfrastructureMonitoring Services:
Service for configuring telemetry reporting of
O-Cloud infrastructure resources.

 O2ims_InfrastructureProvisioning Services:
Service for configuring the O-Cloud
infrastructure resources and management
services.

 O2ims_InfrastructureSoftwareManagement
Services: Services for software inventory and
updating the software used for O-Cloud
infrastructure resources and management
services.

 O2ims_InfrastructureLifecycleManagement
Services: Services related to O-Cloud
infrastructure lifecycle management and

________________________________________________________________________________________________

© 2024 by the O-RAN ALLIANCE e.V. Your use is subject to the copyright statement on the cover page of this specification. 19
 O-RAN.WG11.O-CLOUD-Security-TR.0-R003-v06.00

events.

SMO performs relevant configuration updates in

RAN over O1 interface for each network function.

SMO on operator request can perform recover

(reset) of an application (in case of failures) within
SMO and the a NF through the O1 interface.
O1 RAN managed External SMO is notified of configuration events, fault TLS 1.2/1.3
functions events and performance measurements from an O-
RAN NF instantiated on an O-Cloud, using the O1
interface.

SMO retrieves configuration data from NFs

through O1.

The interface is used to specify interactions

O-Cloud
between the VNFs/CNFs and O-Cloud. The
O-Cloud infrastructure HTTPS (HTTP
Internal interfaces can be used by the VNFs/CNFs to
APIs and over TLS)
register/deregister for receiving events from the
VNFs/CNFs
O-Cloud.

External
interfaces are
use case
specific
interfaces that
are not
standardized in
APIs for the management (creation, deletion, and
O-RAN.
Management operation) of the Tenant, software flavours,
Security of
(Tenant level External Operating System and workload images, Identity HTTPS
these interfaces
APIs) and Authorization, virtual resources, security, and
is outside the
the workload application.
scope of this
work item and
recommended
to be outside
the scope of the
O-RAN
Alliance.

Enable External External An operational O-Cloud needs a set of standard HTTPS

Services interfaces are services to function. Services such as NTP for
Interfaces use case time synchronization, DHCP for IP address
specific allocation, DNS for obtaining IP addresses for
interfaces that domain names, and LBaaS to distribute incoming
are not requests amongst a pool of designated resources.
standardized in
O-RAN.
Security of
these interfaces
is outside the
scope of this
________________________________________________________________________________________________

© 2024 by the O-RAN ALLIANCE e.V. Your use is subject to the copyright statement on the cover page of this specification. 20
 O-RAN.WG11.O-CLOUD-Security-TR.0-R003-v06.00

work item and

recommended
to be outside
the scope of the
O-RAN
Alliance.

1 Table 4-1 : O-Cloud interfaces

3 AAL interfaces are as follows [i.51]:

4 - AALI-C-Mgmt: between the O-Cloud IMS/DMS and the Hardware Accelerator Manager. It is consistent with
5 O2 interface.

6 - AALI-C-App: common APIs between O-RAN NFs and the hardware accelerator device for initial discovery,
7 AAL initialization, runtime operations, real time telemetry and status, etc.

8 - AALI-P: Profile specific API – fine grain control over selection and off-loading, etc. The AALI configuration
9 and management APIs are the APIs that an application (O-DU) executes to configure and manage the AAL-
10 LPU(s) that have been allocated to the application by the O-Cloud.

11 - Vendor specific interface between the hardware accelerator manager and hardware accelerator device.

12
13 The transport between a NF and an AAL implementation can be of different types (e.g., based on shared memory, PCIe
14 interconnect, over Ethernet). AALI-C-App shall support abstraction of these various transport mechanisms between a
15 NF and an AAL implementation through a set of common transport APIs, constituting a transport abstraction
16 framework.

17

18

19 Figure 4-2 : AAL Architecture and interfaces (Source [i.52])

20

________________________________________________________________________________________________

© 2024 by the O-RAN ALLIANCE e.V. Your use is subject to the copyright statement on the cover page of this specification. 21
 O-RAN.WG11.O-CLOUD-Security-TR.0-R003-v06.00

1 4.3 Critical services

2 The following main critical services are provided by the O-Cloud components [i.1], [i.2] which need to be highly
3 protected and securely maintained. They are identified in this report to assess the negative impact that the identified
4 threats may cause on them.

5 4.3.1 SERV#01 SMO-O-Cloud O2 services

6 Using the O2 interface, the SMO can perform the following operations:

7  Provide a boot image for a remote node

8  Send a cloud descriptor, (i.e., cloud deployment and configuration files) for initial cloud startup

9  Query the O-Cloud for attributes such as SW inventory

10  Send a request to O-Cloud to download software sent to it from the SMO, such as request for download of an
11 xAPP deployment.

12  Subscribe to notification of configuration events, fault events and performance measurements from the O-
13 Cloud

14  Query the O-Cloud for the DMS end points it supports

15  Query the O-Cloud for attributes such as capabilities and capacities

16  Request the O-Cloud to create a Network Function deployment using cloud resources

17  Request the O-Cloud to terminate Network Function deployment(s)

18  Request the O-Cloud to reset NF Deployment(s)

19  Request the O-Cloud to reset O-Cloud Node(s)

20  Issue a subscription to the O-Cloud to receive alarm event notifications

21  Query the O-Cloud for alarms on O-Cloud resources with query criteria which define the alarm characteristics
22 that the SMO is interested in

23  Query the O-Cloud for state and status information

24  Perform an Alarm Subscription query towards the IMS

25  Perform a NF deployment (that releases an NF instance) reset through the O2dms interface

26  Perform an O-Cloud Node (recovery of the resources within the O-Cloud) reset through the O2ims interface

27 Using the O2 interface, the O-Cloud can perform the following operations:

28  Send asynchronous events to the SMO when available capabilities or capacities are changed, including when
29 new hardware is added

30  Asynchronously notify the SMO when a software upgrade completes

31  Asynchronously notify the endpoint specified by the SMO (alarm subscriber) of alarm notifications related to
32 O-Cloud resources

33  Return alarms in response to the SMO alarm query that match the alarm query criteria

________________________________________________________________________________________________

© 2024 by the O-RAN ALLIANCE e.V. Your use is subject to the copyright statement on the cover page of this specification. 22
 O-RAN.WG11.O-CLOUD-Security-TR.0-R003-v06.00

1 4.3.2 SERV#02 O-Cloud images service

2 It provides Add/Delete/Update/Query functions of O-RAN Cloudified Network Functions images with their related
3 information (e.g. SoftwareImageId, Vendor, and Version) from O-Cloud repository.

4 4.3.3 SERV#03 O-Cloud monitoring service

5 When the O-Cloud Infrastructure or the O-RAN cloudified NFs fails, it needs to be fixed immediately, and preferably
6 automatically, to prevent end users from experiencing service disruptions. To avoid this service disruption Network
7 Operations must consider the telemetry information of O-Cloud deployments in the network. The telemetry information
8 serves as a vital resource for analysing the O-Cloud’s state and health, and for delivering on service monitoring goals.
9 The O-Cloud Monitoring Service uses telemetry data to provide monitoring of O-Cloud infrastructures. O-Cloud
10 telemetry shall minimally consist of Fault, Performance, and Configuration Data. There are different types of telemetry:

11  Managed Element Telemetry to monitor the NFs behavior through O1.

12  Deployment Telemetry to monitor the number of deployment instances an O-Cloud has at that moment and
13 how many were expected, how the on-progress deployment is going, and health checks. Additional
14 Deployment Telemetry metrics like CPU, network, and memory usage can also be collected. This will be
15 performed through the O2dms interface.

16  Infrastructure Telemetry to monitor the health of the O-Cloud Infrastructure components. Network
17 Operations are interested in discovering if all the components in the O-Cloud Infrastructure are working
18 properly and at what capacity, how many deployments are running on each node, and the resource utilization
19 of the O-Cloud Infrastructure. This will be performed through the O2ims interface.

20 The SMO shall be able to collect and correlate telemetries to aggregate problems to a root cause.

21 The O-Cloud shall be able to report telemetries and make all Configuration Data and any external changes to it
22 available to the SMO.

23 4.3.4 SERV#04 O-Cloud provisioning service

24 O-Cloud Provisioning is the allocation of O-Cloud’s resources and services to an O-RAN Cloudified Network Function.
25 This is one of the key functionalities of the O-Cloud, relating to how an O-RAN Cloudified Network Function procures
26 O-Cloud services and resources. O-Cloud Provisioning shall provide:

27  Create/Read/Update/Delete rules for Affinity, Anti-Affinity, and Quorum Diversity

28  Query of O-Cloud Capacity & Availability

29 4.3.5 SERV#05 O-Cloud software management service

30 Software management will manage the O-Cloud software. The software management should be a priority as without
31 proper management unnecessary risks may be taken. The software management ensures security, cost management and
32 software support. There are many benefits to software management, of which the main benefits are:

33  Prevents unauthorized software from being installed

34  Maintains a catalog of authorized software and its versions

35  Provides visibility into what software and version is being used

36  Provides a better view of which software products and versions are vendor supported

________________________________________________________________________________________________

© 2024 by the O-RAN ALLIANCE e.V. Your use is subject to the copyright statement on the cover page of this specification. 23
 O-RAN.WG11.O-CLOUD-Security-TR.0-R003-v06.00

1 In O-RAN from an O-Cloud perspective there are two types of software which needs to be managed on the O2
2 Interface:

3  The O-Cloud Infrastructure Software

4  The O-RAN Cloudified Network Function Software is the software implementation of O-RAN NFs which can
5 run over the O-Cloud

6 4.3.6 SERV#06 O-Cloud fault management service

7 It is related to IMS & DMS fault management. There are three types of fault notifications that originate from O-Cloud
8 and collected by SMO through O1, O2dms and O2ims.

9  Fault notifications originate from the O-cloud infrastructure when a condition occurs within IMS on an O-
10 Cloud resource. An event is issued towards the SMO for analysis. The SMO can issue a specific fault query
11 towards to IMS related to the O-Cloud resources and resource pool through O2ims.

12  DMS resource faults are associated with a workload. The SMO can issue a specific query related to xApp/NF
13 deployments (e.g. workloads) from the DMS through O2dms.

14  NFs faults are reported through O1 (application level).

15

16 Figure 4-3 : Parallel reporting & Alarm correlation [i.1]

17 It is possible that multiple resources can associate with a workload, whereby one fault might trigger a fault notification
18 on IMS, DMS and O1.

19 For example, it is conceivable that a O-DU application might report a fault on O1, and a related physical server
20 allocated to a workload of a O-DU would raise a DMS fault which might also have an infrastructure fault raised on
21 IMS.

22 For example, the SMO may receive a fault with a root cause of a network issue among the O-Cloud resources which
23 manifests itself in a deployment and application fault as well. Thus, the SMO might receive three notifications over
24 O2ims, O2dms and O1. It might correlate these faults to a common root cause.

25 NOTE: Faults issued by the O-Cloud could be stored at the O-Cloud resource for a configured amount of time.

________________________________________________________________________________________________

© 2024 by the O-RAN ALLIANCE e.V. Your use is subject to the copyright statement on the cover page of this specification. 24
 O-RAN.WG11.O-CLOUD-Security-TR.0-R003-v06.00

1 4.3.7 SERV#07 O-Cloud performance service

2 The purpose of performance service is to report operational information related to O-cloud resources. Typically,
3 performance information allows an operator or administrator of the O-cloud a sense of how well the system is
4 operating. It is distinct from faults in that it is not about failures in the system but about how well the overall system is
5 performing. Though, faults or alarms may negatively impact performance of the O-Cloud which might be observable in
6 performance measurements.

7 Performance measurements are typically captured periodically through time. They are collected and stored at regular
8 intervals by the system in order to gauge the performance of a system over a period of time. This allows for analytical
9 operations to be performed on the collected data and statistics to be built over time. This can tell an operator or system
10 analyst whether they have sufficient capacity in a network based on the demands of the network. This can be vital for
11 making business operational decisions such as scaling a network.

12 4.3.8 SERV#08 O-Cloud Admission Control Service

13
14 4.3.8.1 Definition
15
16 Admission Control Service, within the framework of O-Cloud, operates as a customizable and adaptable security layer.
17 It intercepts API requests after they are authenticated and authorized but before they are executed. This service
18 evaluates and decides on the admission of requests to perform specific actions, such as deploying a software image,
19 creating or updating Pods, managing resources, and setting up network policies.
20
21 4.3.8.2 Security policies
22
23 Some of the configurable security policies include:
24
25  Vulnerability scanning: The Admission Control Service incorporates a robust vulnerability scanning process.
26 This process is integral to identifying and assessing any known security vulnerabilities within a software
27 image. It ensures that only those images that meet the set vulnerability thresholds, indicating a minimized risk
28 of security threats, are approved for deployment. The activation of this scanning feature can be adjusted
29 according to the specific needs and security requirements of different scenarios.
30  Image signature verification: In addition to vulnerability scanning, the Admission Control Service also
31 includes the critical step of verifying the digital signature of software images. This verification process is
32 essential for confirming the authenticity and integrity of the image. It guarantees that the image originates from
33 a trusted source and remains unaltered. The enforcement of this verification can be tailored based on the
34 operational context and the level of security needed.
35  Resource quotas and limits: The Admission Control Service enforces policies on the amount of resources
36 (CPU, memory, storage) that can be consumed by pods or namespaces. This prevents any single application or
37 user from monopolising cluster resources, which can be a security concern in multi-tenant environments.
38  Pod security policies: The Admission Control Service defines a set of conditions that a pod must meet before it
39 is accepted into the system. These policies can enforce the use of non-privileged containers, restrict volume
40 types, and require the use of read-only root file systems, all of which enhance security.
41  Immutable containers: The Admission Control Service enforces policies that prevent changes to running
42 containers, ensuring that the containers remain in their original, secure state as defined at deployment.
43  API rate limiting: To prevent abuse and potential denial-of-service attacks, The Admission Control Service can
44 enforce rate limiting on API requests. This ensures that the API server remains stable and responsive, even
45 under high load or during an attack.
46
47
48 4.3.8.3 Admission Control in Kubernetes
________________________________________________________________________________________________

© 2024 by the O-RAN ALLIANCE e.V. Your use is subject to the copyright statement on the cover page of this specification. 25
 O-RAN.WG11.O-CLOUD-Security-TR.0-R003-v06.00

1
2 In Kubernetes, the Admission Control Service is an integral component that significantly enhance the cluster's security
3 and operational integrity. It can be implemented as a plugin that can either modify or reject requests to the Kubernetes
4 API, ensuring compliance with defined security and operational policies. Examples of a such Admission Control
5 Service include:
6 - Kubernetes Pod Security Admission: Admission Controller provided by Kubernetes itself. It focuses on
7 enforcing security-related best practices for Pods.
8 - 3rd party admission plugins: such as OPA. Open Policy Agent (OPA) is a popular third-party admission
9 controller. It extends the functionality of Kubernetes admission control by allowing more complex and
10 customized policy enforcement. OPA uses a declarative language called Rego to define policies that specify
11 the desired state and behaviour of the cluster resources. For example, OPA can be used to require that all
12 container images come from a trusted registry.
13
14 In the O-Cloud context, the decision hinges on achieving a delicate balance: on one hand, there's the need for simplicity
15 and seamless integration, which is a strong point of Kubernetes native controllers. On the other hand, there's a demand
16 for advanced, customizable policy management, where OPA excels. Throughout this balancing act, it is crucial to
17 maintain high standards of security and optimal performance, ensuring these implementations are effectively aligned
18 with the broader O-RAN system. Opting for a combination approach might provide the most flexibility, catering to
19 these diverse requirements. This strategy enables the adaptation to varying operational scenarios within O-RAN, each
20 with its own unique set of needs, whether they pertain to security, efficiency, scalability, or compliance.

21 5 Cloud deployment scenarios

22 5.1 Main actors

23 1. Operator

24 2. CSP (Cloud Service Provider)

25 3. Vendors

26 4. Third parties (e.g. service providers, verticals)

27 5.2 Cloud service models

28 Different levels of abstraction constitute the platform of the cloud architecture. These abstractions are grouped into the
29 different service levels, depending on what resources are offered as a service for a given abstraction level. According to
30 NIST SP 800-145 the three standard cloud service models are Platform as a Service (PaaS), Software as a Service
31 (SaaS), and Infrastructure as a Service (IaaS).

32 5.2.1 Infrastructure as a Service (IaaS)

33 The capability provided to the Operator is to provision processing, storage, networks, and other fundamental computing
34 resources where the Operators or Vendors are able to deploy and run arbitrary software, which can include Host OS
35 (Operator or Vendor), virtualization platforms (Operator or Vendor) and VNFs/CNFs (Operator). Operators and
36 Vendors do not manage or control the underlying cloud infrastructure but have control over Host OS (Operator or
37 Vendor), virtualization platforms (Operator or Vendor) and VNFs/CNFs (Operator).

________________________________________________________________________________________________

© 2024 by the O-RAN ALLIANCE e.V. Your use is subject to the copyright statement on the cover page of this specification. 26
 O-RAN.WG11.O-CLOUD-Security-TR.0-R003-v06.00

2 Figure 5-4 : IaaS cloud service model

3 5.2.2 Platform as a Service (PaaS)

4 The capability provided to the Operator is to deploy onto the cloud infrastructure VNFs/CNFs created using
5 programming languages, libraries, services, and tools supported by the cloud provider. The Operator does not manage
6 or control the underlying cloud infrastructure including network, servers, operating systems, or storage, but has control
7 over the deployed VNFs/CNFs and possibly configuration settings for the application-hosting environment. PaaS
8 provides this platform from the cloud, hence allowing operators to develop and run VNFs/CNFs without the overhead
9 cost (CAPEX) of building and maintaining separate platforms.

10

11 Figure 5-5 : PaaS cloud service model

12 5.2.3 Software as a Service (SaaS)

13 SaaS as defined by NIST is the capability provided to the Cloud Consumer to use the Cloud Provider’s applications
14 running on a cloud infrastructure. Applications are accessible through web browser or program interface. The operator
15 does not manage or control the underlying cloud infrastructure including network, servers, operating systems, storage,
16 or even Applications.

________________________________________________________________________________________________

© 2024 by the O-RAN ALLIANCE e.V. Your use is subject to the copyright statement on the cover page of this specification. 27
 O-RAN.WG11.O-CLOUD-Security-TR.0-R003-v06.00

2 Figure 5-6 : SaaS cloud service model

3 This service model introduces risk for the Operator, acting as the Cloud Consumer, due to shared resources, reduced
4 control, lack of transparency for data security, secure access configuration, limited visibility to logging at lower layers,
5 malicious insiders, regulatory drift, and lack of due diligence. It is not expected that 5G operators will deploy with the
6 SaaS service model.

7 The Cloud Provider may offer 5G private networks directly to its customers in a SaaS service model. In this service
8 model the Cloud Provider’s customer is the Cloud Consumer, which has responsibility for securing its data and access
9 to the applications.

10 5.3 Cloud deployment types

11 In NIST SP 800-145, cloud deployment models describe how the cloud is operated and who has access to the cloud
12 service resources. The four deployment models are defined in NIST SP 800-145 as follows:

13 5.3.1 Private cloud

14 A private cloud gives a single Operator the exclusive access to and usage of the cloud service and related infrastructure
15 and computational resources. It may be managed either by the Operator or by a third party Cloud Provider and may be
16 hosted on the Operator’s premises (i.e., on-site private clouds) or outsourced to a hosting company (i.e., outsourced
17 private clouds). The following figures present an on-site private cloud and an outsourced private cloud, respectively.

________________________________________________________________________________________________

© 2024 by the O-RAN ALLIANCE e.V. Your use is subject to the copyright statement on the cover page of this specification. 28
 O-RAN.WG11.O-CLOUD-Security-TR.0-R003-v06.00

2 Figure 5-7 : On-site private cloud

4 Figure 5-8 : Outsourced private cloud

5 On-site private cloud

Cloud Container Engine or

Cloud type Hardware Host OS VNFs/CNFs
model Hypervisor

SaaS On-
On-site private Operator Operator Operator Operator
Premise

IaaS Operator, CSP,

On-site private Operator, Vendors Operator
CSP Operator

PaaS Operator, CSP,

On-site private CSP, Operator Operator
CSP Operator

7 Outsourced private cloud

Cloud type Cloud Hardware Host OS Container Engine or VNFs/CNFs

________________________________________________________________________________________________

© 2024 by the O-RAN ALLIANCE e.V. Your use is subject to the copyright statement on the cover page of this specification. 29
 O-RAN.WG11.O-CLOUD-Security-TR.0-R003-v06.00

model Hypervisor

SaaS On-
Outsourced private NA NA NA NA
Premise

IaaS Operator, CSP,

Outsourced private Operator, Vendors Operator
CSP Operator

PaaS Operator, CSP,

Outsourced private CSP, Operator Operator
CSP Operator

2 5.3.2 Community Cloud

3 A community cloud serves a group of Operators that have shared concerns such as mission objectives, security, privacy
4 and compliance policy, rather than serving a single Operator (e.g., a private cloud). Similar to private clouds, a
5 community cloud may be managed by the Operators or by a third party Cloud Provider and may be implemented on the
6 Operator’s premise (i.e., on-site community cloud) or outsourced to a hosting company (i.e., outsourced community
7 cloud). Figure 5-6 depicts an on-site community cloud comprised of a number of participant Operators. An Operator
8 can access the local cloud resources, and also the resources of other Operators through the connections between the
9 associated Operators. Figure 5-7 shows an outsourced community cloud, where the server side is outsourced to a
10 hosting company. In this case, an outsourced community cloud builds its infrastructure off premise, and serves a set of
11 Operators that request and consume cloud services.

12

13 Figure 5-9 : On-site community cloud

________________________________________________________________________________________________

© 2024 by the O-RAN ALLIANCE e.V. Your use is subject to the copyright statement on the cover page of this specification. 30
 O-RAN.WG11.O-CLOUD-Security-TR.0-R003-v06.00

2 Figure 5-10 : Outsourced community cloud

3 On-site Community Cloud

Cloud Container Engine or

Cloud type Hardware Host OS VNFs/CNFs
model Hypervisor

On-site Community On-Premise

Operators Operators Operators Operators
Cloud

IaaS CSP,
On-site Community CSP, CSP, Operators,
Operators, Operators
Cloud Operators Vendors
Vendors

PaaS CSP,
On-site Community CSP, CSP, Operators,
Operators, Operators
Cloud Operators Vendors
Vendors

5 Outsourced community cloud

Cloud Container Engine or

Cloud type Hardware Host OS VNFs/CNFs
model Hypervisor

Outsourced On-Premise
NA NA NA NA
community

IaaS CSP,
Outsourced CSP, Operators,
CSP Operators, Operators
community Vendors
Vendors

PaaS CSP,
Outsourced CSP, Operators,
CSP Operators, Operators
community Vendors
Vendors

________________________________________________________________________________________________

© 2024 by the O-RAN ALLIANCE e.V. Your use is subject to the copyright statement on the cover page of this specification. 31
 O-RAN.WG11.O-CLOUD-Security-TR.0-R003-v06.00

1 5.3.3 Public Cloud

2 A public cloud is one in which the cloud infrastructure and computing resources are made available to the general
3 public over a public network. A public cloud is owned by an organization providing cloud services, and serves a diverse
4 pool of clients (e.g. Operators, Third parties service providers).

6 Figure 5-8 presents a simple view of a public cloud and its actors.

8 Figure 5-11 : Public cloud

Cloud Container Engine or

Cloud type Hardware Host OS VNFs/CNFs
model Hypervisor

Public On-Premise NA NA NA NA

Public IaaS NA NA NA Operators

Public PaaS CSP CSP CSP Operators

10 5.3.4 Hybrid Cloud

11 A hybrid cloud is a composition of two or more clouds (on-site private, on-site community, off-site private, off-site
12 community or public) that remain as distinct entities but are bound together by standardized or proprietary technology
13 that enables data and application portability. Figure 5-9 presents a simple view of a hybrid cloud that could be built with
14 a set of clouds in the five deployment model variants.

15 The idea is to combine the benefits of multiple deployment models. The deployment in hybrid clouds could be either a
16 combination of private, public or community clouds. One of the popular use cases of hybrid clouds is in enhancing
17 security and privacy on the cloud without incurring the overhead costs (CAPEX) of building a private cloud. In this
18 case, non-critical resources like test workloads can be hosted in the public cloud, while critical resources like user data
19 and workloads are hosted internally.

20

________________________________________________________________________________________________

© 2024 by the O-RAN ALLIANCE e.V. Your use is subject to the copyright statement on the cover page of this specification. 32
 O-RAN.WG11.O-CLOUD-Security-TR.0-R003-v06.00

3 Figure 5-12 : Hybrid cloud

10

11

12

13

________________________________________________________________________________________________

© 2024 by the O-RAN ALLIANCE e.V. Your use is subject to the copyright statement on the cover page of this specification. 33
 O-RAN.WG11.O-CLOUD-Security-TR.0-R004-v06.00

2 5.4 High-Level risk assessment

3 The following table illustrates the high-level security risk assessment of the cloud deployment models (Private, Community, Public and Hybrid). Colors red, yellow, and green
4 are used on the security risk assessment to indicate high, medium, and low levels of risk. The Cloud Consumer (operator) is accountable for the security posture of the
5 deployment for all cloud deployment models [i.44].

Risks Private Cloud Community Cloud Public Cloud Hybrid Cloud

Regulatory Low Risk: Similar to traditional computing, as Moderate Risk: Cloud Consumer High Risk: Lack of flexibility Moderate Risk:
Compliance: Risk operators have better control and understanding (operator) has better control and over data protections Cloud Consumer
of non-compliance on how various government rules, laws, and understanding on how various government mechanisms, such as (operator) has better
with regulations on regulations apply to them. The Cloud Consumer rules, laws, and regulations apply to them. encryption and control and
data ownership, (operator) has control of data and regulatory Data leakage or data access risks due to implementation of specific understanding on
geographic compliance. multitenancy/shared infrastructure controls by data type. how various
location and between different operators. Different operators or service government rules,
privacy. providers might have different laws, and
Regulatory drift. encryption and control regulations apply to
requirements, and a public them.
cloud provider may not be
Data security and able to customize their
regulatory risk can infrastructure or provide Administrators
be associated with customers the control over have more control
loss, leakage, or encryption keys. and flexibility when
unavailability of implementing
data. This can security. The
cause business In some situations, it may be Cloud Consumer
interruption, loss determined that a Cloud can architect the
of revenue, loss of Service Provider's Hybrid Cloud
reputation, or cybersecurity tools, processes deployment to
regulatory and methods are insufficient ensure regulatory
incompliance (e.g. for protecting highly sensitive compliance of most
________________________________________________________________________________________________

© 2024 by the O-RAN ALLIANCE e.V. Your use is subject to the copyright statement on the cover page of this specification. 34
 O-RAN.WG11.O-CLOUD-Security-TR.0-R003-v06.00

sensitive data,
while less sensitive
data is accessed,
data. The Cloud Consumer
stored, and
GDPR, HIPAA). (operator) is responsible for
processed in the
the security configuration of
Public Cloud.
CSP provided applications,
The Cloud tools and services.
Consumer
The Cloud
(operator) is
Consumer
accountable for The Cloud Consumer
(operator) must
data, regulatory (operator) must practice due
practice due
compliance, and diligence to assess the
diligence to assess
configuration of regulatory compliance of the
the regulatory
security controls. Cloud Service Provider's
compliance of the
environment.
Cloud Service
Provider's
environment.

Multi-Tenancy: Low Risk: Private Networks avoid shared High Risk: Data leakage or access risks High Risk: Data leakage or High Risk: Data
Risk due to Multi- resources. due to multitenancy/shared resources for access risks due to leakage or access
Tenancy with multiple Cloud Consumers (operators) that multitenancy/shared risks due to
shared resources. may be competitors. Cloud Consumer resources. Cloud Consumer multitenancy/shared
Risks include data (operator) must ensure security (operator) must ensure infrastructure.
leakage, VM configurations to protect access to network security configurations to Cloud Consumer
Escape, Host functions, confidentiality and integrity of protect access to network (operator) must
Escape, and data in motion, and confidentiality, functions, confidentiality and ensure security
Hyperjacking. integrity, and access controls for data at integrity of data in motion, configurations to
rest. and confidentiality, integrity, protect access to
and access controls for data at network functions,
rest. confidentiality and
integrity of data in
motion, and

________________________________________________________________________________________________

© 2024 by the O-RAN ALLIANCE e.V. Your use is subject to the copyright statement on the cover page of this specification. 35
 O-RAN.WG11.O-CLOUD-Security-TR.0-R003-v06.00

confidentiality,
integrity, and
access controls for
data at rest.

Third-Party Low Risk: With private cloud, the operator gains Moderate Risk: Security administrators High Risk: Lack of High Risk:
Administration: full control and visibility over its cybersecurity may deal with differing methods and tools customized security and Varying security
Operational risk posture and can customize it to fit its specific to monitor and act on threats depending on service level for different O- tools and
can be associated needs. where vulnerable resources reside. RAN network services, which configurations may
with O-RAN might require the operator to not prevent a
network services, choose a compensating consistent security
lack of control, Operator has complete visibility, monitoring and Lack of customized security and service security control and security baseline across the
visibility, etc. control, analyze logs, alerts and other data down level for different O-RAN network baseline. Hybrid Cloud
to the packet level. services, which might require the operator deployment. The
to choose a proximate acceptable security Cloud Consumer
and service level, including those related The underlying infrastructure may have reduced
to availability and disaster recovery. is not managed by the visibility with the
operator, security information CSP controlled part
may be not accessible. of the service.

Reduced control on critical Disaster Recovery

network services can impact should be provided
availability and disaster with a second CSP,
recovery. Disaster Recovery which may not have
with a second CSP, which the same security
may not have the same posture due to use
security posture due to use of of different security
different security tools and tools and
configurations. configurations.

________________________________________________________________________________________________

© 2024 by the O-RAN ALLIANCE e.V. Your use is subject to the copyright statement on the cover page of this specification. 36
 O-RAN.WG11.O-CLOUD-Security-TR.0-R003-v06.00

Security roles and

responsibilities
must be clearly
defined and
assigned to the
Cloud Consumer
(operator) and
Cloud Service
Provider (CSP).
The Cloud
Consumer
(operator) must
practice due
diligence to ensure
a consistent security
posture across the
Hybrid Cloud
deployment.

Technology High Risk: A constantly evolving technology Moderate Risk: Operators share a Low Risk: Larger CSPs often Moderate Risk:
Evolution: landscape that might require the operator to common set of security tools, for which invest heavily in top-end Hybrid Cloud
Technology risk upgrade or rearchitect its computing resources each is responsible for properly cybersecurity tools, as well as deployments
can be associated and retrain its technology support staff. configuring the security of its tenancy. staff who are highly provide flexible
with constantly knowledgeable in their field. management of
evolving This makes offloading legacy and
technologies and A potential for human error due to the number of Operators can share cloud complexity to cybersecurity tools and tasks proprietary
lack of configurable points and frequency of manage constantly evolving technology from in-house to a third party applications while
standardization in deployments. landscape that might require operators to highly appealing. enabling use of
how they integrate upgrade or rearchitect its computing technologies
or interoperate. resources and retrain its technology associated with
Technology risks support staff. Operators can transfer cloud cloud-based
could lead to costly Lack of qualified talent. services and
complexity to the CSP, which
rearchitecture already has the necessary applications.
efforts for adoption
________________________________________________________________________________________________

© 2024 by the O-RAN ALLIANCE e.V. Your use is subject to the copyright statement on the cover page of this specification. 37
 O-RAN.WG11.O-CLOUD-Security-TR.0-R003-v06.00

A potential for
human error due to
the number of
cloud expertise, infrastructure configurable points
and systems. For example, and frequency of
faster time-to-market and deployments. The
improved operations operator is
efficiency are achieved by responsible for
taking advantage of CSP- properly
or integration with
trained talent and their configuring the
new technology.
existing CI/CD DevOps, security across the
automation, orchestration and Hybrid Cloud. The
analytics capabilities. Cloud Consumer
Operators can then focus on (operator) must
service differentiation, not the practice due
underlying cloud platforms. diligence to ensure
a consistent security
posture across the
Hybrid Cloud
deployment.

Financial costs & High Risk: Operating private clouds is often a Moderate Risk: Designing and Low Risk: Operating public Moderate Risk:
operation more expensive endeavor than public cloud maintaining cybersecurity tools inside clouds is often a less Designing and
options. Businesses pay a premium for granular community clouds increase management expensive endeavor than maintaining
cloud control and visibility. responsibilities. private and community cloud cybersecurity tools
options. inside hybrid clouds
increase
Designing and maintaining cybersecurity tools Lack of Operator-trained administrators. management
inside private clouds dramatically increase Operators can transfer cloud responsibilities.
management responsibilities. operation to the CSP, which
already has the necessary
cloud expertise,
________________________________________________________________________________________________

© 2024 by the O-RAN ALLIANCE e.V. Your use is subject to the copyright statement on the cover page of this specification. 38
 O-RAN.WG11.O-CLOUD-Security-TR.0-R003-v06.00

Operators can
transfer part of the
cloud operation to
the CSP, which
Operators can share financial cost and the
infrastructure, and systems. already has the
Lack of Operator-trained administrators. operation of community cloud.
necessary cloud
expertise,
infrastructure, and
systems.

2 Risk levels: High, Moderate, Low

3 Table 5-2 : High level security risk assessment of cloud deployment models

________________________________________________________________________________________________

© 2024 by the O-RAN ALLIANCE e.V. Your use is subject to the copyright statement on the cover page of this specification. 39
 O-RAN.WG11.O-CLOUD-Security-TR.0-R004-v06.00

1 6 Roles and responsibilities

2 The list of users likely to interact with the O-CLOUD as well as their roles are presented in the table below. The last
3 column distinguishes between stakeholders acting:

4  Under the direct responsibility of an operator or

5  Under the responsibility of a third party (e.g. equipment supplier) acting through a contract with the operator.

6 The table shows many roles in which the operator and cloud service provider are both stakeholders. This highlights the
7 need to have:

8  Clearly defined and agreed upon roles and responsibilities in the cloud service agreement.

9  Separation of Duties enforced by the cloud service provider to limit insider threats.

10  Principles of least privilege access control configured and enforced by the operator.

Roles Responsibilities Stakeholders

O-Cloud Planner Operator planning O-Cloud instance. Operator, CSP

O-Cloud Installation Operator designing each O-Cloud instance.

Manager
Cloud Installation Manager issues a “service request” to the SMO
to update its Inventory, i.e., indicate that a new O-Cloud is to be Operator, CSP
inventoried. The Cloud Installation Project Manager also registers
to the SMO the basic software for the O-Cloud.

Network Function Install Operator designing each Network Function instance. Operator,
Manager Vendor

O-Cloud Installer Operator installing O-Cloud Node. He notifies SMO of the new O-
Cloud Build

NOTE: Cloud Installer must provide SMO with information to Operator, CSP
connect with the new O-Cloud Build, including the target O-Cloud
Node in the O-Cloud and identity of the basic software for O-
Cloud to be loaded on the O-Cloud

O-Cloud Maintainer Operator that operates and manages O-Cloud Nodes Operator

They manage component security configuration: configuration of

access rights, password and cryptographic key storage system,
Security administrator IPSec parameters, configuring remote access systems, etc. Operator

They hold the root password and the secret encryption root key.

They manage “system” components (e.g. back-up, update,

System administrator Operator
configuring system logs, etc.).

They can manage and configure one or more VNFs/CNFs (e.g.

O-RAN NF Administrator Near RT RIC, O-CU, O-DU). They can perform the daily Operator
operational tasks (notably provisioning) of NFs.

IMS Administrator They manage IMS activities. They can perform the daily Operator, CSP
________________________________________________________________________________________________

© 2024 by the O-RAN ALLIANCE e.V. Your use is subject to the copyright statement on the cover page of this specification. 40
 O-RAN.WG11.O-CLOUD-Security-TR.0-R003-v06.00

operational tasks and configure the IMS. They control functions

providing access to the IMS. They are responsible for VNFs/CNFs
hardware configuration.

They manage DMS activities. They can perform the daily

DMS Administrator operational tasks (notably provisioning) and configure the DMS. Operator CSP
They control functions providing access to DMS.

They manage the virtualization/containerization layer

Virtualization layer
(Hypervisor/Container Engine). They can perform the daily
administrator
operational tasks (notably provisioning) and configuration of the Operator, CSP
(Hypervisor/Container
virtualization layer. They control functions providing access to
Engine)
this layer.

They manage compute nodes (physical servers) They can access

Compute nodes administrator the node’s graphic console, start, stop, restart the node. They can
Operator, CSP
(physical servers) activate/deactivate the node network interfaces and check its
status. They manage local storage in compute nodes.

Storage administrator They manage shared storage (e.g. images repository) Operator, CSP

They can remotely (e.g. via VPN) or locally access equipment to

update, configure, remove or add network applications. They have
access to compute node configuration interfaces to update
Maintainer (equipment firmware and configure BIOS, CPU, MMU, etc. Vendor, Third
supplier or third party) Party
The maintainer works on the O-Cloud platform under the control
of the operator who (e.g. via IAM: Identity Access Management)
creates specific accounts for a limited period.

They are responsible for vulnerability scanning, testing,

Operator,
Internal validation laboratory qualifications, security/compliance of network applications before
Vendor, CSP
their deployment.

Setup a vulnerability management process of monitoring,

identifying, evaluating, treating, and reporting on security
vulnerabilities and incidents.

Security Incident Response Maintenance of the O-Cloud components that includes monitoring Operator,
Team for use of open source software with known vulnerabilities and Vendor, CSP
patching for vulnerabilities.

Provide a process for users, including security researchers, to

submit bug reports (e.g., using an issue tracker or a mailing list).

1 Table 6-3 : List of Users

________________________________________________________________________________________________

© 2024 by the O-RAN ALLIANCE e.V. Your use is subject to the copyright statement on the cover page of this specification. 41
 O-RAN.WG11.O-CLOUD-Security-TR.0-R003-v06.00

1 7 Security Problem Definition

2 Before analyzing the way to protect the O-Cloud, it is important to identify the threats affecting the different O-Cloud
3 components and data.

4 For this identification of threats, it is essential first to know the critical assets, consisting of anything that has value for
5 within O-Cloud and needs to be protected, and secondly to identify the threat agents, the entities that can adversely act
6 on the asset.

7 7.1 Assets
8 The services offered by the O-Cloud must be available and non-corrupted and must protect the assets highlighted in the
9 following cartography.

10

11 Figure 7-13 : Cartography of assets

12 For each asset, a description, the owner, and its security protection properties are given in the table below.

________________________________________________________________________________________________

© 2024 by the O-RAN ALLIANCE e.V. Your use is subject to the copyright statement on the cover page of this specification. 42
 O-RAN.WG11.O-CLOUD-Security-TR.0-R004-v06.00

Ass Com When Protection Level

Interfa
et Asset Title Asset Description pone At In Confidentia Integ Availabi Repl Authe
ce
ID nt rest transit lity rity lity ay nticity

A- O-Cloud It consists of SMO, O2, O- x x x x x x x

OC- Inventory O- CLOU
1 information of  The Physical Infrastructure (O-Cloud Node CLO D
NFVI Identifier, Pool Identifier, Pool Location UD internal
hardware Identifier, and Use Identifier) used to create the interfac
resources and O-Cloud es
software  The logical Clouds which it provides as
resources interfaces for deployments, and the inventory of
deployments (deployment ID and descriptor) on
the cloud

 O-Cloud ID, IP address, IMS address, the IP

address endpoint or url of the SMO and any
necessary security keys or passwords for
communication using O2

 DMS capabilities

 O-Cloud (IMS): List of All Resource Pools in

the O-Cloud, Attributes of a specific O-Cloud,
List of all resources of an O-Cloud Pool,
Attributes of each O-Cloud Resource, List of all
DMS

 O-Cloud (DMS): List of Locations Supported

For a given location the Capabilities supported
(e.g. Descriptor types, Technology types,
Accelerator types), For a given location the
Capacity of the location, For a given location the

________________________________________________________________________________________________

© 2024 by the O-RAN ALLIANCE e.V. Your use is subject to the copyright statement on the cover page of this specification. 43
 O-RAN.WG11.O-CLOUD-Security-TR.0-R003-v06.00

Ass Com When Protection Level

Interfa
et Asset Title Asset Description pone At In Confidentia Integ Availabi Repl Authe
ce
ID nt rest transit lity rity lity ay nticity

Availability of the location

It includes:

 Telemetry information of O-Cloud deployments

in the network for analyzing the O-Cloud’s state
and health, and for delivering on service
monitoring goals. It consists of fault,
performance and configuration data.

 Deployment Telemetry to monitor the number of

deployment instances an O-Cloud has at that O2, O-
Functional moment and how many were expected, how the SMO, CLOU
A- on-progress deployment is going, and health
telemetry: O- D
OC- checks. Additional Deployment Telemetry x x x x x x x
deployment, CLO internal
2 metrics like CPU, network, and memory usage
infrastructure UD interfac
can also be collected. es

 Infrastructure Telemetry to monitor the health of

the O-Cloud Infrastructure components. Network
Operations are interested in discovering if all the
components in the O-Cloud Infrastructure are
working properly and at what capacity, how
many deployments are running on each node,
and the resource utilization of the O-Cloud
Infrastructure.

A- O-Cloud O-Cloud Provisioning information (Affinity, Anti- SMO, O2, O- x x x x x

OC- Provisioning Affinity, Quorum Diversity Rules, capabilities, O- CLOU
3 information capacity and availability) CLO D

________________________________________________________________________________________________

© 2024 by the O-RAN ALLIANCE e.V. Your use is subject to the copyright statement on the cover page of this specification. 44
 O-RAN.WG11.O-CLOUD-Security-TR.0-R003-v06.00

Ass Com When Protection Level

Interfa
et Asset Title Asset Description pone At In Confidentia Integ Availabi Repl Authe
ce
ID nt rest transit lity rity lity ay nticity

internal
UD interfac
es

O2, O-
O-Cloud SMO, CLOU
A- O-Cloud software management information: catalog
software O- D
OC- of authorized software and its version, list of x x x x x x
management CLO internal
4 authorized VNF/CNF, VNF/CNF description files
information UD interfac
es

Package: O-RAN Cloudified Network Function

Software Image including the underlying software
executable image, image properties/metadata such as
descriptors, image signature(s), LCM scripts, data
files, SoftwareImageId, Vendor, and version, secrets,
configuration files.
O-RAN
A- O-
Cloudified Application data: Subscriber data, Policy data, UE
OC- CLO - x x x x
Network context, etc.
5 UD
Function
NF location, time clock

NF instance: Application software, guest OS, host

OS, Libs, instance identity, crypto keys, namespaces,
virtual resources instance states, physical hardware,
etc.

A- Certificates X.509 certificates in O-RAN network such as those All O2, O- x x x x x

OC- used for SMO, O-CU-CP, O-CU-UP, O-DU, O-RU, CLOU
6 Near-RT RIC, Non-RT RIC, O-CLOUD, NetCONF D
________________________________________________________________________________________________

© 2024 by the O-RAN ALLIANCE e.V. Your use is subject to the copyright statement on the cover page of this specification. 45
 O-RAN.WG11.O-CLOUD-Security-TR.0-R003-v06.00

Ass Com When Protection Level

Interfa
et Asset Title Asset Description pone At In Confidentia Integ Availabi Repl Authe
ce
ID nt rest transit lity rity lity ay nticity

internal
(O1, Fronthaul) interfac
es

Security private keys in O-RAN network such as O2, O-

those used by SMO, O-CU-CP, O-CU-UP, O-DU, O- CLOU
A-
RU, Near-RT RIC, Non-RT RIC, O-CLOUD, D
OC- Private keys All x x x x
NetCONF (O1, Fronthaul) for authentication, internal
7
encryption, signing (e.g. for TLS and similar interfac
protocols, image signing) es

Credentials (Administrators): account information

A-
and passwords on SMO, O-CU-CP, O-CU-UP, O-
OC- Credentials All - x x x x
DU, O-RU, Near-RT RIC, Non-RT RIC, O-Cloud
8
used in O-RAN network

O-Cloud components associated and configuration

data, such as:
Software O2, O-
components at  Software version information, identifier, IP CLOU
A-
runtime and address, port number, network layer parameters, D
OC- All x x x x
their time of request, previous behavior, etc. internal
9
associated interfac
data  The security related parameters (such audit es
records, lists of algorithms which are allowed for
usage, file management, hash values, etc.).

A-
Security event Security event log files generated by O-Cloud
OC- All - x x x x x x x
logs components
10

________________________________________________________________________________________________

© 2024 by the O-RAN ALLIANCE e.V. Your use is subject to the copyright statement on the cover page of this specification. 46
 O-RAN.WG11.O-CLOUD-Security-TR.0-R003-v06.00

Ass Com When Protection Level

Interfa
et Asset Title Asset Description pone At In Confidentia Integ Availabi Repl Authe
ce
ID nt rest transit lity rity lity ay nticity

O2, O-
CLOU
A-
Security Security telemetry from the NFV system for D
OC- All x x x x x x x
telemetry detecting threats and anomalies internal
11
interfac
es

A-
Other Crypto Cryptographic keys used during secure boot, for
OC- All - x x x x
materials encryption/decryption, etc.
12

Data in transit x x x x x
A- AALI-
AALI-C-
OC- Data transported over the AALI-C-Mgmt interface C-
Mgmt
13 Mgmt
interface

AALI- x x x x
Data in transit
A- C-App
AALI-C-App Data transported over the AALI-C-App & AALI-P
OC- &
& AALI-P interfaces
14 AALI-
interfaces
P

Data in transit vendor x x x

A-
vendor specific
OC- Data transported over the vendor specific interface
specific interfac
15
interface e

________________________________________________________________________________________________

© 2024 by the O-RAN ALLIANCE e.V. Your use is subject to the copyright statement on the cover page of this specification. 47
 O-RAN.WG11.O-CLOUD-Security-TR.0-R003-v06.00

Ass Com When Protection Level

Interfa
et Asset Title Asset Description pone At In Confidentia Integ Availabi Repl Authe
ce
ID nt rest transit lity rity lity ay nticity

A- HW x x x

OC- AAL profiles AAL profiles accel

16 erator

A- HW x x x

OC- AAL-LPU s AAL-LPUs accel

17 erator

A- HW x x x
Stored AAL
OC- Stored AAL data (e.g., logs, configuration data) accel
data
18 erator

A- HW x x x
AAL software including software, libraries, drivers,
OC- AAL software accel
etc.
19 erator

A- HW x x x
Device
OC- The hardware accelerator device firmware accel
firmware
20 erator

1 Table 7-4 : List of Assets

________________________________________________________________________________________________

© 2024 by the O-RAN ALLIANCE e.V. Your use is subject to the copyright statement on the cover page of this specification. 48
 O-RAN.WG11.O-CLOUD-Security-TR.0-R003-v06.00

1 7.2 Threats
2 The complexity and the extension of attack surface of a virtualized environment increase the difficulty to list, in an
3 exhaustive manner, the security threats to which the O-Cloud assets are exposed. For this activity of threat analysis,
4 some reports have been used to help the identification of a largest number of these threats:

5  CISA/NSA - Kubernetes Hardening Guidance [i.3]

6  MITRE ATT&CK containers matrix [i.4]

7  ENISA Threat Landscape for 5G Networks: Threat assessment for the fifth generation of mobile
8 telecommunications networks (5G) [i.5]

9  ETSI Secure End-to-End VNF and NS management specification Secure End-to-End VNF and NS management
10 specification [i.6]

11 The following table is the template used to present the threat characteristics:

Threat ID Unique identification per Threat (e.g. T-XX-01)

Threat title Title of the threat

Threat description Description of the Threat

Threat type Spoofing

Tampering

Repudiation

Information disclosure

Denial of Service

Elevation of Privilege

Vulnerabilities What vulnerabilities can the threat exploits?

Impact type Authenticity

Integrity

Non-repudiability

Confidentiality

Availability

Authorization

Threatened Assets Impacted Asset(s) (Data & Component)

Affected Services What services (from section 4.3) could be affected by this Threat

Potential mitigations Mitigation measures to address the threat

12

________________________________________________________________________________________________
© 2024 by the O-RAN ALLIANCE e.V. Your use is subject to the copyright statement on the cover page of this specification. 49
 O-RAN.WG11.O-CLOUD-Security-TR.0-R003-v06.00

1 7.2.1 Threat and impact types

2 For identifying threats, we are using STRIDE:

3 1. S - Spoofing identity. An application or program can masquerade as another to gain advantages not typically
4 allowed for that program.

5 2. T - Tampering with data. This involves the malicious modification of data, including making unauthorized
6 changes to a database and alteration of data as it flows between computers.

7 3. R - Repudiation. A user or program refuses the authenticity of a good or reasonable command or action.

8 4. I - Information disclosure. This involves the exposure of information to individuals with unauthorized access
9 to it. For example, users gain the ability to read a file that they normally would not have been granted access
10 to, or an intruder can read data in transit between computers.

11 5. D - Denial of service. These attacks deny service to valid users, such as making a website unavailable or
12 unusable by flooding it with illegitimate requests to keep legitimate users without access.

13 6. E - Elevation of privileges. An unauthorized user gains privileged rights to access previously no granted to
14 compromise or destroy the system, such as a change in membership.

Threat types Impact types

Spoofing Authenticity

Tampering Integrity

Repudiation Non-repudiability

Information disclosure Confidentiality

Denial of Service Availability

Elevation of Privilege Authorization

15

16 7.2.2 Attack surface

17 An attack surface of a system refers to the set of various entry points that can be exploited. The various components that
18 compose the attack surface of the O-Cloud are depicted in the following figure. They are as follows:

19 1) VNFs/CNFs: O-DU, O-CU, O-RU, Near RT-RIC/xApps

20 2) Images repository with its interface to O-Cloud

21 3) Virtualization layer: Hypervisor and/or Container Engine, Host OS

22 4) Hardware resources including compute, storage, network, and hardware accelerator manager

23 5) O-Cloud API

24 6) O2dms and O2ims interfaces

25 7) NFO and Federated O-Cloud O&M (FOCOM) within the SMO

26 8) AAL

________________________________________________________________________________________________
© 2024 by the O-RAN ALLIANCE e.V. Your use is subject to the copyright statement on the cover page of this specification. 50
 O-RAN.WG11.O-CLOUD-Security-TR.0-R003-v06.00

1 The attack vectors for exploiting vulnerabilities of these components are discussed in detail in the threat events sections.

3 Figure 7-14 : Attack vectors

5 7.2.3 Vulnerabilities
6 The following figure highlights the main vulnerabilities that may emerge within the attack vectors (see Figure 7-2).

8 Figure 7-15 : Vulnerabilities within O-Cloud

________________________________________________________________________________________________
© 2024 by the O-RAN ALLIANCE e.V. Your use is subject to the copyright statement on the cover page of this specification. 51
 O-RAN.WG11.O-CLOUD-Security-TR.0-R003-v06.00

1 7.2.4 Threat events

2 The following threats to O-Cloud have been identified and are analyzed in this Clause. Other threats within the attack
3 vectors ④, ⑥, ⑦ ⑧ will be added in future versions of the report.

Threat Threat Title

Generic Threats

T-GEN-01 Software flaw attack

T-GEN-02 Malicious access to exposed services using valid accounts

T-GEN-03 Untrusted binding between the different O-Cloud layers

T-GEN-04 Lack of Authentication & Authorization in interfaces between O-

Cloud components

T-GEN-05 Unsecured credentials and keys

T-GEN-06 Sensitive application data cache exploitation

Threats concerning VMs/Containers

T-VM-C-01 Abuse of a privileged VM/Container

T-VM-C-02 VM/Container escape attack

T-VM-C-03 VM/Container data theft

T-VM-C-04 VM/Container migration attacks

T-VM-C-05 Changing virtualization resource without authorization

T-VM-C-06 Failed or incomplete VNF/CNF termination or releasing of resources

Threats concerning VM/Container images

T-IMG-01 VM/Container images tampering

T-IMG-02 Insecure channels with images repository

T-IMG-03 Secrets disclosure in VM/Container images

T-IMG-04 Build image on VL

Threats concerning the virtualization layer (Host OS-Hypervisor/Container engine)

T-VL-01 VM/Container hyperjacking attack

T-VL-02 Boot tampering

T-VL-03 Attack internal network services

Threats concerning O-Cloud interfaces

T-O2-01 MitM attacks on O2 interface between O-Cloud and SMO

T-OCAPI-01 MitM attacks on O-Cloud interface between VNFs/CNFs and the

________________________________________________________________________________________________
© 2024 by the O-RAN ALLIANCE e.V. Your use is subject to the copyright statement on the cover page of this specification. 52
 O-RAN.WG11.O-CLOUD-Security-TR.0-R003-v06.00

virtualization layer

Threats concerning hardware resources

T-HW-01 Cross VM/Container side channel attacks

T-HW-02 MitM attacks on the interface between virtualization layer and

hardware

Threats concerning O-Cloud management (SMO, NFO, FOCOM)

T-ADMIN-01 Denial of service against NFO/FOCOM

T-ADMIN-02 Abuse an O-Cloud administration service

Threats concerning Acceleration Abstraction Layer (AAL)

T-AAL-01 Attacker exploits insecure API to gain access to hardware accelerator

resources

T-AAL-02 Internal Overload DoS attack targeting AAL services

T-AAL-03 Fail to clear resources

T-AAL-04 HAM compromise

T-AAL-05 Malicious memory accesses

T-AAL-06 Firmware attacks

Threats concerning O-Cloud instance ID

T-O-CLOUD-ID-01 ID reuse in O-Cloud's object lifecycle

T-O-CLOUD-ID-02 Node redundancy in O-Cloud deployments

T-O-CLOUD-ID-03 O-Cloud ID mismanagement

2 7.2.4.1 Generic Threats

Threat ID T-GEN-01

Threat title Software flaw attack

Threat Code of host OS, Hypervisor/Container Engine and VNF/CNF can include flaws that an
description attacker can exploit if they are present.

O-RAN software components rely on opensource software, opensource libraries, 3rd party
components. Vulnerability in any of these software components likely to allow attacker to
exploit O-CLOUD environment. This could lead attacker to carry out to malicious activities,
such as:

 Compromise of the underlying VM/Container

 Exploit host access via Escape to Host

 Take advantage of weak identity and access management policies to attempt to elevate

________________________________________________________________________________________________
© 2024 by the O-RAN ALLIANCE e.V. Your use is subject to the copyright statement on the cover page of this specification. 53
 O-RAN.WG11.O-CLOUD-Security-TR.0-R003-v06.00

privileges

 Execute adversary-controlled code

 Enable an adversary to move from a virtualized environment, such as within a virtual

machine or container, onto the underlying host

Threat type Spoofing, Tampering, Information disclosure, Elevation of Privilege

Vulnerabilities Vulnerable code exploits, Design Weakness

Impact type Authenticity, Integrity, Confidentiality, Authorization

Threatened
Host OS, Hypervisor/Container Engine and VNFs/CNFs (Near RT RIC, O-CU, O-DU)
Assets

Affected Services All services

REC-IMGP Image protection

REC-VHPM Vulnerability Handling and Patch Management

Potential REC-SDLC Secure Development Lifecycle

mitigations REC-LOG Logging, Monitoring and Alerting

REC-ISO Strong Isolation

REC-AUD Security Audit

Threat ID T-GEN-02

Threat title Malicious access to exposed services using valid accounts

Access to valid accounts to use the O-Cloud services is often a requirement, which could be
obtained through credential pharming or by obtaining the credentials from users after
compromising the network.

Adversaries may obtain and abuse credentials of existing accounts as a means of gaining initial
access, persistence, privilege escalation, or defense evasion. Compromised credentials may be
Threat used to bypass access controls placed on various resources on O-Cloud.
description
Compromised credentials may also grant an adversary increased privilege to specific O-Cloud
services or access to restricted areas of the O-Cloud network.

Access may be also gained through an exposed service that doesn’t require authentication. In
containerized environments, this may include an exposed Docker API, Kubernetes API server,
kubelet, or web application such as the Kubernetes dashboard.

Threat type Spoofing, Tampering, Information disclosure, Elevation of Privilege

Vulnerabilities Lack of authentication

Impact type Authenticity, Integrity, Confidentiality, Authorization

________________________________________________________________________________________________
© 2024 by the O-RAN ALLIANCE e.V. Your use is subject to the copyright statement on the cover page of this specification. 54
 O-RAN.WG11.O-CLOUD-Security-TR.0-R003-v06.00

Threatened
Host OS, Hypervisor/Container Engine and VNFs/CNFs (Near RT RIC, O-CU, O-DU)
Assets

Affected Services All services

REC-IAM Identity, Authentication, and Access Management

REC-CM Certificate management

Potential
REC-LOG Logging, Monitoring and Alerting
mitigations
REC-NS Network Segmentation & Filter Network Traffic

REC-AUD Security Audit

Threat ID T-GEN-03

Threat title Untrusted binding between the different O-Cloud layers

One major challenge in virtualized architectures and especially in O-Cloud is to prove that a
particular VM/Container runs on top of a specific Hypervisor/Container Engine. More
specifically, it is necessary to assure that a trusted VM/Container is executed on a particular
trusted Hypervisor/Container Engine, whereas the Hypervisor/Container Engine's trust state
relies on an attestation that considers the entire corresponding hard and software stack. More
precisely, this includes all hardware chips, firmware, OS and Hypervisor/Container Engine
components that are relevant for the Hypervisor/Container Engine's trust state determination.
Threat
description If it is not possible to establish a correlation between VM/Container and Hypervisor/Container
Engine, an attacker is able to make use of a trusted VM/Container that runs on top of an
untrusted Hypervisor/Container Engine and it would be impossible to detect any interference
made by the malicious Hypervisor/Container Engine, e.g. intercepting communication,
replacing strong or using weak cryptographic keys, etc. Similarly, trustworthiness in the
service-layer might only be established if there is a mechanism to determine that only trusted
VNFs/CNFs, w.r.t trusted VM/Container's, are running on specific trusted
Hypervisors/Container Engines that are part of the service-provisioning-chain.

Threat type Tampering, Information disclosure

Vulnerabilities Lack of integrity verification during boot or runtime

Impact type Integrity, Confidentiality

Threatened
Host OS, Hypervisor/Container Engine and VNFs/CNFs (Near RT RIC, O-CU, O-DU)
Assets

Affected Services All services

Potential REC-IMGP Image protection

mitigations
REC-LOG Logging, Monitoring and Alerting

REC-RA Remote Attestation

REC-SB Secure Boot

________________________________________________________________________________________________
© 2024 by the O-RAN ALLIANCE e.V. Your use is subject to the copyright statement on the cover page of this specification. 55
 O-RAN.WG11.O-CLOUD-Security-TR.0-R003-v06.00

REC-SNFLC Security VNF/CNF lifecycle

Threat ID T-GEN-04

Threat title Lack of Authentication & Authorization in interfaces between O-Cloud components

O-Cloud deploys CNF applications as containers in a cluster of physical nodes which may be
spanned across geographical locations. Owing to the Service Based Architecture of CNFs, this
introduces several service endpoints communicating across each other over the network
(container to container, container to cloud infrastructure component) and it is difficult to
distinguish between a service terminating an external interface and a service exposing only an
internal interface.

Multi-tenant deployments and deployments in public cloud also require the CNF applications to
run alongside unknown entities. In such deployment scenarios, CNF service endpoints with no
Threat authentication/weak authentication expose risk of attack that can impact the availability of
description service and the CNF.

Lack of proper authentication in interfaces exposed by CNF services, introduces threats of

lateral movement where a compromised container/rogue container:

 Can compromise the availability of internal service by bringing down the internal service
and perform lateral movement of attack by exploiting the availability of other such services

 Can compromise the confidentiality of the internal service by extracting critical application
data

Threat type Information disclosure, Denial of Service

Vulnerabilities Lack of authentication, Insecure interfaces

Impact type Availability, Confidentiality

Threatened
Host OS, Hypervisor/Container Engine and VNFs/CNFs (Near RT RIC, O-CU, O-DU)
Assets

Affected Services All services

Potential REC-IAM Identity, Authentication, and Access Management

mitigations REC-CM Certificate management

Threat ID T-GEN-05

Threat title Unsecured credentials and keys

Threat Adversaries may search compromised O-RAN NFs, VL, orchestration layer or hardware to find
description and obtain insecurely stored credentials. These credentials can be stored and/or misplaced in
many locations on the O-cloud platform, including plaintext files (e.g. Bash History), operating
system or application-specific repositories (e.g. Credentials in Registry), or other specialized
files/artifacts (e.g. Private Keys) [i.4].

Bash History1: Adversaries may search the bash command history on compromised systems for
1
1 https://attack.mitre.org/techniques/T1552/003/

________________________________________________________________________________________________
© 2024 by the O-RAN ALLIANCE e.V. Your use is subject to the copyright statement on the cover page of this specification. 56
 O-RAN.WG11.O-CLOUD-Security-TR.0-R003-v06.00

insecurely stored credentials.

Credentials in registry0: Adversaries may search the Registry on compromised systems for
insecurely stored credentials.

Private Keys0: Adversaries may search for private key certificate files on compromised systems
for insecurely stored credentials. Private cryptographic keys and certificates are used for
authentication, encryption/decryption, and digital signatures; Common key and certificate file
extensions include: .key, .pgp, .gpg, .ppk., .p12, .pem, .pfx, .cer, .p7b, .asc.

Adversary tools have been discovered that search compromised systems for file extensions
relating to cryptographic keys and certificates.

Threat type Tampering, Information disclosure, and Elevation of privilege

Vulnerabilities Lack of authentication, secret exposure (insufficient safeguarding of credentials)

Impact type Integrity, Confidentiality, Authorization

Threatened
Private keys and credentials
Assets

Affected Services All services

REC-SS Secure Storage

Potential
REC-PHY Physical Security Protection
mitigations
REC-SDD Secure data deletion

Threat ID T-GEN-06

Threat title Sensitive application data cache exploitation

Threat Most of the applications use data that is sensitive in nature which needs to be secured. And it is
description common for these applications to cache such sensitive data, after retrieving the data from a
secure storage. This caching occurs in various forms: within application memory, in persistent
file systems, or in ephemeral file systems (For example, non-persistent container file system).

For a VNF, the application can cache the sensitive data in its memory which is non-persistent
(erased when the application ceases to exist) or in the persistent virtual machine file system.

For a CNF, the application can store the sensitive data in its memory which is non-persistent
(erased when the application/microservice ceases to exist) or in the non-persistent container file
system, or in the persistent host file system, provided the application has the necessary
privileges to access host file system.

The storage of sensitive data (For example, certificates and private keys or session keys) in the
application cache is used to improve performance of the applications and keeping the sensitive
information readily available to the applications for faster initialization, re-initialization or
recovery.

An example of faster recovery/re-initialization is a scenario where a TLS client establishes a

0
1 https://attack.mitre.org/techniques/T1552/002/

0
2 https://attack.mitre.org/techniques/T1552/004/

________________________________________________________________________________________________
© 2024 by the O-RAN ALLIANCE e.V. Your use is subject to the copyright statement on the cover page of this specification. 57
 O-RAN.WG11.O-CLOUD-Security-TR.0-R003-v06.00

TLS session with a server and stores the client certificate and corresponding private key in the
application cache. If the TLS session is terminated unexpectedly (For example, due to network
error conditions), the TLS client uses the cached client certificates and private key for
recovering / re-establishing the TLS session, instead of retrieving the information from a more
secure, but slower, storage solution.

While leveraging application cache is indispensable for significant performance gains, it also
presents a notable security risk [i.59][i.60]. The sensitive data stored in application cache would
be a primary target from attackers/threat actors [i.61], who can exploit this information to
penetrate deeper into O-RAN network functions.

To counter this threat, a “Defense in depth” approach is essential. This approach encompasses
multiple security layers designed to mitigate risks associated with application caches, focusing
on strong encryption, strict access management and anomaly detection to protect sensitive data
effectively.

Threat type Tampering, Information disclosure

Vulnerabilities Secret exposure (insufficient safeguarding of credentials, etc.)

Impact type Integrity, Confidentiality

Threatened
Certificates, private keys, credentials and other application specific sensitive data
Assets

Affected Services All services

REC-NS Network Segmentation & Filter Network Traffic

Potential REC-LOG Logging, Monitoring and Alerting

mitigations REC-SDD Secure data deletion

REC-SS Secure Storage

2 7.2.4.2 Threats concerning VMs/Containers

Threat ID T-VM-C-01

Threat title Abuse of a privileged VM/Container

Threat It’s possible to run VMs/Containers with unintended configurations. Such misconfigurations
description can help the adversaries to compromise even strongest of VM/Container isolation measures.

Such misconfigurations scenarios include:

 VMs/Containers can be configured to have more privileges than what is actually required
(e.g. settings that give it unnecessary, and perhaps unplanned, privileges). For example, an
attacker with access to such a container, can use it to gain higher privileges on host,
perform un-authorized operations and get to anything that the host, or any of the containers
running on that host, can reach.

 VMs/Containers have unintended read/write access to a directory on host filesystem. This

could allow an attacker to perform unauthorized modifications to the contents, create
symbolic links to any directories or files not directly exposed by the hostPath, install SSH

________________________________________________________________________________________________
© 2024 by the O-RAN ALLIANCE e.V. Your use is subject to the copyright statement on the cover page of this specification. 58
 O-RAN.WG11.O-CLOUD-Security-TR.0-R003-v06.00

keys, read secrets mounted to the host, and take other malicious actions.

Threat type Spoofing, Tampering, Information disclosure, Denial of Service and Elevation of privilege

Vulnerabilities Misconfiguration or Insecure VM/Container configurations

Impact type Authenticity, Integrity, Confidentiality, Availability and Authorization

Threatened
Host OS, Hypervisor/Container Engine and VNFs/CNFs (Near RT RIC, O-CU, O-DU)
Assets

Affected Services SERV#01, SERV#03, SERV#04, SERV#05, SERV#06, SERV#07

REC-SCONF Security Configuration

REC-IAM Identity, Authentication, and Access Management

REC-CM Certificate management

Potential
REC-ISO Strong Isolation
mitigations
REC-SNFLC Security VNF/CNF lifecycle

REC-NS Network Segmentation & Filter Network Traffic

REC-SS Secure Storage

Threat ID T-VM-C-02

Threat title VM/Container escape attack

Threat VNF/CNF deployed on the same physical machine as tenants share the same host kernel and
description host OS resources. Lack of strong isolation between the VMs/Containers and the host allows for
a potential risk of a rogue VM/Container escaping the VM/Container confinement and
impacting other co-hosted VMs/Containers. In others, an attacker may deploy a new malicious
VM/Container configured without network rules, user limitations, etc. to bypass existing
defenses within O-Cloud infrastructure.

Attacker deploys malicious VM/Container to escape the host (Hypervisor/Container

Engine/Host OS) and reach the server’s hardware, then the malicious VM/Container can gain
root access to the whole server where it resides. This gives the malicious VM/Container full
control on all the VMs/Containers hosted on the same hacked server. This could allow an
attacker to undermine the confidentiality, integrity and/or availability of VNFs/CNFs resources.

Containers can be deployed by various means, such as via Docker's create and start APIs or via
a web application such as the Kubernetes dashboard or Kubeflow. Adversaries may deploy
containers based on retrieved or built malicious images or from benign images that download
and execute malicious payloads at runtime.

When a malicious VM/Container escapes isolation, it can gain full control over the underlying
host and cause any of the below serious threats:

 Attacker would gain the ability to mount attacks on the host or compromise the host
functionalities

 Compromise the confidentiality & integrity of co-hosted VMs/Containers and tenants

________________________________________________________________________________________________
© 2024 by the O-RAN ALLIANCE e.V. Your use is subject to the copyright statement on the cover page of this specification. 59
 O-RAN.WG11.O-CLOUD-Security-TR.0-R003-v06.00

 Launch DDOS attacks on co-hosted VMs/Containers and host services thereby degrading
their performance

 Introduce new vulnerabilities in host to be used for future attacks

 Lack of network segmentation could potentially expose other VMs/Containers in the

environment to attack. An example of this could be reconnaissance, exploitation and
subsequent lateral movement to another host within the cluster.

Threat type Spoofing, Tampering, Information disclosure, Denial of Service and Elevation of privilege

Shared tenancy vulnerabilities (multitenant environment), Lack of strong VM/Container

Vulnerabilities isolation, lack of authentication, Insecure networking, Unrestricted communication between
VMs/Containers

Impact type Authenticity, Integrity, Confidentiality, Availability and Authorization

Threatened
Host OS, Hypervisor/Container Engine and VNFs/CNFs (Near RT RIC, O-CU, O-DU)
Assets

Affected Services SERV#01, SERV#03, SERV#04, SERV#05, SERV#06, SERV#07

REC-ISO Strong Isolation

REC-IAM Identity, Authentication, and Access Management

REC-CM Certificate management

Potential REC-NS Network Segmentation & Filter Network Traffic

mitigations REC-LOG Logging, Monitoring and Alerting

REC-SCONF Security Configuration

REC-SNFLC Security VNF/CNF lifecycle

REC-SS Secure Storage

3 Figure 7-16 : Illustration of the VM/Container escape attack

Threat ID T-VM-C-03

________________________________________________________________________________________________
© 2024 by the O-RAN ALLIANCE e.V. Your use is subject to the copyright statement on the cover page of this specification. 60
 O-RAN.WG11.O-CLOUD-Security-TR.0-R003-v06.00

Threat title VM/Container data theft

The VNF/CNF remotely stores sensitive data (e.g. passwords, private keys, subscription data,
logs) on the logical volume that the IMS/DMS allocates to the VNF/CNF. An attacker can
retrieve/manipulate these data if they have been stored in an insecure way (e.g. clear text,
unsalted hashes) or a malware is installed on the logical volume that the VIM allocates to the
VNF/CNF.

Container example: Adversaries may attempt to discover containers and other resources that are
Threat available locally within O-Cloud. Other resources may include images, deployments, pods,
description nodes, and other information such as the status of a cluster. These resources can be viewed
within web applications such as the Kubernetes dashboard or can be queried via the Docker and
Kubernetes APIs. In Docker, logs may leak information about the environment, such as the
environment’s configuration, which services are available, and what cloud provider the victim
may be utilizing. The discovery of these resources may inform an adversary’s next steps in the
environment, such as how to perform lateral movement and which methods to utilize for
execution.

Threat type Tampering, Information disclosure

Vulnerabilities Lack of authentication, insecure data storage

Impact type Integrity, Confidentiality

Threatened
Images, environment’s configuration, and other information such as the status of a cluster
Assets

Affected Services SERV#01, SERV#02

REC-IAM Identity, Authentication, and Access Management

REC-CM Certificate management

REC-NS Network Segmentation & Filter Network Traffic

Potential
REC-LOG Logging, Monitoring and Alerting
mitigations
REC-PHY Physical Security Protection

REC-SS Secure Storage

REC-SDD Secure data deletion

Threat ID T-VM-C-04

Threat title VM/Container migration attacks

Threat The attacks that exploit VM/Container migration can be divided into two subcategories based
description on the target plane:

1. Control Plane Attacks: These attacks target the module that is responsible for handling
the migration process on a server which is called the migration module that is found in the
host. By exploiting a bug in the migration module software, the attacker can hack the server
and take full control over the migration module. This gives the attacker the ability to launch
malicious activities including the following:

________________________________________________________________________________________________
© 2024 by the O-RAN ALLIANCE e.V. Your use is subject to the copyright statement on the cover page of this specification. 61
 O-RAN.WG11.O-CLOUD-Security-TR.0-R003-v06.00

a. Migration Flooding: The attacker moves all the VMs/Containers that are hosted
on the hacked server to a victim server that does not have enough resource
capacity to host all the moved VMs/Containers. This causes a denial of service for
the VNFs/CNFs running in the VMs/Containers of the victim server as there will
not be enough resources to satisfy the demands of all the hosted VMs/Containers
leading into VM/Container performance degradation and VM/Container crashes.

b. False Resource Advertising: The hacked server claims that it has a large resource
slack (a large amount of free resources). This attracts other servers to off-load
some of their VMs/Containers to the hacked server so that the O-Cloud workload
gets distributed over the O-Cloud servers. After moving VMs/Containers from
other servers to the hacked server, the attacker can exploit other vulnerabilities to
break into the offloaded VMs/Containers as now these VMs/Containers are placed
on a server that is under the control of the attacker.

2. Data Plane Attacks: These constitute the second type of VM/Container migration attacks
and those attacks target the network links over which the VM/Container is moved from a
server to another. Such data plane attacks include the MitM where an attacker sniffs the
packets that are exchanged between the source and destination servers and reads the
migrated memory pages. The attacker can monitor and/or modify the received packets
while continuing to forward them to victim VM/Container resides so that the victim does
not detect that any malicious activity is going on.

Threat type Tampering, Information disclosure, Denial of Service

Host misconfiguration, lack of authentication, memory pages copied in clear, vulnerable code
Vulnerabilities
exploits

Impact type Integrity, Confidentiality, Availability

Threatened
VNFs/CNFs (Near RT RIC, O-CU, O-DU)
Assets

Affected Services SERV#03, SERV#04, SERV#05, SERV#06, SERV#07

REC-CM Certificate management

REC-NS Network Segmentation & Filter Network Traffic

Potential REC-IAM Identity, Authentication and Access Management

mitigations REC-SNFLC Security VNF/CNF lifecycle

REC-LOG Logging, Monitoring and Alerting

REC-RA Remote Attestation

________________________________________________________________________________________________
© 2024 by the O-RAN ALLIANCE e.V. Your use is subject to the copyright statement on the cover page of this specification. 62
 O-RAN.WG11.O-CLOUD-Security-TR.0-R003-v06.00

2 Figure 7-17 : Illustration of the migration flooding attack

5 Figure 7-18 : Illustration of the false resource advertising attack

8 Figure 7-19 : Illustration of the migration MITM attack

Threat ID T-VM-C-05

Threat title Changing virtualization resource without authorization

Threat IMS/DMS which manage the Virtualization layer is responsible for assigning virtualized

________________________________________________________________________________________________
© 2024 by the O-RAN ALLIANCE e.V. Your use is subject to the copyright statement on the cover page of this specification. 63
 O-RAN.WG11.O-CLOUD-Security-TR.0-R003-v06.00

resource as requested.

There are several ways to cause a DoS attack for the VNFs/CNFs:

 If IMS/DMS are compromised or the O2 interface is not securely protected, an attacker

who compromised the IMS/DMS or breached the O2 interface can change the virtualized
resource used by a VNF/CNF by manipulating the allocation of virtualized resource. For
example, when an instantiated VNF/CNF is running, adversaries having access to a
compromised IMS/DMS or adversaries breaching the insecure O2 interface can misguide
the Virtualization layer to reduce the resource of or delete a VM/Container on which a
VNF/CNF is running. This can result in the reliability, availability or even illegal
termination of a VNF/CNF and hence the denial of service.

 Hardware resource configuration and state information (e.g. events) exchange is performed
through O2 interface. If the IMS is compromised or the O2 interface is not securely
description
protected, an attacker who compromised the IMS or breached the O2 interface can tamper
the hardware configuration and state information so that the virtualized resource supported
by the hardware layer becomes unreliable.

 Adversaries having access to a compromised virtualization layer can change the

virtualization resource used by the instantiated VNF/CNF without authorization,

 A malicious VM/Container deployed for one instance of a VNF/CNF on a host can illegally
occupy the resources of the instantiated VNF/CNF deployed on the same host, resulting in
resource limitation of the instantiated VNF/CNF

In this type of attacks, the extra allocation of resources for the malicious VM/Container comes
at the expense of the other VMs/Containers that share the same server as the malicious
VM/Container, where these victim VMs/Containers get allocated less share of resources than
what they should actually obtain, which in turn degrades their performance.

Threat type Denial of Service

Vulnerabilities Insecure O1/O2 interfaces, Lack of authentication/access control on IMS/DMS

Impact type Availability

Threatened
Host OS, Hypervisor/Container Engine and VNFs/CNFs (Near RT RIC, O-CU, O-DU)
Assets

Affected Services SERV#01

REC-LOG Logging, Monitoring and Alerting

REC-CM Certificate management

Potential REC-IAM Identity, Authentication and Access Management

mitigations REC-ISO Strong Isolation

REC-PHY Physical Security Protection

REC-AUD Security Audit

________________________________________________________________________________________________
© 2024 by the O-RAN ALLIANCE e.V. Your use is subject to the copyright statement on the cover page of this specification. 64
 O-RAN.WG11.O-CLOUD-Security-TR.0-R003-v06.00

2 Figure 7-20 : Illustration of the Theft-of-Service/DoS Attack

Threat ID T-VM-C-06

Threat title Failed or incomplete VNF/CNF termination or releasing of resources

A misconfigured VNF/CNF is instantiated in the O-Cloud infrastructure to access data not

erased from a terminated VNF/CNF or any VNF/CNF that has released resources. Data could
include application data, cryptographic keys, etc.

Threat Abuse of resources allocation in the O-Cloud infrastructure to allocate to a malicious VNF/CNF
description the virtual resources released from a terminated VNF/CNF or from a VNF/CNF that has
released resources after a move or a scaling process.

Inclusion of concealed software in the O-Cloud infrastructure to prevent the deletion/erasure of

data and states of the VNF/CNF that has been terminated.

Threat type Information disclosure

Vulnerabilities Lack of authentication, misconfigurations (VNF/CNF, Host OS, Hypervisor/Container Engine)

Impact type Confidentiality

Threatened Sensitive data (e.g. passwords, private keys, subscription data, logs), VNFs/CNFs (Near RT
Assets RIC, O-CU, O-DU) software and data

Affected Services No affected services

REC-SNFLC Security VNF/CNF lifecycle

Potential REC-LOG Logging, Monitoring and Alerting

mitigations REC-SS Secure Storage

REC-SCONF Security Configuration

5 7.2.4.3 Threats concerning VM/Container images

Threat ID T-IMG-01
________________________________________________________________________________________________
© 2024 by the O-RAN ALLIANCE e.V. Your use is subject to the copyright statement on the cover page of this specification. 65
 O-RAN.WG11.O-CLOUD-Security-TR.0-R003-v06.00

Threat title VM/Container images tampering

An attacker can inject malicious code or tamper the information inside the unprotected image
during on boarding. Then after the instantiation of the VNF/CNF, the tampered code can cause
DoS, information stealing, fraud and so on. There are several attacks categories belonging to
this threat. Such attacks include:

 Build machine attacks: If an attacker can modify or influence the way a VM/Container
Threat
image is built, they could insert malicious code that will subsequently get run in the
description
production environment.

 Supply chain attacks: Once the VM/Container image is built, it gets stored in a registry, and
it gets retrieved or “pulled” from the registry at the point where it’s going to be run. An
attacker who can replace an image or modify an image between build and deployment
could run arbitrary code on your deployment.

Threat type Tampering, Information disclosure

Compromised VM/Container images (Build machine attacks, Supply chain attacks) at rest, lack
Vulnerabilities
of authentication, misconfiguration or Insecure VM/Container images configurations

Impact type Integrity, Confidentiality

Threatened
VM/Container images
Assets

Affected Services SERV#02

REC-AUD Security Audit

REC-LOG Logging, Monitoring and Alerting

REC-IMGP Image Protection

Potential
REC-VHPM Vulnerability Handling and Patch Management
mitigations
REC-IAM Identity, Authentication, and Access Management

REC-CM Certificate management

REC-SDLC Secure Development Lifecycle

Threat ID T-IMG-02

Threat title Insecure channels with images repository

Images often contain sensitive components like an organization’s proprietary software, and
embedded secrets and administrator credentials. If connections to registries are performed over
insecure channels, man-in-the-middle attacks could intercept network traffic and therefore the
Threat
contents integrity and confidentiality of images may be compromised. There is also an
description
increased risk of man-in-the-middle attacks that could intercept network traffic intended for
registries and steal developer or administrator credentials within that traffic. Thus, could be
used to provide fraudulent or outdated images to orchestrators, etc.

________________________________________________________________________________________________
© 2024 by the O-RAN ALLIANCE e.V. Your use is subject to the copyright statement on the cover page of this specification. 66
 O-RAN.WG11.O-CLOUD-Security-TR.0-R003-v06.00

Threat type Tampering, Information disclosure

Vulnerabilities Compromised VM/Container images in transit

Impact type Integrity, Confidentiality

Threatened
VMs/Containers images
Assets

Affected Services SERV#02

REC-NS Network Segmentation & Filter Network Traffic

REC-IAM Identity, Authentication, and Access Management

Potential
REC-CM Certificate management
mitigations
REC-IMGP Image Protection

REC-LOG Logging, Monitoring and Alerting

Threat ID T-IMG-03

Threat title Secrets disclosure in VM/Container images

There are scenarios which benefit from including configuration and secrets, such as passwords
or credentials in VNFs/CNFs images. For e.g. VMs/Containers require to be able to connect to
other VMs/Containers within the deployment as well as with external entities. All these
connections need to be authenticated and secured. One way of achieving this is to provide the
requisite secrets or keys to the VMs/Containers which allow them to authenticate, be
authenticated, secure the communication channel and signature. A common but in-secure
means of providing secrets to the VMs/Containers is by packaging the secrets or the keys with
the image itself. There is the risk that the same can be extracted, read or manipulated before the
VM/Container is deployed and the secret used.
Threat
description With a long supply chain, VM/Container images are vulnerable to outside scrutiny. With
VM/Container images containing secrets or keys, this becomes a serious threat vector.
Adversaries can extract them by obtaining a copy of the image and they can be potentially
shared with third parties for illicit gain.

 Secrets embedded within a VM/Container image can be stolen.

 Secrets embedded within a VM/Container image can be modified

Compromised private keys and algorithms used for image signing due to poor key
protection/management/design could undermine the security of image signing process.

Threat type Spoofing, Tampering, Information disclosure

Vulnerabilities Secret exposure in VNF/CNF images

Impact type Authenticity, Integrity, Confidentiality

Threatened
VM/Container images
Assets

________________________________________________________________________________________________
© 2024 by the O-RAN ALLIANCE e.V. Your use is subject to the copyright statement on the cover page of this specification. 67
 O-RAN.WG11.O-CLOUD-Security-TR.0-R003-v06.00

Affected Services SERV#02

REC-AUD Security Audit

Potential REC-IMGP Image Protection

mitigations REC-SS Secure Storage

REC-SDLC Secure Development Lifecycle

Threat ID T-IMG-04

Threat title Build image on VL

Adversaries may build a VM/Container image directly on the VL to bypass defenses that
monitor for the retrieval of malicious images from a registry.

Container example: A remote build request may be sent to the Docker API that includes a
Dockerfile that pulls a vanilla base image, such as alpine, from a public or local registry and
then builds a custom image upon it.
Threat
description An adversary may take advantage of that build API to build a custom image on the host that
includes malware downloaded from their C2 server, and they then may deploy container using
that custom image. If the base image is pulled from a public registry, defenses will likely not
detect the image as malicious since it’s a vanilla image. If the base image already resides in a
local registry, the pull may be considered even less suspicious since the image is already in the
environment.

Threat type Spoofing, Tampering, Information disclosure, Denial of Service and Elevation of privilege

Vulnerabilities Host misconfiguration, lack of authentication

Impact type Authenticity, Integrity, Confidentiality, Availability and Authorization

Threatened
VM/Container images
Assets

Affected Services SERV#02, SERV#05

REC-AUD Security Audit

REC-IAM Identity, Authentication, and Access Management

REC-CM Certificate management

Potential REC-LOG Logging, Monitoring and Alerting

mitigations REC-IMGP Image Protection

REC-SB Secure Boot

REC-SS Secure Storage

REC-RA Remote Attestation

________________________________________________________________________________________________
© 2024 by the O-RAN ALLIANCE e.V. Your use is subject to the copyright statement on the cover page of this specification. 68
 O-RAN.WG11.O-CLOUD-Security-TR.0-R003-v06.00

1 7.2.4.4 Threats concerning the virtualization layer (Host OS-Hypervisor/Container engine)

Threat ID T-VL-01

Threat title VM/Container hyperjacking attack

VMs/Containers run on host machines, and it is needed to ensure that those hosts
(Hypervisor/Container Engine/Host OS- are not running vulnerable code (for example, old
versions of components with known vulnerabilities).

Hyperjacking is an attack in which adversaries gain control over the host of a server or install a
malicious Hypervisor/Container Engine/Host OS and exploit that to run malicious applications
on the VM/Container that run on top of the host. This would enable the attacker to control all
the VMs/Containers running on the host.

Hyperjacking involves installing a malicious, fake the Hypervisor/Container Engine/Host OS

that can manage the entire server system. If the attacker gains access to the
Threat Hypervisor/Container Engine/Host OS, everything that is connected to that server can be
description manipulated. The Hypervisor/Container Engine/Host OS represents a single point of failure
when it comes to the security and protection of sensitive information.

For a hyperjacking attack to succeed, an attacker would have to take control of the
Hypervisor/Container Engine/Host OS by the following methods:

 Injecting a rogue Hypervisor/Container Engine or Host OS beneath the original hypervisor

or on top of an existing Hypervisor/Container Engine/Host OS

 Directly obtaining control of the original Hypervisor/Container Engine or Host OS

 Running a rogue hypervisor on top of an existing hypervisor

Threat type Spoofing, Tampering, Information disclosure, Denial of Service and Elevation of privilege

Vulnerabilities Host misconfiguration, lack of authentication

Impact type Authenticity, Integrity, Confidentiality, Availability and Authorization

Threatened
Host OS, Hypervisor/Container Engine and VNFs/CNFs (Near RT RIC, O-CU, O-DU)
Assets

Affected Services SERV#01, SERV#03, SERV#04, SERV#05, SERV#06, SERV#07

REC-SCONF Security Configuration

REC-SB Secure Boot

REC-VHPM Vulnerability Handling and Patch Management

Potential REC-NS Network Segmentation & Filter Network Traffic

mitigations REC-IAM Identity, Authentication, and Access Management

REC-CM Certificate management

REC-ISO Strong Isolation

REC-SS Secure Storage

________________________________________________________________________________________________
© 2024 by the O-RAN ALLIANCE e.V. Your use is subject to the copyright statement on the cover page of this specification. 69
 O-RAN.WG11.O-CLOUD-Security-TR.0-R003-v06.00

2 Figure 7-21 : Illustration of the VM/Container hyperjacking attack

Threat ID T-VL-02

Threat title Boot tampering

The bootloader of the virtualization layer (Host OS, Hypervisor, Container Engine) for
VNF/CNF may be maliciously tampered by an attacker, e.g. the attacker compromises
hypervisor or host OS to tamper the bootloader of guest OS (in case of VM) or Container.

In a O-Cloud environment any failure during the boot sequence can result in a number of
Threat situations that need to be handled by the NFO/FOCOM:
description
• failure of the physical machine to start at all

• physical machine entering a safe-mode

• physical machine continuing boot regardless of the integrity measurements

Threat type Tampering

Vulnerabilities Host misconfigurations, lack of authentication

Impact type Integrity

Threatened
Host OS, Hypervisor/Container Engine and VNFs/CNFs (Near RT RIC, O-CU, O-DU)
Assets

Affected Services SERV#01, SERV#03, SERV#04, SERV#05, SERV#06, SERV#07

REC-SB Secure Boot

Potential REC-PHY Physical Security Protection

mitigations REC-RA Remote Attestation

REC-LOG Logging, Monitoring and Alerting

Threat ID T-VL-03

Threat title Attack internal network services

Threat In addition to attacking the network between containers, adversaries can also attack supporting
description services such as Kubernetes DNS service, which is only reachable from within the cluster
network. The highly distributed nature of containers requires shared services for example for
________________________________________________________________________________________________
© 2024 by the O-RAN ALLIANCE e.V. Your use is subject to the copyright statement on the cover page of this specification. 70
 O-RAN.WG11.O-CLOUD-Security-TR.0-R003-v06.00

coordination and service discovery. An attacker can target these services to degrade services.
For example, a denial-of-service against the service discovery infrastructure could prevent O-
Cloud to react to changing resource requirements properly. Thus, O-Cloud may no longer be
able to scale appropriately to sudden demand spikes [i.37].

Threat type Denial of Service

Vulnerabilities Lack of authentication, vulnerable code exploits, design weakness, misconfiguration

Impact type Availability

Threatened
Software components at runtime and their associated data
Assets

Affected Services SERV#03, SERV#04, SERV#05, SERV#06, SERV#07

REC-ISO Strong Isolation

Potential
REC-NS Network Segmentation & Filter Network Traffic
mitigations
REC-IAM Identity, Authentication and Access Management

3 7.2.4.5 Threats concerning O-Cloud interfaces

4 7.2.4.5.1 O2 interface

5 Two main interfaces are defined in O-RAN WG6 specification and identified as critical assets of O-Cloud, i.e.
6 interfaces O2 between O-Cloud and SMO. The threats on these interfaces are as follows.

Threat ID T-O2-01

Threat title MitM attacks on O2 interface between O-Cloud and SMO

Threat If the interface O2 interface is not protected, an attacker can attack all the requests/responses
description sent between the O-Cloud and the SMO (FOCOM and NFO).

For example, the attacker can tamper/alter/disclose requests and services (See ‘Critical services’
in 2.3) sent over O2 between O-Cloud and SMO, hence the virtualized resource or relevant
status information is not as requested. This affects the normal operation of the O-Cloud, and
even causes DoS attacks, information leakage.

An attacker can tamper the specific assignment of virtualized resources to cause resource
assignment errors or an attacker can intercept virtualized resources state information leading to
information disclosure.

An attacker can compromise IMS to tamper with the hardware state information (e.g. deleting
hardware alarm information) to affect the hardware's operation or to result in information
disclosure (e.g. an attacker can get the hardware configuration from the compromised IMS.
Then, the attacker can attack the hardware according to the configuration such as CPU type,
memory size etc.). An attacker can also tamper or intercept the hardware resource configuration

________________________________________________________________________________________________
© 2024 by the O-RAN ALLIANCE e.V. Your use is subject to the copyright statement on the cover page of this specification. 71
 O-RAN.WG11.O-CLOUD-Security-TR.0-R003-v06.00

and state information if the configuration and state information are transmitted using an
insecure protocol on the O2 interface.

Threat type Tampering, Information disclosure, Denial of Service

Vulnerabilities Insecure O2 interface, lack authentication

Impact type Integrity, Confidentiality, Availability

Threatened
Telemetry, provisioning, logs, software management, performance information
Assets

Affected Services SERV#01

REC-NS Network Segmentation & Filter Network Traffic

Potential REC-IAM Identity, Authentication, and Access Management

mitigations REC-CM Certificate management

REC-SCONF Security Configuration

2 7.2.4.5.2 O-Cloud API

Threat ID T-OCAPI-01

Threat title MitM attacks on O-Cloud interface between VNFs/CNFs and the virtualization layer

An attacker can attack an instantiated VNF/CNF through a compromised virtualization layer.

For example, cryptographic keys or other security critical data of an instantiated VNF/CNF
Threat could be stolen by an attacker with access to the virtualization layer, or the virtualized resource
description provided by the Virtualization layer to the instantiated VNF/CNF can be manipulated or the
bootloader of Guest OS (in case of VM) or Container of an instantiated VNF/CNF can be
tampered by an attacker via a compromised virtualization layer.

Threat type Tampering, Information disclosure, Denial of Service

Vulnerabilities Insecure O-Cloud APIs, lack of authentication

Impact type Integrity, Confidentiality, Availability

Threatened
Host OS, Hypervisor/Container Engine and VNFs/CNFs (Near RT RIC, O-CU, O-DU)
Assets

Affected Services SERV#01, SERV#03, SERV#04, SERV#05, SERV#06, SERV#07

Potential REC-NS Network Segmentation & Filter Network Traffic

mitigations
REC-IAM Identity, Authentication, and Access Management

REC-CM Certificate management

REC-SCONF Security Configuration

REC-SS Secure Storage

________________________________________________________________________________________________
© 2024 by the O-RAN ALLIANCE e.V. Your use is subject to the copyright statement on the cover page of this specification. 72
 O-RAN.WG11.O-CLOUD-Security-TR.0-R003-v06.00

REC-PHY Physical Security Protection

2 7.2.4.6 Threats concerning hardware resources

Threat ID T-HW-01

Threat title Cross VM/Container side channel attacks

In a typical cross-VM/Container side channel attack scenario, an adversary places a malicious

VM/Container co-resident to the target VM/Container so that they share the same hardware
resources. Then, the attacker extracts useful information such as cryptographic keys from the
target VM/Container to use them for traffic eavesdropping and man-in-the-middle attacks.
Through the side channel attack, an attacker sharing the same cache as the victim can monitor
the cache access behavior of the victim. For example, the attacker is able to monitor cache
timing information by measuring the execution of different operations on the victim’s
VM/Container. Generally, the attacker exploits timings in the shared high-level cache memory.
Threat However, power consumption or electromagnetic leaks can also be used as a vector to launch
description side channel attacks.

In the virtual environment, prior to the cross-VM/Container side channel attack, the attacker
needs to identify the target VM/Container’s location and place a malicious VM/Container co-
resident with the target. Later, that attacker may use the maliciously placed VM/Container to
extract information from the target VM/Container with the side channel attack.

Hardware vulnerabilities in processors can also have a large impact on O-Cloud security. Flaws
in chip design can result in the compromise of tenant information in the cloud through side-
channel attacks0.

Threat type Tampering, Information disclosure, Denial of Service

Vulnerabilities Flaws in chip design, use of shared hardware, Lack of isolation, lack of authentication

Impact type Integrity, Confidentiality, Availability

Threatened Sensitive data (e.g. passwords, private keys, subscription data, logs), VNFs/CNFs (Near RT
Assets RIC, O-CU, O-DU) related data

Affected Services SERV#01, SERV#03, SERV#04, SERV#05, SERV#06, SERV#07

REC-ISO Strong Isolation

REC-PHY Physical Security Protection

Potential
REC-IAM Identity, Authentication, and Access Management
mitigations
REC-CM Certificate management

REC-SS Secure Storage

0
1 Graz University of Technology (2018), Meltdown and Specter. [Online] Available at: https://meltdownattack.com

________________________________________________________________________________________________
© 2024 by the O-RAN ALLIANCE e.V. Your use is subject to the copyright statement on the cover page of this specification. 73
 O-RAN.WG11.O-CLOUD-Security-TR.0-R003-v06.00

2 Figure 7-22 : Illustration of a cross VM/Container side channel attack

Threat ID T-HW-02

Threat title MitM attacks on the interface between virtualization layer and hardware

An attacker can utilize the vulnerabilities of hardware (e.g. Meltdown and Specter of CPU in
Threat
host) to attack virtualization layer and/or VNFs/CNFs through this interface, resulting in
description
tampering, information disclosure or DoS.

Threat type Tampering, Information disclosure, Denial of Service

Vulnerabilities Insecure interfaces between HW and VL layers, lack of authentication, misconfiguration

Impact type Integrity, Confidentiality, Availability

Threatened
All assets
Assets

Affected Services All services

REC-PHY Physical Security Protection

Potential REC-NS Network Segmentation & Filter Network Traffic

mitigations REC-IAM Identity, Authentication, and Access Management

REC-CM Certificate management

5 7.2.4.7 Threats concerning O-Cloud management (SMO, NFO, FOCOM)

6

Threat ID T-ADMIN-01

Threat title Denial of service against NFO/FOCOM

Threat A denial-of-service attack against the NFO/FOCOM can interfere with the ability of operators
description to control and maintain their deployments. This can lead to the inability to react to changing
resource requirements. In addition, the NFO/FOCOM is the external API to interact with the O-

________________________________________________________________________________________________
© 2024 by the O-RAN ALLIANCE e.V. Your use is subject to the copyright statement on the cover page of this specification. 74
 O-RAN.WG11.O-CLOUD-Security-TR.0-R003-v06.00

Cloud platform. Thus, other services may become inaccessible as well. For example, operators
may be unable to retrieve logs, telemetry data. An attacker could use this opportunity to hide
additional attacks on VM/Container instances.

In addition, an attacker on the NFO/FOCOM could prevents the O-Cloud software update
(VNFs/CNFs, VL) to exploit a known security flaw in the O-Cloud software.

Threat type Denial of Service

Vulnerabilities Lack of authentication, vulnerable code exploits, design weakness, insecure O2 interface

Impact type Availability

Threatened VM/Container images, VNF/CNF, host OS, Hypervisor/Container Engine software

Assets

Affected Services SERV#02, SERV#05

Potential REC-IAM Identity, Authentication and Access Management

mitigations
REC-CM Certificate management

REC-AUD Security Audit

REC-SCONF Security Configuration

Threat ID T-ADMIN-02

Threat title Abuse an O-Cloud administration service

Threat Usually, the SMO including NFO/FOCOM is exposed to the tenant in a web front-end or REST
description API. In case these interfaces contain software vulnerabilities or implement authentication and
authorization insufficiently, an adversary would be able to gain access to the VM/Container
management and pose as a tenant. It is also possible that an adversary gains the ability to submit
requests without prior authentication and authorization.

The NFO/FOCOM interfaces encompass a great deal of privileges because anyone gaining
sufficient access is able to deploy new instances and disrupt existing O-Cloud services. It may
also be possible for an adversary to submit compromised VM/Container images that
unsuspecting tenants then use to initiate O-Cloud services. Moreover, adversaries can use the
same access to extract business data, configuration data, user data and possibly credentials. For
example, they may be able to create backups of VM/Container instances or they can export
VM/Container images. The impact of compromised credentials is exacerbated by the fact that
weak and insufficient safeguarding of credentials is recognized as one of the top threats in cloud
computing [i.38].

Container example: Adversaries may abuse a container administration service to execute

commands within a container. A container administration service such as the Docker daemon,
the Kubernetes API server, or the kubelet may allow remote management of containers within
an environment.

Container example: In Docker, adversaries may specify an entrypoint during container

deployment that executes a script or command, or they may use a command such as docker
exec to execute a command within a running container. In Kubernetes, if an adversary has
sufficient permissions, they may gain remote execution in a container in the cluster via

________________________________________________________________________________________________
© 2024 by the O-RAN ALLIANCE e.V. Your use is subject to the copyright statement on the cover page of this specification. 75
 O-RAN.WG11.O-CLOUD-Security-TR.0-R003-v06.00

interaction with the Kubernetes API server, the kubelet, or by running a command such as
kubectl exec.

Threat type Tampering, Information disclosure, Denial of Service and Elevation of privilege

Lack of authentication, secret exposure (insufficient safeguarding of credentials), vulnerable

Vulnerabilities
code exploits, design weakness

Impact type Integrity, Confidentiality, Availability, Authorization

Threatened
VNF/CNF, host OS, Hypervisor/Container Engine software and related information
Assets

Affected Services SERV#03, SERV#04, SERV#06, SERV#07

REC-NS Network Segmentation & Filter Network Traffic

REC-IAM Identity, Authentication, and Access Management

Potential REC-CM Certificate management

mitigations REC-AUD Security Audit

REC-SCONF Security Configuration

REC-VHPM Vulnerability Handling and Patch Management

2 7.2.4.8 Threats concerning Acceleration Abstraction Layer (AAL)

Threat ID T-AAL-01

Threat title Attacker exploits insecure API to gain access to hardware accelerator resources

Insecure AAL API allows an attacker to tamper the requests/responses sent between the AAL
components, the O-Cloud platform and O-RAN APPs/VNFs/CNFs.

For example, the attacker can tamper requests and services sent over AALI-C-Mgmt between
IMS and the hardware accelerator manager, hence capability of the hardware accelerator device,
fault information, logs, performance information and others are not as requested. This affects
Threat the normal operation of the O-Cloud, and even causes tampering.
description An attacker can tamper application (e.g. O-DU) requests sent over AALI-C-App to an AAL
implementation for allocation of buffers. This affects the normal operation of the applications,
and even causes tampering.

An attacker can tamper with application (e.g. O-DU) requests sent over AALI-P for configuring
and managing the AAL-LPU(s). This affects the normal operation of the applications, and even
causes tampering.

Threat type Tampering

Vulnerabilities Insecure AAL APIs and interfaces, lack of authentication and authorization

Impact type Integrity

Threatened A-OC-13 to A-OC-20

________________________________________________________________________________________________
© 2024 by the O-RAN ALLIANCE e.V. Your use is subject to the copyright statement on the cover page of this specification. 76
 O-RAN.WG11.O-CLOUD-Security-TR.0-R003-v06.00

Assets

Affected Services SERV#03, SERV#04, SERV#06, SERV#07

Potential REC-IAM Identity, Authentication and Access Management

mitigations REC-LOG Logging, Monitoring and Alerting

Threat ID T-AAL-02

Threat title Internal Overload DoS attack targeting AAL services

Overload situation could appear in the case of DoS attack or increased traffic on AAL
interfaces. Inability to mitigate traffic volumetric attacks on AAL affects availability of AAL
data and services.

Threat DoS attacks on the AALI-C interface affect the different services provided by the hardware
description accelerator manager and the transport abstraction framework.

DoS attacks on the AALI-P interface affect the configuration and management of AAL-LPU
(Acceleration Abstraction Layer Logical Processing Unit) by an application (e.g. O-DU) in
addition to acceleration functionality.

Threat type Denial of Service

Vulnerabilities Insecure AAL APIs and interfaces, lack of authentication and authorization

Impact type Availability

Threatened
A-OC-13 to A-OC-20
Assets

Affected Services SERV#03, SERV#04, SERV#06, SERV#07

Potential REC-IAM Identity, Authentication and Access Management

mitigations REC-LOG Logging, Monitoring and Alerting

Threat ID T-AAL-03

Threat title Fail to clear resources

Failure to clear accelerator resources after a process termination can cause an information
leakage and incorrect results for computations. Further, failure to release accelerator resources
Threat may prevent other processes from running.
description
This threat is relevant to accelerator resources either inside the hardware accelerator device
(internal memories, registers, cache) or in the O-Cloud memories used by accelerators.

Threat type Information disclosure, Denial of service

Lack of secure deletion of data after process termination, Insecure AAL APIs, Flaws in AAL
Vulnerabilities
design

Impact type Confidentiality, Availability

________________________________________________________________________________________________
© 2024 by the O-RAN ALLIANCE e.V. Your use is subject to the copyright statement on the cover page of this specification. 77
 O-RAN.WG11.O-CLOUD-Security-TR.0-R003-v06.00

Threatened
A-OC-13 to A-OC-20
Assets

Affected Services SERV#03, SERV#06, SERV#07

Potential
REC-LOG, REC-SS, REC-PHY, REC-SDD
mitigations

Threat ID T-AAL-04

Threat title HAM compromise

Threat A malicious actor can gain access to HAM to gain unauthorized access and control of the
description hardware accelerator device. This can result in the disruption of services (DoS) and tampering
of accelerator components, such as firmware, drivers which can cause the accelerator to behave
abnormally or crash altogether.

Threat type Tampering, Denial of service

Vulnerabilities Lack of access control, Insecure HAM APIs, Flaws in HAM design

Impact type Integrity, Availability

Threatened A-OC-13 to A-OC-20

Assets

Affected Services SERV#03, SERV#06, SERV#07

Potential REC-LOG, REC-SS, REC-PHY, REC-SDD

mitigations

Threat ID T-AAL-05

Threat title Malicious memory accesses

AAL that allows one process running on the hardware accelerator device to access memory
owned by another process running on the hardware accelerator device can leak information
(impact on confidentiality).

Similarly, AAL allowing concurrently executing processes to write to one another’s memory
Threat
may have correctness errors (impact on integrity).
description
If multiple processes are running concurrently and one is allowed to dominate accelerator
resources, the other may suffer from degraded performance. For example, if one process can
evict all cache entries belonging to the other, the victim will suffer performance penalties
(impact on availability).

Threat type Information disclosure, Tampering, Denial of service

Vulnerabilities Unrestricted memory access, Lack of access control, Insecure AAL APIs, Flaws in AAL design

Impact type Confidentiality, Integrity, Availability

________________________________________________________________________________________________
© 2024 by the O-RAN ALLIANCE e.V. Your use is subject to the copyright statement on the cover page of this specification. 78
 O-RAN.WG11.O-CLOUD-Security-TR.0-R003-v06.00

Threatened
A-OC-13 to A-OC-20
Assets

Affected Services SERV#03, SERV#06, SERV#07

Potential
REC-LOG, REC-SS, REC-PHY, REC-SDD, REC-ISO
mitigations

Threat ID T-AAL-06

Threat title Firmware attacks

Hardware accelerators often have their own firmware, which can be targeted by attackers. This
Threat could include modifying the firmware to introduce vulnerabilities (e.g., malware) or installing
description malicious firmware to extract/modify sensitive information or execute unauthorized actions
(e.g., control the device remotely).

Threat type Information disclosure, Tampering

Vulnerabilities Weak accelerator design, Misconfiguration, Insecure AAL/HAM APIs

Impact type Confidentiality, Integrity

Threatened
A-OC-13 to A-OC-20
Assets

Affected Services SERV#03, SERV#06, SERV#07

Potential
REC-LOG, REC-SS, REC-PHY, REC-SDD, REC-ISO
mitigations

3 7.2.4.9 Threats concerning O-Cloud instance ID

4

Threat ID T-O-CLOUD-ID-01

Threat title ID reuse in O-Cloud's object lifecycle

Threat In O-Cloud, objects such as Containers, Pods, Nodes, and Services are identified by their IDs
description within a given compute pool (e.g., cluster in Kubernetes). When an object is deleted, its ID
becomes available for reuse. This means that a new object can be created with the same ID as a
previously deleted object. If an object gets deleted but all its associated data isn't properly
isolated or cleaned, the ID, if reused, could lead to unintended data associations or leaks.

Potential consequences:

 Data Residue: A new object, reusing an ID, may inherit residual data or configurations
from its predecessor, leading to potential misconfigurations and incorrect data
associations. This can result in sensitive data exposure.

 Data Overwrite: Automated processes unaware of the deletion and subsequent

________________________________________________________________________________________________
© 2024 by the O-RAN ALLIANCE e.V. Your use is subject to the copyright statement on the cover page of this specification. 79
 O-RAN.WG11.O-CLOUD-Security-TR.0-R003-v06.00

recreation might mistakenly write or read data from the new object, thinking it's the
old one.

 Monitoring Ambiguities: Monitoring tools might combine metrics from the old and
new objects, resulting in confusing data.

 Operational Disruptions: The new object might operate based on the residual
configurations of the old object, potentially leading to system inefficiencies or failures.

Threat type Tampering, Information disclosure

Vulnerabilities Predictable ID generation, Insufficient logging or auditing, Insufficient ID validation

Impact type Integrity, Confidentiality

Threatened
A-OC-3, A-OC-9, A-OC-10
Assets

Affected Services SERV#04, SERV#05

Potential
REC-IDM O-Cloud ID secure management
mitigations

1
2
Threat ID T-O-CLOUD-ID-02

Threat title Node redundancy in O-Cloud deployments

Nodes in O-Cloud often represent physical or virtual machines. If a machine fails and is
replaced without deleting its corresponding Node object, and the new machine is given the same
ID or the hostname, O-Cloud might treat the new machine as if it were the original.

Potential consequences:

Threat  Resource Mismatch: The new host might have different resources (CPU, memory,
description storage) than the old one, leading to scheduling issues or resource constraints.

 Stale Data: The new node might inherit data or configurations from the old node,
leading to potential security or operational risks.

 Network Issues: Network configurations or IP address assignments might be

inconsistent or conflicting.

Threat type Spoofing, Tampering, Information disclosure, Denial of Service

Lack of node validation, Inadequate resource allocation and monitoring, Lack of network
Vulnerabilities
configuration verification

Impact type Authenticity, Integrity, Confidentiality, Availability

Threatened
A-OC-3, A-OC-9, A-OC-10
Assets

Affected Services SERV#04, SERV#05

Potential REC-IDM O-Cloud ID secure management

________________________________________________________________________________________________
© 2024 by the O-RAN ALLIANCE e.V. Your use is subject to the copyright statement on the cover page of this specification. 80
 O-RAN.WG11.O-CLOUD-Security-TR.0-R003-v06.00

mitigations

1
2
Threat ID T-O-CLOUD-ID-03

Threat title O-Cloud ID mismanagement

IDs are crucial for uniquely identifying objects within the O-Cloud. Mismanagement occurs
when these IDs are not properly assigned, tracked, or validated, leading to potential overlaps or
inconsistencies.

Potential consequences:

 ID Collision: Due to system glitches or bugs, two distinct objects could inadvertently
be allocated the same ID. Such an occurrence is termed an ID collision. This can result
in operations meant for one object inadvertently affecting the other.

 Resource Overwrite: If two objects share the same ID, updates or modifications
intended for one might overwrite the data of the other, leading to data
Threat
inconsistencies or loss.
description
 ID-Based Permissions: Many security protocols and access controls in O-Cloud can be
tied to object IDs. If an attacker can predict, guess, or manipulate the ID generation
process, they might gain unauthorized access to resources.

 Log Merging: Monitoring tools and logging systems use IDs to track events and
operations related to specific objects. If two objects share an ID, their logs might get
merged, making it challenging to trace events back to their source.

 RBAC Anomalies: Role-Based Access Control (RBAC) regulations attached to specific

object IDs could unintentionally approve or restrict access to the novel object due to
misidentification.

Spoofing, Tampering, Information Disclosure, Repudiation, Elevation of Privilege, Denial of

Threat type
Service

Inefficient ID assignment algorithm, Lack of validation checks during the ID assignment or

Vulnerabilities object creation process, Weak or absent monitoring of ID lifecycle, Insufficient randomization
in ID generation, Lack of timely updates to RBAC policies, Lack of ID collision detection

Impact type Authenticity, Integrity, Non-repudiability, Confidentiality, Availability, Authorization

Threatened
A-OC-3, A-OC-9, A-OC-10
Assets

Affected Services SERV#04, SERV#05

Potential
REC-IDM O-Cloud ID secure management
mitigations

3
4

________________________________________________________________________________________________
© 2024 by the O-RAN ALLIANCE e.V. Your use is subject to the copyright statement on the cover page of this specification. 81
 O-RAN.WG11.O-CLOUD-Security-TR.0-R003-v06.00

1 8 Recommendations and best practices

2 A large number of useful and relevant security guidelines and best practices exist that are relevant for VM/Container-
3 based virtualization and cloud computing in general. Therefore, we provide them here collectively and highly
4 recommend that readers consult them for additional references:

5  3GPP TS 33.848 Study on security impacts of virtualisation

6  MITRE containers matrix

7  CIS Critical Security Controls

8  CIS Docker Benchmark

9  CIS VMWARE Benchmark

10  ONAP master documentation

11  CISA/NSA Kubernetes security guidance

12  OpenStack security guide

13  Cloud native wiki by aqua

14  ANSSI “Recommandations de sécurité relatives aux déploiements de conteneur docker “

15  CISA/NSA “Security guidance for 5g cloud infrastructures” parts 1 to 4

16  GSMA NG.126 “Cloud Infrastructure Reference Model”

17  Docker best practices

18  FFTelecoms “Référentiel d'objectifs de sécurité en matière de fonctions réseau virtualisées “

19  Fraunhofer AISEC Threat analysis of container-as-a-service for network function virtualization

20 8.1 REC-CM Certificate management

21 Recommendation: O-Cloud should support Public Key Cryptography for the purpose of distributing Public Key
22 Certificates (PKC) for authenticating, authorizing, and encrypting links between components in O-Cloud. Each operator
23 should develop a Certificate Policy in accordance with their regional and national requirements. In addition, Operators
24 should setup a renewal procedure (preferably automatically) of certificates prior to their expiration.

25 In O-Cloud, the components to be issued certificates include:

26  O-Cloud and VNFs/CNFs should employ certificates which can be used for images signing and verification
27 during onboarding and registration.

28  SMO and VNF/CNF should employ certificates which can be used in order to establish secure connections
29 between them.

30  SMO employs certificates in order to establish secure management connections with NFO and FOCOM.

31  O-Cloud infrastructure employs certificate(s) in order to establish secure connections with NFO and FOCOM
32 through O2 interface.

33 Best practices to fulfill this recommendation:

________________________________________________________________________________________________
© 2024 by the O-RAN ALLIANCE e.V. Your use is subject to the copyright statement on the cover page of this specification. 82
 O-RAN.WG11.O-CLOUD-Security-TR.0-R003-v06.00

BP ID Description

REC-CM- The certificate policy should be consistent with the Internet X.509 Certificate Policy and
BP-1 Certification Practices Framework as defined in IETF RFC 3647 [i.9].

In order to eliminate or mitigate risks against attacks such as spoofing, tampering and information
REC-CM- disclosure, secure connection can be established on all the interfaces within O-Cloud. IPsec and TLS
BP-2 mechanisms are widely deployed to protect the communication between O-Cloud components using
certificates.

Certificate management in O-Cloud should be automated and manual operations should be avoided
REC-CM-
as much as possible. Automated certificate lifecycle management should be supported, i.e. creation,
BP-3
update and revocation of certificate.

It’s important to continuously monitor and audit certificates that are issued and active, with the
REC-CM- ability to generate audits and keep on top of expirations and renewals to avoid any disruption in O-
BP-4 Cloud services. Unknown, rogue or non-complaint certificates can result in an unexpected outage, or
worse, misuse that allows unintended access to O-Cloud components.

Securing the CAs that issue the certificates is critical. If a CA is compromised, attackers can issue
their own identities that will be trusted by default across O-Cloud, and this can be extremely costly to
REC-CM-
remediate, as it effectively invalidates every identity issued by that CA. Hardware devices such as
BP-5
HSMs should be used to secure CA certificates and keys, ensure robust protection and complete
visibility, policy enforcement, and automation for all certificates.

2 For more details see ETSI GR NFV-SEC 005 [i.10].

3 This recommendation can help to mitigate: T-GEN-02, T-GEN-04, T-VM-C-01, T-VM-C-02, T-VM-C-03, T-VM-
4 C-04, T-VM-C-05, T-IMG-01, T-IMG-02, T-IMG-04, T-VL-01, T-O2-01, T-OCAPI-01, T-HW-01, T-HW-02, T-
5 ADMIN-01, T-ADMIN-02

7 8.2 REC-NS Network Segmentation & Filter Network Traffic

8 Recommendation: Physical and logical segmentation to prevent access to potentially sensitive O-Cloud components
9 and information should be implemented. In addition, network policies should be defined to ensure a secure
10 communication between VMs/Containers and limit the communication between VMs/Containers as much as possible to
11 limit potential damage if a VM/Container is compromised.

12 Best practices to fulfill this recommendation:

BP ID Description

REC-NS-
Isolate O-Cloud infrastructure components that do not require broad network access.
BP-1

Configure access controls, network proxies, gateways, and firewalls to limit access to:

REC-NS-  Critical O-Cloud components. Most cloud environments support separate virtual private cloud
BP-2 (VPC) instances that enable further segmentation of cloud systems.

 Systems used to create and manage accounts.

________________________________________________________________________________________________
© 2024 by the O-RAN ALLIANCE e.V. Your use is subject to the copyright statement on the cover page of this specification. 83
 O-RAN.WG11.O-CLOUD-Security-TR.0-R003-v06.00

REC-NS- Follow best practices for network firewall and proxies configurations to allow only necessary ports
BP-3 and legitimate traffic to enter and exit the network.

Operate intrusion detection, analysis, and response systems on a separate network from the
REC-NS-
production environment to lessen the chances that an adversary can see and interfere with critical
BP-4
response functions.

Consider filtering DNS requests to unknown, untrusted, or known bad domains and resources.
REC-NS-
Resolving DNS requests with on-premise/proxy servers may also disrupt adversary attempts to
BP-5
conceal data within DNS packets.

REC-NS- Enforce proxies and use dedicated servers for services such as DNS and only allow those systems to
BP-6 communicate over respective ports/protocols, instead of all systems within a network.

Consider using IP allowlisting along with user account management to ensure that data access is
REC-NS-
restricted not only to valid users but only from expected IP ranges to mitigate the use of stolen
BP-7
credentials to access data.

REC-NS-
Apply extended ACLs to block unauthorized protocols outside the trusted network.
BP-8

Upon identifying a compromised network device being used to bridge a network boundary, block the
REC-NS- malicious packets using an unaffected network device in path, such as a firewall or a router that has
BP-9 not been compromised. Continue to monitor for additional activity and to ensure that the blocks are
indeed effective.

When flood volumes exceed the capacity of the network connection being targeted, it is typically
REC-NS- necessary to intercept the incoming traffic upstream to filter out the attack traffic from the legitimate
BP-10 traffic. Such defenses can be provided by the hosting Internet Service Provider (ISP) or by a 3rd
party such as a Content Delivery Network (CDN) or providers specializing in DoS mitigations.

REC-NS-
Filter network traffic to prevent use of protocols across the network boundary that are unnecessary.
BP-11

Use of network intrusion detection and prevention systems that can

REC-NS-  Identify traffic patterns and use network signatures to identify traffic for specific adversary
BP-12 malware, can be used to mitigate malicious activity at the network level.

 Detect and prevent remote service scans.

2 This recommendation can help to mitigate: T-GEN-02, T-GEN-06, T-VM-C-01, T-VM-C-02, T-VM-C-03, T-VM-
3 C-04, T-IMG-02, T-VL-01, T-O2-01, T-OCAPI-01, T-HW-02, T-ADMIN-02

4 8.3 REC-IAM Identity, Authentication and Access Management

5 Recommendation: A strong IAM framework should be in place to ensure authentication, authorization, accounting and
6 access control. It should be used to initiate, capture, record and manage user identities and their related access
7 permissions to O-Cloud assets in an automated way.

8 The IAM framework should be set up to manage and secure access to NFO/FOCOM, VNFs/CNFs, Host OS,
9 Hypervisor, Container Engine, data and services that reside in the O-Cloud. This framework should protect credentials
10 and accounts associated with O-Cloud platforms. Specifically, IAM protects root accounts for servers in the O-Cloud,

________________________________________________________________________________________________
© 2024 by the O-RAN ALLIANCE e.V. Your use is subject to the copyright statement on the cover page of this specification. 84
 O-RAN.WG11.O-CLOUD-Security-TR.0-R003-v06.00

1 limits privileged access to the O-Cloud control panel and governs ongoing access to privileged resources in the O-
2 Cloud.

3 IAM should be based on Authentication, Authorization, and Accounting (AAA) systems and least privileges approach
4 to limit actions administrators can perform and provide a history of user actions to detect unauthorized use and abuse.

5 Protocols without encryption/authentication mechanisms should not be used. Access to administrative and management
6 interfaces from untrusted network sources should be limited.

7 Best practices to fulfill this recommendation:

Req ID Description

OAuth2.0 with access token defined by IETF RFC 6749 [i.11] should be used for the authorization
of API request and notifications. There are several existing Access Token solutions. Such solutions
REC-IAM- are Openstack Keystone0, OpenID Connect0, 3GPP authorization framework ETSI TS 133 5010,
BP-1 IETF TLS-Based AccessToken Binding0 0.

For more details see ETSI GR NFV-SEC 022 [i.12].

REC-IAM- O-Cloud components must support authenticated and secure access to API, GUI and command line
BP-2 interfaces. In addition, they must support Traffic Filtering (for example, FireWall, IDS/IPS).

O-Cloud interfaces should support secure and encrypted communications, and confidentiality and
REC-IAM-
integrity of network traffic on all channels. All APIs access must use TLS protocol, including back-
BP-3
end APIs [i.45].

O-Cloud components should implement controls enforcing separation of duties and privileges, least
privilege use and least common mechanism (e.g. Role-Based Access Control).
REC-IAM-
Communication between different trust domains is not allowed, by default.
BP-4
The O-Cloud infrastructure must not allow the effect of an attack on one trust domain to impact the
other domains either directly or indirectly.

The O-Cloud should not reuse the same authentication credential (e.g., key-pair) on different
components (e.g., on different hosts, or different services).
REC-IAM-
The O-Cloud should protect all secrets by using strong encryption techniques and storing the
BP-5
protected secrets externally from the component.

The O-Cloud should provide secrets dynamically as and when needed.

Data Centre Operations staff and O-Cloud components should use management protocols that limit
REC-IAM-
security risk. Management protocols such as SNMPv3, SSH v2, ICMP, NTP, syslog, and TLS v1.2
BP-6
or higher.

REC-IAM- Remotely available services that may be unnecessary should be disabled or blocked. Remote access
BP-7 to internal O-Cloud systems should be controlled using centrally managed concentrators such as

0
1 https://docs.openstack.org/keystone/latest/admin/tokens.html

0
2 https://openid.net/specs/openid-connect-core-1_0.html

0
3 TSI TS 133 501: "5G; Security architecture and procedures for 5G System (3GPP TS 33.501)"

0
4 draft-ietf-oauth-token-binding-08: "OAuth 2.0 Token Binding", Work in progress

0
5 IETF RFC 8705: "OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens"

________________________________________________________________________________________________
© 2024 by the O-RAN ALLIANCE e.V. Your use is subject to the copyright statement on the cover page of this specification. 85
 O-RAN.WG11.O-CLOUD-Security-TR.0-R003-v06.00

VPNs and other managed remote access systems of network, proxies, gateways, and firewalls.

Strong two-factor or multi-factor authentication for remote service accounts to mitigate an

adversary's ability to leverage stolen credentials should be used.

REC-IAM-
Ensure VM/Containers are not running as root by default.
BP-8

Do not allow domain administrator accounts to be used for day-to-day operations that may expose
REC-IAM- them to potential adversaries on unprivileged systems.
BP-9 Consider using temporary credentials for accounts that are only valid for a certain period of time to
reduce the effectiveness of compromised accounts.

REC-IAM- Limit access to the root account and prevent users from loading kernel modules and extensions
BP-10 through proper privilege separation and limiting Privilege Escalation opportunities.

Container: Run the microservice with the least privilege possible; First, never use the --privileged
flag. It gives all so-called capabilities to the container, and it can access host devices (/dev)
REC-IAM-
including disks, and also has access to the /sys and /proc filesystem. And with a little work the
BP-11
container can even load kernel modules on the host0. The good thing is that containers are per
default unprivileged. You would have to configure them explicitly to run privileged.

When PowerShell is necessary, restrict PowerShell execution policy to administrators. Be aware

REC-IAM-
that there are methods of bypassing the PowerShell execution policy, depending on environment
BP-12
configuration.

Least privilege principles:

 Use the principal of least privilege and protect administrative access to domain trusts such as
the service account in Kubernetes, Openstacks, etc. to limit impact of exploitation.
REC-IAM-
BP-13  Restrict administrator accounts to as few individuals as possible, following least privilege
principles.

 Limit permissions associated with creating and modifying images or VMs/Containers based on
the principle of least privilege.

REC-IAM-
Prevent credential overlap across systems of administrator and privileged accounts.
BP-14

Ensure critical system files as well as those known to be abused by adversaries have restrictive
REC-IAM-
permissions and are owned by an appropriately privileged account, especially if access is not
BP-15
required by users nor will inhibit system functionality.

Audit domain and local accounts as well as their permission levels routinely to look for situations
REC-IAM- that could allow an adversary to gain wide access by obtaining credentials of a privileged account.
BP-16 These audits should also include if default accounts have been enabled, or if new local accounts are
created that have not been authorized.

Do not put user or admin domain accounts in the local administrator groups across systems unless
REC-IAM-
they are tightly controlled, as this is often equivalent to having a local administrator account with
BP-17
the same password on all systems.

0
1 https://www.cyberark.com/threat-research-blog/how-i-hacked-play-with-docker-and-remotely-ran-code-on-the-host/

________________________________________________________________________________________________
© 2024 by the O-RAN ALLIANCE e.V. Your use is subject to the copyright statement on the cover page of this specification. 86
 O-RAN.WG11.O-CLOUD-Security-TR.0-R003-v06.00

REC-IAM-
Do not allow remote access to services as a privileged account unless necessary.
BP-18

REC-IAM-
Do not allow remote access via SSH as root or other privileged accounts.
BP-19

REC-IAM- Restrict execution of particularly vulnerable binaries to privileged accounts or groups that need to
BP-20 use it to lessen the opportunities for malicious usage.

Ensure that any accounts used by third-party providers to access these systems are traceable to the
third-party and are not used throughout the network or used by other third-party providers in the
REC-IAM- same environment. Ensure there are regular reviews of accounts provisioned to these systems to
BP-21 verify continued business need and ensure there is governance to trace de-provisioning of access
that is no longer required. Ensure proper system and access isolation for critical network systems
through use of account privilege separation.

REC-IAM- A Cloud Access Security Broker (CASB) can be used to set usage policies and manage user
BP-22 permissions on cloud applications to prevent access to application access tokens.

Password policy

 O-Cloud components that utilize default username and password should be changed
immediately after the installation, and before deployment to a production environment.
When possible, passwords should be updated periodically and properly secured. (Refer to
NIST guidelines when creating password policies NIST Special Publication 800-63B 0, CIS
Password Policy Guide0).

 Use strong passwords to increase the difficulty of credential hashes from being cracked if
they are obtained.

 Do not reuse local administrator account passwords across systems. Ensure password
complexity and uniqueness such that the passwords cannot be cracked or guessed.

REC-IAM-  In case SSH is used with password (not recommended), Ensure SSH key pairs have strong
BP-23 passwords and refrain from using key-store technologies such as ssh-agent unless they are
properly protected.

 Consider rotating access keys within a certain number of days to reduce the effectiveness
of stolen credentials.

 Use strong passphrases for private keys to make cracking difficult. Do not store credentials
within the Registry. Establish an organizational policy that prohibits password storage in
files.

 Ensure that cloud accounts, particularly privileged accounts, have complex, unique
passwords across all systems on the network. Passwords and access keys should be rotated
regularly. This limits the amount of time credentials can be used to access resources if a
credential is compromised without your knowledge. Cloud service providers may track
access key age to help audit and identify keys that may need to be rotated.

0
1 https://pages.nist.gov/800-63-3/sp800-63b.html

0
2 https://www.cisecurity.org/white-papers/cis-password-policy-guide

________________________________________________________________________________________________
© 2024 by the O-RAN ALLIANCE e.V. Your use is subject to the copyright statement on the cover page of this specification. 87
 O-RAN.WG11.O-CLOUD-Security-TR.0-R003-v06.00

1 This recommendation can help to mitigate: T-GEN-02, T-GEN-04, T-VM-C-01, T-VM-C-02, T-VM-C-03, T-VM-
2 C-04, T-VM-C-05, T-IMG-01, T-IMG-02, T-IMG-04, T-VL-01, T-O2-01, T-OCAPI-01, T-HW-01, T-HW-02, T-
3 ADMIN-01, T-ADMIN-02

4 8.4 REC-VHPM Vulnerability Handling and Patch Management

5 Recommendation: A vulnerability handling process should be in place to find potentially exploitable software
6 vulnerabilities, to determine what types and levels of threat may use software exploits and 0-days against O-Cloud and
7 to remediate them.

8 A patch management process should be implemented to check unused dependencies, unmaintained and/or previously
9 vulnerable dependencies, unnecessary features, components, files, and documentation.

10 Best practices to fulfill this recommendation:

BP ID Description

Regularly scan O-Cloud software components for vulnerabilities and establish procedures to
REC-VHPM-
rapidly patch systems when critical vulnerabilities are discovered through scanning and through
BP-1
public disclosure.

REC-VHPM- Regularly scan the internal network for available services to identify new and potentially vulnerable
BP-2 services.

REC-VHPM- Continuous monitoring of vulnerability sources and the use of automatic and manual code review
BP-3 tools should also be implemented as well.

Patch strategy shall be applied for each component to maintain the O-Cloud software infrastructure.

The patch strategy should handle regular and emergency patches. It is also needed to be prepared
for testing patches and rollback procedures. The patch strategy should be automated. It's also
recommended to make use of plugins for monitoring software and notifying of pending patches.

Keep in mind that some patches require a restart of their service, a new deployment (VM/Container
image) or even a reboot (host) to become effective. If this won't be done, patching otherwise could
be as effective as just not to patch. Technical details when to restart a service, a host or initiate a
REC-VHPM-
new deployment need to be defined in the patch strategy too.
BP-3
There are four different patch domains:

 Images: the VM/Container distribution

 Hypervisor/Container Engine software: e.g. VMWARE, Docker

 Orchestration software (Kubernetes, Mesos, OpenShift, ...)

 Host operating system

Maintain SBOMs for O-RAN software components in a centralized repository. This will make
possible to quickly scan and search the SBOM for any Zero-Day vulnerability when get disclosed,
REC-VHPM-
which allows O-Cloud operator to respond quickly to the Zero-day vulnerability to mitigate
BP-4
potential attacks. For more details about SBOM see Clause 4 ‘SBOM Guidelines for O-RAN’ in
[i.42].

11

12 This recommendation can help to mitigate: T-GEN-01, T-IMG-01, T-VL-01, T-ADMIN-02, T-O2-01, T-OCAPI-01
________________________________________________________________________________________________
© 2024 by the O-RAN ALLIANCE e.V. Your use is subject to the copyright statement on the cover page of this specification. 88
 O-RAN.WG11.O-CLOUD-Security-TR.0-R003-v06.00

1 8.5 REC-SCONF Security Configuration

2 Recommendation: The O-Cloud virtualization layer shall

3  Be configured to ensure conformance to industry standard benchmarks and requirements with respect to
4 security configurations.

5  Use automated or manual mechanisms to detect configuration drifts/misconfigurations from industry standard
6 benchmarks and requirements.

7 Best practices to fulfill this recommendation:

BP ID Description

O-Cloud virtualization layer should be configured to adhere/conform to industry standard

benchmarks and guidelines for securing the virtualization layer. For example, the CIS benchmark
guidelines enforce many security configurations related to the container deployment like:

 Avoid running containers as privileged, apply the principle of least privilege access controls
REC-SCONF- for privileged containers, and restrict functionality of privileged containers.
BP-1
 Restrict containers from using hostPath volume mounts write permissions from within
container.

 Enforce non-root default user in containers (using Kubernetes pod spec parameters or USER
directive in Dockerfile).

O-Cloud operator & vendor should perform automated or manual scans to check security posture
REC-SCONF-
adherence to industry standard benchmarks. For example, Cloud Security Posture Management
BP-2
tools can be used to check conformance to industry standard benchmarks like CIS, NIST, etc.

O-Cloud CNF vendors should define the CPU and Memory requirements of their CNF applications,
ie, the CPU and Memory requirements for the CNF applications to perform its functions under
REC-SCONF- normal operating scenarios and the threshold limit value of CPU & Memory requirements beyond
BP-3 which the CNF should not be allowed to use. O-Cloud virtualization platform should consider the
CPU & Memory resource requirements & limits associated to each CNF provided by O-Cloud CNF
vendors during onboarding of the CNFs.

O-Cloud virtualization platform should consider enforcing the O-Cloud CNF vendors to specify the
REC-SCONF- CPU & Memory resource requirements & limits using suitable admission controller solutions.
BP-4 Setting CPU & memory limits will help OCloud virtualization platform to avoid a rogue CNF
container using up all resources thereby starving off other co-located CNF containers.

9 This recommendation can help to mitigate: T-VM-C-01, T-VM-C-02, T-VM-C-06, T-VL-01, T-ADMIN-01, T-
10 ADMIN-02

11 8.6 REC-SDLC Secure Development Lifecycle

12 Recommendation: Software providers should assume that their VNFs/CNFs and VL software contain flaws and have
13 appropriate processes in place to mitigate these cases. To this end, they should adopt a secure software development
14 life-cycle (S-SDLC). A S-SDLC integrates security considerations into the normal software development life-cycle.
15 This ensures that risks, threats, and security mechanisms are formalized alongside the development of VNFs/CNFs and
16 VL.

________________________________________________________________________________________________
© 2024 by the O-RAN ALLIANCE e.V. Your use is subject to the copyright statement on the cover page of this specification. 89
 O-RAN.WG11.O-CLOUD-Security-TR.0-R003-v06.00

1 Best practices to fulfill this recommendation:

Req ID Description

Define and implement good coding practices. This includes writing documentation, adopting secure
programming guidelines, enforcing code quality metrics and performing software tests. In
REC-SDLC-
particular, code quality and adherence to coding standards can be checked automatically with tools,
BP-1
such as SonarQube0. With this approach, the chance of introducing easily exploitable vulnerabilities
into the code is reduced.

Modern continuous integration (CI) and continuous delivery (CD) systems can be used to build
new container images from code repositories, such as Git0 automatically. Thus, every commit can
be used to generate a new container image that is immediately deployed for testing in a
REC-SDLC-
development environment. Once a new software version passes all tests, it can be deployed
BP-2
automatically to the O-Cloud platform. This step should be safeguarded by an internal approval
process. For example, operators can configure their CI/CD pipeline to only start deployment in
production after quality assurance, security testing and operations have approved the new version.

During development, developers may include private keys and configuration files with passwords
into their VM/Container images for convenience and testing reasons. However, this information
should never be published in a production VM/Container image. Thus, one of important step before
REC-SDLC-
actually deploying any VM/Container image to the O-Cloud platform is to verify that no sensitive
BP-3
information is included. In case of Docker, recent versions allow to specify these image differences
between development and operations by using multiple FROM commands, i.e., one for
development and one production in the respective Dockerfile.

Define mechanisms and processes that ensure that VM/Container image metadata is signed and
REC-SDLC- verified. Thus, if operators download an image from a party they trust, they can verify the signature
BP-4 and the cryptographic hashes of the image files.

Example: use of Docker Notary and Content Trust0

3 This recommendation can help to mitigate: T-GEN-01, T-IMG-01, T-IMG-03

4 8.7 REC-SNFLC Security App/VNF/CNF lifecycle

5 Recommendation: Security in the life cycle management of Apps/VNFs/CNFs should be integrated during
6 development, onboarding, instantiation, scaling, migration, and termination. Security lifecycle management must be
7 adapted to work in a more dynamic environment with fast-changing network topology, data flow paths, and network
8 addresses.

9 Best practices to fulfill this recommendation:

Req ID Description

REC-SNFLC- Before an App/VNF/CNF is deployed, the NFO/FOCOM system should verify compliance with its
BP-1 build-configuration standards. A check can include but is not limited to:

0
1 http://sonarqube.org

0
2 https://git-scm.com

0
3 https://docs.docker.com/engine/security/trust/content_trust/

________________________________________________________________________________________________
© 2024 by the O-RAN ALLIANCE e.V. Your use is subject to the copyright statement on the cover page of this specification. 90
 O-RAN.WG11.O-CLOUD-Security-TR.0-R003-v06.00

 Security of the configuration

 Whether the package contains only trusted and expected components

 Whether trusted components have been altered (integrity)

Apps/VNFs/CNFs can easily be cloned and instantiated. As a result, a security framework must
address the following elements:

 Depending on the migration technique, certificates, accounts, media access control addresses,
REC-SNFLC-
or hardware IDs will look identical after cloning.
BP-2
 Trusted platform modules (e.g., TPM, HSM, Intel’s Trusted Execution Technology, or TXT)
may be required to ensure that virtual components can provide attestation or a true status of the
security of the underlying hardware and physical location.

2 This recommendation can help to mitigate: T-GEN-03, T-VM-C-01, T-VM-C-02, T-VM-C-04, T-VM-C-06

3 8.8 REC-IMGP Image Protection

4 Recommendation: Only images from secure and trusted sources should be used. These images should be scanned to
5 ensure that images do not contain vulnerable software.

6 The App/VNF/CNF images shall not be packaged with embedded secrets such as passwords or credentials, or any other
7 critical configuration data.

8 During the onboarding, the authenticity and integrity of the VNF Package should be verified against the signature
9 provided by the VNF provider. Furthermore, Operators should undertake additional security validation of the VNF
10 Package during the onboarding process and operator's signing should be used to certify the VNF as authorized to
11 onboard into the operator's network [i.46], [i.47].

12 Best practices to fulfill this recommendation:

13 Image Scanning

14 Scanning process needs to identify when Apps/VNFs/CNFs are running with out-of-date packages that need to be
15 updated for security patches. Further, it should identify malware that has been built into an image. The O-Cloud VL
16 should enforce image scans to check and flag the presence of secrets in images.

17 (1) VM/Container images need to be frequently scanned throughout the lifecycle of the App/VNF/CNF

During Development Within the registry Before Deployment During Runtime

Perform frequent Regular scan for Perform frequent scanning for Perform continuous
scanning for known App/VNF/CNF image known vulnerability or scanning/monitoring for
vulnerability or known vulnerability or misconfiguration on known vulnerability or
misconfiguration on misconfiguration stored in App/VNF/CNF image before misconfiguration on
App/VNF/CNF image the registry. E.g., scan for deployment using admission runtime workloads,
during build phase. new vulnerabilities after control techniques. Admission check for any open
E.g., Check for built. controller could block deployments ports, VM/Container
malware, secrets if the image doesn’t comply with escape.
stored in image. the operator security policies e.g.,
Responsible: O-RAN To check the images used to create
Ideal to automate with CNF pods are secure by checking
Solution
________________________________________________________________________________________________
© 2024 by the O-RAN ALLIANCE e.V. Your use is subject to the copyright statement on the cover page of this specification. 91
 O-RAN.WG11.O-CLOUD-Security-TR.0-R003-v06.00

CI pipeline. Provider/Vendor/Operator for malware. Responsible:

Operator/O-Cloud
Ideal to automate with CD Operator
pipeline.
Responsible: O-RAN
Solution
Provider/Vendor
Responsible: O-RAN Solution
Provider/Vendor/Operator

2 (2) As part of O-RAN App/VNF/CNF development, O-RAN Solution Provider/Vendor is recommended to choose
3 base images and packages used in the O-RAN App/VNF/CNF from a trusted publisher or create in-house base
4 images. Choosing trusted signed images helps to mitigate MITM attacks that can introduce vulnerabilities into
5 the base images available in public registries.

6 (3) As part of O-RAN App/VNF/CNF development, O-RAN Solution Provider/Vendor is recommended to choose
7 minimal base images that bundle only the necessary system tools and libraries required by O-RAN
8 App/VNF/CNF, to limit the attack surface of O-RAN App/VNF/CNF.

10 App/VNF/CNF Image Signing

11 Responsible: App/VNF/CNF Solution Provider/Vendor and/or Operator

12 (1) App/VNF/CNF Solution Provider creates public/private key pair for code signing.

13 (2) CA verifies public key belong to the owner and issue CA certificate with attached public key.

14 (3) Hash function on App/VNF/CNF Image returns image Digest.

15 (4) Image Digest is encrypted with private key.

16 (5) Signed App/VNF/CNF Image contains CA Certificate, Digest, Hash function.

17

18 App/VNF/CNF Image Verification

19 Responsible: Operator or O-Cloud Operator

20 (1) Verify CA certificate for authenticity.

21 (2) Decrypt digest with public key

22 (3) Compare Decrypted digest with Digest computed as result of Hash function on App/VNF/CNF Image.

23 (4) Verification is successful if both digest matches.

24

25 Proposed Signing/Verification Models

26 1. Software signing by Solution Provider/Vendor, Software verification at runtime by O-Cloud Operator

27 2. Software signing by Solution Provider/Vendor, Software verification by operator before onboarding vendor
28 images to the operator registry

________________________________________________________________________________________________
© 2024 by the O-RAN ALLIANCE e.V. Your use is subject to the copyright statement on the cover page of this specification. 92
 O-RAN.WG11.O-CLOUD-Security-TR.0-R003-v06.00

1 3. Software signing by Operator, Software verification at runtime by O-Cloud Operator

2 4. Software signing by Solution Provider/Vendor, Software verification at runtime by O-Cloud Operator and/or
3 Operator.

4 5. Software signing by solution provider/vendor, Software verification by Operator and software re-signing by
5 Operator before onboarding vendor images to the operator registry, software verification at instantiation.

6 Other best practices:

7  Least privilege access that limits and controls access to the images’ repository and the repository of source code,
8 secure storage, and automation for verifying the configuration of images before loading.

9  Utilize a trust model such as Docker Content Trust with digital signatures to ensure runtime verification of the
10 integrity and publisher of specific image tags.

11  Implement only digitally signed host images to validate the integrity of the software used on the O-Cloud platform.
12 Make use of this feature where possible in order to prevent and/or detect attempts by adversaries to compromise the
13 host image.

14  The registry is most sensitive part of the system and should be run in an HSM.

15  The App/VNF/CNF images shall not be packaged with embedded secrets such as passwords or credentials, or any
16 other critical configuration data. Secrets have to be stored outside the App/VNF/CNF images. For example, K8s
17 secrets or external secrets managers (like Vault) can be used to store secret and sensitive information hence
18 preventing the threat of packaging secrets in CNF container images. Secrets required by containerized applications
19 can be injected into the CNF container from the External Secrets Manager as required.

20  Encrypting VNF volume / swap areas: Virtual volume disks associated with VNFs may contain sensitive data.
21 Therefore, they need to be protected. The best practice to secure the VNF volume is by encrypting them and storing
22 the cryptographic keys at safe locations. The TPM module can also be used to securely store these keys. In
23 addition, the hypervisor should be configured to securely wipe out the virtual volume disks in the event a VNF is
24 crashed or intentionally destroyed to prevent it from unauthorized access. VM swapping is a memory management
25 technique used to move memory segments from the main memory to disk, which is used as a secondary memory in
26 order to increase system performance in case the system runs out of memory. These transferred memory segments
27 can contain sensitive information such as passwords and certificates. They can be stored on the disk and remain
28 persistent even after system reboot. This enables an attack scenario whereby a VM swap is copied and investigated
29 to retrieve any useful information. One way to avoid this kind of attack is to encrypt VM swap areas. Linux based
30 tools such as dm-crypt can be used for this purpose.

31 This recommendation can help to mitigate: T-GEN-01, T-GEN-03, T-IMG-01, T-IMG-02, T-IMG-03, T-IMG-04

32 8.9 REC-LOG Logging, Monitoring and Alerting

33 Recommendation: The continuous security of O-Cloud software (running VNFs/CNFs, Hypervisor/Container Engine,
34 Host OS, NFO/FOCOM) depends on the ability to identify attacks and reconstruct them. The earlier operators identify
35 suspicious behavior and possible attacks, the faster they can initiate countermeasures. In the best case, they are able to
36 stop attacks before severe harm is done. In the worst case, they at least are able to reduce the attacks’ severity and
37 collect important details on the attack itself. This knowledge is important to find and fix flaws and vulnerabilities to
38 prevent similar attacks in the future. Therefore, a key activity is to perform logging, monitoring and alerting.

39 The importance increases because of the dynamic VM/Container deployment. VMs/Containers may be started when
40 demand arises and then quickly be terminated once they are no longer required. Furthermore, the focused nature of
41 VMs/Containers and the application of a microservice architecture means that there are more systems to monitor. As a

________________________________________________________________________________________________
© 2024 by the O-RAN ALLIANCE e.V. Your use is subject to the copyright statement on the cover page of this specification. 93
 O-RAN.WG11.O-CLOUD-Security-TR.0-R003-v06.00

1 result, monitoring and logging must handle this dynamic landscape and be able to collect data from many systems at
2 once.

3 Best practices to fulfill this recommendation:

Req ID Description

Any change to the O-Cloud components must be logged as a security event, and the logged event
REC-LOG-
must include the identity of the entity making the change, the change, the date and the time of the
BP-1
change.

REC-LOG-
Security logs should be time synchronized and regularly scanned for events of interest.
BP-2

REC-LOG- Consider monitoring for the presence or loading of known vulnerable software that adversaries may
BP-3 drop and exploit to execute code in kernel mode.

Monitor for the deployment of suspicious or unknown container images and pods in your
environment, particularly containers running as root. Additionally, monitor for unexpected usage of
REC-LOG-
syscalls such as mount (as well as resulting process activity) that may indicate an attempt to escape
BP-4
from a privileged container to host. In Kubernetes, monitor for cluster-level events associated with
changing containers' volume configurations.

Establish centralized logging for the activity of container and Kubernetes cluster components. This
REC-LOG-
can be done by deploying logging agents on Kubernetes nodes and retrieving logs from sidecar
BP-5
proxies for application pods to detect malicious activity at the cluster level.

Monitor logs for actions that could be taken to gather information about container infrastructure,
REC-LOG- including the use of discovery API calls by new or unexpected users. Monitor account activity logs
BP-6 to see actions performed and activity associated with the Kubernetes dashboard and other web
applications.

Consider monitoring process resource usage to determine anomalous activity associated with
malicious hijacking of resources such as CPU, memory, and graphics processing resources.
REC-LOG-
Monitor for suspicious use of network resources associated with cryptocurrency mining software.
BP-7
Monitor for common cryptomining software process names and files on local systems that may
indicate compromise and resource usage.

Container administration service activities and executed commands can be captured through
logging of process execution with command-line arguments on the container and the underlying
REC-LOG-
host. In Docker, the daemon log provides insight into events at the daemon and container service
BP-8
level. Kubernetes system component logs may also detect activities running in and out of containers
in the cluster.

Monitor interactions with images and containers by users to identify ones that are added or
REC-LOG- modified anomalously. In containerized environments, changes may be detectable by monitoring
BP-9 the Docker daemon logs or setting up and monitoring Kubernetes audit logs depending on registry
configuration.

Monitor for suspicious or unknown container images and pods in your environment. Deploy
logging agents on Kubernetes nodes and retrieve logs from sidecar proxies for application pods to
REC-LOG-
detect malicious activity at the cluster level. In Docker, the daemon log provides insight into remote
BP-10
API calls, including those that deploy containers. Logs for management services or applications
used to deploy containers other than the native technologies themselves should also be monitored.

REC-LOG- Monitor for unexpected Docker image build requests to the Docker daemon on hosts in the
________________________________________________________________________________________________
© 2024 by the O-RAN ALLIANCE e.V. Your use is subject to the copyright statement on the cover page of this specification. 94
 O-RAN.WG11.O-CLOUD-Security-TR.0-R003-v06.00

environment. Additionally monitor for subsequent network communication with anomalous IPs that
BP-11
have never been seen before in the environment that indicate the download of malicious code.

REC-LOG- Alert the incident responders about a breach / attack on the O-Cloud software via email, SMS or
BP-12 other notification mechanisms.

REC-LOG- Alert using a notification to RASP (Runtime application self-protection) modules, or a SIEM about
BP-13 a breach / attack on the O-Cloud software.

2 This recommendation can help to mitigate: T-GEN-01, T-GEN-02, T-GEN-03, T-GEN-06, T-VM-C-02, T-VM-C-
3 03, T-VM-C-04, T-VM-C-05, T-VM-C-06, T-IMG-01, T-IMG-02, T-IMG-04, T-VL-02

4 8.10 REC-SB Secure Boot

5 Recommendation: All servers that are part of O-Cloud Infrastructure should support a root of trust and secure boot to
6 trust that the running host OS, Hypervisor/Container Engine and VNFs/CNFs code were loaded.

7 Best practices to fulfill this recommendation:

Req ID Description

Using trusted platform module (TPM) as a hardware root of trust, the measurement of system
sensitive components such as platform firmware, BIOS, bootloader, OS kernel, and other system
components can be securely stored and verified. The platform measurement can only be taken when
REC-SB-BP-1
the system is reset or rebooted; there is no way to write the new platform measurement in TPM
during the system run-time. The validation of the platform measurements can be performed by
TPM’s launch control policy (LCP) or through the remote attestation server.

9 For more details see ETSI GR NFV-SEC 007 [i.15].

10 This recommendation can help to mitigate: T-GEN-03, T-IMG-04, T-VL-01, T-VL-02

11 8.11 REC-ISO Strong Isolation

12 Recommendation: Strong VNFs/CNFs sandboxing, isolation and segmentation should be enforced to make difficult
13 for adversaries to advance their operation through exploitation of undiscovered or unpatched vulnerabilities. O-Cloud
14 virtualization layer shall adopt measures to ensure strong VM/Container isolation among VM/Container workloads to
15 limit the impact of rogue/misbehaving VM/Container on other co-hosted VMs/Containers.

16 Best practices to fulfill this recommendation:

Req ID Description

In order to prevent privilege escalations, Operators shall ensure that CNFs shall:

REC-ISO-BP-  Avoid using binaries with SUID or SGID bit. Instead, specific capabilities required by the
1 files/binaries should be provided using Linux Capabilities set

 Avoid root user and sudo privileges within container

REC-ISO-BP- Restrict the damage attackers can do once they successfully escaped a container. Again, the Linux

________________________________________________________________________________________________
© 2024 by the O-RAN ALLIANCE e.V. Your use is subject to the copyright statement on the cover page of this specification. 95
 O-RAN.WG11.O-CLOUD-Security-TR.0-R003-v06.00

kernel provides a couple of security features that can be used to restrict user actions. Among them
2
are Linux security modules providing mandatory access control and user namespaces themselves.

Restrict the large system call interface using seccomp. The seccomp (’Secure Computing’)
integrates a BPF-like filter mechanism for system calls into the Linux kernel. This can be used to
REC-ISO-BP-
reduce the number of system calls that a container can effectively use. Moreover, the parameters to
3
system calls can be sanitized. Thus, seccomp reduces one attack surface by reducing the number of
exploitable system calls.

Linux kernel allows to restrict users’ capabilities to perform specific operations. In particular, root
users have a vast set of permissions. Linux capabilities permit a fine-grained partition of the
capabilities bundled into the root user. Thus, instead of being root, different capabilities can be
restricted. For example, a user can be root without having the permissions to change network
REC-ISO-BP- settings. Currently, the Linux kernel has 37 capabilities. Unfortunately, not all capabilities have a
4 specific, well-defined scope. For example, CAP_SYS_PTRACE permits the use of ptrace(), while
CAP_SYS_ADMIN comprises many permissions such as changing the host and domain name,
using mount() and umount(), or performing various configurations of storage and memory devices.
Restricting capabilities assigned to container processes limits the operations an adversary can use
on the host system.

Namespaces and cgroups are the two features that enable container-based virtualization in the
Linux kernel. They provide isolation and separation of processes. However, their default
configuration is often not as restrictive as possible to support many use cases. Thus, it is important
to employ many namespaces and cgroups and tighten their configuration.
REC-ISO-BP-
5 For example, the user namespace separates the user IDs on the host system from the user IDs of a
container. A user within the container can be root, while on the host system the same user is
unprivileged. As another example, the devices control group can restrict what device nodes can be
created and be accessed. Other control groups limit the maximum resources a container can use.
Thus, they prevent degradation or denial of services in a shared environment.

Linux security modules (LSM) are software components that use a well-defined kernel interface to
control and decline certain operations. In particular, LSMs providing mandatory access control
(MAC) define rules that further restrict what files a process can access. Two well-known LSM
MACs are AppArmor and SELinux. These MACs define policy rules about what a process can and
cannot access. The resulting policies are then enforced by the kernel. Thus, adversaries are on the
one side further limited on the resources that are exploitable. On the other hand, they have to invest
additional time and resources to circumvent and disable the LSMs.

So far, these security mechanisms mostly protect the host from containers. If a container is
compromised, an adversary still has to put in the additional effort to compromise the host.
REC-ISO-BP-
However, these protections may not circumvent exploits across containers on the same host. For
6
example, containers on the Docker engine share a common user namespace and storage space for
the container images. Thus, an adversary escaping one container may have access to the container
images of another container. This can be used to manipulate images and introduce persistent threats
or steal information. One safeguard against these cross-container exploitations are extended
features of LSM MACs known as multi category security. Using MCS, every container gets a
unique identity when it is initialized. Based on this unique identity, the kernel can perform more
fine-grained access decisions because two process executing the same binary that would usually
have the same policy are now distinguishable.

As a result, access to container specific resources can be restrict for each container.

REC-ISO-BP- It is important to secure remote access to the host and containers themselves. While not going into

________________________________________________________________________________________________
© 2024 by the O-RAN ALLIANCE e.V. Your use is subject to the copyright statement on the cover page of this specification. 96
 O-RAN.WG11.O-CLOUD-Security-TR.0-R003-v06.00

the details of full network security in a cloud environment, each container and host must be
protected as part of the security-in-depth approach. On Linux systems, netfilter/iptables and
ebtables can be used to create packet firewalls. They limit network access to exposed ports on the
host and in the containers. Similar to virtual switches in hypervisors, containers can be connected
7
by a Linux bridge device. Platforms such as Docker use a default bridge device for all containers if
no separate network is specified during container initiation. As a result, containers may share a
common network segment, which can be exploited. Therefore, ebtables is recommended as an
additional firewall configured for the bridge device.

Stronger isolation mechanisms to keep application code constrained within a VM/Container. Such
REC-ISO-BP- solutions include the private cloud, physical separation.
8 For containers, many security solutions0 are used for ensuring strong isolation of resources, such as
LXC, LXD, Singularity, Docker (runc), Kata-containers (kata-runtime), and gVisor (runsc).

REC-ISO-BP- Shared cache memory partitioning or isolation and assigning of a separate portion of cache memory
9 to each VM can reduce or eliminate successful side channel attacks in a virtualized environment 0.

2 This recommendation can help to mitigate: T-GEN-01, T-VM-C-01, T-VM-C-02, T-VM-C-05, T-VL-01, T-HW-01

3 8.12 REC-AUD Security Audit

4 Recommendation: Periodic audit and scan should be conducted of:

5  The integrity of images and VM/Containers used in O-Cloud deployments to ensure they have not been
6 modified to include malicious software.

7  Accounts and privileges for images repositories.

8  All accounts, access lists and the privileges they have been granted to access O-Cloud components and images
9 repositories.

10 Best practices to fulfill this recommendation:

Req ID Description

Scan code repositories for exposed credentials or other sensitive information. Preemptively search
REC-AUD-
for files containing passwords or other credentials and take actions to reduce the exposure risk
BP-1
when found.

REC-AUD-
Suspicious accounts/credentials should be investigated and removed.
BP-2

Routinely check account role permissions to ensure only expected users and roles have permission
REC-AUD-
to modify cloud firewalls, to modify cloud compute infrastructure components, create snapshots
BP-3
and backups, and to create/delete new instances.

11

12 This recommendation can help to mitigate: T-GEN-01, T-GEN-02, T-VM-C-05, T-IMG-01, T-IMG-03, T-IMG-04,
13 T-ADMIN-01, T-ADMIN-02
0
1 Olivier Flauzac, Fabien Mauhourat, Florent Nolot, A review of native container security for running applications, Procedia Computer Science, Volume 175, 2020, Pages 157-
2 164, ISSN 1877-0509, https://doi.org/10.1016/j.procs.2020.07.025. “A review of native container security for running applications “

0
3 https://arxiv.org/pdf/1606.01356.pdf

________________________________________________________________________________________________
© 2024 by the O-RAN ALLIANCE e.V. Your use is subject to the copyright statement on the cover page of this specification. 97
 O-RAN.WG11.O-CLOUD-Security-TR.0-R003-v06.00

1 8.13 REC-SS Secure Storage

2 Recommendation: The O-Cloud infrastructure should support encrypted storage, for example, block, object, file
3 storage, credentials, and secrets with access to encryption keys restricted based on a need to know.

4 Best practices to fulfill this recommendation:

Req ID Description

REC-SS-BP-1 Controlled Access Based on the Need to Know should be implemented0.

When possible, store keys on separate cryptographic hardware (e.g. HSM, TPM) instead of on the
REC-SS-BP-2
local system.

Use best practices for authentication protocols, such as OAuth 2.0, and ensure traffic that may
REC-SS-BP-3
contain credentials is protected by TLS.

REC-SS-BP-4 Set up monitoring to track access to cache data and identify any unauthorized access attempts.

Establish policies for cache data lifecycle, including how long data should be retained in cache and
REC-SS-BP-5
when it should be purged.

6 This recommendation can help to mitigate: T-GEN-06, T-VM-C-01, T-VM-C-02, T-VM-C-03, T-VM-C-06, T-IMG-
7 03, T-IMG-03, T-VL-01, T-OCAPI-01, T-HW-01

8 8.14 REC-PHY Physical Security Protection

9 Recommendation: Physical security protection measures should be considered to deny unauthorized access to O-Cloud
10 facilities, equipment and resources.

11 Best practices to fulfill this recommendation:

Req ID Description

Reduce the hardware platform (computing platform based for example on the x86 hardware
REC-PHY- architecture (32bit or 64bit), similar servers) attack surface by removing unneeded interfaces.
BP-1 Example: Wireless interfaces (e.g., WiFi, 4G), if present, should remain optional for the platform
REC-PHY-BP-1 [i.41].

Enforce protection of the main memory against untrusted peripherals.

REC-PHY- Example: The hardware platform exposes an input/output memory management unit, such as VT-x
BP-2 (Intel) or AMD-V (AMD). This feature needs to be enabled by default and can only be disabled by
the owner of the hardware platform (not the user) [i.41].

REC-PHY- Ensure the security hardware component quality.

BP-3
Example: In case the platform embeds a TPM, the latter is certified (e.f. from a Common Criteria
perspective according to the Protection Profile TCG Protection Profile PC Client Specific TPM
Family 2.0) [i.41].

0
1 https://www.cisecurity.org/controls/cis-controls-list/

________________________________________________________________________________________________
© 2024 by the O-RAN ALLIANCE e.V. Your use is subject to the copyright statement on the cover page of this specification. 98
 O-RAN.WG11.O-CLOUD-Security-TR.0-R003-v06.00

Only the owner of the hardware platform (not the user) can enable and disable the TPM.

Ensure the hardening of the platform against persistent compromises.

Example: hardware platform firmwares are expected to ensure their integrity by means of state-of-
the-art security mechanisms. This notably includes protecting integrity of the code and data stored
REC-PHY- on the Flash Memory. The modification of firmware code should only be the result of a legitimate,
BP-4 signed update using robust cryptographic protocols. The installation of a signed update older than
the version currently installed on the hardware platform shall be considered illegitimate by default.
However, for the latter case, the firmware configuration interface shall allow the platform owner to
disable this protection.

Ensure the presence of minimal security features within the firmware (Low-level software
components shipped with the hardware platform, including UEFI and legacy BIOSes or hardware
components embedded software).

Example: The firmware configuration interface provides the following features [i.41]:

 Protecting the access to the firmware configuration interface thanks to a dedicated password
REC-PHY-
BP-5  Locking the boot sequence of the platform thanks to a dedicated password

 Enabling and disabling input/output interfaces (e.g. USB)

 Configuring the boot order (the ordering of the list of devices checked by the BIOS to boot an
operating system)

 Replacing default Secure Boot keys with custom keys generated by the owner

Allow for inspecting and auditing firmware code.

REC-PHY-
BP-6 Example: Mechanisms which prevent firmware code inspection shall be absent or disabled by
default.

Data centre physical security protections based on its location and such risk assessments, to
REC-PHY-
determinate the structures, and data centre support systems (sensors, video camera, alarms to a
BP-7
Security Operation Centre…)

REC-PHY-
Backup system in other area if needed.
BP-8

REC-PHY-
Enforcing Multi-Factor Authentication for privileged users could be a mitigation.
BP-9

REC-PHY-
Server cabinets fitted with an electronic lock.
BP-10

REC-PHY-
Physical Access Control based system with video and entry logs system.
BP-11

REC-PHY-
Sensors on the room or the cabinet to generate alarms to the Network / Security Operation Centre.
BP-12

REC-PHY-
Limited number of physical interfaces on the on-board NIC of the server and remotely control NIC.
BP-13

________________________________________________________________________________________________
© 2024 by the O-RAN ALLIANCE e.V. Your use is subject to the copyright statement on the cover page of this specification. 99
 O-RAN.WG11.O-CLOUD-Security-TR.0-R003-v06.00

REC-PHY-
Secure All Endpoints (terminal, physical connectivity…).
BP-14

REC-PHY- Zero trust architecture with security layers including physical access and redundancies, with regular
BP-15 security audit if needed.

2 This recommendation can help to mitigate: T-VM-C-03, T-VM-C-05, T-VL-02, T-OCAPI-01, T-HW-01, T-HW-02

3 8.15 REC-RA Remote Attestation

4 Recommendation: A remote attestation (RA) approach should be used to determine the trustworthiness of O-Cloud
5 components. It is a defensive measure that addresses the malicious software execution. In O-Cloud it is obvious the
6 need for applying procedures to verify the integrity of the whole O-Cloud service deployment by the appropriate
7 attestation of the O-Cloud architectural elements, including software and firmware images and associated supporting
8 security sub-systems that will run to instantiate individual VNFs/CNFs and their composition into a O-Cloud service.

9 The remote attestation requires identifying the root(s) of trust, establishing a chain of trust for the O-Cloud
10 infrastructure, the VL, VNFs/CNFs, and the NFO/FOCOM sub-systems, and verification of the trust chain, so the
11 NFO/FOCOM components can verifiably establish a sufficient level of assurance in the different software elements
12 constituting the VNFs/CNFs and the service(s) that use them.

13 The remote attestation (RA) capabilities should be used to realize trust establishment in the following use case
14 scenarios:

15 1. Measurement of VM/Container during launch.

16 2. Protected VM/Container launch on a trusted O-Cloud platform

17 3. Measurement of VM/Container during launch and while in use

18 4. Remote attestation of secret storage

19 5. Secure VM/Container migration between two trusted O-Cloud platform

20 Best practices to fulfill this recommendation:

Req ID Description

REC-RA-BP- ETSI GR NFV-SEC 018 [i.13], [i.14], ETSI GR NFV-SEC 007 [i.15] could be used as a security
1 guidance of the remote attestation (RA) approach.

REC-RA-BP- All servers part of O-Cloud infrastructure should support measured boot and an attestation server
2 that monitors the measurements of the servers.

21

22 Example: Operators might use RA to assess if the overall O-Cloud infrastructure is trustworthy, datacenters might use
23 RA to assess trustworthiness of subsystems they use, and management entities might use RA to assess the
24 trustworthiness of individual infrastructural components. Hence, there are numerous use-cases and scenarios that might
25 be considered where attestation is a fundamental step of creating an overall trustworthy system.

26 A trustworthy element is the entity which has a component that provides a unique identifier, certification (e.g. through
27 cryptographic signing) and which is able to store measurements and data about the state of that element (including
28 related sub-elements or dependent elements if necessary) in a tamperproof and verifiable form. For example, the
29 TPM2.0 quoting mechanism using the TPMS_ATTEST data structure is an example of this.
________________________________________________________________________________________________
© 2024 by the O-RAN ALLIANCE e.V. Your use is subject to the copyright statement on the cover page of this specification. 100
 O-RAN.WG11.O-CLOUD-Security-TR.0-R003-v06.00

1 This recommendation can help to mitigate: T-GEN-03, T-VM-C-04, T-IMG-04, T-VL-02

2 8.16 REC-SDD Secure data deletion

3 Recommendation: The O-Cloud platform should delete cryptographic keys and sensitive data using a secure deletion
4 method from both active and backup storage systems.

5 Best practices to fulfill this recommendation:

BP ID Description

REC-SDD- Review the CSP’s policies and SLAs on data deletion to ensure it has a procedure that effectively
BP-1 deletes data.

REC-SDD- Secure overwriting is way to overwrite on existing data to be deleted by new data, replaced with zero
BP-2 or random.

REC-SDD- Cryptography method to encrypt the data before storing to the cloud storage. In order to delete the
BP-3 data, the encryption key is being destroyed. This makes the data unrecoverable.

Each data center adheres to a strict disposal policy and uses the techniques described to achieve
REC-SDD-
compliance with NIST SP 800-88 Revision 1 “Guidelines for Media Sanitization” [i.48] and DoD
BP-4
5220.22-M “National Industrial Security Program Operating Manual.” [i.49].

REC-SDD- Physically destroy media that cannot be sanitized by either crush and deform the drive or shred the
BP-5 drive into small pieces.

REC-SDD-
Limit access to data backups (through use of roles) to know who has access to the data.
BP-6

Enable application deployment using a security policy where volumes containing sensitive data
REC-SDD-
mounted by the O-Cloud infrastructure to the application, are unmounted after application
BP-7
initialization guard timer, or based on application state monitoring.

REC-SDD- Enable applications to delete application sensitive data from their memory / filesystems based on a
BP-8 trigger from O-Cloud infrastructure.

REC-SDD- Enable RASP modules to notify applications to delete application sensitive data from their memory /
BP-9 filesystems based on a trigger from O-Cloud infrastructure.

7 This recommendation can help to mitigate: T-GEN-05, T-GEN-06, T-VM-C-03

9 8.17 REC-IDM O-Cloud ID secure management

10 Recommendation: To counter threats associated with ID reuse, mismanagement, and redundancy, the O-Cloud should
11 employ robust strategies for ID generation, validation, and lifecycle management. Properly managed IDs reduce risks of
12 data inconsistencies, unauthorized access, and operational inefficiencies.

13 Best practices to fulfil this recommendation:

BP ID Description

________________________________________________________________________________________________
© 2024 by the O-RAN ALLIANCE e.V. Your use is subject to the copyright statement on the cover page of this specification. 101
 O-RAN.WG11.O-CLOUD-Security-TR.0-R003-v06.00

REC-IDM-BP-01 Adopt the UUID generation method in line with RFC 4122 standards within the O-Cloud system.
Ensure each newly created object, whether Containers, Pods, Nodes, or Services, is assigned a
unique UUID upon its instantiation. Utilize reputable UUID generation libraries or modules to
ensure adherence to the standard.

REC-IDM-BP-02 Implement validation mechanisms ensuring each ID's uniqueness during assignment.

REC-IDM-BP-03 Use database-level constraints to ensure ID uniqueness across the O-Cloud.

REC-IDM-BP-04 Monitor the lifecycle of each ID, providing a clear history of its assignment and usage.

REC-IDM-BP-05 Implement automated processes to detect and remove defunct node objects.

REC-IDM-BP-06 Audit node resources before ID assignment and raise alerts on mismatches.

REC-IDM-BP-07 Use configuration management tools to maintain node consistency.

REC-IDM-BP-08 Employ dynamic IP management systems to ensure consistent IP assignments.

REC-IDM-BP-09 Ensure monitoring tools can differentiate between data from old and new IDs.

REC-IDM-BP-10 Notify users/systems when an ID is reused, alerting them of potential ambiguities.

REC-IDM-BP-11 Centralize logging systems with distinct identifiers for each ID.

REC-IDM-BP-12 Regularly update and audit RBAC policies to ensure they reflect current ID assignments.

REC-IDM-BP-13 Before reusing any ID, ensure that the lifecycle of the previous object associated with that ID has
been completely terminated.

REC-IDM-BP-14 For any ID that's about to be reused, conduct thorough data cleaning processes to remove all
residual data and configurations associated with its predecessor.

2 This recommendation can help to mitigate: T-O-CLOUD-ID-01, T-O-CLOUD-ID-02, T-O-CLOUD-ID-03

3

4 8.18 REC-IDM Identity management for O-Cloud elements

5 O-RAN Applications hosted on O-Cloud, Services provided by O-Cloud and O-Cloud Nodes use an identity, such as an
6 identifier in an X.509 certificate, for authentication and authorization. To establish consistent and standardized identities
7 throughout O-Cloud, it is essential to implement a uniform identity provider.

8 The incorporation of an Identity Provider framework ensures uniform identity management that provides strong attested
9 identities, through a combination of diverse attestation mechanisms, for the various elements in O-cloud environment
10 and addresses the threats of Identity spoofing, unauthorized access, inadequate verification of the trustworthiness of
11 entities.

12 Recommendation: SPIRE and SPIFFE are CNCF graduated projects that effectively act as an identity provider for
13 workloads and has been specified in NIST SP 800-207A [i.58] which mentions that “service identity should not be

14 subjected to spoofing and should be continuously verifiable. An example of workload identity is a SPIFFE ID which is
15 encoded as a Uniform Resource Identifier (URI) and carried in a cryptographically verifiable document called a SPIFFE
16 Verifiable Identity Document (SVID)”.

________________________________________________________________________________________________
© 2024 by the O-RAN ALLIANCE e.V. Your use is subject to the copyright statement on the cover page of this specification. 102
 O-RAN.WG11.O-CLOUD-Security-TR.0-R003-v06.00

1 SPIFFE provides a structured ID format for applications in RFC 3986 URI format. The SPIFFE ID adheres to NIST
2 SP 800-207A (Zero Trust Architecture Model for Access Control in Cloud-Native Applications) as mentioned above.

3 SPIFFE Runtime Environment (SPIRE), a production-ready implementation of SPIFFE APIs use Node and
4 workload attestation to securely issue SVID [X.509 certificate with SPIFFE ID][i.55] to Applications which can be
5 used for service-service communication.

6 In O-Cloud, services and workloads can be dynamically scaled up, down and scheduled, SPIRE provides a secure way
7 to verify the identity of these dynamically changing entities, ensuring that services can trust one another in such
8 environments.

9 SPIFFE and SPIRE, as a part of O-Cloud Infrastructure enable services and applications to obtain identity (SPIFFE ID
10 [i.57]) and SVID [X.509 certificate with SPIFFE ID] using attestation policies.

11
12 Fig 8.18-1: SPIRE Architecture in O-Cloud

13 SPIRE Architecture: A SPIRE deployment is composed of one or more SPIRE Servers and one or more SPIRE
14 Agents.

15 SPIRE Server: A SPIRE Server is responsible for managing and issuing all identities in its configured SPIFFE trust
16 domain. It stores registration entries [i.54] (which specify the selectors that determine the conditions under which a
17 particular SPIFFE ID should be issued) and signing keys, uses node attestation [i.54] to authenticate agents' identities
18 automatically, and creates SVIDs for workloads when requested by an authenticated agent.

19 SPIRE Agents: A SPIRE Agent runs on every O-Cloud node on which an identified workload runs. The agent
20 performs the following tasks:

________________________________________________________________________________________________
© 2024 by the O-RAN ALLIANCE e.V. Your use is subject to the copyright statement on the cover page of this specification. 103
 O-RAN.WG11.O-CLOUD-Security-TR.0-R003-v06.00

1  Requests SVIDs from SPIRE server and caches them until a workload requests its SVID.
2  Exposes the SPIFFE Workload API to workloads on node and attests the identity of workloads that call it.
3  Provides SVIDs to the identified workloads.
4

5 Best practices to fulfil this recommendation:

BP ID Description

REC-IDM-SPR- Adopt a uniform standardized identity that follow the URI specification as defined by RFC 3986
01 for all elements within the O-Cloud.

spiffe://domain/clusterName/namespace/WL-identity

REC-IDM-SPR- The SPIFFE Verifiable Identity Document (SVID) is cryptographically verifiable document can
02 be issued either by SPIRE server locally or through an external Certificate Authority.

REC-IDM-SPR- Agent and server architecture model as defined in SPIFFE and SPIRE Concepts [i.54] to be
03 implemented in O-Cloud platform.

REC-IDM-SPR- O-Cloud exposes the SPIRE APIs through which identity may be retrieved and/or issued to
04 Applications or services.

REC-IDM-SPR- Registration entries maps an identity -- in the form of a SPIFFE ID -- to a set of properties known
05 as selectors that the workload must possess to be issued a particular identity.

For SPIRE to identify an O-Cloud element, it is essential to register the O-Cloud elements with
the SPIRE Server, via registration entries.

SMO can use the O2ims interface to push the registration entries for O-Cloud Nodes, Network
Functions to the SPIRE server present as part of the O-Cloud platform.

REC-IDM-SPR- Attestation Policies are enforced for asserting the identity of O-Cloud elements by gathering
06 attributes and comparing them to a set of selectors defined in the Registration entries.

Node Attestation [i.56] ensures agent authenticate and verify itself when it first connects to a
server.

Workload Attestation verifies the identity of the elements by querying information about the
process from the node and comparing it with the selectors provided in the Registration entries.

REC-IDM-SPR- SPIRE server as part of O-Cloud platform does issuance of SVID and required trust bundle to O-
07 Cloud elements after successful assertion.

7 This recommendation can help to mitigate: T-O-CLOUD-ID-01, T-O-CLOUD-ID-03

8
9

10 9 Risk Assessment
11 The risk assessment of the identified threats against O-Cloud is provided in the O-RAN Security Threat Modeling and
12 Risk Assessment [i.50].
________________________________________________________________________________________________
© 2024 by the O-RAN ALLIANCE e.V. Your use is subject to the copyright statement on the cover page of this specification. 104
 O-RAN.WG11.O-CLOUD-Security-TR.0-R003-v06.00

1 Annex A (informative): Best practices from some of existing

2 main security guidance
3 Operators, O-Cloud vendors and Cloud providers should ensure that O-Cloud components and interfaces are secure
4 under very strict set of security best practices. Such security guidance include:

5  A.1 CISA/NSA Kubernetes security hardening best practices [i.3]

6  A.2 CIS Docker security best practices [i.18]

7  A.3 ONAP VNFs security best practices [i.24]

8 A.1 CISA/NSA Kubernetes security hardening best practices

9 This section summarizes recommendations and best practices from the CISA/NSA Kubernetes Hardening Guidance.
10 The report details recommendations to harden Kubernetes systems. Primary actions include the scanning of containers
11 and Pods for vulnerabilities or misconfigurations, running containers and Pods with the least privileges possible, and
12 using network separation, firewalls, strong authentication, and log auditing. To ensure the security of applications,
13 system administrators should keep up to date with patches, updates, and upgrades to minimize risk. NSA and CISA also
14 recommend periodic reviews of Kubernetes settings and vulnerability scans to ensure appropriate risks are accounted
15 for and security patches are applied.

16 Download the full Kubernetes Hardening Guidance:

17 https://media.defense.gov/2021/Aug/03/2002820425/-1/-1/1/CTR_KUBERNETES%20HARDENING
18 %20GUIDANCE.PDF

19 Kubernetes Pod security

20 Pods are the smallest deployable Kubernetes unit and consist of one or more containers. Pods are often a cyber actor’s
21 initial execution environment upon exploiting a container. For this reason, Pods should be hardened to make
22 exploitation more difficult and to limit the impact of a successful compromise.

23 “Non-root” containers: Preventing root execution by using non-root containers limits the impact of a container
24 compromise. container engines allow containers to run applications as a non-root user with non-root group membership.
25 Typically, this non-default setting is configured when the container image is built. Having non-root execution integrated
26 at build time provides better assurance that applications will function correctly without root privileges. (See Appendix
27 A in [i.3]).

28 Immutable container file systems: By default, containers are permitted mostly unrestricted execution within their own
29 context. A cyber actor who has gained execution in a container can create files, download scripts, and modify the
30 application within the container. Kubernetes can lock down a container’s file system, thereby preventing many post-
31 exploitation activities. However, these limitations also affect legitimate container applications and can potentially result
32 in crashes or anomalous behavior. To prevent damaging legitimate applications, Kubernetes administrators can mount
33 secondary read/write file systems for specific directories where applications require write access. (See Appendix B in
34 [i.3]).

35 Building secure container images: Container images are usually created by either building a container from scratch or
36 by building on top of an existing image pulled from a repository. In addition to using trusted repositories to build
37 containers, image scanning is key to ensuring deployed containers are secure. Throughout the container build workflow,
38 images should be scanned to identify outdated libraries, known vulnerabilities, or misconfigurations, such as insecure
39 ports or permissions. One approach to implementing image scanning is by using an admission controller [i.3]. This

________________________________________________________________________________________________
© 2024 by the O-RAN ALLIANCE e.V. Your use is subject to the copyright statement on the cover page of this specification. 105
 O-RAN.WG11.O-CLOUD-Security-TR.0-R003-v06.00

1 admission controller could block deployments if the image doesn’t comply with the organization’s security policies
2 defined in the webhook configuration0.

3 Hardening container engines: Some platforms and container engines provide additional options to harden the
4 containerized environments. A powerful example is the use of hypervisors to provide container isolation. Hypervisors
5 rely on hardware to enforce the virtualization boundary rather than the operating system. Hypervisor isolation is more
6 secure than traditional container isolation. Container engines running on the Windows operating system can be
7 configured to use the built-in Windows hypervisor, Hyper-V, to enhance security. Additionally, some security focused
8 container engines natively deploy each container within a lightweight hypervisor for defense-in-depth. Hypervisor-
9 backed containers mitigate container breakouts.

10 Network separation and hardening

11 Cluster networking is a central concept of Kubernetes. Communication between containers, Pods, services, and external
12 services must be taken into consideration. Resource separation and encryption can be an effective way to limit a cyber
13 actor’s movement and escalation within a cluster.

14 Namespaces: Kubernetes namespaces are one way to partition cluster resources among multiple individuals, teams, or
15 applications within the same cluster (See [i.3] for more details).

16 Network policies: Network policies control traffic flow between Pods, namespaces, and external IP addresses. By
17 default, no network policies are applied to Pods or namespaces, resulting in unrestricted ingress and egress traffic within
18 the Pod network. Pods become isolated through a network policy that applies to the Pod or the Pod’s namespace. Once
19 a Pod is selected in a network policy, it rejects any connections that are not specifically allowed by any applicable
20 policy object. (See Appendix E in [i.3] for more details).

21 Resource policies: In addition to network policies, LimitRange and ResourceQuota are two policies that can limit
22 resource usage for namespaces or nodes. A LimitRange policy constrains individual resources per Pod or container
23 within a particular namespace, e.g., by enforcing maximum compute and storage resources. ResourceQuotas are
24 restrictions placed on the aggregate resource usage for an entire namespace, such as limits placed on total CPU and
25 memory usage. If a user tries to create a Pod that violates a LimitRange or ResourceQuota policy, the Pod creation fails.
26 (See Appendixes F and G in [i.3] for more details).

27 Control plane hardening: The control plane is the core of Kubernetes and gives users the ability to view containers,
28 schedule new Pods, read Secrets, and execute commands in the cluster. Because of these sensitive capabilities, the
29 control plane should be highly protected. In addition to secure configurations such as TLS encryption, RBAC, and a
30 strong authentication method, network separation can help prevent unauthorized users from accessing the control plane.
31 The Kubernetes API server should be protected (e.g. by firewall, TLS encryption) and not be exposed to the Internet or
32 an untrusted network.

33 Worker node segmentation: A worker node can be a virtual or physical machine, depending on the cluster’s
34 implementation. Because nodes run the microservices and host the web applications for the cluster, they are often the
35 target of exploits. If a node becomes compromised, an administrator should proactively limit the attack surface by
36 separating the worker nodes from other network segments that do not need to communicate with the worker nodes or
37 Kubernetes services. A firewall can be used to separate internal network segments from the external facing worker
38 nodes or the entire Kubernetes service depending on the network. Examples of services that may need to be separated
39 from the possible attack surface of the worker nodes are confidential databases or internal services that would not need
40 to be internet accessible.

41 Encryption: Administrators should configure all traffic in the Kubernetes cluster—including between components,
42 nodes, and the control plane—to use TLS 1.2 or 1.3 encryption. Encryption can be set up during installation or

0
1 The Linux Foundation, "11 Ways (Not) to Get Hacked," 18 07 2018 https://kubernetes.io/blog/2018/07/18/11-ways-not-to-get-hacked/#10- scan-images-and-run-ids.

________________________________________________________________________________________________
© 2024 by the O-RAN ALLIANCE e.V. Your use is subject to the copyright statement on the cover page of this specification. 106
 O-RAN.WG11.O-CLOUD-Security-TR.0-R003-v06.00

1 afterward using TLS bootstrapping, detailed in the Kubernetes documentation 0, to create and distribute certificates to
2 nodes. For all methods, certificates must be distributed amongst nodes to communicate securely.

3 Secrets: Kubernetes Secrets maintain sensitive information, such as passwords, OAuth tokens, SSH and TLS keys.
4 Secrets can be encrypted by configuring data-at-rest encryption on the API server or by using an external Key
5 Management Service (KMS), which may be available through a cloud provider. (See Appendixes H and I in [i.3] for
6 more details).

7 Protecting sensitive cloud infrastructure: Kubernetes is often deployed on virtual machines in a cloud environment. As
8 such, administrators should carefully consider the attack surface of the virtual machines on which the Kubernetes
9 worker nodes are running. In many cases, Pods running on these virtual machines have access to sensitive cloud
10 metadata services on a non-routable address. These metadata services provide cyber actors with information about the
11 cloud infrastructure and possibly even short-lived credentials for cloud resources. Cyber actors abuse these metadata
12 services for privilege escalation. Kubernetes administrators should prevent Pods from accessing cloud metadata services
13 by using network policies or through the cloud configuration policy. Because these services vary based on the cloud
14 provider, administrators should follow vendor guidance to harden these access vectors.

15 Authentication and authorization

16 Authentication and authorization are the primary mechanisms to restrict access to cluster resources. Cyber actors can
17 scan for well-known Kubernetes ports and access the cluster’s database or make API calls without being authenticated
18 if the cluster is misconfigured. User authentication is not a built-in feature of Kubernetes. However, several methods
19 exist for administrators to add authentication to a cluster.

20 Authentication: Kubernetes clusters have two types of users: service accounts and normal user accounts. Service
21 accounts handle API requests on behalf of Pods. Authentication is typically managed automatically by Kubernetes
22 through the ServiceAccount Admission Controller using bearer tokens. The bearer tokens are mounted into Pods at
23 well-known locations and can be used from outside the cluster if the tokens are left unsecured. Because of this, access
24 to Pod Secrets should be restricted to those with a need to view them using Kubernetes RBAC. For normal users and
25 admin accounts, there is no automatic authentication method for users. Administrators must add an authentication
26 method to the cluster to implement authentication and authorization mechanisms. The Kubernetes documentation 0 lists
27 several ways to implement user authentication including client certificates, bearer tokens, authentication plugins, and
28 other authentication protocols. At least one user authentication method should be implemented. Administrators should
29 not use weak methods such as static password files. Weak authentication methods could allow cyber actors to
30 authenticate as legitimate users.

31 Role-based access control: RBAC is one method to control access to cluster resources based on the roles of individuals
32 within an organization. RBAC is enabled by default in Kubernetes version 1.6 and newer. Privileges assigned to users,
33 groups, and service accounts should follow the principle of least privilege, giving only required permissions to
34 resources. Users or user groups can be limited to particular namespaces where required resources reside. By default, a
35 service account is created for each namespace for Pods to access the Kubernetes API. RBAC policies can be used to
36 specify allowed actions from the service accounts in each namespace. Access to the Kubernetes API is limited by
37 creating an RBAC Role or ClusterRole with the appropriate API request verb and desired resource on which the action
38 can be applied. Tools exist that can help audit RBAC policies by printing users, groups, and service accounts with their
39 associated assigned Roles and ClusterRoles. (See Appendixes J and K in [i.3] for more details).

40 Log auditing

41 Logs capture activity in the cluster. Auditing logs is necessary, not only for ensuring that services are operating and
42 configured as intended, but also for ensuring the security of the system. Systematic audit requirements mandate
43 consistent and thorough checks of security settings to help identify compromises. Kubernetes is capable of capturing

0
1 https://kubernetes.io/docs/tasks/administer-cluster/securing-a-cluster/

0
2 https://kubernetes.io/docs/reference/access-authn-authz/authentication

________________________________________________________________________________________________
© 2024 by the O-RAN ALLIANCE e.V. Your use is subject to the copyright statement on the cover page of this specification. 107
 O-RAN.WG11.O-CLOUD-Security-TR.0-R003-v06.00

1 audit logs for cluster actions and monitoring basic CPU and memory usage information; however, it does not natively
2 provide in-depth monitoring or alerting services.

3 Logging: System administrators running applications within Kubernetes should establish an effective logging,
4 monitoring, and alerting system for their environment. Logging Kubernetes events alone is not enough to provide a full
5 picture of the actions occurring on the system. Logging should also be performed at the host level, application level, and
6 on the cloud if applicable. These logs can then be correlated with any external authentication and system logs as
7 applicable to provide a full view of the actions taken throughout the environment for use by security auditors and
8 incident responders. Within the Kubernetes environment, administrators should monitor/log the following:

9  API request history

10  Performance metrics

11  Deployments

12  Resource consumption

13  Operating system calls

14  Protocols, permission changes

15  Network traffic

16  Pod scaling

17 When a Pod is created or updated, administrators should capture detailed logs of the network communications, response
18 times, requests, resource consumption, and any other relevant metrics to establish a baseline.

19 RBAC policy configurations should be audited periodically and whenever changes occur to the organization’s system
20 administrators.

21 Audits of internal and external traffic logs should be conducted to ensure all intended security constraints on
22 connections have been configured properly and are working as intended.

23 Logs can be streamed to an external logging service to ensure availability to security professionals outside of the
24 cluster, identify abnormalities as close to real time as possible, and protect logs from being deleted if a compromise
25 occurs. If using this method, logs should be encrypted during transit with TLS 1.2 or 1.3 to ensure cyber actors cannot
26 access the logs in transit and gain valuable information about the environment. (See Appendixes L and M in [i.3] for
27 more details).

28 SIEM platforms: Security Information and Event Management (SIEM) software collects logs from across an
29 organization’s network. SIEM software brings together firewall logs, application logs, and more; parsing them out to
30 provide a centralized platform from which analysts can monitor system security. SIEM tools have variations in their
31 capabilities. Generally, these platforms provide log collection, threat detection, and alerting capabilities. Some include
32 machine learning capabilities, which can better predict system behavior and help to reduce false alerts. Organizations
33 using these platforms in their environment can integrate them with Kubernetes to better monitor and secure clusters.
34 Open-source platforms for managing logs from a Kubernetes environment exist as an alternative to SIEM platforms.

35 Alerting: Kubernetes does not natively support alerting; however, several monitoring tools with alerting capabilities are
36 compatible with Kubernetes. If Kubernetes administrators choose to configure an alerting tool to work within a
37 Kubernetes environment, there are several metrics for which administrators should monitor and configure alerts.
38 Examples of cases that could trigger alerts include but are not limited to:

39  Low disk space on any of the machines in the environment,

40  Available storage space on a logging volume running low,

________________________________________________________________________________________________
© 2024 by the O-RAN ALLIANCE e.V. Your use is subject to the copyright statement on the cover page of this specification. 108
 O-RAN.WG11.O-CLOUD-Security-TR.0-R003-v06.00

1  External logging service going offline,

2  A Pod or application running with root permissions,

3  An anonymous account being used or gaining privileges,

4  Unusual system calls or failed API calls,

5  user/admin behavior that is abnormal (i.e. at unusual times or from an unusual location), and

6  Significant deviations from the standard operation metrics baseline.

7 Service meshes: Service meshes are platforms that streamline microservice communications within an application by
8 allowing for the logic of these communications to be coded into the service mesh rather than within each microservice.
9 Coding this communication logic into individual microservices is difficult to scale, difficult to debug as failures occur,
10 and difficult to secure. Using a service mesh can simplify this for developers. The mesh can:

11  Redirect traffic when a service is down,

12  Gather performance metrics for optimizing communications,

13  Allow management of service-to-service communication encryption,

14  Collect logs for service-to-service communication,

15  Collect logs from each service, and

16  Help developers diagnose problems and failures of microservices or communication mechanisms.

17 Fault tolerance: Fault tolerance policies should be put in place to ensure logging service availability. One policy that
18 can be put in place is to allow new logs to overwrite the oldest log files if absolutely necessary in the event of storage
19 capacity being exceeded. If logs are being sent to an external service, a mechanism should be in place for logs to be
20 stored locally if a communication loss or external service failure occurs. Once communication to the external service is
21 restored, a policy should be in place for the locally stored logs to be pushed up to the external server.

22 Tools: Kubernetes does not include extensive auditing capabilities. However, the system is built to be extensible,
23 allowing users the freedom to develop their own custom solution or to choose an existing add-on that suits their needs.
24 One of the most common solutions is to add additional audit backend services, which can use the information logged by
25 Kubernetes and perform additional functions for users, such as extended search parameters, data mapping features, and
26 alerting functionality. Organizations that already use SIEM platforms can integrate Kubernetes with these existing
27 capabilities. Open-source monitoring tools—such as the Cloud Native Computing Foundation’s Prometheus, Grafana
28 Labs’ Grafana, and Elasticsearch’s Elastic Stack (ELK) —are available to conduct event monitoring, run threat
29 analytics, manage alerting, and collect resource isolation parameters, historical usage, and network statistics on running
30 containers. Scanning tools can be useful when auditing the access control and permission configurations by assisting in
31 identifying risky permission configurations in RBAC. NSA and CISA encourage organizations utilizing Intrusion
32 Detection Systems (IDSs) on their existing environment to consider integrating that service into their Kubernetes
33 environment as well. This integration would allow an organization to monitor for—and potentially kill containers
34 showing signs of—unusual behavior so the containers can be restarted from the initial clean image. Many cloud service
35 providers also provide container monitoring services for those wanting more managed and scalable solutions.

36 Upgrading and application security practices

37 Security of applications running on Kubernetes orchestrated containers is an ongoing process, and it is vital to keep up
38 with patches, updates, and upgrades. The specific software components vary depending on the individual configuration,
39 but each piece of the overall system should be kept as secure as possible. This includes updating: Kubernetes,
40 hypervisors, virtualization software, plugins, operating systems on which the environment is running, applications
41 running on the servers, and any other software hosted in the Kubernetes environment.

________________________________________________________________________________________________
© 2024 by the O-RAN ALLIANCE e.V. Your use is subject to the copyright statement on the cover page of this specification. 109
 O-RAN.WG11.O-CLOUD-Security-TR.0-R003-v06.00

1 The Center for Internet Security (CIS) publishes benchmarks for securing software. Administrators should adhere to the
2 CIS benchmarks for Kubernetes and any other relevant system components. Administrators should check periodically to
3 ensure their system's security is compliant with the current security experts’ consensus on best practices. Periodic
4 vulnerability scans and penetration tests should be performed on the various system components to proactively look for
5 insecure configurations and zero-day vulnerabilities. Any discoveries should be promptly remediated before potential
6 cyber actors can discover and exploit them.

7 As updates are deployed, administrators should also keep up with removing any old components that are no longer
8 needed from the environment. Using a managed Kubernetes service can help to automate upgrades and patches for
9 Kubernetes, operating systems, and networking protocols. However, administrators must still patch and upgrade their
10 containerized applications.

11 A.2 CIS Docker security best practices

12 CIS Benchmarks are universal security best practices developed by cybersecurity professionals and experts. Each CIS
13 Benchmark provides guidelines for creating a secure system configuration. The following table summarizes
14 recommendations from the CIS Docker Community Edition Benchmark, specifying how to set up a safe docker
15 configuration.

16 Download the full CIS Docker Benchmark: https://www.cisecurity.org/benchmark/docker/

17 Host Configuration

18 Create a separate partition for containers

19  Harden the container host

20  Update your Docker software on a regular basis

21  Manage Docker daemon access authorization wisely

22  Configure your Docker files directories, and

23  Audit all Docker daemon activity.

24 Docker Daemon Configuration

25  Restrict network traffic between default bridge containers and access to new privileges from containers.

26  Enable user namespace support to provide additional, Docker client commands authorization, live restore, and
27 default cgroup usage

28  Disable legacy registry operations and Userland Proxy

29  Avoid networking misconfiguration by allowing Docker to make changes to iptables, and avoid experimental
30 features during production.

31  Configure TLS authentication for Docker daemon and centralized and remote logging.

32  Set the logging level to 'info', and set an appropriate default ulimit

33  Don’t use insecure registries and aufs storage drivers

34  Apply base device size for containers and a daemon-wide custom SECCOMP profile to limit calls.

35 Container Images and Build File

36  Create a user for the container

________________________________________________________________________________________________
© 2024 by the O-RAN ALLIANCE e.V. Your use is subject to the copyright statement on the cover page of this specification. 110
 O-RAN.WG11.O-CLOUD-Security-TR.0-R003-v06.00

1  Ensure containers use only trusted images

2  Ensure unnecessary packages are not installed in the container

3  Include security patches during scans and rebuilding processes

4  Enable content trust for Docker

5  Add HEALTHCHECK instructions to the container image

6  Remove setuid and setgid permissions from the images

7  Use COPY instead of ADD in Dockerfile

8  Install only verified packages

9  Don’t use update instructions in a single line or alone in the Dockerfile

10  Don’t store secrets in Dockerfiles

11 Container Runtime

12  Restrict containers from acquiring additional privileges and restrict Linux Kernel Capabilities.

13  Enable AppArmor Profile.

14  Avoid use of privileged containers during runtime, running ssh within containers, mapping privileged ports
15 within containers.

16  Ensure sensitive host system directories aren’t mounted on containers, the container's root filesystem is
17 mounted as read-only, the Docker socket is not mounted inside any containers.

18  Set appropriate CPU priority for the container, set 'on-failure' container restart policy to '5', and open only
19 necessary ports on the container.

20  Apply per need SELinux security options, and overwrite the default ulimit at runtime.

21  Don’t share the host's network namespace and the host's process namespace, the host's IPC namespace, mount
22 propagation mode, the host's UTS namespace, the host's user namespaces.

23  Limit memory usage for container and bind incoming container traffic to a specific host interface.

24  Don’t expose host devices directly to containers, don’t disable the default SECCOMP profile, don’t use docker
25 exec commands with privileged and user option, and don’t use Docker's default bridge docker0.

26  Confirm cgroup usage and use PIDs cgroup limit, check container health at runtime, and always update docker
27 commands with the latest version of the image.

28 Docker Security Operations

29  Avoid image sprawl and container sprawl.

30 Docker Swarm Configuration

31  Enable swarm mode only if needed

32  Create a minimum number of manager nodes in a swarm

33  Bind swarm services are bound to a specific host interface

34  Encrypt containers data exchange on different overlay network nodes

________________________________________________________________________________________________
© 2024 by the O-RAN ALLIANCE e.V. Your use is subject to the copyright statement on the cover page of this specification. 111
 O-RAN.WG11.O-CLOUD-Security-TR.0-R003-v06.00

1  Manage secrets in a Swarm cluster with Docker's secret management commands

2  Run swarm manager in auto-lock mode

3  Rotate swarm manager auto-lock key periodically

4  Rotate node and CA certificates as needed

5  Separate management plane traffic from data plane traffic

6 A.3 ONAP VNFs security best practices

7 ONAP provides details on the VNF general security requirements on various security areas such as user access control,
8 network security, ACLs, infrastructure security, and vulnerability management. These requirements cover topics
9 associated with compliance, security patching, logging/accounting, authentication, encryption, role-based access
10 control, least privilege access/authorization. This section summarizes requirements from ONAP, specifying how to
11 integrate and operateVNFs within a robust security environment.

12 For more details see the full documentation: https://docs.onap.org/projects/onap-vnfrqts-requirements/en/latest/

13 index.html

14 VNF General Security Requirements

15 This section provides details on the VNF general security requirements on various security areas such as user access
16 control, network security, ACLs, infrastructure security, and vulnerability management. These requirements cover
17 topics associated with compliance, security patching, logging/accounting, authentication, encryption, role-based access
18 control, least privilege access/authorization. The following security requirements need to be met by the O-RAN NFs in
19 a virtual environment:

20 1. The VNF must implement and enforce the principle of least privilege on all protected interfaces.

21 2. The VNF must provide a mechanism (e.g., access control list) to permit and/or restrict access to services on the
22 VNF by source, destination, protocol, and/or port.

23 3. The VNF should provide a mechanism that enables the operators to perform automated system configuration
24 auditing at configurable time intervals.

25 4. The VNF provider must follow GSMA vendor practices and SEI CERT Coding Standards when developing
26 the VNF in order to minimize the risk of vulnerabilities. See GSMA NESAS Network Equipment Security
27 Assurance Scheme – Development and Lifecycle Security Requirements Version 1.0 (https://www.gsma.com/
28 security/wp-content/uploads/2019/11/FS.16-NESAS-Development-and-Lifecycle-Security- Requirements-
29 v1.0.pdf) and SEI CERT Coding Standards (https://wiki.sei.cmu.edu/
30 confluence/display/seccode/SEI+CERT+Coding+Standards).

31 5. The VNF must have all code (e.g., QCOW2) and configuration files (e.g., HEAT template, Ansible playbook,
32 script) hardened, or with documented recommended configurations for hardening and interfaces that allow the
33 Operator to harden the VNF. Actions taken to harden a system include disabling all unnecessary services, and
34 changing default values such as default credentials and community strings.

35 6. The VNF should support the separation of (1) signaling and payload traffic (i.e., customer facing traffic), (2)
36 operations, administration and management traffic, and (3) internal VNF traffic (i.e., east-west traffic such as
37 storage access) using technologies such as VPN and VLAN.

38 7. The VNF Provider must have patches available for vulnerabilities in the VNF as soon as possible. Patching
39 shall be controlled via change control process with vulnerabilities disclosed along with mitigation
40 recommendations.

________________________________________________________________________________________________
© 2024 by the O-RAN ALLIANCE e.V. Your use is subject to the copyright statement on the cover page of this specification. 112
 O-RAN.WG11.O-CLOUD-Security-TR.0-R003-v06.00

1 8. The VNF must support only encrypted access protocols, e.g., TLS 1.2/1.3.

2 9. The VNF must store authentication credentials used to authenticate to other systems encrypted except where
3 there is a technical need to store the password unencrypted in which case it must be protected using other
4 security techniques that include the use of file and directory permissions. Ideally, credentials should rely on a
5 HW Root of Trust, such as a TPM or HSM.

6 10. VNFs that are subject to regulatory requirements must provide functionality that enables the Operator to
7 comply with ETSI TC LI requirements, and, optionally, other relevant national equivalents.

8 11. The VNF must be able to authenticate and authorize all remote access.

9 12. The VNF must log any security event required by the VNF Requirements to Syslog using LOG_AUTHPRIV
10 for any event that would contain sensitive information and LOG_AUTH for all other relevant events.

11 13. If SNMP is utilized, the VNF must support at least SNMPv3 with message authentication.

12 14. The VNF application processes should not run as root. If a VNF application process must run as root, the
13 technical reason must be documented.

14 15. Login access (e.g., shell access) to the virtualization layer, whether interactive or as part of an automated
15 process, must be through an encrypted protocol such as TLS 1.2/1.3.

16 16. The VNF must include a configuration (e.g. a template) that specifies the targeted parameters (e.g. a limited set
17 of ports) over which the VNF will communicate; including internal, external and management communication.

18 17. Containerized components of VNFs should follow the recommendations for Container Base Images and Build
19 File Configuration in the latest available version of the CIS Docker Community Edition Benchmarks to ensure
20 that containerized VNFs are secure. All non-compliances with the benchmarks must be documented.

21 18. Containerized components of VNFs should execute in a Docker run-time environment that follows the
22 Container Runtime Configuration in the latest available version of the CIS Docker Community Edition
23 Benchmarks to ensure that containerized VNFs are secure. All non-compliances with the benchmarks must be
24 documented.

25 VNF Identity and Access Management Requirements

26 The following security requirements for logging, identity, and access management need to be met by the O-RAN NFs in
27 a virtual environment:

28 1. The VNF must, if not integrated with the Operator’s Identity and Access Management system, support the
29 creation of multiple IDs so that individual accountability can be supported.

30 2. The VNF must, if not integrated with the operator’s IAM system, provide a mechanism for assigning roles
31 and/or permissions to an identity.

32 3. The VNF must, if not integrated with the Operator’s Identity and Access Management system, support
33 multifactor authentication on all protected interfaces exposed by the VNF for use by human users.

34 4. The VNF must support account names that contain at least A-Z, a-z, and 0–9-character sets and be at least 6
35 characters in length.

36 5. The VNF must, if not integrated with the Operator’s Identity and Access Management system, comply with
37 “password complexity” policy and support configurable password expiration. When passwords are used, they
38 shall be complex and shall at least meet the following password construction requirements: (1) be a minimum
39 configurable number of characters in length, (2) include 3 of the 4 following types of characters: upper-case
40 alphabetic, lower-case alphabetic, numeric, and special, (3) not be the same as the UserID with which they are

________________________________________________________________________________________________
© 2024 by the O-RAN ALLIANCE e.V. Your use is subject to the copyright statement on the cover page of this specification. 113
 O-RAN.WG11.O-CLOUD-Security-TR.0-R003-v06.00

1 associated or other common strings as specified by the environment, (4) not contain repeating or sequential
2 characters or numbers, (5) not to use special characters that may have command functions, and (6) new
3 passwords must not contain sequences of three or more characters from the previous password.

4 6. The VNF must allow the Operator to restrict access to protected resources based on the assigned permissions
5 associated with an ID in order to support Least Privilege (no more privilege than required to perform job
6 functions).

7 7. The VNF must set the default settings for user access to deny authorization, except for a super user type of
8 account.

9 8. The VNF must not store authentication credentials to itself in clear text or any reversible form and must use
10 salting.

11 9. The VNF must, if not integrated with the Operator’s Identity and Access Management system, support the
12 ability to lock out the userID after a configurable number of consecutive unsuccessful authentication attempts
13 using the same userID. The locking mechanism must be reversible by an administrator and should be
14 reversible after a configurable time period.

15 10. The VNF must, if not integrated with the Operator’s identity and access management system, authenticate all
16 access to protected resources.

17 11. The VNF must support LDAP in order to integrate with an external identity and access manage system. It
18 MAY support other identity and access management protocols.

19 12. The VNF must not identify the reason for a failed authentication, only that the authentication failed.

20 13. The VNF must provide a means to explicitly logout, thus ending that session.

21 14. The VNF must provide explicit confirmation of a session termination such as a message, new page, or
22 rerouting to a login page.

23 15. The VNF must, if not integrated with the Operator’s Identity and Access Management system, enforce a
24 configurable “terminate idle sessions” policy by terminating the session after a configurable period of
25 inactivity.

26 VNF API Security Requirements

27 This section covers API security requirements when these are used by the VNFs. Key security areas covered in API
28 security are Access Control, Authentication, Passwords, PKI Authentication Alarming, Anomaly Detection, Lawful
29 Intercept, Monitoring and Logging, Input Validation, Cryptography, Business continuity, Biometric Authentication,
30 Identification, Confidentiality and Integrity, and Denial of Service.

31 The O-RAN NFs in a virtual environment needs to meet the following API security requirements:

32 1. The VNF should integrate with the Operator’s authentication and authorization services (e.g., IDAM).

33 2. The VNF must implement the following input validation control: Check the size (length) of all input. Do not
34 permit an amount of input so great that it would cause the VNF to fail. Where the input may be a file, the VNF
35 API must enforce a size limit.

36 3. The VNF must implement the following input validation controls: Do not permit input that contains content or
37 characters inappropriate to the input expected by the design. Inappropriate input, such as SQL expressions,
38 may cause the system to execute undesirable and unauthorized transactions against the database or allow other
39 inappropriate access to the internal network (injection attacks).

________________________________________________________________________________________________
© 2024 by the O-RAN ALLIANCE e.V. Your use is subject to the copyright statement on the cover page of this specification. 114
 O-RAN.WG11.O-CLOUD-Security-TR.0-R003-v06.00

1 4. The VNF must implement the following input validation control on APIs: Validate that any input file has a
2 correct and valid Multipurpose Internet Mail Extensions (MIME) type. Input files should be tested for spoofed
3 MIME types.

4 VNF Security Analytics Requirements

5 This section covers VNF security analytics requirements that are mostly applicable to security monitoring. The VNF
6 Security Analytics cover the collection and analysis of data following key areas of security monitoring:

7  Anti-virus software

8  Logging

9  Data capture

10  Tasking

11  DPI

12  API based monitoring

13  Detection and notification

14  Resource exhaustion detection

15  Proactive and scalable monitoring

16  Mobility and guest VNF monitoring

17  Closed loop monitoring

18  Interfaces to management and orchestration

19  Malformed packet detections

20  Service chaining

21  Dynamic security control

22  Dynamic load balancing

23  Connection attempts to inactive ports (malicious port scanning)

24 The following requirements of security monitoring need to be met by the O-RAN NFs in a virtual environment.

25 1. The VNF must support Real-time detection and notification of security events.

26 2. The VNF must support API-based monitoring to take care of the scenarios where the control interfaces are not
27 exposed or are optimized and proprietary in nature.

28 3. The VNF must support detection of malformed packets due to software misconfiguration or software
29 vulnerability and generate an error to the syslog console facility.

30 4. The VNF must support proactive monitoring to detect and report the attacks on resources so that the VNFs and
31 associated VMs can be isolated, such as detection techniques for resource exhaustion, namely OS resource
32 attacks, CPU attacks, consumption of kernel memory, local storage attacks.

33 5. The VNF should operate with anti-virus software which produces alarms every time a virus is detected.

________________________________________________________________________________________________
© 2024 by the O-RAN ALLIANCE e.V. Your use is subject to the copyright statement on the cover page of this specification. 115
 O-RAN.WG11.O-CLOUD-Security-TR.0-R003-v06.00

1 6. The VNF must protect all security audit logs (including API, OS and application-generated logs), security
2 audit software, data, and associated documentation from modification, or unauthorized viewing, by standard
3 OS access control mechanisms, by sending to a remote system, or by encryption.

4 7. The VNF must log successful and unsuccessful authentication attempts, e.g., authentication associated with a
5 transaction, authentication to create a session, authentication to assume elevated privilege.

6 8. The VNF must log logoffs.

7 9. The VNF must log starting and stopping of security logging.

8 10. The VNF must log success and unsuccessful creation, removal, or change to the inherent privilege level of
9 users.

10 11. The VNF must log connections to the network listeners of the resource.

11 12. he VNF must log the field “event type” in the security audit logs.

12 13. The VNF must log the field “date/time” in the security audit logs.

13 14. The VNF must log the field “protocol” in the security audit logs.

14 15. The VNF must log the field “service or program used for access” in the security audit logs.

15 16. The VNF must log the field “success/failure” in the security audit logs.

16 17. The VNF must log the field “Login ID” in the security audit logs.

17 18. The VNF must not include an authentication credential, e.g., password, in the security audit logs, even if
18 encrypted.

19 19. The VNF must detect when its security audit log storage medium is approaching capacity (configurable) and
20 issue an alarm.

21 20. The VNF must support the capability of online storage of security audit logs.

22 21. The VNF must activate security alarms automatically when a configurable number of consecutive unsuccessful
23 login attempts is reached.

24 22. The VNF must activate security alarms automatically when it detects the successful modification of a critical
25 system or application file.

26 23. The VNF must activate security alarms automatically when it detects an unsuccessful attempt to gain
27 permissions or assume the identity of another user.

28 24. The VNF must include the field “date” in the Security alarms (where applicable and technically feasible).

29 25. The VNF must include the field “time” in the Security alarms (where applicable and technically feasible).

30 26. The VNF must include the field “service or program used for access” in the Security alarms (where applicable
31 and technically feasible).

32 27. The VNF must include the field “success/failure” in the Security alarms (where applicable and technically
33 feasible).

34 28. The VNF must include the field “Login ID” in the Security alarms (where applicable and technically feasible).

35 29. The VNF must restrict changing the criticality level of a system security alarm to users with administrative
36 privileges.

________________________________________________________________________________________________
© 2024 by the O-RAN ALLIANCE e.V. Your use is subject to the copyright statement on the cover page of this specification. 116
 O-RAN.WG11.O-CLOUD-Security-TR.0-R003-v06.00

1 30. The VNF must monitor API invocation patterns to detect anomalous access patterns that may represent
2 fraudulent access or other types of attacks or integrate with tools that implement anomaly and abuse detection.

3 31. The VNF must generate security audit logs that can be sent to Security Analytics Tools for analysis.

4 32. The VNF must log successful and unsuccessful access to VNF resources, including data.

5 33. The VNF must support the storage of security audit logs for a configurable period of time.

6 34. The VNF must have security logging for VNFs and their OSs be active from initialization. Audit logging
7 includes automatic routines to maintain activity records and cleanup programs to ensure the integrity of the
8 audit/logging systems.

9 35. The VNF must be implemented so that it is not vulnerable to OWASP Top 10 web application security risks.

10 36. The VNF must protect against all denial-of-service attacks, both volumetric and non-volumetric, or integrate
11 with external denial of service protection tools.

12 37. The VNF must be capable of automatically synchronizing the system clock daily with the Operator’s trusted
13 time source, to assure accurate time reporting in log files. It is recommended that Coordinated Universal Time
14 (UTC) be used where possible, so as to eliminate ambiguity owing to daylight savings time.

15 38. The VNF must log the Source IP address in the security audit logs.

16 39. The VNF must have the capability to securely transmit the security logs and security events to a remote system
17 before they are purged from the system.

18 40. The VNF should provide the capability of maintaining the integrity of its static files using a cryptographic
19 method.

20 41. The VNF must log automated remote activities performed with elevated privileges.

21 VNF Data Protection Requirements

22 This section covers VNF data protection requirements that are mostly applicable to security monitoring.

23 1. The VNF MUST provide the capability to restrict read and write access to data handled by the VNF.

24 2. The VNF MUST Provide the capability to encrypt data in transit on a physical or virtual network.

25 3. The VNF MUST provide the capability to encrypt data on non-volatile memory. Non-volative memory is
26 storage that is capable of retaining data without electrical power, e.g. Complementary metal-oxide-
27 semiconductor (CMOS) or hard drives.

28 4. The VNF SHOULD disable the paging of the data requiring encryption, if possible, where the encryption of
29 non-transient data is required on a device for which the operating system performs paging to virtual memory.
30 If not possible to disable the paging of the data requiring encryption, the virtual memory should be encrypted.

31 5. The VNF MUST use NIST and industry standard cryptographic algorithms and standard modes of operations
32 when implementing cryptography.

33 6. The VNF MUST NOT use compromised encryption algorithms. For example, SHA, DSS, MD5, SHA-1 and
34 Skipjack algorithms. Acceptable algorithms can be found in the NIST FIPS publications
35 (https://csrc.nist.gov/publications/fips) and in the NIST Special Publications
36 (https://csrc.nist.gov/publications/sp).

37 7. The VNF MUST use, whenever possible, standard implementations of security applications, protocols, and
38 formats, e.g., S/MIME, TLS, SSH, IPSec, X.509 digital certificates for cryptographic implementations. These

________________________________________________________________________________________________
© 2024 by the O-RAN ALLIANCE e.V. Your use is subject to the copyright statement on the cover page of this specification. 117
 O-RAN.WG11.O-CLOUD-Security-TR.0-R003-v06.00

1 implementations must be purchased from reputable vendors or obtained from reputable open source
2 communities and must not be developed in-house.

3 8. The VNF MUST provide the ability to migrate to newer versions of cryptographic algorithms and protocols
4 with minimal impact.

5 9. The VNF MUST support digital certificates that comply with X.509 standards.

6 10. The VNF MUST NOT use keys generated or derived from predictable functions or values, e.g., values
7 considered predictable include user identity information, time of day, stored/transmitted data.

8 11. The VNF MUST provide the capability of using X.509 certificates issued by an external Certificate Authority.

9 12. The VNF MUST be capable of protecting the confidentiality and integrity of data at rest and in transit from
10 unauthorized access and modification.

11 VNF Cryptography Requirements

12 This section covers VNF cryptography requirements that are mostly applicable to encryption or protocol methods.

13 1. The VNF SHOULD support an automated certificate management protocol such as CMPv2, Simple Certificate
14 Enrollment Protocol (SCEP) or Automated Certificate Management Environment (ACME).

15 2. The VNF SHOULD provide the capability to integrate with an external encryption service.

16 3. The VNF MUST use symmetric keys of at least 112 bits in length.

17 4. The VNF MUST use asymmetric keys of at least 2048 bits in length.

18 5. The VNF MUST provide the capability to configure encryption algorithms or devices so that they comply with
19 the laws of the jurisdiction in which there are plans to use data encryption.

20 6. The VNF MUST provide the capability of allowing certificate renewal and revocation.

21 7. The VNF MUST provide the capability of testing the validity of a digital certificate by validating the CA
22 signature on the certificate.

23 8. The VNF MUST provide the capability of testing the validity of a digital certificate by validating the date the
24 certificate is being used is within the validity period for the certificate.

25 9. The VNF MUST provide the capability of testing the validity of a digital certificate by checking the Certificate
26 Revocation List (CRL) for the certificates of that type to ensure that the certificate has not been revoked.

27 10. The VNF MUST provide the capability of testing the validity of a digital certificate by recognizing the identity
28 represented by the certificate - the “distinguished name”.

29 11. The VNF MUST support HTTPS using TLS v1.2 or higher with strong cryptographic ciphers.

30 12. The VNF MUST support the use of X.509 certificates issued from any Certificate Authority (CA) that is
31 compliant with RFC5280, e.g., a public CA such as DigiCert or Let’s Encrypt, or an RFC5280 compliant
32 Operator CA.

33 NOTE: The VNF provider cannot require the use of self-signed certificates in an Operator’s run time environment.

34

________________________________________________________________________________________________
© 2024 by the O-RAN ALLIANCE e.V. Your use is subject to the copyright statement on the cover page of this specification. 118
 O-RAN.WG11.O-CLOUD-Security-TR.0-R003-v06.00

2 Revision History
Date Revision Description
2022.01.11 V01.00.01 Initial draft version for review
2022.03.03 V01.00.02 Update according to notes from the WI core teams. This version addresses
ORA-CR009, ORA-CR010, MTR-CR001, ORA.AO-CR011
2022.03.10 V01.00.03 Update according to notes from the WI core teams. This version addresses
ALT-CR001
2022.03.24 V01.00.04 Update after spelling check
2022.10.21 V02.00.00 Addition of:
 Threats: T-GEN-05, T-VL-03, T-AAL-01, T-AAL-02
 Recommendation: REC-SDD
2022.11.14 V02.00.01 Update according to the new O-RAN TR format
2023.02.20 V03.00.01 Addition of:
 AAL interfaces
 Assets: A-OC-13 to A-OC-20
 Threats: T-AAL-03 to T-AAL-06
2023.03.20 V03.00.02 Update after spelling check
2023.07.05 V04.00.01 Integration of SYM CR 0003
2023.07.05 V04.00.02 References are updated to remove version numbers for O-RAN documents
2023.10.16 V05.00.01 Integration of WG11 CR-0011
2023.10.19 V05.00.02 Editorial corrections in scope and references
2023.10.26 V05.00.03 Editorial corrections in Clause 4.1
2024.02.19 V06.00.01 Additional of:
 Threat: T-GEN-06
 REC-IDM Identity management for O-Cloud elements
 Critical service: O-Cloud Admission Control Services
2024.03.05 V06.00.02 Addressed editorial comments
2024.03.25 V06.00.03 Addressed review comments
3
4

5 History
Date Revision Description
2024.03.25 06.00.03 Published as Final version 06.00
2023.10.26 05.00.03 Published as Final version 05.00
2023.07.05 04.00.02 Published as Final version 04.00
2023.03.20 02.01 Published as Final version 03.00
2022.11.14 02.00 Published as Final version 02.00
2022.03.24 01.00 Published as Final version 01.00
6
7
8

________________________________________________________________________________________________
© 2024 by the O-RAN ALLIANCE e.V. Your use is subject to the copyright statement on the cover page of this specification. 119