Of late, open RAN (O-RAN) has emerged as a technology of choice for telecom operators. O-RAN builds on the foundation laid by 3GPP and includes new functions and open, interoperable interfaces. Unlike traditional RAN, O-RAN decouples hardware and software, thus giving operators more flexibility to deploy and upgrade their network architecture. Decoupling the hardware and software functions reduces the time to market, making it quicker to deploy open networks as compared to traditional ones.
Further, the technology is cost efficient as it reduces operators’ reliance on exclusive vendors and decreases the expenditure incurred on infrastructure. Moreover, open networks can help diversify and reinvigorate the supply chain by promoting competition and innovation. For instance, operators can focus on building and operating a RAN based on mix-and-match components from different vendors.
While there are plenty of benefits of open RAN, there are also certain risks in its deployment, which cannot be undermined. Thus, as the industry evolves towards O-RAN networks, it is important that a risk-based approach is taken in order to adequately address the security concerns surrounding this new technology.
A look at the key security concerns regarding O-RAN deployments and the best practices that can be followed…
Security concerns with O-RAN
Virtualisation and the use of cloud platforms offer the potential to utilise hardware resources better between different applications. However, in doing so, it can also introduce security risks. In fact, recently discovered vulnerabilities such as Meltdown and Spectre reveal that there could be increased security risks when sharing hardware resources.
Industry analysts have highlighted that since O-RAN can be implemented as a multivendor network, each one of the applications can come from a different vendor. This sourcing of applications from multiple places gives rise to a situation
where each application exposes an API to the services it provides and this opens up avenues for potential security risks.
Further, it has been pointed out that since O-RAN network deployment would be heterogeneous, some apps would reside on cell sites, others in an operator’s private cloud and some outside of the operator’s private cloud, for example, on an HCP
cloud. Analysts note that this deployment strategy breaks the prevailing security model in which the operator RAN is secured via a security perimeter. Such a deployment strategy assumes a zero-trust network.
According to Ericsson, in the case of virtualisation 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. Further, as there are different layers between the hardware and its security functions and the application, one needs standardised interfaces and APIs to use the hardware security functions and allow them to attest to and validate the layers above.
Best practices
Keeping in view the security threat posed by O-RAN deployments, it is important to implement key best practices in any complex multivendor environment. This enables vendors and network providers to minimise the exponential impact of certain threats and quickly respond if new vulnerabilities are found.
Secure O-RAN systems may require additional security measures, a trusted stack for software and hardware, and interoperability between vendors with a common understanding and implementation of security requirements. Also, secure network operations are essential across any implementation, with top priority given to protecting the confidentiality, integrity and availability of customer data.
To establish a secure and trusted communication channel (confidentiality and integrity protected) between two end-points, it is imperative to first authenticate each side. For this, a unique identifier and one or more credentials that are kept secret are needed. To protect the credentials in a computer environment, hardware security functionality such as a trusted platform module, a hardware security module and secure enclaves are used to establish a hardware root of trust.
With regard to concerns arising from multiple sources of applications, this can perhaps be addressed by making sure that each app is secured from the network and from other apps. In this architecture, security will be built into each Telcoapp and each app would be responsible for its own security.
