Security risks and requirements are shifting as CSPs transition to 5G networks. The service-oriented architecture of the 5G core network introduces a broad range of data and services than 4G, increasing the attack surface. The common web protocols and APIs of 5G networks expose more attack vectors. Containers used in the RAN shift the security responsibilities to VMs and the development and operations lifecycle. Kubernetes and cloud-native patterns require security enhancements to lock down API interfaces, manage microservices, protect network endpoints, and so on.

Security challenges of an Open RAN are similar to other telecommunications systems such as RAN systems. As more devices connect to a 5G network through the RAN, the need to prevent denial of service attacks and attempts to subvert authentication systems grows.

The trust model has also evolved with the introduction of standalone 5G systems. According to 3GPP, trust within the network for a standalone 5G system decreases as the system aspects move away from the core. This change in the trust model can affect the risk profile for the RAN, especially for DUs deployed in the public domain. CUs are deployed at sites with more restricted access.

Note:

For more information, see 3GPP 5G Security.

As a non-standalone 5G system supports different access networks including previous generations such as 4G, it inherits the risks of those previous generations. Hence, the industry groups creating specifications, such as the O-RAN Alliance, and the CSPs implementing RANs for 5G must perform rigorous threat modeling and risk analysis for the RAN.

Risks and attack vectors in an Open RAN

Some of the risks and attack vectors in an open RAN are as follows:

  • The recent supply-chain attacks on commercial software vendors indicate the importance of using secure development processes, DevSecOps approaches, end-to-end protection for CI/CD pipelines, signed code provenance, and other forms of protection.

  • The usage of emerging technology such as artificial intelligence in the RAN can introduce new risks and attack vectors.

  • The rise of IoT and the growing number of connected devices increases the risk of attacks by compromised devices.

Potential risks and vulnerabilities in O-RAN

The O-RAN Alliance’s architecture for an Open RAN includes additional risks or potential vulnerabilities:

  • The disaggregation of the CU and DU causes a new attack vector in the open fronthaul interface, which operates in the lower-layer split (LLS) interface.

  • Unauthorized access to a component or a control or user plane, such as the DU or the CU control plane, degrades RAN performance or compromise network availability

  • Disabling over-the-air ciphers to eavesdrop on traffic

  • Strict latency requirements can affect how security controls such as encryption are implemented and managed on the Open Fronthaul Interface.

  • RAN intelligent controller (RIC) in the O-RAN architecture accesses user-sensitive data that require additional protection. The RIC exposes this sensitive data to RAN applications developed by multiple vendors. Another potential vulnerability is Near-RT RIC conflicts with O-gNB or between third-party applications.

  • RAN applications and microservices running or connected to the near-real time and non-real-time intelligent controllers, require code signing, isolation, secure lifecycle management and patching, vulnerability management and scanning, monitoring, and tight security controls to protect access to network and subscriber data.

Vulnerabilities and exploits that can be exposed with insufficient security

The components, network functions, or applications that are deployed without the following security best practices cause vulnerabilities:

  • Disaggregation can cause vulnerabilities if hardware roots of trust and code provenance are not in use.

  • Unprotected or improperly isolated management interfaces

  • The inadvertent use of insecure designs, architectures, or interfaces.

  • Misconfiguration, insufficient isolation, weak authentication, or imprecise access control for applicable components and interfaces.

  • Improperly deployed or managed Kubernetes, containers, operating systems, the container image registry, and other cloud-native technology can cause vulnerabilities or introduce new attack vectors.

  • Container images for CNFs and 5G services require code provenance and protection as they move through a CI/CD pipeline. If container images are not stored securely, protected by role-based access control, scanned for vulnerabilities, and signed as trusted, they can contain vulnerabilities or exploits that surface after deployment.

Protecting against threats in an O-RAN architecture with VMware

The O-RAN threat modeling and remediation analysis v1.0, published by the O-RAN Alliance Security Focus Group, in March 2021, contains a comprehensive list of potential vulnerabilities and threats.

Some of the vulnerabilities and threats that are specific to VMware Telco Platform RAN or other VMware technology are addressed in the following sections.