Gestión de incidentes... Episodio 2. La detección...

Estimados amigos de Inseguros !!!

Capítulo 1.
Capítulo 2.
Capítulo 3.

Seguimos con esta serie de artículos relacionados con el amplio mundo de la gestión de incidentes.

En el capítulo 1 introdujimos los conceptos básicos y más bien la necesidad.
Al final este post iba a versar sobre 4 integraciones de 20 productos, pero creo que puedo aportar más dando mi visión y experiencia global, más que con unas cuantas guías, que las pondré !!! pero mejor ir paso a paso.

Somo informáticos, nos gusta la tecnología y probar programitas y cacharros es lo que más. La sensación de instalar un nuevo software, de hacer los primeros pasos, a mi dilata experiencia, toda via me motiva, me gusta !!! Pero como informáticos que somos, debemos recordar que lo primero de todo es hacer un buen análisis de requisitos de qué queremos hacer, luego haremos un análisis funcional, y luego diseñaremos la solución tecnológica. 

Conozco MIL pilotos de software que nunca llegan a solución por eso, porque se prima el programa...

Por desgracia, y por eso lo decía, muchos de nosotros orientamos nuestras soluciones a que nos gusta más WIndows que Linux, o al revés, o a que yo tengo mucho conocimiento sobre una tecnología y NECESITO ponerla donde sea !!! No amigo, no, esto no debería ser así.

Cuando hablamos de la gestión de incidentes, el primero punto debería ser establecer cómo vamos a detectar estos incidentes. Con qué herramientas.

Al final, estas herramientas no dejan de ser eventos (logs), muestras ( pcap, ficheros, memoria...) y sobre todo la correlación que existe entre ellas. Imagina un radar de una autovía, y la típica foto de que te  han cazado a 200km/hora. y aparecen dos coches, uno adelantando a otro. Serviría dicha foto como muestra de la infracción? NO.

Presuponemos que el vehículo de la izquierda adelantaba al de la derecha, por eso saltó el radar, y el que iba "lento" o legal era el de la derecha, pero puede que no sea así !!!! en este caso, el dato de la imágen y el radar no nos sirve, deberíamos tener video en ese contexto....

En este caso, si salta el radar, a quien debería sancionarse?

Podría ponerme 200 ejemplos más del contexto, de la relación entre fuentes, de la correlación pero creo que ya hemos hablado bastante en Inseguros en los capítulos de OSSIM.

Pero ahora vamos más allá. como comenté en el post de la matriz de MITRE, tenemos enumerados la mayoría de procesos de ataques, las tácticas y técnicas, y tenemos los data source que las detectan.

Con esta información, debemos hacer mapa de qué herramientas y tecnologías serían necesarias para llegar al máximo número de data source, y tener claro un plan de trabajo a medio plazo en el que vayamos incorporando fuentes de información.

Tener un IDS no es tener un SOC, ni tampoco es tener un IDS con un SIEM, por supuesto, tener una consola centralizada de alarmas de antivirus tampoco, vamos poco a poco.

Enumeramos los distintos data source a día de hoy. Ahora vamos a empezar a crear supuestos, los use-cases.

Vamos a imaginar un ataque a una empresa. Comienza con un ataque de deautenticación *1 a la red wifi*2 para forzar eso, que clientes legítimos se desconecten a la red y así poder capturar las credenciales o el handshake. Una vez conseguimos acceso a la red wifi, realizamos un ataque de arp-spoofing*3 simple para esnifar tráfico del cliente, o más fácil aún, vamos a realizar un Man In the middle del DNS*4, vamos a suplantarlo para conocer los accesos y poder establecer otro tipo de ataque. Conociendo accesos típicos a una web interna, vamos a intentar montar un web similar*5 y con un proxy inverso capturar credenciales.

Hasta aquí un ataque de primero de hacker de los 2000, pero vamos a desgranar cómo debería ser la monitorización, qué fuentes serían necesarias para detectar este ataque.

*1 Monitorización de la plataforma de WIfi y correlación de eventos para detectar multiples peticiones deauth.
*2 WIFI IDS para detectar rogue AP y nuevos elementos en la red Wifi.
*3 Switches gestionables con detección de arp broadcast storm o similar.
*4 hay varias técnicas de detección para suplantación dns, depende si se cambia en el adaptador cliente, o es un envenamiento DNS, DHCP, etc. En la mayoría de los casos vas a necesitar monitorización total de red.
*5 detectar la navegación de usuarios a sitios con certificados no válidos, como cuando se usa ssltrip y herrmientas de proxy.

Como puedes comprender, desarrollar una estrategia de monitorización es muy complicada para casos de uso muy sencillo. Si a estos casos de uso le sumamos complejidad en el ataque, la monitorización se hace MUY compleja.

En el caso de los IDS de toda la vida, o como vimos en el episodio de OSSIM, se suele guardar el fragmento de pcap que ha saltado la alerta, pero en el caso de uso comentado, debería analizar el tráfico de red PASADO, almacenado, es decir, no el que genera el evento, sino 1 semana de estudio, un día, una hora, lo que necesitemos.

Cómo guardamos el tráfico de red de una empresa para monitorizar después? IMPOSIBLE, podrías guardar x horas, minutos, o días, pero el tráfico es gigante. Hay que trabajar con herramientas como puedan ser BRO o Logtash que generen eventos relacionados con el tráfico. Por ejemplo, en este caso del DNS, no tiene sentido tener un MEGA pcap para ver las peticiones UDP 53. Mejor será tener ese sistema automatizado y preguntar por ese datos, consultas UDP 53, no el PCAP entero.

Cuantos más indicadores "transformemos" del pcap a eventos, más capacidad de usar esa información tendremos. Bro tiene muchas capacidades ya dispuestas, por ejemplo, detectar los mensajes OSCP para detectar el código de error del certificado del caso *5.

Estos son los elementos que presenta el Mitre.

Access Tokens

Anti-virus

API monitoring

Application Logs

Asset Management

Authentication logs

Binary file metadata

BIOS

Browser extensions

Data loss prevention

Detonation chamber

Digital Certificate Logs

DLL monitoring

DNS records

EFI

Email gateway

Environment variable

File monitoring

Host network interface

Kernel drivers

Loaded DLLs

Mail server

Malware reverse engineering

MBR

Named Pipes

Netflow/Enclave netflow

Network device logs

Network intrusion detection system

Network protocol analysis

Packet capture

PowerShell logs

Process command-line parameters

Process monitoring

Process use of network

Sensor health and status

Services

SSL/TLS inspection

System calls

Third-party application logs

User interface

VBR

Web application firewall logs

Web logs

Web proxy

Windows Error Reporting

Windows event logs

Windows Registry

WMI Objects

Algunos son muy evidentes, pero otros? Detonation chamber ? Se refiere a algún tipo de sandbox que inspeccione el contenido del fichero adjunto en un ataque de Phishing.

Las peticiones DNS !!! en los servidores Windows por defecto no se registran, en este artículo aprendimos a registrar estos eventos en servidores DNS Windows,
pero también imagina la cantidad de registros que se van a generar...

Seguro que si repasas todas las fuentes de datos te saldrán mil dudas.

Otra cuestión a tener en cuenta es el propio dato, la calidad del dato. Tenemos un sistema consolidado por el tiempo, para el tiempo? para que cuando un evento me dice las 22:00 sea utc o utc+2 ?. 

Tenemos la misma política de retención de eventos en un log de Apache que en un log de un AP wifi?

Tenemos el campo ip_source en todos sitios, o en algunos es ip_src y en otros es una MAC? tenemos que hacer transformaciones específicas para homogenizar el dato? es decir , construir un modelado de datos para que tenga sentido comparar peras con peras, y no con manzanas...

Imagina un sistema con firewalls de 5 fabricantes, y que cada uno llama a sus datos de una manera distinta...

Aparte, si integras este modelado de datos con estándares de compartición como pueda ser STIX

Imagina un antivirus que te dice: amenaza X detectada en PC-JOSE , la fecha y el nombre del binario. Esa amenaza puede ser un malware en un js de navegación , o la ejecución de Mimikatz !!! Si es la ejecución de una powershell sospechosa, o un CMD, debería tener el comando exacto y los parámetros... y la fuente de la amenaza, si es una web, un proceso remoto en una red local...

También deberíamos tener el fichero en caso de existir, para poder hacer aunque sea un análisis dinámico...

PC-jose es el nombre netbios? DNS? el nombre que se le dió en la consola antivirus...

A mi ya se me están viniendo a la cabeza varios data-source en este mini user-case que es una mera detección de un antivirus. Use-case a millones, tantos, como representar todas las posibilidades reales en un proceso de hacking... infinitos diría yo !!!

A la hora de trabajar con los eventos, con la correlación, debemos usar lenguajes que nos permitan generar alertas y realizar búsquedas de supuestos. 

Cuando realizamos una gestión de incidentes, una respuesta a incidentes, se trabaja con supuestos, vas analizando la información que tienes y vas suponiendo, por ejemplo, si ves indicadores de compromiso o IOC´s relativos a navegación web, debes pensar que ha sido una intrusión por esta vía, deberás revisar en profundidad los logs de acceso y navegación. No vas a ponerte a leer todos los logs del sql-server del servidor de nóminas si no se ha visto implicado, a priori... 

Para trabajar con estos supuestos, con estas búsquedas de IOC´s, usar sistemas con lenguajes "compatibles" como pueda ser el proyecto SIGMA para la definición de búsquedas en los SIEM´s más populares es una ventaja, ya que te permite trabajar en entornos multi SIEM, que aunque parezca una locura, existen. El mismo SOC proveedor puede trabajar con N tecnologías SIEM.

Para la gestión de IOC´s tengo varios favoritos, pero hemos iniciado el artículo diciendo que no iba a hablar de software, para eso tenemos la tercera entrega.

De momento quédate con la idea del data-source. Si vas a trabajar con un fabricante X y tienes fuentes de información Y y Z, comprueba la facilidad que vas a tener de integrar esta información, de cómo vas a poder "meter" pero también "sacar".

En el próximo programa hablaremos de escenarios específicos con software que conoces como The Hive, splunk, MIPS, Alien Vault, Qradar, ELK etc.

Gracias por leerme.