Security considerations of Open RAN

xApps conflict scenarios

The xApps in the Near-RT RIC can be provided by different vendors. For example, one vendor can provide the xApp for mobility management and another vendor provide the xApp for load balancing. This creates the risk that different xApps will take conflicting decisions, unless they are properly coordinated. For example, the xApps for mobility management and load balancing can trigger different handover decisions at the same instance in time for the same user with the risk to trigger a radio link failure. In ORAN WG3 specifications, O-RAN.WG3.RICARCH-v01.00, the following possible conflicts between xApps are identified:

• Direct conflicts: different xApps request change for the same parameter.
• Indirect conflicts: different xApps request change to different parameters that will create opposite effects, for example, antenna tilt and measurement offset.
• Implicit conflicts: different xApps request change to different parameters that are not creating any obvious opposite effect but result in an overall network performance degradation. These conflicts are most difficult to mitigate since dependencies are impossible to observe.

Performance degradation and instabilities that result from these xApps conflicts introduce vulnerabilities that could be exploited by threat actors. O-RAN is working on solutions to mitigate the impact of these identified xApps conflicts. However, as of today, no solution is defined in the specifications. Indirect and implicit conflicts are especially difficult to mitigate due to lack of observability.

xApp Root of Trust

xApps in the Near-RT-RIC have the capability to manipulate behavior of a certain cell, a group of UEs, and a specific UE. A malfunctioning xApp from a 3PP could potentially cause issues on the network.  For example, the xApp could track a certain subscriber or impact service for a subscriber or a dedicated area. In addition, an xApp can receive order via A1 to control a certain UE and if a malfunctioning xApp receives an order to prioritize this UE, then the owner of the malfunctioning xApp knows a VIP that they want to track is in a certain area. With this command exposure, the attacker can obtain a rough location of a very important person and change the order from prioritize to deprioritize for a UE. In order to mitigate these risks, a solid trust chain, preferably from hardware up to the applications, (in this case 3PP xApp) is necessary, which makes it possible to authenticate xApps before loading and starting them.

UE Identification in the RIC

As the E2 interface (similar to A1 interface) can point out a certain UE in the network, this will create a correlation between the randomized (anonymized) UE identities between the RAN nodes. For example, a 3PP xApp can potentially be used as a “sniffer” for UE identification. The additional challenge for the Near-RT RIC / E2 compared to the Non-RT RIC / A1 is that more frequent signaling is expected over the E2 interface to enable near-real-time operation. Therefore, the UE identifier will be exchanged more frequently over the E2 than over the A1. To alleviate this, Ericsson is proposing solutions that reuse randomized UE identifiers defined in 3GPP over the E2 and A1 interfaces. These solutions are currently under discussion within the O-RAN Alliance for inclusion in future releases of the specifications.

Decoupling increases threat to Trust Chain

Virtualization and the use of cloud platforms give the possibility to utilize hardware resources better between different application, but it will also introduce security risks as isolation between applications are only “logical” in software without physical isolation across hardware resources. Recently discovered vulnerabilities like Meltdown and Spectre reveal that there are security risks when sharing hardware resources. More vulnerabilities are likely already part of firmware and software to be discovered in the future.

A cloud-native or a virtualized environment includes many different layers, each with its own security functions. From an application perspective the use of all these security functions at the different layers involves trust at all layers. The host operating system has access to all RAM memory, disk volumes mounted on virtual machines, and containers. This means that a malicious host operating system can get access to all data processed in the workloads. There are techniques in newer CPUs/chipsets that intend to provide trusted computing like secure enclaves. In this case, a workload can use a secure enclave to protect data and processing from the host system, but the application will be hardware-instance dependent.

The virtualization layer includes the hypervisor that is executed on the host environment and is providing its own security functions and APIs to the host systems security functions. Hardware security functions also need to be accessed via the hypervisor as APIs, which means that the hypervisor (and cloud environment) can intercept all security functionality from the lower layers and hence needs to be trusted if these security functions are used. To get a fully trusted virtualized application, one needs to trust all the layers in the stack from hardware to firmware to virtualized software, as it is impossible to protect a virtual machine or containers from the host system.

In a cloud-native environment using containers there is no hypervisor. A container management system, for example, Docker plus the Linux kernel, provides isolation between the host operating system and the container environment. Containers don’t have a full operating system and use name spaces to isolate from other containers. Containers on shared hardware resources are not meant to be used in multi-tenancy environment. Separate hardware and k8s clusters are needed for multi-tenant workloads.

To establish a secure and trusted communication channel between two endpoints, one needs first to authenticate each side before a secure (confidentiality- and integrity-protected) channel can be established. To authenticate each endpoint, a unique identifier and one or more credentials that shall be kept secret are needed. To protect the credentials in computer environment, hardware security functionality such as Trusted Platform Module (TPM), Hardware Security Module (HSM), and secure enclaves, is used to get a hardware root of trust. Newer processors and chipsets also provide secure enclaves so specific software and date can processed in an isolated part of the processor.

In the case of virtualization and cloud environment, there are many layers that need to be considered to ensure the trust chain is maintained between applications and the underlying hardware. The authentication process is the base for establishing a secure communication channel based on the security association established in the authentication process. As there are different layers between the hardware and its security functions and the application, one needs standardized interfaces and APIs to use the hardware security functions. This is important as different hardware vendors may have different security functions. Together with standardized and interoperable APIs, there must also be a transparency into how the different layers use and provide the security functions in the chain. Security assurance and supply chain best practices will give a better transparency.

Management interfaces may not be secure to industry best practices

O-RAN’s O1, O2, A1, and E2 are the new open interfaces that allow software programmability of RAN. These interfaces may not be secured to industry best practices.  For example, the use of SSH on the O1 interface does not meet industry best practice. The O-RAN O1 interface allows optional use of TLS (reference O-RAN-WG1.O1-Interface-v02.00), but industry best practice recommends use of TLS.  An implementation that does not implement TLS, since it is optional, may become the key source of vulnerability that a malicious code will exploit to compromise the RAN system. The O1 interface should meet industry best practice to establish a secure management connectivity based on strong digital identities, such as X.509 certificates, with mutual authentication, confidentiality and integrity protection using TLS. In addition, access controls for 3PP hardware should also be implemented to maintain the trust chain.

Increased exposure to public exploits due to use of Open Source code

The O-RAN Software Community is a Linux Foundation project, supported and funded by O-RAN to lead the implementation of the O-RAN specifications in Open Source; further guiding security principles and overviews of using Open Source software can be found at https://www.o-ran.org/software, https://o-ran-sc.org/, https://www.lfnetworking.org/ and https://www.linuxfoundation.org/blog/blog/how-o-ran-sc-completes-the-open-source-networking-telecommunications-stack. Industry has recognized that Open Source code introduces security risks. Open Source vulnerabilities are publicly available on the National Vulnerability Database (NVD). While this is intended for developers to disclose vulnerabilities, it is also used by hackers to exploit those vulnerabilities. Vulnerabilities frequently propagate as developers re-use free open source code enabling backdoors to attacks. Vendors using Open Source code must enhance its security by applying industry coding best practices as described in the Security Best Practices section. There have been notable vulnerabilities from downloading open source libraries and dependencies, as well as supply chain risks when downloading Open Source code from untrusted repositories. It is recommended that vendors practice a higher level of due diligence for exposure to public exploits when using Open Source code. Recognized industry best practices include security-by-design principles from SAFECode and OWASP SAMM and supply chain security from NIST SCRM and CISA ICT SCRM.

Lack of defense from physical attacks

Use of 3PP hardware opens a new attack surface of physical attacks. Physical attacks include adversarial threats against power to disrupt availability, or hardware interfaces to gain access to information. It is expected that requirements to protect against physical attacks will persist for virtual deployments running on third-party hardware. Potential new risks from physical attacks, as well as applicable mitigation techniques, are ongoing areas of study. Some National Institute of Standards and Technology (NIST) recommendations are provided here.
NIST SP 800-161, Supply Chain Risk Management Practices for Federal Information Systems and Organizations, FAMILY: PHYSICAL AND ENVIRONMENTAL PROTECTION states that “The physical and environmental protection policy should ensure that the physical interfaces of the ICT supply chain infrastructure have adequate protection and audit for such protection.”
NIST Special Publication 800-82 Guide to Industrial Control Systems (ICS) Security, Table C-5 Physical Vulnerabilities and Predisposing Conditions includes hardware vulnerabilities due to radio frequency, electromagnetic pulse (EMP), static discharge, brownouts and voltage spikes. NIST recommends that hardware provide proper shielding, grounding, power conditioning, and/or surge suppression.

It is important to implement security best practices in a multi-vendor environment using Open Source code to build open, interoperable, secure network systems. This enables vendors and network providers to minimize the number of vulnerabilities and quickly respond in case a new vulnerability is found or exploited. These best practices should be implemented by each vendor at the individual product level and by the service provider at the network level:

• Life Cycle Management (LCM) with early integration of security to implement “security by design”
• Continuous development and continuous integration (CD/CI) with continuous regression testing and software security auditing
• Supplier Relationship Management with an inbound development process and strict security controls for FOSS
• Trust stack with software anchored to reliable, trusted supply chains and trusted operations with well-defined processes to reduce risk
• Vulnerability management with intelligence to continuously track, identify and remediate vulnerable applications
• Multi-vendor system integration (SI) with continuous verification to ensure all vendors share the same interpretation and implementation of functions

Vendors should ensure that its software meets 3GPP SA3 Security Assurance Methodology (SECAM) and GSMA Network Equipment Security Assurance Scheme (NESAS) guidelines for development and testing process. A holistic approach across technology and services ensures that security is built in from the start, across supply chain, software and hardware development, testing, implementation and operation. The vendors should also consider security assurance across the product life cycle. For example, Ericsson’s process takes a holistic approach across technology and services ensures that security is built in from the start, across supply chain, software and hardware development, testing, implementation and operation. The Ericsson Security Reliability Model provides risk assessment, privacy impact report, secure code review, vulnerability analysis and hardening guidelines for every release. Product Security Incident Response Team (PSIRT) keeps track of any new vulnerabilities that are found outside of that process and is ready to act on customer product security incidents and reported security issues affecting Ericsson products, solutions and services.  

Additional information about 5G security best practices can be found here.