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

43
Correlación de Eventos (Gestión de eventos de Seguridad) Pablo Ruiz García - Julio Pablo Ruiz García - Julio de 2003 de 2003 http://www.digitalsec.net http://www.digitalsec.net

Transcript of Correlación de Eventos (Gestión de eventos de Seguridad) Pablo Ruiz García - Julio de 2003 .

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

Correlación de Eventos

(Gestión de eventos de Seguridad)

Pablo Ruiz García - Julio de 2003Pablo Ruiz García - Julio de 2003

http://www.digitalsec.nethttp://www.digitalsec.net

Page 2: Correlación de Eventos (Gestión de eventos de Seguridad) Pablo Ruiz García - Julio de 2003 .

[...] Many computers and network devices keep logs of theevents they encounter. These events are usually veryspecific to a certain operating system, application, ornetwork component. When intruders attack any part of acomputer network, it’s likely that telltale signs are leftbehind, written as events to the logs of the computers onthe front line of the attack.

You’d like to see these events as they are occurring, ratherthan going back to each system weeks later and dumpingits system logs. You’d like to have the events fromdifferent systems correlated, to detect broad attacks.You’d like the log data to be consolidated andsynchronized, so you can see what is happening where.Most important, you’d like to generate automatedresponses to intrusions, corresponding to the securitypolicies you’ve established in your organization.These are the topics addressed by products that perform“security event correlation.” [...]

John Q. Walker (NetIQ Corp.)

Page 3: Correlación de Eventos (Gestión de eventos de Seguridad) Pablo Ruiz García - Julio de 2003 .

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

Page 4: Correlación de Eventos (Gestión de eventos de Seguridad) Pablo Ruiz García - Julio de 2003 .

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

Page 5: Correlación de Eventos (Gestión de eventos de Seguridad) Pablo Ruiz García - Julio de 2003 .

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)

Page 6: Correlación de Eventos (Gestión de eventos de Seguridad) Pablo Ruiz García - Julio de 2003 .

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:

Antecedentes

Sin embargo, es una tecnología mucho mas practica en seguridad, donde generalmente varios eventos indican

un único “problema”.

•HP OpenView/ECS • http://www.openview.hp.com/products/ecs/•ECS & Cisco

http://www.cisco.com/warp/public/cc/pd/wr2k/tech/cnm_rg.htm

•Tivoli Event Correlation & Automationhttp://www-3.ibm.com/software/tivoli/solutions/pa/event/

Page 7: Correlación de Eventos (Gestión de eventos de Seguridad) Pablo Ruiz García - Julio de 2003 .

¿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.

Page 8: Correlación de Eventos (Gestión de eventos de Seguridad) Pablo Ruiz García - Julio de 2003 .

¿Por qué es necesaria la correlación de eventos? I

Check Point

Microsoft

• 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.

OS/390OS/390

Page 9: Correlación de Eventos (Gestión de eventos de Seguridad) Pablo Ruiz García - Julio de 2003 .

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

Page 10: Correlación de Eventos (Gestión de eventos de Seguridad) Pablo Ruiz García - Julio de 2003 .

• 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.

¿Qué información se puede utilizar en la correlación? I

NT EventLog

Page 11: Correlación de Eventos (Gestión de eventos de Seguridad) Pablo Ruiz García - Julio de 2003 .

¿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

Page 12: Correlación de Eventos (Gestión de eventos de Seguridad) Pablo Ruiz García - Julio de 2003 .

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

Page 13: Correlación de Eventos (Gestión de eventos de Seguridad) Pablo Ruiz García - Julio de 2003 .

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)

Page 14: Correlación de Eventos (Gestión de eventos de Seguridad) Pablo Ruiz García - Julio de 2003 .

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)

Page 15: Correlación de Eventos (Gestión de eventos de Seguridad) Pablo Ruiz García - Julio de 2003 .

Requisitos - Reducción de la información a tratar

• 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

Page 16: Correlación de Eventos (Gestión de eventos de Seguridad) Pablo Ruiz García - Julio de 2003 .

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)

Page 17: Correlación de Eventos (Gestión de eventos de Seguridad) Pablo Ruiz García - Julio de 2003 .

Requisitos – Control de cambios y Continuidad

• Control de cambios– 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.

Page 18: Correlación de Eventos (Gestión de eventos de Seguridad) Pablo Ruiz García - Julio de 2003 .

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)

Page 19: Correlación de Eventos (Gestión de eventos de Seguridad) Pablo Ruiz García - Julio de 2003 .

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”

Page 20: Correlación de Eventos (Gestión de eventos de Seguridad) Pablo Ruiz García - Julio de 2003 .

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)

Page 21: Correlación de Eventos (Gestión de eventos de Seguridad) Pablo Ruiz García - Julio de 2003 .

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)

Page 22: Correlación de Eventos (Gestión de eventos de Seguridad) Pablo Ruiz García - Julio de 2003 .

¿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

Page 23: Correlación de Eventos (Gestión de eventos de Seguridad) Pablo Ruiz García - Julio de 2003 .

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:

1. 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

2. El NIDS avisa del intento de ataque de la vulnerabilidad “IIS-IDQ” en algunos de nuestros servidores Web

3. Cada Servidor Web afectado registra en sus ficheros de “log” las conexiones del ataque y su codigo de respuesta pertinente

4. 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.

Page 24: Correlación de Eventos (Gestión de eventos de Seguridad) Pablo Ruiz García - Julio de 2003 .

HIDS

FTP

HIDSWWW

HIDS

DNS

Code RedVitim.com

Internet

NIDS

IDSServer

Servidor Infectado con “CodeRed” tratando de Infectar IPs de

“vitim.com”

El sistema de detección de intrusos detecta los ataques (tanto por red):2003-07-17 17:35:29|NIDS|WEB:IIS-IDA|192.168.13.3|10.144.33.2|4457|80|T||6|tcp|

(Como en los logs)2003-07-17 17:35:29|HIDS|HOST:IIS-IDA|192.168.13.3|172.17.21.33|4457|80|T|||log|

[...]

El firewall genera una entrada en de “log” para cada conexión:Jul 17 17:35:29 fw RULE 14 - ACCEPT SRC=192.168.13.3:4457 DST=10.144.33.1:80 TCPJul 17 17:35:30 fw RULE 32 - DROPED SRC=192.168.13.3:4458 DST=10.144.33.8:80 TCPJul 17 17:35:31 fw RULE 32 - DROPED SRC=192.168.13.3:4459 DST=10.144.33.5:80 TCPJul 17 17:35:32 fw RULE 32 - DROPED SRC=192.168.13.3:4460 DST=10.144.33.2:80 TCP

[...]

El servidor Web responde a las peticiones y las registra:172.17.21.33 - - [17/Jul/2003:17:35:29 +0200] "GET /default.ida?

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u

7801%u9090%u9090%u8190%u00c3%u0003%u8b00%u531b%u53ff%u0078%u0000%u00=a HTTP/1.0" 404 2898 "-" "-“

[...]

Analista

•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

1

2

...N

Servidor Infectado

Page 25: Correlación de Eventos (Gestión de eventos de Seguridad) Pablo Ruiz García - Julio de 2003 .

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

Page 26: Correlación de Eventos (Gestión de eventos de Seguridad) Pablo Ruiz García - Julio de 2003 .

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)

Page 27: Correlación de Eventos (Gestión de eventos de Seguridad) Pablo Ruiz García - Julio de 2003 .

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

Page 28: Correlación de Eventos (Gestión de eventos de Seguridad) Pablo Ruiz García - Julio de 2003 .

Fabricantes

• Sistemas Informáticos Abiertos (SIA)• PentaSafe• eSecurity• GuardedNet• Intellitactics• ISS SiteProtector • NetForensics• OPEN• OpenSystems

Page 29: Correlación de Eventos (Gestión de eventos de Seguridad) Pablo Ruiz García - Julio de 2003 .

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

Page 30: Correlación de Eventos (Gestión de eventos de Seguridad) Pablo Ruiz García - Julio de 2003 .

¡GRACIAS!

¿Preguntas?

Page 31: Correlación de Eventos (Gestión de eventos de Seguridad) Pablo Ruiz García - Julio de 2003 .

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]

Page 32: Correlación de Eventos (Gestión de eventos de Seguridad) Pablo Ruiz García - Julio de 2003 .

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)

Page 33: Correlación de Eventos (Gestión de eventos de Seguridad) Pablo Ruiz García - Julio de 2003 .

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.

Page 34: Correlación de Eventos (Gestión de eventos de Seguridad) Pablo Ruiz García - Julio de 2003 .

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)

Page 35: Correlación de Eventos (Gestión de eventos de Seguridad) Pablo Ruiz García - Julio de 2003 .

Squire Squire Squire

DRAGONSENSOR

DRAGONSENSOR

Squire

DRAGONSENSOR

EFP

DPM

WEB

SER

VER

FTP S

ER

VER

MA

IL S

ER

VER

Squire

APPS

SER

VER

SSL

Page 36: Correlación de Eventos (Gestión de eventos de Seguridad) Pablo Ruiz García - Julio de 2003 .

HIDS

FTP

HIDSWWW

HIDS

DNS

Atacante Vitim.com

Internet

NIDS

IDSServer

“Atacante” tratando de entrar en los sistemas de “victim.com”

El Sensor de Red detecta los fallos de autentificación y los registra:2003-07-17 17:35:29|NIDS|WEB:UNAUTH|192.168.13.3|10.144.33.2|4457|80|T||6|tcp|2003-07-17 17:35:30|NIDS|WEB:UNAUTH|192.168.13.3|10.144.33.2|4458|80|T||6|tcp|2003-07-17 17:35:31|NIDS|WEB:UNAUTH|192.168.13.3|10.144.33.2|4459|80|T||6|tcp|2003-07-17 17:35:32|NIDS|WEB:UNAUTH|192.168.13.3|10.144.33.2|4460|80|T||6|tcp|

[...]

El firewall genera una entrada en de “log” para cada conexión:Jul 17 17:35:29 fw RULE 14 - ACCEPT SRC=192.168.13.3:4457 DST=10.144.33.2:80 TCPJul 17 17:35:30 fw RULE 14 - ACCEPT SRC=192.168.13.3:4458 DST=10.144.33.2:80 TCPJul 17 17:35:31 fw RULE 14 - ACCEPT SRC=192.168.13.3:4459 DST=10.144.33.2:80 TCPJul 17 17:35:32 fw RULE 14 - ACCEPT SRC=192.168.13.3:4460 DST=10.144.33.2:80 TCP

[...]

El servidor Web detecta los fallos de autentificación y los registra:172.17.21.33 - - [17/Jul/2003:17:35:29 +0200] "GET / HTTP/1.0" 403 2898 "-" "-“172.17.21.33 - - [17/Jul/2003:17:35:30 +0200] "GET / HTTP/1.0" 403 2898 "-" "-“172.17.21.33 - - [17/Jul/2003:17:35:31 +0200] "GET / HTTP/1.0" 403 2898 "-" "-“172.17.21.33 - - [17/Jul/2003:17:35:32 +0200] "GET / HTTP/1.0" 403 2898 "-" "-“

[...]

Analista

•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

1

2

...N

Page 37: Correlación de Eventos (Gestión de eventos de Seguridad) Pablo Ruiz García - Julio de 2003 .

Ejemplos de Correlación - Inventario

El Sensor de Red detecta los fallos de autentificación y los registra:2003-07-17 17:35:29|NIDS|WEB:UNAUTH|192.168.13.3|10.144.33.2|4457|80|T||6|tcp|2003-07-17 17:35:30|NIDS|WEB:UNAUTH|192.168.13.3|10.144.33.2|4458|80|T||6|tcp|2003-07-17 17:35:31|NIDS|WEB:UNAUTH|192.168.13.3|10.144.33.2|4459|80|T||6|tcp|2003-07-17 17:35:32|NIDS|WEB:UNAUTH|192.168.13.3|10.144.33.2|4460|80|T||6|tcp|

[...]

El firewall genera una entrada en de “log” para cada conexión:Jul 17 17:35:29 fw RULE 14 - ACCEPT SRC=192.168.13.3:4457 DST=10.144.33.2:80 TCPJul 17 17:35:30 fw RULE 14 - ACCEPT SRC=192.168.13.3:4458 DST=10.144.33.2:80 TCPJul 17 17:35:31 fw RULE 14 - ACCEPT SRC=192.168.13.3:4459 DST=10.144.33.2:80 TCPJul 17 17:35:32 fw RULE 14 - ACCEPT SRC=192.168.13.3:4460 DST=10.144.33.2:80 TCP

[...]

El servidor Web detecta los fallos de autentificación y los registra:172.17.21.33 - - [17/Jul/2003:17:35:29 +0200] "GET / HTTP/1.0" 403 2898 "-" "-“172.17.21.33 - - [17/Jul/2003:17:35:30 +0200] "GET / HTTP/1.0" 403 2898 "-" "-“172.17.21.33 - - [17/Jul/2003:17:35:31 +0200] "GET / HTTP/1.0" 403 2898 "-" "-“172.17.21.33 - - [17/Jul/2003:17:35:32 +0200] "GET / HTTP/1.0" 403 2898 "-" "-“

[...]

•Firewall

•Servidor Web

•Sensor IDS

Page 38: Correlación de Eventos (Gestión de eventos de Seguridad) Pablo Ruiz García - Julio de 2003 .

El Sensor de Red detecta los fallos de autentificación y los registra:2003-07-17 17:35:29|NIDS|WEB:UNAUTH|192.168.13.3|10.144.33.2|4457|80|T||6|tcp|2003-07-17 17:35:30|NIDS|WEB:UNAUTH|192.168.13.3|10.144.33.2|4458|80|T||6|tcp|2003-07-17 17:35:31|NIDS|WEB:UNAUTH|192.168.13.3|10.144.33.2|4459|80|T||6|tcp|2003-07-17 17:35:32|NIDS|WEB:UNAUTH|192.168.13.3|10.144.33.2|4460|80|T||6|tcp|

[...]

Page 39: Correlación de Eventos (Gestión de eventos de Seguridad) Pablo Ruiz García - Julio de 2003 .

NT EventLog

Page 41: Correlación de Eventos (Gestión de eventos de Seguridad) Pablo Ruiz García - Julio de 2003 .

Registros de seguridad/Auditoria:FirewallsAntivirus

Sistemas de detección de intrusosHerramientas de filtrado de contenidos

Herramientas de búsqueda de vulnerabilidadesInformació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.

FirewallFirewall

AntivirusAntivirus

IDSIDS

CMS/CFSCMS/CFS

Vuln. Scan.Vuln. Scan.

WWW Srv.WWW Srv.

FTP Srv.FTP Srv.

BBDD Srv.BBDD Srv.

File Srv.File Srv.

LDAP/PKILDAP/PKI

Información de herramientas de gestión¡Inventario!

Gestores SNMP (HPOV, Tivoli, etc.)Información externa:Security Focus (Vuln. DDBB)

Security ProvidersInformación de fabricantes (Advisories)

Otras herramientas de correlación¡Históricos!

Datos de correlación históricosMétricas de red y comunicaciones

Métricas de rendimiento de sistemas

SwitchesSwitches

RoutersRouters

AdministradoresMonitorizaciónHistóricos

Page 42: Correlación de Eventos (Gestión de eventos de Seguridad) Pablo Ruiz García - Julio de 2003 .

Agentes de correlación

Sistema de

Correlación

• Administradores

• Call center

• Dirección ejecutiva

Operadores de Explotación

Fu

en

tes

Ex

tern

as

SwitchesSwitches

RoutersRouters

PBX’sPBX’s

Acceso RASAcceso RAS

Infraestructura Tecnológica

FirewallFirewall

AntivirusAntivirus

IDSIDS

Vuln. Scan.Vuln. Scan.

File Srv.File Srv.

FTP Srv.FTP Srv.

BBDD Srv.BBDD Srv.

PKI/PMIPKI/PMI

Alertas

InventarioInventario

HistóricosHistóricos

Net. MngNet. Mng

HelpDeskHelpDesk

Métricas

Page 43: Correlación de Eventos (Gestión de eventos de Seguridad) Pablo Ruiz García - Julio de 2003 .

Windows

RecolecciónProductos

Microsoft

OS/390OS/390

Centro Control VisualizaciónComunicaciónFiltrado

Windows/Solaris

Agentes

TCPw/SSL

Solaris

Correlación& Lista

Gráficos

Alertas detalladas

Informes

Datos Conocimiento

Muchos más...Muchos más...

Check Point