Casi todas las empresas tienen backup. Muchas menos saben cuánto tardarían en volver a operar si todo el entorno quedara indisponible mañana. Esa diferencia entre tener copias y poder recuperarse es lo que separa el backup de la resiliencia cibernética.
El ransomware dejó esa distancia en evidencia. El atacante moderno no se conforma con cifrar los servidores de producción: busca la consola de backup, borra snapshots e intenta cifrar los propios repositorios antes de lanzar el ataque. Quien descubre el día del incidente que las copias eran accesibles con la misma cuenta de administrador comprometida lo descubre demasiado tarde.
Backup no es resiliencia
El NIST, en el SP 800-160 Vol. 2 Rev. 1, define la resiliencia cibernética como la capacidad de anticipar, resistir, recuperarse y adaptarse a condiciones adversas, ataques o compromisos. El backup cumple bien uno de esos cuatro objetivos —recuperarse— y solo si está diseñado para sobrevivir al propio ataque.
En la práctica, un backup que existe pero no restaura, o que restaura en tres semanas cuando el negocio solo aguanta tres días, no entrega resiliencia. Restaurar una infraestructura compleja rara vez es tan sencillo como parece: dependencias entre sistemas, orden de arranque, credenciales, licencias, DNS y servicios de identidad suelen aparecer recién en la prueba —o en la crisis—. Por eso la pregunta correcta no es "¿tenemos backup?", sino "¿en cuánto tiempo y con cuánta pérdida de datos volvemos a operar?".
Los demás objetivos dependen de controles que reducen la probabilidad de que el ataque llegue al backup: concientización contra phishing, actualización de sistemas y software, autenticación multifactor y filtrado de correo. La guía #StopRansomware de la CISA enumera esas mismas medidas como prevención básica. Para las pequeñas y medianas empresas sin un equipo de seguridad dedicado, apoyarse en un socio especializado suele ser la forma realista de mantener esos controles y la vigilancia sobre el entorno.
RTO y RPO: los números que debe definir el negocio
Dos métricas, descritas en el NIST SP 800-34 Rev. 1 y utilizadas también en la ISO 22301, traducen esa pregunta:
- RTO (Recovery Time Objective). Tiempo máximo que un sistema puede estar indisponible antes de que el impacto en el negocio sea inaceptable.
- RPO (Recovery Point Objective). Punto en el tiempo hasta el cual deben recuperarse los datos; en la práctica, cuánta pérdida de datos es tolerable. Un RPO de cuatro horas exige copias al menos cada cuatro horas.
Estos valores no son una decisión de TI. Surgen del análisis de impacto en el negocio (BIA), que identifica los procesos críticos, sus sistemas de soporte y el tiempo máximo de interrupción tolerable. Sin BIA, la frecuencia de backup y la arquitectura de recuperación se eligen por costumbre y no por necesidad, y es habitual descubrir que el sistema de facturación tiene la misma política de copia que un servidor de archivos olvidado.
3-2-1 y 3-2-1-1-0: la regla y su actualización
La regla 3-2-1 es la referencia clásica de redundancia: tres copias de los datos, en dos tipos de medio o almacenamiento distintos, con una copia fuera del sitio principal. Protege bien contra fallas de hardware, errores humanos y desastres físicos.
Frente al ransomware, se queda corta si todas las copias son alcanzables por la red y con las mismas credenciales. De ahí la variante 3-2-1-1-0, popularizada por el mercado:
- +1 copia offline, aislada o inmutable. Una copia que el atacante no pueda modificar ni borrar, aun con privilegios de administrador en el entorno.
- 0 errores en la verificación. Backups comprobados automáticamente y restauraciones probadas, sin fallas pendientes.
La guía #StopRansomware de la CISA va en la misma dirección: mantener backups offline y cifrados de los datos críticos y probar periódicamente su disponibilidad e integridad en un escenario de recuperación ante desastres.
Inmutable, offline, aislado: qué cambia en la práctica
Los términos suelen usarse como sinónimos, pero no lo son:
- Inmutable. El almacenamiento impide modificar o borrar durante un período de retención (por ejemplo, object lock en almacenamiento de objetos o repositorios con política WORM). Protección lógica.
- Offline (air gap). La copia no tiene conexión de red con el entorno de producción: cinta fuera de la librería, medio desconectado. Protección física.
- Aislado (vault). Entorno separado, con red, identidad y administración propias, al que se accede de forma controlada.
Sea cual sea la elección, tres cuidados valen siempre: credenciales de backup separadas del dominio corporativo y protegidas con MFA; monitoreo de borrados masivos, cambios de retención y fallas de jobs, con alertas tratadas como eventos de seguridad; y cifrado de las copias, para que una fuga del repositorio no se convierta en una fuga de datos.
Una copia limpia importa tanto como una copia disponible. Los atacantes suelen permanecer un tiempo en el entorno antes de actuar. Restaurar un backup que ya contiene el acceso del intruso reinicia el incidente. La retención debe cubrir ventanas lo bastante largas para volver a un punto anterior al compromiso, y la restauración debe verificarse antes de volver a producción.
Probar la restauración es el control más descuidado
Un job terminado con éxito no equivale a datos recuperables. Un programa de pruebas maduro incluye:
- Verificación automática. Integridad de las copias comprobada en cada ejecución, con alerta ante fallas.
- Restauración periódica de muestras. Archivos, bases de datos y máquinas virtuales restaurados en un entorno controlado, confirmando que la aplicación realmente funciona.
- Prueba de recuperación completa. Al menos para los sistemas críticos, simular la pérdida total y medir el tiempo real hasta la operación, y compararlo con el RTO definido.
- Ejercicios con el negocio. Ejercicios de mesa en los que los gerentes toman decisiones en un escenario de indisponibilidad, como recomiendan el NIST SP 800-34 y la ISO 22301.
El resultado de cada prueba debe generar ajustes: runbooks actualizados, dependencias documentadas, prioridad de restauración revisada. Clasificar y segmentar los datos sensibles ayuda a definir ese orden: lo que vuelve primero es lo que sostiene los procesos críticos.
Del backup al plan de continuidad
El backup es un componente técnico; la continuidad es una capacidad organizacional. La ISO 22301 trata la continuidad del negocio como un sistema de gestión, con roles, políticas, BIA, estrategias, planes, ejercicios y mejora continua. El NIST SP 800-34 detalla el plan de contingencia de sistemas, con fases de activación, recuperación y reconstitución.
En un incidente de ransomware, el plan de recuperación también debe articularse con la respuesta a incidentes: antes de restaurar, hay que contener el ataque, entender el vector de entrada y asegurarse de que el atacante ya no está en el entorno. Del mismo modo, la detección continua de un SOC sobre la infraestructura de backup aumenta la probabilidad de percibir el intento de sabotaje antes de que se concrete.
Preguntas frecuentes
¿Un backup en la nube cuenta como copia fuera del sitio?
Cuenta como copia en otra ubicación, pero no necesariamente como copia protegida. Si la nube es accesible con las mismas credenciales del entorno y permite borrar sin restricciones, un atacante con privilegios puede eliminarla. Habilite la inmutabilidad, separe identidades y monitoree los cambios de retención.
¿Cuál es la diferencia entre RTO y RPO?
El RTO mide cuánto tiempo puede estar caído un sistema; el RPO mide cuánta pérdida de datos es tolerable. Un sistema puede tener un RTO largo y un RPO corto (puede tardar en volver, pero no puede perder transacciones) o al revés.
¿Con qué frecuencia debo probar la restauración?
No hay un número único. La verificación de integridad debe ser automática y continua; las restauraciones de muestra, periódicas; y las pruebas completas de los sistemas críticos, al menos en un ciclo planificado y siempre después de cambios relevantes de infraestructura. La frecuencia debe ser proporcional a la criticidad definida en el BIA.
¿El backup inmutable resuelve el problema del ransomware?
Resuelve una parte: garantiza que habrá una copia recuperable. No impide la exfiltración de datos, que hoy acompaña a buena parte de los ataques, ni reemplaza la contención, la erradicación y la verificación de que la copia está limpia.
Referencias: NIST SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems (BIA, RTO, RPO y plan de contingencia); NIST SP 800-160 Vol. 2 Rev. 1, Developing Cyber-Resilient Systems (objetivos de resiliencia: anticipar, resistir, recuperarse, adaptarse); CISA, #StopRansomware Guide (backups offline, cifrados y probados); ISO 22301:2019, Security and resilience — Business continuity management systems — Requirements. La regla 3-2-1-1-0 es una convención de mercado, no un estándar normativo. Este artículo es educativo y no describe un producto específico.