NOTIFICACIÓN DE LAS VIOLACIONES DE SEGURIDAD EN EL RGPD
Como ya vimos en un post anterior, en el Blog del DPD de la AEC, la obligación de notificar las violaciones de seguridad supone ahora disponer de un proceso maduro y protocolizado de gestión de incidentes. Tal como establece la propia definición en el RGPD, una “violación de datos” será cualquier incidente en materia de seguridad de la información que afecte a datos de esta naturaleza, entendido esto como eventos que puedan ocasionar 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. En materia de seguridad de la información, son eventos que impactan en las tres dimensiones: confidencialidad, integridad o disponibilidad.
La primera reflexión a considerar es que cuando deba iniciarse el proceso de notificación de la violación de seguridad ya se estará en una situación de fracaso, desde la perspectiva de la protección de datos. Este tipo de medidas, la notificación, se encuadran dentro de las estrategias de respuesta ante un incidente y suponen la materialización de un riesgo. Con esto queremos incidir en que ya se ha producido un daño (Inicialmente sin valorar probablemente) y se evidencia así el fracaso en la proactividad y prevención de incidentes. Por tanto, ante tales circunstancias, la organización afectada ya será cuestionada respecto a la debida diligencia en la protección y de no reaccionar rápido ante los hechos, también será cuestionada en la agilidad y diligencia frente a la respuesta ante el incidente. Por tanto, el principal objetivo de la organización y la principal preocupación del DPO debe ser que este procedimiento de notificación no tenga que ejecutarse nunca. En este caso, la ausencia de incidentes es la mayor evidencia del trabajo bien hecho en la prevención.
La segunda reflexión incide en qué requisitos deben darse para lograr una respuesta ágil y rápida frente al incidente. En muchos casos, el tiempo es un factor que incrementa el impacto (Sucede con otros eventos físicos como el fuego) y en donde el primer objetivo de la respuesta es la contención y mitigación de la amenaza, es decir, reducir al máximo el tiempo en el que ésta nos está causando daño. En casos de violaciones de seguridad y según las circunstancias en las que esta se produzca, lo primero es localizar el foco de impacto y si está todavía operativo, lograr que cese a la mayor brevedad posible para que el daño sea el menor posible.
Toda organización que se precie debiera tener control sobre sus sistemas de información. En este sentido, la monitorización del funcionamiento es una actividad básica para la gestión y control de los sistemas de información. Las tres dimensiones de la seguridad no se comportan igual frente a los daños. En cada caso, el proceso de gestión de incidentes requiere acciones muy diferentes según el tipo de amenaza y sobre qué dimensión se produce.
Centrándonos ya en la nueva exigencia respecto a la notificación de incidentes, para que pueda ser realizada y se pueda proporcionar la información que establece el artículo 33, la organización debe tener implantado un proceso de gestión de incidentes[1] completo. Ello implica que la organización, ante una violación de seguridad, contempla las siguientes actividades:
- Detección y notificación del incidente: se tiene establecido un protocolo interno para recibir este tipo de incidencias y un proceso de escalado que informa a los diferentes actores que deben estar preparados o participarán en la respuesta.
- Triaje: cuyo objetivo es la valoración de los hechos, su categorización, prioridad y asignar los responsables encargados de gestionar la respuesta. Esta actividad es clave para una gestión eficaz puesto que, en muchos casos, cuanto menor es el tiempo en que la amenaza nos afecta, menores son los impactos. En muchos informes forenses de los incidentes más notorios de estos últimos tiempos relacionados con fugas de información, el atacante ha estado durante meses dentro de los sistemas sin ser detectado. Es por ello que se añade ahora la persistencia a este nuevo tipo de amenazas denominadas APT (Advanced Persistent Threat).
- Análisis: se centra en el intento de determinar qué ha podido suceder, qué impacto ha causado o podría causar y establecer las acciones a emprender como respuesta.
- Respuesta: supone ya ejecutar, una vez focalizado el problema, una serie de tareas o iniciar un conjunto de protocolos que tengan como efecto la mitigación del incidente y la recuperación de la normalidad. Siempre deben incluir un análisis de causas y una incorporación de mejoras para evitar que el incidente pudiera repetirse.
Para poder implantar estas fases mencionadas, la organización debe reunir una serie de requisitos que serán herramientas en la prevención de incidentes pero que luego serán fundamentales para la reacción y respuesta. Las organizaciones deberían contar inicialmente con:
- Monitorización de los sistemas y vigilancia del comportamiento de los mismos.
- Entornos de generación de evidencias para permitir el posterior análisis. Es curioso la falta en la regulación nacional de la obligación de dejar trazabilidad de ciertas operaciones, como base para facilitar el posterior proceso de investigación. Este, el tema de las evidencias digitales, es una de las asignaturas pendientes que deberían regularse para garantizar que existe trazabilidad y se puede garantizar el análisis informático forense en los entornos.
- Personal capacitado para hacer análisis informático forense que pueda averiguar las causas de lo sucedido y lo más importante, obtener lecciones aprendidas para que no se repita.
Supongo que el lector, a estas alturas, estará descubriendo otros aspectos que el RGPD ha querido robustecer y que a priori, no parecen tan evidentes. Una primera lectura del artículo 33 y 34 nos llevaría a pensar que simplemente hay que enviar un escrito o bien a la Autoridad de control o al afectado, pero la clave, es el contenido del informe. Para poder conocer qué ha pasado y cuáles pueden ser los daños, hay que garantizar unas capacidades operativas en materia de gestión de la seguridad de la información.
Por concluir, si se quiere profundizar en la materia, la gestión de incidentes de seguridad, recomiendo recurrir a las buenas prácticas ya existentes. En concreto, dos referencias claras:
- ISO/IEC 27001:2013, que dedica el bloque de control 16, Gestión de incidentes de seguridad y que incluye los siguientes controles:
- 1.1 Responsabilidades y procedimientos: Se deberían establecer las responsabilidades y procedimientos de gestión para garantizar una respuesta rápida, eficaz y ordenada a los incidentes de seguridad de la información.
- 1.2 Notificación de los eventos de seguridad de la información: Los eventos de seguridad de la información se deberían informar lo antes posible utilizando los canales de administración adecuados.
- 1.3 Notificación de puntos débiles de la seguridad: Se debería requerir anotar e informar sobre cualquier debilidad sospechosa en la seguridad de la información en los sistemas o servicios tanto a los empleados como a contratistas que utilizan los sistemas y servicios de información de la organización.
- 1.4 Valoración de eventos de seguridad de la información y toma de decisiones: Se deberían evaluar los eventos de seguridad de la información y decidir su clasificación como incidentes.
- 1.5 Respuesta a los incidentes de seguridad: Se debería responder ante los incidentes de seguridad de la información en atención a los procedimientos documentados.
- 1.6 Aprendizaje de los incidentes de seguridad de la información: Se debería utilizar el conocimiento obtenido del análisis y la resolución de incidentes de seguridad de la información para reducir la probabilidad y/o impacto de incidentes en el futuro.
- 1.7 Recopilación de evidencias: La organización debería definir y aplicar los procedimientos necesarios para la identificación, recopilación, adquisición y preservación de la información que puede servir de evidencia.
- ISO/IEC 27035:2016, que se centra en la gestión de incidentes de seguridad y que se compone de dos partes:
- ISO/IEC 27035-1:2016. Information technology — Security techniques — Information security incident management — Part 1: Principles of incident management
- ISO/IEC 27035-2:2016. Information technology — Security techniques — Information security incident management — Part 2: Guidelines to plan and prepare for incident response
Los que llevamos muchos años en la materia de la seguridad de la información sabemos que es complejo definir cuál es el retorno de inversión en prevención. Tenemos que cuantificar riesgos y sugerir medidas a implantar basándonos en hechos que potencialmente podrían suceder pero que no sabemos si llegarán a ocurrir. Para la Dirección de una organización es tentador hacer caso omiso a los riesgos cuando no está muy claro el retorno de inversión y cuando, además, son amenazas no tangibles que siempre parecen de ciencia ficción. El “nunca pasa nada” es una respuesta habitual con la confianza de que, aunque pase, probablemente no será conocido. Este nuevo escenario introducido por la notificación obligatoria, que ya funciona en otros ámbitos de la seguridad ahora podrá forzar a replantearse las estrategias de muchas organizaciones.
Javier Cao – Cumbre AEC 2018 – DPD
La seguridad en el RGPD. Referencia especial a las vulneraciones de seguridad
[1] Detalles en Defining Incident Management Processes for CSIRTs (http://resources.sei.cmu.edu/library/asset-view.cfm?assetid=7153)
Javier Cao Avellaneda
IT Risk Leader at GOVERTIS Advisory Services
Expertos en Ciberseguridad, Privacidad, IT GRC y Cumplimiento Normativo unificando la perspectiva Legal y Tecnológica.
