Al hilo de posts anteriores sobre continuidad de negocio (tipos de proyectos, pruebas, aspectos a tener en cuenta, tiempos, UNE 71599/BS 25999, …), hoy vamos a centrarnos en la realización de las pruebas, pero no de planes de prueba de esos que se revisan simbólicamente una vez al año para cumplir con requisitos de auditoría. Hablaremos de porqué hace falta hacer pruebas de verdad.
Y es que si algo tiene que fallar algún día, está claro que fallará durante una presentación en directo, durante una importante migración o, como no, durante una contingencia.
Empecemos por la parte organizativa:
Uno de los grandes errores de los planes de continuidad es tener únicamente una serie de documentos técnicos para restaurar HW/SW. Evidentemente esto no podemos considerarlo como un plan de continuidad TIC (véase este post sobre los tipos de los proyectos: https://www.securityartwork.es/2013/04/04/continuidad-de-negocio-tipos-de-proyectos/) ya que se habrá quedado fuera toda la parte organizativa, pero es una situación que encontramos bastante frecuentemente. Esto suele ocurrir cuando no se aborda la tarea como un proyecto en condiciones, sino que se le encarga al departamento de TI “Hacer un plan de esos por si esto explota. Y rapidito que tenéis más cosas que hacer”.
Pues bien, dependiendo de la naturaleza del negocio, la parte organizativa seguramente será mucho más importante que la parte técnica, ya que de nada sirve documentar como restaurar equipos si no hay un local donde hacerlo, si no hay personal de respaldo, o nadie que pueda tomar decisiones relevantes. Por culpa de este tipo de documentos puede pasar que ante una contingencia se dediquen recursos a recuperar antes la aplicación de gestionar las vacaciones del personal que la centralita de atención al usuario u otras situaciones similares.
Al respecto, además de crear la política y establecer prioridades, se tienen que crear los planes clásicos de continuidad organizativa como pueden ser reubicación de personal, sustitución de personal, contacto con proveedores y clientes, etc., los cuales deben ir acompañados de un Plan de Pruebas. Puede parecer que estos planes al no tener componente tecnológica no pueden fallar, pero fallan, y lo peor, hacen que otros planes no puedan ejecutarse. Puede parecer que un plan de reubicación de personal no puede fallar ya que solo hace falta tener, por ejemplo, comunicación con el CPD de respaldo, pero en el momento de la contingencia podemos darnos cuenta de que necesitábamos una impresora con la que no habíamos contado, que las comunicaciones no son suficientes, que el local no tiene mesas, que sin la libreta del 2º cajón del administrador de sistemas no se puede acceder a X servidor, o que nadie recuerda la IP a la que conectar para hacer una tarea ya que todo el mundo la tenía en favoritos y sus equipos están en la ubicación a la que no se puede acceder.
Por otro lado, además de probar los planes con el fin de buscar errores o detalles que hayamos dejado fuera, las pruebas de la parte organizativa sirven como entrenamiento por si llega el día en que hay que utilizarlos. Para un técnico restaurar un sistema puede ser algo relativamente rutinario, pero seguramente la responsabilidad de activar la contingencia y de empezar a lanzar planes recaerá en alguien que no se dedica a hacer esto frecuentemente. El cómo se actúe durante la primera hora será decisivo para el buen funcionamiento del plan ya que una mala decisión puede retrasar todo el restaurado, por lo que es imprescindible que quien tenga que tomar las decisiones tenga cierta soltura y que conozca perfectamente el plan, y esto solo se consigue practicándolo.
¿Y qué ocurre con la parte técnica?
Si en la parte organizativa lo más importante es probarlo todo para familiarizarse con el entorno y ver que no se han dejado cabos sueltos, en la parte técnica nuestro peor enemigo es el “pues esto tendría que funcionar, peeeero…. Por desgracia hoy en día tenemos un montón de tecnologías que nos deberían facilitar la vida ante una contingencia como pueden ser SAIs monstruosos, cabinas de discos inmensas, virtualización por todas partes, sistemas de alta disponibilidad, grupos electrógenos, etc. los cuales nos dan una (falsa) sensación de tranquilidad que puede hacer cundir el pánico si no todo es tan maravilloso como nos han prometido.
Todo es superseguro pero, ¿cuántos se atreven a cortar la luz del CPD sin avisar a nadie confiando en que los SAIs harán su trabajo y que los aires aguantarán? ¿Tirarías del cable de red del cortafuegos principal confiando en que el secundario balanceará perfecto? ¿Borrarías un servidor crítico tranquilamente sabiendo que según el fabricante del robot de copias en 20 minutos lo tienes restaurado? Si alguien contesta a todo que sí o es un valiente o lo tiene todo muy atado (lo cual efectivamente puede suceder).
En la práctica es relativamente frecuente encontrar copias de seguridad corruptas, lentitud en los restaurados o comunicaciones, backups de configuraciones de electrónica de red desactualizados o scripts de restaurado que ya no funcionan con el último cambio que se hizo, y la única forma de detectar estas situaciones es, una vez más, probar que todo funciona.
Resulta además muy recomendable (por no decir necesario) hacer las pruebas técnicas junto con la parte organizativa ya que, por ejemplo, ni se trabaja igual ni se dispone de los mismos recursos en la oficina y en la ubicación alternativa. Detalles como no tener una copia de los certificados de la VPN o del fichero de contraseñas disponible desde una ubicación alternativa, haber olvidado abrir algún puerto en el cortafuegos, o tener las instrucciones técnicas de cómo restaurar una copia dentro de la propia copia, son situaciones que se pueden solventar muy fácilmente, pero que se tienen que detectar antes… ¡PROBÁNDOLO!
¿Y si montamos un teatrillo?
A alguno le parecerá que esto es cosa de modernos, pero una buena forma de hacer las pruebas de la forma más realista posible es hacerlas sin avisar a nadie y añadir dramatismo teatrero como si algo realmente hubiese pasado (aunque todos sepan que no es así): en lugar de convocar una reunión para ver cómo se planifica la puesta en marcha de los planes, se puede montar un pequeño circo en la oficina un día que nadie lo espere y llegar a escenificar que ha sucedido alguna catástrofe y que el negocio no puede operar normalmente. También se puede activar el plan antes de la hora de entrar a la oficina llamando por teléfono a los implicados en las pruebas para que acudan directamente al centro de respaldo, de modo que a nadie le dará tiempo de “hacer trampas” y llevarse la documentación que necesita en un USB, o enviarse al correo la última versión del fichero de claves que ha olvidado actualizar en el repositorio de backup.
Para los más imaginativos se puede incluso montar un pequeño juego de rol, donde un “master” va lanzando cataclismos naturales sobre el CPD, o hace que los técnicos enfermen misteriosamente a medida que los pobres contingente recuperan servicios, pero eso lo contaremos en otra ocasión.
Esperamos que haya quedado claro que si realmente queremos que un plan de pruebas tenga sentido y queremos ver como funcionaríamos ante una contingencia real, no nos vale con restaurar un servidor de forma muestral, o firmar un contrato con un proveedor que nos garantiza el suministro: hay simular que el negocio no puede operar y no quedarse en pruebas de concepto o soluciones a medias.
Hace poco tuvimos una conversación mañanera frente a la máquina de café sobre las bondades y maldades de conseguir permisos de administrador (en adelante “rootear”) en dispositivos android, y en la cual la verdad es que no llegamos al consenso.
Como muchos sabréis, el acuerdo de “puerto seguro”, o safe harbour, es un acuerdo al que se adhieren las organizaciones estadounidenses para poder ser receptoras de transferencias internacionales de datos de carácter personal procedentes de la Unión Europea. 
Yatedo se dedica básicamente a navegar por 