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 ;)
