Muchas iniciativas de recuperación tras un ataque de ransomware comienzan de la misma manera. Alguien saca a relucir un plan de recuperación ante desastres. Otro llama al proveedor de copias de seguridad. Y entonces el plan, que probablemente se diseñó pensando en desastres naturales o en borrados accidentales, se enfrenta a la realidad y se viene abajo.

Las deficiencias en la preparación para la recuperación son notablemente constantes en todas las organizaciones, incluso en aquellas que han realizado importantes inversiones en detección y resistencia. Esto apunta a un problema estructural. Las organizaciones llevan décadas desarrollando programas de seguridad y perfeccionando su capacidad para anticipar las amenazas. Solo se ha dedicado una mínima parte de ese tiempo a la capacidad de recuperación, y los modelos de IA de vanguardia, como Mythos, están poniendo de manifiesto por qué se trata de un error muy costoso.

La ya de por sí baja barrera de entrada para los operadores de ransomware pronto será prácticamente inexistente. Los atacantes actuales pueden burlar casi cualquier defensa si están lo suficientemente motivados. Dentro de un año, con un modelo de IA adecuado que detecte vulnerabilidades de forma autónoma, puede que ni siquiera tengan que estar tan motivados.

El coste de un plan de recuperación sin probar va en aumento. Si tu organización está abordando estos cambios únicamente desde la perspectiva de cómo detectar las amenazas más rápidamente, estás dejando la mitad del problema sin resolver.

En qué siguen equivocándose las organizaciones

Los fallos que se enumeran a continuación no son exclusivos de las organizaciones con programas de seguridad deficientes. También se dan en empresas que cuentan con sistemas de detección consolidados, equipos sólidos y presupuestos de seguridad considerables. El denominador común es que la capacidad de recuperación ha recibido menos inversión y se ha sometido a menos pruebas que la capacidad de detección.

La brecha de confianza en las copias de seguridad

Este es el error más peligroso, porque da la sensación de que está resuelto.

Tienes copias de seguridad. Las tareas se completan. El panel de control está en verde. Informas al consejo de que las copias de seguridad están en marcha. Marcaste la casilla y pasaste a otra cosa, probablemente hace años.

Entonces se produce el ataque. ¿Podrán esas copias de seguridad resistir a un adversario que conoce a la perfección el entorno, dispone de credenciales privilegiadas y ataca deliberadamente la infraestructura de copias de seguridad?

En proyectos reales, Fenix24 suele encontrar que la infraestructura de copias de seguridad se encuentra en el mismo segmento de red que el entorno de producción. Encontramos repositorios «inmutables» en los que la cuenta de servicio sigue teniendo permisos de eliminación. Encontramos tareas de copia de seguridad que se han completado con éxito durante años sin que nadie haya comprobado que la restauración completa funcione correctamente.

Los autores de ransomware se centran en las copias de seguridad porque son lo que permite a las víctimas salir airosas sin tener que pagar. Los modelos de IA de Frontier, capaces de mapear entornos de forma autónoma, harán que esos ataques sean más precisos. Si un modelo es capaz de detectar vulnerabilidades en todo un sistema operativo, también podrá localizar el servidor de copias de seguridad que tu equipo configuró hace tres años y que nunca se ha trasladado.

Las copias de seguridad fiables deben cumplir tres requisitos: inmutabilidad (ni siquiera un atacante con credenciales de administrador puede modificarlas o eliminarlas), segmentación (el entorno de copia de seguridad debe ser inaccesible desde la red comprometida) y restauración validada (se ha comprobado que la recuperación es completa, no solo que la tarea se ha completado). Muchas organizaciones cumplen uno de estos tres requisitos. Son muy pocas las que los cumplen todos. Y las que los cumplen todos suelen haber llegado a esa situación porque han aprendido por las malas lo que ocurre cuando no se cumplen.

La ficción de RTO

Tu RTO indica 48 horas. Se incorporó a un plan, pasó a una presentación ante la junta directiva y pasó a formar parte de la visión común de la organización sobre el riesgo.

Genial, pero… nadie ha calculado el tiempo que llevaría una recuperación completa en un escenario en el que la identidad se vea comprometida, el acceso a las copias de seguridad esté limitado y el equipo esté trabajando con las comunicaciones mermadas. Un simulacro en el que todo el mundo tiene notas y el SIEM funciona no cuenta. Tampoco cuenta una ventana de mantenimiento programada en la que se restaura un sistema a partir de una copia de seguridad.

Una prueba de recuperación significativa parte de la hipótesis más pesimista: el sistema de gestión de identidades no funciona, el acceso a las copias de seguridad está limitado, las comunicaciones se han visto afectadas y la mitad del equipo está tomando decisiones sin haber dormido. El director de seguridad de la información está de safari sin teléfono móvil.

En casi todos los proyectos vemos las consecuencias de unos RTO que no se han puesto a prueba. La cifra que figura en el papel y la realidad sobre el terreno rara vez coinciden. Cuando divergen, las consecuencias se agravan: pérdida de ingresos, interrupción de las operaciones, pérdida de clientes, daño a la reputación y exposición a riesgos normativos que la organización nunca tuvo en cuenta en su evaluación de riesgos, ya que se basaba en una cifra que nadie había comprobado.

Reconstrucción de la identidad

Active Directory suele ser el punto central de los ataques. Por eso, debería ocupar un lugar igualmente central en el plan de recuperación. En la práctica, vemos planes maduros y bien organizados para restaurar aplicaciones y bases de datos, pero luego se hace el vacío cuando la conversación gira en torno a la recuperación de AD. No hay copias de seguridad fuera de línea. No hay un proceso de reconstrucción documentado. No se ha comprobado el tiempo necesario para la reconstrucción. No hay una respuesta clara sobre qué controladores de dominio están limpios, en qué cuentas de servicio se puede confiar o cómo se restablecerá de forma segura el acceso con privilegios.

Esto es más importante de lo que la mayoría de los planes de recuperación reconocen. No se puede confiar en nada de lo que se encuentre más adelante hasta que se haya restablecido la identidad y se haya comprobado que está limpia. Aplicaciones, bases de datos, terminales, recursos compartidos, acceso de administrador, cuentas de servicio, integraciones en la nube, flujos de trabajo con privilegios. Todo ello depende de la identidad de una forma u otra. Si la identidad se ve comprometida, todo lo que se autentica a través de ella queda comprometido por extensión.

Las organizaciones que gestionan bien la recuperación de identidades lo han puesto en práctica. Cuentan con copias de seguridad de Active Directory fuera de línea. Disponen de un proceso documentado y probado para reconstruir el sistema partiendo de cero. Saben cuánto tiempo lleva porque lo han medido. El resto descubre la respuesta durante la peor semana de su carrera.

Ceguera ante las dependencias

Cuando el entorno deja de funcionar, siempre hay alguien que plantea la pregunta que determina la velocidad de recuperación: «¿Qué es lo primero que vuelve a funcionar?».

En demasiadas organizaciones, la respuesta está en la cabeza de un solo ingeniero. A veces, ni siquiera existe.

La recuperación no es una mera lista de sistemas. Es una secuencia. No se puede restablecer un sistema ERP si la base de datos de la que depende sigue inactiva. No se pueden poner en funcionamiento las aplicaciones si la infraestructura de identidades con la que se autentican no se ha reconstruido. No se pueden restaurar los flujos de trabajo críticos si faltan o se han visto comprometidos la red, el almacenamiento, el DNS, los secretos y las cuentas de servicio que los sustentan.

Sin un modelo de dependencias actualizado, los equipos de recuperación pierden un tiempo valioso al restablecer los sistemas en un orden incorrecto. Ponen en marcha las aplicaciones antes de que la infraestructura de la que dependen esté lista. Descubren que faltan dependencias en mitad del proceso de recuperación, bajo presión, mientras el negocio sufre pérdidas. Una recuperación que debería llevar días se alarga durante semanas porque la secuencia fue errónea desde el principio.

La mayoría de las organizaciones tienen los datos sobre sus activos dispersos en docenas de herramientas. Están desactualizados. Presentan contradicciones. La base de datos de gestión de configuraciones (CMDB) dice una cosa, el equipo de redes dice otra, y el responsable de la aplicación, que conocía el panorama completo, dejó la empresa hace ocho meses. En condiciones normales de funcionamiento, esa fragmentación resulta un inconveniente. Durante una recuperación activa, es devastadora.

Las organizaciones que se recuperan más rápido no resuelven esto durante el incidente. Ya lo saben. Los sistemas de nivel 0 están identificados. Las dependencias se han mapeado a partir de datos en tiempo real, no de diagramas estáticos. Las secuencias de recuperación se han generado a partir de relaciones reales y se han probado antes de que fueran necesarias. El resto está elaborando el plan desde cero, contra reloj y a ciegas.

La desconexión entre tiempos de paz y tiempos de guerra

Los programas de seguridad se diseñan y documentan en tiempos de paz. En tiempos de paz, el SIEM funciona. El SOC cuenta con personal. El socio forense está a solo una llamada de distancia. El personal está descansado. Las comunicaciones funcionan. Las decisiones pueden debatirse durante días o semanas.

En tiempos de guerra ocurre todo lo contrario.

Las organizaciones que gestionan bien las situaciones de guerra suelen haberlo ensayado en tiempos de paz. Llevaban a cabo simulacros para poner a prueba las operaciones de recuperación, la coordinación, la secuencia de acciones y la toma de decisiones en condiciones adversas. Así descubrían qué es lo que iba a fallar.

Las organizaciones que se enfrentan a estas dificultades pensaban que el plan se mantendría en pie una vez que todo se hubiera incendiado. Los plazos de ataque comprimidos por la IA echarán más leña al fuego.

Resiliencia y recuperación en un mundo de IA posfronterizo

La mayoría de las hipótesis sobre la resiliencia y la capacidad de recuperación fracasan cuando se produce un ataque real.

• Resulta que las «copias de seguridad inmutables» no son tan inmutables después de todo.
• No solo se pierden los datos, sino que también se destruye la infraestructura.
• Una identificación insuficiente de los activos y las dependencias provoca días o semanas de inactividad.
• Los RTO y los RPO no son realistas.

Los analistas lo analizan todo en lo que respecta al futuro de la resiliencia. ¿Quieres conocer el plan para diseñar y poner en práctica una verdadera ciberresiliencia? Descarga el nuevo informe de validación técnica de Omdia: «Diseña y pon en práctica la resiliencia con Fenix24».

¿Qué es lo que determina si sobrevives?

Hay tres factores que distinguen a las organizaciones que se recuperan rápidamente de aquellas que pasan semanas a la deriva (o que ni siquiera se recuperan). Frontier AI no cambia los mecanismos. Cambia la velocidad. Eso hace que cada factor sea aún más crucial, no menos.

La identidad debe ser lo primero. Esto no es negociable y es el paso que la mayoría de las organizaciones han descuidado más. Active Directory y la infraestructura de identidades se encuentran entre los primeros objetivos de un ataque de ransomware moderno. También deben ser de lo primero que se restaure. No se puede confiar en nada posterior hasta que se haya reconstruido la identidad y se haya verificado que está limpia. Aplicaciones, bases de datos, cuentas de servicio, flujos de trabajo con privilegios, integraciones en la nube. Todo ello se autentica frente a la identidad de una forma u otra. Los ataques acelerados por IA no alteran esa cadena de dependencia. Lo que hacen es reducir drásticamente el tiempo de que se dispone para responder a ellos.

Las copias de seguridad deben resistir un ataque, no solo un fallo de hardware. La mayoría de las organizaciones cuentan con copias de seguridad. Sin embargo, la mayoría no dispone de copias de seguridad capaces de resistir el ataque de alguien que posea credenciales válidas, conozca su entorno y sepa exactamente dónde se encuentra la infraestructura de copias de seguridad. Una estrategia de copias de seguridad diseñada para hacer frente a fallos de hardware o a eliminaciones accidentales no es lo mismo que una estrategia diseñada para contrarrestar a un adversario inteligente con acceso privilegiado.

La recuperación debe seguir la cadena de dependencias real, no la supuesta. No se puede restablecer un sistema ERP si la base de datos de la que depende sigue inactiva. No se pueden restaurar los flujos de trabajo críticos si la infraestructura de soporte falta o está comprometida. La recuperación es una secuencia, y esa secuencia debe ser la correcta. En la mayoría de las organizaciones, las dependencias no mapeadas son una de las principales causas de retraso en las recuperaciones. El mapeo automatizado de dependencias basado en telemetría en tiempo real, del tipo que se mantiene actualizado a medida que cambia el entorno, marca la diferencia entre un plan de recuperación que refleja la realidad y uno que refleja la última vez que alguien actualizó una hoja de cálculo.

Estos tres factores eran ciertos hace cinco años. Y lo seguirán siendo dentro de cinco años. Lo que Mythos y la IA de vanguardia cambian es el coste de equivocarse. Cuando la velocidad de los ataques se acelera por debajo de la capacidad de reacción humana, cada fallo en la preparación para la recuperación se vuelve más costoso y más evidente.

Indicadores de recuperación que conviene comunicar

Si tus informes al consejo de administración incluyen la detección pero no la recuperación, este es el momento adecuado para cambiar eso. Se trata de indicadores que un CISO puede presentar con el mismo rigor que los de detección, y que dan un giro al debate.

Tiempo de recuperación comprobado. No el RTO documentado. El tiempo real medido durante un ejercicio de recuperación basado en un escenario realista de violación de la seguridad. Indique el número y la fecha de la última prueba realizada.

Índice de supervivencia de las copias de seguridad. Porcentaje de repositorios de copias de seguridad que cumplen los tres criterios: inmutables, segmentados y validados mediante una restauración completa. Una cifra única que el consejo de administración puede supervisar a lo largo del tiempo.

Cobertura de dependencias de nivel 0. Porcentaje de aplicaciones críticas con cadenas de dependencias totalmente mapeadas y secuencias de recuperación documentadas. Esto indica en qué medida la recuperación está planificada frente a la improvisada.

Tiempo de reconstrucción de identidades. Tiempo que se tarda en reconstruir Active Directory partiendo de un estado limpio. Si este valor no se ha comprobado, indíquelo como «sin comprobar».

Qué hacer en los próximos 90 días

No es necesario resolver todas las cuestiones relacionadas con la preparación para la recuperación de una sola vez, pero la ventana de oportunidad que plantea Mythos es real. En estos momentos, la atención de los directivos se centra en las amenazas relacionadas con la IA. Nunca será más fácil convencer a la dirección de la necesidad de invertir en recuperación que en el próximo trimestre.

Comprueba la resistencia de las copias de seguridad. Comprueba si las copias de seguridad resisten un ataque intencionado. Comprueba la inmutabilidad, la segmentación y la restauración completa. Si no puedes hacerlo internamente con total confianza, recurre a una empresa especializada en la recuperación tras ataques de ransomware que se dedique a ello profesionalmente.

Identifica las cadenas de dependencia que rigen la secuencia de recuperación. Identifica los sistemas de nivel 0. Documenta qué aplicaciones dependen de qué infraestructura. Elabora secuencias de recuperación basadas en relaciones reales, no en suposiciones. Si tu entorno es lo suficientemente complejo, esto requiere herramientas que correlacionen los datos de telemetría en tiempo real de toda tu infraestructura, no una hoja de cálculo manual que quede obsoleta antes incluso de que llegues a darle al botón de guardar.

Consigue una cifra de recuperación contrastada. Realiza un simulacro de recuperación partiendo de un escenario en el que se contemple lo peor: identidades comprometidas, copias de seguridad atacadas y comunicaciones interrumpidas. Cronometra el proceso. Evalúa en qué punto el equipo se atasca. Esa evaluación se convertirá en tu punto de referencia y en la cifra que presentarás a tu junta directiva.

Informa sobre la recuperación junto con la detección. Incluye las métricas anteriores en tu próxima actualización del panel. Presenta la detección y la recuperación como las dos mitades de un mismo todo. El contraste hablará por sí solo.

Las brechas de recuperación no son riesgos estáticos que se puedan revisar cuando convenga. Son activos que se deprecian. Por cada trimestre que se espera, el entorno se vuelve más difícil de analizar, las dependencias se vuelven más complejas y la curva de capacidad del adversario se aleja cada vez más de la capacidad de recuperación.

Los CISO han dedicado años a ganarse un lugar en la mesa de decisiones demostrando que podían reducir los riesgos. La próxima década se caracterizará por la necesidad de demostrar que se pueden mantener las operaciones a pesar de una brecha de seguridad. Se trata de competencias diferentes, inversiones diferentes y conversaciones diferentes con la dirección. Las organizaciones que se den cuenta de esto pronto se recuperarán. Las que no lo hagan pasarán semanas aprendiendo lecciones que podrían haber aprendido en tiempos de calma.

Empieza con una evaluación de la resiliencia

¿Resistirán tus copias de seguridad el ataque de un pirata informático decidido? La evaluación de resiliencia de Fenix24 pone a prueba tu entorno antes de que un incidente lo haga por ti.

La evaluación de la resiliencia se basa en Argos99, nuestra plataforma de resiliencia de nivel empresarial, que correlaciona los datos de telemetría en tiempo real de toda su infraestructura para identificar cada activo, dependencia y deficiencia. Esto significa que la evaluación de la resiliencia de Fenix24 analiza la cobertura de las copias de seguridad a nivel de aplicación, y no solo el estado de las tareas. Identifica qué depende de qué y genera secuencias de recuperación a partir de esas relaciones. Todo lo que evaluamos se basa en lo que hemos aprendido de cientos de recuperaciones tras incidentes reales.

Olvídate de las auditorías basadas en listas de verificación. A menudo están diseñadas para confirmar lo que ya crees saber, no la realidad. Programa hoy mismo tu evaluación de resiliencia. Ponte en contacto con nosotros llamando al 423.305.7890 o enviando un correo electrónico a info@fenix24.com.