Leyendo la contestación al recurso de reposición, se puede constatar que la empresa “no contaba, en el momento de producirse la brecha de protección de datos, con las medidas adecuadas en relación con los riesgos del tratamiento para la protección de los datos personales” (página 23 de la contestación al recurso), concretamente relativas a las siguientes cuestiones:
1. La política de contraseñas y demás restricciones para el acceso a los sistemas de información de TPHS.
2. La protección de la seguridad perimetral y de las medidas de monitorización para la detección de conducta maliciosa;
3. La formación y concienciación de los empleados.
Análisis de la contestación de la AEPD al recurso de reposición interpuesto por la empresa
La empresa sancionada, en su recurso, pretende establecer una comparación entre su situación y la de otros ciberataques sufridos por otra empresas, pero la AEPD responde que en otras empresas afectadas por ciberataques sí había medidas implementadas porque habían pasado auditorías (mayormente, certificaciones de conformidad con la norma ISO 27001), afectando estos ciberataques únicamente a la disponibilidad de los datos, porque existían sistemas de copia de seguridad, pero no siendo éstos exfiltrados ni conocidos por terceros (páginas 25 y 26 de la contestación al recurso), además de que, como se señala en la página 26 de la contestación de la AEPD al recurso de la empresa, “no se puede comparar ninguno de ellos con el número de afectados por la brecha de datos personales sufrida por TPHS, que afectó a 13 millones de personas”.
Se señala, asimismo, por parte de la AEPD, en la citada página 26 de la contestación al recurso, que “en el supuesto examinado, tal y como consta en los hechos probados, hay una clara pérdida de confidencialidad pues se ha producido el acceso por un tercero no autorizado a los datos personales tratados por TPHS, siendo ello un resultado objetivo, reconocido por TPHS, que no una responsabilidad objetiva. No se ha garantizado, de esta forma, una seguridad adecuada mediante la aplicación de las medidas técnicas y organizativas apropiadas, no sólo de seguridad, sino de todo tipo”.
Seguidamente, en la misma página 26 de la contestación al recurso, la AEPD indica, al respecto de la eventual “valoración positiva en procedimientos de detección y gestión de brechas”, que “la notificación de una brecha de datos personales es una obligación del responsable del tratamiento de datos recogida en el artículo 33 del RGPD y, en buena lógica, sólo podría cumplirse esa obligación con un adecuado procedimiento de detección y gestión de brecha”. Además, la AEPD recuerda también “que el incumplimiento de esta obligación supone una infracción de acuerdo con lo previsto en el artículo 83.4 a) del RGPD”, por si alguna empresa tuviera la tentación de no notificar sus brechas de seguridad.
En la página 27 de la contestación al recurso, la AEPD señala que se ha valorado toda la documentación en su conjunto, de forma rigurosa, no de forma arbitraria ni libre, como señala la recurrente, ni únicamente basada en el informe de auditoría del incidente, elaborada por el “único experto informático que ha tenido la oportunidad de analizar las evidencias y el entorno digital en que se obtuvieron, y cuya trayectoria profesional le permite opinar de forma cualificada sobre la adecuación de las medidas de seguridad adoptadas, gozando de los “conocimientos científicos, artísticos, técnicos o prácticos” precisos para emitir dictamen”, como pretende la recurrente.
Según indica la AEPD, en la página 28 de la contestación al recurso, las deficiencias fueron detectadas en la implementación de medidas relacionadas con las Evaluaciones de Impacto de Protección de Datos (EIPD), en la política de contraseñas implementadas, en la seguridad perimetral y la formación de usuarios, entrando la AEPD a discurrir sobre cada una de ellas.
Evaluaciones de Impacto de Protección de Datos (EIPD)
Al respecto de las medidas relacionadas con las Evaluaciones de Impacto de Protección de Datos, la AEPD señala, en la página 28 de la contestación al recurso, que “TPHS no tenía implantadas las medidas de seguridad que ella misma había indicado en sus EIPDs dos años antes del incidente, lo que de por sí indica que no se habían aplicado las medidas apropiadas para garantizar una seguridad adecuada al riesgo, que en su caso incluya, entre otros: a) la seudonimización y el cifrado de datos personales, lo que supone un incumplimiento del art. 32 RGPD, como en el hecho de que sí se requirieron específicamente los análisis de riesgos y, en su caso, las EIPDs respecto de los tratamientos afectados por la brecha y fue TPHS la que indicó, en respuesta a los requerimientos de información efectuados durante las actuaciones previas de investigación, que entre los tratamientos afectados por la brecha de datos personales, se incluyen el “marketing digital” y el “control de acceso a las instalaciones”. Por tanto, esas actividades de tratamiento sobre las que se realizaron las EIPDs aportadas por TPHS sí estaban afectadas por la brecha, tal y como indicó en las respuestas a los requerimientos realizados, en lo cual ahora simplemente se desdice”. Las medidas detalladas en las EIPDs, pues, no habían sido implantadas.Política de contraseñas implementadas
Respecto de las deficiencias relacionadas con la política de contraseñas, en las páginas 29 y 30 de la contestación al recurso, se indica que “no sólo se ha tenido en cuenta el contenido del Informe SIA sino también los informes de evaluación aportados por la empresa Écija (Informe “Evaluación del cumplimiento en materia de protección de datos – Medidas de Seguridad –“,fechado el 11 de enero de 2021; Informe “Evaluación del cumplimiento en materia de protección de datos – Medidas de Seguridad –“, fechado el 11 de enero de 2021; así como el inventario de sistemas aportado por TPHS el 28 de junio de 2021 (Número de registro: O00007128e2100028705)”. Es decir, parece evidente que el despacho contratado realizó una serie de recomendaciones que no fueron implementadas por la empresa.En este tipo de procedimientos, es esencial que las medidas técnicas recomendadas por el despacho de abogados se cumplan a rajatabla, pero a estas medidas técnicas sólo puede darse cumplimiento mediante un proyecto técnico de Ingeniería Informática, que diseñe, desde el plano técnico, las médicas recomendadas por el bufete de abogados, supervisando su implantación. La existencia de un proyecto técnico de Ingeniería Informática será la único garantía de que las medidas fueron implementadas tras el informe del bufete de abogados, ya que un Ingeniero o Ingeniero Técnico en Informática colegiado diseñará la implantación de dichas medidas, firmando como ingeniero colegiado dicho proyecto técnico.
Es obvio, pues, que las medidas no podrán implantarse sin más, es decir, sin proyecto técnico, pues no quedaría registro del diseño de tales medidas desde el ámbito técnico, ni tampoco de los procedimientos, ni de la fecha de su implantación, siendo que, sin proyecto técnico, una eventual auditoría efectuada al sistema, tras la apertura de un expediente administrativo, no podrá determinar qué medidas fueron implantadas, ni cuándo se implantaron tales medidas, ni quién las implantó y, por tanto, la Administración podría argumentar que no se implantaron o que su implantación es reciente y posterior a la apertura del expediente administrativo, puesto que no existe constancia documentada que acredite, sin género de dudas alguno, dicha implantación.
Señala, asimismo, la AEPD, que “Por último, también se ha tenido en cuenta las medidas que TPHS declaró haber implantado o en proceso de implantación con posterioridad a la brecha”. Ello delata, pues, una insuficiencia de medidas adoptadas con anterioridad a la brecha.
Continúa manifestando la AEPD, que “En dicha documentación se reflejó -tal y como se ha señalado pormenorizadamente al principio de este apartado Cuarto de respuesta a las alegaciones, al cual procede remitirse- numerosas e importantes deficiencias las cuales no han sido desvirtuadas y que reflejan medidas inadecuadas por parte de TPHS y que no aparecen en el Informe SIA.
Todo ello pone de manifiesto que, con independencia de la brecha de datos personales detectada, la política de contraseñas y demás restricciones para el acceso a los sistemas de información de TPHS no eran adecuadas para garantizar una seguridad apropiada, suponiendo vulnerabilidades aprovechables por cualquier atacante”. Señala la AEPD, pues, que las medidas de seguridad implantadas por la empresa sancionada no eran suficientes para garantizar la seguridad.
Respecto del algoritmo de cálculo de hash MD5 utilizado, la AEPD señala que “A este respecto, procede señalar que la deficiencia del algoritmo de encriptado es una verdadera deficiencia, un algoritmo nada seguro y ya puesto ello de manifiesto años antes por el CCN, aunque fuera recogido como recomendación en el informe señalado. Lo que refleja el informe es que TPHS estaba utilizando ese algoritmo y que el mismo es deficiente lo cual se conoce desde hace años. No debe olvidarse que el atacante consiguió las credenciales de varios usuarios de TPHS”. Como es bien sabido, ciertamente, el algoritmo de cálculo de hash MD5 tiene colisiones y cada vez es menos utilizado, al menos en la comunidad forense.
Seguridad perimetral
Con respecto a la seguridad perimetral, en la página 31 de su resolución, la AEPD señala que las medidas implantadas después del ataque no influyen en la sanción, puesto que la sanción se impone por las medidas deficientes implantadas al momento del ataque.Haciendo referencia al informe SIA, aportado por la recurrente, ésta alega que el informe de auditoría señala que los hallazgos “se corresponden con un entorno manipulado y que muchas de las deficiencias encontradas en la seguridad perimetral pueden derivarse de alteraciones realizadas por el usuario intruso”, sin embargo, la AEPD refiere que no se demuestra este extremo, siendo que esas deficiencias permitieron que, efectivamente, el intruso entrara.
Formación de usuarios
Al respecto de la formación de usuarios, la empresa sancionada refiere que se tenía “un plan robusto, exhaustivo y continuado de formación continua en materia de protección de datos y seguridad de la información”, sin embargo, la AEPD, en la página 32 de su resolución, refiere que “analizada la documentación cabe reseñar que la mayoría refleja cursos genéricos y no acredita cuántos alumnos ni cuándo se realizaron (documento 4); curso genérico sin que acredite quiénes lo realizaron y no resulta obligatorio (pantallazo de un mail enviado el 17 de noviembre de 2019); curso dirigido a TPHS, a sus obligaciones como responsable de tratamiento (documento 6); cursos genéricos on line a realizar por los trabajadores nuevos contratados a partir de 2018, acompañado de un listado de unos 330 personas que lo han realizado, sin fechar ni firmar”.Sobre la falta de pseudonimización
Seguidamente, en la página 33 de su resolución, la AEPD señala que, el informe del DPD, elaborado con posterioridad al incidente, no acredita que las medidas adecuadas estuvieran implantadas durante el incidente.Asimismo, en la página 34 de su resolución, la AEPD refiere que “Por lo expuesto, en el presente caso, la ausencia de unas concretas medidas de seguridad que van dirigidas específicamente a garantizar la confidencialidad, a saber, el cifrado y la pseudonimización (o la anonimización) es lo que ha traído como consecuencia la existencia de la brecha de confidencialidad de los datos personales. Si los datos hubieran estado cifrados, anonimizados o pseudonimizados, los delincuentes sólo se hubieran llevado información ininteligible. De ahí que se le impute a TPHS la infracción del artículo 5.1.f), pues el mismo exige garantizar la confidencialidad a través de diversas medidas, que pueden ser tanto de seguridad como de otro tipo. Sin embargo, la infracción del artículo 32 del RGPD que se le ha imputado, lo ha sido por la falta o la inadecuación de numerosas medidas, esta vez sí, dirigidas a garantizar un nivel de seguridad adecuado al riesgo de los tratamientos que se realizan. Y de todas las medidas de seguridad que se detectan que faltan o que eran inadecuadas y que suponen una vulneración del artículo 32 RGPD -las cuales se indican en el Fundamento de Derecho VII de la presente Propuesta, al que nos remitimos-, sólo hay dos, que han resultado determinantes para la pérdida de confidencialidad: de nuevo, el cifrado y la pseudonimización o la anonimización)”.
Este perito informático ha participado en auditorías y proyectos sobre pseudonimización de datos personales e información confidencial en grandes empresas y, la clave radica en que, una vez aplicado el algoritmo de pseudonimización, no se pueda individualizar ni identificar a ninguna persona concreta a través del conjunto de los campos no pseudonimizados.
En la página 37 de su resolución, la AEPD continúa señalando que, “No debe olvidarse, en este sentido, que existen medidas dirigidas específicamente a garantizar la confidencialidad de los datos personales, como el cifrado de los mismos o la aplicación sobre ellos de técnicas de pseudonimización o anonimización, medidas que además indicó TPHS expresamente en sus EIPD como medidas necesarias a implantar para reducir los riesgos “altos” o “muy altos” respecto de las actividades de tratamiento afectadas por la brecha. Sin embargo, tal y como se ha indicado en los Hechos Probados, en el momento de producirse el incidente de seguridad, el mismo ha conllevado una brecha de datos personales que ha afectado a la confidencialidad de éstos por cuanto TPHS no había implementado esas medidas concretas tras más de dos años de detectados esos riesgos e indicadas esas medidas en sus EIPD. En caso de haberse aplicado, no se hubiera producido un acceso ni una exfiltración de los datos personales -ni una publicación de los mismos en texto claro- como finalmente sucedió, pues los datos hubieran sido ininteligibles para el delincuente. Esto lo que refleja es, cuanto menos, una falta de la diligencia debida por parte de TPHS. Por tanto, en el supuesto examinado, tal y como consta en los hechos probados, hay una clara pérdida de confidencialidad pues se ha producido el acceso por un tercero no autorizado a los datos personales tratados por TPHS, siendo ello un resultado objetivo, reconocido por TPHS, que no una responsabilidad objetiva. No se ha garantizado, de esta forma, una seguridad adecuada mediante la aplicación de las medidas técnicas y organizativas apropiadas, no sólo de seguridad, sino de todo tipo”.
Necesidad de proyecto técnico de Ingeniería Informática
La conclusión que se puede obtener de esta multa, que aún no es firme, es que hay que implementar técnicamente las medidas que el bufete de abogados contratado recomienda. Estas medidas deben implementarse a través de un proyecto técnico de implantación, que es el único vehículo capaz de garantizar que se produce una verdadera implementación de las medidas técnicas que garantizan el cumplimiento con el Reglamento General de Protección de Datos. La norma que regula estos proyectos es la “CCII-N2016-02 – Norma Técnica para la realización de la Documentación de Proyectos en Ingeniería Informática”, fundamentada en las normas UNE 157801:2007 – “Criterios generales para la elaboración de proyectos de sistemas de información”, UNE-ISO 21500:2013 – “Directrices para la dirección y gestión de proyecto” y PMBOK® – “Guía de los Fundamentos para la Dirección de Proyectos”, Quinta Edición.
Evidentemente, el proyecto técnico de implantación de las medidas recomendadas por el despacho de abogados contratado, para cumplir con el Reglamento General de Protección de Datos, deberá estar firmado por un Ingeniero o Ingeniero Técnico en Informática colegiado, que acredite el cumplimiento de la norma técnica y el diseño y la efectiva implantación de las medidas técnicas recomendadas. Así pues, en el momento en que se produzca una auditoría, se podrá aportar ese proyecto técnico al auditor o, en caso de querer alegar contra una eventual multa por presunto incumplimiento de las medidas de seguridad que debieron implementarse para cumplir con el Reglamento General de Protección de Datos, se deberá entregar dicho proyecto técnico al perito informático colegiado de parte, que verificará que las medidas fueron, en efecto, implementadas y, que elaborará un informe pericial informático en tal sentido.
Como es evidente, sin proyecto técnico, no se podrá acreditar que las medidas llevan implementadas desde el momento en que se produjere la pretendida implantación, porque no existiría registro de dicha implantación (obviamente, una factura de prestación de servicios con un concepto genérico no es registro de nada y, por otra parte, en muchos sistemas informáticos es muy complejo verificar, analizando los registros, la fecha concreta en la que se implantó una característica, puesto que los registros son meros archivos de texto editable y, además, se van sobrescribiendo). Es esencial, pues, realizar un proyecto técnico de Ingeniería Informática, elaborado por un Ingeniero o Ingeniero Técnico en informática colegiado, para implantar, en un sistema informático, cualquier tipo de medida técnica que después pueda necesitar acreditarse como efectivamente implantada.
Fuente: este post proviene de perito informatico colegiado, donde puedes consultar el contenido original.
¿Vulnera este post tus derechos? Pincha aquí.
Creado: