Open RAN brings both threats and opportunities for cybersecurity, according to a paper just published jointly by the USA’s Cybersecurity and Infrastructure Security Agency (CISA) and National Security Agency (NSA). Published through the Enduring Security Framework (ESF), a public-private partnership set up by the NSA to address risks threatening critical infrastructure and national security in the country, the paper emphasizes that Open RAN will present MNOs with new issues relating to cybersecurity, even if some of these are positive.
The paper examines security issues relating to O-RAN’s various technical aspects, including multivendor management, the open fronthaul connecting radios to base stations, and the new RAN application framework comprising rApps and xApps. It also looked at associated software developments, notably increased use of AI/ML for RAN optimization, as well as the role of open source code, virtualization and a cloud-based 5G core.
“Security considerations always emerge in new open systems aiming for improved cost, performance, and supply chain benefits,” said Jorge Laurel, ESF project director. “Open RAN shares these security considerations too, and, with continuing efforts by the Open RAN ecosystem, they can be overcome.”
As that comment implies, there is not really anything fundamentally different about Open RAN from any other technological advance in the mobile arena, or any ICT sector. In fact, the innovations brought by Open RAN have already been bedded in elsewhere in the ICT firmament, so that to an extent security issues have already been addressed.
A key change comes with the two related concepts of disassociation and disaggregation within the radio layer, the first breaking the system up into modules and the second then allowing those to be separated to allow cloudification and virtualization. Both of those have been practised for some years in the world of general enterprise computing, so some of the security challenges have been solved already.
The same applies to the rApps and xApps, which are novel to mobile networks to provide greater software vendor diversity but have been applied in the data center arena with use of open source software. This also holds for AI, which is primarily machine learning in this case, where again progress has been made mitigating some of the security threats that arise.
It is true that Open RAN increases the threat surface, in the jargon of cybersecurity, by introducing new threats that did not arise in the era of closed single vendor RANs, or at any rate not to the same extent. It is some of these emerging threats that MNOs must be especially alert to.
These include the broad class of denial of service (DoS) attacks designed to disable a network and prevent users from accessing it effectively, or at all. As the ESF paper notes, DoS attacks are also well known and not unique to mobile networks, but nonetheless do present a risk that needs mitigating in ways that may be specific to the Open RAN implementation. This applies particularly to potential DoS attacks on the open fronthaul connection itself, as that is unchartered territory, comprising the real-time communication and interfaces, as well as the links between the baseband unit (BBU) and remote radio head (RRH), usually over fiber at present, but possibly in future over wireless links in millimeter wave spectrum as well.
As the ESF paper makes clear, the open fronthaul must implement security controls to counter potential DoS attacks against the ability of a mobile network to provide services at the local radio level. “One security concern is unauthorized device access to the open fronthaul network,” the paper points out. Mitigations for unauthorized access include network access control mechanisms, hardening and other Open RU (O-RU) physical security measures, as well as access control over O-RU management functions.
There is also potential for coordinated DoS attacks on multiple radio networks, although that is less specific to the Open RAN technology. Such attacks come under the banner of distributed denial of service (DDoS).
The role of ML in Open RAN is interesting in the sense that it has two roles, to facilitate virtualization for use of lower cost and more flexible commercial-off-the-shelf (COTS) hardware with greater automation, and to enhance the value of the rApps/xApps. This introduces new threats, such as ‘data poisoning’, where subtle malicious changes are made to input data to jeopardize the outcome of an algorithm’s execution in some way.
Such changes can be hard to distinguish from random noise in the data, although ML itself offers some recourse by being able to learn how to separate poisoned data from such noise. Yet, as the ESF paper made clear: “AI and ML algorithms deployed in Open RAN components should be chosen, trained, deployed and updated using approaches that harden them against data poisoning attacks.” At least such attacks have already been studied and mitigations developed in different application contexts.
The rApps and xApps will often be open source, which itself uncovers many of the dilemmas associated with Open RAN security. On the one hand, open source software is by definition transparent and exposed to scrutiny by multiple developers or users. But this assumes all the players have good intentions, as this very exposure also makes the software vulnerable to tampering by so called bad actors, in principle anyway. The use of open source code also tends to introduce new dependencies between components from different vendors, thereby bringing more opportunities for attack, increasing the threat surface again.
There is plenty of experience with open source software security in the general enterprise domain. A number of recent genuine security incidents, as well as simulated attacks, have shown that there is a trade-off, with the advantages also being potential weaknesses. The ESF paper points out various techniques and tools available to reinforce open source software defences, such as Verified Software Bill Of Materials (SBM) and Software Composition Analysis (SCA). SBOMs are designed to verify software integrity continuously and provide alerts in a standard format when security vulnerabilities are detected, or rules are broken. Then SCA operates at a lower level, designed to identify open-source software within a larger codebase and assess security and license compliance, as well as code quality. Both of these remain work in progress, constantly advancing against evolving security threats.
One aspect of Open RAN security barely discussed in the paper is the distinction between public and private networks. Given that one motivation for private networks is their greater security it is natural to consider whether this advantage holds for Open RAN networks. This is obviously an issue, and potential selling point, for providers of on-premise cloud systems, especially those collaborating with MNOs to support migration to 5G.
This is the case for Israeli firm ASOCS, which insists that it is possible to have far more confidence in the security of Open RAN networks if they are private, especially if they are ‘airgapped’ or insulated from the wider Internet, or indeed other corporate networks. In that eventuality, access can only be gained through a device attached to the network, which in turn requires physical proximity. That applies to any internal corporate network and was advanced by some as an argument against cloudification.
The other attack route is via insiders, which is the greatest threat facing many corporate networks and requires defense in depth measures to mitigate by responding to signals of attack such as unusual patterns of activity and acting to close them down or isolate them as quickly as possible.
ASOCS also argues that protecting Open RANs requires cooperation between vendors or deployers of network components and an outside network security company that is independent of them. That applies equally to public or private networks, although major operators and also larger enterprises may have the capabilities to assume this security oversight role themselves.
It is true though that many of the issues discussed in the ESF paper apply primarily to public 5G deployments, with security of private networks being relatively easier to address and even a selling point for them.