El lunes por la mañana, el director general de una empresa mediana entró a su oficina sabiendo que había un problema pero que rápidamente saldrían del problema. Habían cifrado su operación. Pedían rescate. Pero él sabía algo que, creía, lo cambiaba todo: Tenía respaldos.
Llevo años viendo esa escena. El directivo respira. Dice que no paguen, que activen el plan (aunque no haya), que avisen al consejo que todo está controlado. Lo he leído en reportes de junta con las mismas palabras: “la continuidad operativa está garantizada porque contamos con respaldos”.
Es ahí donde empieza el problema.
Respaldar es copiar datos. Recuperar es volver a operar. No es lo mismo. Y casi ninguna organización se ha tomado el trabajo de confirmar que puede hacer lo segundo.
Día uno. Los primeros servidores suben, más lento de lo esperado. Al mediodía llaman al director general: ya tienen el primer servidor crítico recuperado. Él respira.
Nadie puede conectarse.
Porque el sistema que controla los accesos a la red, el que decide quién puede entrar a qué, no está levantado. Y cuando van a buscar su respaldo, no hay.
Ese sistema, la pieza más básica, nunca había sido respaldado. No se veía como una dependencia para poder regresar a la operación.
Hay que reconstruirlo a mano. Eso no son horas. Son días.
El director general vuelve a llamar al final de la tarde. “¿Vamos bien?” Le dicen que sí. Técnicamente es cierto, mientras todavía no pueden facturar ni operar.
Día dos. El equipo forense que investiga qué pasó, trae la primera noticia. Ya saben por dónde entraron.
Por el sistema de respaldo. Un servidor viejo, sobre una plataforma que el fabricante dejó de soportar hace años. Nadie lo había migrado porque seguía respaldando procesos críticos y moverlo era caro. El atacante estuvo semanas adentro antes de activar nada. Era un Windows XP sin parches ni nada.
Desde ese servidor alcanzó a cifrar algunos respaldos antes de atacar el resto de la empresa. No todos. Los suficientes para que nadie pueda confiar en el sistema como está.
Hay que detener la restauración. Seguir alimentándola desde un sistema comprometido sería dejarle al atacante la puerta abierta. Hay que levantar uno nuevo, limpio, aislado. Eso toma días.
Y aunque estuviera limpio, no habría dónde restaurar. Los servidores de producción están todos cifrados. Están comprando equipos, pidiendo prestado, improvisando.
El director general vuelve a llamar. El tono de la respuesta ya cambió y siguen sin operar, bueno, algunas cosas a mano, poco a poco. ¿Y si el atacante exfiltra la información de nuestros clientes? No les avisemos, esperemos.
Te interesa: Ciberseguridad y métricas equivocadas: gobernar sin entender el riesgo
Día tres. Con el sistema de respaldo nuevo corriendo, empiezan a restaurar. El resultado es un bonito collage.
Algunos respaldos traen información del día anterior al ataque. Otros vienen de hace un mes, porque eran los que el atacante alcanzó a tocar y las copias previas son las únicas confiables. Otros ni abren: están cifrados, y eso se descubre al intentarlo.
Lo crítico y lo irrelevante se respaldaban con la misma frecuencia. Nadie había decidido lo contrario.
Negocio empieza a pedir fechas. Comercial pregunta desde cuándo tiene órdenes confiables. Finanzas pide los cortes contables. Operaciones, los inventarios. El equipo técnico no puede responder. Hasta que cada restauración no termina, nadie sabe qué se recuperó.
Y cuando los datos sí salen, aparece el siguiente muro. Los datos están. No hay quien los traduzca.
La aplicación que sabía leerlos era un desarrollo interno. Lo hizo alguien que ya no está en la empresa, hace más de diez años, sin documentación. Mientras el servidor original siguió encendido, nadie lo notó. Ahora hay que reconstruir la lógica desde cero, con los datos en la mano y sin el mapa. No hay respaldo del aplicativo.
Es como tener un documento en un idioma que ya nadie traduce.
Día cuatro. Alguien, con 72 horas encima, suelta una frase. “Aprovechemos para actualizar todos los sistemas operativos, ya que estamos en esto.”
Ahí, me cuentan los que estuvieron que se rompió algo.
No un servidor. El ambiente.
Pero la frase peor viene después, con la voz más baja. Alguien pregunta si los respaldos que están metiendo a la nueva infraestructura no traerán algo adentro. Si el atacante estuvo semanas en el sistema de respaldo antes del cifrado, pudo haber dejado cosas esperando.
Nadie lo puede descartar. Hay que revisar cada respaldo antes de conectarlo.
Y ahí el director general entiende que el costo del incidente ya no se mide en horas de operación. Se mide en información que la empresa va a tener que dar por perdida para no volver a abrir la puerta. Los costos de un negocio interrumpido, de multas e incumplimientos de contrato, de una reputación afectada, de un momento que hará cuestionar todo.
También lee: Fraude por correo corporativo: ni tecnología ni finanzas lo están atendiendo solas
Esta empresa nunca existió. Yo la inventé.
Pero cada pieza que te acabo de contar la he visto en un incidente real. El sistema de accesos sin respaldo. El sistema obsoleto de respaldos por donde entró el atacante o con un sistema operativo vulnerable desde donde se hacían. Los respaldos parcialmente cifrados. La restauración detenida hasta conseguir infraestructura limpia. El collage de fechas de los respaldos. Los datos sin quien los traduzca porque nadie respaldó el aplicativo o tiene la forma de volverlo a instalar. La pregunta sobre lo que trae el respaldo adentro. No hay un inventario de datos ni de datos personales.
Las junté en una sola línea de tiempo porque por separado cada una suena a mala suerte. Juntas muestran lo que realmente sale mal cuando una organización asume que “tenemos respaldos” es suficiente.
Durante años, el debate presupuestal en muchas empresas se ha parado en la misma pregunta: cuánto gastamos en prevenir. Pero la prevención no es el único cheque que hay que firmar. Cuando un incidente ocurre, y va a ocurrir, lo que decide si la empresa vuelve a operar es lo que se haya invertido en reaccionar. Planes de crisis probados. Sistemas de respaldo aislados. Infraestructura donde recuperar cuando todo arde.
Esa inversión se ve cara cuando todo va bien. Se ve barata el lunes por la mañana del ataque.
Hay preguntas que un director general tiene que poder contestar. No su director de sistemas.
Si nos pasa algo hoy, ¿en cuánto tiempo volvemos a operar?
Si nos pasa algo hoy, ¿qué sistemas no tienen respaldo y nadie se ha dado cuenta?
Si nos pasa algo hoy, ¿sabemos qué procesos dependen de qué sistemas para priorizarlos en una recuperación?
Si nos pasa algo hoy, ¿cómo sabemos que el propio respaldo no es parte del problema?
Son cuatro preguntas. Y las cuatro son estratégicas. Ninguna es técnica.
Respaldar es fácil.
Recuperarse a tiempo, en el orden correcto, con los datos y las aplicaciones que cada proceso del negocio necesita, es una decisión directiva que pocas organizaciones se han tomado el trabajo de tomar.
Y por cierto, DRP y BCP no son respaldos…
Sobre el autor:
Correo: [email protected]
LinkedIn: https://www.linkedin.com/in/andresvelazquez/
Las opiniones expresadas son sólo responsabilidad de sus autores y son completamente independientes de la postura y la línea editorial de Forbes México.
Inspírate, descubre y comparte. ¡Síguenos y encuentra lo que buscas en nuestro Instagram!
