Ha habido mucho revuelo por el anuncio de una “brecha de datos que afectaba a todos los madrileños” en la web de autocitas de vacunación de la Comunidad de Madrid, que al parecer estaba realizada por la empresa Indra. La información la desvelada Telemadrid en un principio, en base a una comunicación que hasta el momento es anónima.
Sin muchos más datos que los que ustedes han visto, pero con algo de conocimiento, voy a intentar aclarar algunos conceptos.
Una brecha de datos personales “es un incidente de seguridad que afecta a datos de carácter personal, pudiendo producir daños sobre los derechos y libertades de las personas físicas cuyos datos son objeto del tratamiento.”
No todos los incidentes de seguridad son necesariamente brechas de datos personales y no solo los ciber-incidentes pueden ser brechas de datos personales. A su vez, no toda acción que suponga una vulneración de la normativa de protección de datos puede ser considerada una brecha de datos personales.
Protección de datos: responsables y normativas
La Agencia Española de Protección de Datos (AEPD) es la autoridad competente en estos casos porque su ámbito de actuación está en todo el sector privado a nivel nacional, aunque existen sus homólogas catalana, vasca y andaluza si esta se produce en el ámbito del sector público. En el resto de las comunidades si es del sector público también es la AEPD la encargada. Y la gestión de datos está reglada por el Reglamento General de Protección de Datos (RGPD)
El origen de una brecha puede ser accidental o intencionado. En el caso de la brecha de datos en el sistema de autocita de la Comunidad de Madrid debemos pensar que estamos ante el primer caso. Y el resultado de la misma debe entrar en el rango de que lo sucedido provoque la pérdida, alteración, comunicación, destrucción o acceso no autorizado a datos personales. Es por ello que las personas que trabajan con este tipo de datos deben tener un plan de contingencia en el caso de que esto ocurra.
En este plan se debe identificar:
- La razón por la que se ha producido. Esto es claramente porque alguien conoce el DNI, fecha de nacimiento y primer apellido de la persona, que son los datos que nos solicita la aplicación
- El origen. Si es interno o externo, e -importante-, la intencionalidad
- La categoría de los datos. Si pueden ser utilizados para acceder a más datos (por ejemplo, credenciales, etc.). O si son de una categoría especialmente protegida. Los de salud lo son.
- El volumen de los datos accedidos. No el de a cuantos se puede acceder, sino a cuantos se ha accedido. Esto medirá la gravedad. Es muy espectacular decir que todos los madrileños han sido expuestos a este riesgo, pero hay que evaluar cuantos lo fueron en realidad.
- Categoría de las personas afectadas. Si por ejemplo los datos son de personas de colectivos vulnerables añadiría más gravedad al suceso.
- Tiempo. Cuándo se inició, cuando se detectó y cuándo se resolvió la brecha.
Todos estos parámetros son los que determinan una brecha de seguridad.
No es necesario comunicar todas las brechas porque la RGPD establece que no se tiene por qué comunicar a la AGPD si es improbable que la misma afecte a los derechos y libertades de personas físicas. En caso contrario deben comunicarse en un plazo de 72 horas después de que el responsable de los datos tenga notificación de que una brecha ha existido.
Visto esto, la en la web de autocitas de vacunación de la Comunidad de Madrid consistía en que previo acceso con DNI y datos de una persona, esto es un acceso autorizado, se podía modificar con algo de conocimientos informáticos. Esto no está al alcance de todos, pero la consulta del DNI previamente autorizado obteniendo datos de un tercero sí de muchos.
Muchos de los ejemplos que se pusieron de acceso a datos a través de la web de autocitas de Madrid eran de personas públicas, familiares y amigos. Es decir, de personas que ya conocían los datos necesarios, al menos el DNI, de lo que consultaban. Y esto es importante señalarlo, porque ese “dato”, y otros muchos más son muy fácilmente accesibles puesto que están publicados tanto en medios como por organismos públicos. Es muy fácil conocerlos. Quiero decir con ello que desde el punto de vista de seguridad el acceso a datos personales solicitando un DNI, una fecha de nacimiento y el primer apellido es claramente insuficiente, puesto que toda esta información está ya en muchos casos a disposición de cualquiera.
El implementar los sistemas de acceso a estos datos debería ser claramente mejorable, y cuando no es así es síntoma de prisas, desidia o vaya usted a saber. Obviamente los sistemas de credenciales tienen que tener un equilibrio entre la seguridad y la facilidad del acceso, pero no parece la utilizada la mejor solución.
Brecha de datos en la Comunidad Madrid: Qué nos dicen las capturas
Si uno observa las capturas que los medios utilizaron hay algunas cosas que llaman la atención, y creo que deben ser comentadas. Eso sí, manteniendo la prudencia debida, y por tanto entenderán que no cuente más que lo razonable.
Observen estas capturas de la información que dio sobre el tema El Economista.
Ambas nos cuentan cosas.
Fundada en 1987, Health Level Seven International (HL7) es una organización sin fines de lucro con el objetivo, entre otros, de presentar un estándar en la forma de tratar los datos médicos en las aplicaciones en la red y en la que participan muchos miembros y empresas que se dedican a soluciones telemáticas para la sanidad. Lo destaco porque esto es bueno. Que una aplicación siga, o intente, seguir estándares es siempre positivo. Aunque no una excusa ante lo sucedido técnicamente es de agradecer y señalar.
Pero en la siguiente captura vemos algo que descompensa las buenas prácticas.
Primero una referencia clara a quién es el responsable del desarrollo, Indra. Y además una dirección de un dominio que no existe publicado en la red, ni registrado a nombre de la empresa, ni nada. Es decir, un dominio interno, probablemente grabado a fuego con una redirección en el sistema, y que es quien contesta con datos de los cuales no sabemos la procedencia. Esto habla -y es especulación- de que puede que sea un entorno de predesarrollo, o algo que no esté debidamente controlado cuando se puso a disposición del público. Esto no aporta nada bueno reseñable. Permítanme que no insista más en este punto.
La brecha de datos en el sistema de autocita de la Comunidad de Madrid, por lo expuesto, era indiscutible. Se notificó a medios, y una vez dado a conocer se corrigió en poco tiempo. Pero llama la atención que fueran los medios, y no los involucrados, los primeros en conocer lo que sucedía. Además, se consiguió el efecto de amplificación porque de los medios saltó a las redes sociales. Y esto, según nos cuentan, fue por la buena acción de un hacker (que ya he dicho muchas veces que esa palabra no tiene por qué tener connotaciones negativas)
No voy a criticar esto, pero en mi opinión particular un hacker, al menos uno bueno, no hace eso. Lo primero es la notificación a las personas involucradas, no a un medio para amplificar el problema. Y esto no defiende en ningún caso la responsabilidad de nadie, pero para mí esa comunicación fue claramente intencionada, y desde el punto de vista técnico no ayudó a resolver algo que podía haber sido más grave, sino que tuvo otra intención. Y si es así lo veremos, o no, pero vuelvo a decir que es mi opinión.
Y esto es básicamente lo que puedo aportar a esta historia. Si a ustedes les arroja algo de luz y contexto me sentiré reconfortado en el esfuerzo.
Disclaimer | Trabajé 33 años y medio en la empresa que menciono en esta entrada diseñando, evolucionando, asesorando y construyendo sobre los sistemas y servicios que se usan internamente en ella. Más de 40.000 profesionales en más de 100 países. Hoy siguen utilizándolos.
0 Comentarios