“Hola, me llamo Andrés. Me van a ciberatacar”

Suena el teléfono móvil

Domingo 18 de abril, cerca de las diez de la noche. Mientras ceno en casa, pensando como tantos otros domingos lo rápido que pasa el fin de semana, me llega una alerta al móvil. Este fin de semana se acabaría antes de lo que yo pensaba. Hace tiempo que en la Universidad de Castilla-La Mancha nos dotamos de un servicio de monitorización continua de las infraestructuras y servicios digitales críticos para la institución. Afortunadamente, este tipo de alertas no son frecuentes, pero entran dentro de la actividad habitual. Esta vez no lo sería.

Examiné la alerta para confirmar el servicio afectado comprobando que se trataba del sitio web de la institución. Tras este tipo de alertas, se desencadena un protocolo de actuación en varios niveles, así que decidí dejar pasar un tiempo para ver si, como en otras ocasiones, el servicio era recuperado por el equipo de operadores desde el centro externo de monitorización. En aquel momento pensé que podría ser un problema en los servidores donde alojamos el sitio web o incluso del propio sistema de gestión de contenidos que utilizamos para actualizarlo. Estaba equivocado. No había pasado ni una hora cuando recibí la llamada de mi compañero Julian, nuestro director de Sistemas. El teléfono sonando la noche de un domingo no auguraba nada bueno: si Julian me estaba llamado, el protocolo había subido de nivel y estábamos ante un impacto elevado en el servicio.

“Buenas noches, ¿qué ha pasado?, ¿se nos ha caído el gestor web?”, pregunté justo al descolgar en un tono de cierta normalidad, pensando que el problema con el web sería grave y seguramente me llamaban para confirmar que se tardaría tiempo en recuperar el servicio. No fue el contenido de la respuesta, sino el tono de voz que escuché al otro lado el que me sacó de mi error. La respuesta fue breve, algo atropellada por el tono de tensión con el que se trasladaba la noticia: “No. No es un problema en el gestor. Es la base de datos: está cifrada. Nos han atacado.”

El primer balance de daños era demoledor: multitud de servidores cifrados, y varias bases de datos inaccesibles

La primera actuación, siguiendo lo establecido en protocolos de este tipo, ya se había realizado en cuanto se identificó el cifrado: corte de conectividad externa para contener el ataque e interrumpir la comunicación con el o los atacantes. El siguiente paso, por tanto, había que realizarlo in situ, desplazándonos inmediatamente al edificio donde ubicamos las infraestructuras tecnológicas más críticas para la universidad. En mi casa no daban crédito cuando expliqué el motivo de coger el coche con el inicio del toque de queda tan cercano: “¿Os han hecho el qué?”. Tampoco fue sencillo explicarlo, con tan escasa información, al vicerrector y solicitarle que le trasladase la situación al rector. Aún no sabíamos el alcance, pero estábamos ya viviendo una situación inédita para la institución.

Escena del atentado

La ciudad estaba casi desierta ya. Me crucé pocos coches en el breve trayecto hasta la universidad, haciendo serios esfuerzos por no superar los límites de velocidad. Cuando me vio aparecer el guardia de seguridad me indicó que ya había un par de personas en el edificio. Caras serias, rostros tensos.

El primer balance de daños era demoledor. Multitud de servidores cifrados, varias bases de datos inaccesibles y, por supuesto, una nota con cuatro letras en gran formato que aclaraba lo sucedido: RYUK. El escalofrío no se repitió al ver la nota, ya había superado varios esa noche. La dirección de contacto estaba también bastante clara: era la vía de negociación para recuperar los datos cifrados con un rescate que no estaba cuantificado en la nota. La decisión tomada en ese momento fue contundente: apagado progresivo de toda la infraestructura tecnológica de la universidad ubicada en el CPD institucional. Ahora sí, la piel se erizó al pensar en las primeras horas del día siguiente: la universidad comenzaría la semana sin ningún soporte tecnológico. En ese momento ya sabíamos que los elementos principales de la infraestructura tecnológica estaban tomados y que no era in incidente aislado: todos los servidores que ejercían algún tipo de rol fundamental estaban cifrados, alguno de estos roles estaba redundados en hasta media docena de servidores repartidos en diferentes campus y hasta en entornos cloud. Todos ellos cifrados. Llegados a este punto, adoptamos una decisión que vendría a marcar el devenir de los acontecimientos. Creo sinceramente que nuestra arquitectura tecnológica, nuestros recursos y conocimiento técnico se encuentra a la altura del exigente sector universitario. Sin embargo, el análisis que hicimos esa madrugada ya del lunes 19 de abril, solos en el CPD, estuvo basada en la humildad de quienes se ven sobrepasados pro la situación: tuvimos claro desde el primer momento que no podríamos superar la situación solos. Era la primera vez que nos enfrentábamos a una situación como ésta y lo tuvimos claro: necesitábamos ayuda.

La estrategia de comunicación: claridad y frecuencia informativa constante

Decidimos volver a casa. Eran las dos de la madrugada del lunes y, justo antes de irnos, lancé un mensaje en la red social Twitter anunciando el incidente. Aún en la confusión que vivíamos, entendimos que era importante informar de que algo estaba sucediendo. Habitualmente informamos de las incidencias graves a través de esa red social y así lo hicimos en esta ocasión tan especial. Tuve claro que había que hacerlo, pero no la repercusión que tendría entre la comunidad universitaria: esas breves líneas sirvieron para trasladar que los servicios TIC de la universidad comenzaron a trabajar de forma inmediata ese mismo domingo. El regreso a casa fue otro momento difícil, regresábamos con la crudeza de la situación en nuestras manos y la imposibilidad de avanzar en algo más a esas horas. El vigilante nos miró con cara de preocupación al ver reflejados en nuestros rostros la preocupación del momento: “No ha sido posible resolver la avería ¿verdad?”. “No, va a ser complicado”, contesté con pocas fuerzas ya. No olvidaré el regreso a casa, la tensión en el cuerpo y los coches de la Policía Local a lo lejos vigilando el cumplimiento del toque de queda. “Si me paran y tengo que explicar los motivos por los que estoy circulando a estas horas”, pensé, “pensarán que la excusa es tan extraña que a buen seguro será cierta”.

Una mañana de incertidumbre

Cuando la luz del sol ya iluminaba ese lunes, inicié los trámites para buscar ayuda. En ese momento, con máxima tensión, buscas alternativa donde consideras que puedes obtener una respuesta no solo de calidad basada en la experiencia, sino además de rápida ejecución. Decidí, de entre las diferentes opciones que la noche anterior había conseguido identificar, llamar a Telefónica. Su participación en la respuesta a otros incidentes era conocida y, además, estaba convencido de que la respuesta sería rápida en cuanto trasladase la situación. Así fue. A las 9:15 ya mantuvimos la primera reunión de análisis de situación entre el equipo de Telefónica y el grupo de compañeros que constituimos en equipo de respuesta. El primer análisis fue todo crudeza: el alcance completo lo conoceremos en las próximas 24h, pero el tipo de ataque se asemeja a los últimos sufridos recientemente por otras administraciones públicas y la recuperación será lenta. Mi informe al equipo de gobierno de la universidad fue también así de crudo.

De nuevo, momentos de tensión e incertidumbre. Por un lado, debíamos esperar a la valoración de la ayuda externa, por otro, lanzamos también la información de la situación al CCN-CERT, desde donde se nos indicó que generásemos un ticket en su herramienta de gestión de incidentes. En paralelo, sabiendo que la ayuda externa era necesaria, consulté al respecto de la tramitación de la contratación a través del procedimiento de urgencia. En menos de 90 minutos ya contábamos con el visto bueno de nuestra asesoría jurídica y de nuestra gerencia para esa tramitación. Puede parecer baladí, pero la contratación de servicios externos no es sencilla en una Administración y, en esta situación, era conveniente tratar de cerrar todo el proceso.

Sería necesario incorporar nuevos elementos de ciberseguridad ante la amenaza, más que creíble, de sufrir una segunda oleada de ataque

En paralelo, mientras los equipos comenzaban a conformar la estrategia de respuesta, comencé a insistir en otro de los elementos fundamentales en esos momentos: la comunicación. Recomendé informar claramente de la situación que estábamos sufriendo y a la mayor celeridad posible. Las clases y la jornada laborar de ese día ya habían comenzado y era importante explicar lo que estaba aconteciendo. Acordamos lanzar un primer comunicado a través de la cuenta institucional que gestiona nuestro gabinete de comunicación, que no solo estuvo de acuerdo con el planteamiento, sino que redactó con rapidez a primera nota y confirmó la estrategia de comunicación: claridad y frecuencia informativa constante.

Al final de la mañana de ese lunes ya pudimos mantener la primera reunión de gestión del incidente. Estas reuniones se repetirían al menos dos o tres veces al día la primera semana y de forma diaria hasta que el incidente se diera por superado. La primera reunión, no obstante, sentó las bases de la operativa a seguir. Identificación del malware utilizado, alcance de daños, protección de los elementos críticos, recuperación de servicios y monitorización continua fueron los bloques fundamentales de estructuración del trabajo. El equipo interno se centraría en la recuperación de servicios, pero ya desde el inicio identificando que sería necesario incorporar nuevos elementos de ciberseguridad ante la amenaza, más que creíble, de sufrir una segunda oleada de ataque.

Organizando la respuesta

La tarde del lunes 19 de abril fue una montaña rusa de emociones. Este tipo de ataques complementan el cifrado de servidores y bases de datos con la aparición de decenas sino centenares de equipos cifrados. Afortunadamente, no fue nuestro caso. Quizá por lo rápido de la reacción el domingo por la noche o quizá por el buen trabajo realizado en la renovación de equipamiento de puesto de usuario desplegado justo el año anterior, donde se incrementaron las medidas de seguridad aplicables a esos dispositivos. Por otro lado, se confirmaba la seriedad del ataque: el ransomware usado era una variante de RYUK conocida y el alcance en número de servidores estaba aún por definir. Las copias de seguridad se convirtieron, por tanto, en el elemento más preciado: la estrategia de copias de seguridad establece diferentes espacios de almacenamiento, pero el riesgo de perder la actividad desde el primer día del mes o hasta de perder una cantidad mayor de datos estaba ahí. En todo caso, había elementos sobre los que comenzar a reconstruir la situación: el directorio de usuarios estaba disponible y los diferentes niveles de copias de seguridad nos aportaba algo de serenidad.

Esa tarde, apenas 24 horas después, quedó clara la estrategia de recuperación, de organización y de comunicación. Fueron los tres pilares alrededor de los que trabajamos durante las siguientes semanas y cuyo establecimiento sirvió para identificar las actuaciones y responsabilidades de actuación en cada caso.

El despliegue de aplicaciones en entornos cloud nos permitió el restablecimiento de una veintena de aplicaciones

El criterio base de la recuperación de infraestructuras y servicios quedó claro desde el principio: el nivel de ciberseguridad de la arquitectura tecnológica debería ser elevado ante el riesgo que afrontábamos. Esto suponía, modificar el esquema de privilegios en la gestión e infraestructuras; el establecimiento de políticas de “zero trust” con el exterior e incluso su aplicación en algunos de los segmentos de la red interna de la universidad; la monitorización continua de actividad de los dispositivos de usuario para la detección de patrones de malware, para lo que se requería el despliegue de capacidades EDR en nuestro antivirus actual que fue posible gracias al soporte de Microsoft; la protección de las identidades de los usuarios al ser identificado como uno de los vectores de ataque más frecuentes, para lo que se diseñó el despliegue de servicios de doble factor de autenticación en usuarios; así como la exigencia innegociable de sistemas operativos con soporte vigente en los puestos conectados a la red de la universidad.

Otro pilar fundamental que se identificó fue el organizativo. Pese a las primeras chanzas con el buen humor que aún quedaba ese día (tratamos de no perderlo en ningún momento) respecto a las pilas de pizzas, los barriles de Red Bull y las marmitas de café, entendimos claramente que se trataba de un trabajo a abordar en varios días y, como en una carrera de larga distancia, era necesario medir las fuerzas adecuadamente. Las jornadas, como la de ese lunes, serían largas, muy largas, para el equipo de trabajo, pero no indefinidas puesto que el descanso era fundamental. Además, se prefirió desde el principio trabajar en grupo, en lugar de establecer turnos que podrían dar lugar a avances durante las 24h pero también a falta de comunicación entre el equipo de respuesta que provocasen finalmente retrasos o incorrecciones. Por último, hubo que mantener al equipo de respuesta aislado de consultas, presiones e inquietudes. Cualquier cuestión desde o hacia el equipo, incluso de los propios compañeros de otras unidades del área TIC en la universidad, se canalizarían a través de un único punto. El lector podrá adivinar ya quien ejerció el rol de “facilitador”.

La comunicación fue el tercer pilar sobre el que organizar la respuesta al incidente. Asumiendo la situación y habiendo optado por la transparencia de lo ocurrido no solo hacia la comunidad universitaria sino también hacia la sociedad en general, se acordó un protocolo de comunicación que abundaba en la transparencia y en una frecuencia predecible en la información trasladada. Desde ese mismo martes 20 de abril se establecieron comunicaciones diarias entre el gabinete de comunicación y el área TIC de la universidad. Minutos después de las 9 de la mañana esas dos semanas recibí puntualmente una llamada de mi compañera en el gabinete de comunicación en la que conjuntamente identificábamos las novedades a trasladar en la evolución diaria del incidente. La nota de prensa redactada desde el gabinete y validada ágilmente por los vicerrectorados competentes en TIC y comunicación, habitualmente tenía dos ideas fuerza: un elemento de avance y otro de concienciación ante los cambios que iban surgiendo en los servicios, fruto del incremento en niveles de ciberseguridad.

Mucho más que 24 horas

Sí, aunque esas 24 horas resultarían claves, fueron mucho más que 24 horas las que empleamos en la resolución del incidente. La recuperación fue organizada con una priorización de puesta en marcha de servicio que, evidentemente, implicó en fase cero a los roles de arquitectura tecnológica transversales, pudiendo exponer el primer equipo el miércoles de esa semana, y en el resto de las fases los servicios que conjugaban un producto favorable entre impacto en la actividad y tiempo de recuperación, recuperando los servicios de apoyo a docencia y colaboración el jueves de esa misma semana.

Algunas de las apuestas realizadas en la estrategia de despliegue de servicios digitales en la universidad desarrollada desde hace años también han dado frutos positivos en esta situación, del mismo modo que los aportaron en la etapa de confinamiento en 2020. El despliegue de aplicaciones en entornos cloud nos permitió el restablecimiento de una veintena de aplicaciones de un golpe a lo largo del viernes de esa primera semana. Es una de tantas lecciones aprendidas: la resiliencia de este tipo de arquitecturas ante ataques de ransomware es mayor que la que aportan las arquitecturas tradicionales.

La recuperación completa, no obstante, se extendió durante varias semanas. Por un lado, porque cualquier servicio antes de pasar de nuevo a entornos productivos era analizado en cuanto a riesgos, llegando incluso a la refactorización de aplicaciones. Por otro lado, la arquitectura de red, su segmentación y políticas de confianza entre zonas ha evolucionado de tal manera que la reincorporación de equipos, sobre todo de aquellos activos expuestos al exterior, ha sido analizada al detalle. Y, debo reconocer, también porque algún servicio como el de comunicaciones unificadas no disponía de una adecuada política de continuidad. En todo caso, es cierto también que en este caso hemos optado por un paso adelante en lugar de regresar a la situación de partida, lo que realmente ha supuesto que un proyecto de consolidación de comunicaciones unificadas previsto para un desarrollo durante meses se haya desplegado en semanas, al menos en sus servicios básicos.

Y una reflexión final

La expresión utilizada en el título de esta crónica no es mía, evidentemente. Se trata de una adaptación de la frase más célebre de la ópera prima de Alejando Amenábar: ‘Tesis’. Sin embargo, si en lugar de un artículo me hubieran pedido resumir en una sola frase todo lo sucedido y, sobre todo, las lecciones aprendidas, la usaría sin dudarlo: “Hola, me llamo Andrés y me van a ciberatacar”.

Hasta que no te ves inmerso como protagonista de la película, no valoras lo suficiente la situación de vulnerabilidad a la que estamos sometidos

Reiterar que no dedicamos suficiente esfuerzo en ciberseguridad es, desde luego, necesario. Pero no suficiente. Hasta que no te ves inmerso como protagonista de la película, no valoras lo suficiente la situación de vulnerabilidad a la que estamos sometidos, no solo las administraciones públicas, sino las organizaciones en general. No estoy dudando a lo largo de estas semanas después del 18 de abril, en calificar la situación sufrida por la universidad como “atentado”. Es cierto, se trata de un “atentado” sin víctimas, pero con daños en infraestructuras que ya son tan críticas para la organización como los propios edificios. Sin embargo, la respuesta que he observado no está al nivel de los atentados contra las infraestructuras físicas. Seguro que esa respuesta no es posible ofrecerla por falta de recursos destinados a ello, pero lo que es evidente es que esos recursos no estarán nunca al alcance de las instituciones y empresas de manera autónoma. Es necesario una reflexión seria, global, de estado e incluso de nivel europeo. La amenaza a la que nos enfrentamos tiene recursos inalcanzables para entornos como el nuestro, pero también incluso para organizaciones mucho más grandes que la nuestra.

Nos equivocamos en la estrategia de ciberseguridad basada exclusivamente en la prevención, que es absolutamente necesaria, pero creo firmemente que actualmente el primer criterio de diseño es admitir que seremos objetivo de un ciberataque.