El 19 y 20 de septiembre de 2025, un ataque de ransomware contra Collins Aerospace —proveedor de la plataforma de check-in y abordaje MUSE, compartida por decenas de aerolíneas— dejó fuera de servicio los sistemas automatizados de varios aeropuertos europeos: Heathrow, Bruselas, Berlín-Brandenburg, Dublín y Cork, entre otros. La agencia de ciberseguridad europea (ENISA lo confirmó como un ataque de tercero; se atribuyó al grupo Everest). Lo que pasó a continuación es la mejor clase de continuidad OT que se puede pedir: los aeropuertos volvieron al papel.
Qué significó "volver al papel"
Literal, no metáfora. Sin la plataforma automatizada, el personal documentó a los pasajeros a mano, emitió pases de abordar en papel y cotejó equipaje con listas impresas. Fue lento y caótico: en Bruselas se cancelaron alrededor de 60 de unos 550 vuelos ese lunes y muchos más se retrasaron; en Berlín las demoras superaron la hora. Pero —y este es el punto— la operación no se detuvo por completo. Había un modo manual al cual degradar. Ese "modo papel" es, en el fondo, el plan de continuidad del proceso físico: la versión analógica de lo que normalmente hace el sistema.
La consecuencia del OT es física, así que la recuperación también
Aquí está la diferencia de fondo con un incidente de TI clásico. Cuando cae un sistema de datos, "recuperar" es restaurar la información. Cuando cae un sistema OT, la realidad física no se pausa: los aviones siguen llegando, los pasajeros siguen formándose, la producción sigue pendiente, el cuarto de servidores sigue calentándose. Por eso la continuidad de OT tiene una pregunta que la de TI no siempre se hace: mientras recupero el sistema, ¿cómo sigo operando el proceso físico? Y la respuesta honesta es que a veces existe un plan B manual y a veces, simplemente, no.
El espectro: dónde el modo manual salva y dónde no existe
No todos los entornos OT son iguales frente a esta pregunta:
- Fallback viable (lento, pero posible): check-in de aeropuerto, punto de venta de una tienda, buena parte de la logística. Se puede operar a mano un rato —con dolor, pero se puede—.
- Fallback inviable o inexistente: una línea de producción a alta velocidad, el control de una subestación eléctrica, el proceso de una planta química, el enfriamiento de un data center. Nadie "opera en papel" el enfriamiento de un rack ni sincroniza a mano una línea que llena mil envases por minuto. Si ese OT cae, no hay modo manual que valga: hay paro.
Cuanto más a la derecha de ese espectro estás, más caro sale no haber prevenido, porque no hay red de seguridad operativa que amortigüe el golpe.
El error peligroso: creer que tienes un plan B que en realidad no tienes
Entre esos dos extremos vive la trampa más común. Muchas organizaciones asumen que podrían operar en manual, pero nunca lo verificaron —y descubren en el peor momento que el fallback es una ilusión—. Tres formas de que eso pase: el proceso manual nunca se documentó y solo vivía en la cabeza de alguien que ya no está; el volumen actual hace inviable a mano lo que sí se podía hace diez años; o la gente simplemente perdió la práctica. Los aeropuertos batallaron aun teniendo fallback, precisamente porque el personal no está acostumbrado a operar así y el volumen es enorme. Un plan B que nunca se ensayó no es un plan: es una esperanza —el mismo principio de que un DRP sin probar es una hipótesis—.
Qué hacer con esto
La continuidad de OT se diseña en dos frentes, según dónde caigas en el espectro:
- Si hay fallback manual: documéntalo y ensáyalo —un simulacro de "modo papel", igual que un tabletop de DRP—, para que el día real no sea la primera vez.
- Si no hay fallback viable: entonces la prevención deja de ser opcional. La segmentación que evita que un ransomware de TI salte al OT, la redundancia y el monitoreo continuo no son "nice to have": son tu única red, porque no habrá plan B el día del golpe.
Y un aprendizaje transversal del caso Collins: el ataque entró por un proveedor compartido, no por la red de cada aeropuerto. La continuidad de OT hoy incluye preguntar de qué terceros depende tu proceso físico —y qué pasa contigo si ellos caen—.
La pregunta que conviene hacerse
La pregunta no es "¿tengo respaldos de mis sistemas?", sino si mañana cayera el sistema que controla mi proceso físico, ¿podría seguir operando en manual —y lo hemos practicado— o simplemente me detengo? Responderla con honestidad define si tu inversión debe ir a un buen plan de contingencia manual, a blindar la prevención porque no hay plan B, o a ambos. Diseñar esa continuidad —para el OT que quizá no sabías que tenías— es parte de cómo pensamos la resiliencia junto a nuestro NOC/SOC administrado.