MITRE Engenuity ATT&CK Evaluations: Cómo Leer los
Guia para interpretar las evaluaciones MITRE Engenuity ATT&CK de productos EDR. Metodologia, categorias de deteccion (telemetry, general, tactic,.
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 más rigurosas y transparentes de productos de seguridad en el mercado. Desde 2018, MITRE ejecuta simulaciones de adversarios reales contra los principales EDR y pública los resultados completos, paso a paso, de forma pública.
Lo que hace unicas estas evaluaciones:
- Transparencia total: cada paso del ataque y cada detección (o falta de ella) se documenta publicamente
- Sin puntuacion ni ranking: MITRE no declara ganadores. Los datos están disponibles para que cada organización los interprete
- Adversario real: cada ronda simula las tacticas, técnicas y procedimientos (TTPs) de un grupo APT real
- Participacion voluntaria: los vendors eligen participar y pagan por hacerlo
Rondas completadas
| Ronda | Año | Adversario | Foco |
|---|---|---|---|
| Round 1 | 2018 | APT3 (Gothic Panda) | Evaluación 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 evaluación
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
- Escalación de privilegios
- Exfiltración 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.
Categorías de detección
Las categorías de detección son el concepto clave para interpretar los resultados. MITRE clasifica cada detección 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 técnica 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 técnica específica. Ejemplo: "actividad de Persistence detectada" sin especificar si es via Scheduled Task, Registry Run Key u otro mecanismo.
Technique: el producto identifico la técnica específica ATT&CK. Ejemplo: "T1053.005 Scheduled Task/Job: Scheduled Task detected". Esta es la detección más precisa y útil.
Modificadores adicionales
Además de la categoría, MITRE registra modificadores:
- Configuration Change: la detección requirio un cambio de configuración durante la evaluación (no funciona out-of-the-box)
- Delayed: la detección 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 detección "Technique" con "Configuration Change" significa que el producto puede detectar esa técnica, pero no lo hace por defecto. En producción, si el equipo no activa esa configuración, la detección 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)
- Categoría de detección asignada
- Evidencia: capturas de pantalla del producto mostrando la detección
- 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 detección.
Analytic Coverage (General + Tactic + Technique): cuantos pasos generaron alguna alerta o enriquecimiento. Esto indica la capacidad de detección real, porque un analista será notificado sin tener que buscar.
Technique Coverage: cuantos pasos fueron identificados con la técnica ATT&CK específica. 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:
| Categoría | 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 están disponibles pero sin alertar. Útil para hunting, no para detección pasiva
- 8% None: 12 pasos del ataque pasaron completamente desapercibidos. Hay que investigar cuales son esos gaps y si son relevantes para tu organización
Ahora imaginemos otro vendor:
| Categoría | 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 producción (las evaluaciones MITRE no miden falsos positivos)
Errores comunes de interpretacion
Error 1: tratar los resultados como ranking
MITRE pública datos, no rankings. Un vendor puede tener 100% de detección Technique pero generar tanto ruido en producción 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 detección, eso significa que su configuración 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 detección
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 investigación y triaje
- Prevención: capacidad de bloquear el ataque (solo se mide en rounds recientes)
- Soporte y operaciones: calidad del soporte técnico 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 más valioso que una alerta generica. La pregunta es: ¿tu equipo tiene hunters que aprovecharan esos datos?
Error 6: confiar en los gráficos de los vendors
Despues de cada evaluación, los vendors publican sus propios análisis con gráficos que invariablemente los posicionan como lideres. Estos gráficos suelen:
- Seleccionar metricas favorables
- Combinar categorías de formas creativas
- Omitir Configuration Changes
- Comparar con subconjuntos de competidores
La única fuente fiable es el portal oficial de MITRE Engenuity. Todo lo demas es marketing.
Protección vs Detección
A partir de Round 4, MITRE incluyo escenarios de protección (prevención) además de detección. La diferencia es fundamental:
- Detección: el producto registro o alerto sobre la actividad maliciosa, pero no la detuvo
- Protección: el producto bloqueo la actividad maliciosa antes de que se completara
Los resultados de protección muestran en que paso del ataque el producto intervino y como (bloqueo de proceso, cuarentena de archivo, aislamiento de endpoint). Un producto con alta detección pero baja protección ve todo pero no hace nada al respecto.
Para un SOC con recursos limitados, la protección automática puede ser más valiosa que la detección. Para un equipo maduro con threat hunters, la detección (especialmente Telemetry rica) puede ser preferible a la protección que interrumpe las investigaciones.
Usar las evaluaciones para decisiones de compra
Paso 1: definir tu threat model
No todas las técnicas ATT&CK son igualmente relevantes para tu organización. Antes de mirar los resultados:
- Identifica los threat actors que apuntan a tu sector e industria
- Lista las técnicas ATT&CK que esos actores utilizan
- Prioriza las técnicas por impacto potencial en tu entorno
Paso 2: filtrar por ronda relevante
Elige la ronda cuyo adversario sea más 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 técnicas criticas
Para cada técnica que priorizaste, verifica en los resultados:
- ¿El vendor la detecto? ¿Con que categoría?
- ¿Requirio Configuration Change?
- ¿Fue Delayed o en tiempo real?
- ¿Bloqueo el ataque (si hay datos de protección)?
Paso 4: evaluar los gaps
Los "None" son los gaps criticos. Para cada técnica que un vendor no detecto:
- ¿Es una técnica 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 decisión, no la única. Cruzar con:
- Coste total (licencias + personal + infraestructura)
- Integracion con tu stack existente (SIEM, SOAR, ticketing)
- Soporte técnico y SLAs
- Resultados de PoC en tu propio entorno (ver artículo dedicado)
- Impacto en rendimiento de los endpoints
- Retencion de datos y privacidad
Tendencias en las evaluaciones
Mayor enfoque en protección
Las rondas recientes incluyen escenarios de protección, reflejando la expectativa del mercado de que un EDR no solo detecte sino que prevenga.
Adversarios más sofisticados
Cada ronda sube el nivel: de APT3 (técnicas relativamente simples) a Turla (uno de los grupos más sofisticados, con implants que evaden detección activamente). Esto expone diferencias entre productos que en rondas anteriores parecian similares.
Más vendors participantes
El número de vendors que participan ha crecido, incluyendo ahora no solo EDR sino también 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 pública su plan de evaluación completo
- Blog de MITRE Engenuity: análisis de tendencias y guías de interpretacion
- MITRE ATT&CK Navigator: herramienta para visualizar cobertura de técnicas y comparar
Conclusion
Las evaluaciones MITRE Engenuity son la fuente más objetiva de datos sobre la capacidad de detección 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 análisis sesgados de los resultados.
El valor real de las evaluaciones esta en la transparencia: cada paso, cada detección, 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 prácticas 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.