Security Art Work

Hace unos días en la comunidad en la que vivo se llevo a cabo una medida que me llamo mucho la atención y que me hizo reflexionar: se reordenaron los buzones de los vecinos del portal.

Como pasa en todos los edificios de vecinos, cada domicilio tiene asignado un buzón para el correo postal, que se encuentra en la entrada y que generalmente suele ser el receptor de facturas y publicidad a partes iguales. Pues resulta que el orden en el que estaban situados los buzones no cumplía las especificaciones descritas en el Real Decreto 1829/1999, el cual recoge las directrices concretas para llevar a la práctica lo que establece la Ley del Servicio Postal Universal y de Liberalización de los Servicios Postales.

Para ajustarnos a la normativa vigente, en la comunidad se procedió a la reasignación de los buzones. Pero cuál fue mi asombro cuando descubrí que la reordenación se limitó a cambiar los cartelitos donde pone el nombre de las personas que viven en cada domicilio, y al pertinente intercambio de llaves entre los propietarios, sin cambiar las cerraduras. Dicho de otra forma: la llave que yo tenía de mi buzón sigue abriendo ese buzón aunque ya no sea el que me corresponda.

[Read more…]

Aunque les prometimos que el pasado viernes publicaríamos las entradas al primer consultorio LOPD de Security Art Work, la carga de trabajo de la semana pasada ha hecho que tuviésemos que retrasarlo hasta hoy. Aunque la participación ha sido ligeramente inferior a la esperada, hemos intentado unificar las preguntas en la medida de lo posible, de modo que quedasen cubiertas el máximo número de consultas. Como disclaimer previo, simplemente decir que las respuestas dadas a las consultas son según nuestro mejor saber y entender, independientemente de que un estudio pormenorizado de algunas de las situaciones personalizadas pudiera generar una respuesta diferente.

Espero que les haya resultado útil e interesante, y les emplazamos para la siguiente sesión, de fecha todavía por definir. Sin más dilación, les dejo con la parte interesante de la entrada…

— ¿Cómo es posible cumplir “real y honestamente” con el procedimiento de revisión y tratamiento de los ficheros temporales? (Felipe)

Al respecto, el artículo 5.2.g indica que los ficheros temporales son aquellos “ficheros de trabajo creados por usuarios o procesos que son necesarios para un tratamiento ocasional o como paso intermedio durante la realización de un tratamiento.”

Asimismo, el artículo 87 del reglamento, habla de las condiciones a aplicar en su tratamiento:

Al igual que pasa con el concepto de incidencia, el RDLOPD es muy ambiguo con lo que considera un fichero temporal, aspecto que no ayuda mucho a la hora de determinar su correcto tratamiento. Un fichero temporal podría ser una Excel generada a partir de una exportación de datos, tablas temporales de cálculo de un proceso, o fotocopias de documentos. El problema se genera principalmente en los ficheros temporales creados por los usuarios, y no tanto en los creados por procesos informáticos o automatizados. En ese caso, es importante concienciar a los usuarios y fomentar el uso de repositorios departamentales en red, de modo que dichos ficheros temporales sean almacenados con controles de acceso y no residan en dispositivos móviles o equipos personales.

— Limitar la salida de datos de carácter personal a través del correo electrónico. (Felipe)

Esta obligación viene recogida en el artículo 92.2 del reglamento:

Este es sin duda uno de los aspectos más complicados de cumplir de la LOPD, y más teniendo en cuenta que es una medida de seguridad que debe aplicarse a todos los tratamientos, independientemente del nivel de seguridad. En este caso, dada la inviabilidad de que el responsable del tratamiento autorice cualquier salida de datos de carácter personal por correo electrónico, se recomienda incluir la autorización de envíos de correo electrónico de carácter personal en el Documento de Seguridad, delimitando esta autorización a los departamentos cuya gestión e intercambio de datos de carácter personal es más habitual: RRHH, Prevención de Riesgos Laborales, y Administración. Por supuesto, será necesario definir hábitos correctos a la hora de adjuntar datos personales a los correos electrónicos (datos en anexos y no en el cuerpo del correo, utilizar interlocutores definidos cuando sea posible, herramientas de cifrado, etc.).

— Soy un autónomo y no me dedico a una actividad en la que tenga un gran volumen de datos de carácter personal. Aun así, ¿he de adaptarme a la LOPD? (Juan)

Según el artículo 2 de la LOPD:

Por tanto, los ficheros mantenidos por personas físicas en el ejercicio de actividades profesionales están dentro del ámbito de aplicación de la LOPD.

— Recibimos muchos curriculums por correo electrónico y postal en nuestra empresa. ¿Tenemos que hacer algo con ellos? (Marta)

Depende del tratamiento que se le vaya a dar a éstos. Si no se van a conservar, porque no son útiles para la organización, no es necesario hacer nada salvo destruirlos adecuadamente. Si por el contrario van a ser utilizados (almacenados o gestionados para futuras contrataciones), tendrán que tener en cuenta tres aspectos:

• Declaración del fichero ante la Agencia Española de Protección de Datos.
• Deberán proporcionar el derecho de información que exije el artículo 5 de la LOPD.
• En cuanto a su almacenamiento, lo habitual es seguir uno de estos enfoques: a) tratarlos exclusivamente en soporte papel, imprimiendo los correos electrónicos y borrando estos últimos, y b) tratarlos exclusivamente en soporte electrónico, pasando a soporte electrónico los curricula recibidos en soporte papel y protegiéndolos adecuadamente con control de accesos.

— Tenemos un formulario de sugerencias en nuestra página web a través de la que nuestros clientes pueden remitirnos consultas, comentarios, sugerencias. En algún caso hemos recibido comentarios que incluyen datos de salud. ¿Debemos declarar dicha base de datos como de nivel alto? (Andrés)

No (perdonen el lapsus mental). Sí, dado que se trata de un tratamiento automatizado. Tal y como indica el artículo 81.5 del RDLOPD, no será necesario cuando esto suceda en tratamientos no automatizados:

No obstante, se recomienda eliminar la información de nivel alto que no esté directamente relacionada con la finalidad del tratamiento, y mantener el nivel del tratamiento. En cualquier caso, sería necesario estudiar los detalles concretos para dar un veredicto definitivo.

— El nuevo reglamento nos traslada más obligaciones a las empresas a la hora de subcontratar servicios a otras empresas. ¿En qué consisten esas obligaciones? (Laura)

Efectivamente, así es, y no sólo “cuando hay datos personales por en medio”. También introduce la novedad de tener que firmar acuerdos de confidencialidad con las empresas a las que se subcontratan servicios que “en teoría” no deben tener vinculación con el tratamiento de datos personales, pero que puntualmente podrían tenerlo. Son los casos típicos de las empresas de limpieza, empresas de retirada de residuos, empresas de vigilancia, etc.

En relación con las prestaciones en las que sí se tratan datos personales, ya existía la obligación de lo que los abogados llaman el “deber in vigilando” (la obligación de velar por que las cosas se estén haciendo bien…). Pero el RDLOPD detalla en sus artículos 20 y 21 que no basta con firmar un contrato de acceso a datos que recoja los requisitos del artículo 12 de la LOPD: “el responsable del tratamiento […] deberá velar por que el encargado del tratamiento reúna las garantías para el cumplimiento de lo dispuesto en este reglamento”.

Otra cosa es cómo comprobar este punto. Y aquí pueden intervenir factores externos, como puede ser la “relación de fuerzas” entre ambas entidades. Por nuestra experiencia, lo habitual es que el encargado del tratamiento acredite que está “al día” en cuanto al cumplimiento de la LOPD. En otros casos incluso se exige que se facilite el informe de su última auditoría bienal. Finalmente —y de hecho estamos haciéndolo así para un cliente del sector privado sanitario— se puede estipular en el contrato que se abordarán auditorías de cumplimiento en el tercero.

— ¿Qué indemnización cabe recibir de una empresa que me sigue enviando publicidad después de ser cliente suyo? (María)

La LOPD no fija ninguna indemnización para los titulares de los datos, y esta es una idea que le choca a algunas personas. La LOPD puede sancionar a la empresa, pero de esta sanción no se deriva ningún beneficio económico para el perjudicado por un mal tratamiento. En este caso, si usted considera que merece una indemnización, deberá emprender acciones legales contra la empresa.

— A pesar de disponer de carpetas departamentales, muchos empleados de mi empresa siguen utilizando sus unidades locales para almacenamiento de bases de datos, excels y ficheros con datos de carácter personal. ¿Es necesario hacer copias de esta información también? (Luis)

Sí, puesto que dichos datos de carácter personal son responsabilidad de la empresa. Por tanto, no se puede delegar en los empleados la realización de las copias de sus equipos, ni obviar el hecho de que estén gestionando datos de carácter personal sin las adecuadas medidas de seguridad. Puede obtener más información en esta entrada. En cualquier caso, nuestra recomendación es la implantación de una normativa que prohíba el almacenamiento de información corporativa en general en los equipos personales, obligando a la utilización de los discos de red.

La semana pasada asistí a una jornada sobre Delitos Informáticos organizada por Lex Nova y el ICAV. Como no podía ser de otra manera atendiendo a la naturaleza de los organizadores, la jornada consistió en un estudio práctico, desde su vertiente legal, de los delitos que han surgido “amparados” por el auge de las nuevas tecnologías en nuestra sociedad: intrusismo y sabotaje informático, y estafas utilizando las nuevas tecnologías. También se trató el controvertido tema del control laboral sobre el uso de los recursos corporativos (léase correo electrónico e Internet, entre otros).

Intrusismo

El artículo 197 del CP actual castiga la vulneración de la intimidad y la privacidad de la persona, mientras que el artículo 278 persigue la revelación de secretos de empresa. Cualquier menoscabo de la competitividad de una empresa motivada por una fuga o extracción de información se considera revelación de secreto de empresa. Y dicho menoscabo puede ser provocado por la revelación de un listado de clientes, de un acuerdo comercial o de un nuevo proyecto de I+D+i. Y yo apunto: cualquier menoscabo de su competitividad… ¿y por qué no también de su reputación o de su imagen de empresa?

[Read more…]

Hace un rato he bajado la última versión del navegador Opera, concretamente Opera 10 Beta, en base a las noticias que dicen que es más rápido, más estándar, y más todo. Lo es, casi puedo asegurarlo. Incluida la parte del “todo”, y eso no siempre es bueno.

La cuestión es que dicho navegador tiene un modo “Turbo”, que se activa pinchando en un icono que hay en la esquina inferior izquierda. Quizá esto no sea nuevo para los usuarios habituales de Opera, pero sí lo es para mí. Accediendo al blog a través de Opera, me doy cuenta de que el acceso no aparece proveniente de mi IP privada, sino como procedente de la IP 94.246.126.147. Qué raro. Indagando lo mínimo, veo que:

[Read more…]

No me cabe duda de que todos ustedes conocen Facebook. Otra cosa es que lo utilicen de manera asidua; yo personalmente todavía no le acabo de encontrar el gusto. La cuestión es que como saben, si buscan ustedes a alguien dentro de esta red social, no es “amigo” suyo y el perfil de la persona no es público, sólo verán lo siguiente:

Esto significa, por ejemplo, que no tendrán acceso a las fotos de esta persona, que suele ser uno de los recursos más “codiciados” de este tipo de redes sociales. Eso, en teoría, porque al parecer, según nos enteramos por Mar Monsoriu, y tal y como comentan en Geek The Planet, sí existe una forma de acceder a esta información, a no ser que el usuario haya previsto esa posibilidad previamente (algo que muchos usuarios no hacen). Sigan leyendo.

El (posible) problema

Si le echan un vistazo a la página del usuario de la imagen anterior, verán que debajo de la foto hay un enlace, que dice “Agregar a Oscar a mis amigos”, y que está formado de la siguiente forma:

donde “XXXXXXXX” es el identificador de nuestro amigo Óscar en Facebook. Este identificador aparece también en otros enlaces, como en “Enviar un mensaje a Oscar”, “Ver todo” o “Denunciar a esta persona”. El caso es que, una vez hemos obtenido el identificador, vamos a la página web para desarrolladores de aplicaciones:

En esa página, seleccionamos “Facebook PHP Client” en Formato de Respuesta, y fql.query en el desplegable de los métodos. Debajo aparecerá un recuadro donde escribir la consulta SQL que queremos aplicar sobre el identificador que hemos obtenido. Aunque es posible obtener otro tipo de información, vamos a limitarnos a los álbumes de fotos. Así pues, escriban la siguiente consulta SQL:

Con lo que obtendremos (cuando el usuario tenga álbumes de fotos) una serie de URLs con el siguiente formato:

Que sólo tendremos que pegar en el navegador para acceder al álbum de fotos.

La (posible) solución

El problema viene motivado por el sistema que Facebook tiene para desarrolladores de aplicaciones, que permite que éstas puedan acceder a algunos datos de los usuarios, si éstos no se han tomado las suficientes molestias. Otra cosa es porqué este tipo de acceso se permite, pero dejemos las reflexiones para más adelante. ¿Cómo evitamos que nuestro perfil sea visible de esta forma?

Pues la solución no está demasiado clara, ya que aunque no es complicada, no tengo claro que sea definitiva. Dentro de nuestro perfil, vamos a “Configuración”, “Privacidad”, “Administrar”, donde tendremos las siguientes cuatro opciones:

Si nuestro perfil es “típico” y no hemos cambiado demasiadas cosas, veremos que en las tres primeras opciones todo parece correcto. Aparecemos en búsquedas públicas, pero la información que se proporciona es básica, y en general, nuestra información sólo esta accesible a personas conocidas (“amigos”). Sólo nos queda por tanto ver la parte de “Aplicaciones”.

Al entrar, nos aparecerán cuatro puntos hablando de cómo y cuándo las aplicaciones pueden acceder a tus datos, aunque como hemos visto en el anterior paso, nosotros no somos aplicaciones y sí hemos podido acceder a los álbumes de algunas personas. A continuación vamos a la pestaña “Configuración” de esa misma página, donde nos aparecerá algo como lo siguiente:

A partir de aquí les confieso que todo se vuelve algo “borroso”, ya que no he podido hacer bastantes pruebas para determinar la eficacia de los cambios, debido a razones que les expondré luego. Todo apunta a que lo ideal sería marcar “No compartir ninguna información sobre mí a través de la interfaz de programación de aplicaciones (API) de Facebook“, pero en general esa opción aparecerá sombreada debido a que

Por tanto, deberíamos revisar las aplicaciones que estamos usando, y eliminarlas, y entonces marcar dicha opción, aunque eso puede ser un proceso no sencillo ni trivial para cualquier persona con varios meses en Facebook y un uso medio de la red social. Otra opción sería desmarcar todas las casillas, y guardar cambios, aunque francamente, no tengo demasiado claro que eso vaya a solucionar algo.

Para acabar con esta sección, aparentemente sólo los álbumes que un usuario permite compartir con los amigos de sus amigos son accesibles mediante este procedimiento, y no los álbumes que están bajo las configuraciones de privacidad “Sólo yo” y “Sólo mis amigos”. No obstante, como he dicho antes, esto es una conclusión obtenida a partir de un par de pruebas simples, por lo que podría ser que no fuese cierta del todo. Personalmente, he hecho pruebas con usuarios aleatorios con los que no tengo ninguna relación, obteniendo todos sus álbumes (en otros casos, no he podido acceder a ninguno). Por tanto, les recomiendo no poner fotos que les comprometan en algún sentido, por simple precaución.

Conclusiones

Aunque inicialmente tendía a pensar que esto que les he comentado era una vulnerabilidad de Facebook, tras ver que hay configuraciones de privacidad que pueden evitar el acceso por parte de terceros a través del portal de desarrolladores, no estoy seguro de lo que es, o mejor dicho, de cómo considerarla; aunque sea una “feature” documentada, si viola políticas de privacidad, debería considerarse como un problema de seguridad. Hay varios aspectos que me gustaría destacar:

1. La entrada de Geek The Planet que trata este problema es del 23 de mayo. Han pasado 12 días, y el “problema” continúa, aunque es posible que Facebook no considere esto un problema, sino una herramienta para desarrolladores; lo cierto es que no he visto demasiado ruido al respecto. Esa es, por cierto, una de las razones de la publicación de esta entrada.

2. Aunque el defacement de una página web corporativa, o el robo de determinada información estratégica de una organización son problemas muy graves, pienso que en general, el robo de ciertos datos de carácter personal está en otro nivel. La razón es muy sencilla. Mientras que en los dos primeros casos las consecuencias pueden estar más o menos acotadas en el tiempo y tener un relativo impacto sobre la organización, los datos de carácter personal se caracterizan por su inherente vinculación a la persona, durante toda su vida. Si en una foto salgo yo, no hay manera de limitar temporalmente ese hecho; una página web o un plan estratégico se puede cambiar, pero la foto permanecerá mientras no se destruyan todas sus copias. Ese es uno de los aspectos que a) los usuarios de las redes sociales no acaban de entender cuando cuelgan fotos suyas en Internet, y b) las grandes redes sociales no quieren asumir como responsabilidad.

3. Me preocupa la siguiente afirmación, al respecto de aplicaciones y privacidad:

En concreto, la palabra “deben”. Esto parece implicar que la gestión de la privacidad se deja en manos de los desarrolladores, y que no es impuesta por los sistemas de control de privacidad de Facebook; me resulta bastante extraño, pero eso es lo que dice el párrafo anterior. Además, el hecho de que sea posible denunciar este tipo de violaciones de la política de privacidad por parte de las aplicaciones es la confirmación de que efectivamente, las aplicaciones pueden no respetar las políticas de privacidad de Facebook; porqué esto se permite sobrepasa mi comprensión.

4. Facebook, así como Tuenti, son redes sociales donde abunda los usuarios adolescentes y universitarios. Aunque muchos de ellos están acostumbrados de sobra a Internet, Facebook tiene una variedad enorme, en cantidad y complejidad, de configuraciones de privacidad. Me da la impresión de que las implicaciones de cada configuración no se están trasladando correctamente a los usuarios, intencionadamente o no; es imperativo simplificar, unificar, y explicar qué significa cada opción y quién exactamente va a tener acceso a tus fotos, notas, comentarios, etc. Y esto es generalizable a prácticamente todas las redes sociales.

5. Les decía antes que no sabía si esto era una vulnerabilidad o una feature, pero el caso es que durante la escritura de los puntos anteriores, estoy convencido de que es una vulnerabilidad, por una sencilla razón: he buscado aleatoriamente a alguien en Facebook, y desde la red social únicamente podía ver su foto de perfil; nada más, mientras no me hiciese “amigo” suyo. Entonces he ido a la web de los desarrolladores, y con el procedimiento anterior, he podido acceder a los álbumes (siete) de esa persona, que sin duda ignora que sus fotos son accesibles libremente desde Internet, sin más que aplicar un sencillo procedimiento fácilmente automatizable. No sé si es un problema de comunicación a los usuarios o de implementación, pero sin duda es un problema grave de privacidad, en el momento permite a usuarios externos acceder a información que no es (o no debería ser) pública. Quizá no funcione para todos los usuarios y para todas las configuraciones, pero si eso no es una vulnerabilidad, no sé lo que es.

6. Aunque las políticas de privacidad hablan de aplicaciones, en ningún momento se habla de desarrolladores. Es lógico que las aplicaciones, dentro del marco de privacidad de Facebook, requieran acceder a datos de los usuarios, y en efecto, las aplicaciones solicitan autorización para ello. Pero no es lógico que las propias aplicaciones puedan “saltarse” la configuración de privacidad del usuario y desde luego, eso no incluye a los desarrolladores de aplicaciones. Este punto no sólo no está claro, sino que no se indica en ningún lugar.

7. Por último, como podrán imaginar y seguramente hace un rato que estaban pensando, esto supone una violación del artículo 94.4 del Reglamento de Desarrollo de la LOPD:

Ya que como hemos podido comprobar, el nivel de seguridad al realizar pruebas con datos reales no se conserva.

—

Poco más. Mi opinión es que este es sólo el principio; como dijo �?caro Moyano en la XI Noche de las Telecomunicaciones Valencianas, la revolución está por llegar. Tuenti tuvo un episodio similar hace unos meses, en el que —a pesar de lo que decían—, era posible enlazar a imágenes internas desde fuera de la red social. Este problema se ha solucionado (según tengo entendido), pero aparecerán más, no tengan ninguna duda; los usuarios no sólo van adquiriendo destreza informática (sin ir más lejos, aunque en principio Tuenti no deja descargarse fotos, ya hay una extensión de Firefox para “saltarse” la “protección”, por llamarla algo, además de un montón de métodos alternativos), sino que demandan más funcionalidades que introducirán a su vez más vulnerabilidades.

Lo que no hay que olvidar en ningún momento es que estamos hablando de redes sociales con millones de usuarios que comparten datos reales de sus vidas: comentarios, opiniones, hábitos, fotos, etc. Gestionar todos esos datos exige una responsabilidad especial, admitir que son algo más que un montón de información que exprimir publicitariamente, y ser consciente de su importancia.

Personalmente, para serles sincero, no estoy nada seguro de que esa conciencia exista.

Les recuerdo que hoy finaliza el plazo para el envío de preguntas al consultorio LOPD, que serán contestadas el próximo viernes 12. Nos vemos el lunes.