EDR vs Event log vs Sysmon

¿Poner tu seguridad en manos de un EDR o, bien, ponerla al registro de actividad de toda la vida?

Antes de que empiecen a volar las dagas, despleguemos a los contendientes:

¿Qué es un EDR?

Un Endpoint Detection and Response es una solución antimalware complementaria al Antivirus que aumenta las capacidades, debido a que revisa los comportamientos a bajo nivel. Según sus características, algunos pueden incluir capacidades como integrar reglas YARA, traerse ficheros de muestra o, por ejemplo, aislar un equipo, que un antivirus corporativo tradicional no tiene.

¿Qué es un registro de actividad?

Un event log o registro de actividad es una o varias líneas almacenadas en un archivo con información específica que ha pasado en una parte del sistema. Estos eventos, que en Windows se pueden ver con la aplicación “Event Viewer” y en Linux distribuido en diferentes ficheros dependiendo de la versión, nos indicarán algunos de los eventos que ocurren.

Los eventos pueden ser muy distintos entre sí, desde eventos de aplicaciones a los de seguridad, pasando por eventos intrínsecos del sistema.

Y ahora la pregunta del millón. ¿Cómo podemos utilizar los eventos para detección de amenazas? Fácil: distinguiendo lo que es normal de lo que no lo es. Si cogemos, por ejemplo, el evento 4624 anterior y sustituimos la aplicación que realiza el log in en nuestro sistema por mstsc utilizado para hacer conexionas remotas y la IP 127.0.0.1 por una IP pública geolocalizada en un país extranjero, ¿qué tenemos? Una probable exfiltración de datos, lo nunca visto.

Sysmon: sin querer ser nada, lo es todo

El tercero en discordia es Sysmon. Esta utilidad de systernals-Microsoft no es un EDR ni un event log al uso, sin embargo, cubre en cierta medida las capacidades de “ambas cosas”. Sysmon es un programa que registra un driver en nuestro equipo y empieza a monitorizar lo que pasa guardándolo en un registro propio. Sysmon, a diferencia de los EDR, no tiene capacidades de contención ni erradicación. Solo es el ojo que todo lo ve, aunque requiere un proceso de configuración y fine tuning muy preciso para obtener los resultados deseados sin generar problemas

Una vez desplegadas las soluciones, hagamos una pequeña tabla de lo que podremos ver con ellas para la detección de una amenaza muy conocida como Emotet, en 5 pasos para hacernos una idea de las limitaciones:

Como podemos ver tanto los EDR como Sysmon pueden cubrir muchos de los puntos de detección típicos, sin embargo el event log tiene alguna limitación y necesidades añadidas, nada grave hasta el momento, por lo que el resultado de nuestra elección/elecciones debería estar basado en otros aspectos aparte de la funcionalidad, para lo que necesitamos responder antes a ciertas preguntas:

·  Coste: ¿es asumible contar simultáneamente con las tres alternativas? ¿Es posible aumentar lo suficiente la auditoria para contar con toda la visibilidad y mantenerlo dentro de un coste asumible?

· ¿Dónde vamos a almacenar los resultados? Cuanta más visibilidad mayor coste, por lo que siempre hay que encontrar el equilibrio y llegar al punto de visibilidad optimo dentro de un coste.

· ¿Qué nivel de visibilidad necesitamos en el endpoint?

· ¿Qué tiempo de retención de logs necesitamos?

· Qué accesibilidad tendremos a los datos. Almacenar muchos logs en bruto puede ofrecer mucha visibilidad, pero si no se puede consultar de forma flexible y ágil es mejor contar con menos información pero importante, para poder gestionar la búsqueda con herramientas más accesibles.

· ¿Necesitaremos necesidades adicionales a futuro?

· ¿Qué tipo de actividades vamos a realizar? Contar con una herramienta con capacidad de respuesta sin poder invertir en equipos o servicios que le saquen partido puede no ser la mejor decisión.

Desde el punto de vista del Threat Hunting, las capacidades más necesarias a cubrir por cualquier solución de endpoint -considerando que ya tenemos visibilidad por otros medios de los eventos que únicamente se pueden conseguir con el event log- son las siguientes:

· Creación de procesos (con hash del proceso creado)

· Conexiones a red de procesos (con hash del proceso que inicia la conexión)

· Creación de hilos en otros procesos

Los recomendables son los siguientes:

· Carga de DLL (con hash de la DLL)

· Navegación y tráfico DNS

· Tokens asignados

· Lectura/escritura en registro

Aunque existen funcionalidades complementarias muy interesantes, con estas se debería de poder conducir la mayoría -si no todas- de las investigaciones y detectar una amenaza que se mueva utilizando técnicas del ATT&CK. Se debe considerar también que la solución perfecta, como ocurre en cualquier área de la ciberseguridad, no recae solo en un único producto, sino que el escenario ideal implica priorizar las funcionalidades más importantes en un roadmap de evolución. Entre los 3 elementos de estudio en este artículo, podemos resumir sus características de la siguiente manera:

· EDR: el único que añade una capa de protección, dado que bloquea. No requiere de invertir en inteligencia propia, ya que normalmente son productos que incluyen mecanismos de detección y feeds de inteligencia propios.

· Event log: en algunos casos se trata de la única solución que permite ver ciertas acciones. En general, podemos considerar obligatoria la visibilidad a nivel de dominio en entornos Windows y recomendable la auditoria de logs local para servidores.

· Sysmon: ofrece gran nivel de visibilidad si se configura adecuadamente. Por la contra, su gestión y configuración es menos industrializable e implica el uso de una utilidad de Microsoft que no ofrece como producto comercial, con el consiguiente vacío en soporte.

En este sentido, ¿cuál es la mejor solución? Todas y, a la vez, ninguna. En general, idealmente, como en otros ámbitos, la mejor solución implica coger las mejores funcionalidades de cada elemento y combinarlas.

Es necesario tener plataformas que permitan bloquear automáticamente las nuevas detecciones de IOC e IOA y, por supuesto, que tengan módulos de respuesta. No obstante, esto no es suficiente en muchos casos y requiere de apoyo de event logs para cubrir la superficie de detección.

Por otro lado, el papel de Sysmon, aunque muchos lo tenemos en mente como táctico, dado que podemos conseguir un gran nivel de visibilidad con él, desde un punto estratégico puede tener varias consecuencias, algunas negativas:

- Es casi imposible implementar todos los eventos de Sysmon salvo que se restrinja mucho la configuración (podrían perderse cosas).

- Es complicado configurar e implementar bien un evento en entornos grandes.

- Hay eventos extremadamente ruidosos que pueden saturar o desbordar fácilmente las plataformas de retención y procesado de logs (SIEM, Data Analytics, etc).

- Sysmon es gratuito, pero sin soporte técnico. La implementación en entornos de producción es responsabilidad del usuario y no de Microsoft. Esto puede incurrir en riesgos adicionales.

Por otro lado, si aplicamos Sysmon como un complemento y no como un sustituto, podemos disminuir los tiempos y la complejidad de implementación:

- Seleccionando los eventos que el resto de las plataformas no pueden enseñarnos y en los que Sysmon aporta un valor diferencial (ID8,9,10,23, etc.).

- Podemos aplicar configuraciones de tipo blackbox o whitebox dado que, al ser un sistema estratégico y no táctico, no debe de tener obligatoriamente la máxima visibilidad posible. Debe tener lo que necesitemos que requiera para mejorar nuestra capacidad de detección con una inversión de tiempo razonable.

Ahora os toca a vosotros. ¿Cuál es vuestra solución o combinación favorita?

Equipo Detectar y Responder