Correlacin de Eventos Gestin de eventos de Seguridad

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

[. . . ] 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 (Net. IQ Corp. )

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

Gestión de intrusiones - Futuro • En palabras de Pinkesh Shah, director de Penta. Safe 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

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)

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 Open. View/ECS • http: //www. openview. hp. com/products/ecs/ • ECS & Cisco http: //www. cisco. com/warp/public/cc/pd/wr 2 k/t ech/cnm_rg. htm • Tivoli Event Correlation & Automation http: //www-3. ibm. com/software/tivoli/solutions/pa/event/ Sin embargo, es una tecnología mucho mas practica en seguridad, donde generalmente varios eventos indican un único “problema”.

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

¿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

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

¿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. NT Event. Log • Información de aplicativos: – Aplicaciones Corporativas (Aplicaciones propias) – Mail, Servidor Web, DNS, etc.

¿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

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

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)

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)

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

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)

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.

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)

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”

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)

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)

¿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

Ejemplo funcional Ante el ataque de un gusano como el “Code. Red” a alguna de las redes de la empresa, varios sistemas empiezan a generar información: 1. 2. 3. 4. 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.

Code Red Vitim. com 1 Servidor Infectado Internet HIDS Servidor Infectado con “Code. Red” tratando de Infectar IPs de “vitim. com” NIDS WWW 2 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 TCP Jul 17 17: 35: 30 fw RULE 32 - DROPED SRC=192. 168. 13. 3: 4458 DST=10. 144. 33. 8: 80 TCP Jul 17 17: 35: 31 fw RULE 32 - DROPED SRC=192. 168. 13. 3: 4459 DST=10. 144. 33. 5: 80 TCP Jul 17 17: 35: 32 fw RULE 32 - DROPED SRC=192. 168. 13. 3: 4460 DST=10. 144. 33. 2: 80 TCP [. . . ] HIDS FTP El servidor Web responde a las peticiones y las registra: 172. 17. 21. 33 - - [17/Jul/2003: 17: 35: 29 +0200] "GET /default. ida? XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XX XXX%u 9090%u 6858%ucbd 3%u 7801%u 9090%u 8190%u 00 c 3%u 0003%u 8 b 00%u 531 b%u 53 ff%u 0078%u 0000%u 00=a HTTP/1. 0" 404 2898 "-" "-“ [. . . ] 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| [. . . ] • Existe demasiada información sobre el mismo evento en diferentes lugares y con diferentes formatos • ¡Perdida de tiempo y recursos! Analista • Facilidad para que la información importante pase inadvertida . . . N HIDS DNS IDS Server

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

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 Do. S, 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 Code. Red, automáticamente se genera un ticket para que algún técnico de sistemas elimine el virus)

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

Fabricantes • • • Sistemas Informáticos Abiertos (SIA) Penta. Safe e. Security Guarded. Net Intellitactics ISS Site. Protector Net. Forensics OPEN Open. Systems

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

¡GRACIAS! ¿Preguntas?

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]

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)

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.

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)

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

Vitim. com nte ca Ata 1 Internet “Atacante” tratando de entrar en los sistemas de “victim. com” Jul Jul 17 17 HIDS WWW NIDS El firewall genera una entrada en de “log” para cada conexión: 17: 35: 29 fw RULE 14 - ACCEPT SRC=192. 168. 13. 3: 4457 DST=10. 144. 33. 2: 80 17: 35: 30 fw RULE 14 - ACCEPT SRC=192. 168. 13. 3: 4458 DST=10. 144. 33. 2: 80 17: 35: 31 fw RULE 14 - ACCEPT SRC=192. 168. 13. 3: 4459 DST=10. 144. 33. 2: 80 17: 35: 32 fw RULE 14 - ACCEPT SRC=192. 168. 13. 3: 4460 DST=10. 144. 33. 2: 80 [. . . ] 2 TCP TCP HIDS FTP 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 [. . . ] "-" "-" 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| [. . . ] • Existe demasiada información sobre el mismo evento en diferentes lugares y con diferentes formatos • ¡Perdida de tiempo y recursos! Analista . . . N "-“ "-“ • Facilidad para que la información importante pase inadvertida HIDS DNS IDS Server

Ejemplos de Correlación - Inventario Jul Jul 17 17 El firewall genera una entrada en de “log” para cada conexión: 17: 35: 29 fw RULE 14 - ACCEPT SRC=192. 168. 13. 3: 4457 DST=10. 144. 33. 2: 80 17: 35: 30 fw RULE 14 - ACCEPT SRC=192. 168. 13. 3: 4458 DST=10. 144. 33. 2: 80 17: 35: 31 fw RULE 14 - ACCEPT SRC=192. 168. 13. 3: 4459 DST=10. 144. 33. 2: 80 17: 35: 32 fw RULE 14 - ACCEPT SRC=192. 168. 13. 3: 4460 DST=10. 144. 33. 2: 80 [. . . ] 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 [. . . ] "-" "-" TCP TCP "-“ "-“ 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| [. . . ] • Firewall • Servidor Web • Sensor IDS

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| [. . . ]

NT Event. Log

Inventario ! Administrador Seguridad Soporte e-scudo

Antivirus FTP Srv. WWW Srv. BBDD Srv. File Srv. Firewall Históricos Routers Switches 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. CMS/CFS Vuln. Scan. LDAP/PKI Monitorización IDS 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 Administradores

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

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/ Solaris Informes OS/390 Muchos más. . . Datos Conocimiento