Seis conclusiones que todo CIO debería extraer de la debacle de CrowdStrike

A principios del año 2000, tras la respuesta eficaz y sin precedentes de las TI al efecto 2000, el mundo hizo una chapuza de revisión a posteriori. Consumidos por la necesidad de tener a alguien a quien culpar, personas influyentes de todo el mundo proclamaron que se trataba de un engaño perpetrado por TI para inflar los presupuestos de tecnología y su importancia percibida.

Feliz de tener un chivo expiatorio, el mundo se burló ignorantemente y luego pasó al siguiente pseudo-culpable.

Así que ahora tenemos CrowdStrike. Consumidos por la necesidad de tener a alguien a quien culpar, y con Microsoft como un blanco fácil encaramado precariamente a una dudosa pila de parches, las personas influyentes de todo el mundo están decididas a gastar sus energías y (hablando de dudosa) experiencia, culpabilizando en lugar de construir una visión sistémica de la situación.

Pero antes incluso de empezar: parece que, por muy atractiva que sea la historia, Southwest Airlines no era inmune al fallo CrowdStrike porque sus servidores funcionan con Windows 3.1. (Para una visión en profundidad, véase No, Southwest Airlines no sigue utilizando Windows 3.1 – OSnews). Luego está esta sencilla prueba de verosimilitud: estamos hablando de una red que tiene que dar soporte a varias decenas de miles de usuarios finales. ¿Cuál es la causa más probable de fallo de los sistemas en una red basada en Windows 3.1 que tiene que escalar tanto: un mal parche de CrowdStrike o el propio Windows 3.1? Sería un poco como si Southwest basara su tecnología de motores en cinta aislante y papel de aluminio. Tal vez se podría hacer, pero sería igual de propenso a estrellarse.

Lamentablemente, la inverosimilitud no persuadirá a los ejecutivos que sufren un sesgo de confirmación según el cual la petición de TI de financiar la gestión del ciclo de vida es, como el efecto 2000, innecesaria.

Suspiro.

Es mi opinión: en la era de los ciberataques impulsados por la inteligencia artificial, lo último que hay que hacer es adoptar la obsolescencia como estrategia.

En su lugar, es mejor prestar atención a lo que sigue del lío de CrowdStrike.

Conclusión nº 1: La interrupción de CrowdStrike fue más que un defecto técnico

Sí, Microsoft permitió el acceso a su kernel mientras que Apple y la mayoría de las variantes de Linux no lo hicieron, permitiendo los malos parches que causaron el problema. Sin embargo, no se trató de pereza ni de una toma de decisiones chapucera por parte de Microsoft. Microsoft lo hizo porque los reguladores de la UE insistieron en ello.

Los reguladores de la UE tampoco insistieron porque fueran tontos. Su objetivo era garantizar una competencia leal en el mercado europeo de los sistemas operativos. Fue un compromiso que no mereció la pena. Pero los compromisos no siempre salen bien. Por eso se llaman “compensaciones”.

Conclusión nº 2: ¿Quiere culpar a alguien? Culpe a la Reina Roja

CrowdStrike está en el negocio de la ciberseguridad. Muchos, y quizás la mayoría de los proveedores de ciberseguridad reconocen que están atrapados en una “Estrategia de la Reina Roja”. Al igual que la némesis de Alicia en el País de las Maravillas, tienen que correr tan rápido como puedan para permanecer en un lugar.

Es decir, están sometidos a una presión incesante para lanzar respuestas más nuevas y sofisticadas a amenazas más nuevas y sofisticadas.

Es otra forma de que esto sea un problema sistémico. Los proveedores de ciberseguridad como CrowdStrike tienen que desplegar parches y versiones más rápidamente de lo que dictaría la prudencia, con un “más rápidamente” que se traduce en “insuficientemente probado”.

Los proveedores están atrapados por la Reina Roja. Pueden defenderse contra los nuevos programas maliciosos en los calendarios de lanzamiento de los malos, asumiendo el riesgo de enviar parches con errores, o pueden no defender a sus clientes contra los nuevos programas maliciosos y dejarlos vulnerables.

Cuanto más rápido irrumpan los nuevos programas maliciosos, más probabilidades tendrán los proveedores de ciberseguridad de pasar por alto defectos en sus parches y versiones.

Como CIO, usted tampoco es inmune al efecto Reina Roja. El departamento de TI está sometido a una presión constante para entregar las cosas con rapidez, y nadie quiere oír que ralentizar las cosas para reducir el riesgo es una necesidad.

La roca se encuentra con el lugar duro. Entonces, conoce a DevOps.

Conclusión nº 3: Tenemos que analizar DevOps detenidamente

DevOps ya no es sólo el lugar donde las pruebas de aceptación del usuario han ido a morir. Es el lugar donde la integración continua / entrega continua (CI / CD) se suponía que era la “mejor práctica”. Pero demasiados adoptantes han sustituido el despliegue por la entrega, con la diferencia de que entregar significa crear compilaciones liberables para un mayor control de calidad, no desplegarlas a PROD de inmediato.

Conclusión nº 4: Las líneas se han difuminado

Érase una vez los bugs. Érase una vez el malware. Ahora, la única diferencia entre los bugs y las formas destructivas de malware es la intención del autor.

Conclusión nº 5: La preparación lo es todo

Las empresas que fueron resistentes y recuperables ante el fallo de CrowdStrike lo fueron porque se habían preparado para ataques de ransomware y otras situaciones de recuperación.

Conclusión nº 6: Persuadir a la ELT sobre las ventajas y desventajas de las TI merecerá la pena

Todo esto nos lleva de nuevo a un reto que todos los CIO deben superar si quieren conservar la más mínima pizca de cordura: asegurarse de que el equipo de liderazgo ejecutivo de la empresa acepta la naturaleza de las compensaciones del comercio de TI. La debacle de CrowdStrike le ofrece un caso práctico que puede utilizar para poner de relieve las principales disyuntivas de TI. El dilema de Red Queen -la elección entre velocidad y riesgo descrita anteriormente- es un buen punto de partida para iniciar la conversación.

A continuación, puede solicitar la ayuda del ELT para establecer el punto de equilibrio adecuado para algunas compensaciones clave con las que su propia organización de TI tiene que lidiar.