¿Cómo evitar el próximo ‘Viernes Azul’?

El 19 de julio tuvo lugar el “Viernes Azul”, cuando 8,5 millones de pantallas de PC de todo el mundo se vieron afectadas por la infame Pantalla Azul (BSOD): un mensaje de error crítico que muestra Microsoft Windows cuando el sistema se encuentra con un problema grave del que no puede recuperarse.

Esta interrupción sin precedentes fue provocada por una actualización defectuosa de CrowdStrike, un proveedor líder de ciberseguridad. La interrupción afectó a servicios gubernamentales, operaciones de emergencia, el transporte, los sistemas de pago y los mercados financieros de todo el mundo.

Aunque no se trató de un ciberataque, su escala fue histórica y suscitó dos grandes preocupaciones. En primer lugar, el fallo tuvo su origen en una actualización de CrowdStrike destinada a proteger las redes. Segundo, solucionar el problema requería una intervención manual: reiniciar cada ordenador en el modo seguro de Windows y aplicar un parche, un proceso que lleva mucho tiempo cuando se trata de millones de dispositivos.

Desde entonces, algunos han argumentado que es necesaria una nueva regulación para garantizar que no vuelva a producirse. En la UE, esto no es necesario. Ya tenemos dos sólidas piezas legislativas, la Directiva sobre Redes y Sistemas de Información 2 (NIS2) y la Ley de Ciberresiliencia (CRA). Sólo hace falta aplicarlas adecuadamente, combinadas con una mejor preparación y un esfuerzo para ampliar el número de proveedores de software de seguridad.

¿Cómo ocurrió todo?

CrowdStrike es una conocida empresa de ciberseguridad que presta servicio a más de la mitad de las 500 empresas de Fortune. Tienen un historial en la investigación de incidentes como el pirateo de Sony Pictures en 2014 y la filtración de los correos electrónicos de Hillary Clinton en 2016.

Una actualización de software como la que causó el Viernes Azul puede acceder a Windows de dos modos: a través de un “espacio de usuario” restringido, donde las aplicaciones se ejecutan con acceso limitado a todos los recursos del hardware/sistema, o a través de un “kernel”, donde el acceso no está restringido. En el primero, un incidente sólo provoca el cierre de la aplicación individual, mientras que en el modo kernel, el fallo del software provoca la caída de todo el sistema.

CrowdStrike actualiza su software de seguridad de forma automática y silenciosa a nivel del núcleo, ya que así todas las actualizaciones pueden producirse lo más rápidamente posible. Pero, según algunos, CrowdStrike no es la única empresa de seguridad que provoca caídas de Windows. Lo que hizo histórico el incidente de julio fue su gran escala.

Implicaciones para la industria

El incidente de CrowdStrike pone de relieve la fragilidad de la infraestructura central de Internet y señala dos problemas críticos específicos: nuestra excesiva dependencia de un pequeño grupo de proveedores únicos y los riesgos asociados a las actualizaciones automáticas de software.

A diferencia de las industrias en las que los consumidores disfrutan de variedad, la industria del software converge hacia el monopolio: la mayoría de los usuarios particulares y empresariales, gracias a los fuertes efectos de red, prefieren utilizar los mismos sistemas operativos, como Microsoft Windows. Las ventajas de esto incluyen una gestión más sencilla, redes de soporte más amplias y productos más compatibles.

Sin embargo, esta “monocultura del software” puede provocar trastornos en cascada cuando algo va mal. En pocas palabras, cuantos más sistemas dependan del mismo software y de las mismas soluciones de ciberseguridad, mayor será el impacto potencial de cualquier fallo grave.

En 2009, Microsoft, tras consultar con los reguladores de la UE, accedió voluntariamente a abrir su sistema operativo Windows Vista mediante la creación de interfaces de programación de aplicaciones (API) a nivel del núcleo, permitiendo así a los proveedores de seguridad de terceros acceder a partes de sus sistemas operativos para ofrecer productos y servicios de seguridad. En consecuencia, esto generó un vasto mercado para la seguridad de terminales valorado hoy en unos 15.000 millones de dólares, con varias grandes empresas competidoras, entre ellas CrowdStrike.

Concretamente, CrowdStrike proporciona a Microsoft el sistema Falcon, que repele los ataques contra Microsoft Windows. La actualización del kernel de Falcon provocó el incidente del 19 de julio, subrayando los riesgos de concentrar los servicios críticos en manos de unas pocas empresas de ciberseguridad.

El accidente también puso de manifiesto cómo muchas organizaciones no estaban en absoluto preparadas para hacer frente a interrupciones de servicio a gran escala. La programación defensiva, los planes de contingencia y disponer de sistemas de copia de seguridad son todos fundamentales.

Como la actualización defectuosa de CrowdStrike se hizo automáticamente, los usuarios del software pueden exigir ahora que se cambie este modelo operativo. Pero este asunto es más complejo y lleva a la cuestión más general de cómo equilibrar adecuadamente la interoperabilidad y la ciberseguridad.

Algunos expertos afirman que imponer la interoperabilidad de los sistemas operativos con los productos de los proveedores de seguridad, aunque ha aumentado la competencia entre un grupo relativamente pequeño de proveedores, ha repercutido negativamente en la seguridad. Por lo tanto, la forma en que se diseñan las API se convierte en una consideración crítica. Los gobiernos y las empresas deben replantearse su dependencia de unos pocos proveedores y considerar la posibilidad de diversificar sus soluciones de software para evitar incidentes similares.

No necesitamos nuevas normativas de la UE

El Viernes Azul también ha estimulado el debate entre los responsables políticos sobre la mejor manera de responder. La administración estadounidense está considerando nuevas medidas sobre la resiliencia del software de ciberseguridad.

Pero aquí en la UE no necesitamos ninguna normativa nueva: ya contamos con dos poderosas piezas legislativas que, si se aplican correctamente, podrían ayudar a prevenir y mitigar cualquier futura interrupción sistémica, a saber, la NIS2 y la CRA.

La NIS2 prevé un marco de gestión de crisis y una serie de medidas de gestión de riesgos de ciberseguridad, mientras que la CRA, centrada en los productos con elementos digitales, contiene una serie de requisitos para que el software sea más resiliente.

En lo que respecta a las actualizaciones de software, la CRA exige actualizaciones automáticas para los productos que no presentan riesgos específicos de ciberseguridad, pero no para el software de los productos críticos, es decir, los productos que sí presentan riesgos específicos de ciberseguridad. En la fase de aplicación de la legislación, debería especificarse que las empresas que utilicen productos críticos tengan la opción por defecto de decidir por sí mismas si una actualización es automática o no (un opt-in en lugar de un opt-out). Esto daría a las empresas más control sobre su software y sus sistemas cuando utilicen productos críticos.

¿Aprenderemos del Viernes Azul?

La interrupción de CrowdStrike no fue un ciberataque. Pero sí reveló nuestra dependencia de ciertos softwares y de un pequeño número de empresas cuyo trabajo es proteger dicho software.

Para prevenir y mitigar cualquier interrupción futura, necesitamos aumentar el número de proveedores y animar a las empresas y organizaciones a prepararse mejor para manejar y responder a interrupciones sistémicas. Pueden hacerlo utilizando mecanismos de recuperación, programación defensiva o planes de contingencia.

Y, de nuevo, lo más importante es que no necesitamos en absoluto ninguna nueva legislación en la UE: en su lugar, la aplicación rápida y eficaz de la NIS2 y la CRA debería bastar para ayudar a mitigar las consecuencias de cualquier interrupción futura.

Artículo traducido del inglés de la web de CEPS.