Interlock OS: la distribución Linux para auditar la seguridad del ferrocarril

Durante casi un siglo, la señalización, el control de tráfico y la tracción ferroviaria estuvieron protegidos por algo tan simple como eficaz: el aislamiento físico. Eran redes cerradas, con protocolos propietarios, sin ninguna puerta por la que entrar. Este TFM de Beatriz, alumna del Máster de Ciberseguridad, parte de constatar que esa puerta ya existe, descubre Interlock OS, la distribución Linux para auditar la seguridad del ferrocarril.

Interlock OS, seguridad del ferrocarril, construida desde la norma

La digitalización del sector —ERTMS/ETCS en la señalización, CBTC en los metros, el salto de GSM-R a FRMCS y el «5G ferroviario», el mantenimiento remoto— ha convertido el tren en una arquitectura hiperconectada donde convergen las tecnologías de la información (IT) y las de operación (OT). Cada mejora operativa ha traído consigo, como efecto colateral, un vector de ataque que antes no existía, con impacto potencial sobre la seguridad operacional (safety), no solo sobre los datos.

De ahí nace la pregunta práctica que vertebra el trabajo: si hoy alguien necesita auditar, investigar o defender estos sistemas, ¿con qué herramientas cuenta? La respuesta es que con casi ninguna pensada para este dominio. Hay distribuciones generalistas y otras orientadas a entornos industriales ICS/SCADA, pero ninguna contempla los protocolos ni la normativa específicos del ferrocarril. Ese vacío es mi punto de partida.

Mi propuesta es Interlock OS, una distribución Linux construida sobre Debian 13 y especializada en ciberseguridad ferroviaria. Pero lo que considero verdaderamente aportación no es la distribución en sí, sino el método con que la he construido, deliberadamente invertido respecto a lo habitual: en lugar de reunir un catálogo de herramientas de hacking y buscarles después una justificación ferroviaria, arranco por el extremo contrario.

Primero identifico los vectores de ataque de cada parte de la red; después determino qué exige la normativa de referencia (CLC/TS 50701:2023, EN 50159:2020 y la serie IEC 62443, bajo el paraguas más amplio de NIS2 y la Directiva CER); y solo entonces busco —o certifico la ausencia de— una herramienta capaz de operar sobre ese vector.

Cómo nace Interlock OS

Para hacerlo de forma sistemática he dividido la arquitectura de un operador ferroviario en cinco segmentos de red, cada uno con su propia lógica de riesgo:

• Las comunicaciones inalámbricas tren-tierra y tren-tren (GSM-R, FRMCS, Wi-Fi de CBTC, TETRA).
• La red de campo OT, con sus PLCs, RTUs, enclavamientos electrónicos y contadores de ejes.
• Los sistemas embebidos a bordo (OBU y TCMS).
• La red troncal IP/MPLS que une los centros de control con los de bloqueo por radio.
• La red corporativa/IT de nivel 4, la más parecida a cualquier oficina.

Sobre esos segmentos he desarrollado una metodología de ingeniería propia de seis fases, que se repite de forma anidada para cada segmento y cada protocolo:

• Identificación de zonas y superficie de exposición.
• Caracterización tecnológica.
• Análisis de vulnerabilidad por componente.
• Contraste normativo-tecnológico.
• Selección comparativa cuando hay varias herramientas candidatas para una misma función.
• Consolidación final del catálogo.

La cuarta fase es el corazón del método: por cada vector, contrasto lo disponible y concluyo si existe herramienta, si hay algo parcialmente aplicable o si no hay nada.

El resultado es un catálogo consolidado de 96 herramientas de código abierto, organizadas en 13 metapaquetes, cada una anclada a un requisito normativo verificable o a la evidencia de un incidente real documentado.

Por diseño, el catálogo equilibra al 50 % las capacidades ofensivas de auditoría (Red Team) con las defensivas de monitorización y respuesta (Blue Team), en lo que el sector llama un enfoque Purple Team. La distribución no se queda en lo teórico: está implementada, con lanzadores por segmento, manuales técnicos integrados, un catálogo navegable filtrable por norma y una matriz que cubre tanto la emulación en laboratorio 100 % virtual como las pruebas sobre hardware físico.

Y aquí está el giro que más me interesa como contribución académica: no todos los vectores encuentran su herramienta. El trabajo documenta con honestidad catorce huecos donde la disciplina todavía no dispone de nada maduro, concentrados sobre todo en las comunicaciones inalámbricas y los sistemas embebidos a bordo, los dos segmentos donde la propiedad intelectual del fabricante más restringe. Lejos de esconderlos, los convierto en el principal hallazgo: un mapa de por dónde debería crecer la disciplina, formulado como líneas de investigación futura.

La conclusión no reivindica las 96 herramientas como el logro central, sino la trazabilidad que las sostiene: saber exactamente por qué esa herramienta y no otra, y bajo qué exigencia normativa concreta.

En un sector donde la seguridad operacional y la ciberseguridad están obligadas a converger, esa cadena de justificación es lo que convierte a Interlock OS en algo más que una colección de software: un argumento reproducible sobre cómo debería auditarse hoy la infraestructura crítica que nos lleva al trabajo cada mañana.

Si quieres ver el proyecto completo de Beatriz, rellena el formulario y te lo mandamos a tu correo electrónico.