Seguridad Open RAN en Europa: por qué las pruebas soberanas son esenciales

Son las 2:07 de la mañana. El NOC de un operador europeo muestra una alerta en un sitio Open RAN recién integrado: un mensaje RRC Reconfiguration con parámetros de medición que no coinciden con la configuración definida por el SMO. El ingeniero de turno compara el contenido del mensaje con la política cargada en el RIC. No hay correspondencia. El vendor del O-DU confirma que su implementación es conforme a especificación. El vendor del O-CU dice lo mismo. Pero el terminal recibe instrucciones que nadie autorizó.

Este tipo de incidente no es hipotético. Es la consecuencia directa de una arquitectura que separa componentes antes integrados en una sola caja. Y Europa, donde la soberanía de las infraestructuras de telecomunicaciones es una prioridad política, enfrenta esta realidad con un marco regulatorio que exige respuestas concretas.

La promesa de Open RAN y sus compromisos de seguridad

Open RAN desagrega la estación base tradicional en componentes separados e interoperables, definidos por la O-RAN Alliance:

En una estación base integrada de un solo fabricante, la comunicación entre la unidad radio y la unidad de banda base es propietaria. No hay interfaz abierta que un atacante pueda explotar entre componentes. En Open RAN, cada interfaz (Open Fronthaul, E2, A1, O1, O2) es un punto de comunicación documentado, especificado y accesible.

La especificación 3GPP TS 33.501 define el marco de seguridad para 5G, incluyendo autenticación, cifrado y protección de integridad. Pero TS 33.501 se diseñó para una arquitectura donde el RAN es una entidad monolítica. Las interfaces abiertas entre O-CU, O-DU, O-RU y RIC no estaban en el alcance original. La O-RAN Alliance ha publicado especificaciones de seguridad (O-RAN.WG11) que cubren estas interfaces, pero la implementación real varía entre fabricantes.

El resultado es una arquitectura con más puntos de entrada, más interfaces a proteger y más posibilidades de inconsistencia entre componentes de distintos proveedores.

La respuesta regulatoria de Europa

Europa no ha ignorado este desafío. La respuesta regulatoria se ha construido en varias capas, desde la Toolbox 5G hasta la Directiva NIS2.

La EU 5G Toolbox (enero 2020) estableció el principio de evaluación de riesgo por proveedor. Aunque no nombró fabricantes específicos, creó el marco para que los estados miembros restringieran proveedores considerados de alto riesgo en componentes críticos de la red. En la práctica, esto aceleró la diversificación del suministro y, con ella, la adopción de Open RAN como estrategia de desacoplamiento.

La Directiva NIS2 (2022/2555), efectiva desde octubre 2024 en transposición nacional, clasifica a los operadores de telecomunicaciones como “entidades esenciales.” Esto implica obligaciones concretas: gestión de riesgos de ciberseguridad en la cadena de suministro, notificación de incidentes en 24 horas, y auditorías de seguridad periódicas. Para un operador que despliega Open RAN, NIS2 significa que la seguridad de cada interfaz multi-vendor debe ser demostrable, no presumida.

El informe de ENISA de 2021 sobre seguridad Open RAN fue particularmente directo: la desagregación introduce riesgos que no existen en redes RAN integradas. Entre ellos: mayor superficie de ataque, complejidad de gestión de seguridad multi-proveedor, y dependencia del RIC como punto central de control con acceso privilegiado a toda la red de acceso.

A nivel nacional, las respuestas varían. Alemania exige certificación de componentes 5G críticos. Francia ha implementado restricciones específicas para equipos en zonas sensibles. Suecia y otros países han prohibido directamente ciertos fabricantes en el core y el RAN.

Dónde falla la seguridad Open RAN en el campo

Los laboratorios de interoperabilidad (OTICs) y las pruebas de conformidad verifican que los componentes cumplen las especificaciones. Pero el campo revela vulnerabilidades que el laboratorio no puede reproducir.

Fronthaul (Open Fronthaul entre O-RU y O-DU). La interfaz fronthaul transporta muestras IQ entre la unidad radio y la unidad distribuida. En una implementación integrada, esta comunicación es interna al equipo. En Open RAN, viaja por una red de transporte que puede compartirse con otros servicios. La especificación O-RAN WG4 define opciones de cifrado para el fronthaul, pero la implementación es opcional en muchos productos. Un fronthaul no cifrado es un vector de interceptación directa de datos de usuario a nivel radio.

RIC y xApps. El RAN Intelligent Controller tiene acceso privilegiado a la configuración y al comportamiento de toda la red de acceso. Las xApps (aplicaciones de terceros ejecutándose en el Near-RT RIC) pueden modificar parámetros de handover, asignación de recursos y steering de tráfico. Una xApp comprometida o mal implementada puede degradar el servicio de forma selectiva, redirigir tráfico o crear condiciones de denegación de servicio. La cadena de confianza de las xApps depende del onboarding del operador, la firma de código y el sandboxing. En campo, estos controles no siempre funcionan como se documentan.

Interfaces multi-vendor. Cuando el O-CU es de un fabricante, el O-DU de otro y el RIC de un tercero, la coherencia de las políticas de seguridad depende de la correcta implementación de cada vendor. Un mensaje de reconfiguración RRC generado por el O-CU debe ser coherente con la política del RIC y ejecutado correctamente por el O-DU. En campo, se observan casos donde las reconfiguraciones contienen parámetros que no corresponden a la política activa, indicando desincronización entre componentes.

Pruebas soberanas: validación independiente en campo

La capacidad de un operador para validar de forma independiente la seguridad de su red Open RAN es lo que define la soberanía de prueba. Depender exclusivamente de los resultados de validación proporcionados por los fabricantes o por laboratorios de integración crea un conflicto de interés estructural.

El análisis de protocolo Layer 3 en campo, directamente desde el terminal, proporciona una vista que ningún sistema de gestión centralizado ofrece:

• Decodificación RRC en tiempo real: cada mensaje RRC Reconfiguration, MeasConfig y SIB difundido por la celda puede compararse con la política definida en el SMO/RIC. Cualquier divergencia es una anomalía a investigar.
• Análisis NAS: los mensajes de autenticación, registro y establecimiento de sesión revelan si los procedimientos de seguridad 5G (5G-AKA, cifrado NAS, protección de integridad) se ejecutan correctamente.
• Detección de degradación forzada: un ataque de downgrade que fuerce al terminal de 5G SA a 4G o 3G se hace visible en los mensajes de redirección inter-RAT capturados en Layer 3.
• Verificación de parámetros de celda: la comparación de los SIBs difundidos con la configuración planificada permite detectar celdas falsas o parámetros manipulados.

La herramienta de prueba debe operar a nivel de chipset (protocolo DIAG de Qualcomm) para acceder a la señalización completa sin depender de APIs de fabricante. Un smartphone equipado con un decodificador L3 nativo captura esta información en tiempo real, sin hardware adicional de decenas de miles de euros.

Qué verificar al validar un sitio Open RAN

Lista de verificación para ingenieros de campo:

Capa de señalización (Layer 3)

• Verificar que todos los SIBs difundidos coinciden con la configuración planificada en el O-CU
• Confirmar que los mensajes RRC Reconfiguration contienen únicamente parámetros coherentes con la política del RIC
• Validar que la secuencia de autenticación 5G-AKA se completa sin caídas a mecanismos menos seguros
• Comprobar que el cifrado NAS y la protección de integridad están activos (cipheringAlgorithm y integrityProtAlgorithm en SecurityModeCommand)

Capa de movilidad

• Ejecutar handovers entre celdas de distintos vendors y verificar que no hay pérdida de contexto de seguridad
• Detectar cualquier redirección inter-RAT (5G a 4G, 4G a 3G) que no esté justificada por condiciones RF medibles
• Verificar que los parámetros de medición (MeasConfig) son coherentes entre celdas vecinas de distintos proveedores

Capa de infraestructura

• Comprobar tiempos de respuesta del fronthaul para detectar anomalías de latencia que podrían indicar interceptación
• Validar que las xApps del RIC no generan reconfiguraciones fuera de política
• Verificar la consistencia de las alarmas de seguridad entre el SMO y lo observado en campo

Documentación para cumplimiento NIS2

• Registrar todas las capturas L3 con timestamp y geolocalización
• Generar informes de anomalías explotables por los equipos SOC del operador
• Mantener trazabilidad entre hallazgos de campo y acciones correctivas

Conclusión

La desagregación Open RAN no es intrínsecamente insegura. Pero introduce superficies de ataque que la arquitectura RAN tradicional no tenía. Europa ha construido un marco regulatorio (EU 5G Toolbox, NIS2, directrices ENISA) que exige a los operadores demostrar, no solo declarar, la seguridad de sus infraestructuras.

La validación en laboratorio es necesaria pero insuficiente. El campo es donde las inconsistencias multi-vendor se manifiestan, donde las xApps del RIC interactúan con condiciones RF reales y donde los procedimientos de seguridad se ponen a prueba bajo carga. La capacidad de realizar esta validación de forma independiente, con herramientas soberanas que no dependan del fabricante auditado, es lo que separa el cumplimiento formal de la seguridad real.

Si trabajas en la validación de sitios Open RAN en Europa, la pregunta clave ya no es si tu red cumple la especificación. Es si puedes demostrarlo con datos de campo, celda por celda, mensaje por mensaje.