CrowdStrike presenta un mea culpa al comité de la Cámara

Un ejecutivo arrepentido de CrowdStrike describió esta semana la defectuosa actualización de configuración de contenido de la compañía del 19 de julio, que bloqueó 8,5 millones de sistemas Windows en todo el mundo, como resultado de una «tormenta perfecta» de problemas que desde entonces se han solucionado.

Al testificar ante miembros del Comité de Seguridad Nacional de la Cámara de Representantes el 24 de septiembre, el vicepresidente senior de CrowdStrike, Adam Meyers, se disculpó por el incidente y aseguró al comité que desde entonces la compañía ha tomado medidas para evitar un error similar.

El Comité de la Cámara llamó a una audiencia en julio, después de que una actualización de la configuración de contenido de CrowdStrike para el Falcon Sensor de la compañía colapsara millones de sistemas Windows y provocara interrupciones generalizadas y prolongadas del servicio para empresas, gobiernos y organizaciones de infraestructura crítica en todo el mundo. Algunos han estimado que las pérdidas de las organizaciones afectadas por el incidente ascienden a miles de millones de dólares.

El juego de ajedrez salió mal

Cuando se le pidió que explicara la causa raíz del incidente, Meyers le dijo al comité de la Cámara que el problema se debía a una falta de coincidencia entre las expectativas del sensor Falcon y el contenido real de la actualización de la configuración de contenido.

Básicamente, la actualización provocó que Falcon Sensor intentara seguir una configuración de detección de amenazas que no tenía reglas correspondientes. “Si piensas en un tablero de ajedrez [and] «Estábamos tratando de mover una pieza de ajedrez a un lugar donde no había ningún cuadrado», dijo Meyers. “Eso es exactamente lo que pasó en el sensor. Fue una especie de tormenta perfecta de problemas”.

Los procesos de validación y prueba de CrowdStrike para actualizaciones de configuración de contenido no detectaron el problema porque este escenario en particular no había ocurrido antes, explicó Meyers.

El representante Morgan Luttrell de Texas calificó el hecho de que CrowdStrike no haya detectado la actualización defectuosa como un «descuido muy grande», especialmente para una empresa con una gran presencia en sectores gubernamentales y de infraestructura crítica. “Mencionaste a Corea del Norte, China e Irán. [and other] «Los actores externos intentan comunicarse con nosotros todos los días», dijo Luttrell durante la audiencia. «Nos disparamos en el pie con la actualización incorrecta». Luttrell quería saber qué medidas preventivas ha implementado CrowdStrike desde julio.

En su testimonio escrito y en sus respuestas a las preguntas de los miembros del comité, Meyers enumeró varios cambios que CrowdStrike ha implementado para evitar una falla similar. Las medidas incluyen nuevos procesos de validación y prueba, más control para los clientes sobre cómo y cuándo recibirán actualizaciones y un proceso de implementación por fases que permite a CrowdStrike revertir rápidamente una actualización si surgen problemas. Después del incidente, CrowdStrike también comenzó a tratar todas las actualizaciones de contenido como código, lo que significa que están sujetas al mismo nivel de control y pruebas que las actualizaciones de código.

Varios cambios

«Desde el 19 de julio de 2024, hemos realizado numerosas mejoras en nuestros procesos de implementación para hacerlos más sólidos y evitar que un incidente de este tipo vuelva a ocurrir, sin comprometer nuestra capacidad de proteger a los clientes de las amenazas cibernéticas que evolucionan rápidamente», dijo Meyers en testimonio escrito.

Meyers defendió la necesidad de que empresas como CrowdStrike sigan realizando actualizaciones a nivel de kernel del sistema operativo cuando los miembros del comité le preguntaron sobre los riesgos potenciales asociados con la práctica. «Yo sugeriría que, si bien las cosas se pueden hacer en modo usuario, desde una perspectiva de seguridad, la visibilidad del kernel es ciertamente crítica», explicó. en su Análisis de causa raíz En relación con el incidente, CrowdStrike señaló que todavía queda mucho trabajo por hacer en el ecosistema de Windows para permitir que los proveedores de seguridad implementen actualizaciones directamente en el espacio del usuario en lugar de en el kernel de Windows.

¿Te falta una descripción general?

Sin embargo, algunos sintieron que la audiencia no fue lo suficientemente lejos como para identificar y centrarse en algunas de las lecciones más importantes del incidente. «Ver la interrupción del 19 de julio como una interrupción de CrowdStrike es simplemente incorrecto», dijo Jim Taylor, director de productos y tecnología de RSA. «Más de 8 millones de dispositivos fallaron, y no es culpa de CrowdStrike que no tuvieran copias de seguridad para sobrevivir a una falla o que los sistemas Microsoft que ejecutaban no tuvieran copias de seguridad locales disponibles de forma predeterminada», señaló.

La interrupción global fue el resultado de años de descuidar la responsabilidad de construir sistemas resistentes y descuidar a un número limitado de proveedores de nube para realizar funciones comerciales críticas. «Cuando te concentras en una empresa, los árboles no pueden ver el bosque», dice Meyers. «Me hubiera gustado que en la audiencia se hubiera preguntado más sobre lo que están haciendo las organizaciones para construir sistemas resilientes que puedan soportar fallas».

Grant Leonard, director de seguridad de la información (CISO) de Lumifi, dijo que una deficiencia de la audiencia fue su excesivo énfasis en la causa raíz de la interrupción y su relativa falta de enfoque en las lecciones aprendidas. «Las preguntas sobre el proceso de toma de decisiones de CrowdStrike durante la crisis, sus estrategias de comunicación con los clientes afectados y sus planes para prevenir incidentes similares en el futuro habrían proporcionado a la industria conocimientos más prácticos», dijo Leonard. «Investigar estas áreas podría ayudar a otras empresas a mejorar sus protocolos de respuesta a incidentes y procesos de control de calidad».

Leonard espera que la audiencia conduzca a un énfasis renovado en los procesos de garantía de calidad en toda la industria de la ciberseguridad. «Probablemente veremos un aumento en las revisiones exhaustivas y ensayos de los planes de continuidad del negocio y recuperación ante desastres», afirma. El incidente también podría conducir a un enfoque más cauteloso con respecto a las actualizaciones y parches automáticos en toda la industria, y las empresas implementarían protocolos de prueba más estrictos. «Además, podría llevar a una reevaluación de las cláusulas de responsabilidad e indemnización en los contratos de servicios de ciberseguridad, lo que podría conducir a un cambio en la distribución de responsabilidad entre proveedores y clientes».