Escrito por: Santiago Rangel
Para realizar una cacería de amenaza exitosa, tenemos que partir del pensamiento que nos han atacado o intentado vulnerar y que todos los controles que se han implementado dentro de la organización han sido vulnerados. Por lo tanto, el resultado esperado de una cacería de amenazas pueden ser:
La mentalidad para ejecutar una cacería es que los equipos implementados no son totalmente perfectos y además que son manejados y configurados por humanos y generalmente las brechas de seguridad que son más difíciles de encontrar son las configuraciones erróneas y el desconocimiento de los usuarios de las amenazas a las que está presente en el dia a dia.
Partiendo de lo anterior un threat hunting debe partir que estamos ya en una fase de explotación o que el atacante ya está dentro de la red, tratando de ejecutar una acción maliciosa en nuestra red. Según la figura 1 estaríamos en el cuarto paso de un ataque.
Figura 1. Ciclo de vida de un ataque
Teniendo en cuenta lo anterior, para preparar una buena cacería de amenaza te recomiendo:
En este paso se selecciona el propósito u objetivo de la cacería de amenaza, donde pueden funcionar resultados de threat intelligence y herramientas que automaticen el proceso de threat intelligence. Un ejemplo de esto podría ser: “Encontrar un intento de poisoning DNS en la red”
Teniendo en cuenta que el objetivo debe ser seleccionado según los recursos que tengamos a disposición, esto quiere decir que, si durante la cacería no cuentas con Logs de DNS en sus plataformas, no coloquemos por objetivo esa cacería. Un aspecto muy importante durante una cacería de amenaza es tener todos los logs de la red y de endpoints centralizados de tal manera que se puedan correlacionar y ayudar a la cacería de amenaza, en caso de no tener todos los logs de los IDS e IPS implementados puede llevar a una cacería fallida.
Debido a que dentro de nuestra red o en los equipos pueden existir muchos logs, que no vamos a poder analizar en su totalidad, se debe definir de una manera correcta el alcance que se va a llevar en la cacería. Dentro del ejemplo anterior “Encontrar un intento de poisoning DNS en la red”, podría llevarnos horas si no días realizar una investigación profunda de todos los logs que pueden haber en nuestra empresa de DNS. para ello se puede seleccionar un sampling o un clipping, donde podemos establecer a qué logs nos vamos a enfocar dentro de nuestra Red. Un ejemplo de alcance podría ser: “Revisar la resolución de DNS maliciosos que se han hecho con más frecuencia para ubicar un intento de DNS poisoning”
La idea es acotar la búsqueda de información y encontrar unos intentos de poisoning hacia los servidores DNS, ya que, si se toman todos los logs, posiblemente estarán nadando en un lago de datos sin algún fin o llevándolos hacia falsos positivos. Esta actividad se debe realizar con todos los recursos tecnológicos que tengamos en el momento.
En esta fase debes escoger aquellas tecnologías o recursos que tengas a tu disposición para poder ejecutar el plan. Dentro de estos recursos deben existir:
El escenario ideal sería que todas tus herramientas de respuestas a incidentes estén automatizados, que correlacionen la mayoría de los logs y detecten el comportamiento objetivo en que se basó nuestra cacería. Sin embargo, bajo la premisa de "Cero Confianza" y en un proceso de búsqueda de amenazas debe existir la examinación humana para que exista garantías de nuestra seguridad, aunque haya confianza en nuestros productos y plataformas.
Define y documenta el paso a paso de cómo se va a realizar la cacería de amenaza.
Es importante destacar que dentro del SOC de una compañía, el equipo de Threat Hunting debe existir y debe estar dedicado a la cacería de amenaza. Este equipo debería tener como labor diaria la cacería de amenazas, y por ende debe tener un supervisor que vele por el cumplimiento de estas cacerías según el objetivo de negocio de la empresa.
El supervisor de este equipo determina si los objetivos se plantearon correctamente y si el alcance es realmente medible con respecto a su infraestructura. Además, debe conducir a que la cacería de amenaza detecte realmente amenazas que están presente en la red y que nuestros controles no los han detectado. Es importante aclarar que se debe de revisar que el plan no esté orientado a una auditoría de políticas (como lo puede ser revisión de configuraciones de Firewall) ni la ejecución de pentesting.
En este paso nos debemos centrar en ejecutar todos los pasos establecidos en el diseño del plan. Lo que quiere decir que se tomarán todas las evidencias posibles de los pasos ejecutados y así mismo si se logró evidenciar alguna amenaza que esté presente en la red en algunos de nuestros equipos.
Dentro de los resultados, es muy posible que empieces a aplicar las fases de respuesta a incidentes de seguridad para poder contener la amenaza. Si bien no es el trabajo de la cacería de amenaza, se pueden indicar algunas recomendaciones como de mejorar algunas configuraciones o adquirir alguna solución que disminuya futuros riesgos, destacando que este sería un resultado indirecto, ya que, la mejora continua pertenece al Post-Incident Activity del ciclo de respuesta de incidentes de seguridad.
Figura 2. Ciclo de vida de respuestas ante incidentes
Tal como se mencionó anteriormente, para empezar un buen threat hunting es necesario buscar alguna amenaza explotada dentro de nuestra red que no haya sido detectada. Recuerda que esto no es una auditoría, ni un pentesting y, te puedes apoyar en técnicas de threat intelligence para comenzar las búsquedas.
