On BSI’s findings on Open RAN security

Security teams should take control

To answer that question, security teams should first understand that the O-RAN and 3GPP specifications aim for world-wide inter-operability. In the context of security, that often comes down to making certain features or protocols mandatory to support, but optional to use due to regulatory constraints in some regions. The implication for security teams is that they should make sure they are at the negotiation table when Open RAN technology (or in fact any technology) is procured. That way, they can tell the vendor which ‘optional to use’ features should be turned on by default and which features (security or non-security) should be turned off or removed from the product all together.

Some security teams may also opt to go one step further by deciding to knowingly deviate from the standard. For example, they could mandate vendors to implement additional or different security features. Even though this might break compatibility with the standards, there is no inter-operability problem if security teams do this consistently across the entire deployment. The downside is that the security teams may have to account for the additional costs. Regardless of which approach the security team decides on, they should take control of all the security features and not solely rely on specifications.

Security teams should adopt some recommendations now

The BSI commissioned study lists recommendations to be included in the specifications rather than recommendations to security teams. The requirements are therefore not ready for security teams to use directly and some are downright impossible without serious effort from the industry as a whole. Still, some of the issues identified can be addressed by security teams already today by proactively mandating adequate security controls.

For 3GPP specifications, the study recommends (amongst others) to make optional security features mandatory. However, simply mandating all optional features may not work. For example, some devices have bandwidth limitations when user plane integrity protection is enabled. The recommendation we would give is similar to what we wrote before: security teams should evaluate which optional features should be mandated and instruct vendors and system integrators accordingly.

For O-RAN specifications, the study also recommends making optional security features mandatory. In addition, the study recommends the removal of outdated and weak security protocols and configurations. Similarly, we recommend security teams take control and mandate features they require and demand removal of unwanted, weak security features.

Moreover, we suggest security teams to go one step further. Not only should they require turning on optional features and removal of weak security, they should also request removing any unused features from the product altogether.

Further recommendations in the risk analysis that security teams could directly consider are:

• To protect data at rest;
• To secure the communication between rApps;
• To disallow the usage of SSH2 in favor of TLS;
• To secure the connection to external data lakes; and
• To only program xApps/rApps with secure programming languages.

Compared to making optional features mandatory, these requirements are more open-ended. If a security team would want to address these requirements now, they would also have to design the solution.

The study provides more recommendations for 3GPP and O-RAN than the ones that we discussed. At large, those recommendations are primarily targeted at the technical specifications. In contrast, we recommend that security teams design a cloud security architecture that mitigates most of the risks and considers the limitations of the 3GPP and O-RAN designs. This, to us, seems to address many of the underlying concerns. 

A way forward

The BSI commissioned study provides a detailed a risk assessment of the O-RAN specifications. It also outlines concrete recommendations for improving these specifications. However, it falls short at providing actionable advice to security teams faced with Open RAN technology right now. In this blog post, we highlighted hat security teams should take control. They should mandate which features should be included or excluded and not solely rely on the specifications. Even though this might break compatibility with the standard, we believe that to be the best choice at this point in time.

We find that waiting until the study’s recommendations are implemented is unrealistic: The adoption of Open RAN will be driven by business reasons. Therefore, security teams will have to design an architecture to secure Open RAN deployments. And in that design they should account for the risks the BSI commissioned study identified.

Note about O-RAN and Open RAN

Open RAN is the overall movement by mobile network operators to separate hardware and software and create open interfaces inside the RAN. Open RAN is therefore more of a concept. O-RAN refers to the O-RAN Alliance who produces specifications that implement the Open RAN concept.

Some further reading

BSI press release (in German)

Link to the BSI study (in German)

“White Paper: Securing Open, Virtualized Radio Access Networks”, by Wenovator (now Deloitte)