jueves, 23 de julio de 2020

La anulación del acuerdo Privacy Shield explicada con mutantes

Hace unos días supimos que el acuerdo Privacy Shield entre Estados Unidos y la Unión Europea ha sido anulado por el Tribunal de Justicia de la Unión Europea. 
Lo primero es entender para qué servía el acuerdo Privacy Shield. Para explicarlo voy a partir de la hipótesis de Xavier, con su escuela para jóvenes mutantes, ubicada en un pueblo a la orilla del río Alberche. Ahí los jóvenes mutantes reciben formación y aprenden a controlar sus poderes y a manejarlos. 
La infraestructura tecnológica de la escuela está desplegada en servidores ubicados en EEUU. Por ningún motivo en concreto, simplemente a Forja, el CTO de la escuela, le cuadró la oferta que le hicieron. 
En esa infraestructura la escuela tiene desplegadas diversas herramientas y aplicaciones. Quizás la más relevante, sea una base de datos que contiene las instrucciones para neutralizar a cualquier mutante que pierda el control de sus poderes, incluido el propio Xavier. 
El hecho de que una organización como la escuela de jóvenes mutantes, esté ubicada y preste sus servicios en la Unión Europea y mantenga sus servidores en países fuera de la Unión Europea, se considera una transferencia internacional de datos. Es decir, en este caso hay un flujo de datos desde España a EEUU donde están los servidores.
Las transferencias internacionales de datos sólo pueden realizarse a países que hayan sido declarados con un nivel de protección adecuado por la Comisión Europea. Y EEUU no es un país con nivel adecuado declarado por la Comisión (ups).
Como hay mucho tráfico comercial entre empresas de EEUU y la UE, se habilitó ese “nivel de protección adecuado” a través del Acuerdo Privacy Shield. Y de esa manera, las empresas estadounidenses podrían adherirse al acuerdo y con esa adhesión justificar su cumplimiento de las garantías necesarias y equivalentes con la normativa europea. 
En nuestra historia, el proveedor de los servidores cloud que contrató Forja para el despliegue de sus infraestructuras, estaba convenientemente adherido al acuerdo de Privacy Shield. 

¿Y entonces por qué se ha anulado el Privacy Shield?
Por la NSA. Si alguien ha visto The Good Wife y The Good Fight, sabrá que estas cuestiones siempre se acaban complicando por culpa de la NSA. Y si alguien ha visto estas series también sabrá que es complicado saber quién da las órdenes a la NSA. Podría ser hasta el Doctor Doom, visto lo visto. 
Y es que el Privacy Shield aplicaba y aportaba garantías pero tenía un truco que es, precisamente, sobre lo que se le ha preguntado al Tribunal de Justicia de la Unión Europea. La pregunta que le hicieron al tribunal fue: 
¿Garantiza el Privacy Shield un adecuado nivel de protección conforme a los requerimientos de la normativa europea?
Y la respuesta ha sido que no. Que dado que los principios del Privacy Shield pueden ser limitados si el Doctor Doom considera necesario el acceso a datos de ciudadanos europeos que estén albergados en servidores ubicados en EEUU, la protección equivalente no está garantizada. Y es que el Doctor Doom puede alegar motivos de seguridad o de interés nacional y solicitar acceso a los datos. 
Y recuerdo que Xavier tiene alojados en el server de EEUU, entre otros, los datos de neutralización de los poderes de los mutantes. Que se puede liar ahí un Genosa 2 si a la NSA le da por indagar en los servidores. 
En definitiva, cualquier transferencia internacional que estuviera amparada en el Privacy Shield debe ser interrumpida y los organismos reguladores (la Agencia de Protección de Datos en España), tienen potestad de prohibir esas transferencias. 

¿Y no hay alternativas?
Esta pregunta tiene su truqui. Al Tribunal de Justicia de la Unión Europea se le planteó también otra cuestión bastante relevante. Y es si tienen validez las cláusulas contractuales tipo (SCC en inglés). 
Las SCC son unos modelos de contrato publicados en los anexos de la Decisión 2010/87/UE. Esas SCC son, en resumen, un modelo de contrato que establece obligaciones para el exportador y el importador de los datos personales. Y esas obligaciones tienen la finalidad de garantizar que los datos personales que se transfieren al país de destino, se tratan con garantías adecuadas. 
Y lo que ha dicho el Tribunal es que las SCC sí que son perfectamente válidas y que facilitan mecanismos que aseguran adecuadamente la transferencia al tercer país. 
Eso sí, y aquí viene el plot twist, la transferencia debe ser prohibida o suspendida cuando no se puedan cumplir los requisitos establecidos en esas cláusulas contractuales.
Así que volvemos al Doctor Doom y la NSA. Y es que resulta que si las SCC sólo tienen capacidad de obligar a las partes que firman el contrato (el exportador y el importador) pero no vinculan a los organismos de EEUU, entonces estamos en las mismas. Porque la NSA (entre otros) podrá requerir al importador que facilite los datos de ciudadanos europeos y por ahí se van por el sumidero los derechos y garantías sobre los datos de ciudadanos europeos.
En definitiva, si se suscriben SCC entre las partes, el exportador debe tener en cuenta si los requisitos legales del país al que va a transmitir los datos permiten el cumplimiento de los SCC. Y debe tener en consideración también el acceso de las autoridades públicas del tercer país y aspectos legales de dicha legislación, en particular, que permitan cumplir con el artículo 45.2. 
¿Y entonces?
Aquí es donde se sienta Xavier, como CEO de la escuela de jóvenes mutantes, con Forja que es CTO y viene la pregunta de “¿qué hacemos Charles?”
Con un poco de suerte tienen también una Delegada de Protección de Datos a la que incluir en la sentada porque las transferencias internacionales que estaban amparadas por el Privacy Shield, tienen que dejar de hacerse. 

Spoiler de opciones ante la situación:
(1) Ver si el proveedor tiene la opción de ubicar sus servidores en Europa. 
(2) Revisar si las SCC negociadas entre exportador e importador garantizan los requisitos del artículo 45 del RGPD y ajustarlos si es que no pero, en el caso del EEUU, seguimos teniendo el asunto de seguridad nacional y el Doctor Doom.
(3) Es factible y no sé si plausible, que se llegue a un nuevo acuerdo entre la Unión Europea y EEUU. Un nuevo Privacy Shield al que adherirse. Al fin y al cabo, el Privacy Shield es el upgrade del anterior Safe Harbour que también fue invalidado. Lo que está por ver es qué opinará el Doctor Doom al respecto. 
(4) También se espera que se publiquen nuevas cláusulas contractuales tipo adaptadas al RGPD porque, las que he comentado aquí aunque válidas, en realidad se redactaron en el marco de la anterior Directiva ya derogada. 
(5) Está  el “elige tu propia aventura”del artículo 49 del RGPD, pero como dice su propio título es para “excepciones para situaciones específicas”
Yo creo que son tiempos para hablar con los responsables y delegados de protección de datos en las organizaciones para ver opciones.

miércoles, 10 de junio de 2020

El mutante que contrató a expertos en protección de datos a pesar de la herramienta Facilita EMPRENDE

Estaba comentando con Spike que jugué un rato esta mañana con la herramienta Facilita EMPRENDE que ha publicado la Agencia de Protección de Datos. Y que opino que está muy interesante siempre que tengas conocimientos de protección de datos. Y el muy vampiro, me ha puesto esa cara de la foto y me ha dicho:
– “Mira, tía, que llevo aquí más de tres meses encerrado contigo y sin ver a Buffy. No me cuentes tu vida”
Le he ignorado y he seguido contando pero se me ha puesto a cantar en su línea chunga y por María Jiménez. En plan, “acaba de una vez de un solo golpe y clávame la estaca, ¿por qué quieres matarme poco a poco?”. Así, sin rimar ni nada. 
Así que le he puesto lejos la estaca, que tiene un día muy gris y no quiero tener que barrer luego, y he decidido contarlo mejor en el blog. 

Voy a poner un ejemplo para explicar mi reflexión sobre la herramienta y que Spike no ha querido escuchar.
Vamos a imaginar que el profesor Charles Xavier, líder de los mutantes y de quien ya comenté el otro día que ha desarrollado la versión 3 de  “Cerebro”, ahora ha pensado en un modelo de negocio viable y económicamente explotable basado en una pequeña funcionalidad de “Cerebro” que me invento completamente.
Constituye una S.L a la que llama “Copia tu poder S.L. y en un portal web que apunta a un nombre de dominio similar y a través de una aplicación móvil, comienza el despliegue de su servicio.
El modelo de negocio consiste básicamente en poner a disposición de los mutantes un servicio que les permite hacer un backup o copia de seguridad de sus poderes. La sincronización con la aplicación se realiza vía móvil, a través de la huella digital del mutante o, en su defecto, es adaptable para otros tipos de sincronización con otras partes del cuerpo, mediante un dispositivo adicional que no viene al caso. 
Luego, a través de la aplicación web y también en la aplicación móvil, el cliente puede configurar prelación de poderes, tipos de copias, etc. 
Hay tres paquetes de servicio:
  • Basic – cuota mensual que permite almacenar un único poder durante el tiempo de pago de las mensualidades.
  • Silver – cuota mensual que permite almacenar hasta 3 poderes durante el tiempo de pago de las mensualidades.
  • Gold – cuota mensual que permite almacenar número ilimitado de poderes durante el tiempo de pago de las mensualidades.
Ya tiene todo montado y listo para lanzar y aquí es cuando viene Forja y le dice:
– Pero Charles, ¿tú todo esto los ha adaptado al RGPD? Que mira que aquí estás tratando datos de carácter personal y puede que el dato de poderes sea incluso una categoría especial de datos (nota mental, a valorar en otro post). 
Y Charles le dice:
– Tengo un amigo ingeniero que se lo sabe hacer todo él solo, que me ha recomendado la herramienta “Facilita EMPRENDE” de la Agencia de Protección de Datos y que te adaptas la empresa en tres patadas. 
Y Forja:
– Ah, siendo así, me quedo mucho más tranquilo. 

La herramienta de la Agencia que va a utilizar Charles se divide en tres apartados. Y, una vez completados los tres apartados, permite descargar una serie de documentos compilados en un archivo .docx sobre los que la propia Agencia de Protección de Datos aclara que:
“sirven de guía y apoyo para cumplir con las obligaciones impuestas por la normativa en materia de protección de datos”
(1) Sección 1 de la herramienta:
Datos de actividad de la empresa y canales de divulgación
En el primer apartado se confirman las actividades que desarrolla la empresa.
Ahí Charles confirma que:
  1. La empresa está constituida hace menos de 10 años. 
  2. Presta atención máxima a desarrollos tecnológico y modelos de negocio innovadores, en concreto, vía SaaS y desarrollo de APPs. 
  3. Y también pone que cuenta con perspectiva de crecimiento significativo, para encajar como startup en la herramienta (aunque aún no lo tiene claro, que esto es un experimento con “Cerebro”). 
Facilita los datos societarios de la empresa, confirma que tiene web y cookies de todo tipo, así como redes sociales y canales de Internet. 
(2) Sección 2 de la herramienta:
Responsable o encargado del tratamiento o desarrollador
Lo siguiente que se pregunta en la herramienta es si la empresa es “responsable”  “encargada del tratamiento” o “desarrollador”
He impartido formaciones en las que hemos podido estar más de una hora sólo para que se entienda correctamente la diferencia entre el concepto de “responsable” y “encargado”. Pero Charles es un tipo listo, lee un par de veces en la herramienta la explicación de lo que significa cada cosa, y concluye que su empresa es responsable del tratamiento. 
Colectivos de personas
La siguiente información que se va pidiendo es si la empresa trata datos de distintos colectivos, qué tipo de datos, con qué finalidades, si hay comunicaciones a terceros y si hay alguna gestoría que preste servicios. 
En concreto pregunta por colectivos de:
  • Clientes.
  • Clientes potenciales.
  • Empleados.
  • Candidatos.
  • Proveedores.
Videovigilancia
Si se utilizan cámaras en el ámbito de la actividad con fines de seguridad. 
Proveedores
Si la empresa cuenta con servicios del tipo hosting, desarrollo de software, servicios de correo, limpieza, etc. 
(3) Sección 3 de la herramienta:
Voy a copiar literalmente un párrafo de la herramienta que explica lo que se va a hacer en esta sección:
“caracterizar las actividades de tratamiento basadas en desarrollos tecnológicos e innovadores que ha identificado en la pantalla de inicio y los riesgos que pudieran suponer para los derechos y libertades de las personas. Para cada solución tecnológica identificada se procederá a caracterizar el tratamiento y su nivel de riesgo mediante una serie de preguntas planteadas a lo largo de cinco pantallas. La duración de esta sección dependerá del número de desarrollos o soluciones tecnológicas que necesite caracterizar.

Venga pues vamos a ello, Charles:
¿Es un desarrollo SaaS?
Si es que sí, toca identificar el tratamiento del desarrollo SaaS y marcar el tipo de datos que va a tratar la empresa. 
Entender la diferencia sobre los distintos tipo de datos puede llevar su buen rato de formación pero, una vez más, Charles sabe mucho. 
Se queda dudando un rato si almacenar poderes puede encajar en tipo de datos sobre comportamiento, incluso si podría ser genético pero bueno, tira millas y marca lo que considera. 
Duda un poco también sobre las finalidades de tratamiento de la siguiente pantalla porque, en principio, es un mero backup pero oye, igual luego ésto evoluciona como modelo de negocio que, al fin y al cabo,  “Cerebro” es muy potente y se pueden explotar nuevos modelos de negocio. Pero bueno eso ya una vez tenga los datos, irá pensando si los trata con otra finalidad (¡¡¡No Charles, eso no!!!!).
¿Va a hacer publicidad? 
– “Forja, tú qué opinas, ¿haremos publicidad?” 
– “Pon que sí por si acaso, Charles”. 
En la siguiente pantalla vienen los factores de riesgo sobre los tratamientos. Son 12 preguntas pero lleva ya 10 minutos dando vueltas a la primera que dice: 
“¿Se recaban datos o información de personas en múltiples ámbitos de su vida (desempeño en el trabajo, personalidad y comportamiento), relativos a varios aspectos de su personalidad o sus hábitos?
Y se queda pensando “¿un poder mutante me puede dar información de eso? ¿Qué me están preguntando aquí?” 
Ante la duda marca que sí y cuando pasa a la siguiente pantalla la herramienta no le deja continuar porque, por el tipo de categoría de datos, no encaja en la herramienta y tiene que irse a “GESTIONA – EIPD”. 
– “¿Cómo?. Forja, que aquí me manda a otra herramienta”. 
– “No fastidies Charles. Vuelve para atrás y desmarca esa opción, que no tratamos datos de comportamiento. Dile que “Ninguno de los anteriores”. 
– “Bueno, vale” 
Luego Charles pasa por el mismo proceso para servicios de usuarios a través de aplicaciones móviles. Vuelve a inventarse un poco las respuestas porque no acaba de tener muy claro qué le preguntan y listo. 
Factores de riesgo en los tratamientos
Aquí hay una nueva pantalla con doce preguntas sobre tipos de tratamientos y almacenamientos de los datos. 
Charles empieza a estar un poco mareado y eso que es telépata e implica tener una mente que lo aguanta todo. Pero el caso es hace una lectura diagonal y marca “ninguna de las anteriores” y tira millas. 

Así que, gracias a su sabiduría, consigue llegar a la pantalla final donde le dicen que por la información que ha facilitado ”no se pone de manifiesto que realice operaciones sobre los datos personales que pudieran considerarse un alto riesgo para los derechos y libertades de las personas” y que, además, si realiza desarrollos tecnológicos hay un apartado (muy chulo por cierto) en la web de la Agencia donde puede consultar información de interés. 

Y así nuestro profesor llega a la última pantalla en la que puede descargarse un archivo en formato .docx en el que va a tener: cláusulas de información para los tratamientos que ha ido indicando; políticas de privacidad; políticas de cookies; contratos para los proveedores; registro de las actividades de tratamiento que ha indicado; directrices para atender el ejercicio de los derechos de sus clientes mutantes; recomendaciones sobre videovigilancia; estrategias de privacidad y medidas de seguridad tanto técnicas como organizativas; directrices para la gestión de brechas de seguridad y modelo de registro de incidentes; indicaciones y directrices sobre las actividades que desarrolla tanto para SaaS como aplicaciones móviles y recomendaciones de prevención del acoso digital. 

Satisfecho adjunta el archivo descargado a un correo para enviárselo a Forja. El único de sus 10 trabajadores que tiene un perfil más técnico. 
En el asunto del email le pone:
“A implementar” 
Y en el cuerpo del correo le aclara:
“Forja, por aquí te adjunto el archivo para cumplir con lo del RGPD para que lo implementes y poder lanzar. Saludos mutantes.
PD: Acuérdate de mirarme luego el lavabo que creo que no traga bien”
Lo último que se sabe de Forja es que cambió de empresa. Ahora es CTO de Hydra donde cuentan con un responsable de seguridad y tienen una empresa que les asesora en materia de protección de datos. 

miércoles, 27 de mayo de 2020

Mutantes y planificación de la seguridad de la información

Jonathan Hickman ha hecho un reinicio o “reboot” de los X-Men con doce cómics llamados Dinastía de X y Potencias de X (seis grapas por cada título) muy recomendable. Pero como esto es mi blog jurídico voy a aprovechar para hablar de una cuestión que leí en los cómics y que me genera gran inquietud. 
Si conocéis a los mutantes, no desvelo nada si os digo que la principal funcionalidad de Cerebro es la posibilidad de localizar a mutantes del planeta. Si no conocéis a los mutantes, os digo que Cerebro es un dispositivo que utiliza Charles Xavier, un mutante, para poder localizar a otros mutantes del planeta. Es un localizador francamente bueno. 
Sin entrar en para qué ni en por qué, la versión de Cerebro (tercera generación) que maneja Charles Xavier en los cómics de Hickman, tiene la funcionalidad de hacer copias de las mentes de los mutantes.
Y aquí es donde viene mi preocupación cuando leí una conversación en Potencias de X entre Charles Xavier y Forja. El profesor Xavier le pide a Forja que implemente un sistema para guardar copias de seguridad de Cerebro. Y entonces Forja le plantea dos cuestiones a Xavier:
  • Un posible problema de volumen, porque hay muchas mentes mutantes y el número aumenta (Sí, Wanda, aumenta el número a pesar de lo tuyo, que se te fue mucho la pinza). 
  • Y la redundancia que implica guardar versiones actualizadas de las mentes de los mutantes conforme transcurre el tiempo. 
Forja dice que necesitará, como mínimo, una copia de seguridad. Y Charles le contesta que cinco, ¡que quiere cinco!: “Una unidad principal, tres copias de seguridad y una más para complicaciones imprevistas. “
A partir de ahí se meten en un tema de necesidad de una fuente de energía y almacenaje ilimitados y pasan cosas que os tenéis que leer en el cómic. Leed el cómic. 
Cuando leo estas cosas yo entro en modo análisis de riesgos, posibles vulnerabilidades, amenazas sobre Cerebro, cómo evitarlas y encima cinco copias, y dónde guardas esas copias y cómo proteges esas copias y run run y run run.  
Y ya les hablo: “Suena muy bien Forja. Y Charles, seguro que vas a hacer cosas buenas a favor de los mutantes o eso quieres creer, como siempre. Pero se supone que sois dos de los tíos más listos del planeta, con el permiso de Jean Grey. ¿Qué tal algo de seguridad coordinada en todo esto? 
Charles, yo empezaría por un Plan Director de Seguridad que, por resumir con la definición de INCIBE, se trata de “definir y priorizar un conjunto de proyectos en materia de seguridad de la información con el objetivo de reducir los riesgos a los que está expuesta la organización hasta unos niveles aceptables, a partir de un análisis de la situación inicial.”
Vamos a decir que aquí la organización son los Mutantes. Representados por Charles Xavier en esas atribuciones que siempre se quiere arrogar el profesor y que a mi, muchas veces, me parecen bastante cínicas. Y si le preguntáis a Mística aquí (entre otros sitios), seguro que opina lo mismo que yo. 
Pero hombre, ya que te pones, qué menos que considerar la seguridad del proyecto en su conjunto, ¿no? 
Yo no sé, (o si lo sé no lo digo bien para no hacer spoilers, bien para que me encaje la frikada en el post), si Forja y Charles han hecho un análisis de la situación, pero en esa conversación que comento, a mí todo me suena a parches. Que si necesito una fuente de energía ilimitada por aquí, que si redundancia por allí, que si el sistema de rotación de copias de seguridad será este otro. De hecho, está explicado el sistema de copias de seguridad en el cómic (el cómic lo mola todo y el sistema de backups incluye copias incrementales y completas).
Y mi sentido arácnido cylon se va poniendo de punta, porque me suena todo a parches. No veo que aquí Charles y Forja se hayan sentado a hacer una Plan Director de Seguridad. Un “algo” coordinado en el que tengan en cuenta dónde tiene que estar la organización Mutante en materia de seguridad y la protección de su principal activo, Cerebro. No veo ninguna línea de actuación, ni plan predefinido sobre las medidas de seguridad que la organización Mutante tiene que implantar. 
Y, yo no sé si hay normas ISO en el mundo mutante, posiblemente no porque teniendo a Magnus, quién quiere una ISO, pero deberían basarse en alguna línea de buenas prácticas con las de la ISO 27000 para definir requisitos de seguridad. Porque estamos hablando de Cerebro y de que va a almacenar información francamente muy muy sensible. Y hasta cinco copias de seguridad de esa información muy muy sensible, así que vamos a centrarnos, Charles:
  1. Un Plan Director de Seguridad con alcance a Cerebro y sus copias de seguridad.
  2. Nombra responsables de seguridad y responsables de la información. (Gente fiable y competente, tipo Tormenta. Evita a Logan)
  3. Analiza qué medidas tiene implantadas ahora mismo Cerebro y establece qué objetivos de seguridad tienes que cumplir para garantizar su seguridad. 
    • Analiza riesgos y amenazas. 
    • Qué medidas de seguridad tienes ya para reducir esos riesgos y las amenazas. 
    • Qué riesgos siguen existiendo a pesar de esas medidas y qué nuevas medidas hay que establecer. 
  4. Ejecuta el plan. 
  5. Y revisa que las medidas funcionan, que estamos hablando de Cerebro. 
Voy a seguir profundizando sobre este tema en próximos post porque me parece relevante proteger a Cerebro. Pero por no extenderme demasiado voy a dejar aquí una idea muy simple y fundamental: es necesario abordar el proyecto de la seguridad de los activos de una organización, incluida la organización Mutante, desde su planificación. La finalidad es prevenir amenazas e incidentes sobre esos activos. En el momento que se improvisa, como entendí yo que estaban haciendo Forja y el Profesor Xavier, podemos encontrarnos con un serio problema. 

domingo, 19 de abril de 2020

Brechas de seguridad en el multiverso y brechas de seguridad sobre datos de carácter personal

Una brecha es un resquicio por donde algo empieza a perder su seguridad. Esa es la tercera definición de la RAE y es sobre lo que voy a tratar yo en este post.

Las brechas de seguridad pueden ser peligrosas en función de lo que se escape por ese “algo” que pierde su seguridad.
Por ejemplo, atravesar multiversos por el Vacío puede hacerse sin riesgos o puede causar una brecha de seguridad.
Para quien no lo sepa, el Vacío es un velo invisible que separa distintos multiversos. Un mago como Ingold Inglorion es perfectamente capaz de atravesar el Vacío sin causar brechas de seguridad en el multiverso de origen o en el de destino. Pero si los multiversos están en un momento especialmente cercano, puede existir el riesgo de que los Seres Oscuros encuentren el modo de colarse por el Vacío mientras Ingold lo atraviesa. Y eso causaría una brecha de seguridad en el multiverso de destino del mago porque nadie quiere una invasión de los Seres Oscuros en su lado del multiverso.

Una brecha de seguridad puede ser accidental o intencionada. Sabemos, por ejemplo, que Ingold nunca consentiría que los Seres Oscuros atravesaran desde su multiverso de origen a otro.
Es un buen mago. Se le ve a la legua. Si nos atenemos a la descripción que hace Barbara Hambly en la trilogía del Reino de Darwath donde se cuenta su historia, Ingold es el clásico mago de túnica marrón, barba poblada y espada llameante. Pero eso sí, y aquí es donde está lo importante, “en sus ojos azules intensos” no hay “asomo de soberbia, ni crueldad”. Así que no estamos aquí tratando con Saruman. Si atraviesan de un multiverso a otro los Seres Oscuros con Ingold, sabemos que va a ser una brecha de seguridad accidental.

Si en vez brechas de seguridad por cruzar multiversos, estamos ante brechas de seguridad sobre los datos de carácter personal que tratan las organizaciones, existen incluso más variables que las que maneja Ingold. Porque esas brechas pueden ocurrir sobre datos personales que se tratan en soporte digital, o sobre datos personales que se tratan en soporte papel.
Igual que sucede en el caso de los Seres Oscuros, también con los datos de carácter personal la brecha puede ser accidental. Como que alguien pierda un pendrive que contiene datos personales. O la brecha puede ser intencionada, como que las redes y sistemas informáticos de la organización sufran un ataque porque alguien recibió un email raro y pinchó en un enlace que los malos habían preparado para hacer maldades en los sistemas informáticos de la organización.

Tanto si lidiamos con Seres Oscuros, como si lo hacemos con potenciales brechas sobre datos de carácter personal, es importante que existan procedimientos para estar preparados ante la posibilidad de que algo malo (la brecha de seguridad) ocurra.

Por ejemplo Ingold tiene un procedimiento que consiste en no atravesar el Vacío cuando los multiversos se encuentran demasiados cercanos.  La cercanía de los multiversos depende de la fase lunar en que se encuentren.

Y, aún así, cuando no le queda más remedio y tiene que atravesar el Vacío, cuenta con un protocolo para hacer frente a los Seres Oscuros. Si queréis saber cuál es el protocolo, podéis consultarlo en la trilogía de El Reino de Darwarth. O me escribís por email o por DM en Twitter por evitar los spoilers. Estoy segura de que aplican como consultas jurídicas y además serán probono.

Pero aquí, sobre lo que quiero hacer hincapié, es sobre el hecho de que Ingold está preparado para una potencial brecha porque sabe:
    • Qué puede pasar si atraviesa el Vacío en cierto momento.
    • Qué le puede perseguir si le hace.
    • Cómo debe actuar si ese “qué” le persigue.

¿Se me ve por dónde voy? Porque eso es precisamente lo que tienen que hacer las organizaciones que tratan datos personal para evitar brechas de seguridad. Es muy importante que, igual que Ingold, estén preparadas y que cuenten con un procedimiento de brechas de seguridad. Lo mismo que Ingold sabe que el riesgo está en los Seres Oscuros, las organizaciones, para poder definir un buen procedimiento de brechas de seguridad, tienen que saber:
    • Qué datos personales están tratando.
    • Qué medios utilizan para tratar esos datos personales:
        ◦ ¿Medios digitales? ¿En qué aplicaciones? ¿Dónde están alojados?
        ◦ ¿Medios en papel? ¿Quién los custodia? ¿Se extraen de la organización.
    • Qué riesgos pueden existir sobre dichos datos personales.

Por tanto, un buen procedimiento de brechas de seguridad, implica implantar medios y mecanismos que permitan detectar si se ha producido alguna brecha sobre los datos de carácter personal y cómo actuar cuando ocurra. Porque, cuando se produzca esa brecha, hay que tener muy claro qué hacer. Esto es muy importante. Si Ingold atravesara multiversos sin tener planificado qué hacer si le siguen los Seres Oscuros, os aseguro que ya tendríamos en este multiverso una invasión imparable de Seres Oscuros. Y eso es algo malo, muy malo.

Si una organización no tiene identificado qué hacer cuando se produzca una brecha de seguridad, improvisar en una situación así, será como luchar con los Seres Oscuros pero sin espada llameante.

Así que, ese plan de brechas de seguridad, tiene que especificar tareas y personas para ejecutar esas tareas. De manera que permita solucionar la brecha de seguridad, poner medios para que no vuelva a suceder en el futuro y activar acciones para minimizar sus impactos. Entre las distintas acciones está la comunicación a los titulares de los datos de carácter personal. Además de la comunicación a la propia Agencia de Protección de Datos en un plazo máximo de 72 horas.

En este procedimiento de brechas de seguridad es necesario, además, tener establecidas unas pautas para poder valorar la gravedad de la brecha. Igual que no es lo mismo que se te cuele por el Vacío un solo Ser Oscuro a que se te cuele un regimiento,  tampoco es lo mismo que la brecha de seguridad sea sobre datos poco sensibles como nombres y apellidos, a que sea sobre datos de salud. Ni que la brecha sea sobre datos de cinco personas o sobre cien mil personas.

Así que, para poder valorar y tomar decisiones, es fundamental tener todos los datos relacionados con la brecha de seguridad. Por eso es importante contar con un procedimiento. En una situación excepcional, arriesgada y generalmente estresante para las organizaciones, es mejor contar con un manual (el procedimiento) de lo que hay que hacer paso a paso para poder solucionar la brecha; para saber quién participa en la solución; para decidir si hay que notificar a los titulares y a la propia Agencia de Protección de Datos.

Y toda esa cadenas de acciones y reacciones deben quedar registradas en lo que se llama un “registro de brechas de seguridad”.
El registro de brechas de seguridad es un instrumento muy importante en toda gestión de incidentes y brechas de seguridad de una organización.
Aquí los magos, por ejemplo, manejan este registro con el boca a oído. Ingold se lo cuenta a su discípulo Rudy Solis, quien a su vez, se lo contará a sucesivos magos. Y así hacen los procedimientos. Pero los magos son pocos y pueden hacer una gestión de conocimiento por boca a oído.
En las organizaciones, eso no es un buen plan. Una buena gestión de incidentes, además del procedimiento definido, debe contar con un registro de incidentes y brechas de seguridad por escrito. Nada de boca a oído. Ese registro va a permitir varias cosas:

    • En primer lugar, va a ser una evidencia del sistema de cumplimiento de privacidad (o Privacy Compliance, si os gusta más) de la organización. Y es donde va a quedar constancia de las decisiones que se han tomado ante la brecha de seguridad o el incidente ocurrido, así como los motivos de esas decisiones.  Entre otras cosas, la Agencia de Protección de Datos puede pedir la evidencia del registro. Y a la Agencia no se le puede decir: “Este conocimiento ha pasado de generación en generación de magos durante eones y forma parte de nuestra conciencia colectiva”. Quedaría feo y además de potencialmente sancionable.
    • En segundo lugar, permitirá a la organización verificar el funcionamiento de las medidas paliativas implantadas.
    • En tercer lugar, permitirá aprender a la organización. Es una fuente de gestión de conocimiento para el análisis de futuras medidas preventivas.


En conclusión, tan importante como evitar que los Seres Oscuros atraviesen multiversos, es que la organizaciones cuenten con procedimientos de brechas de seguridad sobre datos de carácter personal.

Y recuerda:
    • No permitas que los Seres Oscuros te sigan cuando atravieses multiversos.
    • No utilices pendrives u otros dispositivos externos sin cifrar.
    • No dejes que los Seres Oscuros te toquen.
    • No compartas contraseñas con nadie y establece segundos factores de autenticación.
    • No te fies de cierta realeza del Reino de Darwath.
    • No dejes tu sistema operativo desactualizado.
    • No pienses mal de los jóvenes con pinta de moteros porque pueden esconder un buen mago en su interior.
    • No pinches en enlaces raros de correos electrónicos y mucho menos si no conoces al remitente del correo electrónico.


Para ti.