El camino del Hunter: Definición de una metodología ad hoc de evaluación de EDR

Hoy en día Threat Hunting es un término muy popular en la comunidad InfoSec. Sin embargo, no existe una definición ampliamente compartida de dicho rol. Las disparidades aparecen porque cada uno considera su propia implementación como la forma correcta de hacerlo. Si bien todavía no todo el sector se ha puesto de acuerdo sobre qué implica exactamente ser un Threat Hunter y cuál es su ámbito de actuación, hay algunos aspectos en los que sí se identifica consenso.

En primer lugar, el Threat Hunting lleva implícita una naturaleza de búsqueda proactiva de amenazas que no se da con los roles defensivos tradicionales de la ciberseguridad. Históricamente, las empresas se han visto obligadas a limitarse a tomar todas las medidas preventivas y reactivas para proteger su infraestructura y esperar lo mejor: evitar ser comprometidas o, al menos, poder mitigar los daños cuando finalmente tuvieran lugar. La figura del Threat Hunter surge de esa necesidad de aplicar proactividad en el lado defensivo para hacer frente al constante aumento en cantidad y sofisticación de los ataques de ciberseguridad que se han observado en los últimos años.

Su aparición cambia el clásico juego del Threat Actor vs. Empresa Víctima. Ahora tenemos un nuevo jugador en el tablero: el Hunter; cuyo papel requiere tener un profundo conocimiento ofensivo que por primera vez se aplica para estar un paso por delante del Threat Actor. Ese conocimiento se basa en la investigación continua de los ataques más avanzados y la disección de su funcionamiento para extraer la comprensión de cómo piensan los adversarios actuales y cuáles son sus técnicas de ataque. Con este nuevo jugador en el tablero, la víctima tradicional gana sus propios guardianes ofensivos, personas que utilizan su conocimiento experto para detectar y detener incidentes antes de que dejen de ser gestionables.

Hasta ahora, hemos establecido la base de lo que es un Threat Hunter a un nivel conceptual en el que la mayoría del sector que proporciona servicios de Threat Hunting estaría de acuerdo. A continuación, profundizaremos en los detalles de lo que abarca nuestra concepción de Threat Hunting.

Aunque consideramos que un Threat Hunter debe tener un conjunto de habilidades transversales que le permitan ser autosuficiente en todas las áreas en las que un atacante podría dejar rastro, nuestro servicio realiza la mayor parte de tareas de hunting adoptando la perspectiva del endpoint, y nuestra arma preferida es el EDR/XDR.

Cada día asumimos la hipótesis de que todos nuestros clientes han sido comprometidos de alguna manera. Para refutarlo, consultamos proactivamente su infraestructura en busca de evidencias con cientos de consultas que detectan trazas de técnicas específicas que un adversario podría haber utilizado para ejecutar alguna táctica de ataque. Esas consultas son el resultado de un trabajo de investigación continuo, y están pensadas para encontrar tanto técnicas ya atribuidas a APTs reales, como técnicas nuevas que podrían ser empleadas en un futuro.

Después de ejecutar nuestras consultas, revisamos todas las coincidencias y descartamos los falsos positivos. Para realizar este análisis, utilizamos la telemetría que los dispositivos envían al EDR. Aunque cada EDR tiene sus particularidades, todos los que homologamos tienen la capacidad de proporcionarnos respuestas a las preguntas que planteamos durante la evaluación de la coincidencia. Por último, sólo cuando estamos seguros de que ninguno de los resultados está relacionado con un comportamiento malicioso, descartamos la hipótesis de compromiso.

Aproximación a la creación de una metodología

En cuanto a qué hace que un «EDR» sea un EDR, y cuáles son sus características principales, volvemos a encontrar diversidad de criterios. Sin embargo, en este caso no se debe tanto a una falta de consenso en la comunidad InfoSec, sino a los proveedores, que a menudo intentan categorizar sus soluciones de seguridad con la etiqueta de «EDR» para aumentar el atractivo de su producto, aunque no cumpla los criterios más básicos de lo que debería hacer.

Como hemos mencionado anteriormente, el EDR es nuestra arma principal. No obstante, como proveedor independiente, nos esforzamos por ser agnósticos con respecto a la tecnología y por ser capaces de integrarnos en entornos heterogéneos de la forma más transparente posible. Por lo tanto, es imprescindible para nosotros conocer y hacer un seguimiento de las soluciones que pueden soportar nuestro modelo de Threat Hunting Continuo, las que son incompatibles, y la evolución de ambos grupos a lo largo del tiempo. Para formalizar ese proceso y hacerlo escalable, decidimos crear una metodología personalizada para la evaluación de EDR.

Estado del arte de la evaluación de EDR

Abordamos la tarea desde la perspectiva que nos da nuestra amplia experiencia en la prestación de un servicio de Threat Hunting de alta calidad. Esto ha llevado consigo, a lo largo de los años, utilizar varias tecnologías EDR, con sus cosas buenas y no tan buenas. Sin embargo, también es necesario investigar el estado del arte para establecer una línea base de cómo la comunidad ha estado evaluando los EDR hasta el momento, comprobar si alguno de sus enfoques se ajusta a nuestro modelo de Threat Hunting y evitar la duplicación en caso de que ya hubiera proyectos en curso que cumplieran nuestros requisitos. Durante esta investigación, descubrimos que la tendencia actual en la evaluación de las EDR tiene principalmente dos ramas.

Proyectos de evaluación técnica

Este tipo de evaluaciones se centran en las capacidades de detección de los EDR. Tener un amplio espectro de detecciones es sin duda una característica clave de cualquier solución que pretenda llamarse EDR. Sin embargo, decidimos que este tipo de evaluaciones no es suficiente y que debían complementarse con evaluaciones funcionales. Esto se debe a que incluso si un EDR tiene una tasa de detección excelente, si no recupera telemetría que podamos utilizar para refutar nuestra hipótesis de compromiso, o si no tiene las características básicas para responder a un incidente, el servicio de Threat Hunting se verá limitado.

Por otro lado, un EDR con menos capacidad de detección, pero más afín a nuestro modelo de Threat Hunting, podría enriquecerse con nuestra amplia base de conocimientos y convertirse en una opción viable.

En esta categoría de proyectos, nos gustaría destacar MITRE Engenuity ATT&CK Evaluations, que proporciona una evaluación anual de las capacidades de detección de varias soluciones EDR contra campañas de APTs conocidas para demostrar su eficacia. Utilizamos estas evaluaciones como un factor de puntuación para nuestra propia metodología.

Proyectos de evaluación funcional

Estos proyectos dan prioridad a la evaluación de la cantidad de la telemetría proporcionada por el EDR. En esta categoría también encontramos proyectos destacables. Concretamente, nos gustaría hacer una mención especial al Proyecto de Telemetría EDR.

Este proyecto se creó para «comparar y evaluar el potencial de telemetría de esas herramientas y, al mismo tiempo, animar a los proveedores de EDR a ser más transparentes sobre las funciones de telemetría que proporcionan a sus usuarios y clientes». Nos proporciona una lista de las fuentes de telemetría que utilizan las distintas soluciones EDR y, en consecuencia, de la cobertura que podemos esperar de ellas. Aunque este proyecto se aproxima al enfoque que queremos seguir para nuestra metodología ad hoc, no se ajusta completamente a todas las necesidades.

Sin embargo, acabamos integrándolo como referencia para decidir en el futuro qué EDRs merecerá la pena seguir de cerca como nuevo candidato a la homologación del mismo.

Aunque, como más adelante explicaremos, nuestra metodología también evalúa la telemetría proporcionada por un EDR, nos centramos en los datos concretos recuperados de cada fuente, asegurándonos de que la información tiene una calidad lo suficientemente alta como para que podamos implementar nuestras consultas de hunting. De este modo, creamos una relación simbiótica entre nuestra metodología y este proyecto, evitando duplicar el gran trabajo que ya están realizando.

Aunque finalmente ninguno de los proyectos existentes se ajusta a nuestras necesidades específicas, sí que constituyeron una base desde la que empezar a trabajar.

Una vez concluida la fase de investigación del estado del arte, empezamos a definir las partes personalizadas de nuestra metodología. La definición de éstas supone la mayor parte del trabajo de este proyecto. Se trata de formalizar el conjunto completo de características que un EDR debería tener implementadas para estar a la altura de nuestro estándar de calidad para la realización de Threat Hunting.

La selección de esas características se concreta a partir de nuestra propia experiencia técnica, adquirida a lo largo de años de prestación de un servicio de Threat Hunting. Nótese que, puesto que nuestro servicio es agnóstico en cuanto a tecnología, y hemos trabajado y evaluado múltiples tecnologías EDR a lo largo de los años, esta lista de características podría considerarse una recopilación de todos los aspectos destacables de las distintas tecnologías EDR a las que nos hemos enfrentado hasta el momento.

Como nota final antes de profundizar en las secciones en las que clasificamos las características, es importante aclarar que esta metodología está pensada para ser aplicada si y solo si se dan las siguientes premisas:

1. Acceso a la documentación del EDR.
2. Acceso a un entorno real con el EDR desplegado que permita probar y verificar sus funciones.
3. Acceso al equipo de soporte del EDR, ya que a veces la falta de documentación deja incertidumbre sobre el alcance del EDR en algunas áreas que son difíciles de probar en un entorno real.

Sin esos tres elementos, no creemos que la evaluación sea representativa de un reflejo real de la calidad de la solución y de cómo interactuaría con nuestro modelo de Threat Hunting.

Telemetría

En esta sección nos centramos en evaluar si la telemetría disponible es de suficiente calidad para realizar nuestro modelo de Threat Hunting. Esto hace que esta sección sea especialmente dependiente del enfoque que le damos nosotros al Threat Hunting. No obstante, intentamos ser lo más verbosos posible en nuestras evaluaciones, incluyendo comentarios que justifican las puntuaciones que otorgamos a cada característica. En ese sentido, creemos que esta sección de telemetría es lo suficientemente rica como para ser una de las más útiles para otros proveedores de servicios, ya que todos analizamos telemetría en mayor o menor medida.

Dos de las características que consideramos más importantes y que merece la pena mencionar en esta sección son el TTA (Tiempo de llegada de la telemetría) y el TTL (Tiempo que la telemetría vive, es decir, está disponible en el EDR).

La TTA es importante porque necesitamos asegurarnos de que en caso de que encontremos algún rastro de actividad sospechosa, podamos hacer a la telemetría en tiempo real todas las preguntas que necesitemos para resolver el caso. Si la telemetría tarda, digamos, 15 minutos en llegar, entonces estaremos en todo momento al menos 15 minutos por detrás de la amenaza. Esto podría verse como un lapso no muy grande, pero en un incidente en tiempo real podría significar la diferencia entre una mitigación temprana y un compromiso total.

El TTL también es una característica muy valiosa para nosotros. Para detectar comportamientos sospechosos, lo primero que tenemos que saber es cuál es el comportamiento normal en el entorno. Cuando se empieza a trabajar con un cliente, es imposible aprender inmediatamente cómo funciona su entorno, ya que eso se consigue con el tiempo. Por eso, disponer de telemetría antigua puede ayudarnos a suplir esa falta de contexto. Esta función también tiene en cuenta otras limitaciones en el almacenamiento de telemetría, como:

• Algunas tecnologías EDR dejan de almacenar telemetría de un dispositivo una vez alcanzado cierto umbral. Este tipo de limitaciones podría dar lugar a posibles ataques de denegación de servicio, en los que un adversario podría generar telemetría relacionada con actividad no sospechosa hasta el punto en que el EDR deja de almacenar, y luego realizar cualquier operación mientras estamos cegados.
• Algunas tecnologías EDR tienen modelos de telemetría basados en guardar en la nube una cantidad reducida de información y permitir hacer preguntas a los propios dispositivos para proporcionar más contexto. En estos casos que los equipos estén apagados o desconectados supone perder acceso a su telemetría.

Query language

Siempre estamos abiertos a utilizar nuevos lenguajes de consulta de nuevas soluciones EDR. Esto requiere satisfacer una serie de requisitos que toda solución y su lenguaje de consulta deben cumplir. En primer lugar, el EDR debe permitir consultar la telemetría. Si lo hace, además su lenguaje deberá ser lo suficientemente potente como para que podamos crear reglas de hunting y adaptar todo nuestro conocimiento de amenazas al nuevo lenguaje. La falta de una implementación adecuada de algunas de las características de esta sección podría resultar en severas limitaciones a la hora de realizar investigaciones con el correspondiente EDR cuando aparezcan indicios de actividad sospechosa, ya que las preguntas que hacemos a la telemetría requieren cierto nivel de potencia en el lenguaje.

Administrative tools

Esta sección abarca todas las funciones de las herramientas administrativas que necesitamos estén disponibles en una solución EDR. Desde la implementación de registros de auditoría hasta la implementación de políticas de seguridad y su flexibilidad, evaluamos varias categorías de funciones.

Features

En esta sección tenemos características generales no tan relacionadas con la parte administrativa del EDR, sino más específicamente con el uso diario de la solución para llevar a cabo las actividades del día a día. Así, encontraremos características relacionadas con, por ejemplo, la facilidad que da el EDR para la recuperación de artefactos, la flexibilidad para establecer exclusiones o qué tipos de acciones de respuesta y mitigación hay disponibles, entre muchas otras.

API

Para cuando llegamos a este punto de la evaluación, ya tenemos una idea del rendimiento del EDR, sus puntos fuertes y sus limitaciones. En esta sección buscamos constatar cuánto de su potencial está disponible a través de la API, lo cual permitirá o limitará la correcta sostenibilidad del servicio con un determinado EDR.

UI

Si bien no es la sección más importante, la UI tiene especial relevancia cuando se trata de una herramienta que vas a usar a diario. Un Threat Hunter debe poder moverse con fluidez por los paneles del EDR durante una investigación. En este sentido no estaríamos hablando de «comodidad» para el Threat Hunter, sino de limitaciones a la hora de estudiar un caso en el menor tiempo posible.

MITRE Engenuity

Hemos integrado los resultados de MITRE Engenuity en nuestro sistema de puntuación. Más concretamente, utilizamos las detecciones que cada EDR fue capaz de generar sin realizar ninguna modificación para cada uno de los ejercicios de MITRE. Esto nos da una idea de la capacidad de detección bruta del EDR a la hora de detectar comportamientos maliciosos, y de cómo ha ido evolucionando a lo largo de los años.

Conclusions

En esta última sección tenemos una versión sintetizada de todas las demás secciones para cada evaluación de EDR, junto con una conclusión de lo compatible que es esa solución con nuestro modelo de Threat Hunting. Nótese que, aunque tengamos un sistema de puntuación empírico, las conclusiones finales están muy influidas por la interpretación que el equipo de hunters haga de esa puntuación. En esta sección fusionamos los datos brutos que nos dan una vista objetiva de los pros y los contras de la solución evaluada, y la opinión experta del equipo para generar una conclusión final que concluirá si el EDR en su estado actual es adecuado, en mayor o menor medida, para desplegar un servicio de Threat Hunting que mantenga nuestros estándares de calidad.

Cabe mencionar que esta metodología está pensada para hacer evaluaciones periódicas de las soluciones. De esta forma podremos adquirir conocimiento no sólo de sus estados actuales, sino también de la manera en la que evolucionan y en qué dirección.

Desafíos de la evaluación de EDR

Definición de una característica NO-GO

Somos conscientes de que algunas de las características que necesitamos en una solución EDR son más importantes que otras. Por lo tanto, necesitamos poder diferenciar aquellas que características que consideramos que desempeñan un papel central para desplegar nuestro servicio de Threat Hunting. A estas funcionalidades as llamamos características NO-GO.

La ausencia de estas características en una solución EDR es considerada como una falta significativa de madurez de la solución en esa sección, por lo que muy probablemente esa solución no podrá ser homologada como lo suficientemente adecuada para nuestro modelo de Threat Hunting.

Nótese que parte del objetivo de estas evaluaciones es poder compartir por qué nos inclinamos por determinadas soluciones en lugar de otras de una forma determinista y empírica, pero en absoluto pretendemos convertir nuestro análisis en una guillotina de tecnologías. No descartamos utilizar una solución que no haya sido homologada, siempre y cuando podamos ser transparente en cuanto a sus limitaciones y éstas sean aceptables por nuestros clientes.

Falta de documentación o de cooperación por parte del servicio de soporte

Durante algunas de las evaluaciones efectuadas ha quedado patente que algunas soluciones EDR tienen una documentación más rica que otras. Del mismo modo, tratar con los equipos de soporte de los productos puede ser una tarea bastante tediosa en ocasiones.

Los primeros niveles de soporte funcionan a menudo como un mecanismo de redirección a la documentación disponible, incluso si el ticket es precisamente sobre la falta de documentación disponible públicamente. Después, si tienes la suerte de que escalen tu petición, no siempre son cooperativos a la hora de dar respuestas sobre la infraestructura o proporcionar información que no esté ya publicada.

Sin embargo, también hemos de admitir que durante algunas evaluaciones también hemos encontrado equipos de soporte muy colaborativos (aunque no sea lo más habitual).

Definición de un sistema de puntuación

Nuestra metodología utiliza varios inputs para llegar a la conclusión final de si una solución EDR es homologable o no con nuestro estándar de calidad para un servicio de Threat Hunting. En concreto, tenemos en cuenta:

1. Grado y calidad de aplicación de las características que hemos incluido como deseables o necesarias (NO-GO Feature) en la metodología. Utilizamos un sistema de tres colores para puntuar esto. Si una característica no está implementada, la marcamos en rojo. Si está parcialmente implementada o tiene carencias importantes, la marcamos en amarillo. Por último, si la implementación es satisfactoria, la marcamos en verde.
2. Como hemos dicho anteriormente, cada EDR evaluado debe probarse durante al menos un periodo suficiente en un entorno desplegado en el que podamos verificar sus capacidades. Durante la parte práctica del análisis de la solución, responder con el sistema de tres colores a la pregunta «¿Está implementada esta característica?» a menudo no es suficiente. Para poder añadir detalles sobre la puntuación otorgada utilizamos notas para transmitir información relevante sobre la implementación de esa característica, especialmente cuando se ha puntuado como amarilla.
3. Una vez finalizada la evaluación, realizamos una síntesis para cada sección de características, en la que congregamos los hallazgos más importantes teniendo en cuenta la puntuación tricolor y las notas, para destacar lo mejor y lo peor de la EDR en esa sección concreta. Esta información está disponible en la sección «Conclusions».
4. En este último paso, el equipo toma como entrada la calificación y las notas de las características, así como su versión sintetizada creada en el paso 3. Con estas aportaciones, el equipo de Threat Hunting puede debatir adecuadamente los resultados de la evaluación para llegar a un consenso de grupo sobre lo que se considerará la conclusión final (es decir, la respuesta a la pregunta «¿Es este EDR compatible con nuestro estándar de calidad para desplegar nuestro servicio de Threat Hunting sin limitaciones?»).

Compartir el producto de nuestro proyecto

Como se ha comentado al principio de este artículo, la forma «correcta» de realizar Threat Hunting sigue siendo objeto de debate. Sin embargo, creemos firmemente en que nuestro modelo despliega uno de los enfoques más completo del sector, intentando superarnos siempre que sea posible y priorizando dar valor en todos nuestros trabajos. Es por ello por lo que hemos decidido compartir con vosotros aquí la implementación de nuestra metodología con una muestra de resultados para facilitar su correcta interpretación.

Al compartir esta metodología y algunos de sus resultados pretendemos no sólo ilustrar este artículo, sino también demostrar la gran importancia que tiene seleccionar una buena tecnología y cómo ésta puede condicionar un servicio Threat Hunting que la utilice.

Esperamos que de este artículo se desprenda cómo hacemos las cosas y la importancia que le damos a un servicio de Threat Hunting serio. También nos gustaría animar a otros researchers de la comunidad a intercambiar ideas y experiencias, así como feedback que nos permitan seguir mejorando el proyecto.

Happy hunting!