Los IDS como herramientas analíticas
Sistemas de detección de intrusiones
Los sistemas de detección de intrusiones (IDS) pueden ser un complemento muy útil en el arsenal de seguridad de las empresas, al ayudar a detectar cómo y cuándo están siendo atacadas las redes. De la comparativa realizada por la Network Global Test Alliance de IDG entre tres distintas herramientas de este tipo, Proventia, de Internet Security Systems (ISS), resultó ser el mejor.
Todos los IDS no están indicados para todas las redes, pero cuando se instalan en el entorno correcto, y se les dedica el tiempo y la atención necesarias por el personal técnico, suponen una muy buena herramienta de seguridad. Así quedó probado en la evaluación de cinco de estos productos realizada por la Global Test Alliance de IDG, de la que en este resumen excluimos las conclusiones relativas a dos de ellos por no tener presencia en nuestro país. En concreto, se probaron soluciones de Internet Security Systems (ISS), Cisco Systems y NFR Security.
Las pruebas consistieron en el tratamiento del tráfico Internet en entornos reales durante 60 días, analizando, además de las simples funciones de detección, otros escenarios específicos con que los responsables de seguridad se suelen encontrar en su trabajo diario. Una de las conclusiones es que, pese a que los falsos positivos siguen siendo todavía un problema, los fabricantes han avanzado mucho durante el último año en la gestión de las falsas alarmas.
En general, quedó patente que cada producto está indicado para un tipo de necesidades distintas. Así, ISS ofrece el kit de herramientas de análisis y gestión más potente, mientras que Cisco aporta una gran flexibilidad gracias a sus sensores, así como una estrecha integración entre sus routers y conmutadores. NFR, por su parte, es el mejor cuando lo que se desea es escribir nuestras propias firmas de ataques.
¿Qué está pasando?
Antes de las epidemias de virus producidas durante el pasado mes de agosto, uno de los sistemas Windows 2000 protegidos por IDS y utilizados en las pruebas fue atacado y estuvo siendo utilizado como un “zombie” para escanear otros sistemas. Y se quiso saber quién lo atacó y cómo.
La mayoría de los productos se distinguen por ofrecer funciones de alertas o funciones de análisis. Los primeros, llaman la atención sobre los eventos de alta prioridad recientes, mientras que los segundos permiten realizar la “autopsia” del problema para averiguar sus causas. Y algunos sistemas se ciñen a este modelo de una manera radical, poniendo una barrera entre ambos tipos de funciones. Los de NFR y Cisco (la consola de alertas Cisco Threat Response –CTR– basada en la tecnología adquirida con la compra de Psionics a principios de año) se inscriben en esta categoría. Sin embargo, ISS y la IDS Management Console original de Cisco no establecen diferencias entre las dos clases de análisis.
ISS no distingue entre alertas y análisis, pero sin embargo ofrece vistas diferentes de los mismos datos en su SiteProtector, la herramienta de gestión y análisis de la información recogida por su suite de herramientas de seguridad. Una poderosa característica es su función de sumarización automática: los eventos se agrupan siempre que es posible para reducir el tamaño del informe. Resultó sencillo confirmar que el sistema Windows fue atacado y cuándo se produjo el ataque.
Para pasar de la pantalla “cuándo” a la del “cómo”, hay que copiar la dirección IP, pegarla en la misma pantalla y seleccionar una visualización diferente de los datos. En ocho segundos aparece la respuesta. Parece simple, pero no se encontró una función tan sofisticada en otros productos para clasificar y averiguar datos.
De la corta lista de eventos de SiteProtector, seis aparecieron como de alta prioridad. Las potentes capacidades de análisis permiten identificar a los atacantes y ver además lo que podrían haber estado haciendo. Y lo que es más importante, la herramienta de gestión de ISS permite a los administradores de redes descargar los eventos más importantes en una carpeta de “incidentes” y generar con gran rapidez una lista de items de acciones de investigación para cualquier nodo. La interrelación entre los eventos y la base de datos X-Force, con enlaces a explicaciones y localizaciones de parches, proporciona una excelente manera de empezar a investigar el problema.
¿Cómo está pasando?
La interfaz de NFR diferencia radicalmente la información sobre alertas y los análisis. En las firmas de ataques del producto, la firma elige cuándo enviar una alerta o grabar la información en la base de datos, e incluso cuándo ambas acciones resultan apropiadas. Comenzando con la parte de alertas, se clasificó por direcciones IP fuente y no se descubrió nada. Por defecto, NFR sólo muestra mil alertas, pero se ajustó esa cifra a 10.000 items, y llevó 85 segundos refrescar la pantalla; cuando los items se incrementaron a 20.000, el refresco de pantalla tardó cinco minutos. Finalmente, se verificó que el sistema Windows había sido atacado y se procedió a la dura tarea de ver cómo.
En pocas palabras, hay que decir que es imposible “hacer preguntas” al producto de NFR. Cuando se están filtrando alertas, no se le puede pedir que muestre todas las que tengan como destino una dirección IP determinada. Es posible obtener todas las alertas durante un periodo de tiempo determinado y clasificarlas por direcciones IP de destino, pero no es posible entresacar la lista de alertas que justo se desea conseguir. Esto resultó un poco desconcertante, pero se pensó que se obtendría el resultado pretendido en la parte de análisis del producto. Pero tampoco en este apartado es posible.
Se finalizó con una enorme pila de alertas irrelevantes qué hubo que escrutar para saber qué había sucedido con el sistema Windows atacado.
Con CTR de Cisco, se consiguen vistas por evento, fuente y destino, pero no resulta sencillo pasar de una a otra. Se puede averiguar el momento del inicio de los ataques y ver entonces quiénes lo están llevando a cabo, pero la tarea requiere mucha más navegación mediante la interfaz gráfica que con cualquier otro producto de los probados. Las visualizaciones preprogramadas no hacen posible entresacar visualizaciones por periodos concretos (aunque si clasificarlas por este factor), ni tampoco emparejar con rapidez fuente y destino. Como CTR muestra exclusivamente datos de alertas, sólo es posible ver la mano la información reciente; es decir, cuando se quieren hacer consultas de análisis hay que pasar a otra herramienta, IDS Monitoring Center, suministrado como parte de la plataforma de gestión CiscoWorks. Como IDS Monitoring Center precede a CTR, puede actuar también como una interfaz “todo en uno” tanto para manejar alertas como para realizar investigaciones de análisis.
Anulando las falsas alertas
A diferencia de la comparativa de IDS publicada en el número 170 de Comunicaciones World, correspondiente a septiembre de 2002, que se centró en las falsas alarmas generadas por estos sistemas, en esta ocasión el foco estuvo en la facilidad y rapidez con que se pueden analizar las listas de alertas. Los responsables de seguridad se acercan al problema con dos enfoques: mientras unos quieren ver todas las alertas, otros sólo desean ver las que ofrecen la información más útil. La cuestión se centr&
Todos los IDS no están indicados para todas las redes, pero cuando se instalan en el entorno correcto, y se les dedica el tiempo y la atención necesarias por el personal técnico, suponen una muy buena herramienta de seguridad. Así quedó probado en la evaluación de cinco de estos productos realizada por la Global Test Alliance de IDG, de la que en este resumen excluimos las conclusiones relativas a dos de ellos por no tener presencia en nuestro país. En concreto, se probaron soluciones de Internet Security Systems (ISS), Cisco Systems y NFR Security.
Las pruebas consistieron en el tratamiento del tráfico Internet en entornos reales durante 60 días, analizando, además de las simples funciones de detección, otros escenarios específicos con que los responsables de seguridad se suelen encontrar en su trabajo diario. Una de las conclusiones es que, pese a que los falsos positivos siguen siendo todavía un problema, los fabricantes han avanzado mucho durante el último año en la gestión de las falsas alarmas.
En general, quedó patente que cada producto está indicado para un tipo de necesidades distintas. Así, ISS ofrece el kit de herramientas de análisis y gestión más potente, mientras que Cisco aporta una gran flexibilidad gracias a sus sensores, así como una estrecha integración entre sus routers y conmutadores. NFR, por su parte, es el mejor cuando lo que se desea es escribir nuestras propias firmas de ataques.
¿Qué está pasando?
Antes de las epidemias de virus producidas durante el pasado mes de agosto, uno de los sistemas Windows 2000 protegidos por IDS y utilizados en las pruebas fue atacado y estuvo siendo utilizado como un “zombie” para escanear otros sistemas. Y se quiso saber quién lo atacó y cómo.
La mayoría de los productos se distinguen por ofrecer funciones de alertas o funciones de análisis. Los primeros, llaman la atención sobre los eventos de alta prioridad recientes, mientras que los segundos permiten realizar la “autopsia” del problema para averiguar sus causas. Y algunos sistemas se ciñen a este modelo de una manera radical, poniendo una barrera entre ambos tipos de funciones. Los de NFR y Cisco (la consola de alertas Cisco Threat Response –CTR– basada en la tecnología adquirida con la compra de Psionics a principios de año) se inscriben en esta categoría. Sin embargo, ISS y la IDS Management Console original de Cisco no establecen diferencias entre las dos clases de análisis.
ISS no distingue entre alertas y análisis, pero sin embargo ofrece vistas diferentes de los mismos datos en su SiteProtector, la herramienta de gestión y análisis de la información recogida por su suite de herramientas de seguridad. Una poderosa característica es su función de sumarización automática: los eventos se agrupan siempre que es posible para reducir el tamaño del informe. Resultó sencillo confirmar que el sistema Windows fue atacado y cuándo se produjo el ataque.
Para pasar de la pantalla “cuándo” a la del “cómo”, hay que copiar la dirección IP, pegarla en la misma pantalla y seleccionar una visualización diferente de los datos. En ocho segundos aparece la respuesta. Parece simple, pero no se encontró una función tan sofisticada en otros productos para clasificar y averiguar datos.
De la corta lista de eventos de SiteProtector, seis aparecieron como de alta prioridad. Las potentes capacidades de análisis permiten identificar a los atacantes y ver además lo que podrían haber estado haciendo. Y lo que es más importante, la herramienta de gestión de ISS permite a los administradores de redes descargar los eventos más importantes en una carpeta de “incidentes” y generar con gran rapidez una lista de items de acciones de investigación para cualquier nodo. La interrelación entre los eventos y la base de datos X-Force, con enlaces a explicaciones y localizaciones de parches, proporciona una excelente manera de empezar a investigar el problema.
¿Cómo está pasando?
La interfaz de NFR diferencia radicalmente la información sobre alertas y los análisis. En las firmas de ataques del producto, la firma elige cuándo enviar una alerta o grabar la información en la base de datos, e incluso cuándo ambas acciones resultan apropiadas. Comenzando con la parte de alertas, se clasificó por direcciones IP fuente y no se descubrió nada. Por defecto, NFR sólo muestra mil alertas, pero se ajustó esa cifra a 10.000 items, y llevó 85 segundos refrescar la pantalla; cuando los items se incrementaron a 20.000, el refresco de pantalla tardó cinco minutos. Finalmente, se verificó que el sistema Windows había sido atacado y se procedió a la dura tarea de ver cómo.
En pocas palabras, hay que decir que es imposible “hacer preguntas” al producto de NFR. Cuando se están filtrando alertas, no se le puede pedir que muestre todas las que tengan como destino una dirección IP determinada. Es posible obtener todas las alertas durante un periodo de tiempo determinado y clasificarlas por direcciones IP de destino, pero no es posible entresacar la lista de alertas que justo se desea conseguir. Esto resultó un poco desconcertante, pero se pensó que se obtendría el resultado pretendido en la parte de análisis del producto. Pero tampoco en este apartado es posible.
Se finalizó con una enorme pila de alertas irrelevantes qué hubo que escrutar para saber qué había sucedido con el sistema Windows atacado.
Con CTR de Cisco, se consiguen vistas por evento, fuente y destino, pero no resulta sencillo pasar de una a otra. Se puede averiguar el momento del inicio de los ataques y ver entonces quiénes lo están llevando a cabo, pero la tarea requiere mucha más navegación mediante la interfaz gráfica que con cualquier otro producto de los probados. Las visualizaciones preprogramadas no hacen posible entresacar visualizaciones por periodos concretos (aunque si clasificarlas por este factor), ni tampoco emparejar con rapidez fuente y destino. Como CTR muestra exclusivamente datos de alertas, sólo es posible ver la mano la información reciente; es decir, cuando se quieren hacer consultas de análisis hay que pasar a otra herramienta, IDS Monitoring Center, suministrado como parte de la plataforma de gestión CiscoWorks. Como IDS Monitoring Center precede a CTR, puede actuar también como una interfaz “todo en uno” tanto para manejar alertas como para realizar investigaciones de análisis.
Anulando las falsas alertas
A diferencia de la comparativa de IDS publicada en el número 170 de Comunicaciones World, correspondiente a septiembre de 2002, que se centró en las falsas alarmas generadas por estos sistemas, en esta ocasión el foco estuvo en la facilidad y rapidez con que se pueden analizar las listas de alertas. Los responsables de seguridad se acercan al problema con dos enfoques: mientras unos quieren ver todas las alertas, otros sólo desean ver las que ofrecen la información más útil. La cuestión se centr&
