La copia de seguridad que nunca has probado no es una copia
Los grupos de ransomware van primero a por las copias, precisamente porque una restauración que funciona les quita la palanca. La mayoría de las organizaciones descubren su tiempo de recuperación durante el incidente.
One stopwatch, nothing else
A single mechanical stopwatch on a seamless bone-white surface, viewed slightly from above. Vast empty space around it. Nothing else in frame.
2400×1350 · WebP · <350KB
Todas las organizaciones a las que hemos ayudado a atravesar un incidente de ransomware tenían copias. No es eso lo que marca la diferencia. Lo que la marca es si alguien había restaurado alguna vez desde ellas bajo presión, con la persona que suele hacerlo no disponible, mientras el controlador de dominio también estaba cifrado.
Los atacantes van a por las copias deliberadamente
Los operadores de ransomware modernos no son oportunistas que casualmente cifran un recurso compartido. Pasan días dentro de la red primero, y uno de sus primeros objetivos es tu infraestructura de copias, porque un cliente que puede restaurar no paga. Borran instantáneas, corrompen repositorios y, si tu servidor de copias está unido al dominio con una cuenta de servicio de administrador de dominio, lo hacen con tus propias credenciales.
Si un atacante con administrador de dominio puede borrar tus copias, no tienes copias. Tienes duplicados.
3-2-1-1-0, y la parte que todo el mundo se salta
- 3 copias de los datos
- 2 tipos de medio distintos
- 1 copia fuera de sitio
- 1 copia inmutable o aislada: almacenamiento con bloqueo de objetos que un atacante con control total sigue sin poder borrar
- 0 errores en la verificación de restauración
El cero final es el que se cae, porque es el único que exige esfuerzo continuo en lugar de una compra. Todo lo anterior es arquitectura. Ese último dígito es un hábito.
Cómo es una prueba de restauración de verdad
No un trabajo de copia que informó de éxito. Una recuperación real, sobre infraestructura aislada, de un sistema que importa, cronometrada, ejecutada por alguien que no es quien la montó. Estás probando tres cosas a la vez: que los datos están íntegros, que el runbook es exacto y que un miembro normal de tu equipo puede seguirlo.
Hazlo con el runbook impreso. Durante un incidente real tu wiki puede estar cifrada, tu SSO caído y tu gestor de contraseñas ser uno de los sistemas que intentas restaurar.
Las cifras que deberías poder decir
Para cada nivel de sistema: cuántos datos puedes permitirte perder (RPO), cuánto tiempo puedes estar caído (RTO) y —por separado— el tiempo de recuperación que has medido realmente. La distancia entre los dos últimos es tu exposición real, y es la única cifra de este artículo que merece llevarse al consejo.
La mayoría de las organizaciones que evaluamos encuentran que esa distancia es de un factor tres o más. No porque la tecnología esté mal, sino porque nadie había contado las horas de restaurar Active Directory antes que los servidores de aplicaciones, ni había notado que la copia externa se restaura por un enlace que tarda once horas en mover un terabyte.