Seguridad de la Información y Fórmula 1: fiabilidad y resultados

La entrada de hoy martes es una colaboración de Javier Cao, un “clásico” del sector que no requiere demasiadas presentaciones. Para aquellos que no lo conozcan, Javier Cao es Ingeniero en Informática por la Universidad de Murcia, certificado CISA y posee los certificados de los cursos IRCA ISO 27001 e IRCA ISO 20000.

Su carrera profesional se ha desarrollado en torno a la gestión de la seguridad de la información desde sus comienzos, participando en diferentes proyectos relacionados en la norma ISO 27002, la continuidad de negocio y la protección de datos, tanto en el ámbito corporativo como en el privado. Actualmente es Director Técnico del Área de Seguridad de la Información de la empresa Firma, Proyectos y Formación dirigiendo diversos proyectos en el ámbito de la Administración Pública relacionados con el análisis de riesgos, la seguridad de la información y la continuidad de negocio. Asimismo, participa activamente en la difusión de la seguridad desde el ámbito de sus blogs personales: “Apuntes de seguridad de la información” y “Sistemas de Gestión Seguridad de la Información”.

Esperamos que les guste la entrada.

En el momento actual de inicio y expansión de sistemas de gestión de la seguridad de la información (en adelante SGSI), la principal preocupación es naturalmente lograr la construcción y establecer bien los procesos que permitan lograr construir el ciclo de mejora continua y certificar el sistema.

Sin embargo, conforme vayan pasando los años estos sistemas deben ir madurando para lograr verdaderamente satisfacer los objetivos establecidos por la Dirección. Uno de los grandes beneficios de implantar un sistema de gestión basado en ISO 27001 debe ser pasar de una “seguridad basada en sensaciones” a una “seguridad basada en datos de comportamiento” que permita mostrar y sobre todo, demostrar que las cosas se están controlando y se mantienen dentro de unos rangos de valores aceptables.

En este sentido, los criterios de gestión establecidos por la Dirección y que debieran estar referenciados en la Política de Seguridad de la Entidad, son el marco de trabajo para todas las personas involucradas de forma activa o pasiva, dentro de las actividades de operación, mantenimiento y supervisión del SGSI. Estas directrices generales son tanto el rumbo como las metas que el sistema de gestión debe lograr. Todo el esfuerzo de construcción y mantenimiento de un SGSI no se justifica si con ello no se logran determinados resultados; un SGSI tiene costes y por tanto, debe ser amortizado y rentabilizado lo máximo posible. Esto, dentro del ámbito de la seguridad, supone que las cosas deben funcionar con normalidad y los imprevistos, incidentes o accidentes deberán ser gestionados de forma correcta para minimizar los daños que pudieran producirse. Pero para lograr esto, es necesario justificar y demostrar con datos todo el esfuerzo que es necesario realizar para que las medidas de seguridad funcionen cuando hagan falta.

Partiendo de la célebre frase de Lord Kelvin (1824-1907), “Lo que no se define no se puede medir. Lo que no se mide, no se puede mejorar. Lo que no se mejora, se degrada siempre“, un SGSI debe tener establecidos criterios de medición de la eficacia y la eficiencia como así establece la propia normativa en las cláusulas 4.2.2. Apartado e) y 4.2.3. Apartado b).

Para ilustrar esta faceta de la seguridad y como viene siendo tradicional dentro del blog “Security Art Work” voy a utilizar como símil de un buen modelo de seguridad la Fórmula 1 dado que creo se comparte un gran paralelismo en los enfoques de ambos mundos.

[Read more…]

La CMT facilita conocer la operadora a la que pertenece un teléfono móvil: ¿intromisión en la privacidad?

A principios de agosto se hizo público que la CMT (Comisión del Mercado de las Telecomunicaciones) disponía de un nuevo servicio por el que los usuarios pueden conocer el operador asociado a un número de teléfono móvil en el ámbito español.

En los principios de la telefonía móvil bastaba con identificar los primeros dígitos de un teléfono móvil para saber el operador al que estaba asociado un número. Si no recuerdo mal, los que empezaban por 654 eran de Amena (ahora Orange), y los que empezaban por 607 o 610 de la antigua Airtel (ahora Vodafone). Pero actualmente, con el auge de los OMV (Operadores Móviles Virtuales) se ha facilitado el proceso y se ha convertido en usual cambiar un número de móvil de una compañía a otra, para intentar ahorrar al máximo en la factura de nuestro móvil, lo que hace muy difícil seguir la pista de los operadores asociados a nuestros móviles.

A primera vista, este servicio puede tener sus ventajas, puesto que visto desde la óptica de un usuario de a pie nos permite conocer el operador móvil de nuestros contactos para ahorrar en nuestras facturas. Es de sobra sabido que las llamadas entre teléfonos de la misma compañía siempre es más barato, así que este podría ser un buen método para decidir a quién llamar primero. Sin embargo, me muestro reticente a considerar este un servicio cuyo uso se vaya a generalizar entre los usuarios, y también se producía en mi interior cierto aire de desconfianza, porque viéndolo desde la óptica de un operador móvil (o una persona que se quiera hacer pasar por él), este servicio puede permitir a ese operador o persona malintencionada conocer la compañía que me presta servicio y ejecutar, entre otros, acciones comerciales no deseadas contra mí.

Según parece, los datos que ofrece esta web son de carácter público y no se está incurriendo en ninguna ilegalidad al divulgarlos públicamente cuando van disociados de sus propietarios como es el caso. Pero a pesar de ello, la necesidad de identificarnos para poder comprar un número de teléfono o utilizar uno existente y la tan manida LOPD (Ley Orgánica de Protección de Datos), con la eterna disputa sobre si el teléfono móvil es un dato personal o no, me hacen ver con cierto recelo esta nueva plataforma y su utilidad de cara al ciudadano “de a pie”.

¿Qué opinan ustedes? ¿Creen que es una plataforma útil para el usuario, o por el contrario genera más problemas que ventajas?

El teléfono móvil SÍ es un dato personal:
http://www.eldia.es/blogs/el13devalentinsanz/?p=478
http://www.iurismatica.com/blog/el-numero-de-telefono-movil-es-un-dato-de-caracter-personal/
http://www.samuelparra.com/2009/01/29/consecuencias-de-no-considerar-el-numero-de-telefono-movil-como-dato-personal/

El teléfono móvil NO es un dato personal:
http://www.carlosucelay.com/index.php?option=com_content&view=article&id=19

Acceso al portal:

https://numeracionyoperadores.cnmc.es/portabilidad-movil/operador

Afinando nuestro IDS con Rule2alert

Los sistemas de detección de intrusos (IDS) son sistemas que requieren un ajuste adecuado para evitar falsos positivos, falsos negativos, alertas repetitivas que colapsan la consola de operación etc. Cuando se decide implantar un IDS, como parte del proceso de implantación, se requiere haber diseñado una batería de pruebas para comprobar que lo implantado reacciona adecuadamente y poder tener una cierta garantía (garantía total es imposible debido a la heterogeneidad del tráfico que circula por las redes) de poseer un ajuste fino y con buen rendimiento. En esta entrada vamos a hablar de la herramienta Rule2alert [1], que nos ayudará a crear una batería de pruebas propia, con el fin de realizar el mejor ajuste posible de nuestros IDS.

Rule2alert, como se puede leer en la página oficial del proyecto, [1] toma como entrada reglas de Snort y genera tráfico de red a partir de ellas, pudiéndolo volcar a un fichero con formato pcap. Rule2alert es una herramienta que se basa en otra herramienta llamada Scapy[2], en la cual destaca su potencia para la manipulación de paquetes de red.

Vista la descripción, vamos a hacer una pequeña prueba a ver que tal se comporta la herramienta. Cabe mencionar que hemos realizado las pruebas sobre un sistema GNU/Linux Debian Testing.

Lo primero, descargamos la aplicación de una manera rápida (no hemos encontrado un tar.gz/zip disponible a la fecha de escritura de esta entrada) mediante wget:

$ wget -r http://rule2alert.googlecode.com/svn/trunk/

Una vez descargada, dentro del directorio “rule2alert.googlecode.com/svn/trunk” dispondremos de la aplicación r2a.py. Para comprobar que tenemos todas las dependencias (comentar que con la versión 2.5.2 de Python no nos funcionaba correctamente, en cambio, con la versión 2.6 no hay problema) y las versiones adecuadas, ejecutamos:

$ python r2a.py -h

Options:
-h, –help show this help message and exit
-c SNORT_CONF Read in snort configuration file
-f RULE_FILE Read in snort rule file
-F Write failed streams to pcap
-w PCAP Name of pcap file
-v Verbose hex output of raw alert
-t Test rule against current snort configuration
-T Test rule against current Suricata configuration
-m HOMENET Set $HOME_NET IP Address
-e EXTNET Set $EXTERNAL_NET IP Address
-s MANUALSID Manual SID Selection
-n MANUALNUM Number of times to alert SID
-E EVASION Evasion Technique

Para hacer las pruebas construimos un fichero test.rule con la siguiente regla:

“alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:”ET TROJAN Win32.Dialer.buv Sending Information Home”; flow:established,to_server; uricontent:”/exit.php?if=”; nocase; content:”&cl=”; content:”&id=”; content:”&ov=”; content:”&site=”; content:”&tk=”; classtype:trojan-activity; reference:url; reference:url,www.emergingthreats.net/cgi-bin/cvsweb.cgi/sigs/VIRUS/TROJAN_Dialers; sid:2008430; rev:2;)”

$ python r2a.py -f test.rule -m 192.168.1.1 -e 1.1.1.1 -w test.pcap -v

Building Rule: 2008430

——– Hex Payload Start ———-
26 63 6c 3d 20 26 69 64
3d 20 26 6f 76 3d 20 26
73 69 74 65 3d 20 26 74
6b 3d
——— Hex Payload End ———–

Loaded 1 rules succesfully!
Writing packets to pcap…
Finished writing packets

En este instante, disponemos un fichero pcap de nombre test.pcap que, al abrirlo con Wireshark, podremos ver como ha generado el fichero:


Figura 1: test.pcap

Por lo que hemos podido comprobar, con Rule2alert generamos tráfico que va a encajar en nuestro IDS y debe generar una alerta, por lo que podemos realizar pruebas sobre nuestra configuración. Para probar este tráfico sobre el IDS, la manera más sencilla y rápida sería como nos indican en el propio Wiki de la herramienta:

$ snort -c /etc/snort/snort.conf -q -A console -k none -r test.pcap

A continuación, planteamos dos posibles ejemplos de pruebas (de los trillones de posibilidades) a realizar con la herramienta:

  • Una primera prueba sería inyectar “n” alertas iguales sobre nuestro IDS, de manera que probemos los umbrales de nuestras reglas (threshold, etc.). Si se da el caso de que disponemos de un correlador que recoge nuestras alertas del IDS, con esta prueba podemos comprobar que las reglas de correlación están haciendo su trabajo; resolviendo incógnitas como “¿agregará bien las alertas?”, “¿dispara un evento de criticidad superior?”, “¿me envía el correo y además un SMS?, etc.
  • Como bien sabéis, existen ocasiones en las que es necesario establecer filtros para determinado tipo de tráfico de red, debido a falsos positivos donde el tráfico es totalmente legítimo. En este caso puede ser interesante, para comprobar que no nos hemos pasado filtrando, lanzar una prueba con un paquete que sabemos que debe saltar alerta y otra donde no tendría que saltar. Siempre es mejor prevenir que curar :).

Queda claro que cualquier aspecto de la configuración de Snort es posible contrastarlo con Rule2alert, de manera que podamos afinar un poco más nuestra configuración. Esperamos que les resulte de utilidad la herramienta :).

[1] http://code.google.com/p/rule2alert/
[2] http://www.secdev.org/projects/scapy/

Let’s Rock!

Hace relativamente poco, buscando algún entretenimiento que me ayudara a salir de la rutina y estando fuertemente influenciado por mi pareja, decidí apuntarme a una actividad que ha resultado ser de lo más divertida: bailar Rock. ¡No me refiero a salir de marcha por locales! Estoy hablando de asistir a clases de baile. Acotando un poco más os diré que bailamos música swing de entre los años 1920 y 1950. Existen distintos estilos de baile relacionados con la música swing: Boogie Woogie, Lindy Hop, Rock´n´Roll, Balboa,… Las clases a las que asisto se centran principalmente en el estilo Lindy Hop.

Para situaros en escena y sin querer entrar en mucho detalle os diré que el Lindy Hop es un estilo de baile popularizado en Nueva York por bailarines afro-americanos en una sala de baile llamada Savoy Ballroom. El baile tenía como base el Charlestón pero incorporaba elementos de otros estilos como el “Texas Tommy“, el “Black Bottom” y el “Cakewalk“. El Lindy Hop nació cuando estos bailarines empezaron a incorporar posiciones abiertas intercalándolas con las tradicionales posiciones cerradas. En la práctica, se trata de un baile rápido, enérgico y, desde mi punto de vista, bastante divertido. El baile puede enriquecerse con una gran variedad de acrobacias que serán más o menos espectaculares en función de la experiencia y de la forma física de los bailarines.

En lo referente a las lecciones de baile puedo decir que las primeras han sido más bien “introductorias”, lo cual era previsible pues la mayoría de asistentes desconocíamos por completo el estilo de baile. No obstante, he de decir que también acuden algunas parejas experimentadas que ensayan coreografías relativamente complejas.

[Read more…]

Analizando nuestra red II

Como vimos en el anterior post, la manera habitual analizar el tráfico de nuestra red pasa por configurar la interfaz de uno de nuestros switches en modo SPAN (o R-SPAN) y reenviar el tráfico para su posterior análisis mediante un analizador de red o un IDS.

Aunque esta solución suele ser la habitual, y suficiente en la mayoría de casos, presenta una serie de problemas, como pueden ser la limitación del número de interfaces (o VLANs) que podemos configurar en modo SPAN, y la carga de CPU asociada a la captura y envío del tráfico, incluyendo la carga generada al propio analizador de red, puesto que recibe todo el tráfico que atraviesa la interfaz, sea interesante o no para nuestra captura.

[Read more…]

Congreso ISACA Valencia 2010 (II)

Como ayer apuntaba José Luis, estuvimos presentes en el congreso de ISACA Valencia 2010, realizado los días 19 y 20 de octubre en la Universidad Politécnica de Valencia. La sesión de ayer miércoles, dedicada a la e-Administración, comenzó con un par de ponencias dedicadas la primera de ellas al estado general de la administración electrónica en España, a cargo de Lorenzo Cotino (Universidad de Valencia), y la segunda a la interoperabilidad, a cargo esta de Roberto Santos, de Telefónica -o Movistar- (videoconferencia desde León con algún que otro problemilla técnico que finalmente pudo subsanarse).

Tras un café, continuó la jornada con una excelente ponencia de Manuel Caño (LBIGroup) en la que se desgranó de una forma muy clara la necesidad de la contratación electrónica para todos (AAPP, empresas…), los problemas a los que se enfrenta en la actualidad y las líneas de resolución que se están adoptando a nivel europeo -que pasan todas por la estandarización-. Tras Manuel, se formó una mesa redonda en la que participaron José Benedito (Diputación de Valencia), Mar Ibáñez (ACCV, en representación de la Generalitat Valenciana) y Ramón Ferri (Ayuntamiento de Valencia), y en la que se plantearon trabajos, problemas y reflexiones en torno a la e-Administración desde el punto de vista de la propia administración pública. Tengo que decir una vez más que lo que yo entendía por “mesa redonda” sigue sin coincidir con lo que entiende el resto del mundo, porque las mesas redondas que llevo viendo desde hace unos años se limitan simplemente a presentaciones más cortas que el resto de las expuestas en el congreso; pero salvado este detalle, decir que me gustaron especialmente las reflexiones personales de José Benedito a la hora de plantearse qué requiere un ciudadano de la administración (hablando de trámites administrativos, no asistenciales -sanidad, educación…-) y dejando en el aire si realmente hace falta todo lo que tratamos de hacer. A fin de cuentas, el 90% de los ciudadanos tenemos unas comunicaciones con las AAPP muy simples: declaración de la renta con AEAT, algunos impuestos con el ayuntamiento y poco más… ¿no estaremos matando moscas a cañonazos con tanta e-administración? Ahí queda eso :)

Para finalizar, decir que este año, para mi sorpresa, la afluencia de público al congreso ha sido mínima, tanto el primer día como el segundo (el último día había un poquito más de gente, pero nada perceptible). Comparado con el éxito de asistencia del congreso 2009, este año nos hemos llevado un chafón; confiemos en que 2011 sea mejor…

P.D. Aquí teneis la presentación con la que S2 Grupo participó en el congreso. Disfrutadla :)

Cuando un cerdo no es suficiente, monta una granja

No, no estamos hablando de dejar esta vida ajetreada de las ciudades e irnos al campo a vivir y alimentarnos de lo que cultivamos y criamos. Tampoco hablamos de “invertir” nuestro tiempo libre en juegos de una determinada red social para aprender las labores del campo. Este post viene a explicar el proceso que hemos seguido para optimizar el rendimiento de un sistema de detección de intrusos (IDS) en redes con una tasa de tráfico alta.

Hace tiempo se nos propuso preparar para un cliente un sistema de detección de intrusos de alto rendimiento, capaz de procesar una gran cantidad de tráfico totalmente heterogéneo. Así que preparamos una máquina con muy buenas prestaciones para asegurarnos que, por hardware, no iba a ser; a saber, un procesador de 6 cores con 4 GB de memoria RAM, tarjetas Gigabit Ethernet y un sistema NAS para albergar toda la información generada en una red que, suponíamos, iba a ser muy complicada de manejar por la cantidad, la variedad y la naturaleza de su tráfico.

Se optó por una de las soluciones más extendidas en los sistemas de detección de intrusos de código abierto: Snort.

[Read more…]

Congreso ISACA Valencia 2010

Durante el día de ayer y hoy, se celebra en la Universidad Politécnica de Valencia el congreso ISACA Valencia 2010 organizado por el capítulo de Valencia de ISACA, que lleva como título “Esquema Nacional de Seguridad e Interoperabilidad y e-Administración”. Durante la jornada de ayer se realizaron una serie de conferencias dentro del marco del Esquema Nacional de Interoperabilidad y Seguridad, en las que S2 Grupo participó como ponente, y de las cuales, procedemos a realizar un pequeño resumen introductorio a continuación.

Protección de Marca

Nuestro compañero Antonio Villalón (S2 Grupo) planteó diversas cuestiones relativas a la reputación, tanto a nivel personal como a nivel de empresa, reflexionando acerca de los problemas actuales, los mismos que hace años pero elevados a la enésima potencia, debido al acceso global a la información donde todo el mundo puede opinar (en ocasiones amparados por una sensación de anonimato en la red), y recalcando que mi reputación no es algo que dependa únicamente de mí. Esta situación ha generado nuevos patrones de ataque no sólo sintácticos (virus, DoS, troyanos, etc), sino también semánticos (daño por la interpretación de la información que hace el ser humano). Para acabar, Toni nos ha sugerido que busquemos nuestro nombre en Internet para ver qué información existe de nosotros.

[Read more…]

Los Pilares de la Seguridad

Hace ya unos años que se produjo el boom de ventas de novelas históricas y ambientadas en el medievo. Quizás el máximo exponente fueron los famosos “Pilares de la Tierra” de Ken Follet que, aunque se publicó en 1989, creo que no ha habido ninguna novela posterior de este género que la haya podido destronar. De hecho recientemente también ha servido para poner “de moda” las series históricas de TV, con la adaptación producida por Ridley Scott. En 2007 la novela de Follet tuvo su continuación con “Un mundo sin fin”, novela que continúa la trama con los descendientes de los protagonistas de los Pilares.

Y ustedes dirán: ¿y este hombre qué nos está contando? Que esto es un blog de seguridad…

Pues les voy a sorprender. Esto es como la teoría de los grados de separación, que dice que entre dos personas que no se conocen en el mundo hay una cadena de conocidos de no más de cinco personas, y por tanto seis saltos.

Voy a ello. Para escribir la segunda parte de los Pilares (por cierto, felicidades a las Pilares que lean este blog por su reciente santo), Ken Follet se inspiró en las obras de restauración de la Catedral de Santa María de Vitoria-Gasteiz, ciudad que me permito recomendarles, y que tuve el placer de disfrutar en mis primeros años en esto de la seguridad (allá por el año 2000), colaborando en un proyecto para la Diputación Foral de Álava. De hecho, la ciudad, en la que se hizo la presentación mundial del libro, ha honrado al escritor británico con una estatua de bronce en su honor.

[Read more…]

Google no es siempre evil (o la ignorancia del redactor)

Hace unos minutos leía en elEconomista.es la siguiente información relacionada con Google Street View y los datos captados por los coches (se han corregido los errores tipográficos, abundantes al parecer por las intempestivas horas). El primer párrafo es introductorio, lo interesante son los otros dos (la negrita es del original, la cursiva mía):

La Agencia ha verificado que Google ha grabado, entre otros, direcciones de correo electrónico —con nombre y apellidos—, mensajes privados asociados a dichas cuentas y servicios de mensajería, o códigos de usuario y contraseñas. Google no lo tiene fácil, porque tiene todas las pruebas en su contra.

El contrato firmado entre el buscador y Eurovendex, una filial de la empresa de trabajo temporal Adecco, para reclutar a los trabajadores que grabarían las calles, destapa la recogida y almacenamiento de información confidencial. En una de las cláusulas, y después de que las dos compañías reconozcan que van a grabar dicha información se establece, por ejemplo, que “Eurovendex se compromete a guardar la más estricta confidencialidad respecto de los datos personales que obtenga como consecuencia de la realización de los trabajos del presente contrato, así como de la veracidad de los mismos“.

[…]

Pero Eurovendex no es la única que firmó este tipo de cláusulas. Los propios conductores de los coches que llevaban las cámaras y que usaban las redes WiFi tenían exigencias parecidas en sus contratos personales. En uno de ellos, uno de los empleados deja firmado, por ejemplo, que “reconozco que Google ha recibido y recibirá en el futuro de terceras partes su información confidencial (…). Me comprometo a manejar esa información en la más estricta confidencialidad y no desvelarla a firma, persona o compañía alguna, ni utilizarla excepto en lo necesario para llevar a cabo mi trabajo para el cliente“. Los datos recogidos incluían información de identificación personal, con nombres, direcciones y teléfonos.

[Read more…]