Content uploaded by Madhusanka Liyanage
Author content
All content in this area was uploaded by Madhusanka Liyanage on Mar 07, 2023
Content may be subject to copyright.
Open RAN Security: Challenges and Opportunities
Madhusanka Liyanagea, An Braekenb, Shahriar Shahabuddinc, Pasika Ranaweerad
aSchool of Computer Science, University College Dublin, Ireland
bDepartment of engineering, technology (INDI), Vrije Universiteit Brussel, Belgium
cMobile Networks, Nokia, Dallas, TX, USA, and Centre for Wireless Communications, University of Oulu, Finland
dSchool of Computer Science, University College Dublin, Ireland
Abstract
Open RAN (ORAN, O-RAN) represents a novel industry-level standard for RAN (Radio Access Network), which defines inter-
faces that support inter-operation between vendors’ equipment and offer network flexibility at a lower cost. Open RAN integrates
the benefits and advancements of network softwarization and Artificial Intelligence to enhance the operation of RAN devices and
operations. Open RAN offers new possibilities so that different stakeholders can develop the RAN solution in this open ecosys-
tem. However, the benefits of Open RAN bring new security and privacy challenges. As Open RAN offers an entirely different
RAN configuration than what exists today, it could lead to severe security and privacy issues if mismanaged, and stakeholders are
understandably taking a cautious approach towards the security of Open RAN deployment. In particular, this paper provides a
deep analysis of the security and privacy risks and challenges associated with Open RAN architecture. Then, it discusses possible
security and privacy solutions to secure Open RAN architecture and presents relevant security standardization efforts relevant to
Open RAN security. Finally, we discuss how Open RAN can be used to deploy more advanced security and privacy solutions in
5G and beyond RAN.
Keywords: Open RAN, Security, Privacy, O-RAN, 5G, 6G, AI, Machine Learning, Virtualization, Radio Access Network
1. Introduction
Mobile network communications are becoming one of the
critical enablers of the current digital economy and intercon-
necting national critical infrastructure-based services [1]. The
number of mobile subscribers and different mobile-based ser-5
vices is increasing in a rapid phase all across the globe [2].
However, the radio spectrum is still a scarce resource, and op-
timal utilization of radio resources is critical for developing a
telecommunication network [3]. Thus, the orchestration and
management of radio resources or the Radio Access Network10
(RAN) are also evolved with each mobile generation. The early
mobile generation mobile networks architectures such as 2G
and 3G had controllers responsible for orchestration and man-
agement of RAN and its resources [4]. The flat network archi-
tecture in 4G enables a new interface (i.e., X2) to support base15
station level communication to handle RAN resource allocation
[5]. However, the RAN of existing mobile network generations
is still based on monolithic building blocks. Thus, RAN func-
tions of existing networks, including most of the 5G network,
are still contained with the proprietary vendor-specific devices20
called Baseband Units (BBUs) at the base stations [6]. How-
ever, this approach leads to the proverbial vendor lock-in RAN
since different RAN vendors can design their flavor of RAN
Email addresses: madhusanka@ucd.ie (Madhusanka Liyanage),
an.braeken@vub.be (An Braeken), shahriar.shahabuddin@nokia.com
(Shahriar Shahabuddin), pasika.ranaweera@ucdconnect.ie (Pasika
Ranaweera)
equipment. This has eliminated the possibility for MNOs (Mo-
bile Network Operators) to get mix-and-match services from25
other RAN vendors.
The introduction of the network softwarization concept in 5G
[7, 8, 9] and added intelligence in beyond 5G networks have
opened up a promising solution, called Open RAN, to mitigate
this issue [9, 10]. The Open RAN Alliance [11] went back30
to the controller concept to enable best-of-breed Open RAN.
Open Radio Access Networks (Open RANs), also known as
ORANs or O-RANs, have been considered one of the most ex-
citing RAN concepts, designed for 5G and beyond wireless sys-
tems. Open RAN promotes openness and added intelligence for35
RAN network elements that could overcome the limitations of
existing RAN technologies, [12, 13]. The feature of openness
allows smaller and new players in the RAN market to deploy
their customized services, while the feature of intelligence is to
increase automation and performance by optimizing the RAN40
elements and network resources. Moreover, Open RAN offers
many RAN solutions and elements to the network operators to
be more open and flexible. Further, the network operators can
shorten the time-to-market of new applications and services to
maximize the overall revenue because of the virtualization fea-45
ture. Thus, the added intelligence in Open RAN could offer
superior benefits even to existing network softwarization based
virtual RAN and cloud RAN concepts.
There are two major Open RAN organizations, i.e., Telecom
Infra Project (TIP)[14] and the O-RAN alliance[15] who are50
working on the advancement of Open RAN realization. The
Preprint submitted to Elsevier March 7, 2023
Table 1: Summary of Important Acronyms
Acronym Definition Acronym Definition
3GPP 3rd Generation Partnership Project 5G Fifth Generation
AI Artificial Intelligence AICPA American Institute of Certified Public Accountants
API Application Programming Interface BBU Baseband Unit
CA Certificate Authority CIA Confidentiality, Integrity, Availability
CICA Canadian Institute of Chartered Accountants CI/CD Continuous Integration /Continuous Delivery
CN Container CNF Containerized or Cloud-Native Network Function
COTS Commercial Off-The-Shelf CPU Central Processing Unit
(D)DoS (Distributed) Denial of Service DL Downlink
DU Distributed Unit E2E End-to-end
eCPRI Enhanced Common Public Radio Interface EI Election Infrastructure
ETSI European Telecommunications Standards Institute FH Fronthaul
FRANS Fair, Reasonable and Non Discriminatory FTP File Transfer Protocol
GDPR General Data Protection Regulation gNB Next generation NodeB
GPS Global Positioning System GUTI Global Unique Temporary Identifier
HTTP Hypertext Transfer Protocol HW Hardware
IoT Internet of Things IP Intellectual Property
IPSec Internet Protocol Security JTAG Joint Test Action Group
LTE-M Long Term Evolution for Machines MI Model Inversion
MIMO Multiple Input Multiple Output MITM Man In The Middle
ML Machine Learning M-Plane Management Plane
MTBF Mean Time Between Failures Near-RT Near-Real-Time
NF Network Function Non-RT Non-Real-Time
NVD National Vulnerability Database OAM Operations, Administration and Maintenance
O-Cloud Open Cloud O-CU Open Centralized Unit
O-DU Open Distributed Unit OFH Open Fronthaul
Open RAN Open Radio Access Network O-RU Open RAN Radio Unit
OS Operating System OSS Operations Support Systems
PBCH Physical Broadcast Channel PDCCH Physical Downlink Control Channel
PNF Physical Network Function PTP Precision Time Protocol
RAM Random Access Memory RAN Radio Access Network
rApp non-real-time intelligence Application RIC Radio Access Network Intelligent Controller
RRM Radio Resource Management RRU Remote Radio Unit
RU Radio Unit SSH Secure Shell
SI System Integration SMO Service Management and Orchestration
S Plane Synchronization Plane SRM Supplier Relationship Management
SUPI Subscription Permanent Identifier SW Software
SQL Structured Query Language TCP Transmission Control Protocol
TPM Trusted Platform Module UDP User Datagram Protocol
UE User Equipment UL Uplink
U Plane, UP User plane vCU Virtual Computational Unit
VIP Very Important Person VM Virtual Machine
VNF Virtual Network Function vRAN virtualized Radio Access Network
xApp near-real-time intelligence Application
TIP’s OpenRAN program is an initiative that focuses on de-
veloping solutions for future RANs based on disaggregation of
multi-vendor hardware, open interfaces, and software. O-RAN
alliance is another Open RAN organization that mainly focuses55
on defining and enforcing new standards for Open RAN to en-
sure interoperability among the different vendors. At the be-
ginning of 2020, a liaison agreement between TIP and O-RAN
was made to ensure their alignment in developing interopera-
ble Open RAN solutions. OpenRAN development of TIP has60
similar original goal similar to O-RAN. Thus, we use the term
“Open RAN” throughout the paper with refer to both Open-
RAN and O-RAN development efforts.
O-RAN refers to the O-RAN Alliance or designated specifi-
cation.65
However, the benefits of Open RAN come at challenges, e.g.,
security, deterministic latency, and real-time control [16, 10,
17]. Among these factors, the security in Open RAN is quite
essential. As 5G and beyond networks are responsible for inter-
connecting many Internet protocol Telephony (IpT) based criti-70
cal national infrastructure, attacks on future telecommunication
networks will have a ripple effect [18, 19]. Some devastating
examples caused by such attacks are smart cities and factories
shutting down, a complete black-out of the power grids and wa-
ter supplies, a fall-out of the transportation infrastructure with75
crashes by autonomous vehicles, etc. [20, 21]. All these chal-
lenges demand significant effort from the research and industry
communities to standardize and implement security for all the
sections of 5G and beyond networks, including Open RAN net-
works [22]. Specially, the decentralization of control functions80
with Open RAN increases the number of threat vectors and the
surface area for attacks.
Open RAN has distinct features that bring intelligence to fu-
ture networks. While AI helps overcome various challenges of
6G Open RANs via intelligent and data-driven solutions, it can85
hurt the security of RAN. Attackers can target the AI systems
or even use AI-based attacks to jeopardize the operation of the
2
Open RAN system. Thus, Open RAN will now be vulnerable to
AI-related attacks such as denial-of-service (DoS) [23], spoof-
ing [24] and malicious data injection [25] could affect the AI.90
For instance, AI training can be manipulated in an Open RAN
spectrum access system by inserting fake signals. In addition,
the integration of network softwarization will add a whole new
set of security attacks related to virtualization. Similar to the
5G core and edge networks, now Open RAN needs to tackle95
softwarization associated attacks such as Virtual Network Func-
tion)/Cloud Network Function (VNF/CNF) manipulation [26],
Virtual Machine (VM) misconfiguration [27], log leak attacks
[28]. In addition, open interfaces defined in Open RAN will in-
troduce another set of security and privacy vulnerability. Thus,100
it is necessary to develop correct security and privacy solutions
to mitigate these new Open RAN-related security and privacy
solutions at the radio network level. Existing security mecha-
nisms, frameworks, and governance approaches will need to be
upgraded to operate in open multi-vendor controlled Ecosys-105
tem.
On the other hand, added features of Open RAN can bring se-
curity and privacy advantages over traditional RAN. Open RAN
can also build upon the security enhancements already enabled
by 5G and allow the operator to control the network’s security110
entirely, ultimately enhancing the operational security of their
network. Less hardware dependency and support for complete
software control in Open RAN allow isolating security breaches
quickly and intelligently, reducing the impact of security risk.
In addition, these features reduce the risks associated with secu-115
rity mechanism upgrades. Moreover, the modularity supported
by the open interface in Open RAN allows the security and pri-
vacy deployments to support continuous integration/continuous
delivery (CI/CD) operating model [40]. The CI/CD model sup-
ports seamless and effective security management against the120
security vulnerability in Open RAN.
Moreover, Open RAN enables the possibility for zero-touch
and frequent software updates [41], which is more transparent,
fast, secure, and low cost than the software upgrades in a tradi-
tional network. Finally, standardization of open interfaces can125
also reduce the security risks to a certain extent as it can help
detect incongruencies and offer concrete steps to monitor the
network. Thus, it is crucial to identify these new security bene-
fits and rectify them correctly in future RAN deployments.
1.1. Motivation130
The research on Open RAN security is still in its infancy. As
Open RAN advocates open interfaces, it is imperative to an-
alyze the security vulnerabilities and their mitigation of Open
RAN in parallel to their system architecture development. The
reason is that without a proper security framework in place,135
the idea of an open network might not be an attractive solu-
tion to the network operators. This is especially true in this
era of complex geopolitics, where global powers are increas-
ingly concerned about wireless infrastructure security. Table 2
summarizes existing research works about Open RAN security.140
The table highlights the lack of a comprehensive Open RAN
security analysis in the literature. Most existing Open RAN-
related publications focused on architecture, interfaces, and al-
gorithms, while security was a secondary topic. A couple of
technical specifications from Open RAN alliance present the145
security flaws and solutions of Open RAN in [34], and [36], re-
spectively. However, they are not comprehensive because they
lack a thorough discussion either on the solutions or the flaws.
They also do not present the Open RAN security benefits and
discuss any research directions. Similarly, other publications150
presented in Table 2 fail to provide a comprehensive analysis of
Open RAN security.
1.2. Our Contribution
To the best of the authors’ knowledge, this is the first attempt
to provide a comprehensive security analysis of Open RAN.155
The main contributions of this article are presented below.
•Classification of security-related risks: A taxonomy dis-
tinguishing the risks present in Open RAN, is provided.
Each of these risks is elaborated concerning a description
of impact.160
•Present Open RAN specific security solutions: Unique
solutions for Open RAN security vulnerabilities based on
blockchain, physical layer, and AI have been presented.
•Overview of general mistakes, consequences, and miti-
gation: A summary of the general design errors pertaining165
to Open RAN, their consequences, and potential mitiga-
tion are presented.
•Discussion on Open RAN security benefits: A list of se-
curity benefits specific to Open RAN, and already avail-
able in V-RAN and 5G networks are presented.170
1.3. Outline
The rest of the paper is organized as follows. Section 2
presents the overview of Open RAN architecture and the dif-
ference from the conventional RAN architectures. The threat
vectors and security risks associated with Open RAN are pre-175
sented in Section 3. Several solutions for the security threats
and vulnerabilities of Open RAN are elaborated in Section 4.
Section 5 presents the security benefits of Open RAN imple-
mentation. Discussion and lessons learned towards realizing
an Open RAN architecture are portrayed in Section 6. Finally,180
Section 7 concludes the paper.
3
Table 2: Summary of publications relevant to Open RAN security
Year & Ref.
Open RAN Architecture
Open RAN Security Flaws
Open RAN Security Solutions
Open RAN Security Benefits
Research Directions
Remarks
2022 [29] H L L L L A review article on RAN evolution towards open models and potential Open RAN
benefits and market trends
2022 [30] M L L L L This article discusses Open RAN deployment with a focus on 5G network device
security
2021 [31] H M H L L A whitepaper by Altiostar on the security of Open RAN which presents a method
to implement Open RAN with a zero-trust security framework
2021 [32] H L L L L An article that summarizes Open RAN specifications focusing on proposed archi-
tecture and building blocks
2021 [33] H L L L L This article presents an analysis of an Open RAN system with the aid of a traffic
steering use case implemented in a modular way
2021 [34] H H L L L A technical specification by O-RAN alliance on Open RAN security threat mod-
eling and remediation analysis
2021 [35] H H L M L A pre-print which identifies the limitations of current Open RAN architecture and
the technologies and opportunities for research and development to overcome them
2021 [36] M M H L L A technical specification by O-RAN alliance on the security requirements and
security controls per Open RAN defined interface and Open RAN defined network
function
2021 [37] M L M L L Presented an analysis to demonstrate the urgent need to protect Open RAN fron-
thaul and proposed a security protocol as a potential solution
2020 [38] L M L L L A whitepaper by Ericsson on Open RAN security considerations that ensure an
open and interoperable RAN is secure by design
2020 [10] H L L L L This article presents the basic functionalities and current research trends on C-
RAN and its derivatives such as vRAN and Open RAN
2017 [39] L M M L L A survey of C-RAN security flaws and solutions where many threats and solutions
are relevant for Open RAN.
This Paper H H H H H A comprehensive security analysis of Open RAN which througly discusses the
Open RAN security architecture, security flaws and solutions and security benefits
of Open RAN
LLow Coverage: Did not Consider the factor or only very briefly discussed it through mentioning it in passing
MMedium Coverage: Partially considers the factor (leaves out vital aspects or discusses it in relation to other factors)
HHigh Coverage: Consider the factor in reasonable or high detail
4
2. Brief Overview of Open RAN Architecture
Unlike traditional RAN technology, Open RAN decouples
hardware and software bonds in proprietary RAN equipment.
This feature offers more flexibility for mobile operators to de-185
ploy and upgrade their RAN segment [9, 12, 42]. Figure 1 il-
lustrated the key differences of traditional and Open RAN ar-
chitectures.
Figure 1: High level Comparison of Open RAN with Traditional RAN
The Open RAN architecture is proposed to enable three main
goals [32, 10], i.e.;190
•Cloudification: The goal is to support cloud-native RAN
functions via disaggregated hardware and software com-
ponents.
•Intelligence and automation: The goal is to utilize ad-
vanced AI/ML capabilities to enable automated manage-195
ment and orchestration in RAN
•Open internal RAN interfaces: The goal is to support vari-
ous Open RAN interfaces, including interfaces defined by
3GPP.
As illustrated in Figure 1, the RAN in Open RAN architec-200
ture is disaggregated into four main building blocks, i.e., the
Radio Unit (RU), the Distributed Unit (DU), the Centralised
Unit (CU), and RAN Intelligence Controller (RIC). The RU is
located with antennas, and it is responsible for transmitting, re-
ceiving, amplifying, and digitizing the radio frequency signals.205
The former BBU (Based Band Unit) is now disaggregated into
DU and CU. They are the computation parts of the base sta-
tion. Here, DU is physically located closer to RU, while CU
can be located closer to the Core. RIC is possible for taking the
intelligent and automated decisions related to RAN.210
O-RAN appliance has proposed a more detailed architecture
for Open RAN as represented in Figure 2. The main elements
of the Open RAN architecture include Service Management
and Orchestration (SMO), RAN Intelligence Control (RIC), O-
Cloud, Open RAN central unit (O-CU), Open RAN distributed215
unit (O-DU), and Open RAN radio unit (O-RU).
•Service Management and Orchestration (SMO): The
SMO framework is a core component of the Open RAN
Figure 2: The high-level architecture of Open RAN proposed by the O-RAN
alliance.
architecture, whose main responsibility is to manage the
RAN domain, such as the provision of interfaces with net-220
work functions, near-real-time RIC for RAN optimization,
and O-Cloud computing resource and workload manage-
ment [43, 29]. These SMO services can be performed
through four interfaces, including A1, O1, O2, and open
fronthaul M-plane.225
•RAN Intelligence Control (RIC): This logical function
enables Open RAN to perform real-time optimization of
functions and resources through data collected from the
network and end-users. It is the key element in Open RAN,
which helps to realize disaggregation strategy, bringing230
multivendor interoperability, intelligence, agility, and pro-
grammability to RANs [44, 30]. The RIC is divided into
components as non-real-time RIC (Non-RT RIC) and near-
real-time RIC (Near-RT RIC). The Non-RT RIC is in-
tegrated with Open RAN SMO Framework. It handles235
the control request and RAN resources within the second
range. To this task, Non-RT RIC utilizes specialized ap-
plications called rApps. Non-RT RIC can also collect net-
work performance metrics and subscriber data to offer AI-
based network optimization and policy guidance recom-240
mendations for Near-RT RIC. The Near-RT RIC resides
within edge servers or regional cloud as it is responsible
for performing network optimization actions within mil-
liseconds range. Near-RT RIC uses the different xApps to
support these tasks [45, 33].245
5
Open RAN
Threats
Process
Risks related to
rules, regulations
and oversight.
Prerequisites
Preliminary
assumptions
Regulations
General
regulations
Privacy
Privacy related
aspects
People
Risks related to human
aspects like training,
communication, etc.
Technology
Technology related risks are about the
mechanisms for enforcing rules and
procedures, as well as detecting threats
Open-Source
Software
Attacks on Software
Component
Radio/Open
Interface
Fronthaul
Attack on
Fronthaul
BBU
Attack on
Base Band
Unit
5G/6G Radio
Network
Intelligence
Attacks related to
Added Intelligence
Near-RT-RIC
Near Real-time
Attacks on
Intelligence
Non-RT RIC
Non-Real-time
Attacks on
Intelligence
ML
Virtualization
Attacks related to
Network
Virtualization
PNF
VNF/CNF
Attacks on
Virtual/cloud
Network Functions
SMO
Attacks on
Orchestration
Hypervisor
VM/CN
Attacks on Virtual
Machines and
Containers
General
General mechanisms and
techniques applying on
different components in
the network
Global
Broad risks related to
global communication
infrastructure
Figure 3: The Threat Taxonomy of Open RAN Systems
•O-Cloud: This is a physical computing platform. It
creates and hosts the various virtual network functions
(VNFs) and cloud network functions (CNFs) which are
used by near-real-time RIC, O-CU control plane, O-CU
user plane, and O-DU[46].250
•O-DU: This logical node has functionalities of the physi-
cal and MAC layers. This element terminates the E2 with
F1 interfaces.
•O-CU: This is a logical node in the Open RAN architec-
ture and hosts all the functions of both the control plane255
and data plane. These two O-CU planes connect with the
O-DU logical node via the F1-c interface and F1-u inter-
face, respectively.
•O-RU: This logical node has a physical layer and radio
signal processing capabilities to connect with the SMO260
framework via the open fronthaul M-plane interface and
connects with end-users via radio interfaces.
One of the main goals of Open RAN is “opening” the pro-
tocols and interfaces between these RAN components, such as
radios, hardware, and software. The O-RAN Alliance has de-265
fined eleven different interfaces, including A1, O1, E1, F1 open
fronthaul M-plane, and O2. More specifically, the open fron-
thaul M-plane interface is to connect Service Management and
Orchestration Framework (SMO) and Open RAN radio unit (O-
RU), A1 is to connect non-real-time RAN intelligent controller270
(RIC) located in the SMO framework and near real-time RIC
for RAN optimization, O1 is to support all Open RAN net-
work functions when they are connected with SMO, and O2
is to connect SMO and O-Cloud for providing cloud computing
resource and workflow management. According to [32], there275
are different deployment scenarios of the O1 interface, such as
flat, hierarchical, and hybrid models, by which the SMO frame-
work can provide numerous management services, for example,
provisioning management services, trace management services,
and performance management services.280
3. Threat Vectors and Security Risks Associated with Open
RAN
We start by explaining the taxonomy, used to distinguish the
different types of risks. Next, each of the four identified do-
mains are further elaborated.285
3.1. Threat Taxonomy
We categorize the risks in three main domains: Process,
Technology and Global. First, process risks are related to rules,
regulations, oversight. Second, the technology risks correspond
with the risks caused by the mechanisms for enforcing rules290
and procedures, as well as detecting threats. Third, global risks
are broad risks related to the global communication instruction.
Figure 3 provides an overview of the risk domains in Open
RAN respectively.
3.2. Process295
In the process risks, four categories are distinguished, corre-
sponding to the preliminary assumptions or prerequisites, the
general regulations, the privacy and human related aspects. In
fact, all the process risks apply to any RAN implementation,
but are in general more complex in Open RAN due to the mod-300
ularity and the higher amount of stakeholders involved. Table
3 provides an overview of the key process risks associated with
the Open RAN process.
6
Table 3: Overview of process related Open RAN risks
Risk category Threat Description Specific to Open-RAN
Prerequisite Requirement
of reliable
operational envi-
ronment
The operational environment of the Open RAN sys-
tem must provide reliable timestamps for e.g. the
generation of audit records. In addition, the list of
minimum prerequisites and assumptions, required to
successfully operate the O-RAN system, needs to be
defined for the operational environment. [47, 16]
This is applicable to any RAN implementation. How-
ever, it is more complex in Open RAN since some
aspects (e.g. cloud services) are not under the control
of the Open RAN system.
Requirement of
secure storage
of stored logs,
credentials and
secrets
Log files, secrets and credentials stored in external
systems and related to Open RAN need to be pro-
tected, and access controlled should be enable to al-
low only privileged users. [47, 31]
This is applicable to any RAN implementation.
However, Open RAN hardware should possess a
hardware-based security module like TPM (Trusted
Platform Module) to manage, generate, and securely
store cryptographic keys, to offer secure boot, full
disk encryption, and remote attestation.
Requirement of
Trusted certifi-
cate authorities
(CAs)
Trusted certificate authorities for identity provision-
ing are applied. [47, 31] This is applicable to any RAN implementation. How-
ever, due to involvement of additional stakeholders,
the CAs used in Open RAN for authenticating net-
work elements should be properly audited by well es-
tablished global organizations and SDOs
General Requirement of
Secure complete
lifecycle process
and assessment
strategy
Network operators should have an appropriate secu-
rity process for the complete lifecycle of Open RAN
deployment. [47, 48]
This is applicable to any RAN implementation. How-
ever, it is more complex in Open RAN due the in-
volvement of additional stakeholders.
Requirement
of Trusted as-
sets/supply chain
verification
There is a need to identify, locate, authenticate and
verify the origin of the relevant assets in the Open
RAN system. [47]
This is applicable to any RAN implementation. How-
ever, it is more complex in Open RAN because an
Open RAN system is built with components coming
from different additional parties.
Increased com-
plexity and
inter-dependency
Increased difficulty for identifying issues exists and
accountability due to complexity is not evident. [49]
This is specific to Open RAN. Due to the modular-
ity of O-RAN and loss of total ownership. Multi-
ple stakeholders need to collaborate to mitigate the
threats
Privacy Violation of
privacy policies
such as GDPR
Privacy issues arise due to new interfaces, shared en-
vironments and new players with different views and
objectives on privacy. [47, 50]
Privacy issues arising from 5G C-RAN are already
identified. However, the attack surface increases in
case of Open RAN as components can be designed in
different regions.
People Requirement of
Trustworthy and
qualified insiders
There is a need to provide sufficient security resources
and sufficient security education and training for the
users. [47, 51, 52]
The availability of sufficient security educated peo-
ple is a well-known problem. In the case of Open
RAN additional expertise is required such as virtu-
laized component security
Requirement of
Trusted stake-
holders
All stakeholders involved with Open RAN System
should be identified, authenticated and trusted. [47,
51]
This is applicable to any RAN implementation. How-
ever, it is more complex in Open RAN due to the in-
creased and diversifed number of stakeholders.
7
3.2.1. Prerequisites
To operate a successful Open RAN system, a list of mini-305
mum prerequisites and assumptions of the the operational en-
vironment needs to be defined. However, The prerequisites are
not under control of the RAN system, but should be carefully
checked [53]. To start with, a reliable operational environment
must be ensured, providing for instance reliable timestamps to310
be used in the audit records [54, 47].
Next, secure storage of stored logs, credentials and secrets
in external systems need to be guaranteed for instance by using
hardware based security modules like trusted platform modules
(TPMs) [55, 47]. Cryptographic key management, remote at-315
testation, disk image encryption, and secure booting are func-
tions that are typically conducted by a TPM. O-RAN requires
such an entity within its midst for managing hardware based se-
curity and a root of trust for facilitating signing and verification
functions.320
In addition, access to this sensitive data should only be al-
lowed by privileged users [47]. The last prerequisite is that the
certificate authorities (CAs), which authenticate the network el-
ements, are fully trusted and audited by well established, world-
wide recognized organizations [47, 56]. In fact, all these pre-325
requisites are essential for any RAN implementation. However,
since there are more stakeholders involved in Open RAN, it is
clear that these requirements are more challenging to enforce
and verify, compared to other RAN implementations.
3.2.2. General regulations330
The first step in the effective Open RAN launch that needs
to be done is the standardization of critical processes like oper-
ation, administration and management, covering the complete
lifecycle of the Open RAN deployment [57]. This includes a
clear description of components used for secure establishment335
of mutual authentication, access control, key management,
trusted communication, storage, boot and self-configuration,
update, recoverability and backup, security management of
risks in open source components, security assurance, privacy,
continuous security development, testing, logging, monitoring340
and vulnerability handling, robust isolation, physical security,
cloud computing and virtualization, and robustness.
Next, it is also important to identify, locate, authenticate and
verify the origin of the relevant assets in the system. Further-
more, for each of the different assets, at rest and in transit and345
location, the type (data, component, etc.) and the security prop-
erties (Confidentiality, Integrity, Availability - CIA) should be
carefully collected. In fact, a complete and efficient supply
chain process is required [58]. In particular, this is more com-
plex for Open RAN due to the decoupling of hardware and soft-350
ware and the modularity. For instance, there is a risk of firms
from allied states purchasing relabeled products or components
from adversarial states.
Finally, when an issue arises in the network, due to the com-
plexity of the network it is not evident to identify and isolate355
the issues. Moreover, in case the issue is found, it is possible
that the corresponding vendors do not take their responsibility
as they can pass the blame to others because of the complexity
and interdependence of the whole system.
3.2.3. Privacy360
The privacy of end users encompasses privacy related to data,
identity and personal information [59]. Privacy sensitive data
for end users are mostly leaked via communication services that
are gathering all types of personal information, which are of-
ten not needed for the functioning of the services. Adversaries365
can even further extract more personal information about end
users, such as User Equipment (UE) priority, location informa-
tion, trajectory, and preference. The protection of the user data
is regulated by the law of the hosting country, where different
jurisdictions can be applicable. There are, at least, three pos-370
sible locations, the victim, the offender, or the service provider
[50]. Therefore, clear guidelines should be developed in order
to cope with these new interfaces, shared environments and new
players available in Open RAN.
3.2.4. People375
First of all, it is necessary to clearly identify and authenti-
cate the stakeholders involved in the different processes like im-
plementation, management, operation and maintenance of the
Open RAN system. For each of the stakeholders, their roles and
responsibilities should be clearly defined and assessed. Vendors380
should have well established and transparent security practices
built into their engineering processes [47].
Moreover, adequate training and assessments need to be or-
ganized for the different stakeholders, going from administra-
tors, integrators, operators and orchestrators in order to be ca-385
pable to securely implement and manage the system according
to the instructions provided by the Open RAN Alliance and the
later to be developed standards [47].
Finally, strategies for security testing with published well-
known test plans at trusted lab facilities should be defined up-390
front and integrated in the regular operation [47] Moreover, ad-
equate training and assessments need to be organized.
3.3. Technology
The largest class of risks is related to the different compo-
nents and mechanisms in the network. Here, distinction is made395
based on [48], considering aspects related to open software, ra-
dio/open interface, intelligence, virtualization and general. Fig-
ure 4 provides an overview of the main technology related risks
in Open RAN.
3.3.1. Open source software400
The open source related risks are well known problems avail-
able in open source software code. An overview is provided in
Table 4. Since, Open RAN is expected to be built (solely or
partly) based on such open source codes, it is in particular vul-
nerable for this type of attacks.405
A trusted developer can intentionally insert a backdoor by in-
jecting a few lines of malicious code into an open source code
component to be used within the Open RAN system [63]. It
is then highly likely that a software project team picks it up
and uses the infected open source code later, while the tools410
for vetting and testing of the development team do not detect
the malicious code [47]. As a consequence, a vulnerability into
8
Radio Unit
(RU)
Software
Hardware
Virtualization Layer
Baseband (CU/DU)
RAN Intelligent Controller (RIC)
Open Interface
Attacks Related to Open Source
Software
Attacks Related to
Intelligence
Attacks Related to
Virtualization
Attacks via compromised or outdated images
Stealing security credentials
Insufficient authentication and authorization
Steal/damage data in VNF/CNF images
MITM on VNF/CNF migration
Interoperability issues
Location shift attack
Improper/missing authentication and authorization
DoS attacks
Orchestration associated security issues
VM/guest OS manipulation
Exhausting the hypervisor
Exceeding logs troubleshooting failure
Insider attacks
Insecure runtime configuration
Compromise due to flaws
Attacker hack
Malicious host
Migration attack
VM rollback attack
Scheduler Attacks
Eavesdropping on network traffic
Spoofing on network traffic
Sharing hardware
Compromised security services
Configuration defects
Intercept the Fronthaul (MITM) over U Plane
Attacks on user’s data traffic
Physical access to Fronthaul cable network
Insecure open fronthaul interfaces
Radio Jamming
Jam airlink via IoT devices
RAN Sniffing
RAN Spoofing
Rogue O-RU
Security level mismatch between O-DU and O-RU
Intercept the Fronthaul (MITM) over M Plane
Attack on master clock
MITM random delay attack to desynchronize the
clocks
Spoofing of DL/UL C-plane messages
DoS attack against O-DU C-plane
Known vulnerabilities
Backdoors
No standards for trusted
coding are available
Dispute in patents
UE location tracking and change in UE priority due to
malicious xApps
UE identification due to malicious xApps
Vulnerabilities and misconfiguration in xApps
Conflicts in xApps
Compromising isolation in xApps
DDoS attack
Sniffing attacks via A1 for UE identification
Vulnerabilities and misconfiguration in rApps
Weak authentication and authorization in rApps
Compromising isolation in rApps
Conflicts in rApps
Unanticipated results
Data poisoning attacks
Evasion attacks/Adversarial examples
Model poisoning Attacks
Transfer learning attack
Model inversion
Membership Inference Attacks
Attacks Related to
the Fronthaul
Figure 4: A Summery of Related Attacks on Open RAN Architecture and It’s Components
Table 4: Overview of Open source software related Open RAN risks
Impacting Open
RAN Component
Threat Description Specific to Open-RAN
All Known vulnerabilities Attention should be paid to developers using SW
components with known vulnerabilities or untrusted
libraries and without proper management of interde-
pendencies and patch management. [47, 60]
This is a well-know problem in open source
software code. Since Open RAN is expected
to be built (solely or partly) based on such
open source codes, it is in particular vulner-
able for these attacks
Backdoors Attention should be paid to a trusted developer inten-
tionally inserting a backdoor into an open source code
Open RAN component.[47, 61]
This is a well-know problem in open source
software code. Since Open RAN is expected
to be built (solely or partly) based on such
open source codes, it is in particular vulner-
able for these attacks
No standards for trusted
coding available
Explicit legislative standards, guidance, require-
ments, or conditions to ensure trusted programming
should become available.[47, 61, 60]
This is a well-know problem in open source
software code. Since Open RAN is expected
to be built (solely or partly) based on such
open source codes, it is in particular vulner-
able for these attacks
Dispute in patents The actors involved in Open RAN development im-
plement 5G functions at their discretion and under
different copyright regimes. The establishment of a
certain type of collaboration is required between those
actors as the degree of their collaboration is not at the
same level in many cases. [61, 62]
Due to the need of inherent agreements in
the O-RAN alliance (With increased number
of stakeholders), this is a threat specific for
Open RAN.
9
the software code is included and can go undetected for a long
period. The resulting effect on the Open RAN system can be
diverse. It can either be simply annoying, but at the same time415
it can significantly decrease the system performance via for in-
stance Denial of Service (DoS) attacks, or it can even lead to
serious loss of sensitive data.
Open source vulnerabilities are normally published on the
National Vulnerability Database (NVD) [64]. This database420
is primarily intended for developers to disclose vulnerabilities.
However, this source is also used by hackers to exploit those
vulnerabilities enabling backdoors to attacks on e.g. the hyper-
visor, Operating System (OS), Virtual Machine (VM) or con-
tainer. Moreover, vulnerabilities frequently propagate as devel-425
opers often re-use free open source code. As a consequence,
downloading open source libraries and their dependencies, as
well as downloading open source code from untrusted repos-
itories contain significant risks [47]. Open RAN vendors and
operators should thus store at each moment up-to-date invento-430
ries containing the dependencies in their open source software
used in the applications. In addition, this should be comple-
mented by a process, which receives and manages all the noti-
fications coming from the open source community that are re-
lated to newly discovered vulnerabilities, including newly de-435
veloped patches to overcome them. This should enable a better
supply chain traceability.
Existing legislation demonstrates implied security prefer-
ences but provides no explicit legislative standards, guidance,
requirements, or conditions. These preferences should be ex-440
plicit but transparent, reviewable, and auditable to ensure se-
cure coding. Due to the fact a material amount of Open RAN
code is being written by firms in different countries, security
audits should be mandatory making code available to security
researchers [61].445
Finally, the last open source software risk is more linked
to political and financial interests, instead of security interests.
Both the 3GPP and Open RAN alliance operate a Fair, Reason-
able and Non Discriminatory (FRANS) policy when it comes
to patents that are held by contributors to those respective or-450
ganizations. Patents are held on aspects of the 3GPP and Open
RAN Alliance specifications, but the holders of those patents
agree that it is mutually beneficial for everyone if the patents
are licensed with a FRANS approach. The concern in this area
is politically oriented. There might be a possibility that the455
patents held by competing manufacturers and service providers
may be withdrawn from the FRANS licensing arrangement if
trade relations between different countries dramatically deteri-
orate [61, 65].
3.3.2. Radio/Open Interface460
The different radio/open interface components include the
Fronthaul, the central Unit/distributed unit (CU/DU) and the
5G radio network. Table 5 summarizes the threats related to
this radio/open interface.
•Fronthaul. The Fronthaul of Open RAN, consisting of465
O1, O2, A1, and E2 are the new components, all available
with open interfaces allowing the software programmabil-
ity of RAN. These components and interfaces may not be
secured to industry best practices, for instance contain-
ing no proper authentication and authorization processes,470
ciphering and integrity checks, protection against replay
attacks, prevention of key reuse, validation of inputs, re-
sponse to error conditions, etc [47]. This follows often
from the strict performance requirements (bandwidth, la-
tency, fronthaul transport link length, etc.) that limit the475
use of some security features, enforced by the high bit rate
fronthaul interface to increase the processing delay. As
a consequence, different MITM, DoS, data tampering or
even information disclosure attacks become possible.
–The first category of risks is due to attacks from the480
internet exploiting weak authentication and access
control to penetrate the network boundary. There are
several possibilities for this.
First, it would allow the presence of a rogue Open
RAN Radio Unit (O-RU) in order to fool the O-485
DU or UE into associating with it instead of the le-
gitimate O-RUs [47]. This opens the door to sub-
scriber’s identity interception/disclosure and unau-
thorized user tracking attacks of user movements and
activities by catching the SUPI/5G-GUTI of the sub-490
scriber’s User Equipment (UE) and location of a de-
vice).
Second, an adversary can inject DL/UL C-plane
messages that falsely claim to be from the associated
O-DU, which would impact the O-RU to process the495
corresponding U-Plane packets [67]. Also spoofing
of DL/UL C-plane messages, leading to temporar-
ily limited cell performance (or even DoS) on cells
served by the O-RU and in addition, a consequen-
tial threat to all O-RUs parented to that O-DU might500
exist.
Third, if in addition no trusted stakeholders are guar-
anteed, an attacker can attack a master clock by send-
ing an excessive amount of time protocol packets
or impersonate a legitimate clock, a slave, or an in-505
termediate clock, by sending malicious messages to
the master, thus degrading the victim’s performance
[66]. The attacker may be residing either within the
attacked network (insider) or on an external network
connected to the attacked network. This attack re-510
sults in a situation where the clock service is inter-
rupted completely or the timing protocol is opera-
tional but slaves are being provided inaccurate tim-
ing information due to the degraded performance of
the master clock. This degradation in the accuracy of515
time may cause DoS to applications on all the RUs
that rely on accurate time, potentially bringing down
the cell. A cell outage caused by misaligned time
may further impact performance in connected neigh-
boring cells.520
Finally, when having two different vendors, the O-
RU and the O-DU need to be managed as different
10
Table 5: Overview of Radio/Open Interface related Open RAN risks
Impacting
Open RAN
Component
Threat Description Specific to Open-RAN
Fronthaul Rogue O-RU The idea is to fool O-DU or UE into associating it to a rogue O-RU
over the legitimate O-RUs. [47]
It is possible to set up a rogue RU in other
RAN systems as well. However, it will be
more easy to develop a rogue O-RU in O-
RAN due to the open nature. No implicit se-
curity due to lack of knowhow.
Security level
mismatch be-
tween O-DU and
O-RU
An attacker penetrates O-DU and beyond through O-RU or the
Fronthaul interface due to heterogeneous security levels in the split
architecture. [47, 38]
Yes, This is happen only in O-RAN as differ-
ent vendor equipment is possible for O-RU
and O-DU.
Intercept the
Fronthaul
(MITM) over
M Plane
The high bit rate Fronthaul interface imposes strict performance
requirements which force to limit the use of some security features.
[47]
Yes, This interface is specific in O-RAN.
Attack on master
clock
An attacker can attack a master clock by sending an enormous
amount of time protocol packets. It can also impersonate a legiti-
mate clock, a slave, or an intermediate clock, by sending malicious
messages to the master, thus degrading the victim’s performance.
[47, 66]
No, however, there is an increased range of
attacks in Open RAN due to the use of var-
ious xApps and rApps. Moreover, near-RT
operation is expected in Open RAN for some
of the functions.
MITM random
delay attack to
desynchronize
the clocks
An attacker acting as MITM can introduce random packet delay on
Precision Timing Protocol (PTP) sync messages and/or PTP delay-
req/resp messages, which causes inaccurate PTP offset calculation,
thus the clocks may not be synchronized properly. [47, 66]
No, however, there is an increased range of
attack in O-RAN.
Spoofing of
DL/UL C-plane
messages
An adversary injects DL/UL C-plane messages that falsely claim
to be from the associated O-DU which would impact the O-RU
to process the corresponding U-Plane packets [47, 67]. This will
lead to temporarily limited cell performance (or even DoS) on cells
served by the O-RU and in addition, a consequential threat to all
O-RUs parented to that O-DU might exist.
No. However, there is an increased range of
attacks in Open RAN. Moreover, this attack
can be easier to perform in shared virtualized
environment.
DoS attack
against O-DU
C-plane
DoS attacks against the O-DU C-plane are launched. [47]. Due
to the cleartext nature of Enhanced Common Public Radio Inter-
face (eCPRI) messages used for the Open Fronthaul C-Plane, an
attacker can launch a volumetric DoS attack with bad or unauthenti-
cated eCPRI Real-time control data messages (adopted for C-Plane
communication) against the O-DU C-Plane, causing O-DU perfor-
mance degradation and potentially its overall service interruption,
which could further cascade to all its serving O-RUs.
No, however, there is an increased range of
attacks in Open RAN. The openness in the
Open RAN system will be a cause to lose
explicit security due to a lack of know-how.
Intercept the
Fronthaul
(MITM) over
U Plane
An attacker attempts to intercept the Fronthaul (MITM) over the
User Plane due to the limited use of some security features at the
Fronthaul interfaces. [47]
No, This is a problem also in 3GPP RAN.
Attacks on user’s
data traffic
The integrity protection is enabled on the Control Plane messages,
which still makes the data traffic of the user vulnerable because the
Control Plane and User Plane are segregated. [47, 38]
No, This is a problem also in 3GPP RAN.
However, Open RAN offers the computing
resources (i.e. not available in other RANs)
to implement 3GPP specified UP integrity
protection algorithms without impacting on
the user experience.
Physical access
to Fronthaul
cable network
An intruder into the exchange over the Fronthaul cable network at-
tempts to gain electronic access to cause damage or access sensitive
data. [47, 68]
The same type of attack can be applied in
other RAN. However, the attack range and
possibilities are increased in O-RAN.
Insecure open
Fronthaul inter-
faces
An attacker penetrates and compromises the O-RAN system
through the open O-RAN’s Fronthaul due to the lack of industry
level security best practices. [47, 67, 69]
Yes, since this involves the new interfaces in-
troduced specific in O-RAN. Although fol-
lowing [69], it is also inherently required for
a secure 5G implementation.
CU/DU Attacks via
Shared Baseband
Units
An attacker exploits the lack of isolation on Shared Baseband Units
and the edge platforms to perform attacks. [12, 70]
The same type of attack can be applied in
V-RAN. However, the attack range and pos-
sibilities are increased in O-RAN.
5G Radio
Network
Radio Jamming An attacker could disrupt the communication by deliberate jam-
ming, blocking or creating interference with the authorized wire-
less network. [47]
No, this is a general attack that can be ap-
plied to any RAN.
Jam airlink via
IoT devices
An attacker attempts to jam the airlink signal through IoT devices.
[47]
No, this is applicable to any RAN.
RAN Sniffing An attacker could decode the essential network configuration de-
tails by sniffing the RAN. [47]
No, this is a general attack that can be appied
to any RAN.
RAN Spoofing An attacker is spoofing the RAN signals by transmitting a fake sig-
nal meant to pretend as an actual signal. [47]
No, this is a general attack that can be ap-
plied to any RAN.
11
entities and may have heterogeneous security levels
[38]. Instead, the O-DU will have to bridge the man-
agement traffic between the management system and525
the O-RU. Hence the possibility to reach the north-
bound systems beyond the O-DU through the Open
Fronthaul interface becomes a possible attack vector
in this split architecture.
–The second category of risks on the fronthaul is due530
to the ability of the attacker to compromise Open
RAN data integrity, confidentiality and traceability
in case the components are not secured to the indus-
try best practices. This follows often from the strict
performance requirements (bandwidth, latency, fron-535
thaul transport link length, etc.) that limit the use of
some security features, enforced by the high bit rate
fronthaul interface to increase the processing delay.
As a consequence, different MITM attacks become
possible.540
A MITM attacker over the fronthaul interface is able
to intercept the data over the U-Plane and intro-
duce random packet delay on the Precision Timing
Protocol (PTP) sync messages and/or PTP delay-
request/response messages, which causes inaccurate545
PTP offset calculation, resulting in clocks which may
not be synchronized properly [66]. Also, denial of
service (DoS) attacks become possible. Moreover,
after breaking the PDCP security, also access to con-
tent can be obtained.550
A Man-in-the-Middle (MITM) attack over the fron-
thaul interface or O1 is able to intercept the M plane,
and thus also to do passive wiretapping and DoS, but
needs to break M Plane Security prior to gain OAM
access [47].555
–The third category of risks on the fronthaul is if
an attacker compromises the Open RAN monitoring
mechanisms and integrity and availability of the log
files [71].
–The fourth category of risks on the fronthaul is560
caused by a compromise of the integrity and avail-
ability of the Open RAN components in general. In-
sufficient assurance of Open RAN software package
integrity could affect CIA of data, services, hardware
and policies during installation or upgrade phases for565
Open RAN components [47]. An attacker could, in
such a case, cause denial-of-service, data tampering,
information disclosure, spoofing identity, etc.
–Finally, if an attacker is able to get physical access to
the fronthaul components, it can result in a devastat-570
ing impact on the confidentiality and integrity of the
data [68]. Note that this is typically linked to the first
type of process related threats dealing with trusted
stakeholders.
•CU/DU. The shared units pool in the Open RAN cloud575
native deployment may suffer from insufficient isolation
and impose the risk of breaking user privacy and access-
ing sensitive data [12]. The openness and exposure of the
CU and DU entities in comparison to C-RAN are inviting
intruders for gaining access of those entities through cyber580
hacking attempts. As the fronthaul of the O-RAN is ex-
pected to be deployed via enhanced Common Public Radio
Interface (eCPRI), converged packet based network that
contrives it is inviting cyber threats unlike the traditional
frounthauls [72]. Although uncommon, intrusions can be585
perpetrated via the F interface in the Mid-haul that con-
nect CU to its corresponding DUs. Such interventions are
possible through the threat vectors such as service migra-
tion, offloading, or handover mechanisms that exist with
edge computing base stations that are presumed to host590
CUs [70]. A compromised CU is capable of impregnating
both fronthaul and the backhaul directions leveraging the
open interfaces of the O-RAN.
•5G Radio Network. These attacks are classical attacks,
which can be applied to any RAN system and include ra-595
dio jamming, jamming via IoT devices, RAN sniffing and
spoofing [47].
Radio jamming can be impacting on the reference sig-
nals, the synchronization signal, the Physical Broadcast
Channel (PBCH), the Physical Downlink Control Chan-600
nel (PDCD), the Physical Uplink Control Channel, or the
Physical Random-Access Channel [73]. This would en-
able an attacker to disrupt the communication by delib-
erate jamming, blocking or creating interference with the
authorized wireless network. Additionally to blocking the605
communication flow, jamming the synchronization chan-
nels or the signaling flow is another method to disrupt the
5G services [74]. A capable adversary can target different
entities of the 5G communication network simultaneously
to impact an interference significant enough to subdue the610
communication. Thus, a jamming detection mechanism is
mandatory to filter out the jamming frequencies in this era
of 5G and beyond [75].
In addition, due to the millions of IoT devices in the net-
work, jamming of the airlink signals through the IoT de-615
vices, can easily overload the Open RAN resources by
means of Distributed DoS (DDoS) attempts carried via
a botnet army of millions to billions of infected devices,
on which a malware instructs to reboot all devices in a
specific or targeted 5G coverage area at the same time620
[76]. Most IoT based services are Location Based Ser-
vices (LBSs) and expect locational awareness with utmost
availability. The attackers capable of jamming the GPS re-
ceiver will succeed in subduing the service to an inaccurate
state [74]. Since the O-RAN interfaces should be open to625
a common standardization to avoid vendor-specific nature,
adversaries have the ability to assimilate the firmware and
software specifications and induce a race-like condition by
exploiting its vulnerabilities.
RAN sniffing allows the attacker to decode essential net-630
work configuration details, assisting attackers to optimize
12
and craft their attacks [77]. Vulnerabilities of the PBCH
channel are allowing the attackers to sniffthe 5G RAN net-
work stats [78]. The open-source and low-cost natures of
the software radio are inviting the attackers to exploit the635
existing vulnerabilities in software, protocol, and firmware
layers. With RAN spoofing a fake signal pretending to be
an actual signal is conveyed by targeting an RF receiver
within the RAN [77]. Similar to sniffing, vulnerabilities of
the PBCH channel and the software radio devices can be640
the main causes targeted through spoofing attempts, that
embrace the masquerading signal as a legitimate one [79].
3.3.3. Intelligence
The different components and mechanisms that contribute to645
the intelligence in the Open RAN network are the Near Real-
time Radio Access Network Intelligence Controller (Near-RT-
RIC), Non Realtime RIC (Non-RT RIC), and machine learning
(ML) algorithms. These risks are mostly specific to Open RAN
as they operate on new components and new algorithms, which650
are currently not available. The threats related to intelligence
are summarized in Table 6.
•Near-RT-RIC related Attacks: xApps have the capabil-
ity to manipulate behavior of a certain cell, a group of UEs,
and a specific UE. The related attacks are due to either ma-655
licious xApps, xApps with vulnerabilities, misconfigured
xApps, compromised xApps or conflicting xApps [47].
As xApps are launched to perform intelligent functions for
CU and DU entities in regards to radio resource manage-
ment, a compromised xApp could attempt to take the con-660
trol of a cell, a RU device, or a group of UE devices; and
would be capable of tracking a certain consumer within
its RIC domain. In addition, the same malicious xApp
could gather priority information on the served UE de-
vices through the A1 interface, where distinguishing and665
identifying serving UEs are possible. Such acts violate the
location privacy of the important UEs and even the prior-
itization on the currently serving services can be manipu-
lated. This will leads to compromise RAN performance as
well as the privacy violation.670
Malicious xApps can potentially be used as a sniffer for
UE identification. In such a circumstance, RAN perfor-
mance could be impacted negatively while the privacy of
the subscribers may be violated. This follows from the
fact that the A1 interface is able to point out a certain UE675
in the network (through its UE identifier), which creates
correlations among the randomized and anonymized UE
identities between the RAN nodes. As a consequence, UE
location tracking and change in UE priority become pos-
sible. In particular, identification and tracking of a certain680
subscriber, for instance, a Very Important Person (VIP) be-
comes a real threat. The exposure of the UE identifier is
most probable through E2 signaling channels in compari-
son to its counterpart A1, due to the Near-RT conditions
of the E2. Further, such malicious xApps could change685
the Service Level Agreement (SLA) specifications of the
assigned services similar to changing of the priority lev-
els. Such acts could conflict with the Near-RT-RICs deci-
sion process as the program execution times might extend
beyond the specified boundaries of a presumed Near-RT690
event or SLAs [35].
Vulnerabilities can potentially exist in any xApp, since it
can come from either an untrusted or unmaintained source.
Such vulnerabilities can then be exploited to take over an-
other xApp or the whole near-RT RIC and often have the695
purpose to degrade the performance (e.g. a DoS). It may
also be possible to alter data transmitted over A1 or E2
interfaces, or to extract sensitive information. Also, the
xApp isolation can be exploited in order to break out of
the xApp confinement and to deduce information from co-700
hosted xApps. In addition, unauthorized access provides
new opportunities to exploit vulnerabilities in other xApps
or Open RAN components to intercept and spoof network
traffic, and to degrade services (through DoS). The open
source nature of the xApps are advertising the vulnerabili-705
ties to the adversaries while misconfigurations and incom-
patibilities are inevitable with the open nature of the O-
RAN.
Finally, since there is no clear functional split between the
Near-RT RIC and the Open RAN Next Generation Node B710
(O-gNB), possible conflicts, including conflicts in xApps,
between the decisions taken by the Near-RT RIC and the
O-gNB regarding the radio resource management can ap-
pear, both unintentionally or maliciously. This can have
an impact on the Open RAN system functions such as mo-715
bility management, admission controls, bandwidth man-
agement and load balancing, potentially resulting in per-
formance degradation. Moreover, isolation of xApps is
critical for the independent operation of O-RAN services
and for accurate Near-RT-RIC decision making. Such an720
isolation or confinement can be penetrated through under-
lying system vulnerabilities, deducing access information
via shared resource applications, or masqueraded authen-
tication attempts. A compromised isolation could subdue
the xApp operations to the attacker.725
•Non-RT RIC related Attacks: rApps impact non-RT RIC
functions such as AI/ML model training, A1 policy man-
agement, enrichment information management, network
configuration optimization for the purpose of performance
degradation, DoS, and enrichment data sniffing (UE lo-730
cation, trajectory, navigation information, and GPS data).
rApps bearing many resemblances to xApps in their oper-
ational context, have the ability to manipulate the behavior
of a certain cell, a group of UEs, and a specific UE. The re-
lated attacks are similar to xApps, due to either malicious735
rApps, rApps with vulnerabilities, misconfigured rApps,
compromised rApps or conflicting rAPPs. Besides these
similar ones, there are two more risks identified related to
Non-RT RIC [47].
Untrusted or unmaintained sources can cause vulnerabil-740
13
Table 6: Overview of Intelligence-related Open RAN risks
Impacting
Open RAN
Component
Threat Description Specific to Open RAN
Near-RT-RIC UE location tracking and
change in UE priority due
to malicious xApps
xApps have the capability to manipulate the behavior of a certain cell, a group of UEs, and
a specific UE to track a certain subscriber or change priority level of an UE. [47, 38]
Yes since xApps and E2,
A1 interfaces are only de-
fined in O-RAN.
UE identification due to
malicious xApps Malicious xApps can exploit UE identification and track UE location. For example, a xApp
can potentially be used as a “sniffer” for UE identification. [47, 38, 67]
Yes since xApps and E2,
A1 interfaces are only de-
fined in O-RAN.
Vulnerabilities and mis-
configuration in xApps Vulnerabilities can potentially exist in any xApp, if it obtained from an untrusted or un-
maintained source. An attacker exploits vulnerabilities and misconfiguration of such xAPPs
to disrupt the offered network service and potentially take over another xApp or the whole
near-RT RIC. [47, 38, 35]
Yes, as these components
are only defined in O-
RAN.
Conflicts in xApps Conflicting xApps unintentionally or maliciously impact O-RAN system functions such as
mobility management, admission controls, bandwidth management and load balancing in
the purpose of performance degradation. Moreover, a threat actor can utilize a malicious
xApp that intentionally triggers RRM (Radio Resource Management) decisions conflicting
with the O-gNB internal decisions to create DoS. [47, 38]
Yes, as these components
are only defined in O-
RAN.
Compromising isolation
in xApps An attacker compromises xApp isolation to break out of xApp confinement. Such a way,
attacker can perform side channel attack to deduce information from co-hosted xApps in a
shared resource pool. [47]
Yes, as these components
are only defined in O-
RAN.
Non-RT RIC DDoS attack An attacker penetrates the Non Real-Time RAN Intelligent Controller (Non-RT RIC) to
cause a DoS or degrade the performance. [47]
Yes, as these components
are only defined in O-
RAN.
Sniffing attacks via A1
for UE identification An attacker performs UE sniffing in the Non-RT RIC via A1 interface or via R1 interface
via rApps in order to identify UE. For example, a rApp can potentially be used as a “sniffer”
for UE identification. [47]
Yes, as these components
are only defined in O-
RAN.
Vulnerabilities and mis-
configuration in rApps Vulnerabilities can potentially exist in any rApp, if it obtained from an untrusted or unmain-
tained source. An attacker exploits vulnerabilities and misconfiguration of such rAPPs to
disrupt the offered network service and potentially take over another rApp or the whole non-
RT RIC. [47, 38, 35]
Yes, as these components
are only defined in O-
RAN.
Weak authentication and
authorization in in rApps If web front-end or REST API interfaces contain software vulnerabilities or implement au-
thentication and authorization insufficiently, an attacker could bypasses authentication and
authorization and able to gain access to the rApp and pose as a tenant. Such a way an at-
tacker gains the ability manipulate configurations, access logs and implement back doors
[47, 67]
Yes, as these components
are only defined in O-
RAN.
Compromising isolation
in rApps An attacker compromises rApp isolation to break out of rApp confinement. Such a way,
attacker can perform side channel attack to deduce information from co-hosted rApps in a
shared resource pool[47]
Yes, as these components
are only defined in O-
RAN.
Conflicts in rApps Conflicting rApps (i.e. direct, indirect and implicit conflicts) unintentionally or maliciously
impact non-realtime Open RAN system functions such as Carrier license scheduling, energy
savings and subscription handling to degrade performance or trigger a DoS. [47]
Yes, as these components
are only defined in O-
RAN.
ML Unanticipated results If unexplainable AI is used, the results cannot be predicted and might have a fast impact
[80]. Therefore, use of unexplainable AI/ML models in the Open-RAN can potentially lead
to unanticipated consequences, which might have an impact on the security and privacy [67].
Such AI/ML models could unintentionally violate the security and privacy policies and offer
bias results.
The same type of at-
tack can be applied in V-
RAN. However, the at-
tack range and possibili-
ties are larger in O-RAN.
Data poisoning attacks An attacker with access to the training set is able to poison the ML training data (Data poi-
soning attacks) and thus break the reliability of the training. This impacts the xApps/rApps
managed Open RAN system functions such as mobility management, admission controls,
bandwidth management, load balancing and results a performance degradation [47, 81].
This attack only applies
to O-RAN, where ML is
explicitly included.
Evasion at-
tacks/Adversarial ex-
amples
An attacker uses an adversarial example (intentionally designed date) as an input to the ML
models to make a mistake[82, 83, 84]. This impacts the xApps/rApps managed Open RAN
system functions results a performance degradation.
This attack only applies
to O-RAN, where ML is
explicitly included.
Model poisoning Attacks An attacker with access to the model can alter the ML model resulting in system manipula-
tion and compromise of ML data confidentiality and privacy [47, 84, 85]. This impacts the
xApps/rApps managed Open RAN system functions results a performance degradation.
This attack only applies
to O-RAN, where ML is
explicitly included.
Transfer learning attack A transfer learning attack becomes possible [47]. This impacts the xApps/rApps managed
Open RAN system functions results a performance degradation.
This attack only applies
to O-RAN, where ML is
explicitly included.
Model inversion An attacker can have the aim to reconstruct training data from model parameters [82, 86, 87].
This impacts the xApps/rApps managed Open RAN system functions results a performance
degradation.
This attack only applies
to O-RAN, where ML is
explicitly included.
Membership Inference
Attacks An attacker tries to identify the data samples used for the model training [82, 88]. This im-
pacts the xApps/rApps managed Open RAN system functions results a performance degra-
dation.
This attack only applies
to O-RAN, where ML is
explicitly included.
14
ities in any rApp. Exploitation of these vulnerabilities
mostly leads to disruption of the offered network service
and potentially taking over another rApp or the whole non-
RT RIC. As a consequence, the attacker may gain the
ability to alter data transmitted over A1 interface, or ex-745
tract sensitive information. Also rApp isolation can be
exploited to break out of rApp confinement and to de-
duce information from co-hosted rApps. Unauthorized ac-
cess provides new opportunities to exploit vulnerabilities
in other rApps or Open RAN components to intercept and750
spoof network traffic, to degrade services through DoS at-
tempts; An attacker might also penetrate the non-RT RIC
through A1/O1 interfaces or from external sources through
SMO and attempts to trigger a DoS or degrade the perfor-
mance of non-RT RIC [35].755
In addition, rApps in the Non-RT RIC can cause conflict-
ing decisions as they can be launched by different vendors
targeting different purposes: Carrier license scheduling, or
energy savings. Such conflicts could take the form of a
direct, indirect, or implicit nature depending on the rApp760
parameters in question, and the effect that particular con-
flict is inducing. As in direct ones deals with the conflict
of same parameter change requested by different rApps,
indirect ones where the different parameter changes by dif-
ferent rApps would cause an opposite effect, and implicit765
ones that different parameter changes would lead to chang-
ing the network state. The effects can lead to an overall
network performance degradation, or instabilities within
the network entities. These conflicts are difficult to miti-
gate since dependencies are impossible to observe.770
There is an additional vulnerability that can appear in the
case the rApp management is exposed to a web front-end
or REST API, whose software interfaces contain vulnera-
bilities or do not implement authentication and authoriza-
tion in a proper way. This would allow an attacker to gain775
access to the rApp and pose as a tenant or to manipulate
configurations, access logs, or to implement back doors.
•ML related Attacks: ML and AI play a vital role in the
formation of the O-RAN concept. Thus, vulnerabilities
or flows in existing ML models or algorithms can be en-780
visaged as probable threats to the O-RAN system as they
are deployed in the intelligence portion of the architecture.
One of the most common threats is the data poisoning at-
tacks, where the adversary is altering the data sets that
are intended for training, testing, or validating [81, 47].785
The access to perform such modifications, however, can
be gained via the penetration through fronthaul, midhaul,
xApps, or rApps. Poisoning attempts could impact any
stage of the ML process as in feature selection, predic-
tion, decision making, model classification, or anomalous790
detection. The O-RANs openness and the Near-RT op-
erations require the ML models to be formed online with
continual updating during the operation. Though it would
not impact in the long run, feeding bogus data to the on-
line ML model is capable of impacting the RIC decision795
making negatively, especially in terms of radio resource al-
location. Similarly, evasion/adversarial attacks or model
poisoning attacks represent two variants of the poisoning
attack. In the evasion attempt, data is carefully tampered
according to a perturbed design that would not detect as800
anomalous. In the model poisoning attempt, the entire
model or the control parameters of the model are altered
to impact the learning phases of the process [85].
Pre-trained and widely available ML models can be uti-
lized by the attackers for gaining access or evading the805
system’s anomalous detectors for launching transfer learn-
ing attacks. Model inversion and membership inference
attacks are ensuing privacy leakages [82]. In model inver-
sion attempts, adversary is reconstructing the training data
set from the model parameters [86, 87, 89]. This is plausi-810
ble as there are plenty of online repositories with training
data that would aid the attacker in cross-validating the de-
termined data. Membership inference threat would deter-
mine whether a particular data set was used in the training
process of the ML model or not [88].815
Finally, due to the complexity of the models in AI/ML, the
results are not yet explainable in most of the cases [80].
Therefore, its use in the RAN can potentially lead to unan-
ticipated consequences, which might have an impact on
the security or performance [67].820
The impact of data poisoning attempts would clearly target
the allocation and management of radio resources within
the O-RAN fronthaul, and could result in jeopardizing the
accuracy of mobility management, load balancing, and
QoS management functions that are administered under825
the Near-RT-RIC. In the long run, the entire RT intelli-
gent framework could become compromised. Model poi-
soning, evasion and transfer learning attempts induce the
same impact on the RT systems. For the Non-RT system,
however, as the time is not a critical parameter, the impact830
would be less costly, as the decisions are made from the
data gathered from an extended period in comparison to
the RT instances.
3.3.4. Virtualization
The following components, Physical Network Function835
(PNF), Virtual Network Function (VNF), Cloud Network
Function (CNF), SMO, hypervisor, Virtual Machine/Container
(VM/CN), are involved in the virtualization process. Here, we
discuss the security issues associated with each of these com-
ponents. Some of these attacks can be applied also in V-RAN840
and C-RAN[97]. However, the attack range and impact of such
attacks larger in Open RAN. The threats related to intelligence
are summarized in Table 7.
•PNF related Attacks:. An attacker compromises a
PNF to launch reverse attacks and other attacks against845
VNFs/CNFs. A lack of security policies to protect mixed
PNF-VNF/CNF deployments, resulting to insecure in-
terfaces, could be exploited to perform attacks against
15
Table 7: Overview of Virtualization related Open RAN risks
Impacting
Component
Threat Description Specific to Open-RAN
PNF-
VNF/CNF
Lack of security policies
to protect mixed PNF-
VNF/CNF
Compromises a PNF to launch reverse attacks and other at-
tacks against VNFs/CNFs due to the lack of security policies
to protect mixed PNF-VNF/CNF[47, 89].
Can be applied in V-RAN. How-
ever, the attack possibilities are in-
creased in Open RAN.
VNF/CNF Attacks via compromised
or outdated images
Compromises VNF/CNF images or used outdated images[47] The same type of attack can be ap-
plied in V-RAN.
Configuration defects Utilizes the configuration defect of VNF/CNF to attack[47]. However, the attack range and pos-
sibilities are increased in Open
RAN.
Stealing security creden-
tials
Steals embedded security credentials from VNF/CNF
images[47].
Insufficient authentication
and authorization
Insufficient authentication and authorization can lead to IP loss
and expose significant technical details about an Open RAN
VNF/CNF image to an attacker. [47]
Stealing or damage of em-
bedded information from
VNF/CNF images
Steal or damage sensitive information from/in VNF/CNF
images[47].
MITM on VNF/CNF mi-
gration
Performs MITM to intercept network traffic and jeopardize the
VNF/CNF image migration. [47, 70]
Interoperability issues Exploits the security level mismatches of different
VNF/CNFs[90, 50, 70, 91].
Location shift attack A compromised VNF/CNF changes the run-time environments
to perform an attack[90, 91, 70]
SMO Improper/missing authen-
tication
Can exploit the improper/missing authentication on Service
Management and Orchestrator (SMO) functions to illegally ac-
cess the SMO and its functions[47].
The same type of attack can be ap-
plied against the Management and
Orchestration (EMM) in C-RAN.
Improper/missing autho-
rization
Can exploit the improper/missing authorization on SMO func-
tions [47].
However, the attack range and pos-
sibilities are larger in Open RAN.
DoS attacks Performs overload or flooding DoS attacks at SMO[47].
Orchestration associated
security issues
Exploits weak orchestrator configuration, access control and
isolation[47].
Can be applied in V-RAN. How-
ever, the attack possibilities are
higher in Open RAN.
Hypervisor VM/guest OS manipula-
tion
Exploits the security weaknesses in the guest OS to attack the
hypervisor [92, 90, 93].
The same type of attack can be ap-
plied in V-RAN.
Exhausting the hypervisor Changes the configurations of compromised VNFs/CNFs to
consume more resources and exhaust the hypervisor [92, 90,
70].
However, the attack range and pos-
sibilities are larger in Open RAN.
Exceeding logs trou-
bleshooting failure
Change the configurations of compromised VNFs/CNFs
to generate excessive amounts of logs and exhaust the
hypervisor[92, 90].
Insider attacks An insider who has access to the hypervisor misuses his privi-
leges to perform an attack[92, 90].
VM/CN Misuse to attack others A VM/CN can be misused to attack another VM/CN, hypervi-
sor/container engine, other hosts (memory, network, storage),
etc. [47]
The same type of attack can be ap-
plied in V-RAN.
Insecure run time configu-
ration
Insecure VM/CN run time configuration by the administrator
can lower the security[47].
However, the attack range and pos-
sibities are larger in Open RAN.
Compromise due to flaws VMs/CNs may be compromised due to flaws in the
VNFs/CNFs they run[47, 94, 95].
Attacker hack Hack into VM/CN retrieves the administrator privileges, re-
sulting in obtaining all tenant’s tokens and the administrator
rights of the whole Open RAN system[47].
Malicious host The host OS has access to all data[38, 96].
Migration attack During the VM/CN migration, a MITM attacker can modify
arbitrary VM/CN OS or application states[92, 90].
VM rollback attack An attacker uses and older snapshot of VM/CN to obtain ac-
cess to the system[92, 90].
Scheduler Attacks Misconfigures the hypervisor scheduler to allocate more re-
sources to malicious VMs[92, 90].
Eavesdropping on network
traffic
Eavesdrop on network traffic via a malicious VM/CN or hy-
pervisor/container engine[47].
Spoofing on network traf-
fic
Intercept and spoof on network traffic via VMs/CNs[47].
Sharing hardware Applications may share the same hardware resources in virtu-
alization, which might be affected by vulnerabilities[38].
Compromised security
services
Compromises auxiliary/supporting network and security
services[47].
16
VNFs/CNFs, potentially taking advantage of legacy se-
curity used by PNFs and not provided by the virtualiza-850
tion/containerization layer [47]. Apart from the security
policies, service level agreements and service specifica-
tions are vital consensus for the PNF, CNF, and VNF entity
deployment. As these entities are envisaged to launch se-
curity management entities as specified in [89], the origi-855
nal consensus should not be altered for all the service level
guarantees.
•VNF/CNF related Attacks: Despite VNF/CNF images
are effectively static archive modules including all com-
ponents used to run a given Open RAN VNF/CNF, mod-860
ules within an image may have vulnerabilities, introduc-
ing malware, missing critical security updates or are out-
dated. These images are only collections of files pack-
aged together. Therefore, malicious files can be included
intentionally or inadvertently within them. In addition,865
VNF/CNF images may also have configuration defects,
e.g. configuring a specific user with greater privileges than
needed. This could all be used to attack other VMs/CNs
or hosts within the environment. An attacker can migrate a
compromised VNF/CNF to a different location which has870
less security or privacy policies to gain additional access
to the system. Since Open RAN uses different equipment
with different vendors and different configurations, there
can be less secure environments, which can lead to addi-
tional vulnerabilities if deployed in the same system [47].875
Moreover, since many Open RAN VNFs/CNFs require
secrets to enable authentication, access control and se-
cure communication between components, these secrets
are embedded directly into the image file system. In ad-
dition, the images often contain also sensitive components880
like an organization’s proprietary software and administra-
tor credentials. Anyone with access to the image (e.g. by
means of insufficient authentication and authorization) can
easily parse it to extract these secrets, resulting in the com-
promise, stealing or damage of the contents on the images.885
As a result, it can lead to Intellectual Property (IP) loss and
expose significant technical details about an Open RAN
VNF/CNF image to an attacker. Even more critically, be-
cause registries of images are typically trusted as a source
of valid, approved software, compromise of a registry can890
potentially lead to compromise of downstream VMs/CNs
and hosts [47].
There is an increased risk of MITM attacks by intercept-
ing network traffic intended for registries in order to steal
developer or administrator credentials within that traffic.895
This can result in fraudulent or outdated images to or-
chestrators [47]. Further, typical VNF/CNF based security
threats exist, as in: location shift attack where the adver-
sary is capable of displacing the VNF to a domain inher-
iting a lesser level of security policy assignment with the900
intention of gaining access, or interoperability issues be-
tween the VNF/CNF developers or service providers that
can be exploited by an attacker [91, 70].
•SMO related Attacks: As the SMO is the key entity be-
hind the holistic autonomic environment of the O-RAN,905
its security is extremely vital for the O-RAN performance
and the individual subscriber security and privacy. Im-
proper or insufficient authentication or authorization of
Open RAN external (e.g. AI/ML, Emotional Intelligence
(EI), Human-Machine) or internal (e.g. over O1 or O2910
interfaces, with Non-RT RIC) interfaces on SMO, allow
access to the SMO and in particular the data stored on it.
Besides disclosing Open RAN sensitive information, the
attacker may also alter the Open RAN components [47].
DoS attacks or increased traffic can cause overload situ-915
ations and thus affects availability of the SMO data and
functions. Further, an attacker may exploit weak orches-
trator configuration, access control and isolation. A sin-
gle orchestrator may run many different VMs/CNs, each
managed by different teams, and with different sensitivity920
levels. If the access provided to users and groups is not
conform their specific requirements, an attacker or care-
less user would be able to affect or subvert the operation of
another VM/CN managed by the orchestrator. Malicious
traffic from different VMs/CNs sharing the same virtual925
networks may be possible if VMs/CNs of different sen-
sitivity levels are using the same virtual network with a
poorly isolation of inter-VM/CN network traffic [47].
•Hypervisor related Attacks: An attacker can exploit the
security weaknesses in the guest OS to attack the hyper-930
visor of the hosting OS. Examples of guest OS vulnera-
bilities are OS command injection, SQL injection, buffer
overflow or missing authentication for critical functions
[92, 90, 93]. Privilege escalation is a common threat
among hypervisor deployments that is also applicable in935
the context of the O-RAN. In this attack, any autho-
rization violations are sought out by the perpetrator ex-
ploiting the infrastructure vulnerabilities formed through
ill-maintenance or misconfigurations [70]. The adminis-
trative capabilities granted to the adversary through this940
threat is devastating as it could range from a simple ex-
cessive allocation of resources to a complete deletion of
xApps or rApps [98, 99].
An attacker may also change the configurations of com-
promised VNFs/CNFs to consume high amounts of CPU,945
hard disk, and memory resources in order to exhaust the
hypervisor. Another way to compromise the hypervisor
is by generating an excessive amount of log entries such
that it is infeasible or very difficult to analyze the log files
coming from other VNFs [92, 90].950
Finally, as the hypervisor provides its own security func-
tions and Application Programming Interfaces (APIs) to
the host system security functions, it is in full control of
the security functionalities of the lower layers and thus
needs to be fully trusted. When a malicious administrator955
has for instance root access to the hypervisor and by using
a search operation, the user identity (ID), passwords and
Secure Shell Protocol (SSH) keys from the memory dump
17
can be extracted, which in turn violates the user privacy
and data confidentiality [92, 90].960
•VM/CN related Attacks: VMs/CNs may be compro-
mised due to flaws in the Open RAN VNFs/CNFs they run.
For example, an Open RAN VNF/CNF may be vulnera-
ble to cross-site scripting (SQL) injection [94] and buffer
overflow vulnerabilities [95].965
Insecure VM/CN runtime configuration by the administra-
tor can lower the security of the Open RAN system. It may
expose VMs/CNs and the hypervisor/container engine to
increased risk from a compromised VM/CN. For example,
it could be used to elevate privileges and attack VMs/CNs,970
the O-Cloud infrastructure/services, etc [47].
A compromised VM/CN will be able to alter that VM/CN
in order to access other VMs/CNs, monitor VM/CN to
VM/CN communications, attack the O-Cloud infrastruc-
ture/services, scan the network to which it is connected to975
in order to find other weaknesses to be exploited, etc. The
container engine (in case of CN) or hypervisor (in case
of VM) has access to all RAM memory, disk volumes
mounted on the virtual machines and containers. This
means that a malicious VM/CN or hypervisor/container980
engine can get access to all Open RAN network data pro-
cessed in the workloads. An attacker can launch a noisy
neighbor attack against the shared O-Cloud infrastructure
to cause the Open RAN system performance degradation
and/or the services disruption by depriving the resources985
required by various Open RAN running functions [47].
An attacker hack into VM/CN is for instance possible if
an attacker steals VMs/CNs private key from one VM/CN
and so reveals the administrator privileges. Next, all ten-
ant’s tokens and the administrator rights of the whole Open990
RAN system can be obtained, [47].
From the side of the application, trust is required at all lev-
els. In case the underlying host OS is malicious, access can
be obtained to all data processed in the workloads, as in
RAM memory and disk volumes. Techniques like secure995
enclaves [96] have the goal to provide a trusted environ-
ment. However, the application will be hardware-instance
dependent [38].
If VM/CN migration is not secured or performed over
a secure channel, a MITM attacker can modify arbitrary1000
VM/CN OS or application states during the migration. An
attacker may also use an older snapshot of VM/CN without
the concern of the VM/CN owner to bypass the security
system and obtain access to the system. This attack is pos-
sible after an already comprised hypervisor rollback to a1005
previous snapshot. In the scheduler attack, the vulnerabil-
ities in the hypervisor’s scheduler are exploited to acquire
system resources for the malicious VM at the expense of a
victim VM [92, 90].
Furthermore, due to virtualization and cloud comput-1010
ing, different applications might use the same hard-
ware resources. Isolation between these applications are
only at software level and not at the level of hardware.
As a consequence, hardware related vulnerabilities like
the recently discovered Meltdown and Spectre attacks1015
(https://meltdownattack. com/) can have a larger attack
range [38].
Finally, besides the main functionality of the VNF/CNF
itself, the administrators may also decide to deploy addi-
tional network services on their VMs/CNs in order to do1020
extra monitoring, remote configuration, remote access to
other services such as SSH, etc. If these additional net-
work services are directly accessible over the Internet or
from another administrator, new entry points for attackers
are created and if access is obtained to the VM/CN, more1025
extra attacks become possible [47].
3.4. Global
Offering the highest level of security on the network is im-
portant for a nation. We here distinguish five major types of
attacks or risks that need to be taken into account [100]. The1030
related threats can be found in Table 8.
•Attack on digital economy: Since 5G is fully integrated
in the digital economy, it can result in potential life