28 octubre 2010

Sistemas de notificación de eventos ¿Renovarse o morir?

La semana pasada tuve que hacer una presentación en un gran cliente, que en el turno de preguntas, me cuestionaba, como muchos otros clientes, sobre las capacidades de integración y el tipo de mecanismos de notificación que permiten los productos de la empresa en que trabajo, lo cuál demuestra una vez más que, en el momento de adquirir una solución de seguridad, los requisitos de integración de los logs y alertas con las plataformas existentes en la casa, son muy importantes.

Las grandes organizaciones requieren que todos los dispositivos que tengan una IP, desde servidores, electrónica de red, equipos de seguridad y comunicaciones, hasta PCs, impresoras, tostadoras y cafeteras, envíen datos sobre lo que pueden considerar un "evento" a un sitio centralizado. Allí dicha información podrá ser tratada y gestionada convenientemente para priorizarla y comunicarla a quien corresponda según esté definido en la política de responsabilidades de la organización.

Muy de moda están por ello los sistemas de centralización de eventos de seguridad (o SIEM), de los cuáles ya hemos hablado alguna que otra vez en SbD a fin de poder obtener algo útil partiendo de un montón de fuentes que, si tuviéramos que leer todo lo que envían, el resultado sería inútil o nos sobrepasaría por la cantidad de recursos humanos necesarios para procesar tanta información.

Una vez decidimos si el mejor es OSSIM, NetIQ o ARC Sight (comprada por HP hace poco), lo que está claro es que un proyecto de esta envergadura, requiere definir muy claramente quién recibirá los "diamantes" pulidos en forma de notificación, cómo, cuándo y en qué canal. No es práctico, que por una caída puntual de una máquina se notifique a toda la jerarquía de una organización. Es vital tener en cuenta la criticidad de un evento para priorizar avisando a unos u otros, según corresponda. El mismo principio es aplicable a sistemas puros de monitorización de sistemas como Nagios o Cacti por ejemplo.

Tradicionalmente, los mecanismos de aviso estándar a los centralizadores/correladores de eventos, que suelen implementar los dispositivos son los siguientes:

  • Syslog: Cifrado o no. Es, posiblemente, el más estándar sistema de envío de eventos que cualquier centralizador es capaz de entender. Indica además el "recurso" (facility) origen que genera el evento y la "severidad" (severity) del mismo, indicando por supuesto una descripción del mismo.
  • SNMP: Protocolo utilizado desde los orígenes para leer/escribir en dispositivos basándose en la comunidad utilizada. Permitía configurar o preguntar a un dispositivo por su estado de forma síncrona o asíncrona. En el caso de las notificaciones, los "traps" SNMP permiten hacer llegar un mensaje a un servidor SNMP por parte de casi cualquier dispositivo de hoy en día. A lo largo del tiempo ha evolucionado en diferentes versiones que implementan mayores detalles de seguridad/autenticación para dar su funcionalidad.
  • Email: No puede considerarse un mecanismo de notificación tan sencillo de integrar en un sistema de centralización de eventos, pero sin embargo, resulta mucho más humano para notificar a personas (en cualquier nivel jerárquico) sobre diversos problemas. Es el mecanismo preferido por las empresas para alertar al personal de que algo pasa. Y puedo decir que he visto en más de un cliente la carpeta "Nagios" en el Outlook con cientos de correos sin leer.
  • SMS: Gracias a que las empresas se empeñan en regalar un teléfono a todo aquel empleado que compense pagarle la factura telefónica mientras lo puedan tener disponible 24 horas, muchos padres y madres de familia, reciben notificaciones a horas ajenas al horario laboral, que lógicamente han de subsanar. A veces no es tan sencillo justificar que le diste al "mute", que se te quedó en el coche, que se acabó la batería o que se lo comió el perro.
  • Pager/Busca: Aunque este mecanismo está completamente en desuso, siempre vemos en películas o series cómo al inspector, policía, médico o el bombero de turno, le suena el busca y tiene que salir corriendo. Me imagino que no será un "Máquina Urano está caida; Máquina Saturno entra en el Fail-over", pero es efectivo, porque lo ve y va a atender la emergencia.

Pero,… ¿dónde pasamos el resto del día?

Contando con que el busca lo usamos poco, y el uso del SMS suena exagerado para notificaciones de una prioridad que no sea muy elevada, en según qué momentos, así como por asegurarnos que nos llega la notificación aunque lo que falle sea el servidor de correo o el servidor SNMP, puede ser interesante recibir aviso de dichos eventos por diferentes canales como:

  • Mensajería instantánea: SbD cuenta con bots para las redes de MSN Messenger, Gtalk y Facebook que avisan, siempre y cuando estés en estado "Disponible" que se ha escrito un nuevo post, entre otras cosas. Diseñar un bot para la mensajería instantánea que se desee, que alerte a los destinatarios correctos ante determinados eventos abriéndoles una ventana puede resultar más que útil en aquellas organizaciones en las que la mensajería instantánea no está prohibida.
  • Prowl: En iPhone, las notificaciones automáticas, además de acortar la vida de la batería del mismo (efecto colateral), permiten tener un mecanismo bastante potente para recibir mensajes mediante la tarifa de datos. Prowl es una aplicación que se instala en nuestro teléfono y recibe, los mensajes. Para enviar los avisos, Prowl dispone de aplicaciones por línea de comandos que le otorgan grandes dosis de flexibilidad y potencia para mentes creativas.

Como conclusiones me gustaría destacar que:
  • En todos los mecanismos de notificación comentados, hemos de tener muy en cuenta que el abusar del número de avisos, puede dar lugar a problemas de saturación, tanto de las infraestructuras, como de los receptores humanos de los mismos, lo que hará que al principio se preste atención a eventos que no valgan para nada y que, con el paso del tiempo, se descarten notificaciones que deberían tener unas acciones más inmediatas.
  • Muchos de vosotros pensaréis que es una aberración enviar eventos cuyo contenido va en claro (sin cifrar) a Twitter, Facebook o Messenger. Sin embargo, los elementos que envían notificaciones tampoco suelen incorporar mecanismos de cifrado de correo de basado en PKI como PGP, ni siquiera cifrados con una clave conocida por ambas partes. Lo más normal es que la información a recibir es saber que un backup ha terminado correctamente, que un servicio no funciona, que una partición se está llenando, etc,… En general, y dada la nomenclatura utilizada para las máquinas, poco importa que otra persona sepa lo que le ha pasado a "Mortadelo", "Filemón", "Zipi" o "Zape"… En definitiva, se trata de recibir un aviso urgente, lo más rápidamente posible. Para comunicar secretos de Estado confidenciales, mejor usar otros canales, o cifrar la información, si no queremos que aparezcan en Wikileaks.
  • Por defecto, los dispositivos normales, siguen incorporando mecanismos de notificación clásicos (SNMP, Email, Syslog remoto); si queremos algo más sofisticado hay que utilizar una pasarela, que bien puede ser el consolidador/correlador de eventos, que permita enviar a diferentes roles, mediante diferentes canales, las notificaciones definidas. Es decir, que no incorporan de forma nativa el envío mediante canales más modernos de notificación o ejecutar un script personalizado que permita construir la notificación por el medio de nuestra elección.
  • ¿Qué hay de malo en redundar la notificación por varios canales? En caso de eventos críticos, de lo que se trata es de que me entere cuanto antes, ¿no? Además así, dotamos de alta disponibilidad el sistema de envío/recepción de mensajes. Si no tengo el correo abierto, pero sí Twitter o Messenger, me enteraré de que algo de lo que debería estar alertado ha sucedido, y lo haré cuanto antes, para poder reaccionar y minimizar el impacto en el tiempo.

4 comments :

Román Ramírez dijo...

(Divido el comentario en trozos, que me corta por longitud :) )


Los problemas principales que veo en los SIEM no pasan por que puedan o no notificar (ya sea push, pull).

Veo problemas de:

a) Precio sobredimensionado: es irracional que una puñetera plataforma de correlación de eventos tenga semejantes costes. Es tratar de forzar un mercado que no existe.

Que es una herramienta con almacenamiento, con base de datos (o ficheros, dependiendo de la solución) y un frontal. Y ya.

Que la correlación la haces a mano con IDEA-ACL, con Talend Open Studio, CON LA EXCEL...

En gran cuenta desplegar una máquina CUESTA, espacio con un LUN CUESTA, meter máquinas en un Data Center CUESTA... ¿y encima me quieres cobrar una salvajada por una herramienta con cuatro ventanas y dos gráficas?

Román Ramírez dijo...

(segundo)


b) Funcionalidades absurdas:

¿Para qué necesita una gran empresa que le integres un sistema de tickets en el SIEM? (por mucho que lo llames "Gestión del ciclo de vida del incidente")

El SIEM es un producto que solamente va a comprar una gran cuenta; y una gran cuenta va a tener, sí o sí, Remedy o cualquier mecanismo de gestión de tickets (uno de verdad).

Mejor dame más funcionalidades de integración con TSA, que yo pueda personalizar el cómo se firma y qué ...

Una entre muchas. La impresión que me da desde fuera es que los fabricantes disparan a todo lo que se mueve, a ver si aciertan por casualidad con algo...

c) Integración:

Cuesta la vida integrar la organización y, sumado con a), generas unos proyectos totalmente irreales.

Sí, es muy bonita esa venta de que "a largo plazo" la organización "explota" el SIEM... Sí, fijo.

Que se lo cuenten a diversas empresas que conozco, sí señor (que seguro que conoces tú también). Por cada ejemplo positivo tengo cinco negativos, cosa que no es una proporción muy sana...

Román Ramírez dijo...

(y tres)


d) Coste en servicios:

Ya entramos en los costes indirectos y no evidentes. Cuando ya tienes montado el "Moztruo" y estás integrando elementos.

Y, coño, ¿no sabías que las personalizaciones solamente las puede hacer un consultor certificado? Ah, ¿no te lo dijimos?

O, mira, nuestros partners gold son PEPE SOPORTE, CARLOS OPERADOR y PITITA SOC... ah, ¿que tienes otros? Pero es que los nuestros son éstos...


En general, el SIEM es un producto necesario y el mercado trata de convertirlo en una necesidad core de tu organización (para justificar un coste desmesurado).

¿No me sale más rentable coger Ossim Open, poner capas de integración y normalización intermedias que reduzcan y agrupen eventos? Si me pongo a calcular de memoria, en lo que me ahorro en costes de licencia, de hardware, costes no evidentes etc. me sale más rentable contratar a una empresa cojonuda de servicios y que me lo hagan todo.

Total, al final los voy a tener que contratar igual...

Román Ramírez dijo...

(Divido el comentario en trozos, que me corta por longitud :) )


Los problemas principales que veo en los SIEM no pasan por que puedan o no notificar (ya sea push, pull).

Veo problemas de:

a) Precio sobredimensionado: es irracional que una puñetera plataforma de correlación de eventos tenga semejantes costes. Es tratar de forzar un mercado que no existe.

Que es una herramienta con almacenamiento, con base de datos (o ficheros, dependiendo de la solución) y un frontal. Y ya.

Que la correlación la haces a mano con IDEA-ACL, con Talend Open Studio, CON LA EXCEL...

En gran cuenta desplegar una máquina CUESTA, espacio con un LUN CUESTA, meter máquinas en un Data Center CUESTA... ¿y encima me quieres cobrar una salvajada por una herramienta con cuatro ventanas y dos gráficas?