MITRE Engenuity ATT&CK Evaluations: Cómo Leer los Resultados de EDR
Guia para interpretar las evaluaciones MITRE Engenuity ATT&CK de productos EDR. Metodologia, categorias de deteccion (telemetry, general, tactic, technique), como leer los resultados de Round 5 (Turla), errores comunes de interpretacion y uso para decisiones de compra.
Que son las MITRE ATT&CK Evaluations
Las MITRE ATT&CK Evaluations, gestionadas por MITRE Engenuity (la division de I+D aplicada de MITRE), son las evaluaciones mas rigurosas y transparentes de productos de seguridad en el mercado. Desde 2018, MITRE ejecuta simulaciones de adversarios reales contra los principales EDR y publica los resultados completos, paso a paso, de forma publica.
Lo que hace unicas estas evaluaciones:
- Transparencia total: cada paso del ataque y cada deteccion (o falta de ella) se documenta publicamente
- Sin puntuacion ni ranking: MITRE no declara ganadores. Los datos estan disponibles para que cada organizacion los interprete
- Adversario real: cada ronda simula las tacticas, tecnicas y procedimientos (TTPs) de un grupo APT real
- Participacion voluntaria: los vendors eligen participar y pagan por hacerlo
Rondas completadas
| Ronda | Ano | Adversario | Foco |
|---|---|---|---|
| Round 1 | 2018 | APT3 (Gothic Panda) | Evaluacion inicial |
| Round 2 | 2020 | APT29 (Cozy Bear) | Espionaje estatal |
| Round 3 | 2021 | Carbanak + FIN7 | Cibercrimen financiero |
| Round 4 | 2022 | Wizard Spider + Sandworm | Ransomware + destructivo |
| Round 5 | 2023 | Turla (Snake) | Espionaje estatal avanzado |
| Round 6 | 2024 | CL0P + LockBit | Ransomware moderno |
Cada ronda anade complejidad y simula adversarios con TTPs diferentes, lo que permite evaluar la cobertura de los productos en distintos escenarios.
Metodologia de evaluacion
Escenario de ataque
MITRE define un escenario de ataque detallado basado en los TTPs documentados del adversario objetivo. Por ejemplo, en Round 5 (Turla), el escenario incluyo:
- Spearphishing con documento malicioso
- Descarga de implant (Carbon, Snake)
- Descubrimiento del entorno
- Movimiento lateral via SMB
- Escalacion de privilegios
- Exfiltracion de datos via canal C&C cifrado
- Persistencia mediante tareas programadas y servicios
El ataque se ejecuta paso a paso contra los endpoints protegidos por cada vendor. El equipo MITRE opera el red team y documenta cada accion.
Categorias de deteccion
Las categorias de deteccion son el concepto clave para interpretar los resultados. MITRE clasifica cada deteccion en una jerarquia:
None: el producto no detecto ni registro nada sobre este paso del ataque. Punto ciego total.
Telemetry: el producto registro el evento en sus datos crudos, pero no genero ninguna alerta ni enriquecimiento. Un analista tendria que buscar proactivamente en los logs para encontrarlo.
General: el producto genero una alerta o marco el evento como sospechoso, pero sin especificar que tecnica ATT&CK esta ocurriendo. Ejemplo: "actividad sospechosa detectada en el proceso cmd.exe".
Tactic: el producto identifico el objetivo tactico (la columna ATT&CK) pero no la tecnica especifica. Ejemplo: "actividad de Persistence detectada" sin especificar si es via Scheduled Task, Registry Run Key u otro mecanismo.
Technique: el producto identifico la tecnica especifica ATT&CK. Ejemplo: "T1053.005 Scheduled Task/Job: Scheduled Task detected". Esta es la deteccion mas precisa y util.
Modificadores adicionales
Ademas de la categoria, MITRE registra modificadores:
- Configuration Change: la deteccion requirio un cambio de configuracion durante la evaluacion (no funciona out-of-the-box)
- Delayed: la deteccion no fue en tiempo real, llego con retraso
- Host Interrogation: requirio que el analista ejecutara una consulta activa al endpoint
Estos modificadores son criticos para la interpretacion: una deteccion "Technique" con "Configuration Change" significa que el producto puede detectar esa tecnica, pero no lo hace por defecto. En produccion, si el equipo no activa esa configuracion, la deteccion no existira.
Como leer los resultados
El portal de resultados
Los resultados se publican en attackevals.mitre-engenuity.org. Para cada vendor y cada paso del ataque, se muestra:
- Descripcion del paso (que hizo el atacante)
- Categoria de deteccion asignada
- Evidencia: capturas de pantalla del producto mostrando la deteccion
- Notas sobre modificadores o condiciones especiales
Metricas que importan
Visibility (Telemetry + General + Tactic + Technique): cuantos pasos del ataque fueron al menos registrados. Un producto con alta visibility tiene buen logging, aunque no necesariamente buena deteccion.
Analytic Coverage (General + Tactic + Technique): cuantos pasos generaron alguna alerta o enriquecimiento. Esto indica la capacidad de deteccion real, porque un analista sera notificado sin tener que buscar.
Technique Coverage: cuantos pasos fueron identificados con la tecnica ATT&CK especifica. Esta es la metrica de mayor calidad: detecciones precisas que dan al analista contexto inmediato.
None count: cuantos pasos pasaron completamente desapercibidos. Cuanto menor, mejor.
Ejemplo: interpretar Round 5 (Turla)
Round 5 simulo dos escenarios de Turla con un total de 143 substeps. Veamos como leer los resultados de un vendor hipotetico:
| Categoria | Detecciones | Porcentaje |
|---|---|---|
| Technique | 89 | 62% |
| Tactic | 12 | 8% |
| General | 8 | 6% |
| Telemetry | 22 | 15% |
| None | 12 | 8% |
Interpretacion:
- 62% Technique: la mayoria de las detecciones son precisas. El analista recibe contexto ATT&CK directo
- 15% Telemetry: los datos estan disponibles pero sin alertar. Util para hunting, no para deteccion pasiva
- 8% None: 12 pasos del ataque pasaron completamente desapercibidos. Hay que investigar cuales son esos gaps y si son relevantes para tu organizacion
Ahora imaginemos otro vendor:
| Categoria | Detecciones | Porcentaje |
|---|---|---|
| Technique | 120 | 84% |
| Tactic | 5 | 3% |
| General | 10 | 7% |
| Telemetry | 5 | 3% |
| None | 3 | 2% |
A primera vista parece claramente superior. Pero hay que verificar:
- Cuantas detecciones Technique requirieron Configuration Change
- Cuantas fueron Delayed
- Cual es el nivel de ruido en produccion (las evaluaciones MITRE no miden falsos positivos)
Errores comunes de interpretacion
Error 1: tratar los resultados como ranking
MITRE publica datos, no rankings. Un vendor puede tener 100% de deteccion Technique pero generar tanto ruido en produccion que los analistas ignoran las alertas. Los resultados muestran capacidad, no eficacia operativa.
Error 2: ignorar los Configuration Changes
Si un vendor necesito 30 Configuration Changes para lograr alta deteccion, eso significa que su configuracion por defecto tiene gaps significativos. Pregunta clave: "¿mi equipo sabria activar todas esas configuraciones?"
Error 3: comparar rondas diferentes
Cada ronda simula un adversario diferente con TTPs diferentes. Comparar los resultados de un vendor en Round 3 (Carbanak/FIN7) con otro vendor en Round 5 (Turla) no tiene sentido. Solo se pueden comparar vendors que participaron en la misma ronda.
Error 4: enfocarse solo en deteccion
Las evaluaciones MITRE no miden:
- Falsos positivos: un producto puede detectar todo y generar un tsunami de alertas irrelevantes
- Rendimiento: impacto en el endpoint (CPU, RAM, I/O)
- Usabilidad: facilidad de investigacion y triaje
- Prevencion: capacidad de bloquear el ataque (solo se mide en rounds recientes)
- Soporte y operaciones: calidad del soporte tecnico del vendor
Error 5: asumir que Telemetry es malo
Telemetry no es un fallo: significa que el producto registro los datos. Para un threat hunter, tener la telemetria disponible puede ser mas valioso que una alerta generica. La pregunta es: ¿tu equipo tiene hunters que aprovecharan esos datos?
Error 6: confiar en los graficos de los vendors
Despues de cada evaluacion, los vendors publican sus propios analisis con graficos que invariablemente los posicionan como lideres. Estos graficos suelen:
- Seleccionar metricas favorables
- Combinar categorias de formas creativas
- Omitir Configuration Changes
- Comparar con subconjuntos de competidores
La unica fuente fiable es el portal oficial de MITRE Engenuity. Todo lo demas es marketing.
Proteccion vs Deteccion
A partir de Round 4, MITRE incluyo escenarios de proteccion (prevencion) ademas de deteccion. La diferencia es fundamental:
- Deteccion: el producto registro o alerto sobre la actividad maliciosa, pero no la detuvo
- Proteccion: el producto bloqueo la actividad maliciosa antes de que se completara
Los resultados de proteccion muestran en que paso del ataque el producto intervino y como (bloqueo de proceso, cuarentena de archivo, aislamiento de endpoint). Un producto con alta deteccion pero baja proteccion ve todo pero no hace nada al respecto.
Para un SOC con recursos limitados, la proteccion automatica puede ser mas valiosa que la deteccion. Para un equipo maduro con threat hunters, la deteccion (especialmente Telemetry rica) puede ser preferible a la proteccion que interrumpe las investigaciones.
Usar las evaluaciones para decisiones de compra
Paso 1: definir tu threat model
No todas las tecnicas ATT&CK son igualmente relevantes para tu organizacion. Antes de mirar los resultados:
- Identifica los threat actors que apuntan a tu sector e industria
- Lista las tecnicas ATT&CK que esos actores utilizan
- Prioriza las tecnicas por impacto potencial en tu entorno
Paso 2: filtrar por ronda relevante
Elige la ronda cuyo adversario sea mas cercano a tus amenazas reales:
- Sector financiero: Round 3 (Carbanak/FIN7) y Round 6 (CL0P/LockBit)
- Gobierno/defensa: Round 2 (APT29) y Round 5 (Turla)
- Infraestructura critica: Round 4 (Sandworm)
Paso 3: analizar las tecnicas criticas
Para cada tecnica que priorizaste, verifica en los resultados:
- ¿El vendor la detecto? ¿Con que categoria?
- ¿Requirio Configuration Change?
- ¿Fue Delayed o en tiempo real?
- ¿Bloqueo el ataque (si hay datos de proteccion)?
Paso 4: evaluar los gaps
Los "None" son los gaps criticos. Para cada tecnica que un vendor no detecto:
- ¿Es una tecnica relevante para tu threat model?
- ¿Hay mitigaciones compensatorias en tu stack? (firewall, WAF, proxy)
- ¿Otro vendor que evaluas si la detecta?
Paso 5: cruzar con otros criterios
Las evaluaciones MITRE son una dimension de la decision, no la unica. Cruzar con:
- Coste total (licencias + personal + infraestructura)
- Integracion con tu stack existente (SIEM, SOAR, ticketing)
- Soporte tecnico y SLAs
- Resultados de PoC en tu propio entorno (ver articulo dedicado)
- Impacto en rendimiento de los endpoints
- Retencion de datos y privacidad
Tendencias en las evaluaciones
Mayor enfoque en proteccion
Las rondas recientes incluyen escenarios de proteccion, reflejando la expectativa del mercado de que un EDR no solo detecte sino que prevenga.
Adversarios mas sofisticados
Cada ronda sube el nivel: de APT3 (tecnicas relativamente simples) a Turla (uno de los grupos mas sofisticados, con implants que evaden deteccion activamente). Esto expone diferencias entre productos que en rondas anteriores parecian similares.
Mas vendors participantes
El numero de vendors que participan ha crecido, incluyendo ahora no solo EDR sino tambien soluciones XDR, SIEM y plataformas cloud. Esto amplica la utilidad de las evaluaciones para decisiones de stack completo.
Linux y macOS
Las rondas recientes incluyen escenarios en Linux y macOS, no solo Windows. Esto es critico para organizaciones con entornos mixtos.
Recursos
Para profundizar en las evaluaciones MITRE ATT&CK:
- Portal oficial de resultados:
attackevals.mitre-engenuity.org - Metodologia detallada: cada ronda publica su plan de evaluacion completo
- Blog de MITRE Engenuity: analisis de tendencias y guias de interpretacion
- MITRE ATT&CK Navigator: herramienta para visualizar cobertura de tecnicas y comparar
Conclusion
Las evaluaciones MITRE Engenuity son la fuente mas objetiva de datos sobre la capacidad de deteccion de productos EDR. Pero requieren interpretacion cuidadosa. No son un ranking, no miden todo lo que importa (falsos positivos, rendimiento, usabilidad), y los vendors publican analisis sesgados de los resultados.
El valor real de las evaluaciones esta en la transparencia: cada paso, cada deteccion, cada gap esta documentado publicamente. Ningun otro benchmark de seguridad ofrece ese nivel de detalle. Usarlas correctamente requiere entender la metodologia, definir tu propio threat model, y cruzar los resultados con evaluaciones practicas en tu entorno real.
Preguntas frecuentes
Este contenido tiene fines exclusivamente educativos y de investigación en ciberseguridad defensiva. No se proporcionan binarios maliciosos ni payloads ejecutables. El uso indebido de esta información es responsabilidad exclusiva del usuario. Leer disclaimer completo.