El apagón global de CrowdStrike: lecciones de resiliencia y dependencia de proveedores
El 19 de julio de 2024, CrowdStrike publicó una actualización defectuosa de su Falcon Sensor que provocó el colapso de 8,5 millones de máquinas Windows en todo el mundo, según CNN. Aerolíneas en tierra. Hospitales con los sistemas caídos. Bancos sin poder operar. Pérdidas estimadas solo para las empresas del Fortune 500: 5.400 millones de dólares.
No fue un ciberataque. No fue ransomware. Fue una actualización rutinaria de un proveedor de confianza.
Si diriges una startup y piensas que esto no va contigo, piénsalo otra vez. He pasado años en el lado enterprise de la respuesta a incidentes, lidiando con fallos como este, y lo que ocurrió aquel viernes es un caso de estudio perfecto sobre dependencia de proveedores, resiliencia operativa y por qué necesitas ingenieros que entiendan lo que están desplegando.
Un archivo defectuoso, cero gates, millones de máquinas caídas
El fallo lo causó una actualización de un archivo de canal (channel file) del Falcon Sensor de CrowdStrike. Ese archivo contenía una definición defectuosa que provocaba una lectura de memoria fuera de límites (out-of-bounds memory read) en el driver de Windows a nivel de kernel. El resultado: pantalla azul de la muerte (BSOD) inmediata.
La actualización se publicó en torno a la medianoche UTC. CrowdStrike la revirtió 90 minutos después. Pero para entonces, millones de máquinas ya habían descargado automáticamente el archivo defectuoso.
Lo devastador no fue solo el fallo en sí. Fue la velocidad de propagación. Un único archivo, distribuido automáticamente, sin gates intermedios, a millones de endpoints a la vez. El mecanismo de distribución diseñado para proteger se convirtió en el vector del desastre.
Lección 1: depender de un único proveedor es un riesgo existencial
Si la actualización de un solo proveedor puede tumbar toda tu operación, tu arquitectura tiene un punto único de fallo.
Esto se aplica a todo: tu proveedor de cloud, tu herramienta de seguridad, tu base de datos gestionada, tu CDN. No digo que no uses servicios de terceros. Digo que debes diseñar asumiendo que cualquiera de ellos puede fallar.
Preguntas que deberías hacerte ahora mismo:
- Si tu proveedor de cloud principal se cae durante 4 horas, qué pasa con tus usuarios
- Si tu herramienta de monitorización deja de funcionar, cómo te enteras de que algo está roto
- Si tu proveedor de autenticación se cae, pueden tus usuarios seguir usando el producto
Tus respuestas a estas preguntas definen tu nivel de resiliencia. Y si la respuesta a todas es "nos quedamos parados", tienes un problema de arquitectura.
Lección 2: las actualizaciones automáticas sin gates son peligrosas
CrowdStrike distribuyó la actualización defectuosa a todos los endpoints a la vez. Sin canary deployment. Sin rollout escalonado. Sin aprobación manual para sistemas críticos.
Para una startup, la lección es directa: cualquier cambio que toque producción necesita gates.
- Canary deployments: despliega primero al 1% de los usuarios. Si no hay errores, sube al 10%, luego al 50%, luego al 100%.
- Feature flags: separa el despliegue del lanzamiento. Puedes tener código en producción sin que esté activo.
- Rollback automático: si las métricas de error superan un umbral, revierte automáticamente.
- Aprobación manual para infraestructura crítica: no todo debe automatizarse. Los cambios en bases de datos, configuración de seguridad o infraestructura de red merecen ojos humanos.
Esto no es burocracia. Es ingeniería.
Lección 3: necesitas ingenieros que entiendan lo que están desplegando
Muchas startups externalizan la seguridad por completo. Contratan a un proveedor, instalan el agente y se olvidan. Nadie dentro de la empresa entiende qué hace ese agente, cómo interactúa con el sistema operativo ni qué permisos tiene.
El incidente de CrowdStrike demuestra por qué eso es peligroso. El Falcon Sensor opera a nivel de kernel. Tiene acceso total al sistema. Cuando falla, no es una app que se cierra: es el sistema operativo entero el que deja de funcionar.
No necesitas un equipo de seguridad de 10 personas. Pero sí necesitas al menos un ingeniero senior que:
- Entienda las integraciones de tus proveedores de seguridad a nivel técnico
- Pueda auditar qué accesos tiene cada herramienta de terceros
- Sepa responder cuando algo se rompe, sin depender del soporte del proveedor
- Sepa evaluar el riesgo de cada herramienta que opera con privilegios elevados
La seguridad delegada sin supervisión no es seguridad. Es hacerse ilusiones.
Lección 4: los planes de respuesta a incidentes no son opcionales
Cuando estalló el apagón de CrowdStrike, las empresas que se recuperaron más rápido tenían algo en común: un plan de respuesta a incidentes documentado y ensayado.
No hablo de un documento de 80 páginas que nadie ha leído. Hablo de respuestas claras a preguntas simples:
- Quién lidera la respuesta cuando hay un incidente
- Cómo se comunica el equipo durante una crisis (si Slack se cae, cuál es el plan B)
- Dónde está el runbook para los escenarios más probables
- Quién tiene acceso para hacer rollbacks, reiniciar servicios o escalar con los proveedores
- Cómo se comunica a los usuarios lo que está pasando
En muchas startups, la respuesta a todo esto es "ya lo iremos viendo". Eso funciona hasta que deja de funcionar. Y cuando deja de funcionar, cada minuto de caída es dinero, reputación y confianza de los usuarios que se esfuman.
Si tu equipo no ha hecho nunca un simulacro de incidente, este fin de semana es un buen momento para empezar.
Lección 5: la resiliencia es una disciplina de ingeniería
La resiliencia no es algo que se compra. No es un producto SaaS. No es una casilla que marcar en una auditoría de compliance. Es una disciplina de ingeniería que exige diseño intencional, implementación cuidadosa y mantenimiento continuo.
Implica:
- Redundancia: ningún punto único de fallo en ningún nivel (infraestructura, datos, proveedores, personas)
- Degradación elegante: cuando algo falla, el sistema sigue funcionando con capacidad reducida en lugar de colapsar por completo
- Circuit breakers: mecanismos que detectan fallos en cascada y los aíslan antes de que se propaguen
- Chaos engineering: probar deliberadamente qué pasa cuando las cosas fallan, antes de que fallen en producción
- Observabilidad: no puedes arreglar lo que no puedes ver. Logs, métricas, alertas, dashboards
Y lo más importante: requiere personas que hayan diseñado sistemas para sobrevivir a fallos. Ingenieros que han vivido incidentes, que saben lo que se siente cuando un sistema se cae a las 3 de la madrugada, y que diseñan con eso en mente.
Lo que yo pondría en marcha este trimestre
Si eres una startup en fase temprana, probablemente no necesitas redundancia multi-cloud ni un equipo de SRE de 5 personas. Pero sí necesitas lo básico:
- Un ingeniero senior que entienda de DevOps y seguridad
- Despliegues con gates, no pushes directos a producción
- Un plan mínimo de respuesta a incidentes
- Una auditoría de qué proveedores tienen acceso a qué, y con qué privilegios
- Backups probados (no solo configurados: probados restaurándolos)
El problema es que encontrar ingenieros con experiencia real en resiliencia operativa y gestión de incidentes no es fácil. Es un perfil que se forja con años de experiencia, no con cursos.
En Conectia trabajamos con ingenieros senior de LATAM que han construido y operado infraestructura en producción para empresas en crecimiento. Perfiles de DevOps y SRE que entienden la gestión del riesgo de proveedores, que han diseñado pipelines de despliegue con gates y que saben construir sistemas que sobreviven cuando las cosas fallan. Porque siempre acaban fallando.
El incidente de CrowdStrike no fue el primero y no será el último. La pregunta no es si tu startup se enfrentará a un incidente de este tipo. La pregunta es si tu equipo estará preparado para responder cuando ocurra.
¿Tiene tu equipo la capacidad técnica para responder a un incidente en producción? Habla con un CTO — te ayudamos a incorporar ingenieros senior de DevOps y SRE que construyen sistemas resilientes desde el día uno.
