Construir un Programa de Detection Engineering: De Cero a Producción

Por qué necesitas un programa de Detection Engineering

La mayoría de organizaciones tienen detecciones. Pocas tienen un programa de detección. La diferencia no es semántica: es la diferencia entre tener reglas dispersas en un SIEM sin dueño claro, y tener un proceso ingenieril que produce detecciones de calidad medible, testeadas antes de producción y mantenidas a lo largo del tiempo.

Sin un programa formal, las detecciones nacen reactivas (post-incidente), se acumulan sin revisión, generan falsos positivos que nadie ajusta, y pierden efectividad conforme el entorno cambia. El resultado es un SOC que trabaja contra sus propias herramientas en lugar de contra los adversarios.

Un programa de Detection Engineering resuelve esto estableciendo tres principios:

1. Las detecciones son código. Se versionan, revisan, testean y despliegan con el mismo rigor que el software.
2. La cobertura se mide. No basta con "tener reglas". Se mapean a amenazas reales (MITRE ATT&CK) y se identifican los gaps.
3. El ciclo de vida es continuo. Las reglas se crean, se mejoran, se miden y se retiran. Nunca se abandonan.

Este artículo traza el camino desde cero hasta un programa maduro, dividido en cuatro fases con hitos concretos, más la estructura de equipo, herramientas y errores comunes que debes evitar.

Prerrequisitos: qué necesitas antes de empezar

Antes de escribir la primera regla dentro de un programa formal, necesitas tres cosas en su sitio.

Un SIEM o plataforma de detección operativa. No tiene que ser perfecto ni estar completamente configurado, pero necesitas un lugar donde desplegar reglas y ver resultados. Puede ser Elastic SIEM, Splunk, Microsoft Sentinel, CrowdStrike Falcon LogScale o cualquier plataforma que acepte reglas personalizadas.

Fuentes de log mínimas. Sin datos, no hay detección. Los logs esenciales para arrancar son: eventos de endpoint (Sysmon en Windows, auditd en Linux), logs de autenticación (Active Directory, IdP), logs de red (firewall, proxy, DNS) y logs de correo electrónico. No necesitas tenerlo todo el primer día, pero necesitas al menos endpoints y autenticación.

Conocimiento básico de MITRE ATT&CK. El framework sirve como lenguaje común para priorizar qué detectar. No necesitas dominarlo al completo, pero el equipo debe entender la estructura de tácticas, técnicas y subtécnicas, y saber navegar la matriz para identificar qué técnicas son relevantes para su entorno.

Si alguno de estos tres no está resuelto, resuélvelo primero. Intentar montar un programa de Detection Engineering sin logs o sin plataforma es construir sobre arena.

Fase 1: Fundación (primeros 30 días)

El objetivo de esta fase es establecer la infraestructura mínima y producir las primeras detecciones funcionales. No busques perfección. Busca el primer ciclo completo: escribir, testear, desplegar, medir.

Semana 1 a 2: Repositorio y estructura

Crea un repositorio Git dedicado para detecciones. No lo mezcles con código de aplicación ni con configuración de infraestructura. La estructura inicial:

detection-repo/
├── rules/
│   ├── sigma/           # Reglas Sigma organizadas por táctica
│   ├── yara/            # Reglas YARA para artefactos
│   └── custom/          # Reglas nativas del SIEM
├── tests/
│   ├── unit/            # Datos de prueba por regla
│   └── validation/      # Scripts de validación de sintaxis
├── docs/
│   ├── playbooks/       # Procedimientos de respuesta por alerta
│   └── coverage/        # Matriz de cobertura ATT&CK
├── scripts/
│   └── deploy.sh        # Script de despliegue al SIEM
└── README.md

Documenta desde el primer día las convenciones de naming, la estructura de metadatos de cada regla (autor, fecha, técnica ATT&CK, severidad, estado) y el proceso para proponer una nueva regla.

Semana 2 a 4: Primeras 10 reglas

Selecciona las 10 primeras reglas basándote en dos criterios: relevancia para tu entorno y disponibilidad de logs. No empieces por técnicas exóticas. Empieza por lo que realmente te pueden atacar y que puedes detectar con los datos que ya tienes.

Una selección sólida para la mayoría de entornos:

1. Ejecución de PowerShell codificado (T1059.001)
2. Creación de servicios sospechosos (T1543.003)
3. Acceso a LSASS (T1003.001)
4. Ejecución desde directorio temporal (T1204.002)
5. Modificación de tareas programadas (T1053.005)
6. Conexiones a dominios recién registrados (T1071.001)
7. Fuerza bruta contra autenticación (T1110.001)
8. Descarga de ejecutables por certutil/bitsadmin (T1105)
9. Movimiento lateral via PsExec/SMB (T1021.002)
10. Deshabilitar Windows Defender (T1562.001)

Para cada regla, escribe en formato Sigma (portabilidad entre plataformas), incluye al menos un caso de prueba positivo (debe disparar la alerta) y uno negativo (no debe disparar), y documenta el playbook de respuesta asociado.

Testing básico

No necesitas un framework complejo. En esta fase, testear significa:

• Validar que la regla tiene sintaxis correcta (sigma check, yara -w).
• Ejecutar el ataque simulado con Atomic Red Team o manualmente en un lab.
• Confirmar que la alerta aparece en el SIEM con la información esperada.
• Verificar que la actividad legítima equivalente (si existe) no dispara la regla.

Fase 2: Proceso (días 30 a 90)

El objetivo de esta fase es pasar de "un ingeniero que escribe reglas" a "un proceso que produce detecciones de calidad predecible".

CI/CD para detecciones

Configura un pipeline de integración continua en el repositorio. El pipeline mínimo:

1. Lint y validación de sintaxis en cada push. Sigma tiene sigma check, YARA tiene validadores nativos. Si usas reglas nativas del SIEM, escribe un validador de formato.
2. Ejecución de tests unitarios. Cada regla tiene datos de prueba asociados (logs que deben disparar la alerta y logs que no). El pipeline ejecuta las reglas contra estos datos y valida el resultado.
3. Review obligatorio. Configura branch protection en main. Toda regla nueva o modificada pasa por pull request con al menos un reviewer.
4. Despliegue automatizado. Cuando un PR se aprueba y mergea, el pipeline despliega la regla al SIEM de staging. El paso a producción puede ser automático o requerir aprobación manual, según tu tolerancia al riesgo.

Proceso de revisión (PR reviews)

Define qué se revisa en cada pull request de detección:

• Lógica de detección. La regla detecta lo que dice que detecta. No hay errores lógicos (operadores AND/OR invertidos, campos incorrectos).
• Falsos positivos. Se han considerado escenarios legítimos que podrían disparar la regla. Se documentan las excepciones.
• Metadatos completos. Técnica ATT&CK, severidad, autor, fecha, estado, playbook de respuesta referenciado.
• Cobertura de tests. Existen casos positivos y negativos.
• Impacto en rendimiento. Reglas con muchos wildcards, regex complejas o lookups masivos se señalan para revisión de performance.

Matriz de cobertura ATT&CK

Crea un mapa de cobertura que relacione cada regla con las técnicas ATT&CK que cubre. Esto te permite ver de un vistazo dónde tienes cobertura y dónde hay gaps. Herramientas como ATT&CK Navigator permiten exportar el mapa como imagen o JSON.

Actualiza la matriz cada vez que añades, modificas o retiras una regla. Es el documento vivo más importante del programa.

Fase 3: Escala (meses 3 a 6)

El objetivo de esta fase es multiplicar la capacidad del programa sin multiplicar proporcionalmente el esfuerzo manual.

Automatización de la ingesta de inteligencia

Conecta el programa a fuentes de Threat Intelligence para priorizar qué detectar. El flujo:

1. Feeds CTI (CISA KEV, MITRE ATT&CK updates, informes de amenazas sectoriales) alimentan una cola de técnicas a evaluar.
2. Para cada técnica, se evalúa: hay logs disponibles, es relevante para nuestro entorno, existe ya una detección.
3. Si es relevante y no está cubierta, se crea un ticket con la especificación para una nueva regla.

Esto convierte la priorización de "qué siente el equipo" a "qué dicen los datos de amenazas reales".

Dashboard de métricas

Sin métricas, no sabes si el programa funciona. Las métricas esenciales:

Métrica	Qué mide	Objetivo
Reglas en producción	Volumen del catálogo	Crecimiento sostenido
Cobertura ATT&CK (%)	Técnicas cubiertas / técnicas relevantes	>60% en tácticas críticas
Tasa de falsos positivos	FP / total alertas por regla	Menos de 10% por regla
Tiempo medio de creación	Días desde ticket hasta producción	Menos de 5 días laborables
Reglas sin activar en 90d	Detecciones que no han disparado nunca	Investigar o retirar
Detecciones que generaron incidente real	True positives con impacto	Crecimiento

Publica el dashboard donde el equipo SOC pueda verlo. La transparencia genera confianza en el programa.

Priorización threat-informed

Cruza tres fuentes para decidir qué detectar primero:

1. Threat landscape. Qué técnicas usan los actores que atacan tu sector y región (informes sectoriales, feeds CTI).
2. Superficie de ataque. Qué tecnologías tienes expuestas (Windows, Linux, cloud, OT) y qué logs tienes disponibles.
3. Gaps de cobertura. Qué técnicas relevantes no tienen detección activa en tu matriz.

La intersección de las tres te da la lista priorizada. Las técnicas que aparecen en las tres listas son las que debes cubrir primero.

Fase 4: Madurez (meses 6 a 12)

El objetivo de esta fase es hacer que el programa sea autosuficiente, con calidad controlada y mejora continua sin depender de heroísmos individuales.

Detection-as-Code

En esta fase, toda la lógica de detección vive en el repositorio como código. Esto incluye:

• Reglas en formato Sigma/YARA/nativo con metadatos estandarizados.
• Tests automatizados que se ejecutan en cada cambio.
• Playbooks de respuesta vinculados a cada regla.
• Configuración de despliegue como código (Terraform, Ansible, scripts) que define cómo se aplican las reglas al SIEM/EDR.
• Excepciones documentadas y versionadas (no hardcodeadas en el SIEM).

El estado del SIEM se puede reconstruir desde el repositorio. Si pierdes la configuración del SIEM, puedes re-desplegar todas las reglas activas desde Git.

Testing automatizado avanzado

Más allá de los tests unitarios, implementa:

• Tests de regresión. Cada vez que modificas una regla, se ejecuta contra el historial de alertas pasadas para verificar que no rompe detecciones que antes funcionaban.
• Simulación periódica. Ejecuta Atomic Red Team o MITRE Caldera de forma programada (semanal o mensual) contra un entorno de lab para validar que las detecciones siguen funcionando.
• Test de rendimiento. Mide el impacto de las reglas en el SIEM (tiempo de búsqueda, uso de recursos). Reglas costosas se optimizan o se limitan en alcance.

Mejora continua

Establece un ciclo recurrente (mensual o trimestral):

1. Revisar métricas. Identificar reglas con tasa de FP alta, reglas sin actividad, gaps de cobertura nuevos.
2. Tuning. Ajustar reglas con FP alto. Documentar cada ajuste y la razón.
3. Deprecación. Retirar reglas que ya no aportan valor (amenaza mitigada, tecnología retirada, redundancia con otra regla mejor).
4. Retrospectiva. En cada incidente real, evaluar si existía una detección, si funcionó, y qué se puede mejorar.

Estructura de equipo

No hay un modelo único. La estructura depende del tamaño de la organización y la madurez del SOC.

Modelo 1: Detection Engineer solo (1 a 3.000 endpoints)

Un único ingeniero que combina análisis SOC con creación de detecciones. Dedica el 40 a 60% de su tiempo a escribir y mantener reglas, el resto a triaje. Funciona para organizaciones pequeñas con un SIEM y una o dos plataformas de detección.

Riesgo: dependencia de una sola persona. Si se va, el programa se detiene. Documenta todo desde el primer día.

Modelo 2: Embedded en SOC (3.000 a 15.000 endpoints)

Dos o tres Detection Engineers dentro del equipo SOC. Colaboran con los analistas N2/N3 que identifican gaps y proponen nuevas detecciones. Los DE implementan, testean y despliegan. Los analistas validan en producción.

Ventaja: proximidad al feedback real. Desventaja: las prioridades del SOC (incidentes activos) pueden desplazar el trabajo de ingeniería.

Modelo 3: Equipo dedicado (>15.000 endpoints)

Equipo independiente con su propio manager, métricas y roadmap. Interactúa con SOC, Threat Intelligence, Red Team e Infraestructura como equipos cliente. Produce detecciones como producto interno.

Roles dentro del equipo: Lead DE (priorización y arquitectura), DE Senior (reglas complejas, mentoring), DE Junior (reglas estándar, testing), y opcionalmente un Automation Engineer (CI/CD, tooling).

Skills y contratación

Lo que buscas en un Detection Engineer no es lo mismo que en un analista SOC. Las competencias clave:

Conocimiento de ataques. Entiende cómo funcionan las técnicas de los adversarios, no solo el nombre. Sabe qué genera un ataque en los logs a nivel de campos específicos. Es capaz de reproducir un ataque en lab para validar una detección.

Pensamiento de ingeniero. Trata las detecciones como software: las versiona, las testea, las documenta, las mide. No las escribe y se olvida.

Familiaridad con datos. Sabe qué logs existen, qué campos contienen, cómo se normalizan. Puede escribir queries complejas en el lenguaje del SIEM.

Comunicación. Documenta sus reglas con claridad. Explica a un analista SOC qué hace la regla, qué significa cuando dispara, y qué pasos seguir. Puede justificar prioridades ante management.

En la entrevista, pide que escriban una regla de detección para una técnica concreta. No evalúes solo la sintaxis. Evalúa cómo razonan: preguntan qué logs tienen disponibles, consideran falsos positivos, definen qué constituye "verdadero positivo".

Stack de herramientas

Categoría	Herramientas	Propósito
Repositorio	GitHub, GitLab	Versionado, PR reviews, CI/CD
Formato de reglas	Sigma, YARA, Snort/Suricata	Portabilidad entre plataformas
SIEM/Detección	Elastic SIEM, Splunk, Sentinel, Falcon LogScale	Despliegue y ejecución
Testing adversarial	Atomic Red Team, MITRE Caldera, Stratus Red Team	Simulación de ataques
Cobertura	ATT&CK Navigator, DeTT&CT	Visualización de gaps
CI/CD	GitHub Actions, GitLab CI	Automatización del pipeline
Documentación	Confluence, Notion, Markdown en repo	Playbooks y procedimientos
Métricas	Grafana, Kibana, dashboards nativos del SIEM	Monitorización del programa

La mayoría de estas herramientas son open source o tienen tier gratuito. No necesitas presupuesto significativo para empezar.

Modos de fallo comunes

Estos son los errores que hunden programas de Detection Engineering. Evítalos conscientemente.

Escribir reglas sin testear. La regla pasa a producción sin validación. Genera falsos positivos masivos. El equipo SOC pierde confianza en el programa. Una vez perdida, es difícil de recuperar.

No medir. Sin métricas, no puedes demostrar valor. Cuando llegan los recortes de presupuesto, los programas sin datos medibles son los primeros en caer.

Acumular sin deprecar. Cada regla tiene coste operativo (alertas que alguien investiga, recursos de SIEM que consume). Si solo acumulas y nunca retiras, el catálogo se convierte en una carga. Reglas sin actividad en 90 días deben evaluarse para deprecación.

Copiar reglas sin adaptar. Tomar reglas de SigmaHQ o repositorios públicos y activarlas tal cual. Funcionan como punto de partida, pero necesitan adaptación a tu entorno: nombres de campos, exclusiones de tu infraestructura, umbrales específicos de tu baseline.

Ignorar el feedback del SOC. Los analistas que investigan las alertas son tu mejor fuente de información sobre calidad. Si reportan falsos positivos y nadie ajusta la regla, dejan de reportar. Y dejan de investigar las alertas de ese tipo.

Priorizar volumen sobre calidad. Tener 500 reglas no es mejor que tener 50 si las 500 generan ruido. Mide por true positive rate y cobertura de técnicas críticas, no por número total de reglas.

ROI y justificación ante dirección

Para que el programa sobreviva, necesitas que la dirección entienda el retorno. Estos son los argumentos que funcionan.

Reducción de MTTR (Mean Time to Respond). Detecciones de calidad con playbooks asociados reducen el tiempo de respuesta porque el analista sabe exactamente qué hacer cuando la alerta dispara. Mide el MTTR antes y después del programa.

Reducción de falsos positivos. Menos FP significa menos tiempo perdido. Si un analista N1 gasta 15 minutos por falso positivo y reduces los FP en un 30%, puedes calcular las horas recuperadas al mes.

Cobertura medible de amenazas. La matriz ATT&CK permite decir "cubrimos el 65% de las técnicas relevantes para nuestro sector". Es un lenguaje que los CISOs entienden y pueden reportar a su board.

Prevención de incidentes. Cada detección que atrapa un ataque real antes de que cause daño tiene un valor calculable. Un ransomware detenido en la fase de acceso inicial ahorra el coste del incidente completo (media: 4.45 millones de dolares segun IBM Cost of a Data Breach 2023).

Cumplimiento normativo. ENS, NIS2, DORA y otros marcos regulatorios exigen capacidades de detección y respuesta. Un programa formal con métricas y evidencias facilita las auditorías.

El formato más efectivo para presentar esto es un dashboard trimestral con tres secciones: estado del catálogo (reglas activas, cobertura ATT&CK), rendimiento operativo (FP rate, MTTR, true positives) y roadmap del siguiente trimestre.

Recursos y referencias

Frameworks y metodologías:

• Palantir Alerting and Detection Strategy Framework (el paper original que popularizó DE)
• MITRE ATT&CK (matriz de técnicas adversariales)
• Detection Maturity Level (DML) model de Ryan Stillions
• Pyramid of Pain de David J. Bianco (jerarquía de indicadores)

Repositorios de reglas:

• SigmaHQ (repositorio comunitario de reglas Sigma con miles de detecciones)
• Elastic Detection Rules (reglas del equipo Elastic)
• Splunk Security Content (reglas del equipo Splunk Threat Research)
• YARA Rules (repositorio comunitario de reglas YARA)

Herramientas de testing:

• Atomic Red Team (Red Canary, tests unitarios de ataques mapeados a ATT&CK)
• MITRE Caldera (plataforma de adversary emulation automatizada)
• Stratus Red Team (simulación de ataques cloud)
• DeTT&CT (herramienta para mapear cobertura de detección y visibilidad)

Lecturas recomendadas:

• "Crafting the InfoSec Playbook" de Jeff Bollinger, Brandon Enright y Matthew Valites
• Blog de Jared Atkinson sobre Detection Engineering en SpecterOps
• Serie "Detection Engineering" de Florian Roth (creador de Sigma y YARA)
• SANS Institute: "Building a Detection Engineering Program" (whitepaper)

Un programa de Detection Engineering no se construye en un sprint. Se construye con consistencia a lo largo de meses, midiendo cada paso y ajustando en función de los datos. El primer paso no es perfecto. Es funcional. Y desde ahí, iteras.