Making sure that Open RAN doesn’t open the door for new risks in 5G

5G has the promise to be *the* foundational platform for the global digital economy by providing secure connectivity for everything and everyone. As the industry evolves towards RAN virtualization, with virtual RAN or Open RAN (O-RAN), it is important that a risk-based approach is taken to adequately address security.

Open ran security 5G

Head of Security, Network Product Solutions

Head of Security, Network Product Solutions

Category & Hashtags

100 ways to build (and secure) a network 

Architectural changes in 5G, broader technological developments and the openness and flexibility of 3GPP have created the opportunity for new use cases and virtualized network deployments to increase flexibility and reduce costs to meet use case-specific requirements.  While 3GPP has standardized many new security improvements with 5G, virtualization throughout the network and a service-based architecture means that security needs to be handled in a new way. 

5G will accelerate innovation and provide transformative use cases across multiple global sectors. However, it will also bring new security challenges for the mobile ecosystem, with broader attack surfaces, more devices and increased traffic loads. We must have networks that are trustworthy, resilient, and secure at every phase of the system lifecycle.  These new security challenges are addressed by 3GPP’s SA3 security work group.  

O-RAN:  Additional functions, interfaces and a modified architecture

Figure 1 O-RAN: Additional functions, interfaces and a modified architecture

Open RAN is the industry’s generic term for an open radio access network architecture. O-RAN refers to the version of Open RAN standardized by the O-RAN Alliance. Building upon the foundation set forth by 3GPP, O-RAN includes new functions and open, interoperable interfaces; this new approach to RAN architecture may provide future benefits such as lower deployment cost (commoditized hardware) and increased supply chain diversity (more vendors) while potentially increasing network integration costs and complexity.  Continued study and further work efforts are required to ensure that security, integrity and resilience of Open RAN architectures are preserved across future deployments; possible focus areas are mentioned below.   

Expanded threat surface 

The introduction of new and additional touch points in O-RAN architecture, along with the decoupling of hardware and software, has the potential to expand the threat and attack surface of the network in numerous ways, including: 

  • New interfaces increase threat surface – for example, open fronthaul, A1, E2, etc. 
  • Near-Real-Time (RT) RIC and 3PP xApps introduces new threats that could be exploited 
  • Decoupling of hardware increases threat to Trust Chain 
  • Management interfaces may not be secured to industry best practices 
  • (not exclusive to O-RAN):  adherence to Open Source best practices   

These and other areas are explored in greater depth in Ericsson’s report, Security considerations of Open RAN.  Many of these items are being studied in several O-RAN Alliance working groups, including the Security Task Group, a consensus-based standards group that will ensure that O-RAN implementations meet the levels of security expected by the industry. Ericsson is committed to providing leadership and guidance in the O-RAN Alliance on these emerging areas of study.  In the meantime, let’s take an in-depth look at just one of these new areas of risk: 

Weakened Links in the Trust Chain 

Virtualization and the use of cloud platforms give the possibility to utilize hardware resources better between different applications, 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 can be increased security risks when sharing hardware resources. 

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 a computer environment, hardware security functionality such as Trusted Platform Module (TPM), Hardware Security Module (HSM), and secure enclaves, are used to establish a hardware root of trust.  

In the case of virtualization and cloud environments, 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, but it must trust the layers underneath to attest that the node, layer or data set has not been compromised. For example, a node could request a valid service, authenticate correctly to the system and be authorized to use that service yet still represent a malicious threat if it is running on compromised firmware.  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 and allow those to attest to and validate the layers above. Together with standardized and interoperable APIs, there must also be a transparency to how the different layers use and provide the security functions in the chain, especially as different hardware vendors may have different security functions, capabilities or implementation variances. 

Risks relevant but not exclusive to O-RAN 

Risks relevant but not exclusive to O-RAN

There are other areas of concern that, while not exclusive to O-RAN, should be considered due to the additional risks posed. It is recommended that vendors practice a higher level of due diligence and care in regard to the use of Open Source code, including cataloging and tracking, an inbound process for vetting code with dynamic and static testing and full integration to existing software lifecycle practices. Recognized industry best practices include security-by-design principles from SAFECode and OWASP SAMM.   
Additionally, third party hardware may require an additional layer of security assurance and checks to ensure that end-to-end integrity of the components and a trustworthy, secure supply chain are maintained.  Relevant recommendations in this area can be found in the current NIST SCRM guidelines and the ongoing work of DHS’s ICT SCRM Task Force.   

Security best practices for open, interoperable network systems 

It is important to implement security best practices in any complex multi-vendor environment; this enables vendors and network providers to minimize the exponential impact of certain threats and quickly respond if new vulnerabilities are found or exploited. 

Several service providers intend to leverage virtual RAN in an Open RAN architecture to build secure, open, interoperable, disaggregated, virtual networks based upon industry standards. As the industry evolves towards RAN virtualization, with 3GPP or O-RAN, it is important that a risk-based approach is taken to adequately address security risk. Secure Open RAN systems may require additional security measures not yet fully addressed, a trusted stack for software and hardware, and interoperability between vendors with a common understanding and implementation of security requirements.  Lastly, secure network operations are essential across any implementation, with top priority placed on protecting the confidentiality, integrity and availability of customer data.  

Open RAN


We recommend that O-RAN implementations provide the following security measures: 

  • Protect expanded threat surface due to more interfaces and functions  
  • Limit risks associated with Near-Real-Time RIC, especially as related to control framework vs policy guidance capabilities and potential conflicts of xApps 
  • Address threat to Trust Chain introduced by decoupling of functions by enforcing hardware-anchored trust mechanisms (certificates, for example) which can validate other layers 
  • Ensure management interfaces are secured according to industry best practices using TLS and digital signing 
  • Practice a higher level of due diligence and implement mature and secure DevOps practices when utilizing Open Source code  
  • Implement defenses from physical attacks 

Ericsson will continue its leadership role within the O-RAN Alliance and its Security Task Group to incorporate security best practices, ensuring that new deployments are ready to meet the level of security, resilience and performance expected by service providers and their customers. Ericsson’s integrated and open network solutions, built upon a resilient, flexible and high-integrity supply chain, will allow our customers to deploy robust, secure and trusted 5G networks.   

With any nascent technology, including O-RAN, security cannot be an afterthought and should be built upon a security-by-design approach. Ericsson will continue to drive standards that give suppliers and carriers a common, transparent and well-established technical foundation of interoperability and security. 

To learn more, read our paper Security Considerations of Open RAN, and visit Ericsson Security

Jason S. Boswell, CISSP 
Head of Security, Network Product Solutions 
Ericsson North America 

Discover more

Read Jason’s previous blog post, 5G network security is national security.
Read our blog post on security standards and their role in 5G.
Read about Ericsson in the US.
Follow Jason S. Boswell on Twitter.

Open RAN Challenges and Opportunities


The Ericsson Blog

Like what you’re reading? Please sign up for email updates on your favorite topics.

Subscribe now

At the Ericsson Blog, we provide insight to make complex ideas on technology, innovation and business simple.