Interrupción del servicio de Microsoft 365: cómo mantener las operaciones en marcha cuando fallan los sistemas circundantes

En BlackBerry, hay un principio que prima por encima de todos los demás. Los gobiernos y los operadores de infraestructuras críticas necesitan que sus operaciones sigan funcionando ante ataques, cortes de suministro y crisis, sin ceder el control a nadie más. 

La interrupción del servicio de Microsoft 365 que comenzó el 12 de noviembre fue otro ejemplo de por qué. La interrupción no solo afectó a los sistemas empresariales, sino que también dejó fuera de servicio los sistemas de comunicación y coordinación de emergencias . Microsoft afirma que no tiene pruebas de actividad maliciosa. Dicho esto, la causa importa menos que el patrón: cuando la comunicación y la coordinación se concentran en un único lugar, fallan juntas, a menudo justo en el momento en que más se necesitan. 

La lección es sencilla: no debes depender de un único proveedor para todas tus comunicaciones. La continuidad de la misión depende de que exista un canal independiente que siga funcionando cuando la plataforma principal deje de funcionar, de modo que los responsables puedan seguir comunicándose con su personal y dirigir la respuesta en caso de que la plataforma principal falle. 

Plan para el modo de funcionamiento limitado 

Muchos planes de continuidad se centran en la rapidez con la que se restablece el servicio. Los planes de continuidad de la misión también deben garantizar el funcionamiento de las operaciones mientras los sistemas están inactivos, cuando se deniega el acceso a la red, esta está desconectada, funciona de forma intermitente o tiene limitaciones, sea cual sea la causa. Una interrupción del servicio por parte del proveedor principal provoca esa situación dentro de la organización sin que intervenga ningún adversario. La pregunta es la misma en todos los escenarios: cuando la plataforma en la que trabajas deja de funcionar, ¿qué sigue funcionando? 

Los planes fracasan cuando el sistema de respaldo se encuentra en la misma plataforma que el principal. Si las llamadas de emergencia, las alertas al personal, la lista de contactos y los códigos de acceso pasan todos por un mismo proveedor, elplan de respaldo falla junto con el principal.

Para subsanar esa deficiencia se necesita algo más que una segunda plataforma. Una vía alternativa que permita continuar con la misión debe cumplir una serie de requisitos, y cada uno de ellos debe mantenerse mientras la plataforma principal esté fuera de servicio. 

Qué debe incluir un plan de continuidad de la misión 

• Los responsables necesitan una identidad verificada en la ruta de contingencia. Cuando las herramientas oficiales dejan de funcionar, el personal recurre al correo electrónico personal y a aplicaciones de consumo, que no cuentan con controles de identidad ni registros.  

• Las comunicaciones de voz y mensajería seguras deben ejecutarse en los propios servidores de la organización o en una nube nacional. El sistema también debe proteger la información sobre quién ha hablado con quién, ya que ese patrón constituye información que un adversario podría utilizar.

• La copia de seguridad no puede compartir datos de inicio de sesión, herramientas de administración ni dispositivos con el sistema principal. Si lo hace, una interrupción del servicio afectará a ambos, lo que incluye las alertas que se envían por correo electrónico o a través de herramientas de colaboración. 

• Las alertas deben llegar a todos los canales y dispositivos, y debe indicarse quién las ha recibido. El centro de mando debe saber quién se encuentra a salvo y coordinar la respuesta en función de esa información. 

• Las declaraciones de seguridad deben ir acompañadas de pruebas emitidas por organismos independientes, como la certificación NIAP según los Criterios Comunes, la inclusión en la Lista de Componentes CSfC de la NSA y la autorización FedRAMP para servicios en la nube. Los usuarios fuera de EE. UU. deben solicitar las certificaciones que sean aplicables en su propia jurisdicción. 

• La coordinación requiere más de una ruta. Las llamadas y los mensajes, que se adaptan a distintos operadores, redes Wi-Fi, PBX y redes internacionales, siguen llegando cuando una ruta se ve afectada, y el sistema de alertas local o aislado sigue funcionando dentro de su enclave cuando falla la conectividad externa. 

Nada de esto implica que las organizaciones deban abandonar la plataforma principal, que es sumamente fiable. La clave está en la separación. Una ruta de contingencia controlada por la organización, ya sea en las propias instalaciones, en una nube nacional o aislada físicamente, puede ser susceptible de sufrir fallos por motivos distintos a los de la plataforma principal, y esa diferencia es la que permite que la misión siga adelante. 

Por dónde empezar 

El siguiente paso es sencillo. Haz una lista de los flujos de trabajo críticos que dependen de la plataforma principal, incluidas las herramientas de inicio de sesión y de administración que los sustentan. A continuación, realiza un simulacro en el que se suponga que la plataforma principal ha dejado de funcionar durante 24 horas y anota cada paso que se vea interrumpido. 

Utiliza el ejercicio para responder a estas preguntas: 

• ¿Se ha probado tu plan para el modo de funcionamiento limitado o se parte de la base de que la plataforma principal está operativa? 

• ¿Cómo se avisa al personal? ¿Y se puede confirmar quién ha recibido el aviso? 

• ¿Tu copia de seguridad comparte datos de inicio de sesión, herramientas de administración o dispositivos con el sistema principal? 

• Cuando la red principal no funciona, ¿cómo se comunican de forma segura tus responsables? 

El requisito que justifica la financiación es muy específico. Las personas que dirigen operaciones críticas necesitan una vía que no falle junto con el sistema principal, de modo que la misión pueda continuar independientemente de lo que hagan los sistemas que la rodean. 

Empieza a planificar unas operaciones eficaces en modo degradado.