Hay una idea con la que convivo hace años y que cada tanto la realidad se encarga de subrayar: solemos creer que tenemos todo bajo control hasta que una sola pieza se corre de lugar. Vivimos rodeados de capas que nos dan tranquilidad —sistemas, automatizaciones, plataformas cloud, monitoreo, actualizaciones automáticas— y esa tranquilidad funciona bien hasta que algo que instalamos para protegernos se convierte, aunque sea por error, en el origen del problema. Eso fue, en buena parte, lo que dejó el incidente de CrowdStrike de julio. No escribo esto para señalar a una empresa ni para caer en el “alguien se equivocó”, porque en tecnología todos convivimos con errores tarde o temprano. Me interesa otra cosa: usar el caso para pensar qué tan preparados estamos de verdad para resistir, recuperarnos y seguir funcionando cuando una dependencia crítica falla. Porque la resiliencia no se demuestra cuando todo anda bien, sino el día que algo se rompe.
Para ubicarnos: qué es CrowdStrike#
Para quien no esté tan metido en el mundo de la ciberseguridad, CrowdStrike es una empresa estadounidense especializada en seguridad informática, y su producto más conocido es Falcon: una plataforma que se instala en equipos y servidores para detectar, prevenir y responder ante amenazas. Dicho de forma simple, ayuda a proteger computadoras y entornos empresariales contra ataques, malware y comportamientos sospechosos.
No hablamos de una herramienta menor ni de una app que alguien usa suelta en su notebook. Es software de seguridad que vive en ambientes corporativos: bancos, aerolíneas, hospitales, organismos públicos, medios, organizaciones críticas. Y ahí aparece el primer punto que me parece importante. Cuando una herramienta así funciona bien, casi nadie la ve; está corriendo en silencio, protegiendo. El problema es que el día que falla, queda en evidencia lo profundamente integrada que estaba en la operación diaria.
Qué pasó en julio#
El 19 de julio, una actualización de contenido de CrowdStrike para sistemas Windows generó fallas masivas. Muchos equipos empezaron a mostrar la famosa pantalla azul y quedaron sin poder iniciar correctamente. Microsoft estimó que el incidente afectó alrededor de 8,5 millones de dispositivos Windows, lo que en porcentaje representaba menos del 1% del total. Y sin embargo el impacto fue enorme, porque esos equipos estaban dentro de organizaciones que prestan servicios críticos.
Ese contraste me resulta revelador. A veces miramos los porcentajes y pensamos que menos del 1% es poco, pero en tecnología el impacto no se mide solo por cantidad: se mide por ubicación, criticidad, dependencia y capacidad de recuperación. No es lo mismo que falle una computadora personal a que falle un equipo dentro de un aeropuerto, un hospital o una sala de control. El problema de fondo no fue “se rompieron muchas máquinas”, sino que muchas de esas máquinas formaban parte de procesos que el mundo necesita que sigan funcionando.
El alcance: de lo global a lo cercano#
El impacto fue global y muy visible. Hubo aerolíneas afectadas, vuelos demorados y cancelados, problemas en bancos, hospitales y medios, equipos técnicos corriendo para recuperar máquinas una por una. En Europa también se sintió, sobre todo en aeropuertos, servicios internacionales y empresas con infraestructura compartida; en España el evento se vivió principalmente como parte de esa afectación global, a través de aerolíneas y proveedores que operan de forma distribuida. En América Latina apareció de manera directa e indirecta: muchas empresas regionales no tenían todo su stack afectado, pero dependían de una aerolínea, un banco, una pasarela de pago o una herramienta SaaS que sí lo estaba.
Y este punto me parece clave: en 2024 ya casi ninguna organización es una isla. Incluso una empresa mediana, con sistemas relativamente simples, está conectada a decenas de proveedores —correo, CRM, facturación, pagos, analytics, cloud, seguridad, monitoreo, CI/CD— y cuando una pieza importante de ese ecosistema falla, el efecto llega aunque el problema no haya nacido dentro de tu propia infraestructura.
Por qué vale la pena detenerse acá#
Porque el caso deja una pregunta más profunda que “¿qué pasó con CrowdStrike?”. La pregunta real es qué tan preparada está una organización para seguir operando cuando falla una dependencia crítica. Y esa pregunta no distingue tamaños: vale igual para una multinacional, una startup, una pyme, un SaaS o un equipo interno de tecnología. Todas dependen de piezas, externas e internas, que pueden afectar el negocio si se caen.
Hablamos mucho de innovación, inteligencia artificial, automatización y transformación digital, y bastante menos de continuidad operativa, recuperación, planes de contingencia, pruebas de restauración o límites razonables para las actualizaciones automáticas. Sin eso, la innovación queda coja. Una organización puede acumular tecnología, pero si no puede resistir un incidente, esa misma tecnología termina siendo una forma de fragilidad.
La falsa sensación de control#
Uno de los problemas más grandes en tecnología es justamente esa: la falsa sensación de control. Tenemos dashboards, alertas, backups, pipelines, monitoreo, tickets, reuniones, proveedores y contratos. Todo eso ayuda, claro, pero no garantiza que estemos preparados.
Sabemos que un proceso existe, pero no siempre qué pasa si falla. Usamos un proveedor, pero no siempre tenemos claro cuántos procesos dependen de él. Tenemos backups, aunque rara vez probamos restaurarlos bajo presión. Hay monitoreo, pero no siempre alerta sobre lo que de verdad importa. Existe un plan de contingencia, y tal vez nadie lo ejecutó nunca en una crisis real. En un incidente, la distancia entre “creemos que estamos preparados” y “estamos preparados” puede ser enorme, y normalmente se descubre en el peor momento.
No todo riesgo viene de un atacante#
Cuando hablamos de ciberseguridad solemos imaginar ataques: ransomware, phishing, robo de credenciales, intrusiones. Pero lo de CrowdStrike no fue un ciberataque, sino una falla asociada a una actualización, y eso lo vuelve todavía más interesante para analizar, porque nos recuerda que el riesgo tecnológico no siempre tiene un atacante del otro lado.
También hay riesgo en una actualización mal validada, en una dependencia demasiado extendida, en un despliegue sin control gradual, en una configuración incorrecta o en una integración crítica que no tiene alternativa. Lo hay en un proveedor que cambia algo sin suficiente visibilidad, en una automatización que ejecuta rápido lo que no debería ejecutarse tan rápido, o en un proceso de recuperación que depende de tocar equipo por equipo a mano. La seguridad no es solo evitar que alguien entre; también es asegurarnos de que aquello que instalamos para protegernos no pueda tumbar la operación completa ante una falla propia.
La importancia de los despliegues graduales#
Uno de los aprendizajes que más se repite después de incidentes así es el valor de los despliegues graduales. En desarrollo de software hablamos seguido de canary releases, feature flags, staging, despliegues progresivos, rollback y monitoreo posterior al release. El detalle es que muchas veces aplicamos esos conceptos a nuestro propio código y pensamos mucho menos en las herramientas de terceros que viven dentro de nuestra infraestructura.
Una actualización global, rápida y automática puede ser muy útil para responder ante amenazas reales; en seguridad la velocidad importa. Pero esa velocidad también necesita controles. La pregunta no es si hay que actualizar, sino cómo actualizar sin convertir una corrección en un incidente masivo. En algunos contextos tendrá sentido permitir actualizaciones inmediatas; en otros convendrá escalonar, segmentar o probar primero en grupos reducidos. No hay una respuesta única, pero sí una idea central: cuanto más crítica es una herramienta, más importante se vuelve entender cómo se actualiza, cómo se prueba y cómo se revierte.
Dependencias invisibles#
Toda organización tiene dependencias visibles e invisibles. Las visibles las reconoce cualquiera: la base de datos principal, el proveedor cloud, el sistema de pagos, el CRM, el repositorio, el servidor de correo. Las invisibles son más peligrosas, porque suelen aparecer recién cuando fallan: un agente de seguridad instalado en miles de equipos, un servicio DNS, una política de autenticación, un certificado, una librería compartida, una cuenta de servicio o ese script que corre desde hace años y que “siempre funcionó”.
La resiliencia tecnológica empieza, en buena medida, por hacer visibles esas dependencias. No se puede proteger lo que no se conoce, recuperar lo que no está mapeado ni priorizar lo que no se entiende. Y esto no se resuelve solo comprando herramientas; se resuelve también con cultura técnica, documentación viva, conversaciones entre equipos y una mirada honesta sobre cómo funciona realmente la operación, más allá del diagrama.
Continuidad operativa no es solo backup#
Cuando hablamos de continuidad operativa aparece casi por reflejo la palabra backup. Los backups son fundamentales, no lo discuto, pero no alcanzan. La continuidad operativa abre muchas más preguntas: qué servicios son realmente críticos, cuánto tiempo podemos estar caídos, qué procesos tienen alternativa manual, quién toma decisiones durante un incidente, cómo se comunica el problema hacia adentro y hacia los clientes, qué proveedores hay que contactar y si alguna vez probamos el plan de recuperación.
Un backup sin proceso de restauración probado es casi una promesa. Un plan de contingencia que nadie conoce es casi un documento decorativo. Un monitoreo que alerta tarde es apenas una explicación posterior. La resiliencia no se construye el día del incidente; se construye antes, en los días en que parece que no hace falta.
El costo de recuperar a mano#
Uno de los aspectos más duros del incidente fue la recuperación. En muchos casos, los equipos afectados necesitaban intervención técnica directa para volver a funcionar, y ese detalle debería prender una alarma en cualquier organización. Cuando recuperar depende de tocar máquina por máquina, el tiempo de respuesta se vuelve mucho más difícil de controlar: no es lo mismo recuperar un servicio centralizado que intervenir cientos o miles de endpoints distribuidos.
Ahí aparecen preguntas incómodas. Si tenemos inventario actualizado de equipos y sabemos cuáles son críticos. Si podemos acceder de forma remota cuando el sistema operativo ni siquiera arranca. Si hay personal suficiente para una recuperación masiva, o si dependemos de soporte local en ciertas sedes o países. Qué pasa si el incidente ocurre fuera del horario laboral, o si afecta también las herramientas que usamos para coordinarnos entre nosotros. Muchas veces el problema técnico inicial dura poco; lo que se estira es la recuperación operativa. Y para el negocio, esa diferencia se siente.
Proveedores críticos: confianza, pero también control#
Usar proveedores es parte normal de la tecnología moderna. No tiene sentido construir todo internamente: sería caro, lento y muchas veces peor. Pero tercerizar no significa dejar de gestionar el riesgo. Cuando una organización adopta una herramienta crítica, debería entender lo básico: qué nivel de acceso tiene, qué componentes puede afectar, cómo se actualiza, cómo se desactiva en una emergencia, qué alternativas existen, qué SLA ofrece, qué soporte hay durante un incidente y qué controles conserva la propia organización sobre los cambios.
La confianza en un proveedor no debería reemplazar el diseño de resiliencia. Podemos confiar en una empresa, en su trayectoria y en su equipo, y aun así asumir que algún día algo va a fallar. No porque el proveedor sea malo, sino porque los sistemas complejos, simplemente, fallan.
La resiliencia también es arquitectura#
A veces se trata la resiliencia como un asunto de infraestructura u operaciones, pero también es una cuestión de arquitectura. Una arquitectura resiliente no es solo una que escala; es una que tolera fallos, que se degrada de forma controlada y que permite recuperarse. Eso implica pensar en aislamiento, segmentación, redundancia, observabilidad, rollback, circuit breakers, colas, reintentos, prioridades y modos degradados.
No todo tiene que seguir funcionando perfecto durante un incidente, pero sí deberíamos saber de antemano qué puede seguir funcionando, qué se degrada y qué se apaga para proteger al resto. En una organización real esto es decisivo, porque no todos los sistemas tienen la misma criticidad ni todas las funcionalidades valen lo mismo en una emergencia. Buena parte de la resiliencia consiste, justamente, en saber priorizar antes de que la urgencia decida por nosotros.
El rol del liderazgo técnico#
En eventos como este, el liderazgo técnico ocupa un lugar enorme. No alcanza con que los equipos sepan mucho; hace falta alguien que ordene, priorice, comunique y decida bajo presión. Durante un incidente pasan muchas cosas a la vez: equipos investigando, áreas de negocio pidiendo información, clientes afectados, proveedores comunicando avances, directivos necesitando estimaciones, soporte recibiendo consultas y operaciones tratando de sostener lo que se pueda. Sin liderazgo, todo eso se convierte en ruido. Y el ruido, durante un incidente, también es un problema técnico.
Liderar en tecnología no es solo definir arquitecturas o aprobar herramientas; es preparar a la organización para los momentos difíciles, lo que significa procesos claros, responsabilidades definidas, comunicación ordenada y capacidad de aprender después. Un buen postmortem vale oro, pero solo si se hace con honestidad: no para buscar culpables, sino para entender qué falló, qué no vimos y qué asumimos mal.
Las preguntas que conviene hacerse#
Más allá del caso puntual, el incidente deja una buena lista de preguntas para cualquier equipo de tecnología. Cuáles son nuestras dependencias críticas y qué herramientas tienen acceso profundo a nuestros sistemas. Si tenemos control real sobre sus actualizaciones y si podemos segmentarlas por grupos. Si mantenemos un inventario actualizado de servidores y endpoints, y qué sistemas pueden seguir operando en modo degradado. Cuánto tiempo podemos funcionar sin cada proveedor crítico. Si tenemos procedimientos de recuperación documentados, y —la más incómoda— si alguna vez los probamos. Cómo nos comunicamos durante una crisis, quién decide las prioridades, y si hacemos postmortems de verdad o solo cerramos tickets.
Son preguntas que no resultan cómodas, pero son necesarias. Muchas veces la madurez tecnológica de una organización no se mide por la cantidad de herramientas que usa, sino por la calidad de las preguntas que se anima a hacerse.
Algunas ideas para avanzar#
Si tuviera que aterrizar todo esto en acciones concretas, empezaría por mapear las dependencias críticas. No hace falta un documento perfecto desde el primer día; alcanza con empezar a identificar qué servicios, proveedores, agentes e integraciones son indispensables para operar. A partir de ahí, clasificar criticidad, porque no todo tiene la misma prioridad: hay cosas que pueden esperar, otras que pueden degradarse y otras que necesitan recuperación inmediata.
Después, revisar las políticas de actualización, sobre todo en herramientas con acceso profundo al sistema operativo, la red, la identidad o la infraestructura. Y probar la recuperación, porque tener procedimientos no es lo mismo que saber que funcionan; aunque sea en ejercicios pequeños y controlados, conviene ensayarlos. A eso le sumaría mejorar la comunicación de incidentes definiendo canales y responsables, hacer postmortems sin castigo —buscar culpables rara vez mejora un sistema, entender causas sí— y pensar de antemano en modos degradados, porque muchas veces operar parcialmente es bastante mejor que quedar completamente detenidos.
El caso CrowdStrike no debería dejarnos solo miedo a las actualizaciones automáticas ni desconfianza hacia una herramienta de seguridad. Debería dejarnos algo más útil: conciencia. Conciencia de que vivimos sobre sistemas cada vez más conectados, de que una dependencia pequeña en apariencia puede tener un impacto enorme, de que lo que instalamos para protegernos también puede introducir riesgos operativos, y de que la continuidad no se improvisa. Si la transformación digital no viene acompañada de resiliencia, lo único que conseguimos es construir organizaciones más modernas y, a la vez, más frágiles.
Quizá ahí esté lo más valioso para llevarse. No alcanza con digitalizar, automatizar ni proteger: también hay que diseñar para fallar, recuperarse y aprender. La tecnología real no vive en los diagramas perfectos, vive en producción, con usuarios, proveedores, horarios, urgencias y decisiones humanas. Y ahí, tarde o temprano, algo se rompe. La diferencia está en si ese día nos encuentra improvisando o preparados para responder. Me quedo dando vueltas a una pregunta que cada uno puede llevarse a su propio contexto: si mañana cae una de tus dependencias más invisibles, ¿cuánto de la respuesta está diseñada y cuánto quedaría librado a la improvisación del momento?
Fuentes consultadas#
- Microsoft, “Helping our customers through the CrowdStrike outage”, 20 de julio de 2024.
- CrowdStrike, “Falcon Content Update Preliminary Post Incident Report”, 25 de julio de 2024.
- Reuters, “Microsoft says about 8.5 million of its devices affected by CrowdStrike-related outage”, 20 de julio de 2024.
- Reuters, “CrowdStrike says over 97% of Windows sensors back online”, 25 de julio de 2024.
- CrowdStrike, “External Technical Root Cause Analysis — Channel File 291”, 6 de agosto de 2024.