Ya han pasado varias semanas desde que George Kurtz, fundador y CEO de CrowdStrike, recibiera una llamada a las tres de la mañana con un lacónico mensaje: «Tenemos un problema». Todavía hoy, organizaciones de todo el mundo siguen recuperándose de un fallo causado por una actualización de software que dejó a más de 8 millones de ordenadores fuera de servicio, aproximadamente un 1% de la base instalada de Windows. Aunque, visto así, como porcentaje, no parezca gran cosa, su efecto ha sido demoledor. Aún se respira una extraña sensación de fragilidad, tanto por lo inesperado como por lo incomprensible de este suceso. ¿Cómo es posible que un simple error haya hecho que sectores enteros de la economía se tambaleen?
Podemos buscar culpables para quedarnos más tranquilos, pero ¿realmente habremos solucionado el problema evitando que mañana pueda volver a producirse? Asignar responsabilidades es parte de la solución, pero primero hay que entender las decisiones de compromiso que enmascara este incidente. Entonces, podremos repartir culpas y desarrollar mecanismos que nos permitan evitar que se repita o, al menos, amortiguar su impacto.
Esto nos lleva a la necesidad de identificar cuáles son esas decisiones de compromiso:
- Velocidad frente a calidad. Cuando la velocidad y la calidad entran en conflicto, hay que decidir qué riesgo se quiere asumir. Por un lado, la velocidad en ciberseguridad es fundamental para proteger a las empresas frente a nuevas amenazas que, una vez descubiertas, son rápidamente aprovechadas por los atacantes. Cuanto menor sea la ventana de tiempo en la que pueden actuar, mejor. Por otro lado, cuando se corre mucho para reducir el tiempo de exposición a una brecha, se cometen errores. Por ejemplo, la calidad del software se resiente al reducir las pruebas previas a su implementación. En teoría, la decisión entre agilidad y calidad plantea un falso dilema al existir metodologías capaces de combinar ambas (ej. DevSecOps). Sin embargo, la realidad nos muestra que en la práctica a veces hay que elegir.
- Vanguardia tecnológica frente a estabilidad. La industria de la ciberseguridad es muy joven y todavía está atravesando una etapa marcada por una fuerte innovación, lo que ha llevado a una proliferación de proveedores especializados. Como consecuencia, las herramientas se han multiplicado creando un entorno tecnológico cada vez más complejo. Buscando una simplificación, los proveedores de mayor tamaño han comenzado a proporcionar plataformas que consolidan distintas herramientas. Ahora, las empresas pueden elegir entre la innovación tecnológica de un especialista (ej. CrowdStrike) o tener un único proveedor que, aunque pueda no disponer de la mejor herramienta, ofrezca una solución completa e integrada (ej. Microsoft).
- Eficiencia frente a resiliencia. Nos dirigimos a un mundo lleno de automatismos, donde la inteligencia artificial impulsa la automatización hacia nuevos espacios. Con ello, nos volvemos más rápidos y eficientes. Pero, ¿qué sucede cuando lo digital falla? La resiliencia de las organizaciones, en última instancia, sigue dependiendo de lo manual, de tener un plan B. Sin embargo, el incidente de CrowdStrike ha revelado que las empresas no tenían una redundancia física de sus procesos digitales. Tampoco contaban con recursos para un escenario donde todos sus equipos tuvieran que reiniciarse manualmente, uno a uno, lo que ha demorado la resolución del problema varias semanas.
- Competencia frente a control. Permitir el acceso al núcleo (kernel) de un sistema operativo para fomentar la competencia conlleva una pérdida de control que no está exenta de riesgos. Microsoft ofrece a distintos proveedores de seguridad acceso sin restricciones a sus sistema operativo en virtud de un acuerdo de 2009 con el regulador europeo. Sin este nivel de acceso, el impacto de errores de terceros se minimiza. Sin embargo, el precio de dar un control estricto a Microsoft es ofrecer una ventaja competitiva a su propia solución de seguridad. Definitivamente va a ser necesario encontrar una forma de conciliar control y competencia cuando se trate de accesos al kernel de un sistema operativo.
Mirando al futuro, lo sucedido el pasado 19 de julio debe servir para que proveedores, empresas y reguladores entiendan mejor la naturaleza de los riesgos tecnológicos actuales. Los proveedores tecnológicos tienen deberes. En un plano técnico, tendrán que ofrecer garantías sobre la calidad de su software, especialmente cuando pasen de ser startups a proveedores consolidados con una presencia significativa en sectores críticos de la economía. Además de llevar a cabo pruebas frecuentes, también tienen que pensar en mecanismos que minimicen el impacto de sus errores. Por ejemplo, haciendo despliegues escalonados para detectar problemas antes de que escalen y se desencadene un efecto en cascada. Por su parte, las empresas también tienen que asumir parte de la responsabilidad e invertir en redundancias. Además, deben tener un plan B con procesos manuales cuando lo digital deje de funcionar. Esto es especialmente relevante cuando existe un alto riesgo de “contagio” en sectores con empresas fuertemente interconectadas. Por ejemplo, basta que un aeropuerto se vea gravemente afectado para que el problema se extienda a los demás. Tienen que existir mecanismos que permitan aislar las empresas afectadas del resto. Por último, hay que dejar que el regulador establezca las reglas del juego, pero que lo haga con un ojo puesto en los riesgos tecnológicos sistémicos.
La próxima vez, con la lección aprendida, seguro que lo haremos mejor.
