Securing the RAN #4: From Security Standards to Operational Defense

Introduction: Translating Standards into Daily Operations

Securing the Radio Access Network (RAN) requires more than understanding its architecture or identifying individual threats. It requires connecting how the network operates, how adversaries can exploit the radio interface, and how standardized security mechanisms can be translated into effective operational controls. Across this series, the discussion has progressed from RAN architecture and protocol behavior to threats such as False Base Stations (FBS), protocol downgrade attempts, radio frequency (RF) jamming, and user-plane manipulation, together with the security mechanisms introduced across 3rd Generation Partnership Project (3GPP) releases, including Subscription Concealed Identifier (SUCI) and User Plane Integrity Protection (UPIP).

However, a significant operational gap can exist between standardized security mechanisms and their implementation in production networks. Security controls defined in specifications such as 3GPP Technical Specification (TS) 33.501 depend on correct configuration, deployment, monitoring, and lifecycle management. Misconfigured security policies, insufficiently protected transport links, or weakly secured management interfaces can undermine otherwise strong security mechanisms ¹.

This final installment focuses on translating these security mechanisms into operational practices. It examines base-station hardening, proactive threat hunting using radio and network telemetry, and the application of Zero Trust principles ² across traditional and disaggregated Open RAN (O-RAN) environments. The goal is to provide practical guidance for security engineers, network administrators, and telecom Security Operations Center (SOC) analysts responsible for protecting modern RAN infrastructure. Figure 1 provides an overview of how security controls span the user plane, control plane, management layer, and SOC operations in a modern RAN environment.

Base Station Hardening: Eliminating Weak Baseline Configurations

A modern 5G next generation NodeB (gNB) is a distributed, software-driven system that may operate across virtualized or cloud-native infrastructure. Hardening this environment requires systematic configuration management, secure algorithm selection, protection of cryptographic keys, and continuous verification of security policies.

Enforcing Cryptographic Algorithm Policies and Restricting Null Algorithms

3GPP TS 33.501 defines the cryptographic algorithms used for confidentiality and integrity protection in 5G. For ciphering, these include 128-NEA1, based on SNOW 3G, 128-NEA2, based on Advanced Encryption Standard (AES), and 128-NEA3, based on ZUC. Corresponding integrity algorithms include 128-NIA1, 128-NIA2, and 128-NIA3. The specification also defines the null algorithms NEA0 and NIA0, which provide no confidentiality and no integrity protection, respectively.

Null algorithms have specific uses within 5G security procedures. In particular, NIA0 is permitted for unauthenticated emergency sessions where such services are required by local regulations. 3GPP requires NIA0 to be disabled in gNB deployments where support for unauthenticated emergency sessions is not a regulatory requirement ¹.

To reduce the risk of weak algorithm selection, operators should maintain locally configured and prioritized lists of permitted ciphering and integrity algorithms. Algorithm selection should consider both the User Equipment (UE) security capabilities and the security algorithms allowed by the serving network. Non-null algorithms should be prioritized for normal authenticated services, while the use of null algorithms should be restricted to explicitly permitted scenarios and applicable regulatory requirements. Figure 2 summarizes the main hardening areas discussed in this section, including cryptographic algorithm selection, integrity protection, and secure key management.

Operational Enforcement of UPIP

While encryption protects the confidentiality of user-plane traffic, it does not by itself guarantee that transmitted data has not been modified. UPIP adds integrity protection to user data exchanged between the UE and the Next Generation Radio Access Network (NG-RAN) at the Packet Data Convergence Protocol (PDCP) layer, as shown in Figure 3.

In 5G, user-plane integrity protection can be configured for a Protocol Data Unit (PDU) session according to three policy levels: Required, Preferred, or Not Needed ³. The Session Management Function (SMF) determines the applicable User Plane Security Enforcement policy using the subscribed policy received from the Unified Data Management (UDM), locally configured policy for the relevant Data Network Name (DNN) and network slice, and the UE’s supported integrity-protection data rate.

For services that require stronger protection against user-plane data manipulation, operators can configure UPIP as Required. When UPIP is set to Required, the NG-RAN must enforce it for the PDU session. If the NG-RAN cannot satisfy the required protection, it rejects establishment of the corresponding user-plane resources, and the SMF may release the PDU session. Operators should therefore consider service requirements, UE capabilities, and supported integrity-protection data rates when defining policies for sensitive enterprise, industrial, or other high-assurance services.

Cryptographic Key Lifecycle Management and Secure Key Storage

Subscriber privacy in 5G relies on the SUCI to protect the Subscription Permanent Identifier (SUPI) when it is transmitted over the air. For non-null protection schemes, the UE generates the SUCI using the Home Network Public Key that has been securely provisioned under the control of the home network.

The corresponding Home Network Private Key is securely protected within the home network and used by the Subscription Identifier De-concealing Function (SIDF), which is provided by the UDM, to recover the SUPI from the received SUCI. Protecting this private key is critical because compromise of the key could undermine subscriber identity confidentiality.

Operators should therefore establish secure lifecycle procedures for subscriber-privacy keys, including controlled provisioning, protected storage, key replacement when required, and restricted access to the SIDF. Security mechanisms used to protect these keys should also consider physical attacks and unauthorized access to the UDM environment.

Threat Hunting and Telemetry Analysis across the Radio Interface

Because radio signals propagate through open physical space, attackers can target the RAN without requiring direct physical access to core network infrastructure. Proactive RAN defense therefore depends on continuous monitoring and correlation of radio measurements, network telemetry, configuration data, and security events.

As shown in Figure 4, FBS detection can combine telemetry collection, anomaly detection, correlation with known network information, and escalation to the SOC for further investigation.

Signatures and Telemetry Indicators of False Base Stations

False Base Stations may attempt to attract nearby UEs by transmitting stronger signals or manipulating broadcast and cell-selection information. Because similar anomalies may also result from legitimate network conditions, such as congestion, interference, mobility events, or configuration errors, individual indicators should not be treated as standalone proof of an attack.

“Confidence in radio threat detection comes from correlation, not from a single signal.”

SOC and network operations teams can correlate multiple telemetry sources to identify suspicious behavior. Cross-layer analysis of physical, radio, and network measurements can improve the detection of abnormal or potentially rogue gNB behavior ⁴. Relevant indicators may include:

• Abnormal Signal Strength: Unexpectedly strong Reference Signal Received Power (RSRP) from an unrecognized or inconsistent cell may indicate a rogue base station attempting to attract nearby UEs.
• Radio Resource Control (RRC) and Registration Anomalies: Unusual increases in RRC setup failures, rapid connection releases, repeated registration attempts, or unexpected mobility behavior within a localized area may indicate abnormal radio activity.
• Broadcast Information Inconsistencies: Unexpected changes in cell-selection or reselection parameters, neighboring-cell information, frequencies, or other broadcast configuration may indicate manipulation or an unauthorized cell.
• Cell Identity and Topology Mismatches: Unexpected combinations of Public Land Mobile Network (PLMN) identifiers, Physical Cell Identifiers (PCI), Tracking Area Codes (TAC), or operating frequencies that do not match the operator’s authorized network inventory may indicate suspicious infrastructure.

These indicators become more meaningful when correlated across multiple UEs, cells, and telemetry sources rather than evaluated individually. Figure 5 summarizes the transition from observable radio and network anomalies to potential security impact and SOC investigation.

Real-Time Threat Mitigation via Open RAN Intelligent Controllers

Open RAN architectures enable programmable monitoring and control through the RAN Intelligent Controller (RIC). The Non-Real-Time RIC (Non-RT RIC) supports optimization and policy functions operating at time scales greater than one second, while the Near-Real-Time RIC (Near-RT RIC) supports control loops operating approximately between 10 milliseconds and one second ⁵.

The Near-RT RIC hosts Near-RT RIC applications (xApps) that can process near-real-time RAN information collected from E2 Nodes, including O-RAN Distributed Units (O-DUs) and O-RAN Central Units (O-CUs), through the E2 interface. E2 Service Models (E2SMs) define the types of measurements, events, and control capabilities that can be exposed through this interface. The Non-RT RIC can host Non-RT RIC applications (rApps) that support longer-term analytics, policy optimization, and Artificial Intelligence (AI) and Machine Learning (ML) driven RAN management.

These capabilities can also support security-oriented monitoring. For example, an xApp could correlate abnormal RRC behavior, radio measurements, and other available telemetry to identify patterns associated with suspicious radio activity. Depending on the E2SMs supported by the deployment and the operator’s security policy, the application could trigger an available RAN control action or escalate the event to the SOC for further investigation.

This programmable approach allows threat-detection logic to be integrated with RAN telemetry and supported control mechanisms while ensuring that automated responses remain within the capabilities and policies defined by the operator.

Zero Trust Implementation in Disaggregated Network Architectures

Traditional RAN deployments often relied heavily on trusted network boundaries and tightly integrated base-station components. In modern disaggregated 5G and O-RAN deployments, RAN functions are separated into software and hardware components connected through standardized interfaces. This improves interoperability and deployment flexibility but also introduces additional interfaces, distributed components, and security boundaries that must be protected.

The main disaggregated RAN components include:

• O-RAN Radio Unit (O-RU): Provides radio-frequency and lower-layer processing functions close to the antenna.
• O-RAN Distributed Unit (O-DU): Performs latency-sensitive radio protocol processing and communicates with the O-RU over the Open Fronthaul interface.
• O-RAN Central Unit - Control Plane (O-CU-CP): Handles centralized control-plane functions.
• O-RAN Central Unit - User Plane (O-CU-UP): Handles centralized user-plane functions and associated data processing.

Because these components may operate across different physical locations, cloud environments, and administrative boundaries, security cannot rely solely on network location or perimeter trust. O-RAN security specifications apply Zero Trust principles by requiring authentication, authorization, confidentiality, integrity, and other security controls across O-RAN components and interfaces ⁶.

Securing Open Disaggregated Interfaces

Each interface in a disaggregated RAN represents a security boundary and should be protected according to its specific protocol and security requirements.

“In a disaggregated RAN, trust should be established per interface, not assumed from network location.”

For the Open Fronthaul interface between the O-RU and O-DU, different controls apply to its management and traffic planes. The Management Plane (M-Plane) supports secure mechanisms such as Transport Layer Security (TLS) or Secure Shell (SSH), together with authentication and authorization controls. For the Control, User, and Synchronization planes, Institute of Electrical and Electronics Engineers (IEEE) 802.1X can provide port-based network access control, while Media Access Control Security (MACsec) can provide additional confidentiality and integrity protection where deployed ⁶.

For the E2 interface, which connects E2 Nodes with the Near-RT RIC, O-RAN specifies Internet Protocol Security (IPsec)-based protection to provide confidentiality, integrity, authentication, and replay protection. This helps protect telemetry and control exchanges between the Near-RT RIC and connected RAN components.

The O1 interface uses TLS-based protection together with access-control mechanisms such as Network Configuration Access Control Model (NACM), while the O2 interface uses TLS for transport protection, mutual TLS (mTLS) for mutual authentication, and Open Authorization (OAuth) for applicable Application Programming Interface (API) interactions ⁶.

The F1 and E1 interfaces, which are defined by 3GPP rather than O-RAN, should similarly be protected according to the applicable 3GPP transport-security requirements and the trust boundaries of the deployment.

Applying interface-specific controls rather than a single security mechanism across all links supports a Zero Trust approach in which every connection is explicitly authenticated, authorized, and protected according to its function.

Summary Operational Hardening Checklist for Network Operators

The main operational controls discussed throughout this article are summarized in Table 1. These controls should be adapted to the operator’s architecture, service requirements, regulatory environment, and deployment trust boundaries.

Table 1. Summary of operational hardening controls for RAN and O-RAN security

Conclusion: The Future of Resilient Mobile Infrastructure

Across this four-part series, the main layers of RAN security have been explored:

1. Part 1: Introduced RAN architecture, radio protocol stacks, physical-layer interfaces, and split base-station architectures.
2. Part 2: Examined threats including FBS, protocol downgrade attempts, RF jamming, and user-plane data manipulation.
3. Part 3: Explored the evolution of RAN security across 3GPP releases, including subscriber-identity protection, user-plane integrity, and security considerations for modern and disaggregated RAN architectures.
4. Part 4: Translated these security mechanisms into operational practices for base-station hardening, threat detection, interface protection, and security operations.

Modern RAN infrastructure is increasingly software-driven, distributed, and integrated with cloud-native environments. As mobile networks continue to evolve through 5G-Advanced and toward 6G, security depends not only on standardized mechanisms but also on how those mechanisms are configured, monitored, and maintained in operational environments.

A resilient RAN security posture therefore requires multiple layers of protection. Strong cryptographic configuration, secure key management, interface-specific protections, continuous telemetry analysis, and Zero Trust principles all contribute to reducing the attack surface and improving the ability to detect and respond to threats.

“RAN security becomes operational when standards are translated into controls that are continuously enforced, monitored, and maintained across the network lifecycle.”

References