sims718718/unifiedthreathuntingDocumenta una metodología de threat hunting estructurada y repetible que abarca desencadenantes, hipótesis SMART, criterios de viabilidad, alcance, planes de caza y reporte de resultados para equipos de seguridad.
Como Cazador de Amenazas Principal, se me encomendó la tarea de construir un Programa de Caza de Amenazas desde cero. Esto implicó una gran cantidad de reflexión sobre qué es realmente la caza de amenazas y cómo traducirla en resultados significativos. Se dedicaron muchas horas a leer diversas metodologías sobre caza de amenazas, ingeniería de detección, Inteligencia de Amenazas Cibernéticas (CTI), forense, e incluso la experiencia de mi tiempo en la Fuerza Aérea de los Estados Unidos. Sin embargo, a través de la construcción de un programa, me di cuenta de que necesitaba un proceso, un Proceso Unificado de Caza de Amenazas. Desarrollé este proceso para proporcionar una forma estructurada y definida de cazar y, en última instancia, de entregar resultados significativos para la organización.
graph LR
Z[Step 0: Environment Context] --> A[Triggering Event]
A --> B[Hypothesis Development]
B --> C[Initial Assessment]
C --> D[Feasibility Assessment]
D --> E[Define Scope & Objectives]
E --> F[Formalize Hunt Plan]
F --> G[Execute Hunt]
G --> H[Document Outcomes]
H --> I[Report & Iterate]
I --> A
La búsqueda de amenazas es la búsqueda proactiva de amenazas que eludieron tus controles. Esa definición está establecida; cómo ejecutarla como un programa no lo está. Este proceso es una síntesis, y la tabla es el registro honesto de la misma:
| Fuente | Qué aporta aquí |
|---|---|
| Sqrrl / Hunting Maturity Model (Bianco) | El bucle central y la escala de madurez utilizada en Maturity & Metrics |
| TaHiTI | El disparador como el verdadero punto de partida, y la transferencia a procesos adyacentes al cierre |
| PEAK | La tipificación de cacerías (hipótesis / línea base / asistida por modelo) y el cierre orientado a resultados "actuar con conocimiento" |
| AIMOD2 | La premisa de brecha asumida y las categorías de resultados tipificadas |
| OTHF | El marco operativo para ejecutar cacerías como una función de equipo repetible |
| Este proceso añade | Paso 0 Contexto del Entorno · una puerta estricta de viabilidad GO / NO-GO / CONDICIONAL · Jira Epic/Story/Task con resultados tipificados · una hipótesis con compuerta de rúbrica y una transferencia de detección especificada |
Los diferenciadores son la última fila. Todo lo demás se apoya en el trabajo de otros, citado en Referencias.
Existen diversos métodos descritos para llevar a cabo operaciones de cacería: estructurados, no estructurados, enfocados en TTPs, enfocados en inteligencia, basados en datos, etc. Aunque este Proceso Unificado de Búsqueda de Amenazas pueda parecer estructurado, eso no significa que tu hipótesis no pueda estar impulsada por datos de manera no estructurada. Este proceso pretende incorporar diversos tipos de búsqueda de amenazas, permitiendo un enfoque modular. Utilizaríamos todas estas técnicas para asegurarnos de probar a fondo nuestra hipótesis.
El objetivo es un enfoque modular de la búsqueda de amenazas donde no existe una talla única. Utiliza todas las técnicas a tu disposición.
En la práctica, el tipo de cacería que elijas depende de dónde estés comenzando en la cadena DAIKI (Datos → Información → Conocimiento → Perspicacia):
| Tipo de Cacería | Punto de Partida | Características |
|---|---|---|
| Exploratoria (EDA) | Datos brutos | Establecimiento de línea base, comprensión de la forma de los datos, sin hipótesis previa |
| Basada en Hipótesis (HBO) | Conciencia situacional | Prueba de escenarios de ataque creíbles basados en el conocimiento del equipo |
| Informada por Amenazas (TIO) | CTI accionable | Impulsada por inteligencia, enfoque en actor conocido o TTP |
| Operaciones Púrpura (DPO) | Perspectiva del equipo rojo | Validación conjunta ofensiva/defensiva |
Siguiendo los principios de la ciencia de datos, independientemente del tipo de cacería, deberías aspirar a explorar y comprender las fuentes de datos relevantes para tu cacería. La carpeta /Data_Analysis en este repositorio contiene técnicas de apoyo y notebooks para esa fase de exploración.
Además, la Inteligencia de Amenazas, ya sea un punto de partida o no, está arraigada en todo el proceso para ayudar a impulsar las operaciones.Threat Intelligence
Nota: Aunque normalmente querrás centrarte en comportamientos o TTPs, los IoCs tienen su mérito si son verdaderamente accionables y oportunos. Aunque cazar IoCs en un entorno no es realmente búsqueda de amenazas, aún pueden proporcionar información útil y otro punto de partida. Pueden ser parte del ciclo de cacería, pero no la cacería completa en sí misma.
Antes de que comience cualquier cacería, captura el entorno para que cada artefacto posterior (consultas, nombres de campos, decisiones de alcance) esté adaptado a donde realmente trabajas en lugar de estar escrito de forma genérica. Añadí esto como un paso explícito porque seguía viendo planes de cacería que hacían referencia a fuentes de datos que nadie tenía, o consultas escritas en el dialecto equivocado por completo. Unos minutos aquí ahorran horas después.
Como mínimo, documenta:
| Contexto | Por Qué Importa |
|---|---|
| SIEM / Plataforma de Datos | Splunk SPL, KQL, Elastic DSL y Chronicle dan forma cada uno a cada consulta que escribes |
| Plataforma EDR | CrowdStrike, SentinelOne, Defender for Endpoint usan cada uno nombres de campos de telemetría diferentes |
| Tipo de Entorno | On-prem, nativo de la nube (AWS/Azure/GCP) o híbrido cambia qué logs existen siquiera |
| Vertical de la Industria | Determina qué actores de amenaza son realísticamente relevantes |
| Ventanas de Retención de Logs | Determina qué rangos de tiempo son realmente factibles de consultar |
| Nivel de Madurez de Cacería | Los cazadores primerizos necesitan andamiaje; los equipos experimentados quieren un esqueleto |
Documenta esto como un bloque Environment Profile en la parte superior del Epic. Si vas rápido, el mínimo absoluto es plataforma SIEM y tipo de entorno, cualquier cosa menos y tus consultas serán genéricas.
¿Cazando a través de múltiples organizaciones? (MSSP/MDR, subsidiarias federadas o una plataforma SIEM compartida.) Mantén un perfil por inquilino en un registro
tenants/<id>/profile.yamly haz que cada Epic referencietenant: <id>en lugar de incrustar el perfil. Antes de la viabilidad, verifica la autorización: un inquilino sin cobertura de RoE/contrato, o una acción planificada fuera de susallowed_actions, es NO AUTORIZADO y se detiene ahí. Los equipos de una sola organización pueden omitir esto. Consulta Multi-Tenant Operation.
Tomando prestado del marco TaHiTI, la búsqueda de amenazas comienza con un evento disparador. Estos eventos justifican la iniciación de una cacería. Según TaHiTI, los disparadores pueden incluir:
Para nuestra organización, utilizamos estos junto con algunos disparadores adicionales como requisitos directos de las partes interesadas y divulgaciones de vulnerabilidades que afectan al entorno.
Algunos marcos comienzan la búsqueda de amenazas con la Hipótesis inicial (paso 2 aquí), pero yo pregunto: ¿cómo llegas a esa hipótesis en primer lugar?