Blog
Proyectos
Mostrando entradas con la etiqueta Politicas de seguridad. Mostrar todas las entradas
Mostrando entradas con la etiqueta Politicas de seguridad. Mostrar todas las entradas

viernes 25 de abril de 2008

Escándalo por filtración de datos personales

Desde varios post de este blog (véase por ejemplo Me da igual y Me sigue dando igual) se ha tratado de concienciar a todo el mundo de la importancia de seguir ciertas políticas de seguridad para mantener nuestros equipos y los datos que ahí guardamos a salvo de extraños. La ignorancia y la despreocupación sobre la seguridad de nuestro equipo y sobre la importancia de los datos que ahí puede haber guardados, se traslada muchas veces al ámbito del trabajo. Frente a la legislación actual que trata de proteger la privacidad en la gestión de los datos de carácter personal (véanse los post sobre LOPD en este mismo blog), siempre sigue habiendo personas, empresas, instituciones, que no ponen todo el énfasis que debieran en proteger los datos.

Hoy mismo se ha publicado una noticia en la que se informa de que más de 11.000 historias clínicas de pacientes, entre las que se incluyen 4.000 historias de casos de abortos, han podido ser filtradas desde una clínica de Bilbao. La noticia es especialmente preocupante ya que los datos fueron compartidos a través de la red P2P de emule, lo cual indica deficiencias graves de seguridad por parte del empleado/s (que utilizaron el emule en el trabajo sin preocuparse de lo seguro que podía ser) y también por parte de la clínica (que no se ha preocupado por la seguridad de su red informática). La clínica en cuestión ha sido sancionada con 150.000 euros por la agencia española de protección de datos (AEPD) lo cual obviamente ha hecho que tome conciencia del problema e implante medidas de seguridad estrictas en sus sistemas informáticos. No obstante, según la misma noticia, este no es un caso aislado. La agencia de protección de datos ha abierto 21 expedientes a lo largo de 2007 por filtraciones a Internet de datos personales sobre historias clínicas, datos personales de recursos humanos, solicitantes de adopciones internacionales, etc.

¿Está nuestra privacidad a salvo en la era de la información? .......


Guzmán Santafé
S21sec labs


lunes 21 de abril de 2008

Federal Trojan Horse

The German investigators have not yet been able to do the controversial secret online searches because of missing software. Joerg Ziercke - chief of the BKA - said they are working under "high pressure" on the appropriate software, but it would be no problem to get it also from other countries which already do this kind of observation.


The law to permit this way of online analysis is not yet determined - but the theoretical agreement exists now even though in a very restrictive form. At present the details are being discussed, like if the police is allowed to enter accommodations to install the software or if everything has to be done remotely.

For the police the situation is comparable to installing secret video cameras in order to observe people - here they are also permitted to enter the accommodations and install the necessary equipment.

The opponents see in secret online observations a break of the basic rights and a big step in the change from a democratic state towards a surveillance state.

Clemens Kurtenbach
S21sec labs

jueves 17 de abril de 2008

Spam - Google calendar

Está claro que sólo es cuestión de tiempo que un sistema sea atacado. Ahora le toca al gigante Google, y su integración de gmail con los clientes de correo de Microsoft Outlook y Outlook Express.

El problema proviene al usar una técnica mediante la cual se adjunta correo electrónico no solicitado a un archivo en el formato de calendario de Gmail. De forma que se adjunta un recordatorio en el calendario de los clientes de correo.

Debido a que la integración del cliente de correo con g-mail incorpora “de serie” la modalidad de “agregar automáticamente invitaciones a mi calendario”, el fichero de correo no deseado es agregado directamente al calendario del usuario, incluso sin ser abierto.

La solución, muy sencilla, deshabilitar dicha opción por defecto para que no se incorporen los archivos de formato calendario automáticamente.

Más información aquí.

José María Arce Guillén
S21sec labs

jueves 10 de abril de 2008

Comprometida red de suministro y distribución eléctrica por pentesters

En la RSA Conference que está teniendo lugar estos días en San Francisco, California unos pentesters han presentado los detalles de un trabajo de "pentesting" o "penetration testing" realizado en una empresa del sector energético.

Tras haber recolectado las direcciones de correo electrónico del grupo de usuarios de los sistemas SCADA con los que se gestionaba la red de suministro y distribución eléctrica, los pentesters han podido tomar control de la red eléctrica después de haber tenido éxito en un ataque de phishing que dirigía a los usuarios a una página web que presentaba un error, y al mismo tiempo descargaba malware en los equipos de los usuarios por medio de los que adquirieron su control. La empresa mantenía sin segregar las redes corporativa y de control, la primera de ellas con acceso a Internet, factor principal de éxito del ataque.

Los detalles sobre el trabajo pueden verse aquí.

Cada vez más se va notando el interés de las empresas usuarias de sistemas de control de instalaciones industriales o infrastructuras críticas (PLC, DCS o SCADA) en la gestión de la seguridad de la información, después de haber caído en la cuenta de que las redes y sistemas de control son vulnerables por las diferentes razones que se presentan en este artículo de algunos de nuestros compañeros de S21sec (ver páginas 18 a 20).

Recientemente hemos tomado parte en un proyecto en Oriente Medio para evaluar el estado o la madurez y proponer recomendaciones sobre el sistema de gestión de seguridad de la información de una empresa de producción de petróleo, gas y electricidad. Esta empresa ya tenía clara la importancia de la segregación de las redes corporativa y de control en cuyo proceso de implantación estaba inmerso, habiéndonos dado la oportunidad de participar también en el diseño lógico de la nueva arquitectura de red una vez finalizada la segregación física.

Esperemos poder seguir prestando nuestros servicios de consultoría de gestión, operativa y técnica en materia de seguridad de la información a las entidades que cuentan con sistemas de control de infraestructuras industriales o infraestructuras críticas.

Álvaro Del Hoyo
Departamento de Consultoría

lunes 7 de abril de 2008

Hasta la cocina

No son pocas las empresas y particulares que usan en la actualidad un servidor proxy para dar salida a Internet. Con ello pueden ganar en velocidad de navegación, ya que las páginas más visitadas serán cacheadas por él, y además, éste podrá usarse como filtro de contenidos, que realmente puede que sea lo único que lleve a una empresa a instalarlo. En este caso me estoy refiriendo a un proxy HTTP (aunque también se usen para otros protocolos), pero también existen los que usan el protocolo SOCKS, en sus distintas versiones. Especialmente son estos últimos los que pueden dar más información de la debida si no son configurados correctamente. Esto no es nuevo, ni mucho menos, pero se hace necesario un pequeño recordatorio de vez en cuando a modo de toque de atención.

Pongamos el caso de un internauta curioso que navega por la red de redes y se dispone a probar un proxy SOCKS configurado en su navegador. Además, no sólo eso, sino que le da por enchufar su sniffer favorito para ver la comunicación entre su PC y el proxy. Después de pegar sus ojos a la pantalla y pasar unas cuantas tramas llega a una que le llama la atención. Dentro del protocolo SOCKS que le responde el servidor ve una IP interna. ¿Coincidencia?


Como ya he dicho que el internauta es curioso pone en el navegador esa IP y espera paciente la respuesta. Parece que no hay mucha suerte, por lo que deja entrever el siguiente error en un idioma asiático.


Pero bueno, si esa IP no parece dar ningún fruto, ¿por qué no probar con otras IPs del mismo rango? puede que haya más suerte...


Vaya, vaya, parece ser el acceso interno a la configuración del router, un D-Link DI-804HV. No creo que esto sea una buena política de seguridad...

Pero con el protocolo SOCKS no sólo es posible acceder al puerto 80, sino que teóricamente se podría acceder a cualquier puerto de esa máquina. Usando la librería SocksiPy de Python se tendría la herramienta perfecta para probar la teoría.


Y así, nuestro curioso amigo podría seguir indagando en las posibilidades que le ofrece esa pasarela a la red interna de la empresa X. De hecho, no le costaría demasiado trabajo la programación de un escáner de puertos para explorar todas las máquinas de ese rango, con la intención de descubrir hasta dónde podría llegar...

El problema es que en el mundo no sólo hay internautas curiosos, sino que también pululan a sus anchas algunos que intentarán sacar provecho de esos agujeros de seguridad. Además de instalar un servidor proxy es muy importante configurarlo correctamente y estrictamente para nuestro uso privado, prohibiendo explícitamente que alguien sea capaz de atravesarlo y acceder a nuestra red interna. Este ejemplo es extensible a otros servicios de red, que deben comprobarse meticulosamente antes de ser publicados en Internet; si no, como habéis visto, se nos pueden meter hasta la cocina.


José Miguel Esparza
S21sec labs

jueves 27 de marzo de 2008

Novedades del nuevo Reglamento LOPD respecto a la gestión de soportes y documentos

Al analizar en profundidad el recién estrenado 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 RLOPD), me ha llamado la atención la importantísima novedad relativa a la obligación de solicitar autorización al responsable del fichero, cada vez que se remita un correo electrónico que incluya datos de carácter personal.

Art. 92.2: La salida de soportes y documentos que contengan datos de carácter personal, incluidos los comprendidos y/o anejos a un correo electrónico, fuera de los locales bajo el control del responsable del fichero o tratamiento deberá ser autorizada por el responsable del fichero o encontrarse debidamente autorizada en el documento de seguridad.

Esta novedad, que parece haber pasado desapercibida en los numerosos artículos y eventos que se están realizando, equipara los correos electrónicos a los soportes de información (memorias removibles, cintas de backup, etc.) siendo por lo tanto necesaria la solicitud de autorización al responsable del fichero cada vez que se quiera enviar un correo electrónico donde se incluyan datos de carácter personal.

Esta medida, lógicamente no es gestionable por ninguna organización independientemente de la magnitud de la misma, ya que todo profesional / trabajador, utiliza el correo electrónico como herramienta de trabajo transmitiendo a través del mismo ingentes cantidades de información que incluyen en muchos casos datos de carácter personal. Asimismo y teniendo en cuenta que la citada medida de seguridad se refiere a datos de nivel básico, se debe cumplir la medida de seguridad en todos y cada uno de los correos electrónicos que incluyan cualquier tipo de dato de carácter personal.

Siguiendo con la problemática surgida con la equiparación de soporte de información y el correo electrónico, se podría, llegando al absurdo, a generar un registro de entrada y salida de todos y cada de los correos electrónicos que entren o salgan con algún dato de carácter personal en su cuerpo o adjunto al mismo. En dicho registro se debería incluir: la fecha, hora, el emisor, el destinatario, el tipo de información recibida o enviada, la persona responsable de la recepción, la persona responsable de la emisión y la correspondiente autorización.

Llegados a este punto, y teniendo en cuenta los plazos de prescripción de las sanciones, los registros y las autorizaciones para recibir y/o enviar correos electrónicos deberán almacenarse por un periodo no inferior a tres años.

Finalmente y como conclusión comentar la gran dificultad que tendremos todas las organizaciones para cumplir escrupulosamente con lo establecido por el nuevo RLOPD, ya que la labor administrativa y organizativa que exige es desmesurada .

Koldo Peciña Txintxurreta
Consultor Senior S21sec

Códigos tipo y transferencias internacionales de datos

La Legislación de Protección de Datos de Carácter Personal vigente en España, permite dentro del respeto de los mínimos legalmente establecidos, la posibilidad de que las entidades públicas y/o privadas que tratan datos de carácter personal, puedan establecer criterios voluntarios de adecuación que les permita mejorar el tratamiento de los datos de carácter personal que realizan.

En este sentido, se pueden establecer diferentes marcos de trabajo entre los cuales destacan:

1. LOS CODIGOS TIPO

Son un conjunto de buenas prácticas de adhesión optativa, que recogen compromisos adicionales y criterios básicos relacionados con la protección de datos.

Los códigos tipo deben cumplir los criterios mínimos que establece la legislación de Protección de Datos, y constituyen una adopción voluntaria que obliga al cumplimiento de su contenido en tanto en cuanto la entidad se adhiera a ellos.

Son inscritos en el Registro General de Protección de Datos, previa aprobación de su contenido por la Agencia Española de Protección de Datos, y se han constituido como elementos útiles para la adopción de posturas adoptadas unilateralmente por empresas o criterios sectoriales para tratamiento de datos de carácter personal.

Los Códigos Tipo tienen una gran aceptación por parte de los clientes potenciales así como de la ciudadanía en general puesto que establece un compromiso de respeto al derecho a la intimidad, al honor y la propia imagen del afectado.

  1. ACUERDOS INTERNACIONALES

Si tenemos en cuenta una perspectiva internacional de datos, salvando los casos en los que el afectado consiente de forma expresa el tratamiento internacional de los datos, la Legislación Española de Protección de Datos, establece la necesidad de que el país de origen y el país de destino tengan un mismo nivel de protección en materia de datos de carácter personal.

En relación a ello, se establecerán dos grandes grupos;

  1. Países destinatarios con un nivel de protección equivalente. Respecto a los cuales, para la realización de transferencias internacionales de datos no se requiere autorización del Director de la Agencia Española de Protección de Datos, dado que bien el Estado Español bien la Unión Europea considera que garantizan un nivel de protección equivalente. El listado de estos países es publicado regularmente en el Boletín Oficial del Estado.
  1. Países destinatarios respecto a los cuales no se considera que exista un nivel de protección equivalente.

En cuyo caso las entidades españolas que pretendan realizar una transferencia internacional de datos a estos países (y dicha transferencia no se encuentra exceptuada por Ley) deberán solicitar autorización al Director de la Agencia Española de Protección de Datos, en donde deberán fundamentar que entre ambas partes se ha establecido acuerdos concretos que garanticen dicha equivalencia de protección a la legislación española.

Ambos supuestos relativos a la transferencia internacional de datos, constituyen en relación a países fuera del espectro territorial de la Unión Europea una adhesión voluntaria, bien Estatal mediante la formalización de Acuerdos Internacionales, bien de la entidad destinataria mediante la formalización de acuerdos bilaterales privados, o la adhesión a protocolos marco (como pueden ser los denominados Protocolo de Puerto Seguro entre Estados Unidos y la Unión Europea).

En todo caso, el contenido de estos acuerdos, contratos bilaterales y protocolos de adhesión son de libre disposición siempre y cuando garanticen el cumplimiento de un contenido mínimo establecido por la Legislación de Protección de datos aplicable en el país de origen.

NORMAS CORPORATIVAS VINCULANTES

Dentro del marco internacional establecido anteriormente, se ha añadido la posibilidad de que empresas de un mismo grupo puedan definir e implantar las denominadas Normas Corporativas Vinculantes (Binding Corporate Rules) que son una propuesta de la Unión Europea enfocado a flexibilizar los movimientos internacionales de datos.

Las Normas Corporativas Vinculantes (NCV) son declaraciones de grupos empresariales internacionales que comparten datos de carácter personal entre todas ellas, que definen un criterio corporativo para el tratamiento de datos de carácter personal.

La ventaja de las NCV respecto al resto de elementos contractuales arriba referenciados, cuando la transferencia internacional de datos se realiza países que no tienen un nivel de protección equivalente al Español es el ahorro de tramites burocráticos ante la Agencia Española de Protección de Datos, dado que sólo se solicita una autorización bajo unas premisas de tratamiento de datos que vincularán a todas las empresas pertenecientes a ese grupo empresarial.

Uno de los “inconvenientes” que se le asocian a las NCV es que deben estar regidos por la norma local más restrictiva en materia de protección de datos, de todas las que apliquen al holding empresarial, y que debe ser de obligado cumplimiento en todas las empresas filiales.

En conclusión siempre bajo el prisma del cumplimiento de los mínimos establecidos en la Legislación Española de Protección de Datos, las entidades ya sean públicas o privadas pueden adherirse a criterios voluntarios relativos al tratamiento de protección de datos que mejoran su imagen empresarial ante Organismos como la Agencia Española de Protección de Datos, y sus clientes potenciales.

No obstante estas normativas de aceptación voluntaria constituyen un catálogo de criterios de adecuación adicionales que deben de ser adoptados por las entidades de forma obligatoria desde su adhesión.

Será por tanto, necesario que cada entidad de forma individualizada establezca dentro de su estrategia empresarial la importancia que quiere dar a la Protección de Datos Personales y las relaciones sectoriales, nacionales e internacionales que desee adoptar.

Montserrat Gómez Florez
Departamento de Consultoría

miércoles 26 de marzo de 2008

La figura del encargado del tratamiento

La figura del encargado del tratamiento ha sido objeto de uno de los más manidos debates en la interpretación de la legislación en materia de datos de carácter personal desde sus orígenes.

El estatuto jurídico del encargado del tratamiento fue regulado en primer lugar por el artículo 27 Ley Orgánica 5/1992, de 29 de octubre, de Regulación del Tratamiento Automatizado de los Datos de Carácter Personal (en adelante, "LORTAD"), y desde el inicio de su aplicación práctica generó diversas dudas en su interpretación, en parte alimentadas por el hecho de que no contaba con desarrollo reglamentario alguno y por insuficiencias que fueron parcialmente resueltas por los artículos 12 y 43 de la Ley Orgánica 15/1999, de 13 de diciembre, de Protección de Datos de Carácter Personal (en adelante, "LOPD").

A continuación listamos los principales aspectos que integran el estatuto jurídico de la figura del encargado del tratamiento:

  • Distinción entre los términos "responsable del fichero o tratamiento" y "encargado del tratamiento";
  • Distinción entre cesión o comunicación de datos y acceso a datos por cuenta de terceros;
  • Aplicación a ficheros automatizados y no automatizados;
  • Régimen de responsabilidad del encargado del tratamiento;
  • Formalidades en la contratación del tratamiento de datos a terceros (encargados del tratamiento);
  • Medidas de seguridad aplicables por el encargado del tratamiento;
  • Destrucción y devolución de los datos, soportes o documentos en que conste algún dato de carácter personal objeto del tratamiento;
  • Conservación de los datos objeto de la prestación de tratamiento por el encargado de éste;
  • Posibilidad de subcontratación del tratamiento por parte del encargado de éste y formalidades en su contratación.
La AGPD vino a resolver algunas de las dudas interpretativas existentes por medio de los Informes 283/2004, 416/2004 y 513/2004 de su Asesoría Jurídica, en los que la Asesoría Jurídica venía a reiterar lo ya manifestado en el Plan de Inspección de Oficio a las empresas participantes en la elaboración de los Censos de Población y Viviendas del año 2001, de fecha 17 de julio de 2003. Estos informes se complementan con el Informe 000/2000 cuyo contenido fue revisado en 2006 para incluir la referencia a este Plan de Inspección de Oficio en precisión sobre lo manifestado en este anterior informe sobre la posibilidad de subcontratación de terceros por el encargado del tratamiento.

Precisamente lo manifestado por la AGPD en estas recomendaciones ha sido lo que ha venido a incluirse en el Título II, Capítulo III (artículos 20 a 22) 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, "RLOPD") estableciendo la regulación de la figura del encargado del tratamiento en desarrollo del artículo 12 LOPD y que se complementa con lo establecido en el artículo 43 LOPD y con las referencias específicas al encargado del tratamiento en el Título VIII RLOPD relativo a las medidas de seguridad aplicables a los ficheros de datos de carácter personal.

A continuación, citaremos las novedades que trae consigo el RLOPD y los nuevos problemas interpretativos que trae consigo en relación con el estatuto jurídico del encargado del tratamiento aún reconociendo el avance que supone este nuevo articulado:
  • Formalidades en la contratación de los servicios que impliquen el tratamiento de datos de carácter personal
Las formalidades en la contratación de los servicios de tratamiento de datos de carácter personal vienen estipuladas en el artículo 12 LOPD, en cuya atención y el artículo 20.2 RLOPD viene ahora a establecer que el responsable del fichero "deberá velar por que el encargado del tratamiento reúna las garantías para el cumplimiento de lo dispuesto en este Reglamento".

Quizás hubiera sido conveniente añadir en este artículo un "en todo momento" en relación a una posible reclamación basada ya sea en la "culpa in eligendo", "culpa in contrahendo" o "culpa in vigilando".

  • Cesión o comunicación de datos a terceros por el encargado del tratamiento
Tanto el artículo 12.2 LOPD como el 20.3 RLOPD establecen que el encargado del tratamiento no podrá comunicar a terceros los datos, ni siquiera para su conservación.

El artículo 20.3 RLOPD en su último párrafo viene a aclarar que "el encargado del tratamiento no incurrirá en responsabilidad cuando, previa indicación expresa del responsable, comunique los datos a un tercero designado por aquél, al que hubiera encomendado la prestación de un servicio conforme a lo previsto en el presente capítulo", en clara referencia a la transición del servicio de tratamiento de un encargado del tratamiento a otro.

  • Destrucción o devolución de los datos objeto de la prestación de tratamiento
El artículo 12 LOPD dispone que los datos objeto de la prestación de tratamiento, al igual que cualquier soporte o documentos en que conste algún dato de carácter personal objeto del tratamiento, deban de ser destruidos o en su caso devueltos al responsable del tratamiento.

En este sentido, y en atención a lo dispuesto por los artículos 16.3 y 16.5 LOPD, el artículo 22.1 RLOPD viene a aclarar en su segundo párrafo que la devolución de los datos procederá en tanto en cuanto existan obligaciones legales de conservación. A este segundo párrafo del artículo 22.1 RLOPD se le puede y debe hacer la crítica de que obvia las obligaciones de conservación de tipo voluntario que pudieran existir como reconoce el propio artículo 16.5 LOPD.

  • Conservación de los datos personales objeto del contrato del servicio que implique su tratamiento
El artículo 12 LORTAD establecía la obligación de destruir los datos objeto de la prestación de tratamiento una vez concluida ésta, si bien habilitaba la posibilidad de que el responsable del fichero autorizara la conservación de los datos por el encargado del tratamiento por un plazo máximo de 5 años y adoptando las debidas condiciones de seguridad porque razonablemente se presumiera la posibilidad de ulteriores encargos.

Esta posibilidad fue omitida por el artículo 12 LOPD, si bien el Informe 283/2004 vino a recordar que de conformidad con el artículo 1157 Código Civil y con la jurisprudencia del Tribunal Supremo la prestación del servicio de tratamiento de datos se ha de considerar cumplida una vez ésta ha concluido, a salvo de cumplimiento gravemente defectuoso o de ausencia de coincidencia con la prestación estipulada en el contrato. Todo ello sin perjuicio del derecho que asiste al encargado del tratamiento a recibir el pago por el responsable del fichero del precio acordado como contraprestación del servicio prestado. Ello significaría que una vez cumplida la prestación de tratamiento de datos el encargado de éste debería proceder a la destrucción o devolución de los datos objeto del contrato, si bien el artículo 1255 del Código Civil habilitaría un posible pacto entre las partes consistente en que "el cumplimiento de la prestación pudiera entenderse condicionado a la conformidad del responsable del tratamiento con la actuación efectuada por el encargado, de modo que se indicase en el contrato que la prestación de aquél se entenderá cumplida cuando, una vez finalizada la actividad en que consistía el tratamiento encomendado al encargado del tratamiento, el responsable del tratamiento compruebe y dé su conformidad a la actuación de aquél, siempre que para el otorgamiento de dicha conformidad se establezca un plazo razonable y reducido de tiempo".

Aún y todo, no existiendo acuerdo de este tipo entre el responsable del fichero y el encargado del tratamiento, si ha de ser considerado el encargado del tratamiento también como responsable del tratamiento, era lógico pensar que en atención a lo dispuesto en los artículos 16.3 y 16.5 LOPD, el encargado del tratamiento pudiera conservar los datos objeto de la prestación mientras se pudieran derivar responsabilidades de su relación con el responsable del fichero, de igual manera a cómo lo puede hacer el responsable del fichero (bloqueo de datos). Esto viene a ser ahora reconocido expresamente, como era lógico, por el artículo 22.2 RLOPD.

Por tanto, una vez cumplida la prestación de tratamiento los datos, soportes y documentos objeto de la prestación habrán de ser devueltos al responsable del fichero, a la vez que bloqueados para su conservación por el encargado del tratamiento durante el tiempo en que pudieran derivarse responsabilidades de su relación con el responsable del tratamiento. De modo que la destrucción de los datos por el encargado del tratamiento tan sólo tendrá lugar una vez alcanzado el final del referido plazo máximo de conservación que le sea aplicable.

Cuestión distinta serán las dudas interpretativas que genere la regulación del bloqueo de los datos y que la AGPD ha tratatado de resolver en sus Informes 000/2001 y 127/2006. Y digo que ha tratado de resolver, pues creo que la solución dada no es del todo conforme o no encaja perfectamente con el articulado de la LOPD y su normativa de desarrollo, incluido el RLOPD.

  • Subcontratación de terceros por el encargado del tratamiento
Como apuntábamos antes, los artículos 12.2 LOPD y 20.3 RLOPD prohíben al encargado del tratamiento comunicar a terceros los datos objeto del servicio, aunque tan sólo fuera para su conservación.

Ello nunca ha impedido la subcontratación de terceros por el encargado del tratamiento siempre que se hiciera con el consentimiento y en nombre y por cuenta del responsable del fichero, si bien es cierto que el principio de transparencia requería ciertas obligaciones formales en la celebración de la subcontratación que no estaban recogidas en la legislación. Esto mismo es lo que vino a poner de relieve el Plan de Inspección de Oficio a las empresas participantes en la elaboración de los Censos de Población y Viviendas antes citado.

La doctrina manifestada por la AGPD en este Plan de Oficio viene a incorporarse en el artículo 21 RLOPD, si bien creo que la redacción de este artículo es manifiestamente mejorable y creo que se ha complicado sobremanera, pues este artículo no viene más que a reiterar las formalidades exigibles en la contratación de los servicios de tratamiento a los casos en los que el encargado del tratamiento los subcontrate total o parcialmente a terceros. Además el artículo 21.2 RLOPD induce a confusión al afirmar que es posible la subcontratación sin necesidad de autorización siempre y cuando se cumplan los requisitos en él listados. La subcontratación se ha de producir siempre con autorización del responsable del fichero como demuestran los referidos requisitos y, en especial, lo manifestado por el artículo 21.3 RLOPD.

Álvaro Del Hoyo
Departamento de Consultoría

martes 25 de marzo de 2008

¿Vulnerabilidades en usuarios sin privilegios?

La seguridad de las aplicaciones que dan soporte a un negocio son cruciales para su éxito. Por ello, las normas y códigos de buenas prácticas en los sistemas de SGSI, aconsejan la creación y el uso de usuarios con permisos restringidos.

Esto puede resultar en dos problemas con difícil solución:
  • Realizar un correcto análisis de la necesidad del negocio en base al perfil del usuario. Es decir, crear roles de acuerdo a los requerimientos de los diferentes perfiles y asignarles privilegios adecuados. Lo que en la práctica no es tan sencillo ni trivial.
  • Caer en la falsa creencia de que un usuario restringido es menos vulnerable a los problemas de seguridad de las aplicaciones de escritorio.
Algunos departamentos de IT argumentan que no es necesario actualizar versiones vulnerables de aplicaciones cliente porque los usuarios que las usan tienen los permiso restringidos y por ello, no pueden ser explotadas. Me vienen a la cabeza unos cuantos ataques a los cuales estos usuarios "sin privilegios" serían vulnerables, pongamos por ejemplo ser carne de botnets, MITM, phishing, csrf y cualquier tipo de malware.


La correcta gestión de usuarios sin privilegios en los SOs es ya de por sí complicada, pero si a eso le unimos contradicciones como permisos de administrador para actualizar software, versiones previas de software actualizado (java), y la heterogeneidad de todas las aplicaciones cliente, nos encontraremos en un escenario caótico donde la única regla será "sálvese quien pueda".

¿Todavía crees que no es necesario actualizar tu versión de adobe reader, java (JRE), quicktime, firefox, realplayer o excel?, sólo por nombrar algunas aplicaciones cliente, aunque bien es cierto que firefox es una de las mejores en cuanto a las actualizaciones automáticas.

Las aplicaciones de escritorio actualmente están siendo objeto de ataques tipo "Drive by download" donde el usuario, a través de una vulnerabilidad en estas aplicaciones se descarga malware sin su conocimiento simplemente por visitar una página web. Luego, siempre nos quedará decir que nosotros no hemos sido.

¿Todavía te crees a salvo con ese usuario sin privilegios?

Emilio Casbas
S21sec labs

Niveles de seguridad aplicables a ficheros y tratamientos de datos personales

Recientemente he podido desarrollar un estudio pormenorizado de los niveles de seguridad establecidos en el nuevo Reglamento 1720/2007 de desarrollo de la LOPD (en adelante RDLOPD) en sus arts. 80 y 81 y varias son las cuestiones que me han suscitado algún comentario o debate.

En primer lugar una de las novedades que aporta el RDLOPD es que el establecimiento de los niveles de seguridad ya no se realiza únicamente en función de “la naturaleza de la información tratada” tal como fijaba el art. 3.2. del ya extinto Reglamento 994/1999 de Medidas de Seguridad (RMS), sino que el nuevo RDLOPD tiene en cuenta diferentes factores como son el tipo y naturaleza de los datos contenidos, el tipo de actividad objeto social del Responsable del fichero o la naturaleza pública o privada del mismo. Parece claro que un mismo rasero para todos los responsables de ficheros ya no era la postura más lógica y aquí las administraciones públicas han salido ganando frente a otros colectivos como las telecomunicaciones o la banca.

Respecto de los niveles de seguridad dos tipos de ficheros suscitan la mayor parte de mis dudas…

En el caso “sui generis” de los ficheros de los que sean responsables los operadores que presten servicios de comunicaciones electrónicas disponibles al público o exploten redes públicas de comunicaciones electrónicas respecto a los datos de tráfico y localización; las medidas de seguridad aplicables serán las medidas de nivel básico y medio más el registro de control de accesos del art. 103 RDLOPD. Todo un éxito en la puja entre las empresas de telecomunicaciones y el gobierno que en un primer momento quería obligar a estos operadores a implantar todas las medidas de nivel alto a sus ficheros de facturación y trafico…

Ahora bien, la duda que se nos ha suscitado no pocas veces, recae sobre qué nivel de seguridad declarar ante el Registro General de Protección de Datos respecto de este tipo de ficheros. El sistema de declaración de ficheros de la Agencia, el sistema “NOTA”, tampoco establece una solución del tema. En mi caso entiendo que la solución más prudente en estos casos pasa por declararlos como ficheros de nivel medio y luego incluir en el documento de seguridad la medida de registro de control de accesos exigida, no sea que por declarar el fichero como de nivel alto los inspectores entiendan que son de aplicación todas las medidas de nivel alto y que por tanto se han incumplido las mismas, aunque todos sabemos que la declaración de ficheros únicamente tiene efectos declarativos…

Otro hecho destacable dentro del listado de niveles de seguridad es el siempre controvertido fichero que contenga datos para la “evaluación de la personalidad o comportamiento de los ciudadanos”. La actual redacción del RDLOPD ofrece una mejora respecto del RMS ya que ahora no se habla de la necesidad de contar con “datos suficientes para poder obtener una evaluación de la personalidad” sino que exige que efectivamente el fichero contenga datos referentes a “características o personalidad de los ciudadanos” y que estos datos permitan a su vez “evaluar la personalidad y comportamiento” de los mismos.

¿Es esto un doble requisito o bastaría tener datos “suficientes” como decía el RMS para poder hacer una evaluación de la personalidad?. ¿Cuáles son los datos de características del individuo o de su personalidad?. Tampoco se dice si estos datos deben provenir directamente del individuo o pueden ser fruto de una tratamiento que de los datos iniciales y objetivos del individuo pueda realizar el responsable del fichero Ejemplo típico de estos tratamientos los tenemos en el escoring financiero realizado por bancos o los estudios de fiabilidad hechos por las aseguradoras.

Quizás el art. 36.1 RDLOPD, pueda aportar algo de luz al tema pues al hablar del derecho de oposición habla tangencialmente de las actividades que pueden suponer una evaluación de personalidad, refiriéndose a ellas como aquellas actividades encaminadas a “evaluar el rendimiento laboral, crédito, fiabilidad o conducta” del individuo.

En resumen, ¿Son estas actividades del art. 36.1 RDLOP las evaluaciones de personalidad a las que se refiere el art.81.2.f)? ¿Qué son datos de características del individuo o de su personalidad? y ¿estos datos han de existir de forma previa a la evaluación o basta con un conjunto de datos suficientes para hacerlo?. Última pregunta: ¿Estos datos sobre características y personalidad, han de ser aportados directamente por el individuo o pueden ser elaborados por el responsable del tratamiento a partir de datos objetivos de aquel?

He ahí el debate…

Raúl Rodriguez Celaya

Dpto. Consultoría

jueves 6 de marzo de 2008

El "pretexting" en la legislación española (II)

No existen en España obligaciones legales específicas en cuanto a la configuración o calidad de los sistemas de autenticación en la provisión de servicios de atención telefónica, si bien los responsables de ficheros que los provean han de cumplir con el deber de secreto y seguridad exigidos por los artículos 9 y 10 LOPD y con el régimen legal establecido para la satisfacción del derecho de acceso por los titulares de datos personales.

El artículo 15 LOPD establece que el derecho de acceso consiste en "solicitar y obtener gratuitamente información de sus datos de carácter personal sometidos a tratamiento, el origen de dichos datos, así como las comunicaciones realizadas o que se prevén hacer de los mismos", derecho que si bien "sólo podrá ser ejercitado a intervalos no inferiores a doce meses, salvo que el interesado acredite un interés legítimo al efecto".

La Instrucción 1/1998, de 19 de enero, de la Agencia de Protección de Datos, relativa al ejercicio de los derechos de acceso, rectificación y cancelación vino a determinar la forma y las condiciones en las que se debía producir el ejercicio de los derecho de acceso, rectificación y cancelación, exigiendo que ha de mediar solicitud dirigida al responsable del fichero por el interesado o persona que legal o voluntariamente la represente, la cual contendrá:

  • Nombre, apellidos del interesado y fotocopia del DNI del interesado y, en los casos que excepcionalmente se admita, de la persona que lo represente, así como el documento acreditativo de tal representación. La fotocopia del DNI podrá ser sustituida siempre que se acredite la identidad por cualquier otro medio válido en derecho;
  • Petición en que se concreta la solicitud;
  • Domicilio a efectos de notificaciones, fecha y firma del solicitante;
  • Documentos acreditativos de la petición que formula, en su caso; y
  • El interesado deberá utilizar cualquier medio que permita acreditar el envío y la recepción de la solicitud.

En esta misma Instrucción se establece que "el responsable del fichero podrá denegar el acceso a los datos de carácter personal cuando el derecho se haya ejercitado en un intervalo inferior a doce meses y no se acredite un interés legítimo al efecto", añadiendo tal posibilidad también "cuando la solicitud sea formulada por persona distinta del afectado", a salvo de los casos en que el derecho de acceso pudiese ejercerse por representante legal o voluntario del interesado, casos en los que el responsable del fichero habrá de asegurarse de constatar la realidad de la representación por medio del documento acreditativo correspondiente.

Por otra parte, concreta esta Instrucción la forma de la información que se debe proporcionar al interesado que ha ejercido su derecho de acceso, así como la información que en concreto deba facilitarse al interesado, resultando particularmente gravoso para los responsables de ficheros que exigiera la entrega de "todos" los datos personales tratados, lo cual además de implicar un elevado coste para los responsables de ficheros podía no ser del interés del titular de los datos que tan sólo pretenda acceder a algunos de los datos en poder de aquellos.

Resulta evidente que estos requerimientos en la autenticación de la identidad del interesado que pretende ejercer el derecho de acceso no casa bien con la agilidad que puede ser necesaria, por ejemplo, en la obtención de una copia de una factura telefónica (y no de todos los datos en poder del operador) o con la posibilidad de ejercer el derecho de acceso por medio de servicios de atención telefónica o medios telemáticos dispuestos al efecto.

Ello vendrá a resolverse con la entrada en vigor del Reglamento de la LOPD (RLOPD) puesto que, además de admitir los servicios de atención telefónica como cauces válidos tanto para la emisión de la negativa al tratamiento como para la revocación del consentimiento, el artículo 24.4 reconoce a quienes disponen de este tipo de servicios la posibilidad de conceder a los interesados por este medio el ejercicio de los derechos de acceso, rectificación, cancelación y oposición, en cuyo caso dispone además "la identidad del interesado se considerará acreditada por los medios establecidos para la identificación de los clientes del responsable en la prestación de sus servicios o contratación de sus productos". Medios que como hemos comentado antes pueden no ser del todo idóneos y estar siendo caldo de cultivo de quienes deseen hacer uso del "pretexting".

Los interesados que ejercieran sus derechos de acceso, rectificación, cancelación y oposición empleando los servicios de atención al cliente quedan excepcionados por el artículo 25.1 RLOPD de enviar comunicación alguna al responsable del fichero, si bien entiendo que ello implica necesariamente que el responsable de fichero deba registrar en sus sistemas los datos identificativos y la petición concreta formulada, así como el domicilio a efectos de notificaciones en caso de que no coincidiera con el domicilio de facturación de los clientes. Si bien es cierto que que cuando fuera necesario los interesados habrán de enviar en cualquier caso los documentos acreditativos de la petición que formulasen los interesados.

El hecho de que no se requiera copia del documento nacional de identidad, pasaporte o documento válido que identifique a quienes ejercen su derecho de acceso por medio de los servicios de atención telefónica deja en manos de la robustez del sistema de autenticación implantado o de la candidez o solidaridad de los teleoperadores el acceso a datos personales de terceros por quienes empleen el "pretexting", incrementado así la probabilidad de que el responsable del fichero en el que obran los datos pueda ser sancionado por vulneración del deber de secreto que le es impuesto por el artículo 10 LOPD y que supone una infracción leve, si bien puede que grave o muy grave dependiendo de los casos, sea dado el sector de las compañías citadas, o por estarse tratando datos de nivel alto o datos que en su conjunto sean suficientes para obtener una evaluación de la personalidad del individuo.

Podría ser mejor que estas compañías que prestan servicios al público en general de especial trascendencia económica derivaran las solicitudes de derechos de acceso, rectificación, cancelación y oposición al "medio de interlocución telemática" basado en el "uso de certificados reconocidos de firma electrónica" que les impone el artículo 2 de la Ley 56/2007, de 28 de diciembre, de Medidas de Impulso de la Sociedad de la Información. Aunque desconozco hasta qué punto este tipo de compañías van a dotarse de este medio de interlocución telemática, puesto que en esta ley no se establece régimen sancionador para el incumplimiento de esta obligación.

Como decíamos en el anterior post el "pretexting" es una práctica habitualmente empleada por detectives privados, aunque puede ser utilizada por cualquiera. Huelga decir que, abstrayéndonos de los casos en los que el atacado fuera una persona jurídica, los datos personales que fueran obtenidos fraudulentamente y las demás informaciones que gracias a ellos se consiguieran habrán de ser apreciadas como nulas por un Juez en caso de que le fueran presentadas como pruebas (art. 11.1 LOPJ). Aparte se daría el hecho de que los detectives privados que hicieran uso de esta técnica podrían ser sancionados por las condiciones ilícitas en que se produce el tratamiento por estos de los datos personales obtenidos por medio del "pretexting".

Pero el "pretexting" no sólo está regulado por la legislación en materia de protección de datos de carácter personal, ya que al mismo tiempo este tipo de prácticas pueden suponer, según los casos (por ejemplo, acceso a datos de una póliza de seguros de salud o de vida) una intromisión ilegítima en el derecho a la intimidad personal y familiar (artículo 7.2 Ley Orgánica 1/1982) e incluso pueden caber en el tipo del delito de descubrimiento y revelación de secretos (Capítulo 1 del Título X del Libro II del Código Penal).


En definitiva, ya sea por el "pretexting" o casi mejor, para asegurarse de realizar un totalmente adecuado tratamiento de los datos personales de su responsabilidad, cualesquiera entidades que ofrecieran servicios de atención telefónica debieran analizar y revisar los procesos de estos servicios a fin de adecuarlos a la legislación en maeria de protección de datos, prestando especial interés principalmente a la robustez y calidad los sistemas de autenticación empleados en estos servicios no presenciales. Es de destacar que aún no habiéndolos mencionado anteriormente, los servicios de atención telefónica de la Administración Pública pueden ser igualmente objeto de ataques de "pretexting" y que en atención al artículo 8.2.c de la Ley 11/2007, de 22 de junio, de acceso electrónico de los ciudadanos a los Servicios Públicos, los sistemas de autenticación empleados deberán garantizar la seguridad de las informaciones sobre los ciudadanos a las que se dé acceso por medio de este tipo de servicios.

Álvaro Del Hoyo
Departamento de Consultoría

martes 26 de febrero de 2008

Datos personales, direcciones IP y los movimientos de Google (III)

En relación con esta serie de posts, 1 y 2, hemos de indicar que Google ha dado un nuevo paso. Y el Grupo del Artículo 29 también.

Por otra parte, gracias al blog de Samuel Parra he accedido a esta interesante resolución de la AGPD en la que se decide que dada la posibilidad de modificar una dirección IP no se puede determinar con exactitud que un usuario de una red local, haciendo uso del equipo informático que la empresa le tenía asignado, fuera quien publicó en una página web datos personales contenidos en un fichero responsabilidad de aquélla.

Una buena monitorización y gestión de "logs" podía haber ayudado a esta empresa a evitar la interpretación hecha en la jurisdicción social.

Álvaro Del Hoyo
Departamento de Consultoría

jueves 21 de febrero de 2008

No des tu password

La gestión de cuentas/contraseñas de usuarios, que comprende aspectos como eliminar o modificar cuentas de usuarios que cambian de puesto dentro de una misma compañía, o modificar el nivel de acceso de un usuario con su cuenta, es una tarea a la que a menudo no se le da la importancia que le corresponde.

Al tratarse de una tarea algo repetitiva, en teoría sencilla, debido a algún descuido, puede ocurrir que no se realice correctamente (dejarse cuentas viejas activas etc.). Además, hay que añadir que en algunas ocasiones son los propios usuarios del sistema los que lo comprometen al facilitar la contraseña de su cuenta.¿Quién no ha
visto o conocido la situación en la que un compañero de oficina se va de vacaciones y tiene que dejar su password a otro para realizar una tarea en concreto?.

Todos estaréis pensando que lo que digo no es nada nuevo, pero ante casos como lo ocurrido con el banco frances Société Générale creo que es necesario sacar el tema a la palestra. Si una entidad financiera tan importante como esta última (a la que se le supone que cuenta con unas medidas de seguridad importantes) ha descuidado tanto este aspecto, ¿que es lo que estará ocurriendo en otro tipo de compañías?

Es necesario pues, para que una compañía funcione con unas garantías mínimas de seguridad, por un lado concienciar a los usuarios (mi contraseña es mía y de nadie más) y por otro, llevar un control exhaustivo de quien puede entrar y que puede hacer dentro del sistema.



Asier Marruedo
S21sec labs

sábado 16 de febrero de 2008

Datos personales, direcciones IP y los movimientos de Google (II)

Peter Fleischer, responsable de privacidad para Europa de Google, ha publicado un nuevo post en su blog personal acerca del debate sobre la consideración o no de las direcciones IP como datos de carácter personal.

Expone los mismos argumentos en contra del carácter personal de las direcciones IP que exponía yo en nuestro anterior post sobre este tema, pero sigue olvidándose de tomar en cuenta que los buscadores de Internet, proveedores además de otros muchos servicios de la Sociedad de la Información, adquieren cantidades ingentes de datos que relacionan o pueden relacionar con los identificadores únicos que asignan a los navegadores de sus usuarios y que se recopilan junto con las direcciones IP fijas o dinámicas que estos emplean.

Parece que Peter Fleischer declaró que "there is no black or white answer: sometimes an IP address can be considered as personal data and sometimes not, it depends on the context, and which personal information it reveals" y quizás sus propias palabras le estaban dirigiendo a la respuesta que no espera recibir del Grupo del Artículo 29.

Me temo que próximamente todos los buscadores de Internet se van a llevar un par de jarros de agua fría en forma de Dictamen del Grupo del Artículo 29: uno, sobre el uso de "logs" y "cookies" y, otro sobre publicidad contextual. Aparte de la que se le pueda venir encima en términos de privacidad a Google en relación con la compra de Double-Click.

En cualquier caso, sí que estoy de acuerdo con Peter Fleischer en destacar los problemas que trae consigo la consideración de las direcciones IP como datos de carácter personal en relación con el deber de información, el principio de consentimiento, ya sea para el tratamiento o para la cesión de las direcciones IP, o con las transferencias internacionales de estos datos o con el ejercicio de derechos de acceso, rectificación cancelación y oposición.

Pensemos por ejemplo en el tratamiento que de los datos de tráfico -las direcciones IP lo son- están habilitados los ISPs a llevar a cabo para la gestión de la seguridad de sus servicios y redes (ver artículo 4 de la Directiva 2000/58/CE) o en el tratamiento de direcciones IP que hacen los CERT para la vigilancia de la Red y la defensa organizada contra el ciberterrorismo o ataques a gran escala contra los usuarios de la Red.

¿No sería mejor que los ISPs no necesitaran de consentimiento para la cesión entre operadores para combatir de forma conjunta ataques distribibuidos, el "spam" o el "phishing"? ¿Realmente no sería beneficioso que un CERT quede excepcionado de cumplir con los principios de transparencia, consentimiento y cesión con respecto a las direcciones IP que tratan?

Veremos en qué resulta finalmente todo este debate.

¿Alguna modificación en ciernes de la regulación europea de la privacidad?

Álvaro Del Hoyo
Departamento de Consultoría

jueves 14 de febrero de 2008

Redes P2P, datos personales, ilícitos civiles, delitos y seguridad de la información (II)

En el anterior post comentábamos la sentencia del caso 275/06 del TJCE y adelántabamos el contenido de este nuevo post.

Como constata el TJCE no existe en España norma alguna que obligue a los operadores a comunicar los datos personales de sus clientes en el marco de un proceso civil de cualquier tipo ni en concreto con la finalidad de la protección de los derechos de autor. O al menos de momento, pues aunque sea por la inercia tomada en otros Estados europeos incluso puede que también vayamos más allá de una regulación que obligue a los ISPs a ceder los datos personales de sus clientes usuarios de redes P2P como ya está sucediendo en algunos Estados europeos.

En Francia se ha optado por un modelo voluntario de colaboración de los ISPs con las sociedades de gestión de derechos de autor, a la espera de que llegue la ley que regule esta invasión de los derechos a la intimidad, al secreto de las comunicaciones y a la protección de datos, además de a las libertades de expresión y de información. El objeto de estos acuerdos es el filtrado de la navegación de los usuarios de Internet para el bloqueo del acceso a las redes P2P. Este filtrado ha sido puesto por los ISPs en manos de terceros, cuya actividad parece ser está y seguirá estando celosamente supervisada por la CNIL, en especial en lo que atañe a la obligación de que las direcciones IP se hagan anónimas inmediatamente durante el filtrado. De las dos inspecciones realizadas hasta la fecha en una de ellas ya se ha encontrado al encargado del filtrado registrando las direcciones IP para una sociedad de gestión de derechos de autor.

Ante el fracaso de las negociaciones entre las sociedades de gestión de derechos de autor y los ISPs británico para establecer un sistema similar al ya existente en Francia, parece que la semana que viene se presentará en el Reino Unido una nueva ley que obligará a los ISPs a trazar las comunicaciones de sus clientes, de modo que en caso de que se detecte se está haciendo uso a redes P2P habrán de remitir por dos veces una advertencia de cese que en caso de no ser atendidas implicará la interrupción del servicio de acceso a Internet. Los datos identificativos y otros datos personales de los usuarios infractores podrán ser cedidos a los tribunales. Es preciso recordar que en el Reino Unido no se halla establecida la limitación de copia privada, siendo el uso de redes P2P en