Hoy, con motivo de la celebración del día de Internet, promovido desde 2005 por la Asociación de usuarios en Internet a las que se han ido sumando diferentes asociaciones españolas, me gustaría reflexionar sobre las virtudes y facilidades que los Servicios de la Sociedad de la Información han traído a las vidas de muchos ciudadanos y empresas internautas y qué mejor forma de hacerlo en los tiempos que corren que reflejarlo en la búsqueda de empleo.

En España el 48% de la población utiliza Internet para buscar empleo, según la reciente encuesta realizada por la consultora Ipsos siendo la referida tasa superior a la de otros países, como Italia (36%), Alemania (30%) o Francia( 25%). Para más datos, según el último informe publicado por el Instituto Nacional de Estadística (INE) en fecha 5 de octubre de 2011, el índice de personas en situación de desempleo que usaron Internet en sus hogares asciende al 86,6 % y aunque desconocemos los usos de este porcentaje, qué duda cabe que Internet es una herramienta útil para la búsqueda de empleo.

Siendo múltiples y variadas las plataformas, portales de búsqueda de empleo, mi atención la voy a centrar en las redes sociales puesto que dentro de la disparidad que encontramos en las redes sociales (generalistas y profesionales) y sus funcionalidades, están destacando como una opción más para la oferta de empleo.

Las redes sociales como plataformas de comunicación en línea permiten crear redes de usuarios, posibilitando que los candidatos puedan relacionarse con otros candidatos e incluso interactuar con empresas que demanden empleo diseñando y ajustando su perfil profesional a las necesidades del mercado laboral. Actualmente, no solo se utilizan redes sociales profesionales, como podría ser LinkedIn, sino que todas valen para dicho fin. Prueba de ello, el estudio realizado por el equipo de jobandtalent que establece que los contactos de Facebook son más utiles en la búsqueda de empleo que los de LinkedIn.

Desde mi punto de vista, el uso adecuado de las redes sociales son una oportunidad para estar conectado y tener acceso a múltiples grupos, perfiles de usuarios, Curriculums y ofertas de empleo asumiendo en todo caso la pérdida de intimidad que ello supone y la ausencia de confidencialidad para el caso de que lo que se pretenda sea simplemente una mejora de empleo.

Por otro lado, no debemos olvidar la otra cara de estar presente en las redes sociales para ofrecerte como candidato; me estoy refiriendo desde el punto de vista del posible futuro empleador. Por razones obvias, desde hace tiempo las redes sociales se están convirtiendo en un instrumento frecuente en los procesos de selección de personal habida cuenta la información personal que se puede extraer del candidato, resultando en ocasiones tras la consulta del perfil del usuario la causa por la que se desechan las candidaturas.

La duda que planteo es ¿hasta qué punto sería legal esta práctica de acuerdo con el principio de calidad de los datos establecido en el artículo 4 de la LOPD? El problema en todo caso es probar que se ha producido este tipo de tratamientos de datos “casi invisibles” por parte del seleccionador o headhunter, teniendo en cuenta que suelen suceder previamente a la entrevista de trabajo.

Como concepto derivado de un BIS o Sistema Inmune Biológico, los trabajos han sido orientados al seguimiento básicamente de tres paradigmas:

• La Selección Negativa
• Clonación Selectiva
• La teoría de la señal de riesgo

1. La selección negativa

El paradigma de la selección negativa biológica es simulado usando un aprendizaje sobre el comportamiento normal de una red o un sistema y tratándolo como propio, de modo que todo elemento ajeno al sistema es considerado como una intrusión. Concepto ya conocido como la detección de intrusiones basada en anomalías. Pues bien, dentro de este paradigma encontramos diferentes aproximaciones según autores.

• Zhang et al (2005). La propuesta de Zang pasa por la utilización de agentes independientes que trabajan de forma coordinada para detectar intrusiones, implementada en Java con AgentMOM y JSDT para las comunicaciones.
• Okamoto and Ishida (2007). Okamoto implementa tres clases de agentes, los C, B y M. El primero gestiona los dos siguientes, marcando a los de clase B las rutas entre los hosts que debe seguir. Los de clase B recolectan información de los equipos monitorizando comportamientos sospechosos. Por último los de clase M son los encargados de reaccionar ante intrusiones detectadas. Este modelo permite repartir la carga computacional de detección entre diversos equipos.
• Zhongmin et al (2007). Introducen el modelo de la diversidad, donde cada host de la red genera diversos agentes y estos son compartidos con los sistemas vecinos. Su sistema basado en anomalías genera agentes específicos para cada usuario del equipo, donde cada agente es capaz de reconocer a su usuario, pasando posteriormente a autoclonarse y cambiando de perfil de usuario. Esta copia podrá sobrevivir solo si obtiene una puntuación adecuada en el periodo de entrenamiento del agente.
• Luther et al (2007). Luther incorpora el concepto de mutación de agentes, donde todos los elementos de detección del sistema desplegados de forma distribuida son tratados como un único IDS. Para la comunicación entre sus elementos utiliza un modelo P2P ayudando a mitigar los falsos positivos generados por la detección basada en anomalías. Por último destacar que el sistema está desarrollado en Java.
• Bye et al (2008). Como el anterior, Bye utiliza la detección colaborativa, basando su lógica en la recolección estadística de información de los sistemas. Para el intercambio de información entre sus agentes hace uso de una red P2P, donde cada elemento tiene asociada una métrica computada de la posibilidad de infección, la cual es compartida dentro del entorno P2P. A su vez comparten información sobre ataques o incluso falsos positivos. Para testar el sistema utilizan NeSSI, un simulador de tráfico de red. El único inconveniente es que no se realiza ninguna acción tras la detección de una intrusión.
• Boudec and Sarajanovic (2004). Estos autores describen un sistema basado en conjuntos de agentes Workers donde cada grupo es especialista en un tipo de detección de intrusión. Todos ellos son gestionados por un agente Master. Cada elemento de esta red intercambia información periódicamente.
• Byrski and Carvalho (2008). Este modelo se centra en la definición de un comportamiento lícito del activo generado por la monitorización de los procesos y las llamadas a sistema de los equipos. Cuando un proceso se inicia se comparan todas las llamadas a sistema realizadas con las identificadas en el proceso de aprendizaje, de modo que si difieren es posible que se esté produciendo una intrusión. Al margen de esto utilizan el concepto de agentes móviles, capaces de viajar de sistema en sistema examinando las llamadas generadas.

2. Clonación Selectiva

El paradigma de la clonación selectiva simula la replicación de anticuerpos para combatir agentes patógenos. En un ABAIS esto es implementado creando agentes específicos para detectar y defender al sistema ante determinadas intrusiones, de esta manera un elemento especialista de la red es capaz de responder ante un determinado ataque clonándose él mismo y desplazándose hasta el lugar de la intrusión. Dentro de este paradigma encontramos diferentes aproximaciones según autores:

• Machado et al (2005). La detección de la intrusión es realizada mediante el análisis de los logs del sistema utilizando la herramienta Logcheck y apoyándose en Syslog-ng. Cuando una intrusión es detectada el sistema genera un número de agentes móviles que se desplazan al origen del incidente para erradicarlo. Para llevar a cabo esta respuesta se definen 2 tipos de actuación: las pasivas (remitir un email al administrador) y las activas (desplazamiento y eliminación).
• Yang et al (2009). Estos autores introducen el concepto de vacuna, donde dentro de un sistema IDS distribuido, los segmentos de protección que no han recibido la intrusión son “vacunados”, para prevenir ataques exitosos.

3. La teoría de la señal de riesgo

El paradigma de la señal de riesgo o peligro en un sistema inmune hace referencia a la muerte de las células de un cuerpo, bien sea por necrosis o por muerte natural (vejez). En un ABAIS esto se consigue coordinando una serie de agentes detectores situados en puntos distantes de la red capaz de alertar a los miembros del entorno de protección de que se está produciendo cierta amenaza.

• Greensmith et al (2008). Greensmith define dos tipos de nodos capaces de detectar y decidir, en primer lugar, si una alerta debe ser notificada a la red y en segundo lugar de actualizar al resto de elementos con la información obtenida. Estos datos capturados por estos agentes son recopilados en un log centralizado, donde son utilizados para aprender y desarrollar nuevas estrategias de defensa.

Cisco Modular Policy Framework (MPF) es un conjunto de funcionalidades y reglas que nos proporciona Cisco para configurar de forma flexible sus firewalls, pudiendo realizar un filtrado más específico de las conexiones que atraviesan nuestra red.

Habitualmente, cuando configuramos un firewall, solemos centrarnos principalmente en las capas de red y transporte, filtrando únicamente por direcciones IP, puertos, o incluso flags, no obstante, no debemos olvidarnos de que esto no siempre es suficiente, por lo que debemos poder controlar también las capas superiores, pudiendo filtrar por parámetros concretos a nivel de aplicación.

Como ya vimos hace tiempo, Cisco ASA nos da la posibilidad de poder normalizar conexiones TCP, no obstante, es realmente MPF quien hace posible esta normalización, junto con otras funcionalidades avanzadas como comprobaciones a nivel de checksum de paquete, tcp windowing, filtrado de flags, gestión de ancho de banda, o incluso, la posibilidad de hacer un bypass del stateful inspection del sistema. No obstante, para este post usaremos el framework para llevar a cabo una inspeccionar tráfico a nivel de aplicación.

Recordando el post de Roberto sobre la identificación de accesos de logmein, podemos configurar nuestro ASA para filtrar determinados patrones de tráfico a nivel de aplicación; en nuestro caso y para mantener un ejemplo similar, bloquearemos las peticiones DNS a dominios de logmein.com, aunque también se podría inspeccionar el tráfico HTTP para evitar ciertas conexiones.

Para llevar a cabo la inspección DNS, realizaríamos los siguientes pasos (existen configuraciones alternativas):

1. Configuramos una expresión regular que nos permita detectar los patrones de tráfico interesante:

ciscoasa# regex DNSFilter ".\.logmein\.com"

Podemos comprobar si una url hace match con la expresión regular mediante el comando test:

ciscoasa# test regex www.logmein.com .\.logmein\.com
    INFO: Regular expression match succeeded.

2. Configuramos un class-map para identificar el tráfico que queremos inspeccionar:

ciscoasa(config)# class-map type regex match-any DNSFilterList
ciscoasa(config-cmap)# description Dominios Bloqueados
ciscoasa(config-cmap)# match regex DNSFilter

Creando un class-map, podríamos añadir más entradas a la comprobación de expresiones regulares.

3. Creamos un policy-map donde asociamos el anterior class-map para especificar las acciones a llevar a cabo al detectar la expresión regular sospechosa. En este caso, cortamos la conexión y registramos el acceso:

ciscoasa(config)# policy-map type inspect dns DNSInspection
ciscoasa(config-pmap)# parameters
ciscoasa(config-pmap-p)# match domain-name regex class DNSFilterList
ciscoasa(config-pmap-c)# drop log

4. Asociamos al policy-map existente la nueva inspección de tráfico DNS creada en el punto anterior.

ciscoasa(config)# policy-map global_policy
ciscoasa(config-pmap)# class inspection_default
ciscoasa(config-pmap-c)# inspect dns DNSInspection

Puesto que hemos modificado el policy-map creado por defecto, no sería necesario modificar o crear un nuevo service-policy.

Llegados a este momento, si intentamos realizar una consulta DNS (que no esté almacenada en nuestra caché local o en la caché de nuestro servidor DNS) por ejemplo a www.logmein.com, sería filtrada por el firewall, generando el siguiente log:

%ASA-4-410003: DNS Classification: Dropped DNS request (id 24326) from
     inside:10.10.10.20/64355 to outside:8.8.8.8/53; matched Class 23: match
     domain-name regex class DNSFilterList

Donde claramente podremos identificar la IP que lanza la consulta DNS, y también se reflejaría en el debug si esta activado en el firewall:

DNS: === request: Param flags 0x7, match flags 0x10
DNS: Match flags 0x100 rr 1, return 0
DNS: Match dn, list 0xd5711358 entries 1
DNS: Match dn regex, return 1
DNS: Match type 0x1, class 0x1, return 1
DNS: Action 20: matching class 24, DNS Classification: Dropped
DNS: Ques 0: DN: 

Como hemos podido ver, esta funcionalidad nos permite crear nuevos patrones de filtrado acorde a las necesidades de nuestra organización; Veremos otras interesantes utilidades de MPF en el próximo post.

El congreso comienza con una breve introducción de Javier Borredá, que da paso a las intervenciones de Ana Borredá (Directora de Seguritecnia) y Mercedes Oriol (Directora de Red Seguridad). Entre ambas hacen un repaso a las ediciones del congreso, destacando el papel de Mapfre y Prisa apoyando a éste desde sus inicios y, desde hace dos años, como padrinos de honor; también revisan el avance de la convergencia en este tiempo, en especial desde el punto de vista normativo (ENS, LPIC…) y en el ámbito nacional, así como la evolución en estos cuatro años de la figura del CSO.

Tras la charla de presentación entra en juego MAPFRE hablando del análisis y gestión integral de riesgos, con una charla dividida en tres partes diferenciadas. En la primera, teórica y en la que se llega a echar en falta algo práctico (algo que, dicho sea de paso, se corrige perfectamente más tarde), se habla, entre otras cosas, del mapa de riesgos globales del World Economic Forum en el que, en 2012, aparece ya el riesgo asociado a la ciberseguridad, además de las interrelaciones entre los diferentes tipos de riesgos; a continuación José María Cortés, Subdirector de Análisis de Riesgos de la DISMA muestra sólo dos transparencias, de las más claras y directas que he visto en mi vida, en las que sin darle vueltas al asunto nos dispara los problemas reales del análisis de riesgos tradicional; ahí van:

• Caos conceptual. Conceptos que no están muy bien definidos (riesgo tecnológico, vulnerabilidad…).
• Modelos de análisis poco ajustados a la práctica y a la realidad.
• Métodos muy específicos o demasiado generalistas que no descienden al detalle.
• Problemas con los pretendidos análisis matemáticos.
• Expresión tradicional del riesgo como fórmula matemática (esperanza matemática de que suceda un hecho indeseable).
• Cuantificación de la probabilidad y del impacto.
• Identificación y valoración de activos.
• BBDD estadísticas sobre incidentes.
• Correlaciones entre riesgos.
• Gran volumen de información.
• Ausencia de cultura de gestión integral de riesgos.

No puedo estar más de acuerdo; la problemática asociada al análisis de riesgos y sus supermetodologías ya la comentamos hace tiempo en este mismo blog y vemos que no somos los únicos que la sufren (¿cómo era aquello de “Mal de muchos…“? ;). Finalmente, para acabar la presentación y para que no sea todo poner problemas encima de la mesa, MAPFRE nos cuenta cómo tratan de solventar estos problemas comentados previamente.

Después de MAPFRE José García (Vodafone España) nos cuenta la evolución del Departamento de Seguridad de la compañía con un ejemplo muy gráfico sobre evolución de TI vs. evolución de seguridad. Destacar, cambios de nomenclatura aparte, que en 2012 aparece la figura del CTSO para “colgarse de la chepa” de TI y poder gestionar en primera persona los riesgos asociados a la tecnología.

A continuación llega la charla de EULEN hablando de convergencia; Ricardo Cañizares nos cuenta que en 2008 empezaron con el tema (vaya, esto me suena ;) y a partir de ahí diseñaron servicios que contemplaban la convergencia, ya que siempre la han considerado el futuro y explicando a continuación, desde un punto de vista comercial, los servicios que en este sentido ofrecen.

Tras el café, Miguel Rego habla de convergencia de nuevo desde un punto de vista muy práctico, citando por ejemplo los dispositivos de seguridad física ya conectados por IP, como cámaras, con los riesgos que esto implica: nuevos vectores de ataque, nuevos riesgos ya no sobre la seguridad de la información en exclusiva, sino también sobre la seguridad física, etc. Tras la introducción de Miguel, se muestra una demostración práctica de ataque a un sistema de videograbación, con búsqueda en shodan y tokens predecibles incluidos en la que se hace un acceso “en vivo” a una cámara de seguridad de un determinado modelo. Llama la atención que esta parte de la demostración, el control de una cámara de seguridad vía IP, a buena parte del público le parece algo muy novedoso y aparentemente no eran conscientes de que cosas así se pueden hacer. No comments.

La siguiente charla es de Manuel Rodríguez, Jefe de la Unidad de Gestión de Riesgos del Parlamento Europeo, hablando de seguridad en este Parlamento, primero poniendo cara (seguridad física) a cada una de las tres sedes que tienen que proteger y luego hablando de sus preocupaciones en materia de seguridad, que incluyen los ataques IT o el espionaje, así como de su organización interna y sus objetivos de seguridad. Un buen orador que nos presenta una ponencia curiosa e interesante, no puedo decir más.

A continuación se pasa a hablar sobre internacionalización de la seguridad en un formato de mesa redonda con MAPFRE, Acciona, Ferrovial… donde una de las palabras más repetida es “inteligencia”, tratando cuatro asuntos principales:

• Problemas en el extranjero, en delegaciones, filiales, operaciones…
• Proveedores que estén capacitados para prestar seguridad global (física, electrónica, tecnológica, normativa y operativa). ¿Son españoles?
• Papel de la inteligencia en la presencia exterior.
• Marco internacional de capacitación para seguridad.

Como siempre, Guillermo Llorente hablando claro en la mesa y metiendo el dedo en la llaga: no hay que saber de todo, sino tener el teléfono del que sabe, y de proveedores globales nada, porque no existen.

Tras la comida, una nueva mesa redonda, esta vez sobre protección de infraestructuras críticas desde un punto de vista “convergente”, en la que participan FFCCSE, operadores de tales infraestructuras y proveedores de servicios, con varias preguntas en la agenda:

• Situación estimada de seguridad en el ciberespacio.
• Condición de España tanto en ataques como en defensa.
• Qué falta en España para poder abordar la seguridad desde un punto de vista global.
• Qué organismo debe liderar la futura Estrategia Española de Ciberseguridad.
• Cómo conjugar todos los actores implicados en la ciberdefensa española.

Me interesa mucho más la opinión de organismos públicos, como el CNPIC, que la de entes privados o semipúblicos (éstos velaran lógicamente por sus intereses particulares, mientras que los primeros confío en que velen por el interés general). Óscar de la Cruz (GDT-GC) define muy bien un problema: la legislación del siglo pasado (o del anterior) que afecta a la seguridad de hoy en día; no podemos combatir un ciberataque con un marco legal que habla de serenos, por poner un ejemplo. De esta mesa, comentarios interesantes aparte, me llama mucho la atención que nadie responde a las dos últimas cuestiones de la agenda, salvo a la de liderar la estrategia nacional de ciberseguridad y muy de pasada (y a raíz de una pregunta de Mercedes). ¿Casualidad?

Finalmente la jornada acaba con una última mesa redonda en la que se debate la seguridad global en la futura LSP, con las siguientes cuestiones sobre la mesa:

• Qué perfil debe tener el responsable de seguridad de los activos de una organización.
• Debería incorporarse una visión global de la seguridad en una nueva LSP?
• Formación y capacitación de un directivo de seguridad (vaya, esta me suena ;)
• Qué están haciendo las asociaciones profesionales al respecto de la seguridad integral.

Dos bloques de participantes (los de seguridad “lógica” y los de seguridad “física”) no enfrentados entre sí, pero con opiniones para todos los gustos. En definitiva, una jornada muy interesante en la que si algo queda claro es que en convergencia aún queda mucho trabajo por hacer y en muchos sentidos. Felicitar, como no podía ser de otra forma, a los compañeros de Borrmart por el éxito de la convocatoria, que si siempre es difícil, lo es más aún en estos tiempos.

Como siempre, pasen un buen fin de semana.

Como ya he comentado el informe es extenso y ofrece gran cantidad de ejemplos que ilustran cada una de las recomendaciones para que se entienda cómo puede ayudar a mitigar. No pretendo en esta entrada hacer un resumen del informe sino destacar algunos aspectos que me han llamado la atención del mismo.

En primer lugar destacaría como bien comenta el informe la necesidad de medir la eficacia de la medidas que adoptamos para mitigar las botnets. Es decir, responder a preguntas como, ¿Haber puesto un DNS sinkhole ha tenido un efecto positivo para mitigar esta amenaza? ¿La campaña de concienciación ha funcionado?, etcétera. Entonces, como no podía ser de otra manera para responder a esta pregunta deberemos definir una serie de indicadores relacionados con esta amenaza que nos determinen de manera clara y objetiva si las medidas están teniendo efecto. Ejemplo de estos indicadores podrían ser:

I1. Número de zombies global
I2. Número de zombies por departamento
I3. Número de C&C activos
I4. Número de C&C por país
I5. Número de dominios maliciosos consultados
I6. Número de zombis por Botnet
I7. Número de C&C por Botnet
…

Gracias a estos indicadores y otros que podamos definir medimos nuestra eficacia.

Por otro lado del informe destacaría las siguientes dos tablas resumen:

En estas dos tablas podemos ver de manera resumida las medidas de detección y las contramedidas que detalla el informe, junto a diferentes elementos a tener en cuenta antes de abordar su implantación, como puede ser una estimación de los conocimientos técnicos para su puesta en marcha, el esfuerzo técnico, esfuerzo administrativo, etcétera. Aunque cada entorno es diferente y se tendrá que tener en cuenta a la hora de la implantación, no está de más ver esta tabla y tomarla como una referencia inicial, ya que nos ayudará a crear nuestro plan de acción para la lucha contra este tipo de amenazas.

Como siempre espero que os sea de utilidad y os recomiendo la lectura del informe ;)

Dicha vulnerabilidad puede ser explotada de un forma muy sencilla, añadiendo los caracteres ?-s al final de la URL, que es lo mismo que ejecutar php-cgi con la opción -s.

Otra forma de explotarla y que tiene una consecuencia peor, es poder ejecutar código de forma remota, lo que se haría a través del comando -d, insertándolo de la misma forma en la URL y pasándo por POST los comandos que queremos lanzar. De esta forma, también se han presentado ejemplos de como se podría ejecutar una shell reversa, donde recogeríamos los resultados de los comandos lanzados.

Si incluimos la siguiente cadena “?-T+100000” el atacante puede hacer efectivo un ataque DoS.

Podemos comprobar si nuestro sitio web es vulnerable a través de este script de nmap: http-vuln-cve2012-1823.nse o bien a través del módulo de metasploit php_cgi_arg_injection.rb.

Desde snort, también nos han sugerido varias reglas a través de las cuales podemos detectar si están intentando explotar la vulnerabilidad. Los SIDs correspondientes son el 22063, 22064 y 22097.

Una de las opciones para evitar que exploten la vulnerabilidad en nuestros servidores es añadir las siguientes reglas en el fichero .htaccess:

RewriteEngine on
RewriteCond %{QUERY_STRING} ^[^=]*$
RewriteCond %{QUERY_STRING} %2d|\- [NC]
RewriteRule .? – [F,L] 

Otra opción es mediante el uso de modsecurity en apache, a través de esta regla:

SecRule QUERY_STRING "^-[sdcr]"
"phase:1,t:none,t:urlDecodeUni,t:removeWhitespace,block,log,msg:'Potential
PHP-CGI Exploit Attempt'"

Aunque la mejor opción es siempre actualizar a la última versión de php-cgi en la que se han corregido los fallos de seguridad. Hay que tener en cuenta que existen BOTs que intentan explotar la vulnerabilidad de forma masiva, por lo que debemos tener especial cuidado de no ser víctima de ninguna de ellas.

Referencias:

En este sentido, aunque la cesión o comunicación de datos entre el Responsable del Tratamiento y una tercera parte requiere el consentimiento del afectado, la LOPD tiene varios supuestos que eximen de este consentimiento. En nuestro caso y como veremos después, es aplicable el artículo 11.2 a) de la LOPD o el 10.2 a) del RDLOPD, algo más detallado y que recogemos a continuación:

Así pues, lo que debemos ver ahora es si efectivamente existe una ley que ampara dicha cesión. Tal y como se recoge en la carta que recoge el requerimiento de información, la solicitud de información de la Agencia Tributaria está amparado en el artículo 93 de la Ley General Tributaria, concretamente los puntos 1, 2 y 5, y el artículo 94.5. Ambos se reproducen a continuación:

Por tanto, ahora cabe entrar a determinar si el nombre y apellidos, NIF y datos de las propiedades puestas a la venta o el alquiler son datos de trascendencia tributaria. Aunque la finalidad de la cesión de datos no la conocemos, es razonable asumir que entre otras posibles, esta petición tiene como objetivo cruzar los datos de propietarios con la información que éstos han proporcionado a la Agencia Tributaria, datos del catastro, para la detección de posibles fraudes. Siendo así, tanto el nombre, apellidos y NIF como la información de los inmuebles serían datos de trascendencia tributaria ya que son vitales para el procedimiento.

Existen de hecho un par de resoluciones de la Agencia de Protección de Datos muy similares a este caso, y en ambos casos se determina que la cesión está amparada por el artículo 11.2 a) de la LOPD:

• Informe 0316/2009
• Informe 0190/2010

En definitiva, cabe concluir que la cesión de esos datos está amparada en el artículo citado.

La prueba en la que participan alumnos de Ingeniería Informática de esta Universidad, está enmarcada dentro de las actividades propuestas para del Año Turing. Las bases de la competición las podéis encontrar en el siguiente enlace; los alumnos deberán resolver doce criptogramas dentro de cuatro niveles de dificultad diferentes, donde todos ellos han sido cifrados mediante el algoritmo Vigenèrè. El cifrado de Vigenère es un cifrado de sustitución simple polialfabético, basado en el clásico Cesar y muy amigo de Friedrich Kasiski ;)

Para dar como válida cada solución, se deberá entregar tanto el texto en claro como la cadena de cifrado. Para aquellos crackeadores de códigos que aporten la solución en el menor tiempo posible, S2 Grupo como patrocinador, aportará los siguientes premios:

1º: iPad 2, WIFI 16GB
2º: iPod nano 8GB
3º: iPod shuffle

Los sufridos regalos serán entregados a finales de este mismo mes en las instalaciones de la ETSINF.

El problema en las aplicaciones de Android reside en que si intentas hacer un man-in-the-midle y el certificado no está firmado por una CA de confianza, no aparece ningún mensaje para que decidas confiar o no en ese certificado, sino que directamente no deja establecer la comunicación.

Con este problema, empecé a buscar alguna solución y encontré la pareja mitmproxy y proxydroid. La primera de ellas como bien indica su nombre, se trata de un proxy con capacidades de realizar ataques mitm. Es muy similar a Burp o ZAP, pero para línea de comandos. Está escrita en python y permite modificar tráfico automáticamente mediante scripts. La segunda es una aplicación que instalaremos en nuestro móvil y que añadirá reglas en el firewall para redirigir todo el tráfico HTTP/S hacia mitmproxy.

Para montar nuestro laboratorio, primero deberemos instalar en nuestra máquina mitmproxy. En Debian/Ubuntu se puede hacer con:

# apt-get install python-pip
# pip install mitmproxy

Una vez instalado, iniciamos mitmproxy para que nos genere la CA. Los certificados los podemos encontrar en /home/usuario/.mitmproxy/. En nuestro caso, nos interesa el archivo mitmproxy-ca-cert.cer que tendremos que copiar a nuestro dispositivo Android en la carpeta /sdcard/Downloads/. Una vez copiado el certificado en la memoria del teléfono, ya lo tenemos casi hecho. Para instalarlo en Android 4 (En otras versiones no debe diferir mucho) hay que ir a Ajustes -> Seguridad -> Instalar desde almac dispositivo. Nos aparecerá un popup con los datos y a partir de este momento podremos ver el certificado en el apartado Credenciales de confianza

Hecho esto, cuando mitmproxy genere los certificados para cada sitio, la CA que acabamos de instalar le garantizará al móvil que son confiables y podremos descifrar el tráfico.

Ahora solo nos queda redirigir todo el tráfico hacia nuestra máquina para analizar ese tráfico cómodamente. Para ello, utilizaremos proxydroid (necesitamos ser root), y lo configuraremos mínimamente con la dirección IP donde está corriendo el mitmproxy, el puerto y el tipo de proxy:

Ahora solo nos queda arrancar mitmproxy y empezar a jugar:

Para no arruinar la diversión, os remito a la web de mitmproxy.org para que veáis como se pueden modificar las peticiones a mano o con scripts.

Como saben, esta norma es una consecuencia de las diferentes iniciativas que promulgaron los Estados Unidos tras los atentados del 11-S en Nueva York en materia de protección y de seguridad en el transporte de mercancías. Esos atentados marcaron un punto de inflexión, supusieron un antes y un después en el nivel de seguridad o mejor, en la sensación de seguridad que los estadounidenses tenían. Y supuso un cambio en sus planteamientos. Supuso por ejemplo la creación de la iniciativa MEGAPORTS, que trasladaba a los puertos más importantes del mundo desde los que llegaban mercancías a puertos estadounidenses (en el caso de España, los puertos de Valencia, Algeciras y Barcelona) la obligación de realizar costosas inversiones para detectar la posible existencia de sustancias radioactivas en los contenedores con destino USA.

Y no sólo en el ámbito del transporte marítimo de mercancías. Recordarán la polémica surgida alrededor de la obligación impuesta a las compañías aéreas de entregar al gobierno estadounidense la lista de pasajeros de todos los vuelos internacionales con destino a los Estados Unidos antes del despegue de los aparatos. Y seguro que también se acordarán de las polémicas surgidas por la instalación de escáneres corporales en los aeropuertos estadounidenses a partir de los atentados de 2001, y en otros aeropuertos internacionales posteriormente.

Todo este tipo de medidas físicas de seguridad tienen un coste económico muy elevado, por la necesidad de diseñar, fabricar e instalar dispositivos muy costosos en múltiples infraestructuras. Pero es que además se dieron cuenta de que el terrorismo internacional estaba cambiando sus estrategias. Los ataques “clásicos” tenían una probabilidad de éxito muy baja, requerían maquinar acciones cada vez más rocambolescas y complicadas, acciones que en muchos casos requerían además que los terroristas no sólo participaran en las mismas, sino que se “implicaran” personalmente (ya saben, la diferencia entre implicarse y participar: el caso de la tortilla de jamón). El ciberterrorismo entró en escena de una manera paulatina, rudimentaria si quieren al principio, pero venía para quedarse. La relativa sencillez de llevar a cabo ataques más o menos coordinados contra instalaciones e infraestructuras críticas de países objetivo, con niveles de riesgo muy bajo para los ciberterroristas, sin que precisen de grandes ni costosos medios, y con probabilidades de éxito considerables por el nivel de vulnerabilidad de muchas de estas instalaciones, como podían ser por ejemplo las centrales nucleares. Toni Villalón nos puso en situación en un post hace no mucho. Y no voy a ponerme ahora a hablarles de las múltiples iniciativas legales y de todo tipo dirigidas a mejorar la seguridad física, lógica y organizativa de las infraestructuras críticas nacionales, europeas y mundiales.

Si el terrorismo y la delincuencia organizada cambiaban de hábitos, las armas para combatirlos también tenían que evolucionar y readaptarse. Las medidas de seguridad fueron extendiéndose de lo físico a lo virtual. De hecho los sistemas de inteligencia y contrainteligencia de los países más avanzados comenzaron a ver las ventajas de este tipo de actuaciones, bordeando ellos mismos la ilegalidad (¿se acuerdan del gusano Stuxnet en 2010?).

El control pasó también a las telecomunicaciones, con directivas y leyes que exigían a los operadores el mantenimiento de registros y logs de las comunicaciones mantenidas, y permitían la posibilidad de que las autoridades y/o las fuerzas de orden público accediesen a dichos registros con la pertinente orden judicial para la investigación de delitos de diferente índole, como podía ser el terrorismo, el fraude, el crimen organizado, etc.

Todo esto no era nada nuevo. Desde hace muchos años los diferentes gobiernos norteamericanos habían auspiciado iniciativas –algunas conocidas, otras que quizás nunca conoceremos- relacionadas con el control de las comunicaciones de los ciudadanos. Para muestra la serie de posts de nuestro excompañero y colaborador Rafa Páez sobre sistemas de monitorización social, control de redes sociales etc. (véase Sistemas de monitorización social parte I, II y III, y ¿Cuánto sabe Internet de nosotros?, entre otras).

El caso del terrorista yihadista de Tolouse finalmente abatido el pasado mes de Marzo, y que fue identificado entre otras cosas tras “cruzar siete millones de datos telefónicos, 700 conexiones de Internet y cientos de respuestas al anuncio de venta de una moto” es un ejemplo más de que el uso de internet y de las telecomunicaciones está siendo registrado y monitorizado.

José Luis Villalón también nos habló del asunto en un post sobre la privacidad de las redes de este mismo blog. Poco a poco este tipo de medidas han ido ampliándose e irremediablemente han ido acercándose a la tenue línea que separa lo lógico de lo excesivo. Siempre se ha dicho que la gente que nos dedicamos a esto de la seguridad —ya sea desde planteamientos físicos, lógicos, organizativos y/o legales— tenemos un componente paranoico importante, y vemos riesgos y puntos débiles donde otros no reparan. Vemos la necesidad de implantar controles, sensores, mecanismos de prevención que permitan detectar a tiempo los riesgos y actuar en consecuencia. Pero a la vez somos personas, somos ciudadanos, y al menos yo no puedo evitar plantearme ciertas preguntas: ¿Dónde situamos esa línea que no se debería sobrepasar? Porque esa frontera no está en el mismo sitio si estamos hablando de un entorno de trabajo o corporativo o de un entorno privado… ¿A partir de qué momento decimos que estamos allanando el terreno privado de las personas?

En el mundo físico las “fronteras” se ven, son palpables. La puerta de una casa, de un domicilio particular, es el límite que no se debe sobrepasar, salvo que se tengan sospechas fundadas y se cuente con una orden judicial que permita allanarla. Pero, ¿y en el mundo “no real” de internet? ¿Y en las redes sociales?

Porque es tan fácil caer en la tentación… Piensen sin ir más lejos en Whatsapp, la aplicación de mensajería instantánea más utilizada en el mundo. Sí esa que todos (o muchos) utilizamos, más o menos. Piensen en lo que se dice a través de Whatsapp, en el ámbito profesional, en el personal, en las fotos que se mandan y piensen que todo ese tráfico de todo el mundo que la utiliza viaja por internet, sin cifrar, y que cada vez que mandan un mensaje a una persona que está en su misma ciudad, ese mensaje antes ha pasado por un servidor que está en los Estados Unidos. Qué tentador, ¿no?

Insisto. Como profesional de la seguridad entiendo, justifico e incluso defiendo la adopción de medidas de control destinadas a prevenir posibles incidentes de seguridad. Como ciudadano me preocupa el cariz que están tomando ciertas iniciativas, como la que se publicaba este fin de semana pasado en El País: un proyecto de ley que está en el Congreso norteamericano y que posibilitaría el intercambio, entre empresas privadas que operan en la Red y el Gobierno y otros organismos federales, de información de los usuarios que utilizan sus servicios. Con la excusa de la defensa nacional ante posibles ataques informáticos a través de Internet y la defensa de la propiedad intelectual estadounidense ante ataques de otros países, tener acceso a datos personales de los usuarios de la red. Parece que la Casa Blanca no está por la labor de aprobarla, pero parece también que la norma contaría con el apoyo inicial de Facebook y de Microsoft.

De acuerdo. Es un proyecto de ley. Primero tendrá que vencer la controversia que se está suscitando, y después aprobarse. Incluso la noticia podría ser malintencionada o falsa. Pero ya saben, cuando el río suena…

Es evidente que la estrategia correcta en materia de seguridad es la prevención y la detección precoz. En según qué casos tener que adoptar planteamientos correctivos puede estar implicando hablar de pérdidas económicas importantes o incluso, de vidas humanas. Pero llevar esta estrategia al extremo puede implicar la pérdida injustificada de derechos fundamentales, como puede ser el derecho a la intimidad. Todo un dilema. ¿Dónde opinan ustedes que están los límites?