Tantra Analyst

How to secure cloud-native 5G virtual and Open RAN infrastructure

Ever since the cloud-native virtual RAN (vRAN) and Open RAN architectures have started gaining popularity, one key question both proponents and adversaries have been asking is “What about security?” Considering the massive number of services and critical applications that 5G will connect, security risks couldn’t be higher. 

Some contend that any disaggregated, virtualized, multi-vendor system will naturally have security vulnerabilities. Others challenge that assertion and suggest that an expansive open ecosystem with many large players will make the system inherently more robust. 

No matter which view you hold, the best approach is to have a dedicated hardware-based, AI-powered onboard security. Let’s explore why and what it takes to bring such security.

Basics of cloud-native virtual and Open RAN architecture

The security mechanism in traditional RAN networks is relatively straightforward because all the software and hardware in the baseband is proprietary and supplied by a single vendor. But it is not so in new architectures.  

In vRAN, the software is disaggregated and runs on off-the-shelf hardware, and in Open RAN that software comes from many different vendors. In a cloud-native approach, the software is containerized, that is, the monolithic RAN baseband software is divided into many containerized microservices: PHY, RLC, MAC, transport, and other functions. These microservices are orchestrated in a Kubernetes cluster. The 5G infrastructure providers have realized that the cloud-native approach used in data centers by cloud service providers (CSPs) is the best architecture to leverage for scalability and efficiency. So, using that same infrastructure and the same Kubernetes architecture saves them from reinventing the wheel. That being said, they must deal with the same issues the CSPs do regarding security, disaggregation, and latency with a focus on those aspects as they pertain to 5G use cases.

Microservices must securely communicate with each other to function. This communication is usually managed by a cloud-native entity called “service mesh” such as Istio. There are two parts in a service mesh: (1) the control plane that sets up the communication channels between the microservices, and (2) the data plane, that manages the transfer of actual data. For our discussion here, we focus on the control plane, as it is much more crucial from a security point of view. 

Microservices are heterogeneous and highly distributed. They can run on multiple different servers that are geographically and logically separated, and they might be supplied by different vendors, each providing different baseband functions. Additionally, if vRAN is hosted on the public or shared cloud, microservices from different cellular operators or even non-operators could be running on the same cloud infrastructure. In such a case, one could imagine the complexity of the implementation and the large attack security surface involved.

Another important dimension of this cloud-native architecture is latency. Microservices are transient entities that are created and broken down in terms of milliseconds. Further, the microservices activity in telco clouds is magnitudes higher than other clouds, mainly because of user mobility. For that reason, securing the microservices while managing the latency is even more crucial, especially for 5G URLLC (Ultra Reliable Low Latency Communications) applications and services. So, the timing involved in the creation, as well as the communication between microservices directly impacts the system performance. 

Securing cloud-native virtual and Open RAN

Service mesh enforces policies upon the microservices the Kubernetes cluster manages, including where they are running and how they are connected. Service mesh uses certificates to authenticate the microservices and crypto keys to encrypt the communication between them.

The traditional approach is to run the service mesh in the software, on the underlying layers, say, in the operating system. In that case, the certificates and keys are generated, stored, and managed locally. Letting the security reside in software makes the whole RAN network extremely insecure, and highly susceptible to attacks. 

The best and most comprehensive option to secure cloud-native RAN networks is to relegate all the key security functions, including the service mesh, to a dedicated purpose-built ruggedized processor. A good example of such a processor is the Trusted Control/Compute Unit (TCU™) offered by a leading security solutions company Axiado. Gopi Sirineni, CEO of Axiado, explains “TCU is a state-of-the-art secure processor with hardware root-of-trust (based on its immutable hardware ID), secure boot, secure storage, and Trusted Execution Environment (TEE). He adds, “Such a processor will be tamper-resistant, it can store and manage keys certificates safely, and provide a holistic security cover for the whole system.” 

Side note: You can read more about this approach in this article that Gopi and I have cowritten- AI-powered, hardware-based preemptive security is a game-changer.

Some cloud-native systems utilize a third-party cloud-based service mesh. But that adds latency to the system. To meet the stringent latency requirements of 5G RAN, especially for URLLC applications, a secure processor must be onboard and within proximity to where the microservices are being run.

Some might suggest that most of the vRAN microservices, such as PHY, RLC, and MAC, are always running, and may not require frequent authentication. Hence service mesh can be run remotely on the cloud. However, the biggest promise of cloud-native architecture is enabling extreme RAN scalability—instantly upscale and downscale capacity where and when needed. Running microservices round-the-clock significantly degrades this benefit.

As is true in the non-telco ecosystem, security in the 5G ecosystem is often reactive with pre-defined rules based on known threat behaviors. A robust service mesh system must not only facilitate secure communications but also observe and identify suspicious behavior. Hence the dedicated security processor should also have AI capabilities so that any potential security threat can be proactively identified and stopped before any damage. AI capability also helps in continuously learning and adapting to the constantly changing security risk landscape. This critical supplement to more traditional security measures will be recognized as a necessity moving forward as the growth of the vRAN footprint attracts an equally growing opportunity for bad actors.

In closing 

While the cellular industry is moving toward cloud-native, vRAN, and Open RAN architectures, security is one of the fundamental challenges. With software and hardware disaggregated, being supplied by many different vendors, it is extremely risky to rely on the security of each of the components or only on a software-based approach.

The best option is to utilize a dedicated hardware-based, on-board, AI-powered approach that can provide holistic, future-proof security.

If you would like get more articles like this, and an up-to-date analysis of the latest mobile and tech industry news, sign-up for our monthly newsletter at TantraAnalyst.com/Newsletter, and listen to our Tantra’s Mantra podcast.