Rápidamente quedó claro que el problema no era un problema con el servicio Azure de Microsoft, como apareció por primera vez, sino un problema con un único proveedor de software, llamado CrowdStrike, que lanzó una actualización defectuosa de su software, que luego se distribuyó rápidamente por todo el mundo a través de las redes globales de Azure.
Como informó Computer Weekly, ese “parche defectuoso” estuvo disponible en línea durante 78 minutos, y en ese tiempo se distribuyó a 8,5 millones de máquinas Microsoft que quedaron bloqueadas en un ciclo de arranque y quedaron inutilizables.
Una vez que quedó claro que la fuente de los problemas no era un ciberataque organizado por parte de personas desconocidas, las cosas se pusieron en modo de resolución.
El impacto en las empresas afectadas y el público en general fue en algunos casos importante, pero, cuando se trata de interrupciones del hiperescalador, el mundo tiene poca memoria y las cosas rápidamente volvieron a la normalidad.
No hay otro apagón
Excepto que el 30 de julio de 2024, los servicios en la nube de Microsoft sufrieron otra interrupción, que afectó a las empresas a nivel mundial y, nuevamente, sin previo aviso.
Esta interrupción, sin embargo, no se parece en nada a la debacle de CrowdStrike en términos de causa, impacto o incluso implicaciones.
Lo que demuestra esta última interrupción es que tenemos un único problema: nuestro nivel de dependencia de los servicios en la nube, que podrían no ser tan confiables.
Pero primero debemos profundizar un poco más en por qué estas dos interrupciones no fueron iguales.
El personal de seguridad de TI intenta determinar y gestionar los riesgos para los datos y los sistemas de TI y, al hacerlo, tiende a considerar tres características clave: confidencialidad, integridad y disponibilidad.
Mantener estas características y mantenerlas dentro de rangos definidos y aceptables es de lo que se trata la ciberseguridad.
Es poco práctico en casi todos los casos mantener un equilibrio perfecto entre confidencialidad, integridad y disponibilidad. Y, en cualquier caso, diferentes organizaciones necesitan diferentes combinaciones de estas tres cosas para funcionar de manera óptima.
Es común que el personal de seguridad de TI se centre en la confidencialidad como la mayor preocupación y, de hecho, el Esquema de Clasificación de Seguridad del Gobierno del Reino Unido trata principalmente de asignar clasificaciones a la confidencialidad de los datos. Pero, en algunos casos, la confidencialidad es el factor menos importante, mientras que la integridad y la disponibilidad son de suma importancia.
Pensemos, por ejemplo, en los bomberos. Cuando se informa de un incendio, la ubicación del incendio debe ser lo más precisa posible y los bomberos en el terreno deben comunicarse con la mayor precisión posible para garantizar que obtengan los recursos necesarios para combatir el incendio.
En este ejemplo, la integridad y la disponibilidad son altas prioridades, pero mantener el incendio en secreto es poco probable que lo sea.
Lo que sí necesitamos, si queremos lograr la seguridad de TI, son esas tres cosas de alguna forma. Y cuando el equilibrio no es el adecuado, eso es un problema.
Interrupción versus incumplimiento
Los medios utilizan dos palabras diferentes para describir estos problemas, dependiendo de la característica que esté comprometida. La pérdida de confidencialidad suele denominarse violación, mientras que la pérdida de integridad o disponibilidad suele denominarse interrupción.
Estos describen los efectos visibles del compromiso, pero no siempre la causa del problema. Y es por eso que los dos informes de interrupciones de Microsoft en poco más de una semana deben tomarse por separado.
Pueden parecer iguales a los ojos del público y pueden ser mencionados de la misma manera en la prensa, pero son cosas diferentes y entenderlas es importante y necesario para aprender lecciones de cada una.
El incidente de Crowdstrike fue una pérdida de integridad de un único archivo en su software, lo que resultó en una pérdida de disponibilidad general del servicio.
El incidente del 30 de julio no parece ser el mismo en absoluto. Y aunque duró menos, solo un par de horas, después de las cuales la mayoría de los servicios volvieron a estar en línea prácticamente ilesos, en realidad podría ser de naturaleza mucho más grave.
La última ‘interrupción’ fue una pérdida general y generalizada de disponibilidad de los servicios de red de Microsoft para su servicio global Azure, supuestamente causada por un “pico de uso”, que podría ser un eufemismo de Microsoft para un ataque de denegación de servicio (DoS) por parte de Microsoft. un mal actor desconocido.
Un ataque DoS ocurre cuando un usuario (generalmente malicioso) consume todos los recursos de servicio disponibles y no deja nada para nadie más.
Mientras el atacante conserve esos recursos, el servicio no estará disponible para sus usuarios legítimos. Y durante ese tiempo, la empresa o el usuario afectado normalmente no podrá operar ni funcionar.
Los ataques de denegación de servicio son amenazas importantes que pueden provocar situaciones financieras y mortales graves, y se invierte mucho dinero y recursos en evitar que ocurran, algo en lo que, para ser justos, Microsoft suele ser bastante bueno.
Esta vez, sin embargo, parece que algo salió mal y podría deberse a un fallo de las contramedidas de seguridad para detener estos ataques.
O podría ser simplemente que los malos encontraron una manera de dedicar más recursos al ataque.
Tiempo lo es todo
El ataque no podría haber sido peor para Microsoft, ya que se produjo el día en que informan sus ganancias a los inversores.
Eso da más credibilidad a las sugerencias de que se trató de un ataque dirigido, no de un error accidental o una mala práctica administrativa.
Microsoft tuvo un mal día, pero sin duda lo dejará atrás lo suficientemente rápido y volverá a la normalidad. Lo más probable es que muchos de sus usuarios también lo hagan.
La cuestión, por supuesto, es que los sistemas de TI fallan, y fallan más de lo que a muchos de nosotros nos gustaría admitir. Para los socorristas de luz azul, tales fallas son literalmente una cuestión de vida o muerte del público, y se ha pensado mucho en la creación de sistemas de TI resilientes en todos los grupos y organizaciones en los que confiamos para nuestra seguridad.
Durante unos 20 años, ese fue mi trabajo diario: trabajé en la arquitectura, la construcción y la garantía de estos servicios para que, cuando todo a su alrededor se derrumbara durante un momento de crisis, siguieran funcionando.
Hasta hace un par de años, esto se manejaba a través de inversiones en sistemas nacionales y policía dedicada y otras redes de servicios 999 que operaban bajo condiciones comerciales especiales de un grupo específico de proveedores aprobados del Reino Unido con experiencia en el suministro de TI “que nunca falla”.
Además, las fuerzas y servicios individuales operaban bajo un mecanismo de ayuda mutua, mediante el cual cada fuerza policial, ambulancia o servicio de bomberos tenía relaciones con sus homólogos vecinos para garantizar que si sus propios sistemas fallaban, alguien más tomaría el relevo inmediatamente. y con poca o ninguna degradación del servicio.
Esto también funcionó en casos en los que el incidente local era tan grave que un socorrista local tenía que comprometer todos sus recursos para manejar ese incidente y necesitaba enviar llamadas de ayuda a otros lugares, e incluso había una serie de sistemas que gestionaban estas circunstancias. La Telefonía Nacional de Ayuda Mutua (NMAT) y la Oficina de Víctimas (CasWeb) son dos ejemplos.
Esos sistemas se diseñaron teniendo en cuenta las fallas y para garantizar que, cuando fallaran, alguien aún levantaría el teléfono y estaría en una posición viable para responder a la emergencia.
En este momento no estoy diciendo que nuestra capacidad nacional para hacer esto se haya degradado por completo –y los responsables de ello hoy seguramente argumentarán que no es así.
De lo que no podemos escapar es del hecho de que durante los últimos cinco años la policía (y los bomberos y las ambulancias, junto con otros sectores críticos) han estado trasladando servicios a las nubes de hiperescala de Amazon Web Services (AWS) y Microsoft con poca consideración evidente por la entrega. de capacidad de respuesta crítica si esos servicios fallan.
En lugar de considerar la posibilidad de que esos sistemas fallen, quienes toman las decisiones han optado por asumir que seguirán disponibles en todas las circunstancias, a pesar de que son productos básicos consumidos por el público en general y no tienen términos ni priorizaciones especiales.
Esto inevitablemente ha introducido riesgos en nuestra resiliencia nacional que nunca antes habíamos enfrentado.
El uso de la nube de Microsoft para alojar servicios críticos y de seguridad pública se debe principalmente a nuestra luz azul y a que los líderes de TI de infraestructura nacional crítica no leen la letra pequeña de los Términos de licencia universal de Microsoft para sus servicios en línea y su política de uso aceptable.
Estos identifican muy claramente que los servicios en línea de Microsoft, de los que forman parte Azure y M365, no están diseñados para un “uso de alto riesgo” y no deben utilizarse.
“Ni el cliente, ni aquellos que acceden a un servicio en línea a través del cliente, pueden utilizar un servicio en línea en cualquier aplicación o situación donde la falla del servicio en línea pueda provocar la muerte o lesiones corporales graves de cualquier persona, o daños físicos o ambientales graves. , excepto de acuerdo con la sección de uso de alto riesgo a continuación”, establece su término.
La sección de uso de alto riesgo mencionada continúa diciendo: “Los servicios en línea no están diseñados ni destinados a soportar ningún uso en el que una interrupción del servicio, defecto, error u otra falla de un servicio en línea pueda resultar en la muerte o lesiones graves. lesiones corporales de cualquier persona o en daños físicos o ambientales”.
Los altos dirigentes que optaron por utilizar estos servicios no cumplieron con su debida diligencia o optaron por aceptar riesgos que sus predecesores nunca aceptarían y que incluso podrían incumplir sus obligaciones conforme a la legislación.
Este trabajo fue sancionado al más alto nivel, siendo financiado en gran medida por el Ministerio del Interior y facilitado por sus programas y el Servicio Digital de la Policía, con el apoyo del Consejo de Jefes de Policía Nacional y el Comisionado de Policía y Crimen.
La adopción de nuevos servicios de nube pública trajo capacidades muy necesarias basadas en productos básicos para la racionalización y modernización del manejo de datos policiales.
Sin embargo, además de las cuestiones legales tratadas en profundidad por Computer Weekly, también podrían haber expuesto al Reino Unido a riesgos críticos para la seguridad pública que no se tuvieron debidamente en cuenta.
Microsoft no escapa por completo a la responsabilidad en este caso, incluso aunque su responsabilidad limite las cláusulas de la política de uso aceptable (AUP).
Dadas las relaciones directas de la empresa con el Servicio Digital de la Policía y las fuerzas clave, está claro que la empresa sabe que se está violando su AUP y es posible que haya desempeñado un papel en que los usuarios de la policía lo hicieran.
A menudo hablamos de huevos y cestas como eufemismo para exponernos a riesgos críticos para la seguridad, pero cada vez hay más pruebas de que en el Reino Unido es posible que ya lo hayamos hecho, o al menos que estemos a punto de hacerlo.
Dos fuerzas (la Policía Metropolitana y la Policía de Gales del Norte) han anunciado en los últimos años que planean trasladar sus servicios de sala de control a la nube pública de Azure, y he examinado si esto es prudente o no en el pasado.
Lo que está claro es que quienquiera que sea ahora responsable de iniciativas como estas dentro de nuestro nuevo gobierno (y, de hecho, de la adopción general más amplia de la nube pública por parte de los Servicios Nacionales Críticos del Reino Unido) debe tomar plena conciencia de los problemas que tuvieron los sistemas de Microsoft el 30 de julio de 2024.
En todos los aspectos clave, si los servicios básicos del Reino Unido no fueron afectados ayer, eso significa que se esquivó otra bala.
Esta vez, sin embargo, hay algunos indicios de que este podría haber sido activado por un actor malicioso y, de ser así, por primera vez, se debe considerar que el servicio en la nube “siempre activo” de Microsoft, previamente asumido, podría ser simplemente vulnerables a cortes de disponibilidad.
Como ha demostrado anteriormente ser más débil de lo que pensábamos en cuanto a compromisos de integridad y confidencialidad.
La bala esquivada esta vez bien puede haber venido de un atacante que acaba de encontrar una ametralladora DOS que puede disparar contra Azure cuando quiera.
Estoy seguro de que en los EE.UU. los altos dirigentes de Microsoft participarán en los comités del gobierno estadounidense en los próximos días para explicar las circunstancias de este incidente global.
Estoy igualmente seguro de que bajo la administración anterior el Reino Unido no habría hecho lo mismo.
Espero que este nuevo gobierno sea más sabio y se dé cuenta de que, al igual que el hacinamiento carcelario y los problemas de situación financiera que afirman haber descubierto al asumir el cargo, enfrentamos otra posible crisis en la nube pública para servicios críticos.
Microsoft debería ser llevado a un comité parlamentario u otro comité de supervisión pública del Reino Unido tan pronto como sea posible para explicar todas las cosas cubiertas en los EE.UU. al nuevo gobierno y al público del Reino Unido.
Esto no tiene por qué ser un ejercicio de derramamiento de sangre o de vergüenza pública; es una oportunidad de lecciones aprendidas, de la cual podemos elegir elegir un camino diferente para nuestros proveedores de servicios de CNI.
Si después el gobierno del Reino Unido no lo hace, entonces está bien porque será una decisión basada en riesgos y de la cual el nuevo gobierno habrá asumido la responsabilidad.
Hoy…