Herramientas de ayuda para el Data Protection Officer (1)

Una de las críticas más comunes de los responsables técnicos de la seguridad en las empresas hacia la normativa de protección de datos de carácter personal, hace referencia a la carencia de detalle y ambigüedad de la normativa en cuestiones técnicas.  Desde un punto de vista de seguridad de la información, es cierto que ni la directiva Europea, ni la Ley ni el reglamento que la desarrollan son de mucha ayuda para un responsable a la hora de implantar un programa de medidas técnicas de protección de datos. En este sentido, cada responsable deberá echar mano de distintos estándares de seguridad y suplir con su experiencia las carencias técnicas referidas.

Con este post vamos a iniciar una serie de artículos en los que desarrollaremos una metodología para la implantación de un programa efectivo de protección de datos. Se trata de una metodología desarrollada a partir de la experiencia propia, aunque tiene cierto carácter experimental. Invitamos a los interesados a compartir con nosotros mejoras, sugerencias o a adaptarlo libremente. Esperemos que sea de utilidad para todos aquellos que tengan que desempeñar la función de Data Protection Officer. La metodología presentada es de aplicación en todo tipo de empresas u organismos públicos sea cual sea su tamaño.

Las fases de dicha metodología implican las siguientes actividades:

  • Mantener un inventario con los tratamientos de datos personales que han de formar parte del alcance del programa de medidas de seguridad.
  • Analizar los riesgos en cada tratamiento; definir los requisitos de seguridad e identificar las eventuales acciones necesarias para asegurar estos requisitos.
  • Implantar las medidas técnicas y organizativas necesarias y corregir las eventuales deficiencias de control identificadas.
  • Monitorizar periódicamente:
    • La efectividad del marco de control implantado (identificando eventuales deficiencias que será necesario corregir).
    • La necesidad de incluir nuevos tratamientos en el programa, o de realizar los ajustes necesarios como consecuencia de cambios en los procesos.

Identificación de los procesos de tratamiento de información relevantes

El primer objetivo de un programa efectivo de protección de datos es identificar todos los tratamientos de información relevantes desde la perspectiva del reglamento de protección de datos. Esta fase tendrá como resultado principal la creación de un inventario lo más detallado posible de los procesos, sistemas e instancias de ficheros con datos personales que van a constituir el alcance de nuestro programa de seguridad.

Dado que los tratamientos de datos personales no son otra cosa sino procesos de negocio o administrativos, es factible usar para esta actividad cualquiera de los distintos lenguajes de modelado de procesos existentes (UML y sus extensiones para modelado de procesos de negocio, IDEF ó BPMN), aunque es también posible dependiendo de las circunstancias usar descripciones textuales estructuradas.

Desde la perspectiva de nuestro objeto de estudio, las ventajas de una documentación formal son:

  1. Permitirá identificar de manera sistemática todas las posibles instancias de ficheros de datos personales a proteger, ayudando a que no queden elementos desprotegidos. A veces ocurre que en un proceso se crean copias temporales de los datos como paso previo a la obtención del fichero principal. Es muy frecuente que este último esté claramente identificado y protegido, mientras que el fichero temporal quede en el “olvido” y desprotegido.
  2. Identificar todas las computadoras, sistemas, aplicaciones, almacenamientos físicos y ubicaciones relacionados con el proceso.
  3. Identificar posibles terceros encargados del tratamiento, no identificados a priori, a los que habrá que exigir que apliquen las debidas medidas de seguridad en sus instalaciones.
  4. Ayudar en el proceso de identificación de escenarios de riesgo, vulnerabilidades y definición de controles de seguridad.
  5. Facilitar la mejora de los procesos de tratamiento de datos, de modo que se optimice el coste de las medidas a implantar y se minimicen las vulnerabilidades
  6. El resultado final es un modelo fácil de entender y de validar.

En este post usaremos un lenguaje gráfico de modelado de procesos simplificado, fácil de entender y manejar. Se trata de un formalismo adaptado a las características concretas de los procesos de tratamiento de datos. Cada proceso se describe mediante una serie de elementos del proceso, tal como se muestra a continuación:

DIAG_DPO_01

Lenguaje de Modelado de Tratamientos de Datos

Analicemos brevemente los tipos de elementos usados en el diagrama:

Proceso

DIAG_DPO_02_01

Representa una actividad  o grupo de actividades, realizadas manual o automáticamente. Los procesos son básicamente funciones de transformación de datos en información. El destino de esta información así transformada puede servir como output de otro proceso o ser almacenada en un repositorio de información.

Interviniente

DIAG_DPO_02_02

Este elemento se usa para representar e identificar a las personas que intervienen en la ejecución de un proceso. Es importante notar que un interviniente puede ser una persona física o jurídica e incluso un programa de software. Se distinguen dos tipos de intervinientes: el “responsable” del proceso y el “participante”, éste último rol se usa para identificar a personas que sin ser responsables funcionales del proceso supervisan el proceso o realizan alguna acción concreta.

Flujos de Información

DIAG_DPO_02_03

Se representan gráficamente como flechas que “entran” o “salen” de los procesos. Dado que los procesos son concebidos básicamente como funciones de transformación de datos, los flujos de información hacen referencia a las fuentes de datos de entrada del proceso y a las salidas de información.

Instancias de Datos

DIAG_DPO_02_04

Este elemento gráfico representa una instancia concreta de datos de carácter personal que interviene en el proceso. Se usa para representar tanto datos en formato digital como físico. El elemento tiene varios campos de información que hacen referencia a distintos aspectos de la instancia de datos:

DIAG_DPO_02_05

Eventos

Un aspecto importante a tener en cuenta con respecto a las instancias de datos es que éstas no representan tan sólo un fichero informático o físico estático, sino que hace referencia además a otros aspectos relacionados con el procesamiento de los datos, como pueden ser los medios empleados para acceder y manipular la información. Por ello, en nuestro lenguaje formal de modelado de procesos, estos elementos son susceptibles de  recibir y responder a eventos. Los eventos se representan mediante una flecha punteada etiquetada con la descripción del evento. La flecha sale de la instancia receptora del evento y termina en la misma instancia o en otra nueva generada como consecuencia del mismo. Por ejemplo:

Creación de una copia adicional de un fichero local cuyo destino es un servidor de archivos remoto:

DIAG_DPO_02_06

Cualificadores

Un cualificador es un símbolo variable inscrito en un recuadro que se sobrepone a flujos o eventos, de cara a proporcionar mayor información. Por ejemplo, para indicar que el evento de envío se realiza a través de Internet o una red privada externa.

DIAG_DPO_02_07

Conectores

Se usan para facilitar el conectar un diagrama con otro, de modo que en el caso de procesamientos más complejos éstos puedan ser representados en diferentes diagramas.

Indicadores de Secuencia

Son números que se usan para ayudar a entender la secuencia en la que se lleva a cabo el procesamiento del flujo de información.

De cara a que el esfuerzo invertido en la documentación sea el mínimo imprescindible, es importante mantener en los modelos un nivel de detalle adecuado que permita por un lado identificar y representar todas las instancias de datos que intervienen en el proceso, pero evitando desglosar los flujos de actividades innecesariamente. No hay que olvidar que en este ejercicio el foco son los ficheros de datos y los sistemas de procesamiento y no una descripción exhaustiva de cada decisión y paso concreto del proceso.

A continuación vamos a poner a prueba nuestro lenguaje formal de modelado de procesos, aplicándolo a un caso práctico real:

DIAG_DPO_03

El proceso descrito consiste en el tratamiento de los formularios de suscripción publicados en la prensa y que los clientes remiten por correo a una empresa encargada del tratamiento. Diariamente el personal esta empresa recoge la documentación recibida y la lleva a la sala de back Office donde se procede a su digitalización y lectura mecanizada del contenido manuscrito de los formularios mediante tecnología OCR (reconocimiento óptico de caracteres). Como resultado de este proceso, en el servidor de back Office de la empresa, se genera por cada formulario un fichero plano (Nuevos Clientes) que contiene los datos reconocidos por el OCR, así como un archivo PNG con la imagen de cada formulario. Estos ficheros son enviados por sFTP al servidor de la empresa cliente que es responsable de los datos. Allí una tarea programada desencadena el proceso encargado de incluir en base de datos del servidor 194.23.45.55, los datos de los nuevos clientes y en formato blob copia de las imágenes de los formularios. Una vez confirmado el proceso, la empresa encargada del tratamiento se encarga de enviar por valija física a una empresa de archivo los formularios en papel procesados para su archivo definitivo.

Epílogo

El lenguaje formal de modelado de procesos que hemos descrito en la sección anterior es una herramienta bastante útil de cara a analizar los tratamientos de datos que formarán parte del alcance de nuestro programa de seguridad; sin embargo, la documentación de los procesos no se agotará en un simple diagrama del proceso. No en vano, el objetivo de esta fase es construir un repositorio o inventario de los procesos de tratamiento de datos que deberá permitir el acceso, explotación y mantenimiento de la información de una manera sencilla eficaz. Además, este inventario será el eje a partir de cual se organizarán el resto de proceso de la metodología (ej: análisis  de riesgos, definición de controles…)

Dicho repositorio de información puede ser implementado de múltiples formas: de forma muy económica por medio de documentos ofimáticos  (Word, Excel…) vinculados entre sí, o bien de manera un poco más “profesional”,  mediante la implementación de una herramienta soportada en una base de datos, siendo este método el preferido,  al poder beneficiarse de las ventajas que permite una base de datos relacional. En posteriores artículos seguiremos desarrollando estos métodos.

Esperamos que esta información sea de utilidad. Un fuerte abrazo y hasta pronto.