Un año más hemos acudido a las Jornadas SID (que ya van por su XI edición) del Ministerio de Defensa, y como el año pasado hemos estado sólo en la parte de acceso libre (jornadas 3 y 4); la bienvenida a esta parte pública de las jornadas corrió a cargo de D. Esteban Cueva Álvarez, Subdirector General TIC del Ministerio de Defensa, quien muy brevemente nos recordó a todos la importancia de la protección de la información no sólo en el ámbito de defensa, sino en general en cualquier entorno, haciendo especial hincapié en los relativos a infraestructuras críticas.

Tras las palabras de bienvenida, entró en escena un representante del CCN-CERT, quien presentó los servicios que el Centro ofrece a la Administración Pública en general y al Ministerio de Defensa en particular. De su charla, creo que fue particularmente interesante para todos la declaración de objetivos para este año 2012, en especial los relativos a correlación y generación de inteligencia de las alertas generadas por el servicio de sondas de Internet del CCN-CERT, así como la presentación de CARMEN para la aplicación de técnicas de minería de datos, aún en fase piloto pero con muy buena pinta… Además de previsiones, formación, objetivos para este año… resalta (en rojo :) dos ideas fundamentales para cerrar la charla: cooperación e intercambio de información. Nos suena, ¿no? :)

Tras el CCN-CERT, llega el turno de ISDEFE con unos interesantes comentarios sobre ciberguerra y la importancia general de la ciberdefensa, para luego focalizarse en la PIC y, en concreto, en la importancia de las infraestructuras críticas de información como base para el funcionamiento correcto de las IICC en general. Se hace especial hincapié en que todas las acciones de los países con estrategias de ciberseguridad publicadas (Alemania, Reino Unido, Francia…) van por el mismo camino, camino marcado por la Estrategia Europea de Seguridad en Internet y camino que previsiblemente también será el que siga España, donde nuestra Estrategia Española de Seguridad ya incluye el ciberespacio como un posible escenario de conflicto. Y tras ISDEFE es el turno de una mesa redonda sobre movilidad y seguridad, donde el moderador comenzó hablando de una tendencia que parece muy extendida (personalmente la desconocía): bring your own device, tanto para hardware como para software… Como hoy en día no diferenciamos en muchas ocasiones la vida personal de la profesional, los usuarios tienden a usar equipos o software personal con una finalidad profesional y viceversa, con los riesgos que eso implica… Todos los participantes parecen estar de acuerdo en la problemática de esta tendencia -obviamente-, y se focalizan en proporcionar recomendaciones para el uso de tecnologías móviles, tanto técnicas como organizativas: qué información almacenamos, qué uso y condiciones vamos a dar a la tecnología, necesidad de normativas y regulación (reglas del juego), etc., muchas de ellas en línea con el informe del CNCCS que se publicó el pasado año sobre malware en smartphones (por cierto, otro día hablamos del CNCCS…).

Ya por la tarde, asistimos a un taller de los compañeros del grupo de seguridad de everis sobre botnets (instalación, configuración y limpieza), que empieza con una curiosa presentación de malware en códigos QR. Aparte de datos generales y estadísticos sobre botnets, en el taller se muestran bastantes ejemplos prácticos, que en estos casos siempre son de agradecer, incluida la modificación de código de un troyano demo “en vivo” y el empotrado en un joiner, muy curioso (eso sí, mucho Visual Studio, Metasploit y a golpe de GUI… los tiempos del ensamblador, el trabajo manual y artesano y las consolas parece que se han perdido :). La gente de everis nos muestra desde la creación, ocultación, etc. hasta la distribución del troyano empotrado en diferentes tipos de archivo, así como la configuración de los diferentes elementos de la botnet. Un taller muy interesante y bien preparado (alguna sorpresa normal en el efecto demo, pero nada más) para cerrar la jornada, con cita final de “El arte de la guerra” incluida ;)

Al día siguiente, última jornada del congreso, Roberto Gil (MDE) resalta la importancia de la normativa en materia de seguridad y repasa la normativa de aplicación en el Ministerio: OM 76/2006, instrucción 41/2010, instrucciones 9/2011, 95/2011… Comenta además los próximos desarrollos normativos del Ministerio a segundo y tercer nivel (vamos, por debajo de la Orden Ministerial), destacando el procedimiento de notificación y respuesta ante incidentes -algo que como hemos dicho ya marcó el CNI como objetivo para 2012-… Parece que el tema de gestión de incidentes gana cada día más peso… Tras Roberto Gil, charla del Ministerio de Defensa acerca de las tarjetas de identificación TIDEFe para sustituir a todas las tarjetas del Ministerio y en especial a las TEMD (esta con más de 67.000 tarjetas emitidas en estos momentos), que presenta diferentes problemas (desde logísticos, y es que quedan pocas, hasta de seguridad -certificación EAL4+, etc.; esta charla se complementa con la exposición de detalles técnicos de la nueva tarjeta, por parte de ATOS .

Después de ver la nueva tarjeta del Ministerio, de nuevo ISDEFE entra en escena para contarnos temas relativos a los ejercicios de ciberdefensa; temas de la charla aparte (problemática, retos, etc.), lo que más me llama la atención que uno de los objetivos del ejercicio es simplemente que los diferentes POC se conozcan entre ellos y así potenciar la colaboración y la confianza personal, independientemente -o complementariamente- a formalismos, protocolos, etc. Me llama la atención y me parece correctísimo… :)

Nos tomamos un café y volvemos a la carga con tres charlas muy interesantes -al menos para mí-; la primera, de personal del Ministerio de Defensa, una demo práctica del COSDEF (el SOC de Defensa) relativa a seguridad en impresoras: descubrimiento, ataques mediante órdenes PJL, captura de documentos, modificación del firmware, spam… incluso DDoS. Una demo interesante y curiosa, la verdad: conocía algunos de los ataques y problemas que plantearon, pero desde luego de otros no tenía ni idea (empezando por la posibilidad de modificación del firmware en algunas multifunciones). Tras la demo, el Director de la Oficina Nacional de Seguridad nos habla de la seguridad de las personas y las Habilitaciones Personales de Seguridad (HPS): evolución y seguimiento de las HPS, validez, implicaciones… muy curiosas algunas pinceladas de signos de posibles riesgos o ataques de ingeniería social, y sobre todo una frase: “la investigación es un fotograma en el tiempo…pero su seguimiento es la película”. Charla muy interesante y que nos enseña algo más de ese oscuro mundo que son las HPS :). Acaban las charlas con una última ponencia relativa a la seguridad de la información en poder de las empresas, por parte de la DGAM, y una mesa redonda sobre los problemas de la movilidad donde, aparte de algún comentario interesante, escuchamos algunos típicos tópicos de los que tengo que escribir algún post cuando tenga tiempo :) Tras ello, clausura por parte del Secretario de Estado de Defensa y vino de honor :)

En resumen, unas jornadas interesantes -al menos la parte a la que hemos podido entrar, seguro que la otra también lo sería ;)- a las que esperamos volver el año próximo. Eso sí, esperamos dentro de doce meses no volver a oir las palabras encriptar ni encriptación (ni sus derivados), y sí cifrar y cifrado :)

Siguiendo con la serie de posts sobre monitorización de entornos no cooperativos, y recapitulando un poco, debemos tener -al menos parcialmente- claro qué queremos monitorizar y dónde y cómo hacerlo. Seguramente hemos diseñado y desplegado agentes, al menos los más sencillos, capaces de detectar la presencia de detonantes en algunos de los entornos no cooperativos que veíamos en el último post y, una vez detectado el detonante, hacer “algo”. Ahora viene el determinar qué es, o qué debería ser, ese “algo”.

Lo más inmediato que se nos puede ocurrir ante la activación de un detonante es, obviamente, enterarnos. Tan sencillo como eso. Así, cuando desplegamos el primer, el segundo o el tercer monitor de entornos no cooperativos (o de entornos cooperativos, da igual), seguramente lo primero que se nos ocurre es recibir las alertas de monitorización a través de correo electrónico. Simple y efectivo: cuando sucede algo que me interesa, me envío un mail; y como además hoy en día puedo acceder a mi correo electrónico desde casi cualquier dispositivo y en cualquier momento y lugar, paso a estar notificado con un esquema 24x7x365 con un esfuerzo mínimo. Vamos, una especie de Google Alerts de andar por casa :)

Este esquema tan sencillo funcionar funciona, pero a nadie se le escapa que presenta muchas limitaciones. Quizás la más importante sea la capacidad: cuando tengo un número reducido de monitores puedo plantearme gestionar así sus alertas, pero conforme este número se incrementa (y por tanto, por pura estadística, también lo hace el número de alertas) la gestión de esas alertas comienza a complicarse… Aparte de este problema, seguramente el más obvio, hay algunos más: trazabilidad, distribución y procesado de alertas entre personas de un equipo… En fin, lo mismito que en la monitorización IT (o no IT) a la que todos estamos habituados. Y como en esa monitorización “habitual”, el siguiente paso suele ser montar un sistema centralizado donde recibir y gestionar las alertas (en general, los eventos) de monitorización, una solución que a muchos les gusta denominar SIEM (Security Information and Event Management).

Personalmente el acrónimo SIEM no me gusta nada; ¿por qué seguimos empeñados en utilizar la coletilla de “information” a la hora de hablar de seguridad, cuando luego se nos llena la boca pregonando las ventajas de la convergencia? ¿Por qué no un entorno único para gestionar las alertas de “todas las seguridades” de forma centralizada? Es más… ¿por qué hablamos de sistemas de gestión de eventos de seguridad en lugar de sistemas de gestión de eventos sin más? Tender a un entorno común, a una consola única para toda la organización (seguridad, financiero, RRHH, administración…) donde se centralicen las alertas que cada área debe procesar es sin duda una medida que ahorra costes, permite mejorar la toma de decisiones, potencia la correlación entre alertas de diferentes áreas… vamos, todo -o casi todo, no quiero generalizar- beneficios para la organización en su conjunto… pero nosotros seguimos empeñados en que seguridad lógica vaya por un lado, seguridad física por otro, RRHH por el suyo… En fin, como diría Forges, “País…” :)

Pero dejando de lado estas divagaciones -material para otro post o para varios cafés-, y volviendo a lo que nos ocupa, montamos un sistema SIEM o como le queramos llamar. En plata, un entorno para la gestión de alertas de seguridad donde se reciban todos los eventos generados por los diferentes monitores, se les aplique información para mejorar su tratamiento y análisis (SLA, soluciones, notificaciones, informes…) y mediante una consola única el equipo técnico pueda procesar convenientemente las alertas. Soluciones de este tipo hay muchas, mejores y peores, caras y baratas, complejas o sencillas… No vamos a comentar ninguna de ellas en particular (y menos las de la competencia ;), así que el que esté interesado que investigue un rato, evalúe diferentes soluciones y elija la que mejor se adapte a sus necesidades… Seguramente lo mejor, si ya disponemos de un sistema centralizado para la gestión de eventos de seguridad donde “disparan” alertas nuestros elementos de monitorización de entornos cooperativos, sea integrar la monitorización de entornos no cooperativos en ese mismo sistema. A fin de cuentas, se trata de alertas tan “alertas” como las otras, ¿no? :)

Creo que es obvio que el despliegue de un sistema de este tipo, frente a la simple notificación por mail a una persona o grupo, nos proporciona muchas ventajas y corrige algunos de los problemas que el esquema más básico presenta. Pero hay un problema muy importante que esta solución, per se, no resuelve: el de la cantidad de alertas que podemos llegar a recibir de la monitorización de entornos no cooperativos. Si a la hora de monitorizar entornos cooperativos, donde podemos ajustar muy fino nuestros monitores, los sistemas que generan datos, la capacidad de discernir entre alertas más o menos críticas y todo eso que sabemos hacer tan bien, ya nos encontramos com problemas de falsos positivos, de alertas no significativas que hacen perder mucho tiempo al equipo que las debe procesar -y que encima ocultan las alertas más importantes-, de alertas independientes que al ser analizadas resultan estar relacionadas con la misma incidencia o el mismo problema, imaginemos en la monitorización de entornos no cooperativos, donde no solemos poder hilar tan fino y donde muchas veces es complicado (incluso para un humano) hasta distinguir entre información negativa e información positiva o establecer relaciones entre diferentes alertas, por poner sólo un par de ejemplos… Intentaremos abordar este problema en el próximo post de la serie :)

En el anterior post planteábamos la introducción a la monitorización de lo que denominábamos entornos no cooperativos. Lo cerrábamos con las preguntas que todos nos hacemos: ¿qué?, ¿cómo?, ¿cuándo? y ¿dónde? monitorizar; vamos a tratar de desarrollar las mismas en el post de hoy (tal y como decíamos, con otro orden…).

¿Qué monitorizar?
Al elemento a monitorizar lo podemos llamar detonante. Habitualmente será una cadena de texto significativa para nosotros (una marca, un nombre, una dirección de correo, una IP…) que, si aparece en el entorno no cooperativo, puede implicar acciones posteriores por nuestra parte. Si rizamos el rizo, conscientes de que la búsqueda de una cadena es demasiado simple y el número de falsos positivos puede ser relevante, podemos lastrar el detonante con información de contexto: no es lo mismo encontrar la cadena “www.securityartwork.es” en un foro sobre seguridad que en pastebin, por poner un ejemplo. Y por poner más, no es lo mismo encontrar esa cadena en una página junto a la palabra “seguridad” que encontrarla junto a insultos en otra página web; así, puedo buscar no sólo un detonante concreto, sino información de contexto que afine los resultados que el monitor va a obtener. Evidentemente la monitorización y la correlación semánticas serían el ideal para focalizar esfuerzos y eliminar falsos positivos, pero esto, como tantas otras cosas, es fácil de decir pero difícil de hacer (no siempre disponemos de un OSEMINTI ;), aunque sin duda este es el camino: el gran volumen de información que podemos obtener de entornos no cooperativos hace necesarios por supuesto la correlación y, puestos a pedir, el análisis semántico, no sólo el sintáctico… vamos, casi lo mismo que a la hora de hablar de entornos cooperativos, ¿verdad?

¿Dónde monitorizar?
¿Qué entornos no cooperativos nos puede interesar monitorizar? Hay muchísimas fuentes públicas (o semipúblicas) de las que debemos plantearnos adquirir información que puede ser significativa para nosotros; en mi opinión, algunas de ellas son las siguientes -sin ningún orden particular-:

• Twitter. A través de este medio se organizan a diario ataques masivos distribuidos de todo tipo, en especial DDoS pero también acciones que van mucho más allá de la disponibilidad lógica de servicios: desde manifestaciones, llamamientos a boicots, actividades políticas… hasta difusión masiva de datos confidenciales. Ser capaces de detectar patrones, tendencias, etc. en tweets en general, o en los de un usuario o grupo de usuarios en particular, es sin duda muy interesante para organizaciones que puedan ser objetivo de ataques masivos (gobiernos, partidos políticos, sectores críticos…), de forma que la detección temprana permita articular cuanto antes mecanismos de respuesta adecuados.
• Canales IRC. Históricamente el IRC ha sido utilizado por grupos de hackers para el intercambio de información y conocimiento y la coordinación de ataques contra objetivos concretos. Aunque el primero de estos usos hoy en día es residual -al menos en canales IRC abiertos-, sigue utilizándose este medio (en especial a través de plataformas web) para coordinar ataques remotos, en muchos casos contra intereses supraindividuales, sobre todo administraciones públicas.
• Foros. En foros especializados en seguridad es posible detectar la existencia de nuevas vulnerabilidades de reciente aparición en tecnologías concretas -entre las que podemos encontrar las nuestras- y que, de una u otra forma, pueden afectarnos; en menor medida, en algunos foros underground es posible detectar la organización de ataques masivos contra terceros entre los que también podemos encontrarnos nosotros… o nuestros clientes. Adicionalmente, en función de nuestras áreas de negocio, seguro que existen foros especializados cuya conveniencia de monitorización debemos al menos evaluar: si por ejemplo yo trabajo en banca, quizás me interese saber que en un foro sectorial, focalizado en el negocio -nada técnico-, se habla de mí -bien o mal-.
• Redes sociales. Monitorizar el uso de redes sociales, tanto de personas internas a la organización como de personas ajenas a la misma pero que puedan introducir algún tipo de riesgo en ésta, nos permitirá detectar tanto el momento en que alguien hable de nosotros -bien o mal- como, mucho más interesante, diferentes indicadores básicos de riesgo humano para la organización: personal que pueda estar interesado en cambiar de trabajo, que mantenga alguna relación con organizaciones que puedan ser nuestra competencia, que introduzca debilidades -sexuales, políticas, religiosas…- que puedan suponer un riesgo para nosotros, etc.
• Webs. Históricamente, creo que todos hemos monitorizado webs específicas para detectar cambios en su contenido (un defacement, la publicación de una noticia interesante, un cambio no autorizado…). Por supuesto, esto es importante seguir haciéndolo, pero igual de importante es monitorizar ciertas webs para ver si publican información relativa a nosotros o nuestros clientes; quizás los mejores ejemplos sean pastebin, pastehtml o similares, sitios en los que -entre otras cosas- se aprovecha para colgar información privada y difundirla a millones de personas… de hecho, tal es el auge de este tipo de ataques que han “creado” un nuevo verbo en nuestra gramática: pastebinear :)
• Listas negras. En múltiples páginas de Internet se publican listas negras (habitualmente de direcciones IP o nombres de dominio) que por uno u otro motivo, pueden implicar riesgos de seguridad para un tercero, como DNSBL o RBN. La aparición del detonante (por ejemplo, una dirección IP propia) en una lista negra de uso relativamente frecuente es motivo más que suficiente para preocuparnos, ya que, con toda probabilidad, nos va a causar problemas: al igual que por nosotros, estas listas son consultadas por terceros para permitir o denegar comunicaciones -por ejemplo, para bloquear correos con un determinado origen- y, si nuestra dirección o nuestro dominio aparecen en ellas, es posible que lleguemos a encontrarnos con tráficos bloqueados, en muchos casos sin ser notificados de forma directa del problema. Ojo, aparecer en estas listas no tiene por qué significar, al menos a priori, que tengamos un problema de seguridad real: como tantas otras cosas, estas listas negras son generadas y mantenidas por personas (o programas) que, como cualquiera de nosotros, pueden cometer fallos, así que la aparición de una IP propia en estas listas puede ser fruto de un error, de un criterio erróneo -o diferente del nuestro- a la hora de generarla o de mil motivos más. Lo que es seguro es que si aparecemos, con o sin motivo, tendremos problemas, por lo que debemos estar al tanto de que esto sucede y actuar cuanto antes en caso afirmativo.
• Listas de correo. Al igual que en los foros, en listas de correo especializadas en una u otra temática de seguridad (o directamente, del negocio) se discute de aspectos que pueden afectar a nuestros niveles de riesgo: nuevas vulnerabilidades, comentarios que pueden afectar a nuestro riesgo reputacional, posibles fugas de información corporativa, etc.

¿Cómo monitorizar?
Hasta aquí todo es relativamente fácil: soy consciente de que necesito monitorizar entornos no cooperativos con una aproximación diferente a la que utilizo para monitorizar infraestructura propia. Es más, sé algunos sitios donde escuchar e incluso me hago una idea de qué es lo que quiero vigilar… ahora viene lo complicado: ¿cómo lo hago? El primer planteamiento es el uso de personas para esta tarea: puedo dedicar a parte del equipo a analizar todo el día entornos como los anteriores para que, si detectan alguna anomalía, la registren y se proceda a estudiarla con más profundidad… esto es técnicamente trivial, pero los problemas que introduce (coste de recursos, falsos negativos…) nos hacen abandonar la idea de forma inmediata -sobre todo por las horas que deberíamos dedicar-, al menos para la mayor parte de entornos. Debemos ir, por tanto, hacia esquemas automáticos de obtención de información y, si es posible, de correlación de datos para que el equipo humano se pueda focalizar en aquellas alertas que realmente merece la pena tratar.

No existe un modelo único para monitorizar entornos no cooperativos; debemos diseñar agentes que se adapten a cada fuente de datos concreta, agentes que podrán ser tan sencillos como una simple consulta sobre un listado descargado de Internet o tan complejos como el desarrollo de bots capaces de grabar y analizar sesiones IRC. Un ejemplo trivial para detectar si nuestra dirección está en una lista negra determinada puede ser el siguiente (sí, ya sé que se puede optimizar y mucho, es sólo un ejemplo…):


#!/bin/sh
DETONANTE="62.97.78.24" export DETONANTE
DATASRC="http://tcats.stop-spam.org/bnbl/bnbl.txt" export DATASRC
wget $DATASRC
grep -i $DETONANTE bnbl.txt 2>&1 >/dev/null
if [ $? -eq 0 ]; then
echo "DETONANTE EN BLACK LIST"
fi


Si damos un paso más, muchas páginas, como este mismo blog, disponen de mecanismos como RSS que facilitan la observación de su contenido (por ejemplo enviándonos un correo con el nuevo contenido, correo que podemos procesar automáticamente con un procmail o similar) y si vamos a cosas menos obvias, muchos entornos de los descritos anteriormente disponen de ciertas API, gratuitas o de pago -o ambas- contra las que podemos programar agentes más elaborados que el anterior; este es el caso, por poner un ejemplo, de Twitter, que nos permite buscar, a través de su API, tweets que cumplan un determinado patrón. Incluso podemos basarnos en capacidades de terceros para hacer esta adquisición de datos: un buen ejemplo en este caso puede ser Google Alerts…

Independientemente de la aproximación particular en cada caso (desde la más simple a la más compleja), el objetivo de una estrategia de monitorización de entornos no cooperativos debe pasar, una vez identificado qué queremos monitorizar y las fuentes de datos donde podemos hacerlo, por diseñar y mantener una comunidad de agentes capaces de extraer información unitaria -y útil- de cada fuente y remitirla a un entorno centralizado, bien para tratarla de forma manual, bien para -y hablaremos de esto más adelante- correlarla con el resto de datos enviados por cada agente y, una vez aportada esta inteligencia adicional, procesarla convenientemente (sustituyendo el echo “DETONANTE EN BLACK LIST” anterior por algo más trabajado ;). Vamos, un enfoque similar al de la monitorización habitual de entornos sobre los que tenemos el control, pero en lugar de recibir -y correlar- alertas de nuestros firewalls, de nuestros IDS o de los antivirus corporativos, ahora estamos haciéndolo sobre mensajes de Twitter, apariciones en listas negras o comentarios en foros, por poner unos ejemplos…

¿Cuándo monitorizar?
La respuesta a esta pregunta es muy sencilla: siempre que podamos. El tiempo real se convierte, como siempre que hablamos de monitorización, en condición indispensable. Si soy capaz de detectar una situación potencialmente peligrosa cuando está en su fase germinal podré hacer muchas más cosas que si hago un análisis post mortem del incidente que me ha causado esa situación. Dicho de otra forma, busco la alerta temprana, reservando los datos históricos para hacer unas gráficas y unas estadísticas que quedarán muy bien en un informe, pero que con la perspectiva histórica no me sirven para enterarme a tiempo de que algo se está organizando contra mí.

Estamos en la misma situación que a la hora de monitorizar entornos cooperativos: quiero enterarme cuanto antes de que algo que puede causarme problemas se está produciendo. Si es en el segundo uno, mejor que en el minuto uno, y si es en el minuto uno, mejor que en la hora uno… En la práctica, los agentes de monitorización de entornos no cooperativos suelen funcionar por polling, no por interrupción, con lo que en cada caso debo evaluar la frecuencia con la que comprobar los datos nuevos de cada fuente: cada minuto, cada hora, cada día… teniendo en cuenta por un lado la frecuencia de actualización de los datos (no tiene sentido monitorizar cada cinco minutos algo que sólo cambia una vez al día) y por otra los recursos consumidos en cada comprobación. En términos generales -aunque es difícil generalizar- para fuentes de datos que se actualizan de forma continua (Twitter, listas de correo…) los intervalos de comprobación deberían ser cortos, del orden de una hora máximo…

A partir de aquí tenemos -o al menos podemos empezar a tener- cubierta una buena parte de la etapa de adquisición de datos; ¿qué hacer con la información que vamos recibiendo? ¿cómo procesarla? Lo comentaremos en el próximo post ;)

En el ámbito de la seguridad -de cualquier tipo- suele existir una gran diferencia a la hora de tratar elementos cooperativos (aquellos que colaboran con nosotros para la consecución de un fin) o elementos no cooperativos (aquellos que o bien no colaboran lo suficiente o incluso se oponen a la consecución de dicho fin). Por poner un par de ejemplos, no tiene nada que ver la detención de un vehículo cooperativo (un policía le dará el alto y el conductor reducirá la velocidad hasta detenerse) con la de uno no cooperativo (el conductor se dará a la fuga y tendrán que utilizarse mecanismos más intrusivos que el anterior para lograr que se detenga), así como tampoco es igual la captura de datos biométricos en un lector de huellas dactilares (entorno cooperativo, los usuarios ponen el dedo voluntariamente y lo mejor posible para que se les permita un acceso) o en la escena de un crimen (el delincuente se esforzará por no dejar rastro y lo que encontraremos será, probablemente, trozos aislados de huellas que habrá que procesar hasta generar la imagen completa… o ni eso).

Al igual que sucede en los ejemplos anteriores, no es lo mismo obtener información de elementos tecnológicos a los que hemos denonimado cooperativos (aquellos que nos facilitarán sus registros, nos permitirán implantar monitores internos de muy bajo nivel, nos enviarán datos en tiempo real…) que de elementos que hemos denominado no cooperativos: sistemas, entornos, infraestructuras… que simplemente están ahí, ajenos a nuestro control, y que pueden ser usados por un número indeterminado de personas para hacernos, de una forma u otra, daño. Más claramente: si quiero monitorizar los sistemas de correo electrónico de mi organización -un entorno cooperativo-, lo tengo, al menos técnicamente, muy fácil: puedo implantar controles que me alerten si un usuario envía N correos en un intervalo de tiempo determinado, si en los correos se lee la cadena “confidencial”, si van cifrados o no, o si se envían en horario laboral o fuera de él. Es más, si me apuran, capturo todos los correos que pasan por el servidor (de entrada o de salida) y me los guardo para su análisis offline. Si quiero hacer eso mismo con un proveedor como GMail, lo tengo bastante más complicado: los amigos de Google no me van a dar -y bien que hacen, por supuesto- ni un mísero log para revisarlo, ni por supuesto nombres de usuario, horas de conexión o direcciones IP desde las que se accede a una determinada cuenta: tengo, por tanto, un entorno no cooperativo.

Antes de seguir, un par de comentarios: a la hora de hablar de “cooperativo”, al menos en este caso, no se determina mala fe ni nada parecido por parte del entorno a monitorizar -incluso, probablemente, estará actuando como debe-, simplemente hacemos referencia a nuestra incapacidad para obtener de él los datos que nos gustaría: Google puede trabajar muy bien, pero no nos proporciona toda la información de GMail que podríamos obtener de nuestro servidor de correo interno. Como segundo comentario, indicar que “cooperativo” no significa necesariamente “interno a una organización”: si no tengo el root del servidor de correo corporativo, por muy “interno” que sea éste no podré obtener de él ciertos datos y, por el contrario, si me alquilo un servidor dedicado en un proveedor ruso, externo por completo a la organización, posiblemente tendré acceso a todos sus logs y podré hacer con él lo que considere…

Como decimos, tiene poco que ver la monitorización de entornos cooperativos (en plata, tengo el control directo o indirecto y hago lo que me place) que la de entornos no cooperativos (no tengo ningún control especial sobre el entorno y por tanto sólo puedo monitorizar lo que me dejan, no lo que me gustaría). En un entorno cooperativo empezaré seguramente desplegando un NIDS y vigilando sus registros, elemento que luego complementaré con un HIDS, un cortafuegos, un proxy, un antivirus… y si quiero ir más allá, desarrollaré agentes específicos que vigilen correos electrónicos, visitas web o llamadas telefónicas que puedan ser significativas para mi seguridad. La profundidad de monitorización la marco yo y solo yo, y técnicamente puedo llegar casi tan lejos como se me ocurra: controlo la infraestructura al 100%. Si quiero monitorizar entornos no cooperativos (Twitter, foros, webmails externos, redes sociales, listas negras…), de entrada me encuentro con que no puedo desplegar un NIDS en Facebook o Twitter, por poner un par de ejemplos…

Nos guste o no, lo que estamos llamando entornos no cooperativos están ahí, al alcance de cualquiera, y seguirán estándolo con independencia de nuestra opinión. Y se seguirán utilizando para introducir riesgos en nuestra organización o en terceros, incluyendo actos delictivos contra determinados objetivos (con independencia del medio en el que luego se comentan estos actos); dicho de otra forma: un grupo de personas puede organizarse a través de Twitter para lanzar un DDoS contra nosotros, contra un tercero… o sencillamente para ir a una manifestación violenta antisistema frente a la Delegación del Gobierno (algo que en ese punto ya no tiene nada que ver con la ciberseguridad sino con la seguridad a secas). Si de una u otra forma somos capaces de detectar estas actividades seremos capaces de responder adecuadamente ante un incidente, incluso antes de que se materialice. Todos de acuerdo, ¿no? Si me entero de que un grupo de personas está organizando un ataque contra mí utilizando canales IRC, podré prepararme mucho mejor para repeler el ataque, llegando incluso a ser posible la infiltración en el grupo y la toma de control del medio no cooperativo, utilizándolo a nuestro favor para proporcionar información negativa o generar confusión y mitigar así el impacto del ataque. Creo que queda claro que monitorizar estos entornos no cooperativos se convierte, cada día más, en una necesidad para todos los Departamentos de Seguridad. Continuaremos con las preguntas del millón: ¿qué?, ¿cómo?, ¿cuándo? y ¿dónde?, pero en otro orden…

Hace ya años que quiero publicar, por estas fechas, un post (quizás algo offtopic, ustedes dirán ;) que hable de la seguridad -de las personas en este caso- a la hora de disfrutar de una afición que muchos compartimos: el estudio de las setas y hongos, el interés por su identificación y recolección y, por supuesto, su valor gastronómico. Por estas fechas por un motivo obvio: estamos ahora en la temporada de setas por excelencia, ya que aunque setas hay todo el año es en primavera, y sobre todo en otoño, cuando más ejemplares y de más especies podemos encontrar en nuestros bosques, y por tanto cuando nos lanzamos, cesta en mano, a su recolección…

Este año no ha sido especialmente bueno en -creo- ningún punto de España para los aficionados a la micología; un verano demasiado seco y caluroso, y las lluvias otoñales que se han hecho esperar más de lo debido, han motivado que en la mayor parte del país podamos disfrutar más bien poco de una jornada en el campo buscando setas… y contando con que el invierno -y por tanto el hielo y la nieve- están al caer, la temporada podemos decir que está siendo más bien inexistente. Pero aún así, ayer ya aparecía en los medios el primer caso de muerte esta temporada por ingesta de setas en Mataró (Barcelona). Todos los años fallecen varias personas por este motivo: la ingesta de setas tóxicas. Muy pocas setas son mortales, pero si tenemos la desgracia de consumir alguna de ellas, las consecuencias son claras…

Desde el punto de vista “gastronómico” las setas se pueden dividir en comestibles, no comestibles y tóxicas (realmente hay un cuarto grupo, las setas comestibles bajo ciertas circunstancias, aunque yo las consideraría directamente no comestibles o tóxicas… y más en este post ;). Las primeras, obviamente, son las más buscadas y las que más se conocen a nivel general: Lactarius deliciosus, Amanita caesarea… y las segundas son setas sin ningún interés culinario: no saben bien, poseen una textura leñosa, etc.; ejemplos de éstas son casi todas las setas que crecen en la madera, como Trametes versicolor. Obviamente las setas no comestibles no suelen causar accidentes: si algo está malo o tiene una textura desagradable, nadie lo ingiere. El problema está en las setas tóxicas, setas con un sabor que puede resultar agradable -por eso es consumen- pero con unos venenos que pueden provocar desde trastornos digestivos (un ejemplo curioso es Coprinus atramentarius) hasta alucinaciones (Amanita muscaria, Amanita pantherina…), daños físicos irreversibles (Schizophyllum commune…) … o incluso la muerte (Amanita phalloides, Cortinarius splendens…).

Como decíamos, todos los años fallecen personas por ingerir setas mortales accidentalmente (eso sin contar intoxicaciones leves por setas no mortales, que no suelen ir más alla de ciertos trastornos menores y que no saltan a los medios); suele haber dos perfiles de víctimas: los incautos y los confiados. Los incautos más extremos son los que salen al monte y cogen cualquier cosa que parezca una seta, la cocinan y se la comen. Sin más. Obviamente, contra esto poco se puede decir: simplemente NO LO HAGAS. La probabilidad de intoxicarte es elevadísima, y la probabilidad de sufrir lesiones irreversibles o incluso morir es también considerable (en función de la zona de búsqueda y demás)… Afortunadamente, este tipo de incautos es mínimo; los incautos más numerosos son los que, basándose en creencias populares que vienen a decir que si un animal come una seta y no muere es que es comestible para un humano, que si la cocemos con una cuchara de plata y la cuchara no se pone negra es que no tiene veneno, que si es de tal o cual color se puede comer o no…deciden ingerir ejemplares de una determinada especie. Por supuesto, todos estos tópicos son completamente falsos y sin ningún rigor científico: la única forma de determinar a qué especie pertenece un ejemplar y la cantidad de veneno que tiene es en un laboratorio, con el material y los conocimientos necesarios. Todo lo demás son mentiras, aunque lamentablemente muy extendidas en zonas con afición micológica y aún a día de hoy creídas por demasiadas personas… Obviamente debemos desconfiar de cualquier identificación en base a estos mitos y jamás comernos una seta porque hemos visto que una oveja la ingiere sin problemas, por poner un ejemplo :)

Tras los incautos, tenemos a los confiados; los que creen que han identificado un ejemplar porque se parece a los de la especie que recogen habitualmente -o peor, porque se parece a la foto de una guía de setas “todo a 100”-, lo cocinan y se lo comen. El reino de los hongos es apasionante, pero entre sus cualidades encontramos que es muy engañoso; factores como la humedad, la exposición al sol o simplemente el terreno de crecimiento pueden hacer que dos ejemplares de una misma especie no se parezcan entre sí en nada -visualmente, claro-. O al contrario, que dos especies diferentes, una excelente comestible y una mortal, tengan un parecido asombroso. Para evitar esto, el principal consejo es no consumir ningún ejemplar si no estamos completamente seguros de su identificación. Y el estar completamente seguro -fuera de un laboratorio, insistimos- es difícil y sólo se consigue con años y años de experiencia y con buenos maestros -no con un simple libro de setas generalista-. Existen por todo el país -por todo el mundo- sociedades micológicas (en la Comunidad Valenciana está SOMIVAL) en las que podemos aprender mucho sobre setas y hongos, con auténticos expertos que nos pueden ayudar a identificar correctamente ejemplares tanto en laboratorio como en el campo y a las que podemos acudir incluso con ejemplares que hemos encontrado por nuestra cuenta para que nos echen una mano con la identificación… una vez que estemos seguros de que una seta es comestible, podremos disfrutarla en la mesa, pero ante la más mínima duda, no vale la pena jugársela…

Finalmente, otro consejo de seguridad; aparte de la correcta identificación de los ejemplares para no equivocarnos a la hora de consumir setas, recordemos que cuando salimos al monte a buscarlas estamos en un entorno más o menos hostil. Todos los años se producen demasiados accidentes buscando setas; típicamente, caídas, desorientaciones… aunque la mayor parte de ellos suelen acabar bien, sobre todo gracias al excelente trabajo de la Guardia Civil en el ámbito rural, algunos tienen consecuencias fatales. Es muy importante conocer el término en el que vamos a buscar setas, llevar un calzado y ropa adecuados y un teléfono móvil -con batería, obviamente- para poder llamar en caso de emergencia; y que personas de nuestro entorno sepan dónde vamos y sobre qué hora tenemos prevista la vuelta, para que puedan dar la voz de alarma en caso de que algo raro suceda. Si podemos salir en grupo, mucho mejor que solos, y si la climatología es adversa -sobre todo con niebla- es preferible quedarnos almorzando que adentrarnos en el monte…

Todos los aficionados confiamos en que esta temporada los problemas de seguridad “micológica” sean los menos posibles… y que no empiece a nevar o a helar de momento, para ver si se arregla la temporada :)

Hace ya tiempo que venía pensando en poner un post cifrado (GPG con clave simétrica) en Security Art Work para ver quién era capaz de romperlo, pero esto me planteaba dos problemas: si nadie lo rompía -que confío en que sea lo normal-, todos íbamos a decir que vaya reto más complicado… y si alguien era capaz de descifrarlo me empezaría a asustar :) Así que decidí incorporar algún tipo de pista que hiciera fácil el romper el post cifrado. Para no andar con adivinanzas raras, del tipo “la clave es la fecha de nacimiento de Phil Zimmermann XOReada con el número de seguidores del blog a fecha 15/04/2009 y restándole 3“, pensé que lo mejor era meter la clave de cifra en el propio mensaje cifrado. Pero esto tenía una complicación: dado un texto en claro y una clave de cifra, yo no sé si el mensaje cifrado contendrá una cadena concreta, en este caso la correspondiente a la clave… ¿o sí?

La verdad es que hace muchos años, tras leer el “Applied Cryptography” de Bruce Schneier, me dí cuenta de que ni tenía ni seguramente jamás conseguiría la base matemática suficiente para aprender criptografía “en serio”; era un tema que me interesaba pero, dentro de la seguridad, no era para mí lo más apasionante… Por tanto, a partir de ese momento he sido un simple usuario de aplicaciones de cifrado, con unos conocimientos básicos de criptografía o criptoanálisis para poder hablar del tema tomando un café pero por supuesto sin poder ir más allá. Vamos, que cuando Jorge Ramió habla de ataques complejos sobre el algoritmo lo-que-sea me quedo con la boca abierta :) Así, tras más de quince años usando PGP/GPG, la verdad es que jamás me había planteado nada más allá de su uso habitual: cifra, firma, anillos, confianzas y demás… pero nunca es tarde :)

Vamos allá. ¿Cómo meter la propia clave de cifra en el mensaje cifrado usando GPG? El RFC 1991 define los formatos de intercambio de mensajes PGP; para el formato ASCII Armor, el que iba a usar, se marcan seis campos:

• Línea de cabecera (cinco guiones, “-“, la cadena “BEGIN PGP MESSAGE” y cinco guiones más en nuestro caso).
• Cabeceras (versión de la aplicación y similares, en nuestro caso algo del tipo “Version: GnuPG v1.4.6 (GNU/Linux)”).
• Línea en blanco.
• Datos cifrados con formato ASCII-Armored.
• Checksum.
• Línea de fin (en nuestro caso, cinco guiones, “-“, la cadena “END PGP MESSAGE” y cinco guiones más).

Los campos que a priori desconocemos son únicamente los correspondientes a los propios datos cifrados y al checksum del mensaje; por tanto, para usar como clave de cifra algo que sepa de antemano que estará en el mensaje cifrado, no tengo más que elegir una clave ubicada los restantes campos: “END PGP”, “—–“, “P MESSAGE-“, “nuPG v1.4” o similares… Demasiado fácil, ¿no? Si me planteo un ataque, con elegir claves de longitud variable a partir de estos campos tengo más que suficiente…

Lo siguiente sería conseguir una clave de cifra que esté en los propios datos cifrados; los ocho primeros caracteres de este campo son “adivinables”, ya que marcan detalles como protocolo de cifra, versión, etc. necesarios para el descrifrado (por cierto, si alguien tiene información de qué es cada uno de los campos, le agradecería que me la enviara, que tengo curiosidad y en San Google no he encontrado nada “digerible” ;) También muy fácil seleccionar claves de esta cadena y empezar a probar por fuerza bruta… Lo interesante es meter la clave de cifra en los datos del cuerpo/checksum no predecibles -al menos por mí-. ¿Cómo? Pues también por fuerza bruta :)

Tenemos un texto -sí, el del post del otro día, bastante antiguo- en un fichero “monkeys”:

$ cat monkeys
I LIKE MONKEYS
I like monkeys.

The pet store was selling them for five cents a piece. I thought that
odd since they were normally a couple thousand each. I decided not to
look a gift horse in the mouth. I bought 200. I like monkeys.

I took my 200 monkeys home. I have a big car. I let one drive. His
name was Sigmund. He was retarded. In fact, none of them were really
bright. They kept punching themselves in their genitals. I laughed.
Then they punched my genitals. I stopped laughing.

I herded them into my room. They didn't adapt very well to their new
environment. They would screech, hurl themselves off of the couch at
high speeds and slam into the wall. Although humorous at first, the
spectacle lost its novelty halfway into its third hour.

Two hours later I found out why all the monkeys were so inexpensive:
they all died. No apparent reason. They all just sorta' dropped dead.
Kinda' like when you buy a goldfish and it dies five hours later. Damn
cheap monkeys.

I didn't know what to do. There were 200 dead monkeys lying all over my
room, on the bed, in the dresser, hanging from my bookcase. It looked
like I had 200 throw rugs.

I tried to flush one down the toilet. It didn't work. It got stuck.
Then I had one dead, wet monkey and 199 dead, dry monkeys.

I tried pretending that they were just stuffed animals. That worked for
a while, that is until they began to decompose. It started to smell real
bad.

I had to pee but there was a dead monkey in the toilet and I didn't want
to call the plumber. I was embarrassed.

I tried to slow down the decomposition by freezing them. Unfortunately
there was only enough room for two monkeys at a time so I had to change
them every 30 seconds. I also had to eat all the food in the freezer so
it didn't all go bad.

I tried burning them. Little did I know my bed was flammable. I had to
extinguish the fire.

Then I had one dead, wet monkey in my toilet, two dead, frozen monkeys in
my freezer, and 197 dead, charred monkeys in a pile on my bed. The odor
wasn't improving.

I became agitated at my inability to dispose of my monkeys and to use the
bathroom. I severely beat one of my monkeys. I felt better.

I tried throwing them way but the garbage man said that the city wasn't
allowed to dispose of charred primates. I told him that I had a wet
one. He couldn't take that one either. I didn't bother asking about the
frozen ones.

I finally arrived at a solution. I gave them out as Christmas gifts. My
friends didn't know quite what to say. They pretended that they like
them but I could tell they were lying. Ingrates. So I punched them in
the genitals.

I like monkeys

$

¿Cómo cifrarlo con una cadena que esté en el texto cifrado? Pues vamos probando… meter una clave de un carácter es inmediato, y por supuesto conforme incrementamos la longitud, la cosa cuesta más:

$ cat encode
#!/bin/sh

if [ $# -ne 2 ]; then
echo "Uso: $0 fichero password"
exit -1
fi

/bin/false
while [ $? -ne 0 ]; do
if [ -f $1.asc ]; then
rm $1.asc
fi
gpg --batch --passphrase $2 -c -a $1
grep $2 $1.asc 2>&1 >/dev/null
done
$
$ time ./encode monkeys a

real 0m0.016s
user 0m0.008s
sys 0m0.000s
$ time ./encode monkeys a1

real 0m0.064s
user 0m0.036s
sys 0m0.028s
$ time ./encode monkeys a1j

real 0m0.177s
user 0m0.108s
sys 0m0.068s
$ time ./encode monkeys a1j6

real 0m29.941s
user 0m17.441s
sys 0m12.473s
$ time ./encode monkeys a1j69

real 10m13.857s
user 5m49.878s
sys 4m16.124s
$

Vemos que si usamos una clave de cinco caracteres ya cuesta generar el texto cifrado diez minutillos… ¿Qué tal si intentamos usar una clave de seis caracteres?

$ time ./encode monkeys a1j69c

real 340m52.839s
user 174m31.662s
sys 115m46.658s
^C
$

Me parece que la probabilidad ya empieza a ser muy baja… 340 minutos y siguiendo para bingo… mejor hacemos Control-C y nos quedamos con una clave de cinco caracteres…:) Esto nos da una idea de la longitud que más o menos puede tener la clave del post cifrado.

¿Cómo romper la cifra? Podemos intentar atacar al algoritmo CAST5, el usado por defecto por GPG para cifrado simétrico, pero no creo que esta línea sea muy provechosa… otra opción es atacar a las personas para obtener la clave, línea que directamente no recomiendo porque en este caso el afectado sería yo. Más sencillo: si alguien me hubiera pedido la clave se la habría dado… a fin de cuentas tampoco se esconde aquí ningún secreto. Pero por supuesto, lo realmente interesante del mensaje cifrado no era cómo romperlo, ya que con la pista de la clave metida en el post era más que suficiente (alguna otra era para despistar ;), sino simplemente pasar el rato y aprender un poquito más de GPG. Este script “rompe” la cifra en unos segundos, muchos menos de lo que cuesta generarla:


$ cat decode
#!/bin/sh
if [ $# -ne 1 ]; then
echo "Uso: $0 fichero.asc"
exit -1
fi
content=`cat $1|tr -d '\n\'`
len=`echo $content|wc -c`
for l in 1 2 3 4 5 6 7 8; do
i=1
while [ $i -le $len ]; do
KEY=`expr substr "$content" $i $l`
i=`expr $i + 1`
gpg --batch --passphrase $KEY -d $1 >$1.clear 2>/dev/null
if [ $? -eq 0 ]; then
##cat $1.clear
echo "CLAVE: $KEY"
exit 0
fi
done
done
$ time ./decode monkeys.asc
CLAVE: a1j69

real 1m17.165s
user 0m45.747s
sys 0m30.230s
$


En poco más de un minuto hemos averiguado la contraseña…Por eso el “premio” era sólo una cerveza ;) Espero que al menos se hayan entretenido una horita… para la próxima, si ponemos un mensaje cifrado con GPG sin pistas y alguien lo rompe, habrá una recompensa más importante (nuestra o de algún otro, seguro).


-----BEGIN PGP MESSAGE-----
Version: GnuPG v1.4.6 (GNU/Linux)

jA0EAwMC2+qz3dKkBoBgyer2DbAvJOF9dlfpJiTGE/ofNUwxhFXMS7XIHRTqTlZe
HvftsDklx/3av8iHFsDUJjcK25zm9a/nuembP1iHBkyDk1RMstF6Z7CWZ1974BBn
BBjfc7MNskqwNbJ5p/skLSzMF/1M9bJk4DRh/OpXz6dUqm2XVpCf1dcMTEipkg6r
8mKk57lk6MTvpNshez7n4qiC+GRLJTSGsCVaQYhYN9hfIhZDfflvruo2Gh7xFoCe
WnECHCKIhzKBxvLq8JePNGdTECtoC0M6EXYZyrJ1Gifd/ev4Z7g3Mlf+tuSj4Kar
bo/K+zkzDZvKXLJDtqk4CAOteaewx1YAUOMa/Omma24jq2D0LHy/rSgcNTSzT12U
e1UyEnzuIs0Qj45qj+P+X/M6wBpm/XkbMtbxceCBW6PVWZyzpo9a0yeLFCR+aoXO
ywJN7ZxF9k5dFOATxPjZlaot0HmqVd81kbAOk/To9b+YDzyMvnLVQSvpv3/2W6Gp
dxAjihWqelE4tPIoAND3aG4u4yS8BBHlMaEaRi4sTD6oRbw8dRjfZJoxJiH3XS1Q
tWx8Z3ChVVvRv3N5bJnNdSzymiWwbutIAU6JFUMP74LDrkG8WkgCjlUqrIdffx4p
NjO9UOdLck0m4Ha8fdHNnuAY18GX+QSFy/M7dJEEhVSiRIu4N+9Oznb8N3ySa/cl
px/iO6jX19W9Na5d7zWJ23FmJL1EWuCwFYCKfYfKiMNppYgoBkzZqJuQ+9aHKlQy
M7JhXyBF80Hu/ymlcrZIH94o/LrJ5bxglICzBoisTORaBsT2yJnObjex7SsR3Y41
4Sq3K/TZ1q6+IX48MFj6RQT+KP7PPadvQdMHzvL+2k1hsj3qLQ6pkC3TbaimVYN6
wS37+jhpP9AbfZRspAg99cpt14dKK2rT66DZicDEdulynRziIyU1RzBhj3iH0BLD
FW+BoD6FaBJBBvHrwBOIbrbfOBTFkmMD7IQx1Hdo4FzK5CjK1x5NRQ048au/yvuV
GyA8V5udZu+yEGQGUaCt18n8X+67GYQHr3c9QAnJPdMutxvwBDEKuv5q434Qtcq0
5Fl2vBHXjoi81VZEZMUDW3imp36UN1BrW53iIypqaJWWGIetP3CZjX9h+7P454lF
aDY0HvJj4pZOtSMbi8Jd+BMNTXKzfXfZTq5gsFoQRvEl4hPna3qre4FA2JHVwWLN
e2dxUnj4EfIS4osh9u6QfIXVveiAU+08oJE8x8FQ06vdFjbumuoltJfyQ2rGdEDB
O/FnoYgPtyo5SJVg4mSxrAqObuF5EQqCHFzhW3zLk13D9WJ8ScYWgi7aVjztd13X
h4aMnAat3yv1gYtV2ZKYfxJOTG4CMGShThLOwGZbiVD7wGhiD871JdcjwvM0DTNu
iEhr65+DsLxqbjZpJJsOYGZcezkb4wbhKID6U+Xjwqii7xu4/rGwhvHA1s5F6fGF
NB3E6zCrAGFGaLi0nPf84qKevxhIlbjpz8TtAkK+N14A/eYwKib2k8aYJSIt5KXg
lMjEpwqxQVvjP7pyJKY+lid5ayzZKCDcemxt2bQyRquFp8UjftFf6YmfUwa1j69J
s2DvGLz2BT87OXfrz2bPQzj4nxWwIgrt524XqHveBzk3Fu6tHiglibYs7C+LcnkO
7+U8lQhcNSdm0Ox9Hgs9enzdMI3sp7MDr4SYkW9gs9cMmM8A7ZhDv2MI5J1Btkfa
lEv0plWxL+rJVQPMkP8vFKtRNfz5kX4otLxyxD7fE5s3caH0l1bbwJ4FfA==
=MICp
-----END PGP MESSAGE-----


Hemos decidido cifrar el post de hoy por varios motivos: cifrar la información siempre queda bien si hablamos de seguridad, no había visto nunca un post cifrado en un blog, tengo mucho trabajo y no me da tiempo a preparar una entrada en condiciones, se acerca el fin de semana -puente para algunos afortunados- y qué mejor que GPG para pasar un rato entretenido… en fin, excusas. La cuestión es que está cifrado para que ustedes, si tienen un hueco, lo descifren y disfruten de una interesante lectura :)

Justificaciones aparte, algunas pistas que pueden (o no) ser de utilidad:

• La orden utilizada para cifrar es gpg -ca fichero (o equivalente ;)
• El cifrado es simétrico, CAST5.
• La clave de cifra está en este mismo post.
• El texto en claro contiene la cadena “197”.
• La clave de cifra no es una palabra en castellano.

Fácil, ¿eh? Para el primero que saque la clave, una cervecita… y la semana próxima comentamos el por qué -real- de esta entrada :)

1. Si mis datos no fallan, dentro de la Guardia Civil se instaura el Grupo de Delincuencia Informática hacia 1997, a cargo del Teniente Anselmo del Moral; desde 2000 hasta este mismo año el Grupo ha estado liderado por el Comandante Salom, y en estos momentos por ti. Ha llovido mucho estos años y, cambios de nomenclatura aparte, ¿cómo ha sido la evolución del Grupo durante este tiempo?

Paralelamente a la evolución de las nuevas tecnologías, a nivel técnico el Grupo se ha ido adaptando a la utilización de las mismas por los delincuentes con nuevos procedimientos, nuevas técnicas y nuevos protocolos de actuación. Sin embargo, a pesar del incremento de la plantilla y las últimas incorporaciones (incluida la mía, claro) el espíritu del mismo permanece intacto, un Grupo muy cohesionado y con clara vocación de servir al ciudadano tratando de crear una red más segura, permitiendo al mismo participar de forma proactiva a través de los distintos canales de comunicación que tenemos abiertos.

2. ¿Y la evolución de la investigación tecnológica en las Comandancias?

De forma igual a como ha sucedido en el Grupo, en las Comandancias se ha conseguido subir un peldaño en lo que a investigación tecnológica se refiere. Dentro de las Unidades de Policía Judicial de la Guardia Civil, encargadas de la investigación de todo tipo de delitos, hay personal encuadrado en unos equipos denominados EDITE´ s (Equipos de Investigación Tecnológica), con formación específica y suficiente como para desarrollar sus propias operaciones en el caso de delitos informáticos, así como para apoyar al resto de sus compañeros, ya que hoy en día es habitual que en cualquier tipo de delito aparezca algún tipo de componente tecnológico. Para nosotros representan una enorme ayuda, ya que ellos se encargan de muchas de las investigaciones cotidianas, y por supuesto de los apoyos a otras investigaciones dentro de su territorio.

3. ¿Y la evolución del delincuente? ¿Nos enfrentamos a hackers románticos como antaño o en la actualidad hablamos de mafias que trabajan por dinero?

En efecto, los grupos de delincuencia organizada en general, han migrado hacia un modelo “empresarial” del delito, en el que las tareas a desarrollar están perfectamente definidas y estructuradas para cada uno de los miembros de la organización, y la finalidad última es el lucro, sin lugar a duda. Existe un mercado negro en la red, en el cual se comercia con todo, desde listados de tarjetas de crédito, hasta credenciales de usuarios, pasando por supuesto por todo tipo de malware y servicios técnicos para el ciberdelincuente.

4. ¿Cuál es el delito telemático que más os preocupa hoy en día, tanto por número de delitos como por repercusión mediática?

Aunque por número de delitos destacan los fraudes cometidos a través de la red, especialmente en el comercio electrónico, el bien jurídico protegido en estos casos es patrimonial, y relativamente sencillo de reparar si lo comparamos con otros como puedan ser la integridad física o moral de los más desprotegidos. Por lo tanto, delitos como los abusos y acosos sexuales a menores siguen centrando gran parte de los esfuerzos que realiza el Grupo en su día a día, con especial atención a las nuevas formas tales como el grooming, el bullying, o el sexting. Tampoco debemos olvidar aquellos que afectan a la integridad de los datos y la intimidad de las personas. Por desgracia el robo de identidad es un fenómeno actual, y cuyos efectos provocan daños a menudo irreparables.

5. ¿Qué capacidad tenéis para afrontar denuncias en las que se implican terceros países? Dicho de otra forma, si me roban la identidad en Facebook, ¿me podríais ayudar?

Una de las características comunes a estos delitos es la globalidad, por lo tanto la cooperación internacional es fundamental para su resolución. Los mecanismos judiciales para el auxilio entre países no son todavía tan ágiles como nos gustaría, por lo tanto nos esforzamos, y creo que podemos decir que hemos conseguido, en mantener excelentes relaciones con todos los actores implicados en este área, como son el resto de policías, proveedores de servicios, redes sociales, portales de venta, que nos permiten solucionar de forma rápida los problemas que no necesitan de una tutela judicial. En el caso concreto que nos expones, nosotros nos encargaríamos de la investigación para localizar al responsable del hecho, pero la devolución del perfil sólo la puede realizar Facebook tras realizar las verificaciones oportunas.

6. ¿Cuáles serían los requisitos para pertenecer al Grupo de Delitos Telemáticosde la Guardia Civil? ¿Puede acceder a este grupo cualquier miembro de la Benemérita? ¿Os pueden trasladar a otro grupo que no tenga nada que ver con la tecnología?

Para acceder al Grupo no se requiere ninguna titulación formal en informática. A los aspirantes se les realiza una entrevista personal para poder evaluar sus conocimientos técnicos, así como una prueba psicológica para evaluar si los rasgos de su perfil se adaptan a nuestras necesidades. Por la experiencia que tenemos, nos aporta más un agente con buena mentalidad investigadora y menos conocimientos, que puede ir adquiriendo, que otro muy técnico pero con menos capacidad analítica. Si la persona seleccionada supera un periodo de prueba que puede durar en torno a un año, pasa a encuadrarse definitivamente en el Grupo. Respecto a la última pregunta, los ascensos son un claro ejemplo en los que obliga a dejar la vacante ocupada, y si no coincide una vacante libre asociada al nuevo empleo obtenido hay que cambiar de Unidad y desarrollar cometidos totalmente nuevos.

7. En un mundo tan cambiante como el del delito tecnológico, ¿cómo conseguís manteneros formados permanentemente? ¿Tenéis acceso a cursos de reciclaje y formación?

Aunque no resulta sencillo poder distraer personal de las investigaciones, por el volumen de trabajo que suponen, somos conscientes de la necesidad de mantenerse formado y actualizado, sobre todo en el ámbito de las nuevas tecnologías. Por lo tanto, frecuentemente miembros del Grupo asisten regularmente a cursos, seminarios o charlas.

8. En las series de policías, tan de moda hoy en día, vemos actividades tecnológicamente impresionantes. ¿Se alejan estas series mucho de la realidad? ¿Cómo es un día normal de trabajo para los miembros de tu equipo?

Sí que es cierto que parte de realidad hay en estos procedimientos, especialmente en el ámbito forense, pero también es un hecho que están convenientemente “adornados” para resultar más atractivos para el espectador. Lamentablemente los cuerpos policiales no tenemos bases de datos “de todo” como en las series de CSI, en la realidad somos muy escrupulosos con la gestión de datos de carácter personal y con las limitaciones de derechos fundamentales de los ciudadanos.

9. Finalmente, queríamos pedirte algunas recomendaciones:

a. A los padres cuyos hijos conectan a Internet y están preocupados porque no son capaces de entender qué hacen en la red.

Que hagan un esfuerzo por aprender. No sirve de nada imponer limitaciones o espiar qué hacen en el ordenador de casa ya que hoy día hay mil formas de conseguir acceso a la red, hay que sentarse con ellos y compartir la navegación. Los padres aprenderán técnicamente de sus hijos, y los hijos aprenderán de la experiencia de los padres para detectar contenidos y situaciones que sean potencialmente peligrosas. Los padres deben trasladar los consejos y la educación que daban a sus hijos para desenvolverse en el mundo real al mundo virtual.

b. A los usuarios domésticos de servicios a través de Internet: banca,servicios DNI-e, P2P…

Que haciendo uso del sentido común, eviten hacer operaciones, gestiones o transacciones que en el mundo real jamás realizarían, si tienen un mínimo de duda sobre la autenticidad o veracidad de la otra parte. Los usuarios deben de ser conscientes de las posibilidades que ofrece Internet para alterar la identidad de las personas con las que nos comunicamos o creemos que nos estamos comunicando.

c. A los profesionales de la seguridad tecnológica que día a día nos encontramos con nuevas técnicas, nuevos delitos y nuevos delincuentes (y cada vez más lejos ;)

Colaborar. La solución a estos nuevos problemas está en las propias nuevas tecnologías, que nos permiten compartir información de forma instantánea. Por lo tanto la mejor forma de actuar es sumar esfuerzos entre todos los implicados, compartir información, y revertirla al ciudadano para que sea capaz de identificar las nuevas amenazas. Al final es cuestión de concienciación y educación.

10. Ya para acabar… ¿algo que quieras añadir a esta pequeña entrevista?

Agradecer la posibilidad que nos habéis ofrecido de acercarnos al ciudadano un poco más, que pueda conocer quiénes somos, qué hacemos y cómo le podemos ayudar. En nuestro portal disponéis de más información tales como alertas y noticias, la posibilidad de colaborar, los enlaces a aplicaciones móviles y enlaces de interés para que, entre todos, consigamos hacer una red más segura.

Si hace unos meses nos dejó Robert Morris, esta mañana nos enterábamos de la muerte el pasado domingo de Dennis Ritchie, dmr. Otro de los grandes que se va en este annus horribilis :(

Dudo que dmr necesite ningún tipo de presentación; jamás diseñó un iPhone o un iPad, pero entre sus pequeños aportes a la informática actual destacan el lenguaje de programación C (si alguien no se ha leído el K&R ahora es un buen momento para hacerlo y homenajear así a la R) o, junto a Ken Thompson, el sistema operativo Unix. Ahí es nada. Eso sin contar trabajos menos populares que Dennis Ritchie lideró o en los que participó de forma muy directa, como Plan9, Inferno o Limbo.

Estos trabajos le valieron a Dennis Ritchie todo tipo de premios y reconocimientos -entre ellos el Premio Turing de la ACM, quizás lo más parecido al Nobel en el campo de la informática- pero, sobre todo, la admiración de millones de personas que hemos devorado buena parte de lo que dmr escribía, usado y administrado sistemas operativos como Unix, programado en lenguajes como C y, en definitiva, tratado de aprender una milésima parte de lo que este genio ha aportado a la tecnología.

[Read more…]