Open RAN Security: Challenges and Opportunities

To operate a successful Open RAN system, a list of minimum prerequisites and assumptions of the the operational environment 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 to 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 attestation, disk image encryption, and secure booting are functions that are typically conducted by a TPM. O-RAN requires such an entity within its midst for managing hardware based security and a root of trust for facilitating signing and verification functions.

In addition, access to this sensitive data should only be allowed by privileged users [47]. The last prerequisite is that the certificate authorities (CAs), which authenticate the network elements, are fully trusted and audited by well established, worldwide recognized organizations [47, 56]. In fact, all these prerequisites 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.

The first step in the effective Open RAN launch that needs to be done is the standardization of critical processes like operation, administration and management, covering the complete lifecycle of the Open RAN deployment [57]. This includes a clear description of components used for secure establishment 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, monitoring 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. Furthermore, for each of the different assets, at rest and in transit and location, the type (data, component, etc.) and the security properties (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 complex for Open RAN due to the decoupling of hardware and software 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 complexity of the network it is not evident to identify and isolate 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.

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 often not needed for the functioning of the services. Adversaries can even further extract more personal information about end users, such as User Equipment (UE) priority, location information, 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 possible 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.

First of all, it is necessary to clearly identify and authenticate the stakeholders involved in the different processes like implementation, management, operation and maintenance of the Open RAN system. For each of the stakeholders, their roles and responsibilities should be clearly defined and assessed. Vendors should have well established and transparent security practices built into their engineering processes [47].

Moreover, adequate training and assessments need to be organized for the different stakeholders, going from administrators, integrators, operators and orchestrators in order to be capable 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 upfront and integrated in the regular operation [47] Moreover, adequate training and assessments need to be organized.

The open source related risks are well known problems available 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 vulnerable for this type of attacks.

A trusted developer can intentionally insert a backdoor by injecting 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 tools for vetting and testing of the development team do not detect the malicious code [47]. As a consequence, a vulnerability into 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 time it can significantly decrease the system performance via for instance 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 database 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 hypervisor, Operating System (OS), Virtual Machine (VM) or container. Moreover, vulnerabilities frequently propagate as developers 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 repositories contain significant risks [47]. Open RAN vendors and operators should thus store at each moment up-to-date inventories containing the dependencies in their open source software used in the applications. In addition, this should be complemented by a process, which receives and manages all the notifications coming from the open source community that are related to newly discovered vulnerabilities, including newly developed patches to overcome them. This should enable a better supply chain traceability.

Existing legislation demonstrates implied security preferences but provides no explicit legislative standards, guidance, requirements, or conditions. These preferences should be explicit but transparent, reviewable, and auditable to ensure secure 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].

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, Reasonable and Non Discriminatory (FRANS) policy when it comes to patents that are held by contributors to those respective organizations. 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 the patents held by competing manufacturers and service providers may be withdrawn from the FRANS licensing arrangement if trade relations between different countries dramatically deteriorate [61, 65].

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 of O1, O2, A1, and E2 are the new components, all available with open interfaces allowing the software programmability of RAN. These components and interfaces may not be secured to industry best practices, for instance containing no proper authentication and authorization processes, ciphering and integrity checks, protection against replay attacks, prevention of key reuse, validation of inputs, response to error conditions, etc [47]. This follows often from the strict performance requirements (bandwidth, latency, fronthaul 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, DoS, data tampering or even information disclosure attacks become possible.

  • –

    The first category of risks is due to attacks from the 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-DU or UE into associating with it instead of the legitimate O-RUs [47]. This opens the door to subscriber’s identity interception/disclosure and unauthorized user tracking attacks of user movements and activities by catching the SUPI/5G-GUTI of the subscriber’s User Equipment (UE) and location of a device).

    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 the corresponding U-Plane packets [67]. Also spoofing of DL/UL C-plane messages, leading 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.

    Third, if in addition no trusted stakeholders are guaranteed, an attacker can attack a master clock by sending an excessive amount of time protocol packets or impersonate a legitimate clock, a slave, or an intermediate 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 results in a situation where the clock service is interrupted completely or the timing protocol is operational but slaves are being provided inaccurate timing information due to the degraded performance of the master clock. This degradation in the accuracy of 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 neighboring cells.

    Finally, when having two different vendors, the O-RU and the O-DU need to be managed as different entities and may have heterogeneous security levels [38]. Instead, the O-DU will have to bridge the management traffic between the management system and the O-RU. Hence the possibility to reach the northbound 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 due to the ability of the attacker to compromise Open RAN data integrity, confidentiality and traceability in case the components are not secured to the industry best practices. This follows often from the strict performance requirements (bandwidth, latency, fronthaul 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.

    A MITM attacker over the fronthaul interface is able to intercept the data over the U-Plane and introduce random packet delay on the Precision Timing Protocol (PTP) sync messages and/or PTP delay-request/response messages, which causes inaccurate 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 content can be obtained.

    A Man-in-the-Middle (MITM) attack over the fronthaul 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].

  • –

    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 is caused by a compromise of the integrity and availability of the Open RAN components in general. Insufficient assurance of Open RAN software package integrity could affect CIA of data, services, hardware and policies during installation or upgrade phases for 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 devastating 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 cloud native deployment may suffer from insufficient isolation and impose the risk of breaking user privacy and accessing 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 cyber hacking attempts. As the fronthaul of the O-RAN is expected 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 be perpetrated via the F interface in the Mid-haul that connect CU to its corresponding DUs. Such interventions are possible through the threat vectors such as service migration, offloading, or handover mechanisms that exist with edge computing base stations that are presumed to host 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 radio jamming, jamming via IoT devices, RAN sniffing and spoofing [47].

  Radio jamming can be impacting on the reference signals, the synchronization signal, the Physical Broadcast Channel (PBCH), the Physical Downlink Control Channel (PDCD), the Physical Uplink Control Channel, or the Physical Random-Access Channel [73]. This would enable an attacker to disrupt the communication by deliberate jamming, blocking or creating interference with the authorized wireless network. Additionally to blocking the communication flow, jamming the synchronization channels 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 the 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 network, jamming of the airlink signals through the IoT devices, 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 time [76]. Most IoT based services are Location Based Services (LBSs) and expect locational awareness with utmost availability. The attackers capable of jamming the GPS receiver will succeed in subduing the service to an inaccurate state [74]. Since the O-RAN interfaces should be open to 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 network configuration details, assisting attackers to optimize and craft their attacks [77]. Vulnerabilities of the PBCH channel are allowing the attackers to sniff the 5G RAN network stats [78]. The open-source and low-cost natures of the software radio are inviting the attackers to exploit the 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 be the main causes targeted through spoofing attempts, that embrace the masquerading signal as a legitimate one [79].

The different components and mechanisms that contribute to the intelligence in the Open RAN network are the Near Realtime 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, which are currently not available. The threats related to intelligence are summarized in Table 6.

• •

  Near-RT-RIC related Attacks: xApps have the capability to manipulate behavior of a certain cell, a group of UEs, and a specific UE. The related attacks are due to either malicious 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 management, a compromised xApp could attempt to take the control 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 devices through the A1 interface, where distinguishing and identifying serving UEs are possible. Such acts violate the location privacy of the important UEs and even the prioritization on the currently serving services can be manipulated. This will leads to compromise RAN performance as well as the privacy violation.

  Malicious xApps can potentially be used as a sniffer for UE identification. In such a circumstance, RAN performance 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 UE 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 possible. In particular, identification and tracking of a certain subscriber, for instance, a Very Important Person (VIP) becomes a real threat. The exposure of the UE identifier is most probable through E2 signaling channels in comparison to its counterpart A1, due to the Near-RT conditions of the E2. Further, such malicious xApps could change the Service Level Agreement (SLA) specifications of the assigned services similar to changing of the priority levels. Such acts could conflict with the Near-RT-RICs decision process as the program execution times might extend beyond the specified boundaries of a presumed Near-RT 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 another xApp or the whole near-RT RIC and often have the 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-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 vulnerabilities to the adversaries while misconfigurations and incompatibilities 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 B (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 appear, both unintentionally or maliciously. This can have an impact on the Open RAN system functions such as mobility management, admission controls, bandwidth management and load balancing, potentially resulting in performance degradation. Moreover, isolation of xApps is critical for the independent operation of O-RAN services and for accurate Near-RT-RIC decision making. Such an isolation or confinement can be penetrated through underlying system vulnerabilities, deducing access information via shared resource applications, or masqueraded authentication attempts. A compromised isolation could subdue the xApp operations to the attacker.

• •

  Non-RT RIC related Attacks: rApps impact non-RT RIC functions such as AI/ML model training, A1 policy management, enrichment information management, network configuration optimization for the purpose of performance degradation, DoS, and enrichment data sniffing (UE location, trajectory, navigation information, and GPS data). rApps bearing many resemblances to xApps in their operational context, have the ability to manipulate the behavior of a certain cell, a group of UEs, and a specific UE. The related attacks are similar to xApps, due to either malicious 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 vulnerabilities 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 extract sensitive information. Also rApp isolation can be exploited to break out of rApp confinement and to deduce information from co-hosted rApps. Unauthorized access provides new opportunities to exploit vulnerabilities in other rApps or Open RAN components to intercept and spoof network traffic, to degrade services through DoS attempts; 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 performance of non-RT RIC [35].

  In addition, rApps in the Non-RT RIC can cause conflicting 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 rApp parameters in question, and the effect that particular conflict 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 different rApps would cause an opposite effect, and implicit ones that different parameter changes would lead to changing the network state. The effects can lead to an overall network performance degradation, or instabilities within the network entities. These conflicts are difficult to mitigate since dependencies are impossible to observe.

  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 vulnerabilities or do not implement authentication and authorization in a proper way. This would allow an attacker to gain 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 envisaged 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 attacks, where the adversary is altering the data sets that are intended for training, testing, or validating [81, 47]. 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, prediction, decision making, model classification, or anomalous detection. The O-RANs openness and the Near-RT operations 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 online ML model is capable of impacting the RIC decision making negatively, especially in terms of radio resource allocation. 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 as 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 utilized by the attackers for gaining access or evading the system’s anomalous detectors for launching transfer learning attacks. Model inversion and membership inference attacks are ensuing privacy leakages [82]. In model inversion attempts, adversary is reconstructing the training data set from the model parameters [86, 87, 89]. This is plausible as there are plenty of online repositories with training data that would aid the attacker in cross-validating the determined data. Membership inference threat would determine whether a particular data set was used in the training process of the ML model or not [88].

  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 unanticipated consequences, which might have an impact on the security or performance [67].

  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 under the Near-RT-RIC. In the long run, the entire RT intelligent framework could become compromised. Model poisoning, 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 impact would be less costly, as the decisions are made from the data gathered from an extended period in comparison to the RT instances.

The following components, Physical Network Function (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 components. Some of these attacks can be applied also in V-RAN 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 against VNFs/CNFs. A lack of security policies to protect mixed PNF-VNF/CNF deployments, resulting to insecure interfaces, could be exploited to perform attacks against VNFs/CNFs, potentially taking advantage of legacy security used by PNFs and not provided by the virtualization/containerization layer [47]. Apart from the security policies, service level agreements and service specifications are vital consensus for the PNF, CNF, and VNF entity deployment. As these entities are envisaged to launch security management entities as specified in [89], the original 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 components used to run a given Open RAN VNF/CNF, modules within an image may have vulnerabilities, introducing malware, missing critical security updates or are outdated. These images are only collections of files packaged together. Therefore, malicious files can be included intentionally or inadvertently within them. In addition, 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 has 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 additional vulnerabilities if deployed in the same system [47].

  Moreover, since many Open RAN VNFs/CNFs require secrets to enable authentication, access control and secure communication between components, these secrets are embedded directly into the image file system. In addition, the images often contain also sensitive components like an organization’s proprietary software and administrator 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 compromise, stealing or damage of the contents on the images. 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, because registries of images are typically trusted as a source of valid, approved software, compromise of a registry can potentially lead to compromise of downstream VMs/CNs and hosts [47].

  There is an increased risk of MITM attacks by intercepting network traffic intended for registries in order to steal developer or administrator credentials within that traffic. This can result in fraudulent or outdated images to orchestrators [47]. Further, typical VNF/CNF based security threats exist, as in: location shift attack where the adversary is capable of displacing the VNF to a domain inheriting a lesser level of security policy assignment with the intention of gaining access, or interoperability issues between 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 behind the holistic autonomic environment of the O-RAN, its security is extremely vital for the O-RAN performance and the individual subscriber security and privacy. Improper 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 O2 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 situations and thus affects availability of the SMO data and functions. Further, an attacker may exploit weak orchestrator configuration, access control and isolation. A single orchestrator may run many different VMs/CNs, each managed by different teams, and with different sensitivity levels. If the access provided to users and groups is not conform their specific requirements, an attacker or careless 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 virtual networks may be possible if VMs/CNs of different sensitivity 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 hypervisor of the hosting OS. Examples of guest OS vulnerabilities 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 in the context of the O-RAN. In this attack, any authorization violations are sought out by the perpetrator exploiting the infrastructure vulnerabilities formed through ill-maintenance or misconfigurations [70]. The administrative capabilities granted to the adversary through this threat is devastating as it could range from a simple excessive allocation of resources to a complete deletion of xApps or rApps [98, 99].

  An attacker may also change the configurations of compromised VNFs/CNFs to consume high amounts of CPU, 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].

  Finally, as the hypervisor provides its own security functions 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 administrator 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 can be extracted, which in turn violates the user privacy and data confidentiality [92, 90].

  Threat	Description	Specific to Open-RAN
  Attack on digital economy	Network communications play an important role in the digital economy of a country and can cause huge damage in case of failure [100, 101] , e.g. shutting down of smart cities, crashing of autonomous electrical vehicles or going dark of factories. In particular, special attention should be given to avoid loss of trust with the users in case of such attacks as they might endanger the entire growth of the network [102].	These threats are very general and in particular related to attacks against the communication infrastructure. There are independent of the usage of Open RAN.
  Espionage	Network communications can be abused to enable espionage [100, 103] and there are currently no regulations for allowing or avoiding collaborations among different suppliers or actors in the network. Without being sure of good intentions of each of the involved entities offering the equipment and software in the network, espionage at all levels, from the government to corporate, might be possible. As a consequence, it is extremely important that proper global ethical restraints are formulated on a global scale.	These threats are very general and in particular related to attacks against the communication infrastructure. There are independent of the usage of Open RAN. However, use of SW make Open RAN more vulnerable than RAN
  Attacks on Critical infrastructure	Network communications play an important role in the operation, management and maintenance of critical infrastructures [100] , like power grids, water supplies, manufacturing and transportation. Since the control of this infrastructure is handed over to the network operators, their responsibilities are of ultimate importance within the O-RAN domain.	These threats are very general and in particular related to attacks against the communication infrastructure. There are independent of the usage of Open RAN.
  Violence against democracy	Besides espionage to dedicated people, also every other citizen can be envisaged. [100] This might be a real threat to the democracy or freedom of speech in the world and it should thus be avoided in any case that one actor receives full control.	These threats are very general and in particular related to attacks against the communication infrastructure. There are independent of the usage of Open RAN.
  Majority attacks and supply chain concerns	It is a danger if there is a significant involvement in Open RAN development from one country or one region, facilitating possibilities for [104, 61] any type of attack. Special attention should be given that no new secret alliances are formed, and therefore a well balanced spread among the suppliers of O-RAN equipment and software is required.	These threats are very general and in particular related to attacks against the communication infrastructure. There are independent of the usage of Open RAN. However, use of SW make Open RAN more vulnerable than RAN

• •

  VM/CN related Attacks: VMs/CNs may be compromised due to flaws in the Open RAN VNFs/CNFs they run. For example, an Open RAN VNF/CNF may be vulnerable to cross-site scripting (SQL) injection [94] and buffer overflow vulnerabilities [95].

  Insecure VM/CN runtime configuration by the administrator 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, 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 infrastructure/services, scan the network to which it is connected to 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/container engine can get access to all Open RAN network data processed 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 resources 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 tenant’s tokens and the administrator rights of the whole Open RAN system can be obtained, [47].

  From the side of the application, trust is required at all levels. 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 secure enclaves [96] have the goal to provide a trusted environment. 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 arbitrary 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 possible after an already comprised hypervisor rollback to a previous snapshot. In the scheduler attack, the vulnerabilities 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 computing, different applications might use the same hardware 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 attacks (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 additional network services on their VMs/CNs in order to do extra monitoring, remote configuration, remote access to other services such as SSH, etc. If these additional network 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, more extra attacks become possible [47].

Due to virtualization and the disaggregated components connected through open interfaces, operators have direct access to all network performance data and operational telemetry data representing activities between/within the different network functions. The integrity of this data is more ensured as this data is created isolated from the functions’ executing environment. Combining this data with security log data results in an earlier detection of security problems and easier detection of the root cause [34, 141, 142].

Note that full visibility can also be a risk. Due to the complexity, the root cause cannot always be easily detected and there is a danger that different vendors will not take accountability for potential issues. Following [144], it is claimed that the time and cost to perform a complete security review would seem to be multiplied by the number of vendors the operators take on board.

Operators can more easily select the vendors offering the best products, meeting the required industry security standards and certifications [34, 141, 142]. Examples of industry best practices are for instance “secure by design” DevSecOps in which information security operations are integrated into DevOps workflows and automated testing in development of containerized applications [145]. The operator can also collaborate with the vendor to determine and influence Continuous Integration/Continuous Deployment (CI/CD) processes with continuous regression testing and software security auditing used by the supplier. Other good practices are the adoption of Supplier Relationship Management (SRM) with an inbound development process and strict security controls for Free and Open Source Software (FOSS), trust stack management with software coming from reliable supply chains and trusted, well-defined operations, intelligent vulnerability management, and multi-vendor System Integration (SI) with continuous verification on vendors sharing the same interpretation and implementation of functions [34, 31].

There are a range of industry best practices that can be adopted including Groupe Speciale Mobile Association (GSMA), National Institute of Standards and Technology (NIST), European Union Agency for Cybersecurity (ENISA), National Telecommunications and Information Administration (NTIA), Center for Internet Security (CIS), Open Web Application Security Project (OWASP), Open Standards, Open Source (OASIS), national cyber security organisations, Building Security In Maturity Model (BSIMM), Cloud Native Computing Foundation (CNCF), the Linux Foundation, SAFECode and CNTT [141, 142].

Integrating independent and individual modules decreases the risk that common coding errors or practices of one single entity impact large parts of the network and thus decrease the attack range. Consequently, diversity helps to balance the security risks. Open RAN enables an expanded pool of vendors on the market, reducing a nation’s dependence on any sole vendor for wireless services [141, 48, 143]. Despite the O-RAN entities being contrived following common and established standards, multiple vendors might embed diverse mechanisms, technologies to meet the standards or guarantees. This will eventually create competition among the vendors for better market returns. This competition can be considered healthy from the security perspective, as the standards might have to be improved from the security front to convince the consumers.

Due to the modularity of the network, operators can switch to a CI/CD operating model, enabling seamless and effective patch management for fixing any detected security vulnerability. As a consequence, the vulnerabilities in the network are faster removed. In addition, updates become more transparent and have less impact on the overall network. Moreover, also operational agility is obtained making it possible to replace functional elements by new versions or capabilities [34, 142]. The CI/CD method combined with the DevSecOps principles can insure individual modules carry out the updates or patches separately, eliminating any opportunity for complete compromise of the system in case of a malicious agent was conveyed via the updating process [146].

Due to the choice among different vendors, modularity and open interfaces, the operator is in the position to demand strong security capabilities and control of its suppliers. For instance, in the case of a cloud architecture, the operator and the cloud infrastructure supplier have a common agreement in which this last one is responsible for the deployment of the latest security tools for detection and prevention [31, 141].

Open interfaces at the different levels give a higher exposure, resulting in more scrutiny and thus higher overall security. Thanks to the open interfaces, operators are not dependent anymore on the supplier in case of (security) issues and can do upgrades themselves, being able to react faster. It also gives the possibility to experiment with new functions and new vendors, exploring new ways to secure the network and its operation [30, 48, 141]. This is at the same time a risk as in order to explore new possibilities by the operator, sufficient qualified people are required, which is not evident due to the complexity of the overall system.

Open-source software presents security challenges regarding its open nature but has the advantage of being verified by multiple independent parties, being rigorously and varied tested, and customized against threats [30].

As mentioned before, the use of open source also includes many risks. It was concluded in the Github 2020 State of the Octoverse Report that vulnerabilities remain undetected in many cases for more than four years, before being disclosed [147]. Therefore, one cannot simply state that open source software is faster patched than proprietary software.

The introduced intelligence in Open RAN can be used to automate the management and control via big data analysis, AI and ML. As a consequence, closed loop responses to changes in the network can be automatically performed. This has the advantage that no human interactions are required anymore, which inherently includes threats like humans accidentally altering the security posture of a network function or maliciously harvesting credentials, changing configurations, or implanting malware within the network [34, 30, 48].

Again, automation can bring risks as previously identified at the ML algorithms.

Open RAN will be developed based on open standards, defined by the Open RAN consortium. Such standards enable to align on a common approach approved by leading members in the field and coordinate all information regarding security threats, vulnerabilities and exploits [34, 141].

A prerequisite is of course the presence of these standards, which are not fully available at the moment. In addition, these standards should be correctly implemented.

Isolation is obtained via the defined interfaces between functional elements in an Open RAN. It offers on the one hand the possibility to insert controls for monitoring and on the other hand allows software updates and patches to be installed with less risk that version dependencies will create issues [141, 10].

Often, there are trade-offs between application, performance and security requirements. Due to the modularity, operators can tailor their deployments and shift more easily the resources for monitoring and control to meet better to these requirements and improve scalability [148]. Also vRAN functional elements can be shifted to provide better isolation [141].

Since operators control the platforms on which virtualized functions run in Open RAN, they have also complete control on the trust infrastructure [149]. The identity and provenance of each functional element is known and managed by using strong cryptographic mechanisms like signature operations. Each new version is validated by the operators and therefore they have control on what is running where on their networks [141].

However, it must be taken into account that the situation becomes more complex as there are more assets and stakeholders involved.

In an Open RAN, there is less dependency between the network software and hardware. This makes it in the first place easier to perform the required upgrades in a faster way. Second, it also avoids risks associated to isolated security breaches [142, 150].

Private 5G networks will soon become the general trend as they enable companies the possibility to fully customize the network according to their specific needs with respect to speed, bandwidth, security requirements, on their locations and own timetable. It will enable companies to offer their customers a dedicated 5G experience, with applications in a large range of domains from healthcare, manufacturing, transportation, education, etc. Companies will have the option to build out and run their own private 5G network, or they can also outsource it to a mobile network operator or systems integrator [151]. One such option is via network slicing, where each slice can be seen as a complete end-to-end network and includes the security capabilities according to the needs [142].

There will be soon many players on the market to launch this innovative network as a service concept, replacing in many cases their existing Wi-Fi and fixed wireless/wired infrastructure.

In traditional network architectures, sensitive cryptographic key material such as for instance Access Stratum keys are more vulnerable to various threats as they are stored at the cell site [152]. In Open vRAN, this key material can be stored deep inside the network in a secure vCU, hosted in a data center [142].

Due to the open interfaces, the operator is able to spread the security analysis throughout the network and include monitoring at the edge. These edge-focused analytics will facilitate the detection and prevention of attacks at the lower part in the network in order to avoid DDoS and to block malicious data from reaching the core network. This is in particular important to support mobility services like services offered by IoT [34, 153].

In zero trust [154], nothing is trusted unless it is verified, regardless of the location. The O-RAN Alliance completely embraces this principle. Therefore, everything needs to be verified and results need to be communicated [34]. Zero trust networking can enhance security in different domains relying on robust standards. First it enables to secure the technology and application stack including all interfaces and APIs. Second, it allows the leverage of the cloud-based nature of 5G and the deployment of cloud security functionality and telemetry. Third, it ensures the tailoring and customization of the security control via network slicing. Finally, it makes it possible to deploy multiple layers of authentication[155].

We have provided a clear taxonomy and an extensive overview of the different types of risks in Open RAN. There are basically three main domains of risks: process, technology and global. The global risks are general and apply for any type of RAN. In particular, we have shown that most of the technical risks follow from basic errors like insufficient mechanisms for encryption, authentication and authorization, improper configuration, software flaws, inappropriate event log management, lack of integrity and availability protection and unprotected physical access. Corresponding risk mitigation measures are provided, which are also related to the identified process risks. Basically, it all falls or stands with well defined standards and policies on all different processes covering the complete lifecycle, which can be clearly implemented, verified and audited in an automatic way. This is currently an ongoing work, but progress is on the way.

As a derivative of C-RAN, Open RAN can inherit many security solutions and practices straight from C-RAN[156, 10]. However, due to its open architecture, it also requires a significant number of unique security solutions. Most of such solutions are required due to their lack of restrictions on O-RUs from different vendors. Open RAN enables blockchain based mutual authentication and privacy preserving P2P communication. Unlike conventional RAN technologies, Open RAN platforms can be upgraded with beamforming functionality and provide a countermeasure against eavesdroppers. Open RAN provides a platform to utilize the full benefit of AI algorithms for security solutions. In addition, many technology related attacks are caused by general design errors and can be mitigated by defining security standards and automation.

A significant amount of additional security benefits have been identified for Open RAN, compared to v-RAN and even 5G networks. However, most of them are closely related to the security risks. For instance, full visibility, selection of best modules, diversity, modularity and open interfaces also bring increased complexity and interdependency, requiring sufficiently trained people and trusted stakeholders. The same holds for open source software, which clearly has several advantages, but also brings several risks as identified here. Another example is the possibility to create an advanced level of automation in the network, but at the same time can lead to vulnerabilities from potential AI/ML attacks. Finally, for the enforcement of security controls and the adoption of open standards, the required standards, processes and policies still need to be fully defined.

The RAN section of the telecommunication domain typically costs around 70% to 80% of the entire cost of the network; and it represent the best opportunity to reduce the cost of the network. In comparison, O-RAN is economically beneficial than PHY RAN or vRAN. The openness of the O-RAN is inviting the vendors to be more competitive with their apparatus, where 30% less amount can be expected on Open Radios and O-RAN software. As proprietary BBUs are replaced by the typical servers, and their cost become less in comparison. According to [157], 32.5% Capital Expenditure (CapEx) savings and 21% Operational Expenditure (OpEx) savings can be expected regardless of whether the O-RAN is configured D or C setting. O-D-RAN in contrast to O-C-RAN has higher CapEx and OpEx values.

The major security repercussions of the O-RAN deployments are forecasted due to its openness of interfaces and modules. Ramifications for such flaws are typically automated security solutions or standards that define secure protocols for communication channels that cover confidentiality, integrity, and accountability; and an automated access control scheme. In addition, an AI or ML driven firewall and IDS facilities are imperative for securing the sub domains. Even with highest level of cryptographic primitives, computation power required for the secure communication protocols can be managed within the available O-RAN resources. The security overhead applicable to the channels are aggregated to the OpEx. The service oriented 5G networks are offering most of its services as cloud based services. Security can also be offered as a service where access control framework, firewall, and IDS facilities can be different flavors of the Security as a Service (SECaaS) use case [158]. These cloud oriented edge leveraged services eliminate the requirement for dedicated hardware; and nullify the required CapEx for launching SECaaS. Such a service can be purchased as a subscription based service that covers the entire O-RAN fronthaul domain, and it can be shared among the other O-RAN services. Hence, OpEx can be manageable. This service outsourcing will allow dynamic scaling ability. For security management and orchestration however, an agent of the SECaaS service should be deployed within the O-RAN for monitoring the security related actions and responses. Substantial amount of CapEx should be allocated for this agent as it requires to be high performing. Considering all these aspects where CapEx and OpEx are allocated for, the cost does justify the benefits granted through the SECaaS based services that would mitigate any disruptions to the O-RAN system.

The Quantum Computing (QC) represents a superior computing power that exceeds almost 158 million times faster than a state-of-the-art supercomputer [159]. The QC manifests an amalgamation of quantum mechanics of superposition, interference, and entanglement. The models that form the QC computations are often based on quantum bits (qbits), where the qbit value scopes higher than a typical computing bit, with its states. With this enormous computing power, QC is an obvious candidate for O-RAN processing core components, specifically for RIC-based computations. A QC enabled core RIC can deliver the real time outcomes of the Near-RT services. In spite of its power, QC based computing requires unique models for performing computing operations. Typical radio resource management and allocation computations might have to adhere to QC models or algorithms for solving the problems.

From the perspective of security, QC is a technology that challenges the complexity of modern applied cryptographic algorithms [160]. The RSA algorithm, which is believed to be unbreakable in the current context, can be broken with a QC employing Shor’s algorithm factoring discrete logarithms. Thus, QC poses a threat to the security of future networks and systems despite its rare existence. As a solution, Quantum Resistance (QR) cryptography was introduced and bares a significant interest among the research community. QR algorithms can be formulated from lattice-based, multivariate, hash-based, or elliptic curve based methods [70]. Thus, O-RAN can leverage the capabilities offered through QC for achieving the guaranteed service level requirements. A Quantum Key Distribution (QKD) infrastructure can be adopted as the PKI for O-RAN internal entities including the xApps and rApps. On the contrary, QR based defense mechanisms should be adopted for signaling and critical channels for improving both the security and efficiency of the O-RAN.

Metaverse is a concept introduced to transcend physical space into a digital reality where all the possible actions in the real-world are enabled within the digitized world. Though the technologies Virtual Reality (VR), Augmented Reality (AR), Mixed Reality (MR), and Extended Reality (XR) are available, a holistic solution that incorporates all these digital visualization technologies is lacking [161]. Metaverse satisfies that void and envisages possibilities beyond measure. The network bandwidth, latency, jitter, availability, and reliability aspects of the RAN should be at its highest capacity to deliver a successful Metaverse [162]. In addition, a significant level of interoperability and flexibility should be maintained within the network to guarantee performance with haptic sensory feedback. The O-RAN is capable of delivering the required flexibility and interoperability within its network. The security concerns of the Metaverse mostly exist in the virtual domain. Therefore, O-RAN cannot guarantee the internal security of the Metaverse; but can secure the network domain via typical security mechanisms.

Digital Twin (DT) technology contrives an exact replica of an object in the digital space. The replica or the twin, however, is formed in a simulated environment where all the actions committed by the actual object and its reactions can be mimicked on its digital counterpart [163]. The main purpose of a DT application is to enable remote controlling and monitoring of apparatus or equipment situated in a factory environment align with Industrial IoT (IIoT) deployments [164]. The DT concept can be visualized as a miniature version of the Metaverse where an interactive interface is formed through AR-based collaborative tools. The O-RAN dynamic and flexible launching of xApps, with their Near-RT standards can facilitate the DT applications successfully. It requires lesser network based requirements than Metaverse. Though, the service rendered by the DT can be mostly critical, and require dedicated service channels with priority. Thus, fronthaul communication channels should embed better security credentials for DT deployments.