Plazo de conservación de los documentos de auditoría
Según el art. 96 del Real Decreto 1720/2007, de 21 de diciembre, por el que se aprueba el Reglamento de desarrollo de la Ley Orgánica 15/1999, de 13 de diciembre, de protección de datos de carácter personal , en adelante Reglamento, “a partir del nivel de seguridad medio los sistemas de información e instalaciones de tratamiento y almacenamiento de datos se someterán, al menos cada dos años, a una auditoría interna o externa que verifique el cumplimiento” del Título VIII del Reglamento, añadiendo que “con carácter extraordinario deberá realizarse dicha auditoria siempre que se realicen modificaciones sustanciales en el sistema de información que puedan repercutir en el cumplimiento de las medidas de seguridad implantadas con el objeto de verificar la adaptación, adecuación y eficacia de las mismas”. Esta auditoría inicia el cómputo de dos años señalado en el párrafo anterior.
Se dice posteriormente que el informe de auditoría deberá estar a disposición de las agencias de protección de datos pero no indica durante cuánto tiempo deben conservarse estos informes.
El art. 44.3 h) de la Ley Orgánica 15/1999, de 13 de diciembre, de Protección de Datos de Carácter Personal, en adelante LOPD, indica que “es infracción grave mantener los ficheros, locales, programas o equipos que contengan datos de carácter personal sin las debidas condiciones de seguridad que por vía reglamentaria se determinen”. Dicha infracción prescribirá a los dos años de su comisión, tal y como dispone el art. 47.1 de la LOPD. Así la entidad requerida debería siempre tener a disposición de la Agencia un informe emitido durante los dos años anteriores al momento en el que se solicita el requerimiento.
El siguiente informe jurídico de la Agencia Española de Protección de datos corrobora lo mencionado anteriormente.
Sin embargo la Autoridad Catalana de Protección de Datos, considera que el plazo de conservación de estos documentos de Auditoría sería de tres años en el dictamen que a continuación se relaciona.
http://www.apdcat.net/media/dictamen/es_286.pdf#search=”Historias clinicas sin medida de seguridad “
En este dictamen la Autoridad Catalana en un primer momento y con misma fundamentación que la Agencia Española llega a la conclusión que debe ser 2 años el plazo de conservación.
Pero posteriormente considera que el registro de incidencias, puede resultar un valioso elemento probatorio en la investigación de otros tipos de infracciones que tienen atribuido un plazo de prescripción más largo, en el caso de infracciones muy graves, que tendría un plazo de prescripción de tres años.
Pero además el artículo 19 de la LOPD también contempla la responsabilidad por daños o lesiones que las personas afectadas sufran en sus bienes o derechos, ya sea mediante la reclamación de la responsabilidad de la Administración, cuando el daño sea imputable a una Administración pública, o mediante el sistema de responsabilidad extracontractual establecido en el derecho civil. En este sentido, disponer de la documentación relativa a las auditorías puede ser un elemento probatorio importante para la acreditación de la diligencia del responsable en el cumplimiento de las medidas de seguridad exigibles. Al respecto hay que recordar que la letra d) del artículo 121-21 del Libro primero del Código Civil de Cataluña establece que prescriben a los tres años las pretensiones derivadas de responsabilidad extracontractual, y las demás pretensiones al cabo de diez años, salvo la recuperación de la posesión (artículos 121-20 y 121-22). En conclusión, la documentación que forma parte de las auditorías de seguridad requeridas por dicha normativa debe conservarse durante un período mínimo de tres años, o hasta que se realice la auditoría de seguridad siguiente, si esta no se ha efectuado dentro del plazo de dos años exigible.
Audea Seguridad de la Información
Aurelio J. Martínez Ferre.
Departamento Legal
Google otra vez en el punto de mira de la Comisión Europea
Google sigue acumulando quejas antimonopolio interpuestas por las compañías rivales ante los organismos reguladores de la Unión Europea. Hasta ahora la Comisión Europea ha confirmado cuatro casos contra Google pero hay por lo menos otros tantos que se esta investigando. A pesar de que la Comisión no quiere dar más pistas sobre estos casos, se cree que algunas de las quejas procedían de los organismos reguladores nacionales, mientras que otros perjudicados podían ser las pequeñas empresas que buscan su sitio en el mercado de buscadores de Internet. Las primeras pesquisas se iniciaron en noviembre del año pasado, tras las acusaciones planteadas por tres firmas que afirmaban que Google degradaba sus sitios en las búsquedas web porque suponían una competencia para la multinacional. En total son ya nueve quejas formales y los rivales incrementaban la presión sobre el buscador número uno del mundo.
Extrañamente, también Microsoft, una de las compañías más denunciadas por quebrantar las leyes de competencia, se incorporó al grupo de los descontentos planteado su primera queja ante la Comisión Europea en marzo de este año, asegurando que Google bloqueaba sistemáticamente la competencia de búsquedas en Internet, lo que demuestra la dura rivalidad entre ambas compañías.
Y como si no fuera suficiente, la Comisión de Comercio de Estados Unidos también investiga a Google tras las quejas de que abusó de su dominio del mercado. El comité antimonopolio del Senado de Estados Unidos celebrará una vista sobre la parte del mercado que tiene Google el 21 de septiembre.
Áudea Seguridad de la Información
Departamento Legal
www.audea.com
Proteger aplicaciones Ruby on Rails de ataques SQL INJECTION
En el siguiente artículo se va a exponer los mecanismos de protección de seguridad de las aplicaciones web Ruby on Rails frente a los ataques de inyección SQL.
La seguridad de las aplicaciones webs depende del conocimiento y experiencia de los programadores, y es el resultado de la seguridad aplicada en cada una de las capas de la aplicación.
Las últimas estadísticas y estudios siguen indicando que aproximadamente el 75% de los ataques realizados tienen como víctimas a las propias aplicaciones webs, y esos mismos estudios indican que casi el 100% de los sitios auditados contenían algún tipo de vulnerabilidad en la capa de aplicación.
Uno de los más famosos y habituales ataques a la capa de aplicación se denomina SQL Injection, tal y como indica el TOP 10 de OWASP (The Open Web Application Security Project). Dicho ataque consiste en modificar los parámetros de entrada de un formulario para obtener al formar la sentencia SQL un resultado no esperado por la aplicación.
En el siguiente ejemplo se muestra código fuente vulnerable
Project.find(:all, :conditions => “name = ‘#{params[:name]}’”)
Si un atacante introduce en el parámetro ‘ OR 1=1′ la sentencia SQL resultante será:
SELECT * FROM projects WHERE name = ” OR 1 –’
Por lo que la sentencia devolverá todos los registros de la tabla Project, ya que la condición es siempre verdadera para todos los registros.
Otro ejemplo se código vulnerable permitiría a un atacante autenticarse en la aplicación sin tener conocimiento previo de ninguna credencial:
User.find(:first, “login = ‘#{params[:name]}’ AND password =
‘#{params[:password]}’”)
Si el atacante introduce ‘ OR ’1′=’1 en el nombre, y ‘ OR ’2′>’1 en la contraseña, la sentencia SQL resultante será:
SELECT * FROM users WHERE login = ” OR ’1′=’1′ AND password = ” OR ’2′>’1′
LIMIT 1
Por lo que se encontrará el primer registro de la tabla users y se permitirá el acceso con dicho usuario.
Ruby on Rails posee un filtro para caracteres SQL especiales. Utilizando Model.find(id) o Model.find_by_something(something) automáticamente aplicará la contramedida frente a ataques de inyección SQL, aunque en fragmentos de condiciones SQL (:conditions => “…”), los métodos connection.execute() o Model.find_by_sql (),tiene que ser aplicado de forma manual.
En lugar de pasar una cadena a la opción de condiciones, se puede pasar una matriz para limpiar las cadenas de la siguiente forma:
Model.find (: en primer lugar,: Condiciones => ["? Login = Y = contraseña", entered_user_name, entered_password]). La primera parte de la matriz es un fragmento de SQL con signos de interrogación.
También se puede pasar un hash para el mismo resultado
Model.find (: first,: Condiciones => {: login => entered_user_name,: password =>entered_password}).
En otros casos se puede emplear sanitize_sql(condition, table_name = self.table_name).
Áudea Seguridad de la Información
Antonio Martínez
Departamento Seguridad TICs
www.audea.com
La ley SINDE comprometida
De acuerdo a una sentencia de la Audiencia de Barcelona, se desestima el recurso de SGAE contra Indice (sitio web de enlaces) al no considerar un acto de comunicación pública enlazar contenidos bajo la protección de los derechos de autor.
La cuestión a debate comenzó con la aprobación de la Ley Sinde, cuando se previó el cierre por una comisión administrativa de las webs que enlazan ese tipo de contenidos, alegando vulneración del derecho exclusivo de comunicación pública de los creadores, que se recoge en la ley de Propiedad Intelectual.
El tribunal considera que Indice “no realiza ninguna reproducción, ya que se limita a suministrar el link”. Además, la sentencia recoge que los enlaces no son un acto de comunicación pública ya que “la descarga del archivo se produce desde un sitio web diferente del sitio del demandado y el usuario puede advertirlo”.
Lo curioso, ¿a que se debe el cambio de criterio?; el pasado marzo, la misma sala de la Audiencia Provincial de Barcelona condenó al titular del sitio web Elrincondejesus a indemnizar a SGAE con 2.041 euros en compensación por los ingresos que no percibieron como consecuencia de las cantidades que dejaron de ingresar por las descargas ilegales.
Lo que queda por concretar aún es: ¿que tiene más peso, el permiso de cerrar webs que alojen enlaces a descargas que ofrece la Ley Sinde o la interpretación constitucional de la justicia?
Audea Seguridad de la Información
Departamento Legal
www.audea.com
Ni tanto, ni tan calvo.
Los caminos del Señor, y los criterios de la AEPD son inescrutables.
Hoy veremos cómo 2 supuestos muy similares, arrojan resultados radicalmente distintos, gracias a los criterios interpretativos de la Agencia Española de Protección de Datos.
Supuesto #1:
Por error, una empresa de telefonía móvil envía factura de otro cliente por email. Los datos revelados por error, incluyen: Nombre y apellido; NIF; Dirección; código postal; localidad; entidad bancaria; número de cuenta bancaria (diez dígitos); detalle de llamadas por número de teléfono.
Supuesto #2:
Por error, una empresa de reparación de terminales móviles da un pendrive con copia de seguridad de 7 teléfonos distintos al suyo a una clienta particular. Los datos revelados por error, incluyen: Nombre y apellidos del titular del teléfono, fotografías personales, agenda personal con teléfonos, mails y direcciones de sus contactos, lista de llamadas emitidas y recibidas, y sms emitidos y recibidos.
¿Qué diferencia ambos supuestos?
En el primer supuesto, la empresa de telefonía móvil es responsable de un fichero, conforme a la Ley Orgánica de Protección de Datos y responde de los incumplimientos en que haya incurrido.
Sin embargo, en el segundo supuesto, la clienta no es “responsable” de ningún fichero, pues los “ficheros mantenidos por personas físicas en el ejercicio de actividades exclusivamente personales o domésticas” están excluidos del ámbito de aplicación de la LOPD (2.2.a LOPD).
Es lógico y comprensible. No tendría sentido que un latin lover tuviese que informar a sus conquistas de que sus datos serán incorporados a un fichero de su responsabilidad con la finalidad de… Bueno, quizá en este caso concreto… sí podría ser defendible… pero si cada uno de nosotros tuviese que cumplir con la LOPD por los datos de nuestros familiares, amigos y conocidos, seguramente nos encerraríamos en casa.
¿Y qué sucede con la tienda de reparación de terminales móviles? ¿No es responsable por su negligencia?
Pues no. Para la AEPD, al no aplicar la LOPD al dueño del fichero por ser un fichero de agenda personal… el tratamiento que hace la tienda por instrucción del dueño, tampoco está sometido al régimen sancionador de la LOPD.
Si la tienda hubiese utilizado los datos obtenidos para sus propios fines, sí hubiese sido responsable de tratar datos sin consentimiento… pero como lo que hizo fue incumplir con la obligación de deber de secreto con respecto a las 7 personas que vieron vulnerada su intimidad por esta tienda, la AEPD entiende que no procede imponer ninguna sanción.
Sin embargo, a la empresa de telefonía móvil del primer supuesto, le pusieron una multa de 6000 euros contantes y sonantes.
¿Y esto qué supone?
Pues… por poner algunos ejemplos… supone lo siguiente:
- Un servicio de correo electrónico español (p.e. @telefonica.net) no tiene que aplicar medidas de seguridad de ningún tipo a una hipotética base de datos de direcciones de destinatarios de emails de sus clientes.
- Igualmente, si @telefónica.net tuviese un percance de seguridad que afectase a estos datos, tampoco tendría ninguna responsabilidad.
- Un servicio de agenda online dirigido a particulares no tiene por qué cumplir con ninguna de las medidas de seguridad del Reglamento.
…Y un sinfín de ejemplos más.
¿Es correcto el criterio de la AEPD?
A todas luces… no lo es.
Los ficheros recibidos por la persona denunciante del segundo supuesto también incluyen datos personales propios de los clientes de la tienda, que sí son responsabilidad de la misma, y deberían estar protegidos por la LOPD.
Sin embargo, el criterio repetido por la AEPD, no cede ni ante un recurso debidamente motivado.
Lo dicho, los criterios de la AEPD son inescrutables y al parecer, no somos dignos de ponerlos en duda.
Audea Seguridad de la Información
José Carlos Moratilla
Consultor legal
www.audea.com
