(N.d.E. Para que no se aburran durante este largo fin de semana, aquí va una entrada de Roberto calentita calentita.)

Hace escasos días surgía la noticia de la posibilidad de saltar el código de bloqueo de los dispositivos iPhone con IOS 4.1 a través de las llamadas de emergencia, permitiendo realizar llamadas a cualquier número. El escándalo saltaba nuevamente, y los “antimaqueros” tenían una nueva excusa para demonizar al gigante de Jobs y los usuarios amantes de “la Manzana”, entre los que se encuentra un servidor, sonreíamos resignadamente ante las burlas de estos.

Pues bien, para quitar hierro al asunto y aunque como profesional de la seguridad me parece una gran pifia por parte de los desarrolladores de Apple, os voy a presentar una segunda manera de poder realizar llamadas a cualquier número con el bloqueo de código activado. Este método hace uso del control por voz de nuestros terminales, de esta manera y con el dispositivo bloqueado tan solo tenemos que dejar presionado el botón de Home durante un par de segundos y activar el reconocimiento de audio. Acto seguido tan solo tenemos que pronunciar el comando “llamar” y el número de teléfono que queramos, por ejemplo “llamar 555 34 43 34”.

Como aspectos negativos de esta funcionalidad nativa del terminal cabe destacar que gran parte de los usuarios no la utilizan o ni siquiera saben que existe, a ello hay que añadir su principal problema y es que viene activada por defecto cuando se adquiere el dispositivo. ¿Debería Apple desactivar esta funcionalidad, al menos por defecto, dejando la posibilidad de activarla al usuario? La respuesta a esto se la dejamos a los lectores.

Por último y como buena noticia comentar que es posible deshabilitar su uso cuando el terminal está bloqueado en Ajustes-> General -> Bloqueo con código -> Marcación por voz.

Después de una semana para dejar pensar a nuestros lectores, seguimos con el artículo sobre la implantación de un sistema IDS en un entorno con una tasa de tráfico muy elevada.

Nos habíamos quedado en un momento donde la tasa de tráfico era tan elevada que, aunque la tarjeta no estaba perdiendo tráfico, Snort no era capaz de procesar todos los paquetes. Teniendo en cuenta la carga de CPU en el sistema, y revisando la documentación de Snort donde se indica que esta aplicación no es multi-hilo, no quedaba otra opción que montar la granja; es decir, levantar varias instancias de Snort y repartir el tráfico para que cada una de ellas analizara una tasa menor. Suponíamos que íbamos a conseguir un buen resultado ya que sólo se estaba utilizando un único core al 100% mientras que el resto no se utilizaba.

Para conseguir esto se deben tener en cuenta varios aspectos para que no entren en conflicto diferentes instancias en un mismo sistema. En resumen, se deben crear filtros BPF para especificar el tráfico que procesará cada instancia, puede haber uno o varios archivos de configuración, debe especificarse un sufijo diferente para el pidfile de cada instancia, debe especificarse un identificador (id) en cada instancia a la hora de escribir en la base de datos y un directorio diferente para almacenar los logs.

Mientras Toni asistía a los talleres relacionados con la protección de las ICs, yo me encargué en esta primera jornada de asistir a los relacionados con el Esquema Nacional de Seguridad, ENS.

Déjenme hacer antes de continuar una sugerencia a INTECO de cara a próximas ediciones. Si los talleres que han suscitado más interés durante las tres jornadas han sido claramente los relacionados con el ENS, el ENI y las ICs, ¿por qué ha juntado los tres temas el primer día? Si hubiese dedicado un día a cada tema, complementándolos con el resto de talleres que se han desarrollado, además de permitir que los interesados pudiesen asistir a los tres temas, se habría garantizado un nivel de asistencia homogéneo durante los tres días (cosa que no ha ocurrido). Tómese como una crítica constructiva.

(N.d.E. Esta tarde tenemos una entrada de Andrés Núñez, que trata la seguridad desde un punto de vista inusual en este blog, pero estarán de acuerdo conmigo en que es igualmente importante que cualquier otra vertiente que puedan pensar. Al fin y al cabo, la (in)disponibilidad de los alimentos ha sido uno de los mayores problemas del ser humano desde sus inicios.)

En las últimas semanas a raíz de la noticia del posible dopaje del ciclista Alberto Contador, hemos podido ver en distintos medios de comunicación noticias y debates relacionados con la seguridad alimentaria, puesto que el citado ciclista achaca el positivo a haber ingerido un filete que contenía la sustancia prohibida clembuterol.

Esta noticia ha vuelto a poner en tela de juicio al sector alimentario hasta el punto de que como publicaba la agencia EFE el pasado 15 de Octubre:

Puesto que vuelve a ser tema de actualidad, repasemos brevemente por medio de este post qué es esto de la seguridad alimentaria y cuáles son las normativas y códigos de buenas prácticas que están utilizando las empresas del sector para gestionarla.

(Toni nos remite esta entrada desde el congreso ENISE, con el aliciente añadido de que la ha escrito con la Blackberry, lo que no deja de tener su mérito)

Como algunos ya sabíais y otros imaginábais, un año más estamos en el congreso ENISE, en León, organizado por INTECO. Este año nos hemos acercado Fernando y yo, para poder repartirnos por los talleres más interesantes de cada sesión, y a mí me ha tocado el correspondiente a la protección de infraestructuras críticas. Más allá del programa, ponentes, etc. que tenéis disponibles en la web del evento, comentamos en este post algunas opiniones y reflexiones acerca de lo que escuchamos en la jornada de ayer.

El encubrimiento de canales o Covert Channels es una técnica de evasión que permite a un atacante enviar información empleando para ello las cabeceras de los protocolos de comunicación. En esta entrada trataremos el encubrimiento de canales en el protocolo TCP/IP, y proporcionaremos una herramienta, CovertShell, diseñada para la prueba de concepto. Pueden localizar los fuentes al final de la entrada.

El protocolo TCP/IP presenta una serie de cabeceras que normalmente son inicializadas por el cliente para mantener o numerar una comunicación. La técnica covert channels aprovecha dichos campos para asignarle valores de tal forma que la máquina destino interprete dichos campos no como una forma de mantener una comunicación o aportar información sobre ésta, sino para obtener datos.

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.

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.

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.

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.