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