Urda: cuando falla un sistema informático crítico, ¿dónde termina la avería y dónde empieza el riesgo?

El accidente ferroviario de Urda (Toledo) vuelve a poner sobre la mesa una cuestión fundamental: ¿qué ocurre cuando los sistemas informáticos que protegen una infraestructura crítica dejan de funcionar?

El 28 de octubre de 2026, una incidencia en el sistema de protección ferroviaria LZB provocó la interrupción de la circulación de varios trenes en el entorno del accidente de Urda. La información técnica difundida posteriormente apunta a una avería que afectó a tres ordenadores y dejó sin protección LZB un tramo de aproximadamente 63 kilómetros.

Desde el punto de vista de la informática forense y la ciberseguridad, este suceso plantea preguntas que van mucho más allá de una simple avería informática: ¿qué falló exactamente?, ¿por qué afectó a varios equipos?, ¿cómo se gestionó la circulación cuando el sistema dejó de funcionar? Y, una cuestión que también debe abordarse con rigor, ¿existe alguna evidencia de una posible intervención externa?

¿Qué es el sistema LZB y por qué es tan importante?

El LZB es un sistema de protección y supervisión ferroviaria que permite controlar de forma continua determinados parámetros de circulación, como la velocidad y las condiciones de seguridad del tren.

No debemos imaginarlo como un único programa informático instalado en un ordenador. Forma parte de un conjunto de equipos, comunicaciones y sistemas de control que intercambian información para supervisar la circulación.

Cuando este sistema deja de funcionar, la operación ferroviaria debe adaptarse a procedimientos específicos de seguridad. La circulación puede pasar a condiciones degradadas, con otras formas de señalización, comunicación y autorización.

El problema no es únicamente que un ordenador deje de responder. Lo verdaderamente importante es cómo afecta esa interrupción al conjunto de la infraestructura y qué mecanismos de respaldo entran en funcionamiento.

Tres ordenadores afectados: ¿una avería aislada o un problema común?

Uno de los datos más relevantes de la información técnica publicada es que la incidencia habría afectado a tres ordenadores y dejado sin protección LZB un tramo de unos 63 kilómetros.

Desde una perspectiva informática, este dato obliga a investigar varias posibilidades:

• Fallo de comunicaciones: pérdida de conexión entre equipos que necesitan intercambiar información.
• Fallo de infraestructura compartida: incidencia en un nodo, servidor, controlador o elemento de red del que dependen varios sistemas.
• Error de software o configuración: funcionamiento incorrecto provocado por parámetros, versiones o cambios en el sistema.
• Problema eléctrico o electrónico: una anomalía de alimentación o de hardware que afecte a los equipos informáticos.
• Intervención externa: una acción no autorizada que haya alterado la disponibilidad o el funcionamiento de los sistemas.

Estas posibilidades no tienen el mismo grado de respaldo. La información disponible apunta a una avería del sistema, pero todavía no permite determinar su causa técnica definitiva.

Que varios equipos fallen al mismo tiempo tampoco significa necesariamente que hayan sido atacados. Podrían depender de un mismo componente cuya interrupción haya provocado un fallo en cadena.

¿Podría haber sido un ciberataque?

La pregunta es legítima, especialmente cuando hablamos de infraestructuras críticas.

Un ciberataque puede tener como objetivo alterar la información, interrumpir comunicaciones, modificar configuraciones o impedir que un sistema esté disponible. En entornos industriales y ferroviarios, estos riesgos deben contemplarse dentro de los planes de seguridad.

Sin embargo, hay una diferencia fundamental entre que un ataque sea técnicamente posible y que existan pruebas de que haya sucedido.

A fecha de publicación de este artículo, no hay evidencias públicas verificadas que permitan atribuir el fallo ferroviario de Urda a un ciberataque.

Para sostener esa hipótesis sería necesario encontrar indicios técnicos concretos, como accesos no autorizados, conexiones remotas sospechosas, modificaciones de configuración sin autorización, ejecución de código malicioso o alteraciones de los registros del sistema.

Incluso si se detectase alguna actividad anómala, habría que demostrar que guarda relación temporal y causal con la interrupción del LZB.

No sería riguroso confundir una incidencia informática con una intrusión deliberada.

El punto clave: qué ocurrió después de la avería

Desde el punto de vista de la investigación, hay otra cuestión especialmente importante: qué sucedió una vez que el sistema LZB dejó de funcionar.

La información publicada indica que la circulación tuvo que gestionarse en condiciones degradadas y que se dieron instrucciones diferentes a los trenes implicados.

Aquí es necesario estudiar tres elementos:

1. La situación real: dónde estaban los trenes, qué velocidad llevaban y cuál era su posición efectiva.
2. La información informática: qué datos mostraban los sistemas de control y señalización.
3. Las decisiones operativas: qué instrucciones se transmitieron, quién las autorizó y qué información tenía disponible cada responsable.

La investigación debe comprobar si la información que manejaban los sistemas coincidía con la situación real de la vía y si las instrucciones transmitidas tuvieron en cuenta todas las circunstancias.

Una avería técnica y una decisión operativa posterior son cuestiones distintas. Ambas deben investigarse, pero no deben confundirse.

¿Qué pruebas informáticas permitirían conocer lo que ocurrió?

Aquí entra en juego la informática forense.

Para reconstruir los hechos no basta con conocer el resultado de la incidencia. Es necesario analizar los registros digitales que permitan establecer una cronología fiable.

Entre las evidencias que deberían examinarse destacan:

1. Registros de los equipos afectados.
Permiten identificar errores, reinicios, pérdidas de conexión, procesos detenidos y eventos anteriores a la interrupción.

2. Registros de comunicaciones.
Pueden ayudar a determinar si hubo pérdida de paquetes, interrupciones, conexiones anómalas o problemas en la transmisión de datos.

3. Registros de acceso y administración.
Permiten comprobar qué usuarios accedieron a los sistemas, cuándo lo hicieron y si existieron sesiones remotas o modificaciones no autorizadas.

4. Historial de mantenimiento y configuración.
Es necesario revisar actualizaciones, cambios de software, sustituciones de equipos y trabajos técnicos realizados antes del incidente.

5. Registradores de los trenes.
Los datos de los propios vehículos pueden ayudar a reconstruir velocidades, posiciones, órdenes recibidas y actuaciones de los sistemas embarcados.

6. Comunicaciones del centro de control.
Permiten contrastar la secuencia de instrucciones con los registros técnicos y la situación real de los trenes.

Toda esta información debe preservarse correctamente, documentando su procedencia, método de adquisición, integridad y cadena de custodia cuando corresponda.

El cálculo de hashes puede ayudar a verificar que las copias forenses no han cambiado desde su adquisición, aunque por sí solo no demuestra la autenticidad ni la integridad histórica de los datos originales.

Las infraestructuras críticas también necesitan informática forense

La seguridad de una infraestructura crítica no depende exclusivamente de que sus sistemas funcionen correctamente. También depende de su capacidad para detectar anomalías, resistir fallos, activar mecanismos alternativos y permitir una investigación posterior.

Por eso, la ciberseguridad debe contemplar tanto los ataques deliberados como los errores de configuración, los fallos de hardware, los problemas de comunicaciones y las actuaciones humanas.

En un entorno ferroviario, una interrupción tecnológica puede tener consecuencias operativas importantes. La investigación debe determinar qué ocurrió, cómo se propagó la incidencia y si los mecanismos de protección respondieron adecuadamente.

No se trata de buscar un culpable antes de disponer de pruebas. Se trata de reconstruir los hechos a partir de evidencias técnicas verificables.

La pregunta que todavía necesita respuesta

¿Fue una avería de comunicaciones? ¿Un fallo de arquitectura o configuración? ¿Un problema de mantenimiento? ¿Hubo alguna intervención externa?

Con la información pública disponible no es posible confirmar una causa definitiva ni atribuir el suceso a un ciberataque.

Lo que sí podemos afirmar es que el incidente demuestra la importancia de investigar los sistemas informáticos que intervienen en la seguridad de las infraestructuras críticas.

Porque cuando falla un sistema informático, la pregunta no debería ser solamente qué ordenador dejó de funcionar, sino qué ocurrió antes, qué sistemas dependían de él y qué mecanismos debían evitar que esa incidencia se convirtiera en una situación de riesgo.

---

INVESTIGA ONLINE
Informática forense · Investigación digital · Ciberseguridad
www.investigaonline.es

Nota: Este artículo analiza la información pública disponible a fecha de publicación y plantea cuestiones técnicas generales desde la perspectiva de la informática forense. No constituye una conclusión pericial sobre las causas del accidente, que corresponden a las investigaciones oficiales en curso.