Desastres naturales

La seguridad de la información se ocupa de tres cosas: que los datos no los vea quien no debe, que no los cambie quien no debe y que estén ahí cuando hacen falta. Los desastres naturales atacan la tercera, la disponibilidad, y por eso están en un glosario de ciberseguridad y no solo en un manual de instalaciones.

La diferencia con el resto del glosario es que aquí no hay adversario. Un terremoto, una inundación, un incendio forestal o un temporal no eligen objetivo, no cambian de táctica cuando te defiendes y no aprenden. Eso los hace más fáciles de modelar y, precisamente por eso, más imperdonables cuando pillan a una organización sin nada preparado.

También cambia el tipo de defensa. Contra un atacante se detecta y se responde; contra un desastre natural se anticipa y se reconstruye. No hay nada que detectar, porque el aviso lo da la meteorología o el suelo, no un registro de seguridad.

Y hay una coincidencia que conviene tener presente: la preparación que sirve para un desastre natural es casi la misma que sirve para un ransomware. Las dos se contestan con copias que el incidente no puede alcanzar y con un plan de vuelta al servicio que alguien ha probado.

La infraestructura física. Los centros de datos, los armarios de comunicaciones y los cuadros eléctricos están en un sitio concreto, y ese sitio puede quedar bajo el agua, sin corriente o sin acceso. Lo que se pierde no es solo el equipo: es el tiempo que tardas en tener otro funcionando.

La conectividad. Un servicio puede seguir vivo en cloud y ser inalcanzable porque la fibra que llega a la oficina se ha cortado o porque la red móvil de la zona está saturada. La continuidad no depende solo de dónde estén tus servidores, también de por dónde se llega a ellos.

La seguridad física. Una evacuación deja edificios vacíos, puertas abiertas y equipos sin vigilancia, y una emergencia es exactamente el momento en el que nadie está mirando quién entra. Los portátiles y los soportes de copia que se sacan a mano en una urgencia son de las cosas que más fácilmente acaban descontroladas.

Las personas. Un desastre afecta primero a quien tiene que responder. El plan que depende de una sola persona que sabe cómo se restaura algo es un plan que falla justo el día en que esa persona está atendiendo lo suyo.

Y el criterio. Bajo presión se toman atajos: se abre un acceso temporal, se comparte una contraseña, se levanta un servicio sin las restricciones de siempre. Esos atajos suelen sobrevivir al desastre, y ahí es donde un suceso sin adversario acaba abriendo la puerta a uno con adversario.

Primero, saber qué tienes y qué aguanta cuánto. Sin un inventario de activos no se puede priorizar nada, porque no se sabe qué sistema sostiene qué proceso de negocio. Es el paso que casi todo el mundo se salta y el que hace inútil el resto.

Segundo, las copias. Fuera del alcance del suceso, o sea en otra ubicación geográfica, y con al menos una que no se pueda borrar desde el mismo sitio desde el que se administra el original. Ver copia de seguridad y copia inmutable.

Tercero, los dos números que ordenan todo lo demás: cuánto tiempo puedes estar caído y cuántos datos puedes permitirte perder. En cuanto esos dos números existen y están acordados con negocio, las decisiones técnicas dejan de ser una discusión de gustos.

Cuarto, la prueba. Una restauración que nadie ha ejecutado no es una copia, es una intención. Restaurar de verdad, cronometrando, sobre un entorno separado y con la persona que estaría de guardia, no con la que diseñó el sistema.

Y quinto, escribir quién decide. La mayor parte del tiempo perdido en una crisis no se va en restaurar: se va en averiguar quién tiene autoridad para declarar la contingencia y para decidir qué se sacrifica primero.

El caso es hipotético y sirve para ver el orden de las decisiones, no para describir ningún incidente real.

Una empresa tiene su centro de datos principal en una región expuesta a temporales fuertes. El aviso llega con horas de margen.

Con la preparación hecha, esas horas se usan para lo que valen: comprobar que la última copia está completa y accesible desde fuera de la zona, confirmar que el entorno alternativo arranca, avisar a los clientes de qué servicios pueden degradarse, y mandar a la gente a casa antes de que sea peligroso moverse.

Sin la preparación hecha, esas mismas horas se van en descubrir que la copia de un sistema llevaba semanas fallando en silencio, que nadie sabe las credenciales del entorno alternativo y que la única persona que ha restaurado eso alguna vez está de vacaciones.

La diferencia entre los dos párrafos anteriores no se decide durante el temporal. Se decidió meses antes, el día que alguien probó la restauración o el día que decidió que no hacía falta.

Guardar la copia en el mismo sitio que el original. Es el error clásico y sigue apareciendo. Una copia en la misma sala que el servidor protege contra un borrado, no contra una inundación.

Dar por hecho que el cloud ya lo resuelve. Un proveedor replica dentro de su ámbito y bajo su modelo de responsabilidad compartida, no bajo el tuyo. Si tus recursos están todos en una misma región, tienes el mismo problema con la factura de otro.

Confundir alta disponibilidad con recuperación. Duplicar servidores dentro del mismo edificio cubre que se rompa uno, no que desaparezca el edificio. Son dos gastos distintos que resuelven dos problemas distintos.

Probar solo la copia y no el proceso entero. Que el fichero se restaure no significa que el servicio vuelva: faltan el DNS, los certificados, las integraciones y las credenciales de los sistemas de al lado.

No tocar el plan en dos años. Un plan de continuidad envejece a la velocidad a la que cambia la infraestructura, o sea muy rápido. Un plan que nombra servidores que ya no existen es peor que no tener plan, porque da confianza.

Los esquemas de cumplimiento piden continuidad, y la piden probada y no declarada. Una certificación ISO 27001 se sostiene sobre evidencias de que la organización ha ensayado la vuelta al servicio, no sobre un documento con el plan escrito.

En el ámbito público la exigencia va por la misma línea: el Esquema Nacional de Seguridad gradúa las medidas de continuidad y de respaldo según el nivel de la información y del servicio, así que la pregunta del auditor no es si tienes copias, sino si tienes las que te corresponden y si has demostrado que funcionan.

Lo que suele suspender no es la falta de plan. Es la falta de la prueba: fecha de la última restauración, tiempo que tardó, qué falló durante el ensayo y qué se corrigió después. Ese registro es el activo, y se genera ensayando.

Y lo que un ejercicio de seguridad ofensiva aporta a esto es la otra mitad de la pregunta: si tu plan de recuperación se apoya en una consola de administración o en un repositorio de copias, alguien tiene que comprobar que un atacante que entra por la red no llega antes que tú a esa consola. Eso es lo que mide un pentesting interno.

¿Un desastre natural es un incidente de seguridad? Sí, si afecta a la disponibilidad, a la integridad o a la confidencialidad de la información. Se gestiona con el mismo procedimiento de respuesta a incidentes, aunque no haya nadie a quien atribuirlo.

¿Cada cuánto hay que probar la recuperación? Con la frecuencia que haga falta para que el resultado siga siendo cierto: al menos una vez al año, y siempre después de un cambio grande de infraestructura. El calendario importa menos que el hecho de que alguien lo ejecute de verdad.

¿Sirve de algo tener copias si no se han restaurado nunca? Sirve de menos de lo que parece. Una copia que nadie ha restaurado tiene un valor desconocido, y el momento de averiguarlo no es el día del desastre.

¿Esto lo hace Asperis? Asperis no presta servicios de continuidad de negocio ni de recuperación ante desastres. Sí revisamos, dentro de un proyecto de ISO 27001 o de ENS, que los controles de respaldo y continuidad que exige la norma existan y estén probados.