AD 41/2021
RESUMEN: Artículo eminentemente práctico en el que se aborda el tema de las violaciones de seguridad de los datos personales y como debe afrontar una organización un evento de este tipo, dando pautas concretas de como actuar en cada una de las fases en las que se divide una brecha de seguridad: preparación, detección/identificación, análisis/clasificación, proceso de notificación y seguimiento/cierre.
Palabras Clave: Brechas de Seguridad, RGPD, Datos Personales
El artículo 4.12 del RGPD define las brechas de seguridad como:
“Toda violación de seguridad que ocasione la destrucción, pérdida o alteración accidental o ilícita de los datos personales transmitidos, conservados o tratados de otra forma, o la comunicación o acceso no autorizados a dichos datos”.
Un ejemplo de violación de seguridad puede ser el robo a un trabajador de un portátil, en el que contenía un listado con los nombres, apellidos y DNI de los clientes de la empresa.
En este sentido, hay que remarcar que las violaciones de seguridad a la que hace referencia el RGPD, están siempre relacionada con la destrucción, pérdida, alteración… en relación con datos de carácter personal, es decir, con información que identifique o pueda identificar a personas físicas (Art. 4.1 RGPD). Por ejemplo, en el caso del robo de un portátil sin contener ningún tipo de información de carácter personal no se consideraría una brecha de seguridad. Por lo tanto, debe quedar claro que, la “violación” a la que hace referencia el RGPD, solo se aplica en la medida en que afecte a datos de carácter personal, y en consecuencia dicho incidente pueda comprometer al Responsable del tratamiento en el cumplimiento de los principios del RGPD.
Para conocer como gestionar una brecha de seguridad, tendremos que acudir al artículo 33 del RGPD:
“1. En caso de violación de la seguridad de los datos personales, el responsable del tratamiento la notificará a la autoridad de control competente de conformidad con el artículo 55 sin dilación indebida y, de ser posible, a más tardar 72 horas después de que haya tenido constancia de ella, a menos que sea improbable que dicha violación de la seguridad constituya un riesgo para los derechos y las libertades de las personas físicas. Si la notificación a la autoridad de control no tiene lugar en el plazo de 72 horas, deberá ir acompañada de indicación de los motivos de la dilación.
2. El encargado del tratamiento notificará sin dilación indebida al responsable del tratamiento las violaciones de la seguridad de los datos personales de las que tenga conocimiento.
3. La notificación contemplada en el apartado 1 deberá, como mínimo:
a) describir la naturaleza de la violación de la seguridad de los datos personales, inclusive, cuando sea posible, las categorías y el número aproximado de interesados afectados, y las categorías y el número aproximado de registros de datos personales afectados;
b) comunicar el nombre y los datos de contacto del delegado de protección de datos o de otro punto de contacto en el que pueda obtenerse más información;
c) describir las posibles consecuencias de la violación de la seguridad de los datos personales; d) describir las medidas adoptadas o propuestas por el responsable del tratamiento para poner remedio a la violación de la seguridad de los datos personales, incluyendo, si procede, las medidas adoptadas para mitigar los posibles efectos negativos.
4. Si no fuera posible facilitar la información simultáneamente, y en la medida en que no lo sea, la información se facilitará de manera gradual sin dilación indebida.
5. El responsable del tratamiento documentará cualquier violación de la seguridad de los datos personales, 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 de lo dispuesto en el presente artículo.”
Una violación de seguridad pasa por diversas etapas desde su notificación e identificación hasta que se le da respuesta y solución. Es importante considerar cuales son las metas a cumplir en cada una de ellas y seguir el flujo establecido, evidentemente con una cierta adaptación a las particularidades que establece la diversidad de tipología de los incidentes.
La “Guía sobre brechas de seguridad” publicada por la Agencia Española de Protección de Datos considera que, en gran medida, todo Proceso de Gestión de Incidentes pasa por los siguientes pasos:
A continuación, iremos analizando cada uno de estos apartados:
- Preparación:
La capacidad de respuesta de una organización ante incidentes de seguridad dependerá en gran medida de su capacidad para prevenirlos y estar preparado para hacerles frente. Además del establecimiento de los controles de seguridad sobre los sistemas, redes y aplicaciones de la organización, es necesario que se consideren todas aquellas acciones formativas, logísticas y técnicas que faciliten una respuesta rápida, efectiva y eficiente ante los incidentes de seguridad que se puedan producir. La experiencia, organización y conocimiento de los servicios de tecnologías de la información y de las amenazas a las que éstos se enfrentan son claves para una gestión de incidentes que minimice los impactos en los procesos de negocio, para ello es importante:
- Elaborar una tipología de posibles incidentes para cada sistema concreto.
- Elaborar una tipología de posibles incidentes para cada sistema concreto.
- Elaborar planes de respuesta ante incidentes para cada escenario definido.
- Mantener las políticas y procedimientos actualizados. Especialmente todos los relativos a gestión de incidentes, recogida de evidencias, análisis forense o recuperación de sistemas.
- Asignar funciones y tareas para cada tipo de incidente previsto.
- Prever la disponibilidad de los recursos técnicos y personales destinados a la resolución de incidentes.
- Realizar simulacros ante incidentes de seguridad.
La prevención es vital para intentar minimizar el número y/o el impacto de los incidentes que, finalmente, se pueden materializar. Las tareas preventivas suelen ir íntimamente ligadas al seguimiento tanto de las amenazas y vulnerabilidades fuera de la Organización, como aquellas identificadas dentro de la Organización relacionadas con incidentes previos. Podemos englobar entre otras las siguientes tareas:
- Análisis y Gestión del Riesgo, que permita disponer de un plan de tratamiento de riesgos que permita controlarlos pudiendo ser mitigados, transferidos o aceptados.
- Formación y concienciación del personal en buenas prácticas del uso de los recursos, TIC y en la forma de actuar cuando se identifica un posible incidente de seguridad, para mejorar las capacidades técnicas y operativas.
- Notificación de nuevas vulnerabilidades en los productos utilizados en la Organización.
- Difusión de avisos sobre la existencia de nuevas o inminentes amenazas tales como código malicioso de alta difusión (gusanos, troyanos, etc.).
- Recomendaciones de la aplicación de medidas de protección o identificación ante situaciones excepcionales.
Como conclusión, se considera que esta fase de prevención y preparación puede mejorar substancialmente tanto la seguridad TIC de la Organización como la capacidad de respuesta ante incidentes en relación con los activos de Información.
- Detección e identificación:
Los incidentes de seguridad pueden ser detectados de forma casual, como resultado de una auditoría, por la monitorización de los sistemas o mediante la utilización de los Sistemas de Información por parte de los usuarios. Al inicio del incidente es necesario proporcionar información suficiente que permita responder en la medida de lo posible tanto cualitativamente como cuantitativamente las siguientes cuestiones:
- ¿Qué ha sucedido o cuáles son los signos de alerta?
- ¿Dónde ha ocurrido?
- ¿Cuándo se produjo?
- ¿Cómo o en qué circunstancias?
- ¿Por qué se ha producido o cuál es su origen?
Al producirse un incidente de seguridad, éste no siempre es notificado de manera inmediata bien sea porque se carecen de los mecanismos de detección necesarios o incluso por el propio desconocimiento de los mecanismos de comunicación ante incidentes de las personas que lo detectan. Esta norma trata de evitar esta deficiencia. La detección es un momento crítico en cualquier incidente porque cuanto más tarde se produzca esta situación, junto con el tiempo necesario para que su notificación llegue al personal de respuesta, el impacto puede ser mayor en los sistemas de información de la organización. Es lo que se conoce como detección temprana. Los mecanismos de detección pueden ser manuales o automáticos. Los manuales han sido notificados directamente por un usuario o gracias a un mecanismo de alerta o auditoría revisado por este, y automáticos se identifican mediante un sistema de detección que utiliza software como sistemas de detección de intrusiones o un sistema de gestión de eventos (por ejemplo, un Data Lose Prevention (DLP), se trata de un software de prevención de pérdida de datos).
- Análisis y clasificación:
Con el análisis se intentará obtener la información suficiente como para responder gran parte de las incógnitas del incidente que debe permitir afrontar su resolución. Contribuye de manera sustancial al análisis, el conocimiento de los parámetros y configuración del Sistema afectado, así como las medidas de seguridad implantadas en el Sistema. En el proceso de investigación destaca el contenido de los archivos de registro de eventos (log) local o bien remotos si existe un punto de recogida centralizado, estos últimos agilizan el análisis de los mismos y suele proporcionar una garantía de que estos no han sido modificados. Se debe guardar una descripción detallada de cada evidencia recogida, incluyendo:
- Datos de identificación
- Personal que ha recogido la prueba
- Fecha y hora de recogida
- Lugar de almacenamiento de la prueba
- Metodología seguida
- Mecanismos de autenticación y custodia aplicados, entre otras cuestiones.
Deberá evitarse la manipulación directa de los soportes de información y de los sistemas, trabajando, siempre que sea posible, sobre las copias de las evidencias para evitar la pérdida irreversible de los datos iniciales. En la recogida de evidencias, son de especial importancia las de tipo volátil, por ejemplo, el estado de las conexiones de red, procesos, sesiones abiertas, ficheros abiertos, contenido de la memoria dinámica, etc. Se deberá documentar, con los medios disponibles (fotografía, impresora, vídeo, etc.), todas las acciones que se realicen sobre los Sistemas.
Se deberá estudiar en detalle todas las evidencias recogidas y tras múltiples fases de análisis, siguiendo las normas descritas, se podrá llegar a resolver todas las cuestiones que permitan abordar su resolución y la recuperación de los Sistemas al estado anterior a la materialización del incidente
- Proceso de notificación:
Independientemente de las notificaciones internas que se deban producir y gestionar internamente para el correcto desarrollo de los incidentes, el RGPD establece que en caso de brecha de seguridad de los datos personales, el Responsable del tratamiento la notificará a la autoridad de control competente sin dilación indebida, y de ser posibles, en un plazo máximo de 72 horas desde que haya tenido constancia de la misma, a menos que la misma no constituya ningún riesgo para los derechos y libertades de las personas físicas implicadas.
Además, el RGPD también establece los casos en los que una brecha de seguridad se debe comunicar al afectado, como ahora veremos.
¿En qué supuestos se considera que no existe ningún riesgo para los derechos y libertades de las personas físicas implicadas? Y por lo tanto, no sea necesario notificar a la autoridad de control.
No hay un listado de supuestos, ni siquiera en los que resulte obligatoria la notificación, es por ello que, el Responsable de forma interna deberá valorar si la violación de seguridad ha supuesto un riesgo para los derechos y libertades de las personas físicas implicadas. La Guía sobre brechas de seguridad de la AEPD te pone los siguientes ejemplos ilustrativos para conocer las diferencias:
- El responsable ha tomado medidas técnicas y organizativas adecuadas, como que los datos no sean inteligibles para personas o máquinas no autorizadas con anterioridad a la brecha de seguridad de datos personales (mediante el uso de: cifrados de datos de última generación, minimización, disociación de datos, acceso a entornos de prueba sin datos reales, etc.).
- Por ejemplo, es probable que no sea necesaria la notificación si se pierde un dispositivo móvil y los datos personales que contiene están cifrados. Sin embargo, sí que es posible que se requiera de notificación si esta fuera la única copia de los datos personales, o por ejemplo, la clave de cifrado en posesión del responsable estuviera comprometida.
- El responsable ha tomado con posterioridad a la brecha de seguridad de datos personales las medidas de protección que mitiguen total o parcialmente el posible impacto para los afectados y garanticen que ya no hay posibilidad de que el alto riesgo se materialice. Por ejemplo, mediante la identificación y puesta en marcha inmediatamente de las medidas contra la persona que ha accedido a los datos personales antes de que pudieran hacer algo con ellos.
El Responsable del tratamiento deberá articular una política interna sobre violaciones de seguridad de los datos personales con la finalidad de tener un criterio común dentro de la organización que nos permita conocer la forma de actuar antes los diferentes escenarios que puedan ocasionarse con motivo de una brecha de seguridad.
¿En qué supuestos habrá que notificar la brecha también a los interesados?
Al igual que la comunicación a la Autoridad de Control, el Responsable del tratamiento deberá valorar si es necesario comunicar estos hechos a los afectados, en los casos en los que exista un alto riesgo para los derechos y libertados de estos. Por lo tanto, la organización deberá articular mecanismos que le permitan tener un criterio para saber en que supuestos deben comunicar a los interesados estos hechos. La AEPD en la Guía sobre Brechas de Seguridad dice lo siguiente sobre los factores a tener en consideración:
- Cuáles son las obligaciones legales y contractuales de la organización.
- Riesgos que comporta la pérdida de los datos: daños físicos, daños reputacionales etc.
- Existe un riesgo de suplantación de identidad o fraude (en función del tipo de información que se ha visto afectada y teniendo en cuenta si la información estaba accesible).
- Hasta qué punto la persona afectada puede evitar o mitigar posibles daños posteriores.
Por lo tanto, la AEPD considera que, si después del análisis correspondiente prevé que la comunicación a los interesados podría comprometer el resultado de una investigación en curso, la comunicación podría no tener que producirse, o posponerse.
Una vez que hemos analizado los supuestos en los que será necesaria la notificación de la brecha de seguridad tanto a las autoridades de control, como a los interesados, pasemos a abordar la notificación de una brecha de seguridad a la autoridad de control.
Como hemos comentado, tan pronto como el responsable tenga conocimiento de que se ha producido una brecha de seguridad, y la misma afecta significativamente a los derechos y libertades de los interesados, el Responsable deberá notificar estos hechos a la Autoridad de Control correspondiente en un plazo máximo de 72 h (artículo 33 RGPD). Se considera que se tiene constancia de una brecha de seguridad cuando hay una certeza de que se ha producido y se tiene conocimiento suficiente de su naturaleza y alcance.
La AEPD en la Guía sobre brechas de seguridad publica un modelo de comunicación de brechas de seguridad:
En el siguiente enlace puede ampliar la información sobre este formulario (anexo 2): https://www.aepd.es/sites/default/files/2019-09/guia-brechas-seguridad.pdf.
Este formulario deberá contener la siguiente información:
- Describir la naturaleza de la brecha de seguridad, y si es posible las categorías y el número aproximado de interesados afectados. Por ejemplo: Se ha producido un ataque ransomware contra la organización en el que se han visto expuestas contraseñas de 400 trabajadores de la empresa, viéndose afectados datos identificativos básicos (nombre, apellidos, email, DNI…)
- Comunicar el nombre y los datos de contacto del delegado de protección de datos o de otro punto de contacto que pueda obtenerse más información.
- Describir las posibles consecuencias de la violación de seguridad de los datos personales. Siguiendo el hilo del ejemplo anterior: las consecuencias del ataque dirigido a los trabajadores pueden ocasionar que los datos personales de los trabajadores acaben en manos de terceros, produciéndose numerosas infracciones de la normativa vigente, habría que ver esas “posibles” consecuencias y sus posibilidades reales de provocar esos daños.
- Describir las medidas adoptadas o propuestas por el Responsable para mitigar los riesgos y las posibles consecuencias para los interesados. Siguiendo con el ejemplo anterior: Se debería cambiar la contraseña automáticamente de los 400 trabajadores para evitar posibles accesos por los detonantes del ataque.
En aquellos supuestos, en los que toda esta información no pueda ofrecerse de forma simultánea a la presentación de la comunicación ante la Autoridad de Control, se irá entregando de forma gradual, a medida que se vaya recibiendo.
- Seguimiento y cierre:
En esta fase se deben dar todos los pasos necesarios para que el incidente quede resuelto. Un incidente se considera resuelto cuando se ha restablecido toda la información y los recursos afectados, por lo tanto, se opera con normalidad dentro de la organización, y se tiene un conocimiento de lo que ha pasado, por qué ha pasado y las pérdidas ocasionadas.
En esta fase se valorará la adopción de las siguientes acciones:
- Determinar las causas y naturaleza de la violación de seguridad, acompañada de una serie de medidas de mitigación eficaces.
- Comprobar que se ha remediado el problema y que no se están produciendo daños para los afectados.
- Realización de un informe final sobre la brecha de seguridad: El Responsable del tratamiento o en quien tenga delegadas dichas funciones, comprobará que las medidas correctoras adoptadas son adecuadas para la resolución de la brecha y para minimizar el riesgo en caso de que se produzca otra de similares características. Dicho informe final recopilará toda la información y documentación relativa a la brecha de manera que se facilite el estudio y la revisión por terceros.
Una vez finalizadas las fases descritas, se tendrá que llevar a cabo por parte de la organización un periodo de reflexión y mejora (con la colaboración de las partes implicadas), y se evaluarán mediante la recopilación y análisis de todas las informaciones obtenidas en cada una de las fases anteriores del proceso, todo ello, puede aportar nuevas conclusiones que permitan mejorar el nivel de seguridad de la organización.
Dentro de este momento final, es de vital importancia que la organización disponga de un registro documentado con todas las violaciones de seguridad de los datos personales, y que incluyan toda la información recopilada, y además, esta documentación permitirá demostrar el cumplimiento a la organización (artículo 33 del RGPD).
Marcos Rubiales
26 de marzo de 2021
PERFIL PROFESIONAL
Marcos Rubiales Olmedo es graduado en Derecho y Ciencias Políticas, con gran interés por el mundo de la abogacía y especialmente en el Derecho de las Nuevas Tecnologías, motivado por ámbitos como: Propiedad Intelectual, Patentes y Marcas, Comercio Electrónico, contratos informáticos, y en especial en la Protección de Datos de carácter personal, habiendo realizado el Curso de Delegado de Protección de Datos de Aranzadi (programa formativo que cumple con los requisitos establecidos en el esquema de certificación de la Agencia Española de Protección de Datos).
También he desempeñado labores relacionadas con el Derecho Civil (incluyendo Derecho de Familia), Derecho Penal y Derecho Mercantil. Resumen de cualificaciones
PERFIL DIGITAL : Linkedin
