Metricas de Detection Engineering: Medir lo que Importa

Por que medir: el problema de los programas sin datos

Un equipo de Detection Engineering sin metricas opera a ciegas. Escribe reglas, las despliega en el SIEM y espera que funcionen. Cuando un incidente escala, no puede responder preguntas basicas: cuanto tardo la deteccion, que tecnicas del atacante no tenian cobertura, cuantas alertas reales se perdieron entre el ruido de falsos positivos.

Sin datos, las decisiones se toman por intuicion. Se priorizan reglas para amenazas que suenan peligrosas en lugar de las que realmente afectan al sector de la organizacion. Se invierte tiempo en optimizar detecciones que ya funcionan bien mientras las lagunas criticas permanecen abiertas. Y cuando llega la pregunta del CISO (cuanto hemos mejorado este trimestre), la respuesta es un encogimiento de hombros.

Medir no es un ejercicio burocratico. Es la diferencia entre un programa de deteccion que evoluciona y uno que acumula reglas sin direccion.

Las 4 categorias de metricas

Las metricas de Detection Engineering se organizan en cuatro categorias, cada una respondiendo una pregunta distinta:

Categoria	Pregunta clave
Cobertura	Cuanto del panorama de amenazas podemos detectar?
Calidad	Las detecciones que tenemos, funcionan bien?
Eficiencia	Cuanto tardamos en detectar y responder?
Impacto	Que diferencia tangible hace el programa?

Un programa maduro mide las cuatro. Uno que empieza deberia enfocarse primero en cobertura y calidad, porque sin saber que detectas y si lo que detectas es fiable, las metricas de eficiencia e impacto carecen de contexto.

Metricas de cobertura

Porcentaje de cobertura ATT&CK

La metrica mas visual y la mas malinterpretada. El porcentaje de tecnicas MITRE ATT&CK para las que existe al menos una regla de deteccion activa.

Formula basica:

Cobertura ATT&CK (%) = (Tecnicas con >= 1 regla activa / Total tecnicas relevantes) x 100

La clave esta en "relevantes". MITRE ATT&CK tiene mas de 200 tecnicas y 600 subtecnicas. Ninguna organizacion necesita cubrir todas. Un hospital no prioriza las mismas tecnicas que un banco o una empresa de energia.

Cobertura ponderada (recomendada):

Asigna un peso a cada tecnica segun la frecuencia con que la usan los actores relevantes para tu sector. Si los grupos APT que atacan tu industria usan T1566 (Phishing) y T1059 (Command and Scripting Interpreter) en el 80% de las campanas documentadas, esas tecnicas pesan mas que T1542 (Pre-OS Boot), que casi ningun actor de tu sector emplea.

Cobertura ponderada = SUM(peso_tecnica * tiene_regla) / SUM(peso_tecnica)

Calidad de fuentes de datos

No basta con tener reglas. Si la regla necesita logs de Sysmon EventID 1 (Process Creation) pero el SIEM solo recibe logs de Windows Security Event 4688 sin command line auditing, la regla existe pero no puede funcionar.

Data Source Quality Score:

Dimension	Pregunta	Puntuacion
Disponibilidad	El log llega al SIEM?	0/1
Completitud	Llegan todos los campos que la regla necesita?	0-100%
Frescura	Latencia desde el evento hasta el SIEM	Segundos/minutos
Fiabilidad	Se pierden eventos bajo carga?	0-100%

DSQS = Disponibilidad x (Completitud x 0.4 + Frescura x 0.3 + Fiabilidad x 0.3)

Una regla con DSQS < 0.7 es una regla que probablemente fallara en produccion. Mejor saberlo antes de que un incidente lo demuestre.

Metricas de calidad

Tasa de falsos positivos (FPR)

La metrica que mas afecta la moral del SOC. Cuando el 60% de las alertas son falsas alarmas, los analistas dejan de investigar con rigor. Alert fatigue es el camino mas rapido para que un true positive se pierda entre el ruido.

FPR = Falsos Positivos / (Falsos Positivos + True Positives) x 100

Objetivos por nivel de madurez:

Madurez	FPR aceptable	Contexto
Inicial	< 70%	Muchas reglas sin tunear
En desarrollo	< 40%	Tuning activo por familia de alerta
Maduro	< 15%	Reglas probadas con datos historicos antes de despliegue
Avanzado	< 5%	ML-assisted tuning, feedback loop cerrado

Tasa de true positives (TPR) y signal-to-noise ratio

El TPR mide cuantas amenazas reales detecta una regla respecto al total de amenazas que deberia detectar. Es mas dificil de medir que el FPR porque requiere conocer los falsos negativos (amenazas que pasaron sin ser detectadas), que por definicion son invisibles hasta que se descubren en un postmortem o un ejercicio de Red Team.

Signal-to-Noise Ratio (SNR):

SNR = True Positives / Total Alertas generadas

Un SNR de 0.3 significa que de cada 10 alertas, solo 3 son reales. El objetivo en un programa maduro es SNR > 0.6. Cada regla nueva deberia desplegarse con un SNR estimado basado en testing con datos historicos.

Reglas por estado de salud

Clasificar cada regla del SIEM en categorias de salud:

Estado	Definicion	Accion
Saludable	FPR < 15%, se dispara regularmente, campos correctos	Mantener
Ruidosa	FPR > 40%, genera alert fatigue	Tunear o desactivar
Silenciosa	No se ha disparado en 90+ dias	Verificar data sources
Rota	Errores de parseo, campos faltantes, query timeout	Reparar urgente
Obsoleta	Cubre amenaza inactiva sin relevancia actual	Archivar

Metricas de eficiencia

MTTD (Mean Time to Detect)

Tiempo promedio desde que la amenaza ejecuta su primera accion maliciosa hasta que el SOC genera una alerta confirmada.

MTTD = AVG(timestamp_alerta_confirmada - timestamp_primera_accion_maliciosa)

Calcular el timestamp de la primera accion maliciosa requiere investigacion retrospectiva durante el analisis del incidente. No es trivial, pero es la metrica mas honesta sobre la capacidad de deteccion.

Benchmarks MTTD:

Nivel	MTTD	Contexto
Critico (no aceptable)	> 30 dias	Dwell time excesivo, tipico de organizaciones sin programa
Basico	7-30 dias	Deteccion reactiva, IOC-based
Intermedio	1-7 dias	Reglas de comportamiento activas
Avanzado	< 24 horas	Detecciones behavioral + threat hunting proactivo
Elite	< 1 hora	Automatizacion, ML, SOAR integrado

MTTR (Mean Time to Respond)

Tiempo desde la alerta confirmada hasta la contencion del incidente. No es estrictamente una metrica de Detection Engineering (pertenece mas a Incident Response), pero el equipo de deteccion influye directamente: una alerta bien contextualizada con IOCs relacionados, tecnica ATT&CK mapeada y playbook sugerido reduce drasticamente el MTTR.

Tiempo de despliegue de nueva regla (TTD: Time to Deploy)

Desde que se identifica una nueva amenaza (por threat intel, incidente o ejercicio de Red Team) hasta que una regla de deteccion esta activa en produccion.

TTD = timestamp_regla_en_produccion - timestamp_identificacion_amenaza

Desglose recomendado:

Fase	Benchmark maduro
Analisis de la amenaza	< 4 horas
Escritura de la regla	< 2 horas
Testing con datos historicos	< 4 horas
Review y aprobacion	< 24 horas
Despliegue a produccion	< 1 hora
Total TTD	< 48 horas

Equipos con CI/CD para reglas de deteccion (detection-as-code pipeline) logran TTD < 24 horas de forma consistente.

Metricas de impacto

Incidentes detectados por reglas automatizadas

El porcentaje de incidentes reales que fueron detectados por reglas del SIEM antes de que un humano los descubriera por otra via (queja de usuario, alerta de tercero, revision manual).

Deteccion automatizada (%) = Incidentes detectados por reglas / Total incidentes x 100

Un programa maduro deberia detectar automaticamente > 70% de los incidentes. Si la mayoria se descubren por vias manuales, el programa de deteccion no esta cumpliendo su funcion.

Reduccion de dwell time

Dwell time es el tiempo que un atacante permanece en el entorno sin ser detectado. Es la metrica de impacto mas directa del programa de Detection Engineering.

Segun el informe M-Trends de Mandiant (2024), el dwell time mediano global es de 10 dias. Organizaciones con programas de deteccion maduros lo reducen a < 5 dias. Las mejores a < 24 horas.

Medir la tendencia trimestral:

Mejora dwell time (%) = (DT_trimestre_anterior - DT_trimestre_actual) / DT_trimestre_anterior x 100

Coste por incidente evitado

Metrica para justificar presupuesto ante la direccion. Si una deteccion temprana de ransomware evito el cifrado de la infraestructura, el coste evitado se calcula comparando con el coste medio de un incidente similar en el sector (IBM Cost of a Data Breach Report: 4.45M USD en 2023).

No es una ciencia exacta, pero es el lenguaje que entiende el CFO.

Diseno de dashboards: que mostrar a cada audiencia

Dashboard para el SOC (operativo)

Los analistas necesitan datos en tiempo real sobre la salud de las detecciones:

• Alertas ultimas 24h: desglose por severidad y estado (nueva, investigando, cerrada, FP)
• Top 10 reglas mas ruidosas: ordenadas por FPR, con boton directo a tuning
• Reglas rotas: errores de parseo, timeouts, campos faltantes
• Cola de alertas pendientes: con tiempo medio en cola
• MTTD rolling 7 dias: tendencia visual (sparkline o barra)

Formato: dashboard en tiempo real, refresco cada 5 minutos, colores por severidad.

Dashboard para liderazgo (estrategico)

El CISO y la direccion necesitan tendencias y cobertura, no alertas individuales:

• Cobertura ATT&CK ponderada: heatmap con las 14 tacticas, coloreado por nivel de cobertura
• Tendencia MTTD/MTTR trimestral: grafico de linea mostrando mejora
• Reduccion de dwell time: comparativa trimestre vs trimestre
• FPR global: tendencia mensual
• Incidentes detectados automaticamente vs descubiertos manualmente: ratio
• TTD promedio: tiempo de reaccion ante nuevas amenazas
• Coste estimado evitado: valor monetario acumulado del trimestre

Formato: informe mensual o trimestral, PDF o presentacion, con narrativa breve en cada seccion.

Benchmarks por nivel de madurez

Metrica	Nivel 1 (Inicial)	Nivel 2 (Definido)	Nivel 3 (Optimizado)	Nivel 4 (Avanzado)
Cobertura ATT&CK	< 20%	20-40%	40-65%	> 65%
FPR global	> 60%	30-60%	10-30%	< 10%
MTTD	> 30 dias	7-30 dias	1-7 dias	< 24h
TTD (nueva regla)	> 2 semanas	3-14 dias	1-3 dias	< 24h
Deteccion automatizada	< 30%	30-50%	50-70%	> 70%
Reglas con test automatizado	0%	< 20%	20-60%	> 60%
Data Source Quality Score	No medido	< 0.5	0.5-0.8	> 0.8

Estos benchmarks son orientativos. Cada organizacion debe definir sus objetivos en funcion de su sector, tamano y perfil de amenaza.

Anti-patterns: metricas de vanidad que evitar

Numero total de reglas

Tener 5.000 reglas en el SIEM no significa mejor deteccion. Si el 40% genera falsos positivos, el 30% nunca se dispara y el 20% esta rota o desactualizada, solo el 10% aporta valor real. Es preferible tener 200 reglas saludables que 5.000 sin mantener.

Alertas generadas por dia

"Nuestro SIEM genero 50.000 alertas esta semana" suena impresionante hasta que preguntas cuantas eran true positives. Un numero alto de alertas brutas suele indicar un problema de calidad, no una buena capacidad de deteccion.

Cobertura ATT&CK sin ponderar

Cubrir el 60% de las tecnicas ATT&CK parece solido, pero si las tecnicas cubiertas son las que ningun actor relevante usa contra tu sector y las que si usan no estan cubiertas, el numero no refleja proteccion real.

Tiempo medio de cierre de alerta

Si los analistas cierran alertas rapido porque las marcan como FP sin investigar (para limpiar la cola), el tiempo medio de cierre baja pero la seguridad no mejora. Esta metrica solo tiene valor si se combina con verificacion de calidad en el proceso de cierre.

Reglas nuevas por sprint

Medir la productividad del equipo por cantidad de reglas escritas incentiva escribir muchas reglas simples en lugar de pocas reglas de alta calidad. Una regla bien investigada, testeada y tuneada vale mas que diez reglas copiadas de un repositorio publico sin adaptacion.

Construir un programa de metricas paso a paso

Fase 1: Inventario (semanas 1-2)

1. Catalogar todas las reglas activas en el SIEM con su estado de salud
2. Mapear cada regla a la tecnica ATT&CK que detecta
3. Identificar data sources disponibles y su calidad
4. Establecer la linea base de FPR por regla

Fase 2: Instrumentacion (semanas 3-4)

1. Implementar logging estructurado en el pipeline de alertas (alerta generada, investigada, clasificada como TP/FP/indeterminada)
2. Crear queries para calcular MTTD y TTD retrospectivamente
3. Construir el dashboard operativo del SOC
4. Definir el proceso de revision de calidad al cerrar alertas

Fase 3: Baseline y objetivos (mes 2)

1. Calcular las metricas con datos del primer mes completo
2. Establecer objetivos trimestrales realistas (mejorar FPR un 10%, aumentar cobertura ponderada un 5%)
3. Presentar el primer informe estrategico a liderazgo
4. Identificar las 10 reglas mas ruidosas y planificar su tuning

Fase 4: Mejora continua (mes 3 en adelante)

1. Revision semanal de reglas rotas y silenciosas
2. Revision mensual de cobertura ATT&CK vs amenazas del sector
3. Revision trimestral de todas las metricas con tendencias
4. Ajustar objetivos en funcion de la madurez alcanzada
5. Incorporar resultados de Purple Team y Red Team como input para nuevas detecciones

Recursos y referencias

• MITRE ATT&CK Navigator: herramienta gratuita para visualizar y mapear cobertura de deteccion sobre la matriz ATT&CK. Permite exportar heatmaps de cobertura.
• Palantir Detection Engineering blog series: metodologia de Detection-as-Code con CI/CD para reglas, testing automatizado y metricas integradas.
• Ryan Stillions Detection Maturity Level (DML) model: framework de 9 niveles para clasificar la madurez de las detecciones, desde IOCs basicos hasta TTPs abstractas.
• MITRE Engenuity ATT&CK Evaluations: resultados de evaluaciones de productos de seguridad contra simulaciones de APT reales, util para calibrar expectativas de cobertura.
• Mandiant M-Trends Report (anual): datos reales de dwell time, vectores de acceso inicial y tendencias de amenazas globales. Fuente primaria para benchmarks de MTTD y dwell time.
• IBM Cost of a Data Breach Report: referencia para calcular coste evitado y justificar inversion en deteccion ante la direccion.
• SigmaHQ repository: mas de 3.000 reglas Sigma mapeadas a ATT&CK, util como baseline para medir cobertura inicial.
• Detection Engineering Weekly (newsletter): curada por Zack Allen, cubre nuevas detecciones, herramientas y metricas relevantes para la disciplina.