10Momento de comienzo de gestión del incidente
11https://www.ccn-cert.cni.es/informes/informes-ccn-cert-publicos.html informe CCN-CERT BP/04 Ransomware de mayo de 2021
• 24 de diciembre a las 21 horas10: el equipo de TI del Hospital X comienza a recibir alertas de mal funcionamiento de múltiples de sus equipos y servido- res. Inmediatamente se comienzan a analizar las alertas junto con el equipo de seguridad. Se detectan archivos cifrados en varios equipos, por lo que se concluye que se está sufriendo un ataque de ransomware.
• 24 de diciembre a las 24 horas: se toma la decisión de proceder a des- conectar el equipo identificado de la red, así como el resto de equipos no considerados imprescindibles y a aislar determinados segmentos de la red de comunicaciones con el objetivo de11:
- Evitar que la acción de cifrado alcance al contenido alojado en las uni- dades de red accesibles desde el equipo infectado.
- Eludir que el código dañino pueda contactar con su servidor de mando y control.
• 25 de diciembre a las 10 horas: tras la contención inicial del incidente, y una vez que se observa que no se están produciendo nuevas alertas en los equipos no identificados como infectados, se comienza el proceso de recuperación y restauración de los sistemas afectados, así como el análisis forense completo de lo sucedido.
• 27 de diciembre a las 10 horas: se presenta el análisis forense inicial a la dirección del Hospital X. Tras el estudio realizado se ha concluido que el vector de entrada ha sido un correo electrónico enviado a uno de los médicos del hospital, que al ser abierto el 01 de diciembre descargó el malware que fue utilizado por los ciberdelincuentes. También se ha observado como entre el día 1 y el día 24 del mismo mes, el atacante fue intentando desplegar el malware en distintos servidores y equipos, no consiguiéndolo en todos los casos.
Solo con la información anterior no se puede saber la gravedad de la situación ni el impacto que ha podido tener el incidente en la privacidad de las personas, ni en el riesgo para sus derechos y libertades. Es necesario seguir analizando lo ocurrido, para lo que los logs o información de registro juegan un papel básico en el análisis forense, que deberá ser lo más detallado posible. Es importante identificar el origen del ataque, las actividades realizadas por el atacante entre la fecha de infección y la de detección, los sistemas y archivos realmente afec- tados, de si se contaba con copias de respaldo de los mismos que garanticen su
GUÍA [ PRÁCTICA ] PARA LA GESTIÓN DE BRECHAS DE DATOS PERSONALES
53 disponibilidad, etc. Y con estos datos, junto con el impacto que haya producido el incidente, se podrá inferir si se ha tratado de una brecha de datos personales y si ha afectado a su disponibilidad, integridad o también a su confidencialidad.A continuación, se muestran distintas situaciones que pueden darse asociado a un ataque de ransomware con el objetivo de mostrar las grandes diferencias entre unas situaciones u otras. La casuística puede ser infinita, pero se selec- cionan estas que, de algún u otro modo, pueden haberse producido en alguna entidad:
Situación 1: el cifrado que se produjo fue de un número reducido de equipos, pero justamente eran unos equipos que tenían información relevante del hospi- tal de las que se realizaban copias periódicas. Entre dicha información no había datos personales. Fue necesaria la restauración de las copias de respaldo y se produjo un impacto operativo en el hospital al no ser posible acceder a dicha información, pero no hubo ningún impacto en la privacidad de las personas y el hecho no supuso ningún riesgo para los derechos y libertades de las personas.
Situación 2: el cifrado fue de un número reducido de equipos, pero justamente uno de ellos estaba asociado a una de las máquinas utilizadas en el quirófano y en el mismo se encontraba información de salud de las operaciones que se encontraban previstas. Dicho equipo tuvo que ser sustituido y, por las ca- racterísticas técnicas que debía tener, dicha sustitución llevó más tiempo del inicialmente previsto. Además, no se pudo recuperar la información y todo esto hizo que hubiera que cancelar determinadas operaciones que se encontraban planificadas.
Situación 3: el cifrado fue de un volumen de equipos significativo que hizo necesaria la activación del plan de continuidad de negocio, pero el cifrado no afectó ni al correo electrónico ni a los sistemas y bases de datos del hospital.
Además, tras las tareas de análisis forense se pudo identificar exactamente cómo se había producido el ataque y se confirmó que no se había producido ninguna exfiltración de datos.
Situación 4: el cifrado fue de un volumen de equipos significativo que hizo necesaria la activación del plan de continuidad de negocio, pero a la hora de realizar la restauración de la información se detecta que había información que no había sido posible recuperar. Además, el plan de continuidad de negocio no se encontraba actualizado y esto hizo que los tiempos de respuesta fueran mayores a lo establecido suponiendo un impacto significativo en las personas, ya que no podían acceder a sus historias clínicas, y hubo que cancelar distintas citas e incluso operaciones.