IntermedioMITRE ATT&CKevaluacionesEDRtelemetriadeteccionTurla

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,.

MalwareIntel Research··10 min lectura
Serie: EDR/XDR Telemetría por Vendor — Parte 12

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

RondaAñoAdversarioFoco
Round 12018APT3 (Gothic Panda)Evaluación inicial
Round 22020APT29 (Cozy Bear)Espionaje estatal
Round 32021Carbanak + FIN7Cibercrimen financiero
Round 42022Wizard Spider + SandwormRansomware + destructivo
Round 52023Turla (Snake)Espionaje estatal avanzado
Round 62024CL0P + LockBitRansomware 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íaDeteccionesPorcentaje
Technique8962%
Tactic128%
General86%
Telemetry2215%
None128%

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íaDeteccionesPorcentaje
Technique12084%
Tactic53%
General107%
Telemetry53%
None32%

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:

  1. Identifica los threat actors que apuntan a tu sector e industria
  2. Lista las técnicas ATT&CK que esos actores utilizan
  3. 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.