¿Qué es Detection Engineering? Del Alert Fatigue a Detecciones que Funcionan

El problema que nadie quiere admitir: tu SOC está ahogado en ruido

Un SOC medio recibe 11.000 alertas al día. De esas, el 45% son falsos positivos. Los analistas investigan menos del 50% del total porque no dan abasto. El resultado es predecible: amenazas reales enterradas bajo una montaña de ruido que nadie puede procesar.

Este fenómeno tiene nombre: alert fatigue. Y no es un problema de personas. Es un problema de ingeniería.

Las organizaciones compran SIEM, EDR, NDR, SOAR. Activan las reglas que vienen por defecto. Añaden feeds de inteligencia. Y esperan que sus analistas N1 sepan distinguir la señal del ruido en turnos de 12 horas, con cientos de alertas en cola. Es un modelo que no escala.

Detection Engineering nació como respuesta a esta realidad. No propone más herramientas ni más analistas. Propone tratar las detecciones como código: con hipótesis, desarrollo, testing, deploy controlado y métricas de calidad.

Qué es Detection Engineering

Detection Engineering es la disciplina de diseñar, construir, testear y mantener reglas de detección de amenazas de forma sistemática. Aplica principios de ingeniería de software al proceso que históricamente fue manual, ad hoc y reactivo.

El término se popularizó en 2019 con el artículo de Palantir titulado "Alerting and Detection Strategy Framework", donde describían cómo su equipo trataba las detecciones como un producto de software con su propio ciclo de vida. Jared Atkinson, uno de los autores, acuñó la idea de que una detección sin tests es equivalente a código sin tests: puede funcionar, pero no lo sabes hasta que falla en producción.

La idea central es simple: las detecciones son código. Y como todo código, necesitan:

• Versionado: cada regla tiene un historial de cambios rastreable.
• Testing: se prueban contra datos reales y simulaciones antes de activarlas.
• Review: otro ingeniero revisa la lógica antes de desplegar.
• Métricas: se mide su rendimiento en producción (falsos positivos, detecciones reales, cobertura).
• Deprecación: se retiran las reglas que ya no aportan valor.

Esto contrasta con el enfoque tradicional donde un analista crea una regla tras un incidente, la activa sin testear y la olvida. Semanas después, esa regla genera cientos de alertas que nadie entiende porque el contexto original se perdió.

El pipeline de Detection Engineering

El proceso de Detection Engineering sigue un pipeline estructurado con fases bien definidas. Cada fase tiene entradas, salidas y criterios de calidad.

1. Threat Intelligence (entrada)

Todo empieza con una amenaza real. No con una idea abstracta de "detectar cosas malas", sino con inteligencia concreta:

• Un informe de amenazas documenta que APT29 está usando DLL sideloading contra el sector energético europeo.
• CISA publica un advisory sobre explotación activa de CVE-2024-XXXX.
• Tu equipo de Threat Hunting identifica un patrón sospechoso en logs de PowerShell.

La fuente de inteligencia define el alcance. Sin amenaza concreta, no hay detección que valga la pena construir.

2. Hipótesis

Con la inteligencia como base, se formula una hipótesis de detección:

"Si un atacante usa DLL sideloading (T1574.002), generará eventos de carga de DLL desde directorios no estándar en procesos firmados por Microsoft. Podemos detectar esto correlacionando eventos Sysmon ID 7 (Image Loaded) con rutas fuera de System32/SysWOW64."

Una buena hipótesis incluye:

• Técnica MITRE ATT&CK que se pretende detectar.
• Fuente de datos necesaria (Sysmon, EDR telemetry, firewall logs).
• Lógica de detección en lenguaje natural.
• Limitaciones conocidas (qué no detectará, posibles evasiones).

3. Desarrollo

La hipótesis se traduce en una regla concreta. Dependiendo del entorno, puede ser:

• Una regla Sigma (formato agnóstico que se compila a múltiples SIEM).
• Una regla YARA (para detección en archivos y memoria).
• Una query KQL/SPL nativa del SIEM (Sentinel, Splunk).
• Una regla Suricata/Snort (para detección en red).

El desarrollo incluye documentación inline: qué detecta, por qué, qué técnica ATT&CK cubre, quién la creó, qué falsos positivos se esperan.

4. Testing

Antes de desplegar, la regla se prueba en tres niveles:

Nivel	Qué se prueba	Herramientas
Unitario	La regla detecta el patrón esperado con datos sintéticos	Sigma test frameworks, logs fabricados
Simulación	La regla detecta la técnica ejecutada en laboratorio	Atomic Red Team, MITRE Caldera, Infection Monkey
Regresión	La regla no genera falsos positivos contra logs de producción históricos	Replay de logs de 30 días en entorno staging

El test de regresión es el más olvidado y el más importante. Una regla que detecta perfectamente en laboratorio pero genera 200 alertas diarias en producción no sirve.

5. Deployment

El despliegue sigue un proceso gradual:

1. Shadow mode: la regla se activa pero no genera alertas visibles. Solo se registran las coincidencias en un log separado.
2. Monitorización: durante 1 a 2 semanas se revisan las coincidencias en shadow mode. Se ajustan umbrales y exclusiones.
3. Activación: la regla pasa a producción y genera alertas reales.
4. Documentación: se actualiza el catálogo de detecciones con la nueva regla.

6. Tuning y mantenimiento

Ninguna regla es "set and forget". El tuning continuo incluye:

• Añadir exclusiones para falsos positivos legítimos (ej: un software de backup que ejecuta PowerShell codificado en base64).
• Ajustar umbrales cuando cambia el entorno (nueva aplicación, nuevo proveedor).
• Actualizar la lógica cuando la amenaza evoluciona.

7. Métricas

Cada regla se mide con indicadores concretos. Sin métricas, no hay ingeniería, solo artesanía.

Detection-as-Code: el cambio de paradigma

Detection-as-Code lleva el pipeline anterior a su conclusión lógica: las reglas de detección viven en un repositorio Git, igual que el código de cualquier aplicación.

Un repositorio típico de detecciones tiene esta estructura:

detections/
├── sigma/
│   ├── credential-access/
│   │   ├── lsass_memory_dump.yml
│   │   └── mimikatz_execution.yml
│   ├── lateral-movement/
│   │   └── psexec_remote_execution.yml
│   └── persistence/
│       └── scheduled_task_creation.yml
├── yara/
│   ├── ransomware/
│   └── infostealers/
├── tests/
│   ├── test_lsass_memory_dump.py
│   └── atomic_red_team_mappings.yml
├── ci/
│   ├── validate_sigma.py
│   └── run_regression.py
└── docs/
    └── detection_catalog.md

El flujo de trabajo es familiar para cualquier desarrollador:

1. Branch: el Detection Engineer crea una rama para la nueva detección.
2. Desarrollo: escribe la regla y sus tests.
3. PR (Pull Request): otro ingeniero revisa la lógica, la cobertura ATT&CK y los falsos positivos esperados.
4. CI/CD: un pipeline automatizado valida la sintaxis, ejecuta tests y comprueba que no hay regresiones.
5. Merge: la regla se despliega automáticamente al SIEM en shadow mode.

Este enfoque resuelve varios problemas crónicos:

• Trazabilidad: cada cambio en una regla tiene autor, fecha y justificación.
• Conocimiento compartido: si el Detection Engineer que creó una regla deja el equipo, la lógica y el contexto permanecen en el repositorio.
• Rollback: si una regla causa problemas, se revierte con un git revert.
• Estandarización: todas las reglas siguen el mismo formato y pasan los mismos controles de calidad.

Roles y skills: quién hace qué

Detection Engineering es un rol distinto al analista SOC tradicional y al Threat Hunter. La siguiente tabla clarifica las diferencias:

Aspecto	Analista SOC	Threat Hunter	Detection Engineer
Foco	Triaje de alertas en tiempo real	Búsqueda proactiva de amenazas sin alerta previa	Crear y mantener las reglas que generan alertas
Temporalidad	Reactivo (responde a alertas)	Proactivo (busca sin alertas)	Preventivo (construye antes del incidente)
Input principal	Cola de alertas del SIEM	Hipótesis basadas en CTI	Inteligencia de amenazas y feedback del SOC
Output principal	Incidentes clasificados y escalados	IOCs, TTPs y hallazgos documentados	Reglas de detección testeadas y desplegadas
Skills técnicos	Investigación forense, herramientas SIEM	Data analysis avanzado, scripting	Programación, CI/CD, testing, MITRE ATT&CK
Métricas	MTTR, alertas investigadas, escalaciones	Amenazas descubiertas, cobertura explorada	MTTD, tasa de falsos positivos, cobertura ATT&CK

En organizaciones maduras, los tres roles se alimentan mutuamente:

• El Threat Hunter descubre una técnica nueva en la red y documenta los indicadores.
• El Detection Engineer convierte esos indicadores en una regla testeada y desplegada.
• El analista SOC consume la alerta cuando se dispara y escala si es un incidente real.
• El feedback del SOC (falsos positivos, detecciones perdidas) vuelve al Detection Engineer para mejorar las reglas.

Skills clave del Detection Engineer

• Programación: Python, regex, queries SIEM (KQL, SPL, Lucene).
• Formatos de detección: Sigma, YARA, Suricata, Snort, reglas EDR nativas.
• MITRE ATT&CK: conocimiento profundo de tácticas, técnicas y subtécnicas.
• Ingeniería de software: Git, CI/CD, testing automatizado, code review.
• Telemetría: entender qué datos genera cada fuente (Sysmon, Windows Event Logs, EDR, NDR, cloud logs).
• Adversary tradecraft: comprender cómo operan los atacantes para anticipar técnicas de evasión.

Herramientas del trade

Lenguajes y formatos de detección

Herramienta	Tipo	Uso principal
Sigma	Reglas genéricas (YAML)	Detecciones en logs, compilables a cualquier SIEM
YARA	Reglas de pattern matching	Detección de malware en archivos y memoria
Suricata / Snort	IDS/IPS rules	Detección en tráfico de red
KQL (Kusto)	Query language	Microsoft Sentinel, Defender
SPL	Query language	Splunk
EQL	Event Query Language	Elastic Security

Plataformas de detección

Plataforma	Categoría
Splunk / Sentinel / Elastic	SIEM
CrowdStrike / SentinelOne / Defender for Endpoint	EDR
Zeek / Suricata	NDR / Network monitoring
Wazuh	SIEM open-source + HIDS

Testing y simulación

Herramienta	Propósito
Atomic Red Team	Ejecución de técnicas ATT&CK individuales para validar detecciones
MITRE Caldera	Simulación de adversarios automatizada
Infection Monkey	Testing de segmentación de red y detección de movimiento lateral
DetectionLab	Entorno de laboratorio preconfigurado con logging completo
Sigma CLI	Validación de sintaxis y compilación de reglas Sigma

Frameworks: medir cobertura y madurez

MITRE ATT&CK como mapa de cobertura

MITRE ATT&CK proporciona el vocabulario estándar para mapear detecciones. Cada regla se asocia a una o varias técnicas (T-codes), lo que permite visualizar la cobertura del SOC como un heatmap de la matriz ATT&CK.

Un heatmap típico muestra:

• Verde: técnica cubierta por al menos una detección testeada.
• Amarillo: detección existe pero con alta tasa de falsos positivos o sin testear.
• Rojo: técnica sin cobertura alguna.
• Gris: técnica no aplicable al entorno.

DeTT&CT

DeTT&CT (Detect Tactics, Techniques & Combat Threats) es un framework open-source que permite:

• Mapear la visibilidad de datos (qué telemetría tienes por técnica).
• Mapear la cobertura de detección (qué reglas cubren qué técnicas).
• Comparar la cobertura contra threat groups específicos (ej: "¿detectamos el 70% de las técnicas de APT29?").
• Generar una puntuación de detección por técnica (de 0: sin datos, a 5: detección automática con alta confianza).

La combinación de ATT&CK + DeTT&CT da al Detection Engineer un mapa objetivo de dónde están los gaps y dónde invertir esfuerzo.

Métricas de Detection Engineering

Sin métricas, Detection Engineering es solo un título bonito. Las métricas esenciales son:

MTTD (Mean Time to Detect)

Tiempo medio desde que ocurre una actividad maliciosa hasta que se genera una alerta. Es la métrica reina. Un SOC con reglas bien diseñadas puede tener MTTD de minutos. Un SOC con reglas genéricas puede tardar días o semanas en detectar (si detecta).

Tasa de falsos positivos

Porcentaje de alertas que resultan ser benignas tras investigación. El objetivo realista es mantenerla por debajo del 20%. Reglas con tasa superior al 50% deben retirarse o reescribirse.

Cobertura ATT&CK

Porcentaje de técnicas relevantes para tu entorno que tienen al menos una detección activa y testeada. No se trata de cubrir las 200+ técnicas, sino las que usan los threat actors que apuntan a tu sector.

Detection health

Métricas operativas de cada regla individual:

Métrica	Qué mide
Alertas/día	Volumen generado por la regla
True positive rate	Porcentaje de alertas que son incidentes reales
Última vez que disparó	Detecta reglas "muertas" que nunca coinciden
Última revisión	Detecta reglas abandonadas sin mantenimiento

Detection Engineering Maturity Model

Ryan Stillions propuso en 2014 el concepto de Detection Maturity Level (DML). Adaptado a la práctica moderna, el modelo tiene cinco niveles:

Nivel 0: Inicial

• Detecciones basadas exclusivamente en firmas de vendor (antivirus, IDS por defecto).
• Sin reglas custom.
• Sin métricas.
• Dependencia total de lo que el fabricante considere malicioso.

Nivel 1: Reactivo

• Se crean reglas custom tras incidentes.
• Sin proceso formal de testing.
• Reglas en la consola del SIEM, sin versionado.
• Las reglas se acumulan sin mantenimiento ni deprecación.

Nivel 2: Definido

• Proceso documentado para crear, testear y desplegar detecciones.
• Reglas en repositorio Git (Detection-as-Code).
• Mapping a MITRE ATT&CK.
• Revisión por pares (PR review) antes de desplegar.
• Métricas básicas (alertas por regla, falsos positivos).

Nivel 3: Gestionado

• Pipeline CI/CD automatizado para validación y despliegue.
• Testing con Atomic Red Team o equivalente antes de cada despliegue.
• Heatmap de cobertura ATT&CK actualizado y visible.
• Proceso de tuning continuo con feedback del SOC.
• MTTD medido y reportado.
• Detecciones priorizadas por threat intelligence (no por lo que es fácil detectar, sino por lo que es relevante).

Nivel 4: Optimizado

• Detecciones basadas en comportamiento, no solo en IOCs.
• Análisis de gaps sistemático contra threat groups específicos del sector.
• Detecciones testeadas con red team / purple team periódicamente.
• Métricas de detección integradas en el reporting ejecutivo.
• Mejora continua basada en datos: las métricas dirigen las prioridades.
• Threat Hunting alimenta directamente el pipeline de Detection Engineering.

La mayoría de organizaciones están entre el nivel 0 y el 1. Llegar al nivel 2 (Detection-as-Code con PR reviews) ya supone una mejora transformacional.

Por dónde empezar

Si tu SOC está en nivel 0 o 1, estos son los pasos con mayor impacto:

1. Audita tus detecciones actuales: lista todas las reglas activas en tu SIEM. Clasifícalas por fuente (vendor default, custom, comunidad). Identifica cuántas no han disparado nunca y cuántas generan más de 100 alertas diarias.

2. Elige 10 técnicas ATT&CK prioritarias: basándote en los threat actors que apuntan a tu sector (consulta los reportes de MITRE, CrowdStrike, Mandiant). Evalúa si tienes detecciones para esas 10 técnicas.

3. Crea tu primer repositorio de detecciones: un repo Git con estructura básica (carpeta por táctica, reglas en formato Sigma, un README con convenciones).

4. Escribe tu primera detección con el pipeline completo: hipótesis, desarrollo en Sigma, test con Atomic Red Team, shadow mode, activación, documentación.

5. Implementa métricas básicas: alertas por regla por día, tasa de falsos positivos de las 10 reglas más ruidosas.

6. Establece el ritual de review: cada nueva detección pasa por un PR con revisión de al menos otra persona del equipo.

El objetivo no es la perfección desde el día uno. Es pasar de "activamos reglas y esperamos" a "diseñamos, testeamos y medimos detecciones como un producto de ingeniería".

Recursos y referencias

Artículos fundacionales

• Palantir (2019): Alerting and Detection Strategy Framework. El artículo que popularizó el término y el enfoque.
• Ryan Stillions (2014): The DML Model. El primer modelo de madurez para detecciones.
• Jared Atkinson: conferencias y posts sobre Detection Engineering como disciplina.
• Florian Roth (creador de Sigma y YARA rules): The Detection Engineering Lifecycle.

Repositorios open-source

• SigmaHQ/sigma: repositorio comunitario con miles de reglas Sigma mapeadas a ATT&CK.
• redcanaryco/atomic-red-team: tests individuales para cada técnica ATT&CK.
• rabobank-cdc/DeTTECT: framework para mapear visibilidad y cobertura contra ATT&CK.
• splunk/security_content: detecciones de Splunk con documentación y tests.

Frameworks y estándares

• MITRE ATT&CK: matriz de tácticas y técnicas de adversarios.
• MITRE D3FEND: contramedidas técnicas mapeadas a ATT&CK.
• MITRE CAR (Cyber Analytics Repository): analytics de detección con pseudocódigo.

Siguientes artículos en esta serie

• Reglas Sigma: sintaxis, estructura y tu primer caso de detección.
• Reglas YARA: anatomía de una regla y tu primera detección de malware.
• Detection-as-Code avanzado: CI/CD, testing automatizado y métricas en producción.