29 julio 2008

Sacándole el jugo a los IDS/IPS (II) - Configuración y afinamiento

En posts anteriores explicamos cómo llevar a cabo un despliegue de sondas IDS/IPS de la forma más óptima posible. Como lo prometido es deuda, en este post detallaremos cómo conviene configurar dichos elementos para que la información generada en forma de eventos de seguridad sea aprovechada por los Departamentos de Seguridad de las organizaciones.

La colección de dispositivos IPS/IDS con la que sembramos nuestra arquitectura de red anteriormente son capaces de enviar alarmas en caso de detectar/bloquear tráfico malicioso. En el momento de la configuración de dichos dispositivos (que traen una base de firmas genérica) se suele poner a registrar toda la actividad de la red durante un tiempo suficiente para obtener una muestra de suficiente calidad (generalmente una semana, aunque este tiempo puede variar). Esto se hace con el fin de evaluar los diferentes eventos detectados por las sondas IDS/IPS. A partir de aquí surgen dos posibles filosofías de afinamiento:

  • La primera sugiere afinar la política de alertas de red eliminando todos los falsos positivos, y eventos de severidad baja, de manera que solamente genere alertas en caso de ataques que puedan suponer un impacto importante para la organización. Esta filosofía también es conocida como “anomaly detection”. Así los operadores que reciban las alertas deberán poner en marcha un plan de contingencia para mantener el ataque bajo control.
  • La otra posible forma de configurar los IDS/IPS es afinar únicamente los falsos positivos y dejar todos los demás eventos activos, de manera que en caso de una intrusión, a la hora de realizar un análisis forense, contar con mucha más información para poder analizar los prolegómenos del ataque.

Ambas filosofías son muy opuestas en cuanto a la funcionalidad práctica (la segunda se hace ingestionable por recursos limitados en redes con mucha actividad), el mantenimiento y los costes de almacenamiento (a mayor verbosidad en el registro de eventos mayores necesidades de espacio en disco y mayor frecuencia de rotado de logs para poder manejar la información). Sin embargo la segunda posee como única ventaja el poder contar con un nivel de detalle excelente en casos post-mortem.

Según el ejemplo con el que contábamos en el posts anterior, teniendo mecanismos diferentes de IDS y de IPS, mi experiencia en estas lides me hace recomendar configurar los IPS de forma abnomally detection y los IDS en modo logging completo. De esta manera los IPS no tendrán que analizar una base de datos de ataques tan grande, priorizando también el rendimiento de los mismos, y los IDS guardarán datos de toda la actividad de red con un primer nivel de filtrado (por los IPS en caso de tráfico entrante/saliente).

En la siguiente entrega, aprovecharé para introducir un "juguete" nuevo en la infraestructura de seguridad de la compañía: los centralizadores/correladores de eventos.