- El 19 de julio una actualización defectuosa del software de seguridad CrowdStrike bloqueó millones de ordenadores con Windows en todo el mundo.
- Aeropuertos, bancos y hospitales sufrieron interrupciones, también en España: no fue un ciberataque, sino un error.
- Conviene tener copias de seguridad, procedimientos manuales y una forma clara de comunicarse con los clientes si los sistemas fallan.
El 19 de julio de 2024, una actualización defectuosa del software de seguridad CrowdStrike bloqueó millones de ordenadores con Windows en todo el mundo. Aeropuertos, bancos y hospitales sufrieron interrupciones, también en España. En cuestión de horas, empresas de todos los tamaños se encontraron con pantallas bloqueadas, sistemas que no arrancaban y servicios que dejaban de funcionar sin que nadie hubiera sufrido ningún ataque. Para muchas de ellas, fue la primera vez que comprobaron hasta qué punto su actividad depende de que el ordenador de cada puesto funcione.
El episodio resultó especialmente instructivo porque no tuvo un origen malicioso. Lo que paralizó a tantas organizaciones fue un error en una pieza de software diseñada precisamente para protegerlas. Esa paradoja explica por qué los especialistas llevan tiempo insistiendo en que la seguridad informática no consiste solo en evitar ataques, sino también en poder seguir trabajando cuando algo falla. El incidente desplazó la conversación desde la defensa hacia la resiliencia.
Qué falló
Una actualización defectuosa de un programa de seguridad bloqueó millones de ordenadores con Windows. No fue un ciberataque, sino un error, pero sus efectos se parecieron a los de uno: las interrupciones alcanzaron a sectores críticos muy distintos. Los equipos afectados no podían arrancar con normalidad y hubo que intervenir uno a uno para recuperarlos. Mientras tanto, la actividad dependía de lo que cada organización hubiera previsto para operar sin sistemas.
Esta circunstancia explica por qué la recuperación fue lenta en muchas organizaciones. Cuando el fallo reside en el propio sistema y no en un servidor central, no basta con apagar y encender: hace falta personal técnico, tiempo y procedimientos. Las empresas con muchos puestos de trabajo, o con equipos repartidos por diferentes sedes, fueron las que más tardaron en recobrar la normalidad. Para los clientes, el resultado fueron esperas, retrasos y servicios limitados, a menudo sin una explicación clara en las primeras horas.
Una dependencia compartida
El incidente demostró la dependencia de unos pocos proveedores tecnológicos. Cuando muchas organizaciones usan el mismo software, una única fallada puede afectarlas a todas a la vez, incluidas las que no tuvieron nada que ver con el error. La eficiencia de usar herramientas comunes tiene como contrapartida un riesgo compartido que rara vez se calcula. Es el precio de la comodidad: lo que simplifica la gestión diaria concentra también los puntos de fallo.
Para una pyme, esto no significa dejar de usar proveedores de confianza, sino saber de cuáles depende realmente y qué ocurriría si uno de ellos fallara. A veces la dependencia está oculta: un sistema de reservas, una pasarela de pago o un programa de facturación que usa de fondo una herramienta ajena. Conocer esa cadena es el primer paso para poder gestionarla. Preguntar a los proveedores cómo gestionan las actualizaciones y qué garantías ofrecen forma parte de esa revisión.
Un plan de contingencia
Un plan de contingencia informático es tan necesario como un seguro. Conviene tener copias de seguridad actualizadas y comprobar que pueden restaurarse, disponer de procedimientos manuales para seguir atendiendo a los clientes y una forma clara de comunicarse con ellos si los sistemas dejan de funcionar. Todo ello debe estar escrito y al alcance de quienes tienen que aplicarlo.
Un buen plan responde a pocas preguntas sencillas: qué procesos son críticos, cuánto tiempo puede aguantar el negocio sin ellos, quién decide qué se hace y cómo se informa a clientes y empleados. Ensayarlo una vez al año, aunque sea de forma sencilla, permite descubrir fallos antes de que sean costosos. Y conviene revisar qué cubre el seguro en caso de interrupción tecnológica. Un seguro no sustituye a un plan, pero ayuda a absorber el coste cuando el plan se ve superado.
La tecnología falla, y lo que importa es cómo se sigue trabajando.
Este artículo es información general. No es asesoramiento jurídico, fiscal ni de inversión, y no tiene en cuenta las circunstancias particulares de nadie.
