Esas debieron ser las palabras que pronunció el cónsul de Panamá en Canarias al ver la publicación de la noticia, después de haberse corrido una buena juerga en los pasados carnavales vestido de esta guisa. Parece que posiblemente le costará el puesto, cosa que por otra parte quizás podría discutirse, pero no es ese el tema.

Fíjense en el pie de la foto: Facebook.

Recordarán el caso del supuesto etarra publicando su CV y su domicilio en un portal de empleo, un congresista norteamericano publicando fotos marcando musculitos en una web de contactos, el director de cine Nacho Vigalondo “metiéndose en un jardín” al twittear un comentario políticamente incorrecto sobre el holocausto (parece que con alguna copa de más según confesión propia, pero de hecho le ha costado perder la campaña que estaba desarrollando para El País), …

¿La gente no se da cuenta de que Internet es un sitio PÚ-BLI-CO? En algunos de los casos citados evidentemente sí, aunque quizás no sopesen de manera adecuada las consecuencias. ¿Aún piensan que lo que publican en la web sólo lo ven ellos o, como mucho, sus amigos? ¿La gente no sabe que sus opiniones en Twitter no las ven sólo las personas a las que ellos siguen sino cualquier hijo de vecino que quiera hacerlo?

Todavía es relativamente frecuente encontrar perfiles “abiertos en canal” en Facebook, o con una configuración de privacidad deficiente. Personas que publican sus fotos bailando en la discoteca en un estado digamos “desmelenado” cuando están de baja por un esguince cervical… Hace no más de un año pude ver las fotos de la última borrachera publicada en Facebook por una persona a la que acababa de hacer una entrevista de trabajo. E incluso he visto situaciones tan delicadas, relacionando lo personal y lo profesional, que no puedo relatar ni siquiera sin mencionar a la persona que lo sufrió.

En el transcurso del año 2010 han visto la luz nuevas técnicas de ataque a aplicaciones Web. Entre todas ellas vamos a hablar del API javascript “Evercookie” creado por Samy Kamkar. Lo que Samy intenta demostrar con la creación de este API es la posibilidad de hacer que las cookies sean persistentes pese a que un usuario intente borrarlas. Para hacerlo se utilizan diferentes mecanismos que permiten almacenar la información en el lado del cliente, como HTML5 local storage, HTTP Etags, LSO Flash cookies, etcétera; todas los mecanismos y sus respectivos enlaces los podéis encontrar en la página de Evercookie.

Una vez nos descargamos el API, este pone a nuestra disposición un ejemplo de página que lo utiliza. En esta entrada vamos a comprobar cómo evercookie hace persistente las cookies usando la página de ejemplo.

Como este viernes no les hemos deleitado con ninguna entrada para que ocupen el tiempo libre que tendrán durante el fin de semana, aquí les dejamos unas perlas de conocimiento para que reflexionen:

Pasen un buen fin de semana.

(Continuamos hoy con la entrevista realizada a Lourdes Herrero, cuya primera parte publicamos ayer)

7. Sobre la concienciación y el aprendizaje en el tema de la seguridad, además de los mencionados cursos formativos ¿CSIRT-cv desarrolla alguna otra labor en éste ámbito?

Si, desde octubre de 2010 CSIRT-cv se une a la red social Twitter (http://twitter.com/csirtcv) en la que diariamente informamos sobre algunas de las noticias y avisos más relevantes en cuanto a seguridad. También estamos en Facebook a través de http://www.facebook.com/csirtcv donde además de lanzar mensajes informativos o alertas apostamos por realizar campañas de concienciación en las que durante un periodo corto de tiempo, diariamente aconsejamos sobre algún tema en concreto. Así, nuestra primera campaña de concienciación “Seguridad en Dispositivos móviles” versó sobre recomendaciones y buenas prácticas a seguir en el uso de dispositivos móviles. En Navidad lanzamos otra que trataba de alertar sobre los peligros más comunes en la red en esas fechas. Y la última que se ha lanzado recomienda diversas herramientas básicas para prevenir ataques o infecciones, reparar daños o simplemente facilitar una navegación más segura en Internet.

Con ello, pretendemos llegar a un público más amplio y que no tiene porqué contar con demasiados conocimientos técnicos. No queremos llegar sólo a profesionales del mundo de la seguridad de la información sino a cualquier internauta. Nuestro objetivo es ayudar a que la Seguridad de la Información forme parte de la cultura del ciudadano, de la misma forma que el concepto de Seguridad Vial o Seguridad Física.

Para hoy miércoles tenemos la primera parte de la entrevista a Lourdes Herrero, Directora del Centro de Seguridad TIC de la Comunitat Valenciana, CSIRT-cv, que se ha prestado amablemente a responder algunas preguntas relacionadas con el centro.

Lourdes Herrero es Ingeniero Informático, por la Universidad Politécnica de Valencia. Tras sus inicios laborales en varias empresas del sector TIC, el grueso de su actividad profesional se ha desarrollado en la Generalitat, donde ha dirigido diversos proyectos de implantación de las Tecnologías de la información en los Ayuntamientos de la Comunidad Valenciana. Actualmente es Directora del CSIRT-cv, desde su inauguración en Junio de 2007.

Este centro depende de la Consellería de Justicia y Administraciones Públicas y fue el primer centro de respuesta a incidentes de seguridad de ámbito autonómico en España.

1. Lourdes, para ponernos en antecedentes, ¿podrías explicarnos brevemente qué es un CSIRT?

Un CSIRT, (o un CERT) es el acrónimo de Equipo de Respuesta ante Incidentes de Seguridad Informática (Computer Security Incident Response Team).

El objetivo que persigue todo Centro de Respuesta es la prevención, detección, asesoramiento, seguimiento y coordinación necesarios para hacer frente a incidentes de seguridad informática que ocurran en su ámbito, y que pueden ser muy diversos. Desde la detección de virus, gusanos, troyanos, phishing, spam… pasando por la aparición de intrusiones y actos malintencionados, hasta la detección de actividades realizadas por colectivos organizados de ciberdelincuentes.

Llevaba alguna semana queriendo escribir un post de la serie GOTO dedicado a los periodistas, tal y como adelanté hace cosa de un mes en la entrada relativa a los ciberataques sufridos por la GVA. He intentado resistirme un poco -más por falta de tiempo que otra cosa-, pero leyendo las últimas noticias sobre el peligro nuclear en Japón que todos los medios generalistas están lanzando no he podido aguantarme… Y es que tenemos periodistas -no todos, obviamente- que no distinguen asterisco de asteroide, pero no contentos con ello transmiten al público general su vasto conocimiento sobre cualquier materia y se quedan tan panchos, satisfechos del trabajo realizado.

Con el tema de los ciberataques contra GVA ya dimos unas pinceladas del saber hacer de estos periodistas; ahora con el debate que se está abriendo sobre la seguridad nuclear siguen cubriéndose de gloria, y encima lo mezclan con la entrada en Cofrentes de unos activistas de Greenpeace hace unas semanas, poniendo este acto como ejemplo de “inseguridad” en las centrales nucleares españolas. Por favor, no mezclemos churras con merinas. Que las centrales nucleares -y otras infraestructuras críticas- de nuestro país sean o no vulnerables no depende de que unos ecologistas capaces de evitar -con presunta violencia- a los vigilantes de seguridad (o a la Guardia Civil si se diera el caso) se cuelen tras la verja de una central. ¿Qué pretenden los periodistas, que disparen con armas de fuego a estos activistas para demostrar lo seguros y fuertes que somos? Venga, hombre… la que se habría montado, y con razón.

Vicent Andreu y Paúl Santapau, del Gabinete de Planificación y Prospectiva Tecnológica de la Universitat Jaume I de Castellón (UJI), inauguran la semana con una entrada sobre el proyecto STORK, una iniciativa participada por un grupo de Universidades españolas y coordinada por la UJI, en lo que puede ser el embrión de una federación de identidades electrónicas paneuropea.

¿Qué es STORK?

STORK es el acrónimo de Secure idenTity acrOss boRders linKed, un proyecto cofinanciado por la Comisión Europea con la finalidad de permitir el uso de las credenciales expedidas por los diferentes estado miembros en toda Europa. Por ejemplo, un caso común es el de un estudiante Erasmus que, desde su país de origen, quiere prematricularse on-line en otra universidad de distinto país. Si nosotros somos responsables de los sistemas en la universidad de destino, ¿cómo podemos validar la identidad del estudiante sin que sea necesario que se persone en nuestra universidad? Parece que la única posibilidad es confiar en un tercero que sí la conozca, por ejemplo, la universidad origen o una entidad gubernamental. Pero, en este caso, ¿con qué nivel de confianza podemos aceptar los datos que nos envíen? Es más, ¿qué datos y en qué formato nos van a enviar? Y, si queremos aceptar estudiantes de diez países, ¿debemos lidiar con los formatos y atributos de todos ellos? ¿Cómo solicitamos permiso al usuario para recabar sus datos y le informamos de cuales son? Este es el problema que pretende resolver STORK.

Mucho tiempo tienen algunos para que se les ocurran las maldades a las que estamos asistiendo en la Red. Los vectores de ataque cambian a una velocidad de vértigo. Incluso hemos visto, en un ataque en marcha, cambiar el vector de ataque buscando resultados positivos ante el fallo de la estrategia inicial.

En algunas ocasiones, como es el caso de los ataques vividos por VISA, MasterCard, la SGAE o por la Generalitat Valenciana hace poco, lanzados desde Anonymous (21/03/11: al parecer, excepto en el caso de GVA), el problema es la cantidad, no tanto la calidad. En otros casos, como se puede deducir del título del post, el problema es la calidad y no la cantidad. ¿Qué creen ustedes que es más peligroso? ¿Qué preferimos, cantidad o calidad?

La verdad es que no sé muy bien que responder ante una disyuntiva de este calibre. Creo que, si pudiese elegir, me quedaría con un ataque masivo donde tuviese el enemigo de frente y pudiese preparar mis defensas de cara a hacerle frente. Eso es lo que paso, con bastante éxito en este caso para los defensores, en los ataques lanzados contra GVA.

Vectores de ataque diferentes que requieren estrategias diferentes y al igual que los atacantes aplican mucha imaginación, y buenas dosis de innovación, los que nos dedicamos a defender a nuestros clientes de estos grupos organizados tenemos que aplicar también buenas dosis de imaginación y métodos innovadores.

El 17 de marzo de 2000 (hoy hace 11 años) un incendio causado por un rayo en una planta de fabricación de semiconductores de Royal Philips Electronics en Albuquerque, Nuevo México, provocó, según The Wall Street Journal, “una crisis corporativa que cambió el equilibrio de poder entre dos de los mayores fabricantes de productos electrónicos de Europa” (The Wall Street Journal, 29 de enero de 2001), Nokia y Ericsson. Aunque el incendio sólo duró 10 minutos, la contaminación que produjo en la “sala limpia” (donde se fabrican los semiconductores) motivó el cierre de la planta durante semanas. En aquella época, tanto Nokia como Ericsson utilizaban microchips producidos en esa planta. Sin embargo, mientras Nokia fue capaz de trasladar su suministro a otras plantas de Phillips, así como a otros suministradores americanos y japoneses, Ericsson quedó atrapada por su dependencia exclusiva de la planta de Albuquerque. Las pérdidas que sufrieron en ventas y la caída en su cuota de mercado en los meses siguientes motivaron que Ericsson se retirara del mercado de los teléfonos móviles en 2001.

Lo que hemos visto en Japón la semana pasada y cuyas consecuencias devastadoras aún estamos empezando a percibir, supera al pequeño incidente de hace ahora 11 años tanto como un tsunami a una onda en un estanque. Ya se están empezando a notar las subidas en el coste de los microchips (esos que tenemos en nuestros móviles, cámaras y en todas partes) y se va anotar aún más en la maltrecha industria de la automoción, con gran número de fabricantes (al parecer todos excepto dos, Hyundai y BMW) dependiendo en alguna forma de los suministros japoneses. En este río revuelto, ni siquiera parece que vaya a haber la “ganancia de pescadores” que experimentó Nokia en 2000, a costa de su competidora Ericsson: incluso aquellos fabricantes que teóricamente se beneficiarían de la desgracia de sus competidores (véase General Motors) verán también su cadena de suministro afectada por esta crisis de alcance global.

Ya hemos hablado anteriormente de Barnyard2, una herramienta para procesar ficheros Unified2 y que permite múltiples configuraciones de salida; la más utilizada, la escritura en Base de datos.

En este pequeño artículo hablaremos de otro uso que puede sernos de utilidad: la salida de ficheros en formato “pcap”. Este tipo de fichero puede ser procesado por otras aplicaciones, como el analizador de protocolos Wireshark —una potente herramienta gráfica que facilitan la vida de administradores de redes y técnicos de seguridad y cada vez ofrece una mayor cantidad de funciones—. En esta entrada vamos a ver un ejemplo de cómo podemos aprovechar esta opción para la conversión de un formato de archivo generado por Snort -del que también se ha hablado aquí- a otro que es capaz de trabajar con Wireshark para analizar esos paquetes “maliciosos”.