// 022Sector Público · Transporte · Infraestructura Crítica

Operación IT Integral
para Operador Ferroviario Nacional

ITOC24x7 OperationsNOC/SOCNIS2Critical InfrastructureRailway
24x7x365modelo de operación NOC+SOC integrados
NIS2 compliantmarco de seguridad para infraestructura crítica ferroviaria
SLAs por criticidaddiferenciados para cada tipo de sistema ferroviario

El operador ferroviario nacional de España —gestor de la red de alta velocidad, larga distancia y cercanías— necesitaba renovar el servicio de operaciones TI que vencía con el proveedor incumbente. La infraestructura IT del operador tenía una complejidad excepcional: sistemas de gestión del tráfico ferroviario (SCADA, ATP), sistemas de venta y atención al cliente, backoffice corporativo y sistemas de mantenimiento de flota y vía, cada uno con criticidades y requisitos de disponibilidad completamente distintos.

La aplicación de la directiva NIS2 clasificaba la infraestructura IT del operador como infraestructura crítica nacional, imponiendo obligaciones de notificación de incidentes, medidas de seguridad técnicas mínimas y auditorías regulatorias que el modelo operativo existente no cubría adecuadamente.

  • Diseñar un modelo ITOC (IT Operations Center) que integrara NOC y SOC en una única organización operativa capaz de correlacionar eventos de disponibilidad y seguridad de los sistemas ferroviarios críticos
  • Definir SLAs diferenciados para sistemas con criticidades radicalmente distintas: desde sistemas de control de tráfico (disponibilidad 99,999%, latencia <100ms) hasta aplicaciones de reporting (disponibilidad 98%, ventana de mantenimiento semanal admisible)
  • Diseñar el plan de transición desde el proveedor incumbente con impacto mínimo en la operativa ferroviaria, considerando que cualquier degradación de los sistemas de señalización podía traducirse en cancelaciones de trenes y sanciones regulatorias
  • Cumplir los requisitos NIS2 para infraestructuras críticas: procedimientos de notificación de incidentes al INCIBE en menos de 24 horas, medidas técnicas mínimas de seguridad (MFA, segmentación, parcheo) y plan de continuidad documentado
  • Diseñar las herramientas de monitorización que permitieran correlacionar eventos IT con impacto en la operativa ferroviaria, para priorizar la respuesta según el efecto real en la circulación de trenes
  • Modelo ITOC integrado NOC+SOC: diseño del centro de operaciones con dos células especializadas (infraestructura/disponibilidad y seguridad) bajo un mando único, con escalado colaborativo para incidentes que afectaran simultáneamente a la disponibilidad y la seguridad de los sistemas ferroviarios
  • SLAs por criticidad de sistema: definición de 5 niveles de criticidad (Misión Crítica, Alta, Media, Normal, Batch) con objetivos de RTO, RPO y disponibilidad diferenciados, y penalizaciones contractuales que escalaban según el impacto real en la circulación de trenes
  • Herramientas de monitorización correlacionada: arquitectura de monitorización con Dynatrace para sistemas de TI y correlación con el estado de la circulación ferroviaria, permitiendo priorizar automáticamente los incidentes según el número de trenes afectados
  • Plan de transición sin impacto operativo: migración de operaciones en 6 meses con cogestión proveedor incumbent + nuevo proveedor durante el periodo de transición, protocolos de escalado claros y knowledge transfer documentado para todos los sistemas críticos
  • Marco de cumplimiento NIS2: procedimientos de notificación de incidentes al INCIBE, controles técnicos de seguridad (segmentación OT/IT, MFA para acceso remoto a sistemas críticos, gestión de parches con ventanas de mantenimiento ferroviarias), y plan de continuidad de negocio con simulacros semestrales
NOC+SOC unificadomodelo operativo integrado que permitió correlacionar por primera vez eventos de disponibilidad y seguridad, reduciendo el tiempo de diagnóstico de incidentes complejos que afectaban a ambas dimensiones
NIS2 compliantdiseño de controles técnicos y procedimientos operativos que cumplían los requisitos de la directiva NIS2 para infraestructuras críticas, reduciendo el riesgo de sanciones regulatorias
SLAs ferroviariosmodelo de SLA alineado con el impacto real en la operativa ferroviaria, no con métricas IT genéricas, lo que hizo los compromisos contractuales directamente relevantes para la dirección de operaciones
Transición controladaplan de migración de operaciones diseñado para que ningún incidente durante la transición pudiera atribuirse al cambio de proveedor, protegiendo la reputación del operador ante pasajeros y regulador
// ARCH 22 · Azure · Infraestructura Crítica
IT/OT Operations Center — NIS2 Critical Rail Infrastructure
OT / SCADA (Air-Gapped) SCADA · ERTMS Señalización · ATP Protocolo IEC 62280 · Certificación CENELEC DMZ Data Diode IT CLOUD · AZURE NOC 24×7 Azure Monitor SOC NIS2 Sentinel · XDR Gestión Activos · CMDB ServiceNow · Azure Service Health SLAs por Criticidad Seguridad: 15min · Tráfico: 30min Comercial: 2h · Soporte: 8h NIS2 · Infraestructura Crítica Ferroviaria Notificación incidentes 24h · Auditoría anual · Gestión riesgos cadena suministro

Centro de operaciones IT/OT integrado 24×7×365 para operador ferroviario de infraestructura crítica: capa OT air-gapped con SCADA/ERTMS certificado bajo CENELEC, DMZ con data diode unidireccional para telemetría, NOC/SOC en Azure con Sentinel para cumplimiento NIS2, y SLAs diferenciados por criticidad de sistema (15 min para sistemas de seguridad ferroviaria, 8h para soporte interno).

Azure SentinelDefender XDRData Diode OT/ITServiceNowNIS2 Framework
// Consideraciones de despliegue · Critical Infrastructure WAF
  1. Separación OT/IT con data diode unidireccional, no solo firewall — en infraestructura ferroviaria, el compromiso de la red IT no debe poder afectar los sistemas SCADA/ATP de seguridad. Un firewall es bidireccional; un data diode físico garantiza que el tráfico solo fluye de OT hacia IT, nunca al revés.
  2. Certificación CENELEC EN 50128/50129 para software de seguridad ferroviaria — cualquier sistema que interactúe con señalización o control de tráfico ferroviario requiere certificación de seguridad funcional. Azure no certifica esto; el operador debe certificar su integración específica.
  3. SLAs diferenciados por impacto en seguridad de la operación ferroviaria — un fallo en el sistema de gestión del tráfico tiene consecuencias de seguridad física. Un fallo en el sistema de RRHH no. Diseñar SLAs que reflejen esta diferencia, no un SLA único para toda la organización.
  4. NIS2: el operador ferroviario es entidad esencial por defecto — el reglamento de implementación de NIS2 incluye explícitamente infraestructura ferroviaria. Las obligaciones incluyen auditoría anual, notificación de incidentes en 24h y gestión de riesgos de terceros en la cadena de suministro.
  5. Telemetría OT hacia Azure con normalización de protocolos industriales — los protocolos OT (DNP3, IEC 61850, Modbus) no son compatibles nativamente con Azure Monitor. Requieren gateways de protocolo con connectors específicos que deben estar en el plan de integración desde el inicio.
  6. Plan de continuidad de operaciones ferroviarias durante la transición IT — en este proyecto, cualquier ventana de mantenimiento de sistemas IT debía coordinarse con el horario de trenes. La coordinación operativa fue tan compleja como la técnica.
FiabilidadSeguridadCumplimiento NIS2Excelencia Operacional