Correlación de Eventos (Gestión de eventos de Seguridad)

Presentación del tema: "Correlación de Eventos (Gestión de eventos de Seguridad)"— Transcripción de la presentación:

1 Correlación de Eventos (Gestión de eventos de Seguridad)
Pablo Ruiz García - Julio de 2003 Interacción

2 John Q. Walker (NetIQ Corp.)
[...] Many computers and network devices keep logs of the events they encounter. These events are usually very specific to a certain operating system, application, or network component. When intruders attack any part of a computer network, it’s likely that telltale signs are left behind, written as events to the logs of the computers on the front line of the attack. You’d like to see these events as they are occurring, rather than going back to each system weeks later and dumping its system logs. You’d like to have the events from different systems correlated, to detect broad attacks. You’d like the log data to be consolidated and synchronized, so you can see what is happening where. Most important, you’d like to generate automated responses to intrusions, corresponding to the security policies you’ve established in your organization. These are the topics addressed by products that perform “security event correlation.” [...] John Q. Walker (NetIQ Corp.)

3 Gestión de intrusiones – Realidad de mercado
El mercado de la seguridad se mueve a dia de hoy hacia la prevención de los ataques y las intrusiones donde sea posible mientras se supervisan, manejan y procura responder a los acontecimientos críticos de la seguridad Mucho de ese esfuerzo se ha enfocado en comprar y desplegar productos basados en la detección de la intrusión en red, pero con resultados generalmente insatisfactorios A día de hoy los actuales sistemas de seguridad corporativos (IDS’s, fw’s, etc.) adolecen de una falta de integración en los procesos de gestión de las empresas El nivel de exposición de las empresas a ataques (no solo de imagen) en Internet es cada año mayor, el numero de ataques aumenta cada año, no solo en numero, sino en sofisticación Debido a este aumento constante del nivel de exposición, las empresas sufren de ataques, intrusiones y violaciones de seguridad que aumentan de una manera que no se había observado nunca Espías industriales..

4 Gestión de intrusiones - Futuro
En palabras de Pinkesh Shah, director de PentaSafe Inc: “IDS must evolve beyond its point product tradition and encompass a new level of management capabilities. Companies have to focus on managing events, correlating them, and responding to them in real time.” La correlación de eventos es una parte fundamental de la gestión de eventos de seguridad y su automatización e integración con el resto de procesos puede facilitar mucho la operación eficiente de las empresas

5 Gestión de Intrusiones - ¿qué es?
Esta integración entre seguridad y gestión es lo que se llama “Intrusion Management “ y esta divido en varias areas: Vulnerability management Intrusion detection Security Event Management Incident Response (fuente Giga Information Group) Esta integración entre los dispositivos de seguridad y los procesos de operación corporativos es lo que se llama “Intrusion Management “ Vulnerability management: La habilidad de comprender a que es vulnerable una organización y como impactarian dichas vulnerabilidades en el negocio si fueran explotadas Intrusion detection: El proceso de identificar incidentes de seguridad en puntos concretos (pe: un servidor, una aplicación) Security Event Management: La habilidad de consolidar múltiples datos sobre incidentes y eventos de seguridad relacionándolos para identificar el impacto y alcance de un incidente de seguridad en la operativa del negocio Incident Response: El proceso de reaccionar de manera correcta ante un incidente cuando el objetivo sea reparar este o hacer responder a los perpetradores del mismo.

6 Antecedentes La correlación de eventos apareció inicialmente en las herramientas de gestión y monitorización de redes, en especial para evitar los típicos “Event Storms” ocurridos tras la caida de algun dispositivo critico, pe: HP OpenView/ECS ECS & Cisco Tivoli Event Correlation & Automation Muchas veces en el mercado de la seguridad se hace camino “reinventando” la rueda, o fijandose en la forma de proceder de otros mercados predecesores.. Aunque resulta mucho mas practica en seguridad, debido al que en seguridad muchos eventos suelen referirse a un solo suceso, mientras en gestión de red, una alarma indica un fallo concreto. Sin embargo, es una tecnología mucho mas practica en seguridad, donde generalmente varios eventos indican un único “problema”.

7 ¿Que significa Correlación?
Relación recíproca o mutua entre dos o más entidades comparables en un determinado periodo de tiempo. Existencia de mayor o menor dependencia mutua entre dos variables aleatorias. (Seguridad): La agrupación de múltiples elementos individuales para la determinación de ataques o situaciones anómalas en los diferentes elementos de la arquitectura corporativa. (Estadística): El cambio simultaneo del valor de dos variables aleatorias aparentemente no relacionadas. Ejemplo de correlación: Relación entre el aumento de CO2 en la atmósfera y el aumento de temperatura (o al revés). Ejemplo de correlación estadística: La relación directamente proporcional entre el consumo de tabaco y la incidencia de cáncer de pulmón. Algunas definiciones son de diccionary.com

8 ¿Por qué es necesaria la correlación de eventos? I
Check Point Necesidad de integración: múltiples plataformas y sistemas de diferentes fabricantes con formatos de información y registro diferentes. Excesivas cantidades de datos (logs) que son difíciles de procesar, o que limitan la efectividad de los equipos de investigación de incidentes. El trafico de Internet, los gusanos y los scripts de automatización de ataques causan grandes cantidades de falsos positivos y de eventos de seguridad en firewalls y sistemas de detección de intrusos. Tanto los grandes volúmenes de datos, como los falsos positivos causan una gran perdida de tiempo (y recursos) en análisis. Microsoft OS/390

9 ¿Por qué es necesaria la correlación de eventos? II
Falta de metodologías para la revisión de logs La correlación puede indicarnos “que existe un problema” aunque no se puede identificar el problema en concreto Necesidad de una visión horizontal de la seguridad de todos los sistemas. (En especial de cara a dirección) Visión horizontal incluso de los sistemas de varias empresas, pe: Managed Security Services o Security Providers) (El uso de reglas de correlación y el estudio del comportamiento de los sistemas ayudan a crear una metodología propia) Correlación de anomalias (muy normal en correlación estadistica)

10 ¿Qué información se puede utilizar en la correlación? I
Registros de seguridad/Auditoria: Firewalls Antivirus Sistemas de detección de intrusos Herramientas de filtrado de contenidos Herramientas de búsqueda de vulnerabilidades Información de análisis de seguridad “Manual” Registros de sistema/comunicaciones: Unix Syslog. NT Eventlog. Routers, switches, etc. Proxy’s. Información de aplicativos: Aplicaciones Corporativas (Aplicaciones propias) Mail, Servidor Web, DNS, etc. NT EventLog OPSec? Eso incluye mucho mas que cortafuegos de una manera ordenada. Información de análisis de seguridad “Manual” -> Hacking manual, información por parte de fabricante.. Etc.

11 ¿Qué información se puede utilizar en la correlación? II
Información de herramientas de gestión ¡Inventario! Gestores SNMP (HPOV, Tivoli, etc.) Información externa Security Focus (Vuln. DDBB) Security Providers Información de fabricantes (Advisories) Otras herramientas de correlación ¡Históricos! Datos de correlación históricos Métricas de red y comunicaciones Métricas de rendimiento de sistemas Información Interna Call center Administradores Una gran empresa no puede pasar sin un inventario donde estén categorizados sus activos y aparezcan las dependencias entre activos (¿Análisis de riesgos?) Mantener un inventario actualizado... y con detalles (parches, criticidad, dependencias) Responsables de cada dato en inventario. El flujo de información puede ser circular, un sistema de correlación, se puede alimentar perfectamente de los datos proporcionados por otros. Los históricos son fundamentales para la correlación estadística y pueden ser perfectamente dinámicos y automáticos Además son parte fundamental para la creación de cuadros de mando (Herramientas fundamentales para dirección y para la visión completa desde el punto de gestión)

12 Requisitos – ¿Que necesita un sistema de Correlación?
Centralización de logs y eventos Reducción de la información a tratar Motor de correlación Explotación del sistema Control de cambios Continuidad

13 Requisitos - Centralización de logs y eventos I
Cuanta mas información, ¡mejor! (siempre siendo coherente con los posibles problemas de rendimiento asociados) Es necesario un análisis global a todos los entornos implicados para determinar como “extraer” la información de cada Es importante tener en cuenta que se va a extraer información de dispositivos de diferentes departamentos y entornos, con políticas y necesidades diferentes Transporte y almacenamiento seguro de los datos a procesar: Seguridad de que los datos no se han perdido Seguridad de que los datos no han sido alterados Ciertos datos se deben tratar conforme a la ley (LOPD) Centralización de datos proporcionando Confianza en que los datos no se han perdido o alterado (pe: Syslog es falseable y carece de cifrado) Generalmente los departamentos de una empresa suelen estar enfrentados entre si, generandose muchos problemas de integración. Además Los logs nunca deben tratarse en la maquina que los genero. (Y menos aun conservarlos en ellas) Esta centralización se suele realizar mediante un agente en cada servidor (o un agente para cada grupo de servidores [syslog])

14 Requisitos - Centralización de logs y eventos II
Todas las maquinas involucradas deben mantener sus fechas sincronizadas. El sistema donde se almacenen centralizados los datos se debe considerar “critico” y debe ser tratado como tal Es fundamental conservar únicamente las partes útiles de cada formato de “log” de diversos dispositivos (reducción de datos) El formato de “log” final debe ser los suficientemente dinamico y extensible para poder añadir diferentes tipos de datos a lo largo de la vida del sistema de correlación Consolidación de los datos unificados en un único punto (Generalmente una BBDD relacional que facilite su acceso)

15 Requisitos - Reducción de la información a tratar
Eliminación de duplicados Filtrar eventos similares Sumarización/Compresión de eventos ¡Cuidado! los “logs” modificados pueden no ser validos judicialmente: Almacenamiento o Backup paralelo de los logs originales Las partes de unificación y “reducción” de información, pueden realizarse tanto en el “agente” instalado en el servidor y que se encarga de recolectar logs, como en la consola/management del sistema de correlacion (o en la propia BBDD). E incluso algunos productos permiten elegir realizar estas tareas en ambos puntos, (una tareas en concreto en un puto y otras en otro) Algunos sistemas de correlación no implementan filtrado, usando una politica mas extensiva basada en que se debe trabajar siempre con todos los datos para no correr el riesgo de perder información, pero esto obliga al motor de correlación a trabajar con volumenes de datos mucho mayores. La normalización y el filtrado no siempre tienen por que hacerse en ese orden. El problema que se implica en esto es la dificultad de usar un “log” modificado como evidencia legal

16 Requisitos – Motor y Explotación
Motor de correlación Explotación del sistema El uso del sistema requiere de entrenamiento y conocimiento de las plataformas involucradas, así como del lenguaje para la creación de nuevas reglas de correlación Integración con el workflow de operación de la empresa Necesidad de soporte (Partner Tecnológico) Es posible integrar un sistema de correlación con el sistema de gestión de mantenimiento corporativo, realizándose la actualización de parches y software como petición del sistema de correlación ante un evento de seguridad o ante la aparición de una nueva vulnerabilidad o “advisory”. El equipo de explotación del sistema puede ademas reforzarse con un buen soporte de nivel 4 proporcionado por un partner de seguridad O una empresa de integración que ofrezca dicho servicio.

17 Requisitos – Control de cambios y Continuidad
En algunos casos y por diferentes motivos, puede ser necesario “asumir” una vulnerabilidad, para esto, puede ser necesario el uso del inventario o de historicos Continuidad Reingeniería de procesos: Cada nuevo desarrollo dentro de la compañía debe tener en cuenta su integración en el sistema de correlación La definición del formato, tratamiento y almacenamiento de logs debe ser una fase mas a tener en cuenta dentro de los proyectos de la empresa.

18 Correlación múltiple:
Tipos de Correlación Micro Correlación: Comparar datos de mismo tipo generados por diferentes fuentes. (Buscar todos los eventos de una misma dirección IP) Correlación atómica: Tipo de micro correlación que se realiza sobre un mismo tipo de dato no normalizado Macro Correlación: Comparar múltiples tipos de datos de diferentes sistemas. (Comparar un evento generado por un IDS con el informe de un escáner de vulnerabilidades) Correlación múltiple: Aplicar los otros tipos de correlación en fuentes de datos generados por múltiples compañías (Managed Services) La correlación atómica es generalmente usada para correlar datos de carácter estadístico (métricas etc.)

19 Micro correlación Correlación de Campos – Correlar eventos dado un unico o multiples “campos” dentro de los datos normalizados. (Todos los eventos de una misma dirección IP y/o destinados al puerto 80) Correlación mediante reglas o patrones – Correlacion de un cojunto de eventos relacionables mediante reglas y patrones preestablecidos en un unico “evento” de seguridad. (Aunar multiples eventos de apertura de puertos [paquetes SYN] como un unico PORTSCAN) Correlación de firmas – El tipo de correlación de utiliza un IDS, comparar datos sospechosos con patrones predefinidos como “maliciosos”

20 Macro Correlación I Correlación de Vulnerabilidades – Asociar los eventos detectados por un IDS a las alertas de seguridad generadas por una herramienta de analisis de vulnerabilidades (o a las alertas generadas por un servicio de alerta automatico, pe: Security Focus) Correlación de Perfiles – Comparar los eventos sucedidos en un momento determinado con los eventos originados por ataques en el pasado (Event Sequence) Correlación Estadística – Correlar metricas actuales con sus equivalencias historicas en diferentes periodos de tiempo. (Comparar el numero de logins fallidos en un entorno entre el ultimo mes y el mes actual) Correlación de vulnerabilidades: Correlación de perfiles: requiere de históricos (y quizás de un perfil de explotación que haga la clasificación y categorización de dichos perfiles) Correlación mediante listas: necesario históricos.. xD, otro ejemplo: comparar el numero de paquetes “dropeados” en el firewall con un historico de estos mismos datos. Correlación estadistica: se registran metricas durante ciertos periodos de tiempo, para obtener una media de cada periodo (este se llama umbral de confianza) a partir de dicho umbral se puede delimitar si el indicador actual de la metrica es “normal” o existen indicios de peligro

21 Macro Correlación II Correlación mediante listas – Correlacionar los eventos normalizados con una serie de listas “predefinidas” de anteriores “atacantes”. Dichas listas se actualizan automaticamente con cada nuevo incidente de seguridad (pe: analizar las direcciones IP de los eventos con una lista de “atacantes conocidos”) Correlación dirigida a eventos – Es la que utiliza información de cualquier fuente pertinente como medio para ayudar en el diagnostico, resolución o prioritización del evento. (el uso de un inventario para asignar prioridades a los eventos de seguridad según la criticidad del entorno al que afecten)

22 ¿dónde tiene sentido el uso de la Correlación?
Cualquier persona dando soporte y gestión a mas de un dispositivo de seguridad (o de red): Proveedores de seguridad gestionada Grandes empresas (especialmente las tecnológicas) Entidades estatales con mucha infraestructura IT Entornos críticos con infraestructura de seguridad Cuanto mas grande y heterogénea sea una compañía, mas útil es el uso de la Correlación Cuanto mas grande y heterogenea sea una compañía, mas util es el uso de Correlación y esto se da a todos los niveles, micro correlación, macro correlación, etc.

23 Ejemplo funcional Ante el ataque de un gusano como el “CodeRed” a alguna de las redes de la empresa, varios sistemas empiezan a generar información: El firewall genera eventos informando de conexiones dirigidas al puerto 80 de diferentes direcciones IP, algunas de estas conexiones son denegadas (dropped) y algunas consiguen acceder hasta los servidores Web de nuestra empresa El NIDS avisa del intento de ataque de la vulnerabilidad “IIS-IDQ” en algunos de nuestros servidores Web Cada Servidor Web afectado registra en sus ficheros de “log” las conexiones del ataque y su codigo de respuesta pertinente El HDIS también registra los intentos de ataque registrados por el servidor Web en su fichero de Log. Adicionalmente, debido a la configuración de red, el servidor Web tiene un direccionamiento interno, pero se publica con direccionamiento publico mediante NAT, lo cual hace que algunos de estos eventos tengas direcciones de destino diferentes.

24 Code Red 1 Servidor Infectado 2 ...N
Vitim.com Servidor Infectado Internet HIDS FTP WWW DNS 1 Servidor Infectado con “CodeRed” tratando de Infectar IPs de “vitim.com” NIDS 2 El firewall genera una entrada en de “log” para cada conexión: Jul 17 17:35:29 fw RULE 14 - ACCEPT SRC= :4457 DST= :80 TCP Jul 17 17:35:30 fw RULE 32 - DROPED SRC= :4458 DST= :80 TCP Jul 17 17:35:31 fw RULE 32 - DROPED SRC= :4459 DST= :80 TCP Jul 17 17:35:32 fw RULE 32 - DROPED SRC= :4460 DST= :80 TCP [...] El servidor Web responde a las peticiones y las registra: [17/Jul/2003:17:35: ] "GET /default.ida?XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u9090%u8190%u00c3%u0003%u8b00%u531b%u53ff%u0078%u0000%u00=a HTTP/1.0" "-" "-“ [...] ...N El sistema de detección de intrusos detecta los ataques (tanto por red): :35:29|NIDS|WEB:IIS-IDA| | |4457|80|T||6|tcp| (Como en los logs) :35:29|HIDS|HOST:IIS-IDA| | |4457|80|T|||log| [...] Por no hablar de los eventos generados por los “HIDS”. Falta de identificación unica (problema del NAT) Todo esto sin incluir el antivirus ni otros posibles logs utiles. IDS Server Existe demasiada información sobre el mismo evento en diferentes lugares y con diferentes formatos ¡Perdida de tiempo y recursos! Facilidad para que la información importante pase inadvertida Analista

25 Correlación Todos los eventos del Firewall relativos a este ataque pueden valorarse de manera conjunta La correlación de la información sobre el servidor Web almacenada en el inventario permite: Determinar si el servidor a sido infectado o no en base al sistema operativo de la maquina y su nivel de parcheado (pe: Si es apache, no es posible que la vulnerabilidad le afecte, de modo que se ignora) Determinar la criticidad del incidente en base al impacto en el negocio del servidor en cuestión (Un incidente en el portal principal de la compañía debe de gozar de la máxima prioridad) Determinar la dependencia de otros entornos en este servidor, de nuevo ayudando a determinar la criticidad de este incidente Relacionar *todos* los eventos del ataque como uno solo aunque estos tengan direcciones IP diferentes, puesto que en el inventario todas esas direcciones están asignadas al mismo dispositivo Todo esto sin incluir el antivirus ni otros posibles logs utiles, sobretodo en caso de contagio.

26 Correlación II Determinar la criticidad del evento en función de la criticidad de la vulnerabilidad, mediante fuentes como Security Focus, CAN o CERT y sus BBDD pertinentes (esto permite priorizar diferente si el incidente es un DoS, permite tomar el control remoto del sistema o por contrario únicamente permite conocer información del sistema operativo [path’s, versiones etcetc]) Se puede crear una relación de actividades ocurridas durante el ataque en orden cronológico, para utilizara como un “perfil” de ataque en posteriores incidentes El uso de un scanner de vulnerabilidades permite conocer en el momento si la vulnerabilidad explotada afecta al servidor, siempre y cuando el scanner tenga un “checker” para dicha vulnerabilidad Adicionalmente, de existir una integración entre el sistema de correlación y el sistema de gestión de operación de la empresa, el tratamiento de la incidencia se incluiría automáticamente como una actividad a realizar por el personal adecuado. (pe: si existiera contagio de CodeRed, automáticamente se genera un ticket para que algún técnico de sistemas elimine el virus) La correlación con un scanner de vulnerabilidades puede ser activa o passiva.

27 Que mas proporciona la Correlación
Otros beneficios directos son: Analizar los incidentes determinando sus posibles causas, para mejorar la seguridad global de la empresa Obtener una visión histórica y actual de la seguridad y del numero y tipo de incidentes permitiendo justificar las inversiones en seguridad Obtener una visión completa de la seguridad de la compañía desde un único punto y en tiempo real Centralizar los eventos de seguridad en un único punto, para facilitar su tratamiento y acceso Facilita la capacidad para responder a un incidente en el mayor tiempo posible con toda la información necesaria Incrementa la eficiencia y disminuye los costes Permite escalar y gestionar mucha infraestructura distribuida Calcular el ROI de seguridad de algunas inversiones.

28 Sistemas Informáticos Abiertos (SIA) PentaSafe eSecurity GuardedNet
Fabricantes Sistemas Informáticos Abiertos (SIA) PentaSafe eSecurity GuardedNet Intellitactics ISS SiteProtector NetForensics OPEN OpenSystems A dia de hoy para muchos fabricantes confunden recolleción y centralización de logs con “correlación”. Algunos otros no quieren mezclar sus productos con herramientas de gestión o inventario, por lo cual se hace necesario el uso de integradores.

29 Reducción de costos y aumento de eficiencia
Conclusiones Reducción de costos y aumento de eficiencia Mejora en la gestión de recursos Eliminar los costos asociados con incidentes de seguridad Paradas de servicio, imagen, etc. Maximizar al máximo el uso de la infraestructura de seguridad actual Aumentar el conocimiento de seguridad global de la compañía

30 ¡GRACIAS! ¿Preguntas? Agredicimientos a la organización, a nicolas y a los asistentes

31 Ejemplo Deemostración de reducción de eventos de un fallo de autentificación, al eliminarse los duplicados generados por el IDS (sensor de Host + Sensor de Red) y por el propio servidor WWW. Generando un “unico” evento de toda esta información y para *todos* los fallos de autentificación. [Grafico]

32 Ejemplo de correlación
Ataque de un gusano detectado por el IDS (NIDS y HIDS) y por el servidor WWW y que mediante su correlación con el Inventario (e incluso puede que con una herramienta de vulnerabilidades) se establece si es un “falso positivo” o no, y su criticidad o impacto en el negocio (gracias a los datos del inventario). Puede incluso que poner varios IDSs sea util. Adicionalmente, los logs del server WWW indican el agente y plataforma desde la que se lanzo el ataque (links/linux)

33 Ejemplo de correlación Anomala
Ataque de autentificación distribuido; se detectan multiples fallos de autentificación desde diferentes fuentes de modo que el numero total de eventos de “fallo de autentificación” superan el “limite de confianza” (que puede ser ‘dinamico’ o ‘preestablecido’) en fallos de autentificación diarios.

34 Ejemplo de correlación sencilla
Ante un ataque se comprueba que la IP del atacante existe dentro de una lista de “Atacantes conocidos” (Watch List)

35 DRAGON SENSOR DRAGON SENSOR DRAGON SENSOR Squire Squire DPM EFP Squire
APPS SERVER Squire Squire DPM WEB SERVER FTP SERVER MAIL SERVER EFP SSL Squire Squire Squire

36 ¡Perdida de tiempo y recursos!
Vitim.com Atacante Internet HIDS FTP WWW DNS 1 “Atacante” tratando de entrar en los sistemas de “victim.com” NIDS 2 El firewall genera una entrada en de “log” para cada conexión: Jul 17 17:35:29 fw RULE 14 - ACCEPT SRC= :4457 DST= :80 TCP Jul 17 17:35:30 fw RULE 14 - ACCEPT SRC= :4458 DST= :80 TCP Jul 17 17:35:31 fw RULE 14 - ACCEPT SRC= :4459 DST= :80 TCP Jul 17 17:35:32 fw RULE 14 - ACCEPT SRC= :4460 DST= :80 TCP [...] El servidor Web detecta los fallos de autentificación y los registra: [17/Jul/2003:17:35: ] "GET / HTTP/1.0" "-" "-“ [17/Jul/2003:17:35: ] "GET / HTTP/1.0" "-" "-“ [17/Jul/2003:17:35: ] "GET / HTTP/1.0" "-" "-“ [17/Jul/2003:17:35: ] "GET / HTTP/1.0" "-" "-“ [...] ...N El Sensor de Red detecta los fallos de autentificación y los registra: :35:29|NIDS|WEB:UNAUTH| | |4457|80|T||6|tcp| :35:30|NIDS|WEB:UNAUTH| | |4458|80|T||6|tcp| :35:31|NIDS|WEB:UNAUTH| | |4459|80|T||6|tcp| :35:32|NIDS|WEB:UNAUTH| | |4460|80|T||6|tcp| [...] IDS Server Existe demasiada información sobre el mismo evento en diferentes lugares y con diferentes formatos ¡Perdida de tiempo y recursos! Facilidad para que la información importante pase inadvertida Analista

37 Ejemplos de Correlación - Inventario
El firewall genera una entrada en de “log” para cada conexión: Jul 17 17:35:29 fw RULE 14 - ACCEPT SRC= :4457 DST= :80 TCP Jul 17 17:35:30 fw RULE 14 - ACCEPT SRC= :4458 DST= :80 TCP Jul 17 17:35:31 fw RULE 14 - ACCEPT SRC= :4459 DST= :80 TCP Jul 17 17:35:32 fw RULE 14 - ACCEPT SRC= :4460 DST= :80 TCP [...] Firewall El servidor Web detecta los fallos de autentificación y los registra: [17/Jul/2003:17:35: ] "GET / HTTP/1.0" "-" "-“ [17/Jul/2003:17:35: ] "GET / HTTP/1.0" "-" "-“ [17/Jul/2003:17:35: ] "GET / HTTP/1.0" "-" "-“ [17/Jul/2003:17:35: ] "GET / HTTP/1.0" "-" "-“ [...] Servidor Web El Sensor de Red detecta los fallos de autentificación y los registra: :35:29|NIDS|WEB:UNAUTH| | |4457|80|T||6|tcp| :35:30|NIDS|WEB:UNAUTH| | |4458|80|T||6|tcp| :35:31|NIDS|WEB:UNAUTH| | |4459|80|T||6|tcp| :35:32|NIDS|WEB:UNAUTH| | |4460|80|T||6|tcp| [...] Sensor IDS Las direcciones IP de los distintos elementos ni siquiera cohinciden en los diferentes “logs”, de modo que necesitamos un inventario para determinar que “TODO” es de una sola maquina.

38 El Sensor de Red detecta los fallos de autentificación y los registra:
:35:29|NIDS|WEB:UNAUTH| | |4457|80|T||6|tcp| :35:30|NIDS|WEB:UNAUTH| | |4458|80|T||6|tcp| :35:31|NIDS|WEB:UNAUTH| | |4459|80|T||6|tcp| :35:32|NIDS|WEB:UNAUTH| | |4460|80|T||6|tcp| [...]

39 NT EventLog

40 Security Focus Inventario ! Soporte e-scudo Administrador Seguridad

41 Históricos Monitorización Administradores
Firewall Antivirus IDS CMS/CFS Vuln. Scan. WWW Srv. FTP Srv. BBDD Srv. File Srv. LDAP/PKI Históricos Monitorización Administradores Switches Routers Registros de seguridad/Auditoria: Firewalls Antivirus Sistemas de detección de intrusos Herramientas de filtrado de contenidos Herramientas de búsqueda de vulnerabilidades Información de análisis de seguridad “Manual” Registros de sistema/comunicaciones: Unix Syslog. NT Eventlog. Routers, switches, etc. Proxy’s. Información de aplicativos: Aplicaciones Corporativas (Aplicaciones propias) Mail, Servidor Web, DNS, etc. Información de herramientas de gestión ¡Inventario! Gestores SNMP (HPOV, Tivoli, etc.) Información externa: Security Focus (Vuln. DDBB) Security Providers Información de fabricantes (Advisories) Otras herramientas de correlación ¡Históricos! Datos de correlación históricos Métricas de red y comunicaciones Métricas de rendimiento de sistemas

42 Infraestructura Tecnológica Operadores de Explotación
Firewall Antivirus IDS Vuln. Scan. Fuentes Externas Sistema de Correlación Agentes de correlación Switches Routers PBX’s Acceso RAS File Srv. FTP Srv. BBDD Srv. PKI/PMI Operadores de Explotación Administradores Call center Dirección ejecutiva Inventario Históricos Net. Mng HelpDesk Alertas Métricas

43 Productos Recolección Filtrado Comunicación Centro Control Visualización Gráficos Check Point Correlación & Lista Agentes Alertas detalladas TCP w/SSL Microsoft Windows Windows/ Solaris Solaris Informes OS/390 Muchos más... Datos Conocimiento