Todas las organizaciones que han fracasado alguna vez en un proceso de recuperación —y hay más de las que nadie reconoce públicamente— tenían una cosa en común: creían que podían recuperarse incluso antes de intentarlo.
Esa creencia provenía de algún sitio. Un ejercicio de simulación completado. Un sistema de copias de seguridad que mostraba un estado «verde». Una prueba anual de recuperación ante desastres que se superó. Todo ello documentado. Todo ello, en algún momento, correcto. Nada de ello actualizado cuando el incidente se produjo realmente. Esto es lo que se conoce como «brecha de confianza». Y es precisamente esa brecha la que la validación continua de la recuperación pretende cerrar.
Qué significa realmente «pruebas» en la mayoría de las organizaciones
Si le preguntas a la mayoría de los responsables de seguridad o de TI con qué frecuencia comprueban su capacidad de recuperación, la respuesta suele ser «una vez al año», a veces «dos veces al año». La prueba consiste en restaurar un subconjunto de sistemas a partir de una copia de seguridad en un entorno de pruebas, comprobar que se inician correctamente y elaborar un informe. A veces también se realiza un ejercicio de simulación junto con ello. Lo que este tipo de pruebas no hace es: validar que los datos de la copia de seguridad estén libres de malware; confirmar que la secuencia de recuperación funcione para servicios interdependientes; probar la recuperación de identidades, algo esencial cuando el ataque se ha producido a raíz de credenciales comprometidas; confirmar que el equipo encargado de llevar a cabo la recuperación conozca los manuales de procedimientos actuales. Ni aportar pruebas lo suficientemente significativas como para convencer a un regulador, un auditor o un consejo de administración de que la capacidad de recuperación es real y está al día. En resumen, valida un momento concreto. Las operaciones de resiliencia (ResOps) requieren que la validación sea un estado continuo.
El modelo de validación continua
La validación continua de la recuperación no consiste simplemente en realizar la misma prueba con mayor frecuencia. Se trata de un conjunto de prácticas integradas que proporcionan una demostración continua y basada en pruebas de la capacidad de recuperación de los servicios críticos. Análisis automatizado de la integridad de las copias de seguridad. Cada copia de seguridad se evalúa continuamente en busca de anomalías, patrones de cifrado y firmas de malware. No en el momento de la restauración, sino antes de la misma. El objetivo es saber si los puntos de recuperación están limpios antes de que se necesiten, no durante un incidente.
Recovery en «cleanroom» programada. Como mínimo dos veces al año, restaurando desde copias de seguridad inmutables a un «Cleanroom Recovery» aislado —ni en producción, ni en un entorno de pruebas adyacente a producción, sino en un espacio realmente aislado donde se pueda realizar un análisis forense sin riesgo de reinfección—. Estos simulacros proporcionan pruebas documentadas de la capacidad de recuperación frente a los niveles de impacto definidos.
Validación de la recuperación de la identidad. Dado que el uso indebido de credenciales es el vector de ataque más habitual, es necesario probar la recuperación de Active Directory y Entra ID junto con la recuperación de datos. Las organizaciones que restauren los sistemas sin restaurar primero una capa de identidad que se haya comprobado que está limpia pueden encontrarse con que los atacantes vuelvan a entrar por la misma puerta.
Cuadros de mando del Indicador de Resiliencia del Servicio (SRI). Los SRI —señales continuas extraídas de las copias de seguridad, los mapas de dependencias y los resultados de las pruebas— ofrecen a los CISO, los CIO y los consejos de administración una visión en tiempo real del estado de la capacidad de recuperación. No se trata de un informe puntual, sino de una señal operativa continua.
Cada una de estas prácticas contribuye a lo que Deloitte y Commvault denominan «resilience backlog»: una lista priorizada y actualizada constantemente de las deficiencias identificadas mediante pruebas y cuyo seguimiento se lleva a cabo hasta su resolución. Es el mecanismo por el que la validación impulsa la mejora, en lugar de limitarse a generar informes.
¿Qué significa el «tiempo medio hasta la recuperación de la limpieza»?
Las métricas de recuperación tradicionales —el objetivo de tiempo de recuperación (RTO) y el objetivo de punto de recuperación (RPO)— miden la velocidad y la actualidad de los datos. No dicen nada sobre si se puede confiar en los datos que se están restaurando. El tiempo medio de recuperación limpia (MTCR) cubre esa laguna: mide el tiempo necesario para restaurar datos que sean verificablemente limpios, no solo técnicamente disponibles.
El MTCR es importante porque, en un incidente de ransomware, el objetivo del atacante suele ser corromper las opciones de recuperación, no solo cifrar los sistemas de producción. Una organización que se recupera rápidamente, pero lo hace a partir de una copia de seguridad comprometida, en realidad no ha recuperado nada. Se ha vuelto a infectar.
Incorporar el MTCR a tu marco de medición de la resiliencia, junto con el RTO y el RPO, cambia los aspectos que optimizas y lo que comunicas al consejo de administración. Rapidez, actualidad e integridad: ese es el panorama completo de la preparación para la recuperación.
Resiliencia que puedes demostrar
Las organizaciones que superan las interrupciones cibernéticas con el menor daño posible comparten una característica: consideran que la capacidad de recuperación es algo que hay que demostrar continuamente, no algo que se afirme de vez en cuando. Conocen su MTCR. Sus SRI están al día. Su entorno de recuperación se ha probado en los últimos 90 días. Esa postura no es solo el resultado de una mejor tecnología. Es el resultado de una disciplina operativa —ResOps— que hace que la resiliencia sea continua, medible y gestionable. La plataforma de Commvault proporciona la base técnica: Recovery limpio, validación automatizada y la visibilidad unificada de datos, identidades y servicios que ResOps requiere a gran escala.
En cuanto al aspecto organizativo de esta ecuación —cómo definir las tolerancias de impacto, alinear a la dirección ejecutiva y construir la estructura de gobernanza que sustente la disciplina—, consulta el blog complementario de Deloitte, «La conversación sobre resiliencia que tu consejo de administración aún no está manteniendo».
Y para conocer el marco completo de ResOps, incluidos los seis ámbitos de ResOps y el modelo de medición que vincula la recuperabilidad técnica con la responsabilidad a nivel del consejo de administración, lea el informe técnico conjunto: «De la viabilidad mínima a la resiliencia operativa: ResOps en la práctica».
Bill O’Connell es director de seguridad de Commvault
.
