Puntos clave
- Frontier AI está reduciendo los plazos para solucionar vulnerabilidades; la prevención por sí sola ya no garantiza la seguridad.
- La pregunta que se plantean ahora los consejos de administración, los organismos reguladores y las aseguradoras no es «¿Tenemos copias de seguridad?», sino «¿Podemos demostrar que somos capaces de recuperarnos sin problemas?».
- Las copias de seguridad no son lo mismo que la recuperación: una copia te indica que los datos existen, pero no si están en buen estado ni si se pueden restaurar.
- El tiempo medio de recuperación tras una limpieza (MTCR) debe convertirse en una cifra que se mida de forma continua a nivel del consejo de administración, y no en una estimación teórica.
- Un entorno de recuperación aislado —sin conexión a la red, inmutable, reforzado y con identidades aisladas— es lo básico, no una función avanzada.
- Lo que se considera «limpio» seguirá cambiando a medida que los modelos de IA sean cada vez más capaces de detectar vulnerabilidades que los humanos no pueden prever.
He dedicado gran parte de mi carrera a gestionar sistemas de producción. Conozco a fondo los entornos de copia de seguridad, aquellos en los que los clientes realmente confían. Sé que los planes de Recovery son elementos que solo revelan sus debilidades cuando ya se ha producido algún problema. Esa experiencia cambia la forma de concebir la ciberresiliencia.
Visto desde la distancia, el proceso de Backup and Recovery parece manejable. Proteger los datos, almacenar copias, documentar el manual de procedimientos, realizar pruebas cuando sea posible y restaurar cuando sea necesario. Pero cualquiera que haya gestionado estos entornos a gran escala conoce la cruda realidad: Recovery es donde se ponen a prueba las suposiciones. Y, en este momento, demasiadas organizaciones están operando basándose en suposiciones que ya no son válidas. Durante años, la seguridad ha seguido un proceso ya conocido: encontrar la vulnerabilidad, aplicar el parche, reforzar el entorno y supervisar la actividad. Ese modelo sigue siendo importante. Pero el margen de tiempo del que depende se está reduciendo.
Frontier AI ha cambiado la velocidad a la que se detectan vulnerabilidades, se encadenan vías de ataque y se generan exploits. Modelos como Claude Mythos y GPT-5.5-Cyber ya han demostrado cómo funciona esto, aunque por el momento solo en pruebas controladas de acceso anticipado que aún dependían de la experiencia humana y presentaban tasas significativas de falsos positivos; pero la tendencia es innegable. A medida que se amplía el acceso, esa misma capacidad pasa a manos de los atacantes.
En solo un mes, Palo Alto Networks dio a conocer 26 CVE, que representan 75 problemas subyacentes, tras adoptar modelos de IA de vanguardia para el análisis de código, en comparación con su volumen habitual de menos de cinco CVE al mes. Los investigadores también advierten de que el descubrimiento asistido por IA está reduciendo drásticamente los plazos de corrección, ya que algunos exploits surgen ahora a los pocos minutos de su revelación. Cuando desaparece el margen para aplicar parches, la ecuación de la corrección deja de funcionar. La prevención no puede asumir todo el peso de la Readiness.
La prevención sigue siendo importante, pero ya no define la «Readiness». Los clientes con los que hablo no se preguntan si necesitan más controles. Ya saben que los necesitan. Se preguntan si su empresa puede recuperarse sin problemas cuando esos controles fallan, cuando los atacantes se mueven más rápido que los ciclos de corrección o cuando la vulnerabilidad lleva presente más tiempo del que nadie se había dado cuenta.
Esa es ahora la pregunta que plantean los consejos de administración, los organismos reguladores y las aseguradoras. Ya han dejado atrás la pregunta «¿Tenemos copias de seguridad?» y se han centrado en algo más trascendental: «¿Podemos demostrar que somos capaces de recuperarnos sin problemas?». Esa prueba comienza con una distinción que la mayoría de las organizaciones siguen confundiendo: las copias de seguridad no son lo mismo que la recuperación.
Una copia de seguridad es, precisamente, una copia. Pero no indica si los datos están en buen estado, si las dependencias de las aplicaciones están intactas, si los servicios de identidad se pueden restaurar de forma segura o si la secuencia de recuperación sigue reflejando el entorno actual. He revisado planes que parecían completos hasta que alguien intentó ejecutarlos. El manual de procedimientos estaba ahí, pero desactualizado. La restauración funcionó, pero tardó tres veces más de lo previsto. El sistema volvió a funcionar, pero las aplicaciones posteriores no podían conectarse. Nada de eso es inusual. Es exactamente lo que se supone que deben poner de manifiesto las pruebas reales. El problema es que la mayoría de las organizaciones descubren estas deficiencias durante un incidente real. El indicador más importante cuando algo sale mal es la rapidez con la que puedes volver a un estado en el que sabes que todo funciona bien. Por eso, el tiempo medio de recuperación completa (MTCR) tiene que convertirse en una cifra que se trate a nivel de la junta directiva, no una estimación teórica en un plan, sino un tiempo medido y validado.
El objetivo en constante cambio: lo que hoy se considera seguro puede que mañana ya no lo sea
Con los modelos de Frontier AI, la respuesta sincera es esta: no puedes garantizar que todas las vulnerabilidades se detecten y se solucionen a tiempo. Los atacantes que se aprovechan de esos mismos modelos están descubriendo y encadenando exploits más rápido de lo que cualquier programa de corrección puede seguirles el ritmo de forma realista. Eso no es un fallo de tu equipo de seguridad. Es la nueva realidad del panorama de amenazas.
Lo que sí puedes controlar es tu capacidad de recuperación. Eso significa un entorno de recuperación aislado: copias de seguridad físicamente aisladas de Internet, inaccesibles desde la red de producción y protegidas contra el movimiento lateral que caracteriza a una brecha sofisticada. Significa inmutabilidad y bloqueo de cumplimiento, de modo que ninguna credencial, por muy privilegiada que sea, pueda acortar el periodo de retención o eliminar datos al margen de un proceso autorizado. Y significa poner en práctica las operaciones de Recovery (ResOps): no solo realizar copias de seguridad de los datos, sino probar continuamente la Recovery, automatizar la validación de la integridad y medir el MTCR —el tiempo validado para volver a un estado conocido como correcto—.
Pero aquí está la parte que la mayoría de las organizaciones aún no tienen en cuenta: lo que se considera «limpio» no es una línea fija. A medida que los modelos de IA se vuelvan más capaces, encontrarán cada vez más vulnerabilidades que la mente humana simplemente no puede anticipar, vías de ataque novedosas, implantes latentes, corrupciones sutiles incrustadas mucho antes de su detección. Un punto de recuperación que sea «limpio» según los estándares actuales puede entrañar un riesgo que el análisis forense asistido por IA del futuro sacará a la luz. Esto significa que su definición de «limpio» debe evolucionar continuamente. El MTCR no es una cifra que se establezca una sola vez. Es una disciplina que hay que mantener, revisando qué significa «limpio», actualizando los criterios de validación y tratando la resiliencia como un estándar vivo, en lugar de como una certificación que se obtiene una sola vez.
Entonces, ¿qué es un buen MTCR? Basándome en lo que he visto que funciona en la práctica, el objetivo para toda tu «empresa mínima viable» —el conjunto más pequeño de sistemas que te permite seguir operando, que defino con precisión más adelante— debería ser inferior a seis horas. Seis horas es un objetivo alcanzable con la arquitectura adecuada: un IRE listo para funcionar, una secuencia de Recovery prevalidada y manuales de procedimientos que sean ejecutables, en lugar de solo legibles. Si tu MTCR actual se mide en días, la diferencia casi siempre radica en uno de esos tres elementos.
Cuatro pasos para mantener la resiliencia en la era de la IA de vanguardia
Aceptar que la prevención por sí sola no basta es el punto de partida. A partir de ahí, el trabajo se concreta. Aquí es donde aconsejo a las organizaciones que se centren.
1. Evalúa tus riesgos reales de recuperación.
La mayoría de las evaluaciones de riesgos de recuperación plantean las preguntas equivocadas. «¿Existen copias de seguridad?» no es lo mismo que «¿Podemos recuperarnos sin problemas?». Las preguntas más difíciles son: ¿Se pueden restaurar los sistemas críticos sin reintroducir la amenaza? ¿Están los entornos de recuperación aislados de los sistemas de producción comprometidos? ¿Están los planes de recuperación adaptados a las dependencias actuales, y no a la arquitectura de hace dos años?
En un entorno de vulnerabilidades que evoluciona rápidamente, la brecha entre «tenemos copias de seguridad» y «podemos recuperarnos» es donde las organizaciones salen perjudicadas. Evaluar esa brecha con honestidad, antes de que un incidente obligue a abordar el problema, es por donde debe comenzar la planificación de la resiliencia. Esa evaluación debe incluir un análisis de impacto en el negocio: qué sistemas tienen un margen de recuperación de minutos, cuáles de horas y cuáles pueden esperar un día. Sin esa clasificación por niveles, todos los sistemas parecen igual de urgentes durante un incidente y nada se restaura con la suficiente rapidez.
2. Haz que la recuperación aislada y el aislamiento físico sean la norma, no la excepción.
Si todavía consideras que las copias inmutables y físicamente aisladas son una funcionalidad avanzada en lugar de un requisito estándar, esa suposición ya no es válida. Cuando los plazos de explotación se reducen a minutos, necesitas opciones alternativas que estén separadas estructuralmente de los planos de identidad, red y gestión de producción: aisladas lógica o físicamente, inmutables y sin ninguna ruta activa de vuelta a producción que un atacante pueda seguir.
El objetivo no es solo protegerse de la amenaza actual, sino mantener opciones de recuperación fiables para cuando se aproveche una vulnerabilidad que aún no hayas corregido. Eso ya ocurre. Prepárate para ello. El aislamiento solo es válido si la infraestructura que lo rodea está fortificada. Esto implica una infraestructura de copias de seguridad en sistemas operativos fortificados, no en imágenes genéricas, e idealmente en servidores físicos que resistan un ataque a nivel de hipervisor. Significa que las claves de cifrado deben almacenarse fuera de la plataforma de copias de seguridad, en una bóveda externa con acceso «justo a tiempo» y sin depender del Active Directory de producción. Y significa tratar tu dominio de copias de seguridad como un perímetro de identidad independiente: sin confiar en el Active Directory de producción, con autenticación multifactorial (MFA) obligatoria y autorización por parte de varias personas para operaciones destructivas. Nada de esto es extraordinario; es la base para que tu entorno se recupere en un espacio no comprometido.
Igualmente importante es la cuestión de a partir de qué se está recuperando. Los datos del sector sobre la respuesta a incidentes sitúan sistemáticamente la mediana del tiempo de permanencia de una brecha en el rango de las semanas, no de los días. Esto significa que sus copias de recuperación deben remontarse lo suficientemente atrás como para encontrar un punto genuinamente limpio, no solo la copia de seguridad de ayer. Los sistemas críticos requieren múltiples copias separadas geográficamente, incluyendo al menos una copia inmutable y otra que esté completamente fuera de línea. La política de retención no es una decisión basada en el coste del almacenamiento. Es una decisión de seguridad.
3. Averigua qué sistemas son imprescindibles para el funcionamiento de la empresa y recupéralos primero.
La mayoría de las organizaciones descubren cuál es su proceso de recuperación cuando se produce un incidente. Por eso, las primeras 24-48 horas no se dedican a restaurar los sistemas, sino a decidir qué es lo que realmente importa. Las organizaciones saben que tienen que restablecer las plataformas de identidad, los sistemas de facturación, las bases de datos operativas y la infraestructura básica. Lo que a menudo no han definido es el orden, las dependencias entre esos sistemas y las aplicaciones posteriores que no pueden funcionar hasta que se restablezcan servicios concretos.
Esto se complica a medida que la IA se va integrando en las operaciones empresariales. Los flujos de datos, los repositorios de modelos, las bases de datos vectoriales y los flujos de trabajo basados en agentes son ahora dependencias operativas, no solo infraestructura técnica. Si tu secuencia de Recovery no los tiene en cuenta, es probable que tus estimaciones del tiempo de recuperación sean erróneas. Definir qué significa operar como una empresa mínimamente viable (el conjunto más pequeño de sistemas necesarios para mantener el negocio en funcionamiento) y estructurar Recovery en torno a esa definición no es un ejercicio teórico. Es la respuesta práctica a la pregunta que todo equipo directivo se planteará durante un incidente: ¿Qué restablecemos primero?
Según mi experiencia ayudando a clientes a gestionar incidentes activos, las primeras 12 horas responden a esa pregunta, lo hayas planificado o no: lo que se recupere en ese plazo se convierte, por defecto, en tu MVC. Las organizaciones que se recuperan más rápido lo decidieron de antemano: sabían exactamente qué sistemas tenían que estar de nuevo operativos en 12 horas y habían comprobado que podían hacerlo. Si tu MVC no cabe en 12 horas, no es tu MVC, es una lista de deseos. El trabajo consiste en ir recortando hasta que lo que quede se pueda restaurar de forma realista en ese plazo, y luego probarlo hasta que puedas demostrarlo.
4. Automatiza la resiliencia y realiza pruebas de forma continua, no según un calendario fijo.
Un plan de recuperación que solo existe en un documento y se revisa una vez al año no es una capacidad de recuperación. Es una hipótesis que nunca se ha puesto a prueba en la práctica. El problema de las pruebas basadas en un calendario es lo que se pasa por alto entre ciclos. Los entornos cambian constantemente: nuevas cargas de trabajo, dependencias actualizadas, una infraestructura que se ha desviado de lo que describe el manual de operaciones. Para cuando se ejecuta la prueba anual, se está validando una instantánea de un entorno que ya no existe. En un panorama de amenazas en el que la explotación puede producirse a los pocos minutos de la divulgación, ese retraso es inaceptable. El análisis de amenazas, la identificación de puntos de recuperación limpios, la restauración que tiene en cuenta las dependencias y la coordinación de la recuperación deben automatizarse y ejecutarse de forma continua. No porque la automatización sea una buena práctica, sino porque la alternativa manual no puede seguir el ritmo al que se mueven las cosas hoy en día. Las pruebas continuas también dependen de la detección continua. No se puede elegir un punto de recuperación limpio si no se sabe cuándo comenzó el ataque. Por eso, la detección de amenazas, el análisis de anomalías en las copias de seguridad y el análisis de los puntos de recuperación deben complementarse entre sí: la detección indica qué copias son anteriores a la intrusión, y esa información determina desde qué punto se va a recuperar realmente. Sin ese vínculo, se estará restaurando a una fecha que se espera que esté limpia en lugar de a una que se haya comprobado, y en un panorama de amenazas de Frontier AI, la esperanza no es una estrategia de recuperación.
Lo que se detecta en las pruebas continuas es diferente de lo que se encuentra en las pruebas anuales. Las pruebas programadas suelen confirmar que el plan funciona en condiciones controladas. Las pruebas continuas detectan la dependencia que cambió el mes pasado, la secuencia de recuperación que falla cuando se añade una carga de trabajo específica y el servicio de identidad que tarda el doble de lo previsto en restablecerse. Esas son las deficiencias que realmente importan cuando ocurre algo de verdad, y la única forma de detectarlas antes de que se produzca un incidente es realizar pruebas constantemente.
Las pruebas también deben realizarse en el entorno adecuado. Una prueba de recuperación que se ejecuta en la infraestructura de producción no te indica si podrás recuperarte cuando la producción se vea comprometida. Las pruebas en «sala limpia» —la validación de la restauración en un entorno totalmente aislado sin conectividad con la producción— son la forma de confirmar que tus copias de seguridad son realmente utilizables en condiciones de incidente. Esto incluye la recuperación de servicios de identidad, la gestión de claves externas y las aplicaciones de nivel 0 de forma aislada, con cuentas de emergencia dedicadas que existen fuera de tu directorio habitual.
Lo que hace que las pruebas diarias sean viables es la «validación de restauración», un tipo de recuperación que comprueba toda la ruta de restauración de cada activo crítico sin afectar al entorno de producción. Tu plataforma de copias de seguridad debe admitir esto de forma nativa; si no puede ejecutar a diario una prueba de recuperabilidad automatizada y sin interrupciones en todo tu MVC, en realidad no sabes si tus copias de seguridad funcionan. En Commvault, esto se lleva a cabo mediante restauraciones de tus grupos de activos críticos, con informes automáticos sobre el estado de recuperación de cada sistema protegido.
Lo mismo se aplica a tus manuales de procedimientos. Un manual de procedimientos que se encuentra en un documento de Word o PDF es un manual de referencia, no una herramienta operativa: da por sentado que alguien tiene el tiempo, la claridad y el acceso necesarios para leerlo bajo presión. Los verdaderos manuales de procedimientos son scripts digitales que ejecutan la secuencia de Recovery y validan cada paso, confirmando que la aplicación funciona realmente antes de continuar: no «el servicio se ha iniciado», sino «la aplicación ha respondido correctamente a una transacción sintética». Los «Commvault Cleanroom Runbooks» están diseñados para esto: flujos de trabajo ejecutables que impulsan una recuperación de extremo a extremo en un entorno aislado, sin que una persona tenga que interpretar un documento en cada paso.
Un último punto que rara vez se incluye en los planes de recuperación hasta que es demasiado tarde: durante un incidente grave, la propia infraestructura de comunicaciones de tu empresa puede verse comprometida o dejar de estar disponible. El correo electrónico, Teams y Slack funcionan en la misma infraestructura a la que apuntan los atacantes. Averigua de antemano qué canales fuera de banda utilizará tu equipo para coordinarse y asegúrate de que dichos canales se prueben junto con tus procedimientos técnicos de Recovery. Escucha lo que tiene que decir Bill O’Connell, director de seguridad de Commvault, sobre los cuatro pasos clave para la resiliencia en la era de la IA.
La resiliencia es una disciplina operativa, no un proyecto
Las organizaciones que resistirán ante las amenazas de vanguardia impulsadas por la IA son aquellas que consideran la resiliencia como una disciplina operativa: un MTCR bien medido, una validación continua y una capacidad de recuperación que han demostrado, no que dan por sentada. El problema no es que los ataques sean cada vez más rápidos. Es que la recuperación no ha avanzado al mismo ritmo, y hasta que lo haga, las cuentas no cuadran.
Preguntas frecuentes
P: ¿Qué es el tiempo medio de recuperación limpia (MTCR) y por qué es importante?
R: El MTCR mide la rapidez con la que una organización puede volver a un estado verificado y reconocido como correcto tras un ciberataque —no solo restaurar los datos, sino confirmar que están limpios y que las dependencias de las aplicaciones están intactas—. Debería ser una métrica a nivel del consejo de administración con un tiempo medido y validado, no una estimación teórica oculta en un plan de Recovery. El objetivo para un MVC bien diseñado —que abarque todos los sistemas de identidad, las aplicaciones críticas y la Readiness del entorno aislado— es inferior a seis horas.
P: ¿Qué es un entorno de Recovery aislado y en qué se diferencia de una copia de seguridad estándar?
R: Un entorno de Recovery aislado es una copia inmutable y totalmente aislada de los datos críticos, separada estructuralmente de las redes de producción, los sistemas de identidad y los planos de gestión. Una copia de seguridad estándar te indica que existe una copia. Un IRE te indica que esa copia está protegida frente al mismo ataque que afectó a tu entorno de producción.
P:
¿Cómo sabemos si realmente podemos recuperarnos hoy?
R: La única respuesta honesta proviene de las pruebas, no de la documentación. Si no puedes señalar una Recovery reciente y validada de tu empresa mínimamente viable —idealmente, una prueba automatizada diaria—, entonces no lo sabes, solo estás haciendo suposiciones. Una respuesta defendible ante el consejo de administración es un MTCR cuantificado y respaldado por una validación continua, no un plan de Recovery que parezca completo sobre el papel.
P: ¿Qué esperan ahora los reguladores y las aseguradoras cibernéticas?
R: El listón ha pasado de «¿Tienes copias de seguridad?» a «¿Puedes demostrar que puedes recuperarte sin problemas y con qué rapidez?». Los reguladores esperan cada vez más una capacidad de recuperación demostrable y una resiliencia probada; las aseguradoras fijan cada vez más el precio de la cobertura —y pagan las indemnizaciones— basándose en pruebas de copias de seguridad aisladas e inmutables y en tiempos de recuperación validados. Un MTCR cuantificado y una cadencia de pruebas documentada se están convirtiendo en requisitos imprescindibles para ambos. Rajiv Kottomtharayil es director de producto de Commvault.
