- Antes de la gran interrupción de julio de 2024, exempleados dicen que ya habían comunicado a la gerencia plazos ajustados, cargas de trabajo excesivas y crecientes problemas técnicos
- Muchos de los 24 exempleados entrevistados consideraban que los ejecutivos priorizaban la velocidad por encima de la calidad, y que algunos empleados asumían tareas de codificación y operaciones sin suficiente capacitación
- CrowdStrike rechazó gran parte de los relatos de los exempleados y respondió que las fuentes eran “algunos exempleados descontentos despedidos por violar claramente las políticas de la empresa”
- La falla en la actualización de Falcon Sensor en julio dejó paralizadas 8,5 millones de computadoras, causó hasta US$5.400 millones en pérdidas a empresas Fortune 500, y CrowdStrike perdió cerca de US$60 millones en contratos previstos para ese trimestre
- Aunque no se confirmó una relación directa entre los problemas de calidad y operación de largo plazo y la interrupción de julio, CrowdStrike enfrentó luego recortes en sus previsiones de ingresos y ganancias, testimonios ante el Congreso y presión por demandas
Preocupaciones de calidad acumuladas desde antes de la interrupción
- Exingenieros de software de CrowdStrike dicen que, desde más de un año antes de la gran interrupción de julio, habían comunicado a sus superiores fechas límite ajustadas, cargas de trabajo excesivas y crecientes problemas técnicos
- Según los exempleados, esas inquietudes se plantearon repetidamente en reuniones, correos electrónicos y entrevistas de salida
- Jeff Gardner, exdiseñador sénior de experiencia de usuario, dijo que “la velocidad era lo más importante” y que el control de calidad no era parte del proceso ni de la conversación
- Un exgerente sénior afirmó que, en varias reuniones, empleados advirtieron que lanzar un “producto que no podemos soportar” podía hacer “fallar” a los clientes
Testimonios divergentes de exempleados y refutación de la empresa
- Semafor entrevistó a un total de 24 exempleados
- 10 dijeron que fueron despedidos o afectados por recortes de personal
- 14 dijeron que renunciaron voluntariamente
- Una persona permaneció en la empresa hasta el verano de 2024
- Tres exempleados no coincidieron con los relatos de otros empleados
- Joey Victorino, quien dejó la empresa en 2023, evaluó que CrowdStrike era “muy meticulosa en todo lo que hacía”
- La empresa negó gran parte de lo publicado
- Afirmó que la información provenía de “algunos exempleados descontentos despedidos por violar claramente las políticas de la empresa”
- Indicó que realiza pruebas y controles de calidad rigurosos para garantizar la resiliencia del producto, y que rechaza por completo las versiones que sostienen lo contrario
La interrupción de julio tras un rápido crecimiento
- CrowdStrike fue fundada en 2011 y, con el lanzamiento del paquete antivirus Falcon en 2013, creció hasta convertirse en una de las principales empresas del sector de ciberseguridad
- Después de salir a bolsa en 2019, aumentó su plantilla en miles de empleados, y para el cierre del año fiscal 2024 sus ingresos habían crecido más de 1.000%
- En julio de 2024, una actualización de software defectuosa derivó en lo que podría ser la mayor interrupción de TI de la historia
- 8,5 millones de computadoras quedaron paralizadas
- Las pérdidas de empresas Fortune 500 podrían alcanzar hasta US$5.400 millones
- Pasajeros aéreos quedaron varados en aeropuertos, se bloqueó el acceso a la banca en línea y centros de llamadas de emergencia quedaron fuera de línea
- El CFO Burt Podbere dijo en la presentación de resultados del 28 de agosto que la empresa perdió alrededor de US$60 millones en contratos que esperaba cerrar en el trimestre terminado el 31 de julio
- El CEO George Kurtz afirmó el 19 de julio que no olvidaría la magnitud del incidente y que se asegurarían de que algo así no volviera a ocurrir
Pruebas, datos de clientes y el caso de LogScale
- Algunos exempleados dicen que, al intentar mantener el ritmo de lanzamientos de productos, a veces se apresuraban las revisiones de calidad del software
- Preston Sego, quien trabajó en la empresa de 2019 a 2023, afirmó que a veces era difícil convencer a la gente de realizar pruebas suficientes
- Su trabajo consistía en revisar si las pruebas de los desarrolladores de experiencia de usuario detectaban correctamente los bugs antes de que los cambios de código se desplegaran a clientes
- Sego dijo que fue despedido en febrero de 2023 por “insider threat” después de criticar en el Slack interno la política de regreso a la oficina
- CrowdStrike indicó que no comenta asuntos individuales de personal
- En el área de servicios profesionales hubo casos en los que información privada de un cliente estuvo a punto de subirse por error tres veces a la carpeta de otro cliente
- CrowdStrike confirmó el incidente y señaló que la causa fue un error manual de ingreso de datos
- Explicó que los datos eran información básica como nombres de host, direcciones IP y nombres de dominio
- Indicó que actualmente ejecuta verificaciones para evitar que datos privados de clientes se envíen incorrectamente
- Varios exempleados dijeron que también hubo problemas con Falcon LogScale
- Uno recordó que, por una actualización defectuosa, alertas en tiempo real sobre posible actividad maliciosa se desactivaron brevemente al menos dos veces
- Algunos ingenieros dijeron que, en reuniones internas, atribuyeron esto a calendarios ajustados
- CrowdStrike negó ese caso, señalando que no tenía conocimiento de ninguna “bad update” por la cual los clientes no recibieran alertas
- La empresa indicó que LogScale no es un servicio diseñado para avisar “en tiempo real” a los clientes sobre posibles brechas de datos
Polémica por el lanzamiento de Falcon OverWatch Cloud Threat Hunting
- Un exempleado dijo que Falcon OverWatch Cloud Threat Hunting, lanzado en 2022, salió al mercado de forma apresurada
- El servicio consiste en que expertos de seguridad de CrowdStrike buscan comportamientos sospechosos que podrían indicar una intrusión en entornos cloud de clientes, como Amazon Web Services
- Un exgerente sénior que participó en el proyecto dijo que a ingenieros y threat hunters se les asignó en 2 meses un trabajo que normalmente tomaría un año
- Afirmó que, al momento del lanzamiento, los threat hunters carecían de herramientas internas necesarias para monitorear por completo los sistemas cloud de los clientes, y que hasta el verano pasado, cerca de un año después del lanzamiento, respondían a alertas de sistemas de seguridad existentes
- El mismo exgerente sénior dijo que se asignó a detección de amenazas en la nube a personal capacitado para vigilar sistemas de computadoras de clientes, como laptops y equipos de escritorio, sin hacer obligatoria una nueva capacitación
- CrowdStrike confirmó que utilizó ingenieros existentes en lugar de contratar un nuevo equipo de “cloud threat hunters”
- Dijo que, al tratarse de un servicio nuevo, no era posible conseguir “cloud threat hunters” con experiencia, y que era imposible contratar personas con capacitación específica en un campo que no existía antes de que CrowdStrike lo desarrollara
- Señaló que no hizo obligatoria la nueva capacitación, pero la ofreció a quienes la quisieran
- Agregó que los empleados reciben capacitación periódica acorde a sus funciones
- SANS Institute ofrecía desde 2020, dos años antes del lanzamiento del servicio de CrowdStrike, programas de capacitación y charlas sobre seguridad cloud
- CrowdStrike negó que el servicio OverWatch no hubiera funcionado siempre según lo previsto, que el proyecto se hubiera apresurado o que los threat hunters carecieran de las herramientas necesarias
Código antiguo y aumento de la carga de trabajo
- Sego dijo que era frecuente que código escrito de forma temporal para avanzar con un proyecto luego no se mejorara
- Un exingeniero sénior afirmó que pidió más de 20 veces tiempo para corregir código antiguo, pero no se lo concedieron
- CrowdStrike respondió que la codificación es un proceso iterativo, y que en la industria del software es habitual desplegar código y mejorarlo continuamente con base en la experiencia real del producto
- Los exempleados citaron el aumento de la carga de trabajo como una de las razones por las que no pudieron mejorar el código antiguo
- Algunos dijeron que asumieron más tareas tras recortes de personal y reorganizaciones
- CrowdStrike se negó a comentar sobre despidos, y afirmó que la cantidad de empleados aumentó de forma constante cada año
- Explicó que el gasto en I+D creció de US$371,3 millones en el año fiscal 2022 a US$768,5 millones en el año fiscal 2024, principalmente por el aumento de la plantilla
- La empresa dijo que recibe, evalúa e incorpora comentarios diversos de sus equipos, y que se enfoca en mantener una cultura de alto desempeño
- También agregó que fue incluida durante los últimos 4 años en la lista Fortune 100 Best Companies to Work For
Costos y pasos posteriores tras la interrupción
- CrowdStrike atribuyó la causa de la interrupción de julio a una falla en la actualización de Falcon Sensor
- El incidente redujo el valor bursátil de la empresa en más de US$21.000 millones
- Le siguieron varias demandas, y Delta Airlines estimó sus pérdidas en US$550 millones tras la cancelación de miles de vuelos, además de plantear la posibilidad de demandar
- Adam Meyers, vicepresidente sénior, tiene previsto testificar ante el Congreso en septiembre de 2024
- Michael Sentonas, President de CrowdStrike, aceptó el premio “Most Epic Fail” en una convención de hackers en agosto y dijo que es muy importante reconocerlo cuando uno se equivoca de forma terrible
- La relación entre los problemas de largo plazo mencionados por los exempleados y la interrupción de julio aún no se ha confirmado
1 comentarios
Opiniones de Hacker News
Un artículo armado apoyándose en exempleados descontentos que dicen cosas como “la velocidad era lo más importante, y el control de calidad no formaba parte de nuestro proceso ni de nuestras conversaciones” parece valer tanto como una tarjeta de regalo de disculpa de GrubHub
No tengo una buena opinión de CrowdStrike, pero si alguien está resentido y tiene la oportunidad de recibir atención, cualquiera puede decir cualquier cosa. Además, esa persona era diseñadora y probablemente ni siquiera estaba involucrada directamente en el control de calidad
El artículo también dice que, de los 24 exempleados, 10 fueron despedidos o afectados por recortes, 14 se fueron por voluntad propia, y 3 no estuvieron de acuerdo con otros testimonios. Joey Victorino dijo que CrowdStrike era “meticulosa en todo”, así que al final hay muy pocas cosas seguras
Se empujó directamente a entornos de producción de todo el mundo, sin despliegue gradual, y tampoco había un laboratorio donde el código nuevo se instalara y ejecutara de verdad. Se veía humo, y también hay varios testimonios de que hubo fuego; puede verse en ese contexto
Más bien, es probable que esos empleados hablen con más honestidad sobre la situación interna, y aunque no fueran del departamento de aseguramiento o control de calidad, podían conocer el ambiente. Esa información es más creíble que la de alguien que simplemente le sigue la corriente a la empresa
Se puede afirmar que Semafor hizo mal su trabajo o actuó con mala fe, pero no es un argumento fácil, considerando que en los propios párrafos citados también presenta evidencia en contra
Si lo escuchas de un solo exempleado de la empresa, podría deberse a circunstancias personales; pero si varias personas expresan la misma queja, hay que tomarlo mucho más en serio
Es más probable que una persona insatisfecha deje una reseña, y también es más probable que quien dejó CrowdStrike haya tenido algún descontento. Son datos sesgados, pero aun así son datos útiles
Me sorprende lo rápido que los comentarios aquí descartan esto. Exempleados, incluidos ingenieros, están diciendo que la cultura de desarrollo riesgosa de su antigua empresa contribuyó a una falla masiva global y a incidentes anteriores
Ese tipo de testimonio debería considerarse confiable, o al menos información útil, pero muchos parecen atacar solo a la diseñadora UX que dijo que “el control de calidad no formaba parte de nuestro proceso”
Tal vez mucha gente se ve reflejada en la frase “la velocidad de lanzamiento lo era todo”, es decir, “muévete rápido y rompe cosas”. Porque les resulta familiar la cultura de la emoción de desplegar código, apagar incendios, generar impacto y pasarle el trabajo pendiente al siguiente ingeniero o gerente
Desde la perspectiva de la era de tasas de interés cero, este tipo de fallas de proceso quizá no se veía como un bug, sino como una feature. El énfasis en la “calidad” también puede haber parecido una barrera molesta que estorbaba el divertirse trabajando con dinero de los clientes
Hace tiempo, un cliente pidió una solución personalizada de alta seguridad basada en un driver de kernel. Ejecutaban una base de datos importante en una computadora offline, y había que rastrear todas las llamadas al sistema para alertar y registrar exactamente cualquier cambio de datos. Los backups tampoco podían salir jamás al exterior, y exigían procedimientos de seguridad antes de la instalación en sitio, como verificar si Windows tenía hooks en ntdll. No se toleraban excepciones, cuelgues ni deadlocks, y perderse una sola llamada al sistema habría sido un desastre
Por eso, cada vez que cambiaba el código del driver, se volvía a probar con un procedimiento definido en 7 computadoras de oficina con hardware distinto, y la prueba final antes del lanzamiento era aún más amplia
Visto con ese estándar, CrowdStrike parece casi totalmente amateur. Tampoco ha contribuido a la comunidad de seguridad, y su nivel de investigación parece el de un investigador de seguridad junior. Su actitud de exagerar abiertamente o sacar conclusiones apresuradas tampoco se ve bien en la comunidad
Hay que mirar a empresas realmente profesionales como Kaspersky y Checkpoint. No solo crearon soluciones de seguridad probadas y de primer nivel, sino que también han contribuido gratis con investigación valiosa para la comunidad, como encontrar y reportar zero-days antes de que sean explotados. CrowdStrike merece las críticas
De las estrategias de reorganización que vi repetirse durante años, la que más se me quedó fue “vamos a entrenar a todo ingeniería para que sean recursos reemplazables de inmediato en cada dominio”. Es dar vueltas en el mismo lugar
La infraestructura crítica de software debería regularse como la infraestructura física crítica. Así como no confiamos en que quienes construyen edificios y puentes “harán lo correcto por su cuenta”, sino que exigimos regulaciones e inspecciones, debería ser igual
Si cuando el software se detiene millones de personas en todo el mundo quedan varadas, eso es infraestructura crítica. Esta vez fue un “accidente” común, pero en el futuro, si actores de amenazas intentan derribar sistemas en un contexto de guerra, podría ser mucho más grave
Si se trata de un área crítica para la seguridad, debería examinarse con más rigor que otras, y no dejarse en manos de procesos de aseguramiento de calidad autorregulados por empresas con fines de lucro. Hace falta más revisión antes de apretar el botón grande
Además, la frase entre comillas no es mía, sino una objeción que he oído de otras personas cuando saco el tema de la regulación
El software casi siempre se hace barato y rápido. Incluso la NASA ha tenido cohetes que explotaron en vuelo por errores de software
Ayer por la mañana me enteré de que una persona que conocía acababa de fallecer y que el funeral quedó programado para la próxima semana.
Esa persona había pasado más de un mes en el hospital y, a los pocos días de volver a casa, sufrió un ACV.
Entonces recordé que originalmente tenía programada una cirugía importante, pero se retrasó por la falla de CrowdStrike. Pasaron varias semanas hasta que pudieron reprogramarla y realizarla.
Me quedo pensando si el resultado habría sido distinto si hubiera recibido la cirugía ese día y no hubiera tenido que pasar varias semanas más en el hospital, bajo el estrés de su estado y de su futuro.
Es uno de los cientos de miles de perjuicios que debieron generarse por este incidente, pero como no se convierte en una cifra monetaria, en realidad no se “contabiliza”.
Por ejemplo, si le das una patada en la rodilla a un niño de 3 años y le dejas una discapacidad de por vida, obviamente te llamarían monstruo. Pero si apoyas una reforma educativa que desplaza la lengua de señas estadounidense de las escuelas y hace que niños sordos crezcan sin lenguaje durante su etapa de desarrollo, ni siquiera tenemos palabras adecuadas para expresar la escala acumulada y el daño de ese acto.
No manejamos bien el daño distribuido. Una gran razón es que no vemos, ni podemos ver, la totalidad de los daños concretos que produce.
Me genera dudas que la persona citada como experta en procesos de ingeniería sea una diseñadora UX sénior. No parece que hubiera estado muy cerca del proceso de distribución de parches del kernel.
No intento justificar el control de calidad de CrowdStrike, pero en varios entornos de desarrollo de software que me tocó vivir también era bastante común que faltara control de calidad.
Al leer el artículo, puede dar la impresión de que todos los proyectos de software se prueban bien, pero en mi experiencia la mayoría se lanza a las apuradas.
Puede estar bien para software de entretenimiento o software empresarial de baja criticidad, pero es una pésima idea para software crítico. Lamentablemente, la actitud de “moverse rápido” se extendió a lugares donde no debería existir.
La industria parece un lugar donde un pequeño grupo de personas capaces logra mantener los sistemas funcionando como puede, mientras en el resto se revela una incompetencia técnica impactante. La gerencia prioriza el ahorro de costos a corto plazo por encima de la calidad cada vez que tiene oportunidad, y el resultado es una deuda técnica espantosa y una fuerza laboral sobrecargada y desmotivada. Si hablar de problemas de calidad te perjudica, al final la gente deja de preocuparse por la calidad.
Algunos exempleados pueden estar resentidos y hablar de CrowdStrike de forma que la deje mal. Eso pasa en todas las empresas.
Pero CrowdStrike ahora tiene credibilidad cero. No creo ni una palabra de lo que digan.
Todo lo que se sabe de CrowdStrike me recuerda a Knight Capital. Pequeños problemas culturales que derivan en una disfunción total y terminan llevando a un bug capaz de acabar con la empresa.
El problema de trading que causó caos en el mercado bursátil el miércoles por la mañana ya le estaba costando eso, y Knight Capital Group anunció que perdió 440 millones de dólares al vender todas las acciones que había comprado por error debido a una falla informática.
“Falla”...
https://en.wikipedia.org/wiki/Therac-25
En una empresa anterior, algunos clientes y aseguradoras de responsabilidad civil impulsaban con fuerza la adopción de CrowdStrike por motivos de cumplimiento normativo. En particular, BCG exigía usar CrowdStrike.
Convencerlos de no usar CrowdStrike fue una batalla realmente difícil. Al final lo logramos, pero hizo falta mucho tiempo y muchas reuniones para persuadir a varias partes interesadas. Creo que mucha gente simplemente habría cedido y lo habría implementado.
Trabajé en un equipo que desplegaba el agente de CrowdStrike en una organización, y uno de los mayores problemas era que el daemon generaba una cantidad enorme de logs sin que hubiera una configuración para detenerlos o reducirlos.