Menos de dos horas después, los sistemas afectados ya han sido aislados, nuestro plan de respuesta ante incidentes está activado y el análisis forense se encuentra en marcha. Aunque el ataque en sí duró relativamente poco tiempo, gestionar sus consecuencias nos mantendría ocupados durante casi tres semanas.

La noticia más importante fue que nuestros sistemas de producción utilizados por los clientes continuaron funcionando durante todo el incidente. Una vez finalizada la investigación forense, no se encontraron indicios de que los datos de nuestros clientes, el código fuente o las bases de datos de producción se hubieran visto afectados. Aun así, nuestra empresa pasó casi tres semanas gestionando una situación de crisis, durante las cuales tuvimos que afrontar simultáneamente desafíos técnicos, organizativos y legales.

Hoy hemos decidido compartir públicamente esta experiencia. No para presentar una historia de éxito sin imperfecciones, sino para ofrecer una visión honesta de un ataque que nos recordó que incluso las empresas con amplios conocimientos de ciberseguridad pueden tener vulnerabilidades y cometer errores.

Lo importante, por tanto, no es estar completamente libre de errores, sino estar preparado para afrontar una situación de emergencia. Una buena preparación puede limitar la propagación de un ataque, reducir los daños y ayudar a una empresa a mantener su capacidad operativa durante una crisis. También es fundamental analizar posteriormente lo sucedido con honestidad y aprender de la experiencia.

Los primeros 120 minutos

Mientras los atacantes todavía intentan presionar por teléfono a nuestros empleados, las primeras medidas de emergencia ya están en marcha. Todas las personas implicadas se reúnen en una videoconferencia, se activa nuestro plan de respuesta ante incidentes y se distribuyen las responsabilidades relacionadas con la investigación forense, la recuperación técnica, las cuestiones legales y la comunicación.

Al mismo tiempo, nuestros equipos técnicos comienzan a apagar de forma controlada determinadas partes de la infraestructura y a desconectar sistemáticamente de la red los sistemas afectados. Se inicia una primera evaluación forense mientras se coordinan en paralelo los siguientes pasos necesarios para contener el ataque.

En una situación así, apenas queda tiempo para mantener largas discusiones sobre las responsabilidades fundamentales. Es necesario decidir rápidamente qué sistemas deben apagarse, quién documentará las medidas técnicas adoptadas y quién se encargará de informar a los empleados, clientes y organismos externos. Paralelamente, deben evaluarse las posibles obligaciones legales de notificación e información, además de organizar la colaboración con especialistas en análisis forense y asesoramiento jurídico.

Muchas de estas cuestiones parecen evidentes durante el funcionamiento habitual de una empresa, hasta que llega el momento de responderlas bajo una presión considerable. El hecho de que las funciones y responsabilidades ya estuvieran básicamente definidas en nuestra organización no impidió el ataque, pero sí evitó que al incidente técnico se sumara también una crisis organizativa.

Lunes: los servicios para clientes siguen funcionando, pero las operaciones internas están afectadas

El mayor alivio llega el lunes siguiente: nuestros sistemas de producción destinados a los clientes continúan funcionando con normalidad. Las plataformas SaaS permanecen disponibles y, según la información de la que disponemos en ese momento, no existen indicios de que el entorno de producción haya sido comprometido.

Que los servicios para clientes sigan operativos no es una coincidencia, sino el resultado de una arquitectura de seguridad diseñada de manera deliberada. Nuestros sistemas de producción y administrativos están estrictamente separados. Internamente denominamos este enfoque nuestro «principio del submarino», en el que distintos compartimentos técnicos tienen como objetivo impedir que un incidente de seguridad en un área se propague sin control al resto de la infraestructura.

Esta separación resultó especialmente valiosa durante el ataque. A pesar de ello, las consecuencias para nuestras operaciones internas fueron considerables. Los sistemas administrativos solo estaban disponibles de forma limitada, varios procesos internos tuvieron que reorganizarse temporalmente y, al mismo tiempo, se estaban llevando a cabo las investigaciones técnicas, las evaluaciones legales y la comunicación con clientes y empleados.

El incidente nos demostró claramente que un ciberataque puede afectar a una parte importante de las actividades de una empresa, incluso cuando los servicios destinados a los clientes continúan funcionando. La disponibilidad de los sistemas de producción no significa necesariamente que el resto de la organización pueda seguir trabajando sin interrupciones.

La prevención sigue siendo el objetivo. Pero cuando la prevención falla, la resiliencia marca la diferencia. Por eso, una arquitectura de seguridad bien diseñada no debe centrarse únicamente en impedir los ataques, sino también en limitar sus consecuencias de la forma más eficaz posible cuando se produce un incidente.

La pregunta más difícil: ¿en qué sistemas podemos seguir confiando?

En determinadas circunstancias, un sistema afectado puede restaurarse con relativa rapidez a partir de una copia de seguridad existente. Sin embargo, la cuestión mucho más compleja es determinar si ese sistema puede considerarse realmente seguro después de su recuperación.

Durante el proceso de restauración, tuvimos que comprobar no solo qué sistemas y datos se habían visto afectados, sino también si algunas cuentas de usuario habían sido comprometidas, si se habían creado accesos adicionales o si determinados permisos habían sido modificados sin nuestro conocimiento. Solo después de aclarar suficientemente estas cuestiones es posible decidir de manera responsable qué sistemas pueden volver a conectarse a la red y ponerse nuevamente en funcionamiento.

Este es precisamente uno de los desafíos que más se subestiman después de un ciberataque. Restaurar correctamente los datos no significa automáticamente que se haya recuperado el nivel de seguridad original de la infraestructura. Para conseguirlo, es necesario realizar una revisión técnica exhaustiva y, cuando corresponda, reconstruir completamente algunos de los sistemas afectados.

El punto de entrada fue un dispositivo periférico aparentemente insignificante

Nuestra investigación forense reveló que una vulnerabilidad en un dispositivo periférico de red había servido como primer punto de entrada para los atacantes. Desde allí, consiguieron desplazarse dentro del entorno administrativo y obtener privilegios adicionales.

Este descubrimiento fue especialmente importante para nosotros porque puso de manifiesto hasta qué punto puede ser amplia la superficie real de ataque de una empresa. Cuando se habla de proteger una infraestructura informática, la atención suele centrarse en servidores, ordenadores de trabajo y cortafuegos. Sin embargo, es fácil pasar por alto que los dispositivos de red menos visibles también cuentan con su propio software, cuentas de usuario y accesos a la red.

Si estos dispositivos no se actualizan periódicamente, no se segmentan adecuadamente y no se supervisan de forma continua, pueden convertirse en el punto de partida de un incidente de seguridad mucho más grave. Nuestra experiencia dejó claro que una arquitectura de seguridad completa debe tener en cuenta también aquellos componentes que, a primera vista, pueden parecer poco importantes.

Exfiltración de datos del entorno administrativo, mientras los sistemas de los clientes permanecen operativos

Durante el ataque se produjo una exfiltración de datos de nuestro entorno administrativo. La información afectada incluía datos internos de la empresa y datos de empleados. Por tanto, el incidente tuvo consecuencias reales, aunque nuestros sistemas de producción destinados a los clientes continuaron disponibles.

Una vez finalizada la investigación forense, no se encontraron indicios de que el entorno de producción o los datos de los clientes hubieran sido comprometidos. Esta distinción fue fundamental tanto para nuestra evaluación interna como para nuestra comunicación externa.

Desde fuera, un ciberataque suele resumirse en una afirmación sencilla: una empresa ha sido hackeada. Sin embargo, las consecuencias técnicas y empresariales pueden ser muy diferentes. Existe una diferencia considerable entre un incidente que afecta a sistemas administrativos y otro en el que los ciberdelincuentes consiguen acceder a los entornos de producción utilizados por los clientes.

Por este motivo, decidimos informar con rapidez y transparencia a nuestros clientes y empleados. Explicamos qué áreas se habían visto afectadas según la información disponible en cada fase, qué sistemas no presentaban indicios de compromiso y qué medidas se habían puesto ya en marcha para contener e investigar el incidente.

Esta transparencia no siempre fue cómoda, pero era necesaria. En lugar de permitir que la incertidumbre aumentara debido a información incompleta, queríamos proporcionar una base objetiva y comprensible sobre la que nuestros clientes y empleados pudieran evaluar la situación.

Por qué la recuperación tardó casi tres semanas

Nuestras copias de seguridad funcionaron y los datos afectados estaban almacenados de forma cifrada, con una separación tanto lógica como física respecto a los sistemas comprometidos. Por ello, la restauración de los datos en sí no representó nuestro principal desafío.

La tarea considerablemente más exigente consistió en sanear por completo la infraestructura afectada y garantizar que los sistemas pudieran volver a utilizarse en condiciones de seguridad. Para conseguirlo, los sistemas afectados fueron reconstruidos o restaurados a partir de copias de seguridad verificadas y posteriormente sometidos a medidas adicionales de refuerzo de la seguridad antes de volver a ponerse en funcionamiento.

Paralelamente, revisamos las estructuras críticas de autenticación y gestión de accesos, algunas de las cuales tuvieron que reconstruirse. Además, como medida de precaución, se cambiaron todas las contraseñas para reducir los posibles riesgos asociados a credenciales comprometidas.

Precisamente este cambio generalizado de contraseñas se convirtió en un desafío organizativo que suele subestimarse en el día a día de las empresas. Para sustituir de forma fiable todas las credenciales relevantes después de un ataque, una organización debe saber qué cuentas existen, quién es responsable de ellas y qué sistemas dependen unos de otros.

En particular, las cuentas de administrador olvidadas o las cuentas de servicio pueden complicar innecesariamente estas tareas de saneamiento. Cuando no existe una visión completa de los accesos, no solo aumenta la carga de trabajo, sino también el riesgo de que determinados permisos comprometidos permanezcan activos sin ser detectados.

El proceso de recuperación, que duró casi tres semanas, nos demostró que disponer de copias de seguridad funcionales es una condición indispensable para garantizar la continuidad del negocio, pero que estas, por sí solas, no aseguran un regreso rápido y seguro a la normalidad.

Seis decisiones que ayudaron a limitar los daños

Mirando hacia atrás, hubo seis decisiones y medidas preparadas con antelación que resultaron especialmente importantes para ayudarnos a contener las consecuencias del ataque y restablecer gradualmente nuestras operaciones.

1. Segmentación rigurosa

La separación estricta entre los sistemas administrativos y los entornos de producción limitó la propagación del ataque e impidió que sus consecuencias se extendieran sin control por toda nuestra infraestructura. La investigación forense no encontró indicios de compromiso en nuestros sistemas de producción destinados a los clientes.

2. Copias de seguridad separadas y fiables

Nuestras copias de seguridad estaban cifradas, separadas lógica y físicamente de los sistemas afectados y podían restaurarse de manera efectiva. Esto nos proporcionó una base fiable para reconstruir la infraestructura sin depender de un posible pago del rescate.

3. Responsabilidades claramente definidas

Gracias a que las responsabilidades ya estaban establecidas, la recuperación técnica, las investigaciones forenses, las evaluaciones relacionadas con la protección de datos y la comunicación pudieron coordinarse de forma simultánea. Esta preparación permitió ahorrar un tiempo valioso y redujo el riesgo de que se pasaran por alto decisiones importantes durante las primeras horas críticas.

4. Comunicación proactiva

En lugar de esperar hasta que todas las investigaciones hubieran concluido, informamos rápidamente a nuestros clientes y empleados sobre las consecuencias conocidas del incidente. Para nosotros era fundamental comunicar únicamente resultados verificados y distinguir claramente entre la información confirmada y las cuestiones que todavía estaban pendientes de aclaración.

5. Capacidad de recuperación sin pagar un rescate

Las copias de seguridad intactas y la separación estricta del entorno de producción nos permitieron avanzar con la recuperación de forma independiente y sin pagar ningún rescate a los atacantes. El factor decisivo fue poder apoyarnos en medidas técnicas y organizativas que ya estaban implantadas.

6. Apoyo de especialistas externos

Recurrimos a especialistas externos y asesores en protección de datos para apoyar las investigaciones forenses y la evaluación jurídica del incidente. Su experiencia nos ayudó a analizar el ataque de manera estructurada y a tomar decisiones importantes sobre una base sólida. Una crisis en curso no es el momento adecuado para empezar a desarrollar procedimientos fundamentales mediante el método de ensayo y error.

Lo que habíamos subestimado y lo que hacemos de manera diferente hoy

El ataque no solo nos mostró qué medidas de seguridad habían funcionado, sino que también puso de manifiesto las debilidades que todavía existían. En particular, habíamos subestimado la importancia de proteger los dispositivos periféricos de red y de supervisar los entornos administrativos.

Desde entonces, hemos adoptado medidas concretas para corregir estas deficiencias. Tras el incidente, comenzamos a revisar con mayor rigor la segmentación de nuestra infraestructura, los permisos existentes, el estado de las actualizaciones y nuestros procesos de supervisión. Actualmente también utilizamos tecnologías asistidas por inteligencia artificial para seguir mejorando nuestras capacidades de monitorización de la seguridad.

Sin embargo, estas mejoras no constituyen un proyecto puntual que algún día pueda considerarse completamente terminado. Las infraestructuras informáticas cambian constantemente, aparecen nuevas vulnerabilidades y los atacantes adaptan continuamente sus métodos. Por ello, las estrategias de seguridad también deben revisarse periódicamente y ajustarse a las nuevas necesidades.

Sobre todo, el incidente reforzó nuestra convicción de que nunca es posible eliminar por completo las vulnerabilidades y los errores humanos. Precisamente por eso resulta aún más importante establecer con antelación las condiciones técnicas y organizativas necesarias para contener un ataque y gestionar sus consecuencias.

Entre estas condiciones se encuentran una arquitectura de seguridad cuidadosamente diseñada, responsabilidades claramente definidas, mecanismos de protección eficaces y la disposición a cuestionar periódicamente los procesos existentes. También es esencial analizar abiertamente los incidentes después de su resolución e incorporar sistemáticamente las lecciones aprendidas a la estrategia de seguridad a largo plazo de la empresa.

La preparación marca la diferencia antes de que se produzca una emergencia

Un ciberataque no termina automáticamente cuando se apaga un servidor comprometido o se restaura correctamente una copia de seguridad. La gestión del incidente solo puede considerarse realmente concluida cuando los sistemas afectados vuelven a funcionar de manera fiable y segura, los accesos críticos han sido revisados y protegidos, y tanto los empleados como los clientes han recibido respuestas claras y fiables a sus preguntas.

Nuestra experiencia demostró que la ciberseguridad va mucho más allá de la simple protección técnica de los sistemas. También está relacionada con la continuidad del negocio, las responsabilidades organizativas, la transparencia en la comunicación y la capacidad de la dirección de una empresa para tomar decisiones fundamentadas incluso bajo una presión considerable.

Por tanto, todas las empresas deberían plantearse una pregunta fundamental: ¿sería su organización capaz de aislar rápidamente una parte de su infraestructura informática, restaurarla a partir de copias de seguridad seguras y mantener operativas sus actividades esenciales, sin tener que determinar primero quién es responsable de tomar las decisiones y qué medidas deben adoptarse?

Nosotros tuvimos que responder a esta pregunta en condiciones reales y comprobamos de primera mano lo valiosa que puede llegar a ser una preparación adecuada.

Espero que todas las empresas encuentren su respuesta antes de verse obligadas a afrontar esta pregunta bajo una presión real.