Sesión paralela
Protocolo Phoenix: renacer de sus cenizas tras un ciberataque
Cuando se produce un ciberataque, la recuperación puede parecer una tarea abrumadora. En esta sesión de SHIFT 2025, Commvault presenta el Protocolo Phoenix, un marco de trabajo contrastado para salir reforzado tras un ataque. Basado en una Recovery disciplinada, el aislamiento y la Readiness, el Protocolo Phoenix muestra cómo las organizaciones pueden convertir la crisis en resiliencia.
Puntos Clave
- Recovery es una oportunidad para reconstruir. La recuperación
cibernética no consiste únicamente en restaurar los sistemas, sino que es una oportunidad para reconstruir de forma más sólida e inteligente. - Cuatro pilares definen el Protocolo Phoenix:
Commvault AirGap, un entorno de recuperación aislado, un plan de recuperación cibernética y pruebas de caos. - La preparación evita los fallos: una Recovery
sin práctica previa conduce a errores, descoordinación e interrupciones prolongadas. - La «TI en la sombra» aumenta el riesgo: las acciones de restauración
descoordinadas durante las crisis pueden reintroducir malware y prolongar el tiempo de inactividad. - Cyber Recovery ≠ Disaster Recovery
Traditional disaster recovery fails during cyberattacks because attackers persist and return to infect the systems. - Las pruebas de caos generan confianza:
practicar en situaciones de estrés ayuda a fortalecer a los equipos y a mejorar los resultados cuando se producen ataques reales.
Acerca de este vídeo
Recuperarse de un ciberataque es un reto, pero también supone una oportunidad única para que las organizaciones se reconstruyan con mayor resiliencia. Este debate de SHIFT 2025 presenta el Protocolo Phoenix: el marco estratégico de Commvault diseñado para ayudar a las empresas a salir fortalecidas tras una interrupción a través de cuatro pilares esenciales: Commvault AirGap, un entorno de recuperación aislado, un plan de recuperación cibernética y pruebas de caos continuas.
Por qué la Recovery cibernética es diferente Los
ciberataques son deliberados y adaptativos. A diferencia de lo que ocurre con los desastres naturales, los atacantes intentan activamente volver a acceder a los sistemas, lo que hace que las restauraciones apresuradas o no verificadas resulten peligrosas.
Un tema clave es la falta de preparación para la recuperación cibernética en todo el sector. Muchas organizaciones no planifican ni practican los procesos de Recovery hasta que se produce una crisis, lo que da lugar a confusión, acciones descoordinadas y decisiones de TI en la sombra. Estos esfuerzos descoordinados —como las restauraciones de sistemas bienintencionadas— pueden reintroducir inadvertidamente malware y prolongar el tiempo de inactividad.
Presentamos el Protocolo Phoenix
El Protocolo Phoenix es el marco estructurado de Recovery tras un ataque de Commvault, diseñado para ayudar a las organizaciones a salir fortalecidas gracias a cuatro pilares esenciales: Commvault AirGap, un entorno de Recovery aislado, un plan de Recovery cibernética y pruebas continuas de caos.
El coste de no estar preparado
Muchas organizaciones posponen la planificación de la Recovery hasta que se produce un incidente. Esto da lugar a confusión, decisiones aisladas y acciones bienintencionadas que agravan los daños.
Recovery metódica que prioriza la seguridad
El Protocolo Phoenix hace hincapié en la contención, la verificación y la coordinación, dando prioridad a la seguridad frente a la rapidez para permitir una restauración limpia.
La práctica fomenta la resiliencia Las pruebas de
caos en condiciones realistas ponen de manifiesto los puntos débiles, validan las hipótesis y preparan a los equipos para recuperarse con confianza.
Commvault AirGap
Almacenamiento basado en la nube y aislado físicamente para ayudar a reducir el riesgo y proteger las copias de seguridad críticas.
Backup & Recovery
Backup and Recovery completas para cargas de trabajo locales, en la nube y en el perímetro.
Cleanroom
Entornos de recuperación aislados que permiten una restauración limpia y validada.
Preguntas frecuentes
¿En qué se diferencia la recuperación tras un ciberataque de la recuperación ante desastres tradicional?
Los incidentes cibernéticos implican adversarios activos e infecciones ocultas. Recovery debe realizarse con cautela y verificarse para evitar una reinfección.
¿Qué es el Protocolo Phoenix?
Es el marco de recuperación tras un ataque de Commvault, basado en Commvault AirGap, la recuperación aislada, un plan de recuperación cibernética y las pruebas de caos.
¿Por qué las organizaciones tienen dificultades con la recuperación cibernética?
Muchas no planifican ni practican Recovery. Los equipos que no están preparados suelen tomar medidas fragmentadas que propagan la infección y retrasan la restauración.
¿Qué papel desempeñan las pruebas de caos?
Las pruebas de caos simulan la presión del mundo real, lo que ayuda a los equipos a validar los procesos y mejorar la coordinación antes de que se produzca un incidente real.
¿Cómo mejoran la Recovery Commvault AirGap y el aislamiento?
Ayudan a evitar la manipulación indebida y permiten analizar y restaurar de forma segura los sistemas no infectados sin riesgo de reinfección.
Transcripción
Ver Transcripción
Por favor, ve el vídeo aquí para consultar la transcripción con marcas de tiempo
Bienvenidos a la sesión de hoy del podcast SHIFT, «El Protocolo Fénix: cómo resurgir de las cenizas
tras un ciberataque».
Soy Chris Dirado y hoy me acompaña Michael Stempf.
Michael, gracias por acompañarme hoy; tengo muchas ganas de que comencemos nuestra conversación.
Gracias, Chris.
Cuando se produce un ciberataque, Recovery puede parecer abrumadora, pero también es un momento para reconstruirse
con más fuerza.
En esta conversación, exploraremos el Protocolo Fénix y cómo nuestros cuatro pilares aquí en
Commvault pueden ayudarte a resurgir de las cenizas.
AirGap Protect, el entorno de Recovery aislado, un plan de Recovery cibernético y, lo más
importante, las pruebas para situaciones de caos.
Juntos analizaremos cómo las organizaciones pueden transformar esta crisis en una
oportunidad de renovación y cómo salir airosas de un ataque.
Entonces, Michael, ¿cuáles son algunos de los errores más comunes que cometen las organizaciones al recuperarse
de un ciberataque?
Esa es una pregunta con trampa.
El problema más habitual que tiene la gente con la Recovery es que no la planifica hasta que
tiene que llevarla a cabo.
Hay que estar preparado, ¿no?
A ese gran suceso nos gusta llamarlo «bang», y la gente piensa en lo que ocurre justo después
de
que se produzca.
Pero si no lo has planificado, si no has ensayado, si no has desarrollado esa fortaleza mental
que se consigue repitiéndolo una y otra vez y trabajando con tus equipos,
para crear una experiencia de trabajo en equipo en torno a ello, no vas a estar preparado.
A posteriori, lo que hemos visto muchas veces es que la gente, sinceramente, intenta dar lo mejor de sí misma.
Te encontrarás con un administrador de Windows que solo quiere ayudar y volver a poner en
marcha sus servidores, así que se saltará las normas, recurrirá a la «TI en la sombra» y pondrá en marcha sus propios
sistemas.
Y hemos visto una y otra vez que, cuando hacen este tipo de cosas, lo único
que consiguen es
volver a infectar una nueva zona en la que el atacante no había entrado,
y entonces hay que volver a ocuparse de ello.
Así que, al intentar hacer el mejor trabajo posible, lo que haces es perpetuar el problema.
Y sin esa práctica, sin ponerse a prueba en el caos del que hablabas,
no van a comprender el verdadero nivel de complejidad y sofisticación con el que estos
delincuentes lanzan contra nosotros.
Y ahí planteas una cuestión muy acertada sobre la gente que solo intenta ayudar, pero
a veces…
ya sabes, se precipitan, ¿verdad?
Iniciar las recuperaciones antes de que estemos realmente preparados para ello.
Y sé, por mi experiencia y también por la tuya, que nos hemos enfrentado a muchos de estos escenarios de Recovery
.
A veces trabajas 60, 70 u 80 horas a la semana.
El peor momento para hacer algo que no va a dar buenos resultados es cuando ya
estás al límite y a toda máquina, ¿verdad?
Así que, para mi siguiente pregunta, quiero hablar de algunas de las falacias que…
ya sabes, en las que creemos que estamos a salvo, pero en realidad, ya sabes, no son más
que
falacias y, al final, no nos ayudan en absoluto.
¿Podrías darme algunos ejemplos de esas falacias?
Sí, creo que la primera y más importante es que todo el mundo tiene un plan de recuperación ante desastres.
Los tienen desde hace años.
Los han probado durante años.
Y un ciberataque no es más que otro desastre, o eso creen.
El problema es que la recuperación ante desastres se basa en la rapidez y la eficiencia.
Exacto.
Ya sea un desastre natural,
un tornado, un huracán, lo que sea.
Y no hay ninguna intención maliciosa.
Y cuando te adentras en el ámbito cibernético, la rapidez y la eficiencia simplemente significan que vas a volver a infectar
el entorno.
Hay que ir despacio, hay que ser metódico, hay que tener en cuenta esa malicia,
que
el malhechor está ahí dentro.
Por eso, utilizar un plan diseñado específicamente para que vuelvas a estar operativo lo
antes posible solo va a causar problemas.
Así que hay que reducir el ritmo, tomarse un respiro.
Tienes que contar con un plan de recuperación cibernética, que en esencia puede incluir gran parte de lo que abarca la
recuperación ante desastres, pero el objetivo final es cómo volver a estar limpio, no cómo volver
lo más rápido posible.
Así que ese es realmente el aspecto principal.
Pero hay muchos otros aspectos que van de la mano de eso.
Ya sabes, ante todo, he visto cómo un
ciberataque puede destruir prácticamente todo lo imaginable.
Y uno de los factores que lo preceden es que hoy en día todo el mundo tiene
todo vinculado a un sistema de gestión de identidades, como Active Directory.
Las últimas estadísticas de Active Directory indican que está presente en el 98 % de todas las empresas y que es objeto de ataque en
el 92 % de todos los ciberataques.
Es lógico, ¿no?
Una vez que estás en Active Directory, puedes acceder a cualquier sitio.
Es la llave del reino.
Así que una de las cosas que siempre recomiendo es, eh, retirar tu última línea de defensa, sacar
tu sistema de protección de datos de Active Directory,
porque una de las tácticas habituales de los ciberdelincuentes —que saben que, si tu sistema de protección
de datos resiste el ataque, es probable que no acabes pagando—
Así es como te libras de pagar.
Por supuesto.
Una de las cosas que recomendamos es sacar tu sistema de protección de datos de Active Directory, convertirlo
en un sistema independiente, separarlo y aislarlo tanto como sea posible.
De este modo, por mucho que se destruya tu empresa, eso seguirá sobreviviendo.
Por cierto, Michael ha hecho una buena
buena observación sobre un plan de recuperación cibernética.
En algunas de las sesiones que he impartido, me he dado cuenta de que mucha gente no tenía planes de recuperación
cibernética.
Pues bien, en Commvault te lo facilitamos.
Si entráis en nuestra plataforma de Readiness y buscáis «plan de recuperación cibernética», podéis descargar
nuestra plantilla y adaptarla a vuestras necesidades.
Y, como ha dicho Michael, algunos de los elementos ya estarán en vuestro plan de recuperación ante desastres.
No dudéis en tomar prestados esos elementos, ¿verdad?
Copia y pega.
Pero contar con un plan de Recovery cibernético es realmente lo que te va a ayudar a salir del apuro una vez que te encuentres
en una de estas situaciones.
Michael, ¿cómo han cambiado las expectativas de Recovery, pasando de simplemente recuperar los datos a recuperar nuestro
negocio?
Buena pregunta.
Verás, la mayoría de la gente planifica restauraciones de tipo «una Z» o «dos Z».
Tengo un par de archivos aquí.
Tengo un servidor aquí.
Y eso se puede planificar, ¿verdad?
Es muy matemático, ¿verdad?
Para una recuperación ante desastres (DR).
Tengo una planta.
Tengo un servidor.
Tengo un edificio.
Tengo que saber cuántos datos hay, de qué ancho de banda dispongo hasta la siguiente
ubicación, una ubicación geográficamente dispersa, y puedo simular escenarios todo el día con eso.
El problema con un ciberataque es que no sé cuál es su alcance, ¿verdad?
¿A cuántos servidores han afectado en esta organización?
¿A cuántas ubicaciones han afectado?
Tuve un cliente que sufrió un ataque.
Tenían 99 sedes en todo el mundo, y el atacante las destruyó todas.
Así que todas las copias de los datos que tenían en cualquier lugar quedaron completamente destruidas.
Analizarlo, diseñarlo, ponerlo en práctica y ensayarlo son realmente algunas de
las cosas más importantes aquí, así que tienes que asegurarte de tratarlo de forma diferente
que lo veas de otra manera y que los resultados siempre vayan a ser distintos.
Y ahí planteas una cuestión realmente importante.
Hay tres tipos distintos de operaciones de Recovery que planificamos correctamente:
Recuperación operativa, recuperación ante desastres y recuperación cibernética.
¿Podrías explicarnos un poco más sobre cada una de ellas, en qué se diferencian y cómo
impide realmente que los clientes no puedan recuperarse ante un incidente cibernético?
Claro.
Recovery operativa es la típica: si borras un archivo, tienes una copia local desde la que
puedes restaurarlo; es rapidísimo, fácil de hacer y, en la mayoría de los casos, está automatizado; simplemente tienes que
y…
Iba a decir que, aquí en Commvault, todos tenemos la posibilidad de hacer nuestras propias recuperaciones en
nuestros portátiles.
Estoy seguro de que en la mayoría de las organizaciones es sencillo, ¿verdad?
Es un procedimiento sencillo.
Por supuesto.
Recovery ante desastres, en el caso de los desastres naturales,
y es muy avanzada.
Llevamos más de 30 años haciéndolo, y lo probamos trimestralmente en la mayoría de los lugares.
De hecho, lo hacíamos tan a menudo que la gente se volvió un poco perezosa con la recuperación ante desastres.
Ya casi ni la prueban.
Lo que suelen hacer ahora es cambiar su centro de datos de una sede a otra
cada seis meses y decir: «Oye, estamos en producción».
Es una buena prueba.
Pero luego, con lo último, lo de la ciberseguridad, se necesitan algunas cosas específicas.
Una, y creo que la más importante, es una copia terciaria de los datos.
Una tercera copia de los datos que esté alojada en la infraestructura de un tercero porque, ya sabes, los
atacantes tendrán acceso a AD, tendrán todo tu entorno,
y tendrán todas tus credenciales en la nube.
Así que tener solo esa segunda copia de los datos —que normalmente distribuirías
geográficamente— no es protección suficiente.
Por eso hay que asegurarse de que esté protegida por la infraestructura de un tercero, de que sea
inmutable e indeleble.
«Indelible» incorpora esa gobernanza para garantizar que
nadie, ni siquiera con credenciales de alto nivel que pudieran haber obtenido de AD, pueda modificar
o eliminar esos datos.
Esos son los datos que nos sacarán del apuro cuando suframos un ataque.
Sabemos que estarán ahí cuando los necesitemos, porque, como has dicho, no se pueden borrar, no se
pueden modificar y deben cumplir unos requisitos estrictos.
Y para que un atacante pudiera hacerse con ellos, no solo tendría que violar la seguridad de vuestra
organización, sino también la nuestra, ¿verdad?
Así que, en realidad, se trata de un ataque en dos frentes que tendrían que llevar a cabo.
Así que, con eso…
sabemos que podemos disponer de una copia segura de los datos.
¿Dónde deberíamos restaurar esos datos en caso de un ciberataque?
Ese es el punto en el que nadie piensa nunca, ¿verdad?
Aproximadamente el 17 % de todos los ataques son ataques destructivos, en los que acceden al firmware y
a la BIOS de los servidores, y no es posible recuperarlos.
Pero eso está en el plan de todo el mundo.
Voy a volver exactamente al punto de partida.
Y hoy en día, aunque ese 17 % sea una cifra bastante pequeña, la mayoría de los CISO
como no sabes si se trató de un ataque destructivo, piensan: «Tengo que dar por hecho que
lo
es».
Así que la mayoría de las empresas no cuentan con un plan en el que tengan 50 servidores preparados en su muelle,
listos para entrar en funcionamiento.
Por eso, en el entorno actual, es imprescindible contar con un entorno de Recovery aislado.
En primer lugar, es un lugar seguro al que puedo recuperar los datos; y, en segundo lugar, es un lugar desde el que puedo pasar
a producción y en el que sé que el atacante no está presente.
Así pues, como una de esas áreas clave de las que hablabas antes,
un entorno de recuperación aislado —al que llamamos «sala limpia»— es esencial para la
ciberresiliencia
.
Claro, así que ahora tenemos una buena solución: sabemos que tenemos copias de nuestros datos, a salvo y seguras, y ahora
tenemos un lugar donde podemos almacenar esos datos y, tal y como has señalado antes, podemos depurar
y depurar esos datos antes de trasladarlos al entorno de producción.
Y una de las características de Commvault que, en mi opinión, no se destaca lo suficiente es nuestra
portabilidad «any-to-any», ¿verdad?
Porque, como has dicho, puede que sufras un ataque destructivo en tus propias instalaciones; pues bien, ahora tienes que
cambiar de
estrategia, ¿verdad?
Tienes que…
tienes que irte a otro sitio; ¿cuánto tiempo se tarda en conseguir nuevo hardware?
¿Seis semanas, tal vez?
No puedes quedarte seis semanas sin servidores de producción.
Puedes redirigir tus cargas de trabajo a tu proveedor de nube preferido o a un hipervisor diferente, y
eso realmente te da la flexibilidad necesaria para recuperarte tras uno de estos ataques.
De hecho, uno de los aspectos clave de los que nunca se habla y que distingue
a Commvault de sus competidores es que llevamos años ofreciendo soluciones «de cualquier tipo a cualquier tipo».
Así que si quisieras…
tuvieras un entorno VMware local y quisieras trasladarlo a un entorno AWS EC2, todo
se hace de forma automática.
Ocurre durante la restauración, no tengo que preocuparme de nada.
Y la variedad de opciones «de cualquier plataforma a cualquier otra» que ofrecemos, de una plataforma a
otra, es absolutamente increíble y eclipsa por completo a cualquier otro en el sector.
Sí, realmente ofrecemos a nuestros clientes todas las opciones que podrían desear, ¿verdad?, en lo
que a eso se refiere.
Por supuesto.
Muy bien, cambiemos de tema.
¿Qué tipo de retos estás viendo con más frecuencia ahora mismo con estos ciberataques?
Lo principal es la falta de preparación.
Se trata de afrontarlo como si fuera un desastre.
Cuando se habla de Recovery ante desastres y de recuperarse de ello, lo normal es contar
con
un administrador de copias de seguridad, ¿verdad?
Y a esta persona, en ese caso,
yo siempre los llamo así, se les considera una especie de dios, ¿verdad?
Cuando se llega a la fase de Recovery ante desastres, es como si dijeras: «No te acerques a esta persona,
no te acerques a ella, solo dale de comer y beber de vez en cuando, y déjala en paz»,
porque lleva toda la vida elaborando el plan.
Y toda la responsabilidad recaía sobre ella.
El problema es que esa persona casi no tiene ninguna responsabilidad en un ciberataque.
No puede ponerse a recuperar datos sin más, porque provocaría una fase de reinfección.
Tienes que colaborar con tus equipos de seguridad, tus equipos de TI, tu departamento jurídico y tus equipos de comunicación;
todas estas personas tienen que trabajar juntas y nunca lo han hecho antes.
Y siempre me gusta bromear diciendo que probablemente la última vez que tu equipo de seguridad y tu equipo
de TI se reunieron fue cuando jugaron uno contra otro en algún partido de béisbol en un
evento corporativo.
Siempre están uno contra otro, nunca en el mismo equipo.
Pero cuando se produce un incidente cibernético, si yo soy el responsable de respaldo, yo…
no tengo autoridad para llevar a cabo una Recovery hasta que alguien del equipo de seguridad me diga que
lo haga.
Y el personal de seguridad no puede hacer lo que tiene que hacer hasta que alguien del equipo de TI se
encargue
de ello.
Así que se trata de esta idea de controles y contrapesos, que es un concepto totalmente ajeno a cualquier Recovery
antes de los incidentes cibernéticos.
Sí, y sabes, lo que me hace gracia es que… piensa en la última vez que interactuaste
con un administrador de copias de seguridad, ¿verdad?
Probablemente fue algo así como: «Oye, he perdido un correo electrónico o una hoja de cálculo», y ¿qué hicieron?
Lo restauró en cuestión de minutos, ¿verdad?
Ahora bien, como tú dices, ya no pueden hacerlo.
No pueden hacer eso porque no sabes qué se ha visto afectado.
No sabes si han afectado a una docena de servidores, si han afectado a toda la granja de ESX, y no puedes
simplemente empezar a restaurar cosas porque eso solo te devolverá al punto de partida.
Realmente tiene que ser un esfuerzo de equipo, ¿verdad?
Al final, todo el mundo tiene que unirse, trabajar en equipo y colaborar para que la organización
vuelva a funcionar.
De acuerdo.
Entonces, ¿cuáles son algunas de las lecciones más importantes que han aprendido las organizaciones tras sufrir un
ciberataque?
Las lecciones aprendidas varían.
Hay de todo.
Creo que lo más importante —y esto suele surgir tras el segundo ataque, ya
que
es muy habitual sufrir hasta cuatro ataques al año, más o menos— es que no se puede planificar realmente.
No vas a poder establecer escenarios que se desarrollen exactamente como tú
los imaginas cuando se produzca ese incidente cibernético.
Hay muchísimas variables diferentes.
La cuestión es que, en Recovery, es muy fácil planificar para un tornado.
Un tornado probablemente va a derribar un edificio.
Una inundación puede arrasar…
quizá las plantas inferiores de un edificio, pero se puede planificar, se puede ensayar; puedo entrar y hacerlo
.
En el ámbito cibernético, hay muchísimas formas diferentes en las que pueden atacar.
Hay tantas formas diferentes en las que pueden colarse, tantas formas en las que pueden destruir información.
Vaya, hoy en día ya ni siquiera se trata tanto del ransomware, ¿verdad?
Hay ataques que se producen simplemente porque alguien quiere acabar con un competidor, o porque un
gobierno quiere acabar con otro gobierno.
Se trata simplemente de pura malicia, sin ningún beneficio a cambio, más allá de destruir
al enemigo.
Es difícil prepararse para eso.
Claro.
Así que lo que tenemos que hacer es aplicar a fondo esa teoría del caos cuando realizamos nuestras pruebas.
Una de las cosas que siempre me gusta hacer es que, cada vez que me enfrento a estas pruebas, siempre tienen
una lista predefinida de lo que se ha atacado, ¿verdad?
Siempre saben exactamente qué servidores se van a atacar y, lo bueno es que siempre cuentan con todos los
responsables de esos servidores en las reuniones con nosotros.
Por supuesto.
Y una de las cosas que siempre me gusta hacer es escribir los nombres de los servidores en el
reverso de unas cartas,
y las lanzo contra la pared; las que caen boca arriba son las
que acaban de recibir un ataque.
Así que esa es una forma estupenda de aplicar aquí la metodología del caos para poder realizar las pruebas.
Y una vez que hayas realizado pruebas de tantas formas caóticas diferentes, no voy a decir que estés
preparado para ese ataque, pero sí que tienes una idea y comprendes cuál será el impacto
que tendrá y, a continuación, cómo puedes recuperarte mejor.
Sí, y conoces tu punto de inflexión, ¿verdad?
Oye, si sé que si ocurre X, voy a cambiar a Y, ¿verdad?
Si sé que si hago Y y no funciona, voy a cambiar a Z.
Y creo que no se puede estar preparado para todos estos escenarios, pero cuantos más tengas
preparados para cuando esto ocurra de verdad, es esa memoria muscular, ¿verdad?
Es como decir: «Oye, sé que vamos a poder hacerlo porque me he preparado para ello, me he
preparado para todas estas situaciones».
Sé que hace unos años el FBI solía decir: «Oye, si te ves afectado por un ciberataque,
tienes que seguir esta serie de procedimientos».
Y luego, un año más tarde, lo cambiaron por:
«cuando sufras un ciberataque, tienes que hacer esto».
Y este año dicen: «Dada la frecuencia con la que vas a sufrir ciberataques
, tienes que estar listo, tienes que estar preparado».
¿Podrías hablar un poco más sobre en qué consiste esa preparación?
Sí, pues ocurre con frecuencia, y creo que lo más importante en materia de preparación es cambiar
de mentalidad.
Y la mentalidad no cambia en función de si ocurrirá, cuándo o con qué frecuencia, sino que, en realidad, hay que
dar por hecho que ya has sufrido una brecha de seguridad.
Ya sabes, siempre nos gusta bromear diciendo que hay dos tipos de empresas en este mundo.
Las que saben que han sufrido una filtración y las que no saben que la han sufrido.
Y aunque eso no es del todo cierto —seamos sinceros—, el año pasado en Estados Unidos solo el 60 % de las empresas sufrió
una filtración, ¿verdad?
Así que tenías una posibilidad, un 40 % de posibilidades de que no te hubieran hackeado, pero eso fue un
año.
Sí, suerte.
Pero si adoptas la mentalidad de que das por hecho que ha habido una filtración,
cuando vaya a trabajar mañana, tomaré decisiones diferentes.
Voy a ver las cosas de otra manera, voy a analizarlas de otra forma y, con suerte, voy a
poner en marcha esa experiencia de trabajo en equipo, involucrando al departamento de TI y al departamento jurídico, y
deberemos debatir temas que normalmente no habría tratado con ellos.
Así que, ya sabes, es curioso, tú mismo dijiste que el 60 % de las organizaciones han sufrido una filtración.
La cuestión es que el otro día leí una estadística que indicaba que, en 2025, se producirá un ciberataque cada
14 segundos.
Esa cifra me parece una locura.
Otra cifra realmente asombrosa es que se prevé que la ciberdelincuencia alcance los 10,5
billones de dólares este año.
Así que, aunque solo haya sido el 60 % de las organizaciones de Estados Unidos, no se llega
a los 10 billones de dólares sin atacar a todo el mundo, ¿verdad?
No es que solo se dirijan al 1 % de las grandes empresas, ¿verdad?
Se dirigen a todo el mundo.
Para ponerlo en perspectiva: 10 billones de dólares; si lo mirás desde el punto de vista del PIB de
los países de todo el mundo, sería el tercer país más grande del mundo.
Es increíble.
El cibercrimen, el tercer país más grande del mundo.
Es increíble.
Vale, creo que es hora de cambiar de tema, ¿no?
Hemos hablado mucho de lo malo, de todas las dificultades.
Hablemos de cómo podemos acortar este plazo de 24 días.
Hablemos de lo que pueden hacer los clientes no solo para recuperarse de estos ataques, sino para responder
e incluso salir reforzados.
A esto lo llamamos nuestros cuatro pilares.
Es muy importante.
Así que, ante todo, hay que tener una copia terciaria de los datos en la infraestructura de
un tercero.
Así, dispondrás de una copia limpia, inmutable e indeleble.
Hay que disponer de un lugar donde restaurarlos, que es un entorno de Recovery aislado.
Al nuestro lo llamamos «sala limpia».
Eso te permite, eh, realizar pruebas, que es lo primero y más importante.
No vamos a reducir los 24 días, ni siquiera aplicando estos métodos, si no realizamos las
pruebas con ellos.
Así que tienes que disponer de un lugar donde realizar las pruebas, porque no puedes interrumpir la producción.
Allí también se pueden realizar análisis forenses.
Así que, muchas veces, digamos que ni siquiera estás sufriendo un ataque, pero incorporas una nueva
herramienta de ciberseguridad y quieres probarla en tu organización.
No quieres limitarte a soltar algún malware en tu organización y ver cómo lo detecta.
Y tampoco quieres hacerlo en un entorno estéril que no se parezca en nada
a tu entorno de producción.
Así que, con Commvault Cleanroom, puedo recuperar mi entorno en una ubicación segura,
y allí puedo soltar un malware para comprobar cómo funciona esa solución de ciberseguridad.
Por otro lado, si sufres un ataque —como me ocurrió una vez, que no fue un
ataque destructivo—, una vez que recibimos el visto bueno, pudimos seguir adelante y recuperar los datos, pero el
intervino y nos dijo: «No pueden recuperar los datos ahora mismo».
Nunca habíamos visto a este atacante ni este tipo de ataque.
Así que querían hacer su propio análisis forense.
Rápidamente, ¿cuál era su SLA en ese caso?
Sí, se pasaron de la…
Sí, claro, ¿verdad?
No hay SLA cuando lo hace el Gobierno.
No, en absoluto.
A nosotros nos llevó dos semanas.
Dos semanas para que el Gobierno hiciera su investigación.
Así que, ¿no habría sido estupendo si hubiera tenido Commvault Cleanroom y hubiera podido restaurar
esas máquinas en ese entorno y decir: «Oye, tómate todo el tiempo que quieras»?
Adelante, haced vuestras evaluaciones, aclarad vuestras dudas.
Nosotros vamos a volver al trabajo».
Sí, genial.
Genial de verdad.
Así que, tengo datos en buen estado.
Tengo un lugar seguro al que puedo llevar los datos.
Lo siguiente y más importante es el plan de recuperación cibernética, del que ya hemos hablado, lo cual
es estupendo.
Va a detallarlo todo, pero hay algunas cosas que deben incluirse en ese plan de Recovery cibernética
y que,
de forma orgánica, son muy difíciles de conseguir.
Se trata, por tanto, de un análisis de todo el mapeo de tus aplicaciones.
Si solo estoy restaurando un par de archivos de un servidor de archivos, realmente no me importa.
Si estoy poniendo en marcha, digamos, Epic para un entorno sanitario, y tiene 32
servidores diferentes que interactúan entre sí, y
tengo que recuperarlos todos.
Tengo que ponerlos todos en un estado coherente.
Y espero que hayáis realizado un análisis para averiguarlo, para hacer la asignación de aplicaciones.
Hay algunas herramientas que te ayudan a hacerlo, pero, para ser sincero, es un proceso muy complicado
.
Sí, ¿cómo averiguas que 32 servidores alimentan a una máquina, verdad?
Y la mayoría de la gente piensa: «Bueno, lo sabemos porque vamos a recuperar nuestros servidores de nivel uno
».
Pues bien, el problema es que un servidor de nivel uno solo funciona si tienes un montón de servidores de nivel tres
y nivel cuatro que, de hecho, le están enviando los datos
que necesita.
Y la única forma de hacerlo es con este cuarto paso, que consiste en realizar pruebas de caos.
Tengo que entrar en la sala limpia.
Tengo que asegurarme de que estoy haciendo Recuperaciones, aleatorizarlas, ver qué pasa, ver qué funciona
y qué no funciona tras esa aleatorización.
De acuerdo, quizá solo se hayan visto afectadas 32 máquinas, pero voy a tener que recuperar 142
debido a todas las dependencias que hay.
Esas son realmente las cuatro cosas: el aislamiento físico, la sala limpia o el entorno de Recovery
aislado,
un plan de recuperación cibernética y, por último, probarlo todo, porque un plan de recuperación cibernética no es más que un
trozo de papel hasta que realmente lo pones a prueba.
Totalmente de acuerdo.
No es más que un documento hasta que no lo pones a prueba.
Y algunas de las pruebas que yo recomendaría son que los clientes realicen, ya sabes, simulacros de mesa
, ya sabes, reunirse en la sala de juntas y hablar de qué haríamos si nos atacara un ransomware: ¿qué
vamos a hacer en primer, segundo y tercer lugar?
¿Cuándo vamos a poner en marcha nuestro plan de recuperación cibernética?
Pero yo iría un paso más allá, ¿no?
Lo que realmente hay que hacer es llevar a cabo una recuperación cibernética práctica.
Por supuesto.
Oye, tengo esto que se llama AirGap Protect, tengo esto que se llama Cleanroom; ahora
vamos a ponerlo a prueba, porque la prueba está en los resultados, ¿no?
Asegurémonos de que podemos recuperar estas cargas de trabajo desde esta copia terciaria de datos en este
Cleanroom, porque esa es la verdadera prueba, ¿no?
Puedo poner en marcha mi empresa.
Y eso me lleva a mi siguiente pregunta: ¿cómo determinan las empresas siquiera qué van
a poner en marcha en una segunda y tercera fase?
He oído hablar mucho de este término, «viabilidad mínima».
Supongo que eso varía según cada organización.
¿Cómo encaja eso con estos cuatro pilares?
Es diferente para cada organización, ¿verdad?, dependiendo del sector en el que te
muevas.
Y la única forma de saberlo es mediante pruebas.
Sin eso, es imposible saberlo.
Muchas veces la gente cree que entiende qué hay que hacer, dónde y cómo.
Y sin esas pruebas, que llevamos años realizando para la recuperación ante desastres, ya que contamos con el
proceso.
Simplemente no lo hemos aplicado.
Es decir, esto es lo más alucinante.
Durante años, 30 años, hemos realizado pruebas trimestrales de recuperación ante desastres y planes de recuperación ante desastres
, y,
sin embargo, menos del 1 % de todas las empresas que han existido jamás han declarado un
desastre y, como hemos dicho antes, el 60 % de todas las empresas de Estados Unidos sufrieron una filtración de datos el año
pasado y nadie está realizando pruebas para ello.
Nadie realiza pruebas porque es algo avanzado, ¿verdad?
Se necesita un doctorado para entender la diferencia entre la recuperación cibernética y la recuperación ante desastres, algo que hoy en día cualquiera puede
hacer.
Claro.
Sí, y es casi como: «Oye, ¿cómo voy a saber siquiera qué estoy probando en un caso de Recovery
cibernético?», ¿verdad?
Y creo que, ya sabes, nuestros clientes aquí en Commvault tienen mucha suerte.
Ahora hemos lanzado este nuevo servicio, el servicio Guardian, y, oye, entendemos que esto
no ocurre de la noche a la mañana, ¿verdad?
Si quisiéramos ser ciberresilientes mañana, lo seríamos, pero no es tan fácil,
¿verdad?
Es un proceso.
Lleva tiempo.
En muchos casos, lo más probable es que necesites ayuda.
Y creo que este nuevo servicio tiene como objetivo ayudar realmente a los clientes
a dar ese siguiente paso en su camino hacia la ciberresiliencia.
Bueno, y a través de nuestro programa «Readiness Verse», dado que mucha gente no sabe cómo llevar a cabo un
ejercicio de simulación adecuado, ahora contamos con un programa tanto para directivos como para técnicos de
ejercicio de simulación sobre incidentes cibernéticos.
Pero, como has dicho, eso es solo el primer paso.
Ahora hay que ponerlo en práctica de verdad.
En el ejército, lo llamábamos el ciclo OODA: Observar, Orientar, Decidir y Actuar.
Y lo que hace es que se trata de un ciclo repetitivo por el que pasas,
en la que constantemente se prueba algo, se evalúa, se modifica y se vuelve a probar.
Y así estás más preparado cuando ocurre algo de verdad.
Bueno, has pasado por tantos ciclos de pruebas, cambios y formas de hacer las cosas
que, para ti, es casi como otra prueba más.
Claro.
Y así es como realmente te recuperas, ¿verdad?
Así que con estos cuatro pilares: la protección mediante espacio de aire, la sala limpia, el plan de Recovery cibernético y,
por último, las pruebas en condiciones de caos, ¿verdad?
Y nosotros…
nos ajustamos perfectamente a ellos, tal y como has dicho.
Tenemos copias seguras y protegidas de nuestros datos.
Tenemos el lugar al que se restauran nuestros datos.
Vaya, si necesitas un plan de recuperación cibernética, descárgatelo de Readiverse, como ya
he
mencionado, y adáptalo a tus necesidades.
Y por último, pero no menos importante, si necesitas ayuda en el proceso, te cubrimos las espaldas
con el Servicio Guardian.
Michael, gracias por tu tiempo hoy.
Ha sido muy esclarecedor.
Gracias, Chris.
Y con esto concluimos nuestra conversación sobre el Protocolo Phoenix y cómo los cuatro
pilares de la ciberresiliencia de Commvault ayudan realmente a los clientes a resurgir de sus cenizas tras un
ataque cibernético.