Normal
0
false
21
false
false
false
ES-TRAD
X-NONE
X-NONE
Estimados amigos
de Inseguros !!!
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 |
|
Asset |
|
Authentication |
|
Binary file |
|
BIOS |
|
Browser |
|
Data loss |
|
Detonation |
|
Digital |
|
DLL monitoring |
|
DNS records |
|
EFI |
|
Email gateway |
|
Environment |
|
File |
|
Host network |
|
Kernel drivers |
|
Loaded DLLs |
|
Mail server |
|
Malware |
|
MBR |
|
Named Pipes |
|
Netflow/Enclave |
|
Network device |
|
Network |
|
Network |
|
Packet capture |
|
PowerShell |
|
Process |
|
Process |
|
Process use of |
|
Sensor health |
|
Services |
|
SSL/TLS |
|
System calls |
|
Third-party |
|
User interface |
|
VBR |
|
Web |
|
Web logs |
|
Web proxy |
|
Windows Error |
|
Windows event |
|
Windows |
|
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.
