CrowdStrike: el Caos del Riesgo Proveedor

Hoy, los accionistas de CrowdStrike han perdido más de 8,000 millones de dólares. Los de Microsoft 32,000 millones de dólares. ¿Por qué?

El desencadenante. CrowdStrike, proveedor de Microsoft, realizó una actualización de su sistema. La actualización tenía fallos críticos que en un principio no se detectan. Empieza la actualización y estos fallos críticos colapsan el sistema en el que están instalados, en este caso principalmente en el CIEM de Azure en Microsoft.

Consecuencias a corto plazo. Los clientes de Microsoft que utilizan lo anterior ven aparecer la famosa pantalla azul, BSOD (Blue Screen of Death). Mala cosa. Muchos sistemas dejan de ser accesibles en todo tipo de actividades. Vuelos, cajeros, programas de televisión, hospitales, infraestructuras, peajes, etc., dejan de estar disponibles para el usuario, es decir, se produce una rotura del famoso “business continuity”.

Reacción. CrowdStrike pone a su gente, también Microsoft así como la comunidad de expertos, y al final parece que se localiza el error. Se sugiere un primer parche, la ya famosa guía:

·      Reinicia Windows en “Safe Mode” o en “Windows Recovery Environment”

·      Navega hasta el Directorio C:\Windows\System32\drivers\CrowdStrike

·      Busca el fichero que coincide con “C-00000291*.sys”, y bórralo.

·      Reinicia el “host” en modo “Normal”

Sin embargo, el propio CEO de la compañía ha advertido a lo largo del día que, aun teniendo los privilegios adecuados, esta tarea se tiene que hacer de forma manual. Así que no se espera que se vuelva a la normalidad en una serie de días. Si en determinadas circunstancias no se cuenta con esos privilegios o con el acceso físico, la cosa se puede complicar y por tanto demorar aún más.

A todo esto, estamos asumiendo que no haya ningún fallo (“bug”) más en sistema o que las consecuencias indirectas no se hayan metastatizado. Nadie puede asegurar a día de hoy, con los datos que se tienen, que no puedan aflorar nuevas consecuencias, hoy desconocidas, en los próximos días.

Lecciones para el futuro. Esto no es un ataque cibernético (“Hacking”). Esto es un problema de IT. Sin embargo, la consecuencia para el cliente final es muy parecida: los clientes de Microsoft no pueden continuar con el servicio y los clientes finales no reciben el servicio que han contratado.

CrowdStrike, con su sistema Falcon Cloud Security, es, para entendernos, un sofisticado antivirus que defiende el SIEM (Security Information and Event Management) de sus clientes. En este caso del Sistema Azure de Microsoft.

 Los clientes de Microsoft que utilizan Azure, necesitan que Microsoft les garantice que sus conexiones al servicio Azure en la nube (Cloud) estén libres de “problemas”. Estas conexiones (cada terminal, móvil, impresora, pantalla, sistema de pago, peaje, etc.) serían los llamados “end points” o puntos de conexión con los servidores de Azure (el Cloud). Microsoft utiliza el Falcon Cloud Security de Crowdstrike para proteger estos end-points. Si la actualización colapsa, Azure no lo reconoce, y colapsa a su vez mostrando la famosa pantalla azul, que es la que ven los end-points conectados. Como consecuencia se colapsa el servicio al cliente final y se produce una rotura de “business continuity”.

 Tanto Microsoft como CrowdStrike tienen ahora mismo decenas de millones de motivos para que esto se solucione. Sin embargo, la pregunta va más allá. ¿Qué pueden hacer los clientes finales?

 Es un caso de manual del denominado Riesgo Proveedor (“Third Party Risk”). En esta incidencia, los clientes han sido meros pasajeros en un autobús conducido por otros, que sin embargo les ha convertido en los mayores perdedores en el corto plazo (clientes, reclamaciones, imagen, etc.). Se queda una clara sensación de vulnerabilidad. ¿Acaso deben conformarse con seguir siendo pasajeros sin control sobre dónde les lleva el autobús?

 Manual de buenas prácticas: Third Party Risk Assessment. Cada vez se está implantando más. Consiste en que el cliente exija a sus proveedores, por contrato, la posibilidad de que un tercero especializado les realice en nombre del cliente auditorías prácticas. Es decir, que puedan testar aquellos elementos, dentro del perímetro del cliente, que proporciona el proveedor, en un entorno real de “risk assessment”. En otras palabras, hackear (o intentar hackear) el sistema para encontrar qué puede fallar que pueda permitir que de forma voluntaria o involuntaria se interrumpa el servicio del cliente por culpa del proveedor. No hay muchos a nivel mundial que puedan realizar este papel con la capacidad, solvencia e imparcialidad que estos temas tan delicados requieren. La buena noticia es que aunque pocos, los hay y les conocemos.