Resumen de las directrices 01/2021 EDPB

El pasado 14 de diciembre el Comité Europeo de Protección de Datos (CEPD/EDPB) ha adoptado una nueva versión sobre directrices con ejemplos relacionados con brechas de seguridad y su notificación a la autoridad de control y/o los interesados, que actualiza con nuevos ejemplos y medidas las ya adoptadas con anterioridad.

Aunque para determinar si es necesario o no la notificación de la brecha, habrá que estar a cada caso concreto, y como no puede ser de otra forma a lo regulado en los artículos 33 y 34 del RGPD, estas directrices serán de gran ayuda tanto para la evaluación del riesgo, y la posible notificación de la brecha, como para la toma de medidas de Seguridad que lo mitiguen.

En esta ocasión se abordan 18 casos que se extraen de la experiencia al respecto de las distintas autoridades de control de los estados miembros, a lo largo de estos años desde la entrada en vigor del RGPD.

En el documento se analizan los siguientes casos de brechas provocadas por:

• Ransomware
• Ataques con sustracción/fuga de datos
• Fuente de riesgo interna y humana
• Dispositivos y documentos en papel perdidos o sustraídos
• Correo
• Otros casos, ingeniería social

MEDIDAS DE SEGURIDAD

Para cada uno de los dieciocho casos reflejados en el documento se exponen las medidas previas y de evaluación de riesgos, así como las medidas de mitigación y obligaciones.

Y para cada uno de los seis grupos de brechas contemplados se aconseja una lista no exhaustiva de medidas técnicas y organizativas para prevenir o mitigar el impacto de la brecha, con el objetivo de proporcionar ideas de prevención y posibles soluciones, pero teniendo en cuenta que cada actividad de tratamiento es diferente, por lo que el responsable debe tomar la decisión sobre qué medidas se ajustan más a cada situación específica.

La seguridad de la TI es un concepto general que abarca la seguridad de las redes, de Internet, de los extremos, de las API, de la nube, de las aplicaciones, etc. Se trata de establecer un conjunto de estrategias de seguridad que funcionen en conjunto para proteger los datos.

De cualquier forma, destacan como medidas de Seguridad esenciales:

• Formación. Hay que destacar la importancia que de nuevo desde el CEPD se le otorga a la formación y concienciación en materia de protección de datos para el personal del responsable y el encargado del tratamiento, en este caso centrada en la gestión de la violación de la seguridad de los datos personales (identificación de un incidente de seguridad de datos personales y otras acciones a tomar, etc.).
  
  El documento refleja que esta formación es esencial para los responsables y encargados del tratamiento, y que debe repetirse periódicamente, en función el tipo de actividad de tratamiento y el tamaño de la entidad responsable del tratamiento, abordando las últimas tendencias y alertas provenientes de ciberataques u otros incidentes de seguridad.

• Cifrado en reposo de bases de datos. El cifrado en reposo está diseñado para evitar que el atacante obtenga acceso a los datos sin cifrar, asegurándose de que los datos se cifran en el disco. Si un atacante obtiene una unidad de disco duro con datos cifrados, pero no las claves de descifrado, el atacante debe anular el cifrado para leer los datos. Este ataque es mucho más complejo y consume más recursos que el acceso a datos no cifrados en una unidad de disco duro. Por este motivo, el cifrado en reposo es muy recomendable y es un requisito de alta prioridad para muchas organizaciones.

• Parches de seguridad. Una adecuada gestión de parches de seguridad que garantice que los sistemas estén actualizados y que todas las vulnerabilidades conocidas de los sistemas implementados estén corregidas, ya que la mayoría de los ataques de ransomware explotan vulnerabilidades conocidas.

• Sistema de copias de Seguridad. Disponer de un sistema de copias de seguridad actualizado, seguro y probado (3-2-1 ó abuelo-padre-hijo.) Los medios para la copia de seguridad a medio y largo plazo deben mantenerse separados del almacenamiento de datos operativos y fuera del alcance de terceros, incluso en caso de un ataque que se materialice (como una copia de seguridad incremental diaria y una copia de seguridad completa semanal).

NOTIFICACIÓN DE LA BRECHA

Durante todo el desarrollo del documento, para obtener orientación sobre las operaciones de tratamiento "que probablemente den lugar a un alto riesgo", el CEPD remite al documento del Grupo de trabajo del A. 29 "Directrices sobre la evaluación del impacto de la protección de datos (DPIA) y determinar si el tratamiento es" probable que dé lugar a un alto riesgo "a los efectos del Reglamento 2016/679”, WP248 rev. 01, pág. 9.

En lo referente a la obligación o no de notificar la brecha, destacar que, aunque no sea necesario la notificación a la AC y a los afectados, siempre habrá que documentar el incidente conforme al artículo 33. 5 del RGPD, incluidos los hechos relacionados con ella, sus efectos y las medidas correctivas adoptadas. Dicha documentación permitirá a la autoridad de control verificar el cumplimiento por parte del responsable o encargado.

Otra cuestión a resaltar es que, en ocasiones, incluso si la brecha en sí misma no representa un alto riesgo para los derechos y libertades de las personas afectadas y, por lo tanto, la comunicación a las mismas no es una obligación conforme al artículo 34 del RGPD, la comunicación de la violación a los interesados puede ser recomendable, ya que su cooperación es necesaria para mitigar el riesgo.

También contempla el documento que, si bien en el caso de los datos personales relativos a la salud de las personas, generalmente se asume que es probable que la brecha supone un alto riesgo para el interesado, hay casos particulares en los que no se puede identificar ningún riesgo, ya que no suponen daños físicos, materiales o morales del interesado la divulgación no autorizada de esa información relativa a la salud (caso nº 15 de las Directrices).

Directrices 01/2021 sobre ejemplos relacionados con la violación de la seguridad de datos personales

Notificación

Adoptado el 14 de diciembre de 2021
Versión 2.0

Traducción literal del texto original realizada por Privacy Driver, no válida jurídicamente.
Manuel Castilleja Toscano
10/01/2022

Historial de versiones

Versión 2.0	14 12 2021	Adopción de las Directrices tras consulta pública
Versión 1.0	14 01 2021	Adopción de las Directrices para consulta pública

Tabla de contenido

1. INTRODUCCIÓN

2. SECUESTRO DE DATOS (RANSOMWARE)

CASO 1: Ransomware con respaldo adecuado y sin exfiltración
CASO 2: Ransomware sin respaldo adecuado
CASO 3: Ransomware con respaldo y sin exfiltración en un hospital
CASO 4: Ransomware sin respaldo y con exfiltración
Medidas organizativas y técnicas para prevenir/mitigar los impactos de los ataques de ransomware

3. ATAQUES DE EXFILTRACIÓN DE DATOS

CASO 5: Exfiltración de datos de solicitud de empleo de un sitio web
CASO 6: Exfiltración de contraseña hash de un sitio web
CASO 7: Ataque de relleno de credenciales en un sitio web bancario
Medidas organizativas y técnicas para prevenir/mitigar los impactos de los ataques de piratas informáticos

4. FUENTE DE RIESGO HUMANO INTERNO

CASO 8: Exfiltración de datos comerciales por parte de un empleado
CASO 9: Transmisión accidental de datos a un tercero de confianza
Medidas organizativas y técnicas para prevenir/mitigar los impactos de las fuentes internas de riesgo humano

5. DISPOSITIVOS Y DOCUMENTOS DE PAPEL PERDIDOS O SUSTRAIDOS

CASO 10: Material sustraído que almacena datos personales encriptados
CASO 11: Material sustraído que almacena datos personales no cifrados
CASO 12: Archivos en papel sustraídos con datos sensibles
Medidas organizativas y técnicas para prevenir/mitigar los impactos de la pérdida o robo de dispositivos

6. CORREO

CASO 13: Error de correo postal manual
CASO 14: Datos personales altamente confidenciales enviados por correo electrónico por error
CASO 15: Datos personales enviados por correo por error
CASO 16: Error de correo postal automatizado
Medidas organizativas y técnicas para prevenir/mitigar los impactos de la publicación incorrecta

7. OTROS CASOS - INGENIERÍA SOCIAL

CASO 17: Suplantación de identidad
CASO 18: Exfiltración de correos electrónicos

EL COMITÉ EUROPEO DE PROTECCIÓN DE DATOS

Visto el artículo 70, apartado 1, letra sexta, del Reglamento 2016/679 / UE del Parlamento Europeo y del Consejo, de 27 de abril de 2016, sobre la protección de las personas físicas en lo que respecta al tratamiento de datos personales y a la libre circulación de los mismos, que deroga la Directiva 95/46 / EC, (en adelante, "GDPR"),

Visto el Acuerdo EEE y, en particular, su anexo XI y su Protocolo 37, modificado por la Decisión del Comité Mixto del EEE nº 154/2018, de 6 de julio de 2018[1],

Visto el artículo 12 y el artículo 22 de su Reglamento,

Vista la Comunicación de la Comisión al Parlamento Europeo y al Consejo titulada La protección de datos como pilar del empoderamiento de los ciudadanos y el enfoque de la UE para la transición digital: dos años de aplicación del Reglamento general de protección de datos[2],

HA ADOPTADO LAS SIGUIENTES DIRECTRICES

1. INTRODUCCIÓN

1. El GDPR introduce, en ciertos casos, el requisito de notificar una violación de la seguridad de los datos personales a la autoridad nacional de control competente (en adelante, "AC") y comunicar la violación a las personas cuyos datos personales se han visto afectados por la misma (Artículos 33 y 34).
2. El Grupo de Trabajo del artículo 29 ya preparó una orientación general sobre notificación de violación de la seguridad de los datos personales en octubre de 2017, analizando las Secciones relevantes del GDPR (Directrices sobre notificación de violación de la seguridad de los datos personales según el Reglamento 2016/679, WP 250) (en adelante, "Directrices WP250)[3]. Sin embargo, debido a su naturaleza y momento, no abordó todas las cuestiones prácticas con suficiente detalle. Por tanto, ha surgido la necesidad de una orientación basada en casos específicos y orientada a la práctica, que se base en las experiencias adquiridas por las AC desde que el GDPR está en vigor, o es aplicable.
3. Este documento está destinado a complementar las Directrices WP 250 y refleja las experiencias comunes de las AC del EEE desde que el GDPR se hizo aplicable. Su objetivo es ayudar a los responsables del tratamiento a decidir cómo gestionar las brechas de seguridad y qué factores considerar durante la evaluación de los riesgos.
4. Como parte de cualquier intento de gestionar una brecha, el responsable y el encargado del tratamiento deben poder reconocerla. El GDPR define una «violación de la seguridad de los datos personales» en su art. 4.12 como toda violación de la seguridad que ocasione la destrucción, pérdida o alteración accidental o ilícita de datos personales transmitidos, conservados o tratados de otra forma, o la comunicación o acceso no autorizados a dichos datos.
5. En el Dictamen 03/2014 sobre notificación de brechas[4] y en las Directrices WP 250, WP29 se explica que las brechas se pueden clasificar de acuerdo con los siguientes tres principios de seguridad de la información:
   • “Brecha de confidencialidad”: cuando hay una divulgación o acceso no autorizado o accidental a datos personales.
   • “Brecha de integridad”: cuando hay una alteración accidental o no autorizada de datos personales.
   • “Brecha de disponibilidad”: cuando hay una pérdida de acceso accidental o no autorizada a los datos personales, o su destrucción.[5]
6. Una brecha puede tener una variedad de efectos adversos significativos en las personas, que pueden resultar en daños físicos, materiales o inmateriales. El GDPR explica que esto puede incluir pérdida de control sobre sus datos personales, limitación de sus derechos, discriminación, robo de identidad o fraude, pérdida financiera, reversión no autorizada de la seudonimización, daño reputacional y pérdida de la confidencialidad de los datos personales protegidos por el secreto profesional. También puede incluir cualquier otra desventaja económica o social significativa para esas personas. Una de las obligaciones más importantes del responsable del tratamiento es evaluar estos riesgos para los derechos y libertades de los interesados y aplicar las medidas técnicas y organizativas adecuadas para abordarlos.
7. En consecuencia, el GDPR requiere del responsable cuando tiene lugar una brecha que afecte a los datos personales:
   • documentarla, incluyendo los hechos relacionados con la misma, sus efectos y las medidas correctivas adoptadas[6];
   • notificarla a la autoridad de control, a menos que sea poco probable que suponga un riesgo para los derechos y libertades de las personas físicas[7];
   • comunicarla a los interesados cuando sea probable que suponga un alto riesgo para los derechos y libertades de las personas físicas[8].
8. Las brechas son problemas en sí mismas, pero también pueden ser síntomas de un sistema de seguridad de los datos vulnerable, posiblemente desactualizado, también pueden indicar debilidades que deben abordarse. Como regla general, siempre es mejor prevenir las brechas preparándose con anticipación, ya que algunas consecuencias de las mismas son por naturaleza irreversibles. Antes de que un responsable pueda completamente evaluar el riesgo que surge de una brecha causada por algún tipo de ataque, se debe identificar la causa raíz del problema, para identificar si las vulnerabilidades que dieron lugar al incidente aún están presentes y, por lo tanto, aún son explotables. En muchos casos, el responsable del tratamiento puede identificar que es probable que el incidente genere un riesgo y, por lo tanto, debe notificarlo. En otros casos, no es necesario la notificación hasta que se haya evaluado por completo el riesgo y el impacto que rodean a la brecha, ya que la evaluación completa del riesgo puede realizarse en paralelo a la notificación, y la información así obtenida se puede proporcionar a la AC de manera gradual sin dilación indebida[9].
9. La brecha debe notificarse cuando el responsable del tratamiento considere que es probable que suponga un riesgo para los derechos y libertades del interesado. Los responsables deben realizar esta evaluación en el momento en que se tengan conocimiento de la brecha. El responsable del tratamiento no debe esperar un examen forense detallado y las medidas de mitigación (tempranas) antes de evaluar si es probable que la violación de datos dé lugar a un riesgo y, por lo tanto, debe ser notificado.
10. Si un responsable del tratamiento autoevalúa que el riesgo es improbable, pero resulta que el riesgo se materializa, la AC competente puede hacer uso de sus facultades correctivas y puede resolver sancionar.
11. Todo responsable del tratamiento y encargado del tratamiento debe tener planes y procedimientos establecidos para manejar eventuales violaciones de datos. Las organizaciones deben tener líneas jerárquicas claras y personas responsables de ciertos aspectos del proceso de recuperación.
12. La formación y concienciación en materia de protección de datos para el personal del responsable y el encargado del tratamiento centrada en la gestión de la violación de la seguridad de los datos personales (identificación de un incidente de seguridad de datos personales y otras acciones a tomar, etc.) es esencial para los responsables y encargados del tratamiento. Esta formación debe repetirse periódicamente, en función el tipo de actividad de tratamiento y el tamaño del responsable, abordando las últimas tendencias y alertas provenientes de ciberataques u otros incidentes de seguridad.
13. El principio de responsabilidad proactiva y el concepto de protección de datos desde el diseño podrían incorporar un análisis que se incorpore al propio "manual sobre la gestión de la violación de la seguridad de los datos personales" del responsable y el encargado del tratamiento, que tiene como objetivo establecer hechos para cada fase del tratamiento en cada etapa principal de la operación. Un manual de este tipo preparado de antemano proporcionaría una fuente de información mucho más rápida para permitir a los responsables y los encargados del tratamiento mitigar los riesgos y cumplir con las obligaciones sin dilación indebida. Esto garantizaría que, si ocurriera una violación de la seguridad de los datos personales, las personas de la organización sabrían qué hacer, y es más que probable que el incidente se gestione más rápido que si no hubiera un plan implementado.
14. Aunque los casos que se presentan a continuación son ficticios, se basan en casos típicos de la experiencia colectiva de AC con notificaciones de violación de datos. Los análisis ofrecidos se relacionan explícitamente con los casos bajo análisis, pero con el objetivo de brindar ayuda a los responsables del tratamiento para evaluar sus propias violaciones de datos. Cualquier modificación en las circunstancias de los casos descritos a continuación puede resultar en niveles de riesgo diferentes o más significativos, requiriendo así medidas diferentes o adicionales. Estas directrices estructuran los casos de acuerdo con determinadas categorías de brechas (por ejemplo, ataques de ransomware). En cada caso, se requieren determinadas medidas correctivas cuando se trata de una determinada categoría de brecha. Estas medidas no se repiten necesariamente en cada caso de análisis perteneciente a la misma categoría de brechas. Para los casos que pertenecen a la misma categoría, solo se exponen las diferencias. Por lo tanto, el lector debe leer todos los casos relevantes a la categoría relevante de una brecha para identificar y distinguir todas las medidas correctoras que deben tomarse.
15. La documentación interna de una brecha es una obligación independiente de los riesgos propios de la misma, y debe realizarse en todos y cada uno de los casos. Los casos que se presentan a continuación intentan arrojar algo de luz sobre si se debe notificar o no la brecha a la AC y comunicarlo a los interesados afectados.

2. SECUESTRO DE DATOS (RANSOMWARE)

16. Una causa frecuente de notificación de brecha es un ataque de ransomware sufrido por el responsable del tratamiento. En estos casos, un código malicioso cifra los datos personales y, posteriormente, el atacante solicita al responsable un rescate a cambio del código de descifrado. Este tipo de ataque generalmente se puede clasificar como una brecha de disponibilidad, pero a menudo también puede implicar una brecha de confidencialidad.

CASO 1: Ransomware con respaldo adecuado y sin exfiltración

Los sistemas informáticos de una pequeña empresa de fabricación estuvieron expuestos a un ataque de ransomware y los datos almacenados en sus sistemas se cifraron. El responsable del tratamiento utilizó cifrado en reposo, por lo que todos los datos a los que accedió el ransomware se almacenaron en forma cifrada utilizando un algoritmo de cifrado de última generación. La clave de descifrado no se vio comprometida en el ataque, es decir, el atacante no pudo acceder a ella ni usarla indirectamente. En consecuencia, el atacante solo tuvo acceso a datos personales cifrados. En particular, ni el sistema de correo electrónico de la empresa, ni los sistemas clientes utilizados para acceder a él se vieron afectados. La empresa utiliza la experiencia de una empresa de ciberseguridad externa para investigar el incidente. Se encuentran disponibles los registros que rastrean todos los flujos de datos que salen de la empresa (incluido el correo electrónico saliente). Después de analizar los registros y los datos recopilados por los sistemas de detección, la empresa tras una investigación interna, respaldada por la empresa de ciberseguridad externa determinó con certeza que el agresor solo cifró datos, sin exfiltrarlos. Los registros no muestran ningún flujo de datos hacia el exterior en el período de tiempo que duró el ataque. Los datos personales afectados por la brecha se refieren a clientes y personas trabajadoras de la empresa, unas pocas docenas de personas en total. Una copia de seguridad estaba disponible y los datos se restauraron unas horas después de que tuvo lugar el ataque. La brecha no tuvo consecuencias sobre el funcionamiento diario del responsable del tratamiento. No hubo demoras en los pagos de las personas trabajadoras ni en las respuestas de las solicitudes de los clientes.

17. En este caso, se dieron los siguientes elementos de la definición de "violación de la seguridad de los datos personales": una violación de la seguridad condujo a una alteración ilegal y acceso no autorizado a los datos personales almacenados.

Caso 1. Medidas previas y evaluación de riesgos

18. Al igual que con todos los riesgos que plantean los agentes externos, la probabilidad de que un ataque de ransomware tenga éxito puede reducirse drásticamente si se refuerza la seguridad del entorno de control de datos. La mayoría de estas brechas se pueden prevenir asegurándose de que se han tomado las medidas de seguridad organizativas, físicas y técnicas adecuadas. Ejemplos de tales medidas son la gestión adecuada de parches y el uso de un sistema de detección antimalware adecuado. Tener una copia de seguridad adecuada y en lugar distinto al CPD ayudará a mitigar las consecuencias de un ataque que culmine con éxito, en caso de que ocurra. Además, un programa de formación, capacitación y concienciación sobre seguridad de las personas trabajadoras ayudará a prevenir y reconocer este tipo de ataques. (Se puede encontrar una lista de medidas recomendables en la sección 2.5.) Entre esas medidas, una adecuada gestión de parches que garantice que los sistemas estén actualizados y que todas las vulnerabilidades conocidas de los sistemas implementados estén corregidas es una de las más importantes, ya que la mayoría de los ataques de ransomware explotan vulnerabilidades conocidas.
19. Al evaluar los riesgos, el responsable debe investigar el incidente e identificar el tipo de código malicioso para comprender las posibles consecuencias del ataque. Entre esos riesgos a considerar se encuentra el riesgo de que los datos se hayan exfiltrado sin dejar rastro en los registros de los sistemas.
20. En este ejemplo, el atacante tuvo acceso a datos personales y se comprometió la confidencialidad de la información, pero que contenía datos personales cifrados. Por tanto, cualquier dato que pudiera haber sido exfiltrado no pudo ser leído ni utilizado por el atacante, al menos por el momento. La técnica de cifrado utilizada por el responsable del tratamiento se ajusta al estado de la técnica. La clave de descifrado no se vio comprometida y presumiblemente tampoco se pudo determinar por otros medios. En consecuencia, los riesgos de confidencialidad para los derechos y libertades de las personas físicas se reducen al mínimo si se excluyen los avances criptoanalíticos que hagan inteligibles los datos cifrados en el futuro.
21. El responsable del tratamiento debe considerar el riesgo para las personas debido a la brecha[10]. En este caso, parece que los riesgos para los derechos y libertades de los interesados resultan de la falta de disponibilidad de los datos personales, ya que la confidencialidad de los datos personales no se vió comprometida[11]. En este ejemplo, los efectos adversos de la brecha se mitigaron en bastante poco tiempo después de que ocurriera la misma. Tener un régimen de respaldo adecuado[12] hace que los efectos de la brecha sean menos graves y aquí el responsable del tratamiento pudo hacer un uso eficaz de la copia de seguridad.
22. Sobre la gravedad de las consecuencias para los interesados, solo se pudieron identificar consecuencias menores ya que los datos afectados se restauraron en unas pocas horas, la brecha no tuvo consecuencias en el funcionamiento diario de la actividad del responsable del tratamiento y no tuvo un efecto significativo en los interesados (por ejemplo, pagos de personas trabajadoras o respuestas de solicitudes de clientes).

Caso 1. Mitigación y obligaciones

23. Sin una copia de seguridad, el responsable puede adoptar pocas medidas para remediar la pérdida de datos personales, por lo que los datos deben recopilarse nuevamente. Sin embargo, en este caso particular, el impacto del ataque pudo ser efectivamente contenido restableciendo todos los sistemas comprometidos a un estado limpio que se sabía libre de código malicioso, arreglando las vulnerabilidades y restaurando los datos afectados poco después del ataque. Sin una copia de seguridad, los datos se pierden y la gravedad puede aumentar porque los riesgos o impacto para las personas también pueden hacerlo.
24. La oportunidad de una restauración de datos eficaz a partir de la copia de seguridad disponible es una variable clave al analizar la brecha. La especificación de un plazo de tiempo adecuado para restaurar los datos comprometidos depende de las circunstancias únicas de la brecha en cuestión. El GDPR establece que una violación de la seguridad de los datos personales se notificará sin demoras indebidas y, cuando sea posible, a más tardar después de 72 horas. Por lo tanto, se podría determinar que exceder el límite de 72 horas es desaconsejable, en cualquier caso, pero cuando se trata de casos de alto nivel de riesgo, incluso el cumplimiento de este plazo puede considerarse insatisfactorio.
25. En este caso, tras una evaluación de impacto detallada y un proceso de respuesta a incidentes, el responsable del tratamiento determinó que es poco probable que la brecha suponga un riesgo para los derechos y libertades de las personas físicas, por lo que no es necesaria ninguna comunicación a los interesados, ni tampoco la brecha requiere una notificación para la AC. Sin embargo, como todas las violaciones de datos, debe documentarse de conformidad con el artículo 33, apartado 5. La organización también puede necesitar (o ser requerido posteriormente por la AC) para actualizar y remediar sus medidas y procedimientos organizativos y de seguridad de los datos personales y las medidas y procedimientos de mitigación de riesgos. En el marco de esta actualización y reparación, la organización debe investigar a fondo la brecha e identificar las causas y los métodos utilizados por el atacante para prevenir eventos similares en el futuro.

Acciones necesarias en función de los riesgos identificados
Documentación interna	Notificación a AC	Comunicación a los interesados
-	X	X

CASO 2: Ransomware sin respaldo adecuado

Uno de los ordenadores utilizados por una empresa agrícola estuvo expuesto a un ataque de ransomware y el atacante cifró sus datos. La empresa utiliza la experiencia de una empresa de ciberseguridad externa para supervisar su red. Se encuentran disponibles registros que rastrean todos los flujos de datos que salen de la empresa (incluido el correo electrónico saliente). Tras analizar los registros y los datos con los sistemas de detección, la investigación interna ayudada por la empresa de ciberseguridad determinó que el agresor solo cifró los datos, sin exfiltrarlos. Los registros no muestran ningún flujo de datos hacia el exterior en el período de tiempo del ataque. Los datos personales afectados por la violación se refieren a los empleados y clientes de la empresa, unas pocas docenas de personas en total. No se vieron afectadas categorías especiales de datos. No se disponía de copia de seguridad en formato electrónico. La mayoría de los datos se restauraron a partir de copias de seguridad en papel. La restauración de los datos llevó 5 días hábiles y generó pequeños retrasos en la entrega de los pedidos a los clientes.

Caso 2. Medidas previas y evaluación de riesgos

26. El responsable del tratamiento debería haber adoptado las mismas medidas previas mencionadas en la sección 2.1. y 2.9. La principal diferencia con el caso anterior es la falta de una copia de seguridad electrónica y la falta de cifrado en reposo. Esto conduce a diferencias críticas en los siguientes pasos.
27. Al evaluar los riesgos, el responsable debe investigar el método de infiltración e identificar el tipo de código malicioso para identificar las posibles consecuencias del ataque. En este ejemplo, el ransomware cifró los datos personales sin exfiltrarlos. Como resultado, parece que los riesgos para los derechos y libertades de los interesados resultan de la falta de disponibilidad de los datos personales, la confidencialidad de los datos personales no se ve comprometida. Un examen exhaustivo de los registros del cortafuegos y sus implicaciones es esencial para determinar el riesgo. El responsable del tratamiento debe presentar los resultados fácticos de estas investigaciones cuando se le solicite.
28. El responsable debe tener en cuenta que, si el ataque es más sofisticado, el malware tiene la funcionalidad de editar archivos de registro y eliminar el rastro. Entonces, dado que los registros no se reenvían o replican a un servidor de registro central, incluso después de una investigación exhaustiva que determinó que el atacante no exfiltró los datos personales, el responsable no puede afirmar que la ausencia de una entrada de registro prueba la ausencia de exfiltración, por lo tanto, la probabilidad de una brecha de confidencialidad no puede descartarse por completo.
29. El responsable del tratamiento debe evaluar los riesgos de esta brecha[13], si el atacante accedió a los datos. Durante la evaluación de riesgos, el responsable también debe tener en cuenta la naturaleza, la sensibilidad, el volumen y el contexto de los datos personales afectados en la brecha. En este caso, no se ven afectadas categorías especiales de datos personales, y la cantidad de datos y el número de interesados afectados es bajo.
30. Recopilar información exacta sobre el acceso no autorizado es clave para determinar el nivel de riesgo y prevenir un ataque nuevo o continuo. Si los datos se hubieran copiado de la base de datos, obviamente habría sido un factor de aumento del riesgo. Cuando no esté seguro de los detalles del acceso ilegítimo, se debe considerar el peor escenario y el riesgo se debe evaluar en consecuencia.
31. La ausencia de una copia de respaldo puede considerarse un factor de aumento del riesgo dependiendo de la gravedad de las consecuencias para los interesados resultantes de la falta de disponibilidad de los datos.

Caso 2. Mitigación y obligaciones

32. Sin una copia de seguridad, el responsable puede tomar pocas medidas para remediar la pérdida de datos personales, y los datos deben recopilarse nuevamente, a menos que haya otra fuente disponible (por ejemplo, correos electrónicos de confirmación del pedido). Sin una copia de seguridad, los datos se pueden perder y la gravedad dependerá del impacto para las personas.
33. La restauración de los datos no debería resultar demasiado problemática[14], si los datos aún están disponibles en papel, pero dada la falta de una copia de respaldo electrónica, se considera necesaria una notificación a la AC, ya que la restauración de los datos llevó algún tiempo y podría causar algunos retrasos en la entrega de los pedidos a los clientes y es posible que no se pueda recuperar una cantidad considerable de metadatos (por ejemplo, registros, marcas de tiempo).
34. Informar a los interesados sobre la violación también puede depender del período de tiempo que los datos personales no están disponibles y de las dificultades que podrían causar en el funcionamiento de la actividad del responsable (por ejemplo, retrasos en la transferencia de los pagos de los empleados). Dado que los retrasos en los pagos y entregas pueden suponer un perjuicio económico para las personas cuyos datos se han visto comprometidos, también se podría argumentar que es probable que el incidente genere un alto riesgo. Además, es posible que no sea posible evitar informar a los interesados si su contribución es necesaria para restaurar los datos cifrados.
35. Este caso sirve como ejemplo de un ataque de ransomware con riesgo para los derechos y libertades de los interesados, pero que no alcanza un alto riesgo. Debe documentarse de conformidad con el artículo 33, apartado 5, y notificarse a la AC de conformidad con el artículo 33, apartado 1. La organización también puede necesitar (o ser requerida por la AC) para actualizar y corregir sus medidas y procedimientos organizativos y técnicos de gestión de la seguridad de datos personales y de mitigación de riesgos.

Acciones necesarias en función de los riesgos identificados
Documentación interna	Notificación a AC	Comunicación a los interesados
-	X	X

CASO 3: Ransomware con respaldo y sin exfiltración en un hospital

El sistema de información de un hospital / centro sanitario estuvo expuesto a un ataque de ransomware y el atacante cifró una proporción significativa de sus datos. La empresa utiliza la experiencia de una empresa de ciberseguridad externa para supervisar su red. Se encuentran disponibles registros que rastrean todos los flujos de datos que salen de la empresa (incluido el correo electrónico saliente). Tras analizar los registros y los datos con los sistemas de detección, la investigación interna ayudada con la ayuda de la empresa de ciberseguridad determinó que el atacante solo cifró los datos sin exfiltrarlos. Los registros no muestran ningún flujo de datos hacia el exterior en el período de tiempo del ataque. Los datos personales afectados por la violación se refieren a los empleados y pacientes, que representan a miles de personas. Las copias de seguridad estaban disponibles en formato electrónico.

Caso 3. Medidas previas y evaluación de riesgos

36. El responsable del tratamiento debería haber adoptado las mismas medidas previas mencionadas en la sección 2.1. y 2.5. La principal diferencia con el caso anterior es la gran gravedad de las consecuencias para una parte sustancial de los interesados[15].
37. La cantidad de datos y el número de interesados afectados son elevados, porque los hospitales suelen tratar grandes cantidades de datos. La indisponibilidad de los datos tiene un gran impacto en una parte sustancial de los interesados. Además, existe un riesgo residual de alta gravedad para la confidencialidad de los datos del paciente.
38. El tipo de brecha, la naturaleza, la sensibilidad y el volumen de datos personales afectados son importantes. A pesar de que existía una copia de seguridad y se podría restaurar en unos días, aún existe un alto riesgo debido a la gravedad de las consecuencias para los interesados debido a la falta de disponibilidad de los datos en el momento del ataque y los días siguientes.

Caso 3. Mitigación y obligaciones

39. Se considera necesaria una notificación a la AC, ya que se trata de categorías especiales de datos personales y su restauración podría llevar mucho tiempo, lo que provocaría importantes retrasos en la atención del paciente. Informar a los interesados sobre la violación es necesario debido al impacto para los pacientes, incluso después de restaurar los datos cifrados. Si bien los datos relacionados con todos los pacientes tratados en el hospital durante los últimos años se han cifrado, solo los pacientes que estaban citados para ser tratados en el hospital durante el tiempo que el sistema informático no estuvo disponible se vieron afectados. El responsable del tratamiento debe comunicar la violación de datos a esos pacientes directamente. La comunicación directa con los demás pacientes, algunos de los cuales pueden no haber estado en el hospital durante más de veinte años, puede no ser necesaria debido a la excepción del artículo 34.3. c). En tal caso, habrá en su lugar una comunicación pública[16] o una medida similar mediante la cual los interesados sean informados de manera igualmente efectiva. En este caso, el hospital debería hacer públicos el ataque de ransomware y sus efectos.
40. Este caso sirve como ejemplo de un ataque de ransomware con alto riesgo para los derechos y libertades de los interesados. Debe documentarse de conformidad con el artículo 33, apartado 5, notificarse a la AC de conformidad con el artículo 33, apartado 1, y comunicarse a los interesados de conformidad con el artículo 34, apartado 1. La organización también necesita actualizar y corregir sus medidas y procedimientos técnicos y organizativos de gestión de seguridad de datos personales y de mitigación de riesgos.

Acciones necesarias en función de los riesgos identificados
Documentación interna	Notificación a AC	Comunicación a los interesados
-	-	-

CASO 4: Ransomware sin respaldo y con exfiltración

El servidor de una empresa de transporte público estuvo expuesto a un ataque de ransomware y el atacante cifró sus datos. Según las conclusiones de la investigación interna, el autor no solo cifró los datos, sino que también los exfiltró. El tipo de datos afectados fueron los datos personales de clientes y empleados, y de los varios miles de personas que utilizan los servicios de la empresa (por ejemplo, comprando billetes online). Más allá de los datos de identidad básicos, los números de documentos de identidad y los datos financieros, como los detalles de la tarjeta de crédito, están involucrados en la violación. Existía una copia de respaldo, pero también fue encriptada por el atacante.

Caso 4. Medidas previas y evaluación de riesgos

41. El responsable del tratamiento debería haber adoptado las mismas medidas previas mencionadas en la sección 2.1. y 2.5. Aunque había copia de respaldo, también se vio afectada por el ataque. Este caso por sí solo plantea dudas sobre la calidad de las medidas de seguridad de TI previas del responsable y debe ser examinado más a fondo durante la investigación, ya que, en un sistema de copias de respaldo bien diseñado, múltiples respaldos deben almacenarse de forma segura sin acceso desde el sistema principal, de lo contrario podrían ser comprometidos en el mismo ataque. Además, los ataques de ransomware pueden pasar desapercibidos durante días y cifrar lentamente los datos que se utilizan con poca frecuencia. Esto puede inutilizar múltiples copias de seguridad, por lo que las copias de seguridad también deben realizarse periódicamente y aislarse. Esto aumentaría la probabilidad de recuperación, aunque aumentaría la pérdida de datos.
42. Esta violación se refiere no solo a la disponibilidad de datos, sino también a la confidencialidad, ya que el atacante puede haber modificado y / o copiado datos del servidor. Por lo tanto, el tipo de brecha resulta en un alto riesgo[17].
43. La naturaleza, la sensibilidad y el volumen de los datos personales aumentan aún más los riesgos, porque el número de personas afectadas y la cantidad total de datos personales afectados es elevado. Más allá de los datos de identidad básicos, también están involucrados los documentos de identidad y los datos financieros, como los detalles de la tarjeta de crédito. Una violación de datos relacionada con este tipo de datos presenta un alto riesgo en sí misma, y si se procesan juntos, podrían usarse para entre otros para suplantación de identidad o fraude.
44. Debido a una lógica de servidor defectuosa o controles organizacionales, los archivos de respaldo se vieron afectados por el ransomware, lo que impidió la restauración de datos y aumentó el riesgo.
45. Esta violación de datos presenta un alto riesgo para los derechos y libertades de las personas, porque probablemente podría ocasionar daños materiales (por ejemplo, pérdidas financieras debido a que los datos de la tarjeta de crédito se vieron afectados) y daños morales (por ejemplo, suplantación de identidad o fraude a través del documento de identidad que se vio comprometido).

Caso 4. Mitigación y obligaciones

46. La comunicación a los interesados es fundamental para que puedan tomar las medidas necesarias para evitar daños materiales (por ejemplo, bloquear sus tarjetas de crédito).
47. Además de documentar la brecha de conformidad con el artículo 33.5, en este caso también es obligatoria una notificación a la AC (artículo 33, apartado 1) y comunicar la brecha a los interesados (artículo 34.1). Esto último podría llevarse a cabo persona por persona, pero para las personas en las que los datos de contacto no estén disponibles, el responsable debe hacerlo públicamente, siempre que dicha comunicación no sea susceptible de desencadenar consecuencias negativas adicionales en los interesados, por ejemplo, a través de una notificación en su sitio web. En este último caso, se requiere una comunicación precisa y clara, a la vista en la página de inicio de la web del responsable, con referencias exactas de las disposiciones relevantes del GDPR.

Acciones necesarias en función de los riesgos identificados
Documentación interna	Notificación a AC	Comunicación a los interesados
-	-	-

Medidas organizativas y técnicas para prevenir / mitigar los impactos de los ataques de ransomware

48. El hecho de que se haya producido un ataque de ransomware suele ser una señal de una o más vulnerabilidades en el sistema del responsable. Esto también se aplica en los casos de ransomware en los que los datos personales se han cifrado, pero no se han exfiltrado. Independientemente del resultado y las consecuencias del ataque, hay que enfatizar en la importancia de una evaluación integral del sistema de seguridad de datos, con especial énfasis en la seguridad de TI. Las debilidades y los agujeros de seguridad identificados deben documentarse y solucionarse sin demora.
49. Medidas aconsejables:

(La lista de las siguientes medidas no es de ninguna manera exclusiva ni exhaustiva. Más bien, el objetivo es proporcionar ideas de prevención y posibles soluciones. Cada actividad de tratamiento es diferente, por lo que el responsable debe tomar la decisión sobre qué medidas se ajustan más a la situación dada.)

• Mantener actualizado el firmware, el sistema operativo y el software de la aplicación en los servidores, las máquinas cliente, los componentes de red activos y cualquier otra máquina en la misma LAN (incluidos los dispositivos Wi-Fi). Asegurarse de que se implementen las medidas de seguridad de TI adecuadas, asegurarse de que sean efectivas y mantenerlas actualizadas periódicamente cuando el tratamiento o las circunstancias cambien o evolucionen. Esto incluye mantener registros detallados de qué parches se aplican y en qué marca de tiempo.
• Diseñar y organizar sistemas de tratamiento e infraestructura para segmentar o aislar sistemas y redes de datos para evitar la propagación de malware dentro de la organización y a sistemas externos.
• Disponer de un sistema de copia de seguridad actualizado, seguro y probado. Los medios para la copia de seguridad a medio y largo plazo deben mantenerse separados del almacenamiento de datos operativos y fuera del alcance de terceros, incluso en caso de un ataque exitoso (como una copia de seguridad incremental diaria y una copia de seguridad completa semanal).
• Disponer / obtener un software anti-malware adecuado, actualizado, eficaz e integrado.
• Contar con un cortafuegos y un sistema de prevención y detección de intrusos adecuado, actualizado, efectivo e integrado.
• Dirigir el tráfico de la red a través del cortafuegos / detección de intrusiones, incluso en situaciones de movilidad como por ejemplo el teletrabajo (por ejemplo, mediante el uso de conexiones VPN a los mecanismos de seguridad de la organización al acceder a Internet).
• Formar y capacitar a los empleados sobre los métodos para reconocer y prevenir ataques de TI. El responsable del tratamiento debe proporcionar los medios para determinar si los correos electrónicos y los mensajes obtenidos por otros medios de comunicación son auténticos y fiables. Los empleados deben estar capacitados para reconocer cuándo se ha producido un ataque de este tipo, cómo determinar el punto final de la red y su obligación de informarlo de inmediato al responsable de seguridad.
• Enfatizar la necesidad de identificar el tipo de código malicioso para ver las consecuencias del ataque y poder encontrar las medidas adecuadas para mitigar el riesgo. En caso de que un ataque de ransomware haya tenido éxito y no haya una copia de seguridad disponible, se pueden aplicar herramientas disponibles como las del proyecto “no more ransom” (nomoreransom.org) para recuperar datos. Sin embargo, en caso de que haya disponible una copia de seguridad segura, es recomendable restaurar los datos a partir de ella.
• Reenvío o replicación de todos los registros a un servidor de registros central (posiblemente incluida la firma o el sello de tiempo criptográfico de las entradas del registro).
• Fuerte cifrado y autenticación de múltiples factores, en particular para el acceso administrativo a los sistemas de TI, la gestión adecuada de claves y contraseñas.
• Pruebas de vulnerabilidad y penetración de forma periódica.
• Designar un Equipo de respuesta a incidentes de seguridad informática (CSIRT) o un Equipo de respuesta ante emergencias informáticas (CERT) dentro de la organización, o unirse a un CSIRT / CERT colectivo. Cree un plan de respuesta a incidentes, un plan de recuperación ante desastres y un plan de continuidad comercial, y asegúrese de que se prueben a fondo.
• Al evaluar las contramedidas, el análisis de riesgos debe revisarse, probarse y actualizarse.

3. ATAQUES DE EXFILTRACIÓN DE DATOS

50. Los ataques que aprovechan las vulnerabilidades en los servicios ofrecidos por el responsable a terceros a través de Internet, por ejemplo, cometidos mediante ataques de inyección (por ejemplo, inyección de SQL, cruce de ruta), compromiso de sitios web y métodos similares, pueden parecerse a ataques de ransomware en el sentido de que el riesgo emana de la acción de un tercero no autorizado, pero esos ataques suelen tener como objetivo copiar, exfiltrar y abusar de datos personales para algún fin malicioso. Por lo tanto, se trata principalmente de brechas de confidencialidad y, posiblemente, también de integridad. Al mismo tiempo, si el responsable del tratamiento conoce las características de este tipo de brechas, existen muchas medidas a disposición de los responsables que pueden reducir sustancialmente el riesgo de una ejecución exitosa de un ataque.

CASO 5: Exfiltración de datos de solicitud de empleo de un sitio web

Una agencia de empleo fue víctima de un ciberataque, que introdujo un código malicioso en su sitio web. Este código malicioso hizo que la información personal enviada a través de formularios de solicitud de empleo online y almacenada en el servidor web fuera accesible para personas no autorizadas. 213 de estos formularios posiblemente se vean comprometidos, después de analizar los datos afectados se determinó que no se vieron implicadas categorías especiales de datos en la brecha. El malware instalado tenía funcionalidades que permitían al atacante eliminar cualquier historial de exfiltración y también permitía supervisar el tratamiento en el servidor y capturar datos personales. El kit de herramientas no se descubrió hasta pasado un mes después de su instalación.

Caso 5. Medidas previas y evaluación de riesgos

51. La seguridad del entorno del responsable del tratamiento es extremadamente importante, ya que la mayoría de estos incidentes se pueden prevenir asegurando que todos los sistemas se actualicen constantemente, que los datos sensibles estén cifrados y las aplicaciones se desarrollen de acuerdo con altos estándares de seguridad, como autenticación fuerte, medidas contra la fuerza bruta, ataques, "escape" o "desinfección"[18] entradas de usuario, etc. También se requieren auditorías periódicas de seguridad de TI, evaluaciones de vulnerabilidad y pruebas de penetración para detectar este tipo de vulnerabilidades con anticipación y corregirlas. En este caso particular, las herramientas de supervisión de integridad de archivos en el entorno de producción podrían haber ayudado a detectar la inyección del código malicioso. (En la sección 3.7 se incluye una lista de medidas recomendadas).
52. El responsable del tratamiento siempre debe comenzar a investigar la brecha identificando el tipo de ataque y sus métodos, con el fin de evaluar qué medidas deben tomarse. Para hacerlo rápido y eficiente, el responsable debe tener un plan de respuesta a incidentes que especifique los pasos rápidos y necesarios para tomar el control del incidente. En este caso particular, el tipo de violación fue un factor de aumento del riesgo, ya que no solo se redujo la confidencialidad de los datos, sino que el infiltrado también tenía los medios para establecer cambios en el sistema, por lo que la integridad de los datos también se volvió cuestionable.
53. La naturaleza, la sensibilidad y el volumen de los datos personales afectados por la brecha deben evaluarse para determinar en qué medida la brecha afectó a los interesados. Aunque no se vieron afectadas categorías especiales de datos personales, los datos a los que se accede contienen información considerable sobre las personas a partir de los formularios en línea, y dichos datos podrían usarse indebidamente de varias maneras (segmentación con marketing no solicitado, suplantación de identidad, etc.), por lo que la gravedad de las consecuencias debería aumentar el riesgo para los derechos y libertades de los interesados[19].

Caso 5. Mitigación y obligaciones

54. Si es posible, después de resolver el problema, la base de datos debe compararse con la almacenada en una copia de seguridad segura. Las experiencias extraídas de la brecha deben utilizarse para actualizar la infraestructura de TI. El responsable debe devolver todos los sistemas de TI afectados a un estado limpio conocido, corregir la vulnerabilidad e implementar nuevas medidas de seguridad para evitar violaciones de datos similares en el futuro, por ejemplo, verificaciones de integridad de archivos y auditorías de seguridad. Si los datos personales no solo se extrajeron, sino que también se eliminaron, el responsable debe tomar sistemáticamente medidas para recuperar los datos personales al estado en el que se encontraban antes de la violación. Puede ser necesario aplicar copias de seguridad completas, cambios incrementales y luego posiblemente volver a ejecutar el tratamiento desde la última copia de seguridad incremental, lo que requiere que el responsable pueda replicar los cambios realizados desde la última copia de seguridad.
55. A la luz de lo anterior, dado que es probable que la violación dé lugar a un alto riesgo para los derechos y libertades de las personas físicas, los interesados definitivamente deben ser informados al respecto (artículo 34, apartado 1), lo que, por supuesto, significa que también se debe notificar a la AC. La documentación del incidente es obligatoria según el artículo 33.5 del GDPR y facilita la evaluación de la situación.

Acciones necesarias en función de los riesgos identificados
Documentación interna	Notificación a AC	Comunicación a los interesados
-	-	-

CASO 6: Exfiltración de contraseña hash de un sitio web

Se aprovechó una vulnerabilidad de inyección SQL para acceder a una base de datos del servidor de un sitio web de cocina. Los usuarios solo podían elegir seudónimos arbitrarios como nombres de usuario. Se desaconsejó el uso de direcciones de correo electrónico para este fin. Las contraseñas almacenadas en la base de datos se codificaron con un algoritmo sólido y la sal (bits aleatorios) no se vio comprometida. Datos afectados: contraseñas hash de 1.200 usuarios. Por motivos de seguridad, el responsable del tratamiento informó a los interesados sobre la violación por correo electrónico y les pidió que cambiaran sus contraseñas, especialmente si se utilizaba la misma contraseña para otros servicios.

Caso 6. Medidas previas y evaluación de riesgos

56. En este caso particular, la confidencialidad de los datos se ve comprometida, pero las contraseñas de la base de datos se modificaron con un método actualizado, lo que reduciría el riesgo con respecto a la naturaleza, la sensibilidad y el volumen de los datos personales. Este caso no presenta riesgos para los derechos y libertades de los interesados.
57. Además, no se vio comprometida ninguna información de contacto (por ejemplo, direcciones de correo electrónico o números de teléfono) de los interesados, lo que significa que no existe un riesgo significativo para los interesados de ser blanco de intentos de fraude (por ejemplo, recibir correos electrónicos de suplantación de identidad o mensajes de texto fraudulentos mensajes y llamadas telefónicas). No se comprometieron categorías especiales de datos personales.
58. Algunos nombres de usuario podrían considerarse datos personales, pero el tema del sitio web no admite connotaciones negativas. Aunque debe tenerse en cuenta que la evaluación de riesgos puede cambiar[20], si el tipo de sitio web y los datos a los que se accede pueden revelar categorías especiales de datos personales (por ejemplo, el sitio web de un partido político o sindicato). El uso de cifrado de última generación podría mitigar los efectos adversos de la brecha. Asegurarse de que se permita un número limitado de intentos de inicio de sesión evitará que los ataques de inicio de sesión de fuerza bruta tengan éxito, reduciendo así en gran medida los riesgos que suponen que los atacantes conozcan los nombres de usuario.

Caso 6. Mitigación y obligaciones

59. La comunicación a los interesados en algunos casos podría considerarse un factor atenuante, ya que los interesados también están en condiciones de tomar las medidas necesarias para evitar mayores daños por la violación, por ejemplo, cambiando su contraseña. En este caso, la notificación no era obligatoria, pero en muchos casos puede considerarse una buena práctica.
60. El responsable del tratamiento debe corregir la vulnerabilidad e implementar nuevas medidas de seguridad para evitar violaciones de datos similares en el futuro, como, por ejemplo, auditorías de seguridad sistemáticas en el sitio web.
61. La brecha debe documentarse de conformidad con el artículo 33.5, pero no es necesaria ninguna notificación o comunicación.
62. Además, es muy recomendable comunicar una violación que involucre contraseñas, a los interesados en cualquier caso, incluso cuando las contraseñas se almacenaron utilizando un hash salado con un algoritmo conforme al estado de la técnica. Es preferible el uso de métodos de autenticación que eviten la necesidad de procesar contraseñas en el lado del servidor. Los interesados deben tener la opción de tomar las medidas adecuadas con respecto a sus propias contraseñas.

Acciones necesarias en función de los riesgos identificados
Documentación interna	Notificación a AC	Comunicación a los interesados
-	X	X

CASO 7: Ataque de relleno de credenciales en un sitio web bancario

Un banco sufrió un ciberataque contra uno de sus sitios web de banca online. El ataque tenía como objetivo enumerar todas las posibles identificaciones de usuario de inicio de sesión utilizando una contraseña trivial fija. Las contraseñas constan de 8 dígitos. Debido a una vulnerabilidad del sitio web, en algunos casos se filtró al atacante información sobre los interesados (nombre, apellidos, sexo, fecha y lugar de nacimiento, código fiscal, códigos de identificación de usuario), incluso si la contraseña utilizada no era correcta o la cuenta bancaria ya no está activa. Esto afectó a alrededor de 100.000 clientes. De estos, el atacante inició sesión con éxito en alrededor de 2.000 cuentas que usaban la contraseña trivial probada por el atacante. Después del incidente, el responsable pudo identificar todos los intentos de inicio de sesión ilegítimos. El responsable del tratamiento podría confirmar que, según las comprobaciones antifraude, estas cuentas no realizaron transacciones durante el ataque. El banco estaba al tanto de la violación de datos porque su centro de operaciones de seguridad detectó una gran cantidad de solicitudes de inicio de sesión dirigidas al sitio web. En respuesta, el responsable deshabilitó la posibilidad de iniciar sesión en el sitio web apagándolo y forzó el restablecimiento de la contraseña de las cuentas comprometidas. El responsable del tratamiento comunicó el inciden Tweet Whatsapp