|
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.
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.”
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.
Prakash Sangam -
Principal Analyst at Tantra. |
