En el último post de esta serie comentábamos la problemática asociada a la cantidad y calidad de las alertas generadas al monitorizar entornos no cooperativos. Para corregir estos problemas debemos aplicar las mismas medidas que cuando monitorizamos entornos cooperativos, y esas medidas pasan, irremediablemente, por la correlación de las alertas generadas por los monitores que vamos desplegando día a día.
Como casi siempre suele suceder, hablar de correlación es muy sencillo pero hacerla de verdad no suele serlo. Para empezar, el primer gran escollo a superar es el motor de correlación: obviamente necesitamos “algo” capaz de correlar, “algo” a lo que decirle qué relaciones entre alertas pueden existir o ser más significativas -o “algo” capaz de aprenderlo por sí mismo, que ya sería el colmo :)-. Bien, pues esta obviedad que indicamos suele ser bastante compleja de implementar en la práctica; de hecho, llevamos años de correlación en PowerPoint pero aún hay muy pocos correladores decentes en el mercado. Existen algunos motores de correlación, pero suelen presentar dos graves problemas (ojo, generalizando, no siempre es así): su precio (aunque hay algunos proyectos abiertos que pueden dar buenos resultados) y, sobre todo, su complejidad, tanto para ponerlos en marcha como para mantenerlos en el tiempo. Como siempre, no voy a hablar de unos y otros aquí (y como siempre, menos aún de los de la competencia :), así que cada uno puede analizar un poco la gama de productos disponibles para correlar y elegir el que mejor se ajuste a sus necesidades…
Estos dos problemas a los que hacemos referencia están causando que con frecuencia la correlación de las alertas procedentes de entornos no cooperativos -como, en muchas ocasiones, también las de entornos cooperativos- no se realice en un motor global, sino que se acabe haciendo correlación en el agente de monitorización: incluimos en el propio monitor cierta inteligencia para que, por sí mismo, sea capaz de generar alertas de mayor valor (a priori) de las que generaría sin esa inteligencia adicional, lo que podemos denominar correlación en origen. Así, si por experiencia sé que cuando aparece un detonante en una red social a principios de mes con un cierto formato no pasa nada porque es la agencia de publicidad distribuyendo noticias, en el propio agente encargado de vigilar esa red social pongo una condición para que si detecto el detonante con el formato correspondiente y además es principio de mes, no se genere una alerta. ¿Y por qué sé esto? Porque conozco el entorno y me ha pasado muchas veces, y por tanto he sido capaz de aprender… Igual que sé que si se produce un pico de CPU o determinado ataque entre dos máquinas internas los martes por la noche no pasa nada ni debo preocuparme, porque es el programa de copias haciendo un backup, y por tanto pongo una excepción o una ventana de mantenimiento en mi sistema de monitorización…
La correlación en origen no tiene por qué ser negativa; todo lo contrario, puede resultarnos muy útil para evitar la saturación de un motor central, permitiéndonos enviar a ese motor sólo la información relevante de un determinado monitor, pero por sí misma presenta alguna limitación. Para empezar, la inteligencia que aportemos debe implantarse agente a agente, sin tener la posibilidad -en términos generales- de distribuirla a un grupo de monitores, ya que estamos hablando de reglas o condiciones muy particulares. Esto motiva un elevado coste de mantenimiento, que si siempre supone un problema lo es aún más en los tiempos que corren… Pero además de este problema de mantenimiento, que podemos arreglar “simplemente” con dinero, hay un problema adicional en la correlación en origen exclusiva que los euros no arreglan, y es la imposibilidad obvia de que podamos relacionar datos generados por diferentes sensores: sin un mecanismo centralizado tenemos que conformarnos con un nivel básico de correlación en origen que muchas veces se limita a excepciones, ventanas y poco más, y luego podemos invertir tiempo en tratar de establecer relaciones o patrones de forma manual, viendo las alertas que se han ido generando en nuestro SIEM. Viendo estos problemas, parece obvio que la correlación en origen molestar no molesta, pero creo que estaremos de acuerdo en que necesitamos ese “algo” capaz de centralizar las alertas recibidas y aplicarles, mejor o peor, cierta inteligencia… Así que lo dicho: analicemos un poco el mercado, elijamos el motor de correlación que mejor nos encaje, despleguémoslo y a jugar :)
Llegados hasta aquí, ya hemos superado (más o menos :) el primer problema que indicábamos, el del motor de correlación: tenemos una plataforma capaz de, con el conocimiento que un humano pueda aportarle, o con el que ella misma sea capaz de inferir, correlar de una u otra forma las alertas recibidas. Además, lo conocemos a la perfección desde el punto de vista técnico y hablamos su lenguaje, con lo que podemos empezar a “insultarle” definiendo reglas… En este punto debemos enfrentarnos a nuestro segundo gran reto: ¿qué inteligencia le proporcionamos al correlador? Quizás es ahora cuando empiezan los problemas de verdad… El introducir conocimiento válido en un correlador es sin duda la parte que más nos va a costar (por muy caro o difícil a la hora de usarlo que sea el motor). Debemos ser capaces de identificar nuestro conocimiento del entorno, plasmarlo en reglas de correlación y desplegar éstas sobre el motor; vayamos por partes:
El conocimiento, en el mejor de los casos, suele estar disperso entre los miembros del equipo de seguridad que han desplegado los sensores para monitorización de entornos no cooperativos y que suelen ser también quienes atienden las alertas generadas (al menos en nivel 2). Y digo en el mejor de los casos porque otras veces ni siquiera existe: ¿cómo sé, de entrada, que un detonante en un foro es bueno o es malo? Probablemente una persona deba acceder al foro, revisar el histórico de conversaciones y, en función de lo que lea ahí, decidir si está delante de un falso positivo o por el contrario es una alerta a considerar… Difícil de plasmar en reglas de correlación, ¿no? El conocimiento del entorno es algo que, como siempre, debe ir afinándose poco a poco. Empezaremos con unidades de conocimiento muy básicas: si el usuario que habla de nosotros en Twitter está en una lista determinada, no generes alerta; si el detonante es pastebineado genera alerta crítica sin correlar nada más; si aparece el detonante en una página focalizada en el negocio, genera una alerta para otro área… En fin, lo que -muchas veces de forma casi inconsciente- están haciendo las personas que atienden las alertas recibidas desde los monitores de entornos no cooperativos… Conforme vayamos identificando unidades de conocimiento básicas, iremos traduciéndolas del lenguaje natural al que hable nuestro motor y las desplegaremos en el mismo para empezar a generar eventos más inteligentes… y de verdad que las reglas sencillas acaban aportando mucha inteligencia y nos ahorran una cantidad de tiempo más que considerable…
Cuando tenemos un cierto número de reglas básicas ya nos podemos enfrentar al siguiente reto: la correlación compleja, la generación de alertas de orden superior en función de la correlación de datos provenientes de múltiples fuentes. Aquí es donde se demuestra el potencial de un correlador: la correlación simple podíamos hacerla, mejor o peor, y con más o menos coste de mantenimiento, en origen, pero para llegar a relacionar datos de fuentes diferentes ya necesitamos algo más elaborado: ese motor de correlación del que hablábamos antes…
Si la correlación compleja es compleja (valga la redundancia :) en entornos cooperativos, a los que conocemos habitualmente mejor y de los que podemos sacar toda la información que necesitemos, en entornos no cooperativos la cosa es mucho más complicada; ¿cómo sé yo que la aparición significativa de un detonante en N entornos a la vez, o simplemente con una relación temporal definida, es buena, mala o simplemente que existe? Realmente, sólo puedo hacerlo de una forma: conociendo el entorno (o aprendiéndolo, aunque como decía antes esto son palabras mayores) a través, casi siempre, de la experiencia adquirida. Seguramente debo empezar con reglas de correlación compleja relativamente sencillas, al igual que hacía con la correlación simple, reglas que con el tiempo y el conocimiento adquirido iré mejorando y haciendo cada vez más valiosas…
Poco a poco, gracias a las reglas de correlación simple y compleja que voy a ir definiendo y mejorando, iré creando una base de datos de conocimiento capaz de aportar cada vez más inteligencia a mis sistemas de monitorización de entornos no cooperativos; llegados a este punto, nos queda ir ampliando el catálogo de entornos monitorizados, mejorar nuestras reglas y, en este caso especial, cruzar los dedos para que la fuente de datos no sufra cambios significativos que afecten a mi monitorización. Recordemos que estamos vigilando elementos fuera de nuestro control, con lo que en cualquier momento pueden desde cambiar el formato de emisión de información (con lo que nos tocaría cambiar nuestros elementos de adquisición de datos) hasta restringir su acceso de alguna forma o, simplemente, desaparecer. Ojo al control de errores en los monitores: no seríamos los primeros -ni los últimos probablemente- que creemos tener perfectamente monitorizada una fuente concreta y de repente nos damos cuenta, por un factor externo casi siempre negativo, de que no es así…. Validemos correctamente la información recibida para darla por buena en forma y tengamos especial consideración con los datos nulos o sencillamente con la ausencia de datos de un monitor que debería estar enviando…
Y si todo va bien… ¿ahora qué? Pues me queda, básicamente, dar valor a mi vigilancia: ser capaz de generar alerta temprana. Material para el próximo post de la serie :)
