Con objeto de cumplir debidamente con lo establecido en la Disposición Adicional Única del Real Decreto 1720/2007 he optado por solicitar a los distintos proveedores de software un documento a modo de acreditación del nivel de (in)seguridad que sus respectivos productos alcanzan. Como era de esperar esta información no aparece en la documentación que poseemos.
Disposición adicional única. Productos de software.
Los productos de software destinados al tratamiento automatizado de datos personales deberán incluir en su descripción técnica el nivel de seguridad, básico, medio o alto, que permitan alcanzar de acuerdo con lo establecido en el título VIII de este reglamento.
Los productos de software destinados al tratamiento automatizado de datos personales deberán incluir en su descripción técnica el nivel de seguridad, básico, medio o alto, que permitan alcanzar de acuerdo con lo establecido en el título VIII de este reglamento.
Tras más de un año de vigencia del mencionado RD, y sin que NINGÚN proveedor se haya tomado la molestia de suministrarnos formalmente esta acreditación, hemos decidido tomar la iniciativa. Bajo mi particular criterio considero que el cumplimiento de esta cláusula es competencia absoluta del desarrollador, pero por lo visto la cosa parece que no va con ellos .......
Con objeto de facilitarles aún más el trabajo he hecho una especie de "trasposición" de las medidas de seguridad del RD en clave de desarrollo de software. Los criterios (acumulativos) por los que se debe regir la acreditación del software dependiendo del nivel de seguridad que le corresponde son:
NIVEL BÁSICO
- Resulta obvio pero debe disponer de mecanismos de control de acceso (por algo será ...... yo me he encontrado con más de uno, de dos, de tres, .............)
- Relación actualizada de usuarios y accesos autorizados (repositorio propio o integrado en uno externo, por ejemplo eledap)
- Distintos privilegios de acceso según funciones/perfiles de usuario (dependiendo de la complejidad del producto)
- Mecanismos que eviten el acceso datos o recursos con derechos distintos de los autorizados (obvio no?)
- Identificación y autenticación personalizada (entre otras cosas no permitir sesiones simultáneas desde distintos equipos)
- Características básicas de las contraseñas (repetición, secuencias, combinar caracteres numéricos/alfanuméricos, etc..)
- Sistema de almacenamiento ininteligible de las contraseñas
- Mecanismos de caducidad de las contraseñas
- Posibilidad de bloqueo de los datos (no eliminación física)
NIVEL MEDIO
- Control de accesos fallidos (bloqueo de cuenta tras superar el límite establecido)
NIVEL ALTO
- Log de accesos reflejando usuario, hora, registro accedido, tipo de acceso, autorizado o denegado
- Conservación de los logs durante 2 años
- Si el software en cuestión efectúa directamente la transmisión de datos por redes de telecomunicación, ésta debe ser de forma cifrada
Hay bastantes puntos más como por ejemplo las copias de seguridad, usuarios genéricos, etc. pero según mi particular criterio corresponden al ámbito general o global de la LOPD (política de seguridad) y no son directamente dependientes del producto de software como tal. Esta lista hace referencia a las medidas mínimas que todo software de tratamiento de datos de carácter personal, para entendernos el típico software de alta/baja/modificación, debe cumplir.
Obviamente no pretende ser un conjunto de requerimientos para todo tipo de software, para eso ya están los common criteria y sus EAL1, EAL2, ..... El objetivo es que sea una relación de las características mínimas que cualquier producto de software debería poseer para poder tratar datos de carácter personal de acuerdo a lo especificado en el RD.
CITA DEL DÍA: "Durante un análisis de riesgos no hay lugar para el optimismo"
3 comentarios:
Edgard,
En mi opinión se te cuela lo relativo a la seguridad y ¿bloqueo o borrado? -borrado directo, en mi opinión- de los ficheros temporales.
De todas formas, como no hay sanción asociada al incumplimiento de esta obligación de los proveedores de software, pues...
Salu2
Cierto amigo deincognito. Buen apunte lo de los ficheros temporales. No entiendo a que te refieres exactamente con "lo relativo a seguridad" ......
Efectivamente, en el fondo no es un problema de incumplimiento o no. Se trata simplemente de aplicar algo que dice una normativa. Si tengo un rato intentaré verificar si en distintos productos de software "estrella" que traten DCP se incluye alguna mencióna al nivel de seguridad que alcanzan. Gracias por leer y participar.
Edgard,
Con lo de "relativo a la seguridad" me refiero a lo de "deberán cumplir el nivel de seguridad que les corresponda conforme a los criterios establecidos en el artículo 81" (art. 87.1 RLOPD).
Apuesto a que ninguno te va a indicar nada sobre el nivel de seguridad que aportan. Total como no hay infracción asociada ;-p
Salu2
Publicar un comentario