Durante años, cada técnica de ATT&CK venía con una frase de detección que no servía para escribir la consulta: atención a los procesos hijo de tal binario. MITRE las retiró el 28 de octubre de 2025 y puso en su lugar dos objetos nuevos, Detection Strategies y Analytics, con guía específica por plataforma, parámetros ajustables y fuentes de registro nombradas de forma inequívoca: wineventlog:security, auditd:SYSCALL.
La proporción es medible. La versión vigente, ATT&CK v19, publicada el 28 de abril de 2026, tiene para Enterprise 222 técnicas y 475 subtécnicas. Frente a ellas hay 697 estrategias de detección, exactamente una por técnica y subtécnica, y 1.758 analíticas, unas dos y media por cada una. Donde antes había una frase, ahora hay dos analíticas y media con su plataforma, sus parámetros y su fuente de datos.
La ingeniería de detección ocupa ese hueco: se encarga de formular la hipótesis, convertirla en una analítica capaz de resistir a un adversario que sabe que existe, validarla, mantenerla y decidir cuándo se retira. Los cuadros de mando de seguridad rara vez la miden. Miden cobertura.
Qué mide en realidad un porcentaje de cobertura
Cuando un SOC declara que cubre el 78 % de MITRE ATT&CK, lo que ha hecho es contar celdas de una matriz en las que existe al menos una regla. El cálculo no cuesta nada y el número queda bien en un comité. Tres defectos lo vacían por dentro.
La matriz no está ponderada por prevalencia
Todas las celdas valen lo mismo. La actividad real se reparte de otra manera. Red Canary publica cada año el ranking de técnicas más frecuentes en amenazas confirmadas, y la metodología es pública: más de 110.000 amenazas sobre 4,5 millones de identidades, equipos y activos en la nube, con 305 petabytes de telemetría procedente de 1.700 organizaciones, filtrando programas no deseados y pruebas autorizadas.
En el informe de 2026, con datos de 2025, encabeza la lista T1078.004 (Cloud Accounts) por segundo año consecutivo, seguida de PowerShell (T1059.001) y el intérprete de comandos de Windows (T1059.003). Detrás vienen los datos desde almacenamiento en la nube (T1530), la transferencia de herramientas (T1105), las reglas de reenvío de correo (T1114.003), WMI (T1047), el copiar y pegar malicioso (T1204.004), las reglas de ocultación de correo (T1564.008) y la ofuscación de ficheros (T1027).
La mitad de esa lista vive en la identidad, el correo y la nube, lejos del puesto de trabajo. Un SOC con cobertura ejemplar del puesto y ninguna analítica sobre reglas de reenvío de correo saca un porcentaje alto y deja abierta la técnica número seis. Es un patrón habitual en los secuestros de cuentas de Microsoft 365. T1204.004, por su parte, circula con un nombre más conocido: es la técnica detrás de ClickFix y los falsos CAPTCHA.
La pirámide del dolor no aparece en la matriz
David Bianco la formuló en 2013: los hashes, las direcciones IP y los dominios están en la base porque el adversario los cambia sin coste; las tácticas, técnicas y procedimientos están arriba porque cambiarlas le sale caro. Una analítica que busca un hash resulta precisa y frágil a la vez, ciega ante la misma familia alterada en un solo byte. Otra construida sobre el comportamiento invariante sobrevive a esa modificación.
Las dos suman igual en el porcentaje de cobertura, y ahí se rompe la métrica.
Hay técnicas que no se cubren sin contexto
El proyecto Summiting the Pyramid las llama técnicas ambiguas: aquellas cuyos comportamientos invariantes se solapan de forma sustancial entre uso malicioso y uso legítimo. PowerShell es el ejemplo que sale en todas las conversaciones sobre esto. Sin contexto adicional, la analítica se ahoga en falsos positivos; con demasiado filtro, se vuelve frágil y el adversario la esquiva colocándose fuera del filtro. Marcar la celda como cubierta no dice en qué lado de ese equilibrio quedó la organización.
Robustez: la medida que sustituye a la cobertura
Summiting the Pyramid, del Center for Threat-Informed Defense de MITRE, define detección robusta con dos condiciones: precisa y resistente a la evasión a lo largo del tiempo. Precisa significa pocos falsos positivos y pocos falsos negativos. Resistente significa que sigue funcionando cuando el adversario cambia de implementación. El proyecto organiza el trabajo en tres dominios (preparación de la telemetría, diseño de analíticas y validación) y aporta lo que faltaba: una forma de puntuar.
El modelo evalúa cada observable de una analítica en cinco niveles:
- Nivel 1, valores efímeros. Hashes, direcciones, nombres de fichero. El adversario los cambia sin esfuerzo.
- Nivel 2, núcleo de una herramienta que trae el adversario, o señal observada desde fuera del perímetro. Si controla la herramienta, controla la evasión.
- Nivel 3, núcleo de herramientas preexistentes, los binarios legítimos del propio sistema, o señal observada desde dentro del perímetro. Ya estaban ahí antes de la intrusión, y modificarlas le resulta más caro.
- Nivel 4, núcleo de algunas implementaciones de la técnica. Comportamientos de baja varianza, inevitables salvo que se reescriba la implementación entera.
- Nivel 5, núcleo de la técnica. Los pasos obligados: el comportamiento invariante que ninguna implementación puede evitar.
A esas filas el modelo añade columnas según de dónde nace la señal. En el modelo de host son tres: aplicación, modo usuario y modo núcleo. Un adversario que llama a una función más baja del sistema operativo o hace una llamada directa al núcleo evita los identificadores de evento que genera la capa de arriba. En el modelo de red son dos: cabecera y carga útil del protocolo. El contenido de la carga útil se cifra o se ofusca con mucha más facilidad que el de la cabecera.
Puntuar con este modelo cambia la conversación de comité. En lugar de «cubrimos el 78 %», la frase pasa a ser «tenemos catorce analíticas de nivel 4 o 5 sobre las doce técnicas con más prevalencia en nuestro sector, y trescientas de nivel 1 pendientes de revisión». La segunda se puede discutir, presupuestar y auditar.
Una detección sin ficha no es una detección
Palantir publicó en abierto su Alerting and Detection Strategy Framework, y el diagnóstico del que nació resulta familiar para cualquiera que haya heredado un catálogo de reglas: los ingenieros escribían lógica de detección por intuición, sin hipótesis explícita, sin dejar constancia de por qué debía saltar una alerta y sin revisión por pares. El marco tiene un nombre para el resultado: apatía ante las alertas.
El marco exige diez apartados rellenos antes de que nada llegue a producción: objetivo en lenguaje llano, categorización en ATT&CK con técnica padre e hija, resumen de la estrategia y contexto técnico para quien responda. Después, puntos ciegos y suposiciones, falsos positivos conocidos, validación, prioridad, pasos de respuesta y referencias. Al final, revisión por pares.
Dos de esas secciones son las que separan un programa de un cajón de consultas guardadas.
- Puntos ciegos y suposiciones. Ninguna analítica es perfecta. Escribir por dónde puede fallar permite que otro ingeniero entienda cómo deja de disparar y cómo la derrota un adversario que la conoce.
- Validación. El marco pide los pasos concretos para generar un verdadero positivo que dispare la analítica, al estilo de una prueba unitaria, y menciona Atomic Red Team como forma de hacerlo. Añade además una regla que el marco sí exige y los catálogos reales rara vez recogen: si no se consigue generar ese verdadero positivo, la alerta se descompone, se rehace o se descarta.
Una analítica que nadie ha conseguido disparar en una prueba controlada está en producción sin evidencia de que funcione. Ninguna encuesta pública mide cuántas hay en esa situación, y esa ausencia de dato ya dice algo.
Detección como código
Si las analíticas son software, se gestionan como software: repositorio, revisión por pares, pruebas, promoción por entornos y política de deprecación. Sigma es el formato que hace portable esa lógica. Sus autores lo describen como lo que Snort es al tráfico de red y YARA a los ficheros, aplicado a los registros, y permite escribir la detección una vez y convertirla a la consulta nativa de cada plataforma.
El flujo encadena las piezas anteriores. La analítica nace de una hipótesis: una caza que dio resultado, un informe de inteligencia, un hallazgo de un ejercicio ofensivo. Se documenta en su ficha, se puntúa su robustez y pasa revisión por pares antes de convertirse al formato nativo y desplegarse en preproducción. Allí se valida con emulación controlada, comprobando no solo que la regla dispara, sino que la alerta llega al panel y genera ticket. Solo entonces pasa a producción y entra en la cadencia de revisión, que es donde se decide su retirada.
La caza de amenazas alimenta ese flujo por su extremo más productivo: una hipótesis que se confirma y no se convierte en analítica es trabajo que habrá que repetir. Un servicio de caza de amenazas que deja capacidad instalada se distingue de uno que entrega informes exactamente en eso.
La validación por emulación tiene además un efecto que se nota en la cuenta de resultados: convierte los ejercicios ofensivos en materia prima de ingeniería. Cada técnica que el equipo ofensivo ejecutó sin generar alerta es, como mínimo, una decisión pendiente: analítica nueva, telemetría que falta o riesgo aceptado por escrito. En los ejercicios que dirigimos desde Hard2bit, esa lista de decisiones pendientes acaba discutiéndose más que el informe técnico.
Qué medir
Jared Atkinson propuso en SpecterOps el Funnel of Fidelity, un modelo que describe la detección y respuesta como cinco fases (recolección, detección, triaje, investigación y remediación) en las que cada filtro reduce drásticamente lo que llega a la siguiente. Sirve para localizar el cuello de botella antes de firmar ninguna compra. Un SOC que se ahoga en triaje tiene un problema de capacidad de análisis, y añadirle reglas lo empeora.
Sobre ese esqueleto se sostienen las métricas que sí describen un programa de detección.
- Cobertura de telemetría por técnica prioritaria, antes que cobertura de reglas. Sin la fuente de datos la analítica no existe, así que decidir qué registros enviar al SIEM y cuáles no es una decisión de detección y no de coste.
- Reparto de analíticas por nivel de robustez, y su evolución trimestre a trimestre.
- Analíticas que dispararon en los últimos doce meses. De esas, cuántas produjeron una decisión. De esas, cuántas un incidente confirmado.
- Tasa de retirada. Un programa sin deprecaciones no está vivo.
- Analíticas en producción sin dueño, sin hipótesis documentada o sin validación. El objetivo razonable es cero, y el número de partida suele sorprender.
- Tiempo desde que una técnica relevante se hace pública hasta que existe analítica validada para ella.
Una advertencia sobre las cifras que circulan. Hay casos muy citados de SOC con miles de reglas de las que apenas un puñado disparó en un año. Son anécdotas de consultoría sin datos publicados detrás, y no deberían usarse como referencia de sector. La cifra que importa es la propia, y sale de una consulta al SIEM que casi nadie ha lanzado.
Por dónde empezar sin rehacer el SOC
- Extraer del SIEM el listado de analíticas en producción con su dueño y la fecha del último disparo. Es una consulta, no un proyecto.
- Cruzar las técnicas con prevalencia real en tu sector contra las que tienen analítica validada. El ranking público sirve de punto de partida; tu histórico de incidentes, mejor.
- Puntuar la robustez de las veinte analíticas que sostienen esas técnicas. Veinte fichas bien hechas rinden más que un inventario completo a medias.
- Documentar los puntos ciegos de esas veinte: qué implementación concreta se les escapa y por qué.
- Validar con emulación controlada y seguir la alerta hasta el final del embudo, no hasta el motor de reglas.
- Fijar una cadencia de revisión y una barra de retirada explícita, acordada por escrito antes de aplicarla.
Ninguno de esos pasos exige comprar nada. Todos exigen que alguien sea responsable del catálogo, que es precisamente lo que suele faltar. En Hard2bit es la primera pieza que revisamos cuando nos hacemos cargo de un SOC gestionado que no montamos nosotros.
Lo que esta disciplina no resuelve
Summiting the Pyramid es explícito con sus límites, y merecen repetirse porque el marketing del sector no lo es. La manipulación de las fuentes de datos queda fuera de alcance: el modelo asume una telemetría fiable, y un adversario que altere el origen invalida la puntuación. Las puntuaciones cambian con el tiempo, porque una actualización del sistema operativo o una función nueva en una herramienta preexistente mueve el nivel de una analítica que ayer era sólida.
Las analíticas de nivel alto son además más caras de construir, porque obligan a traducir una abstracción de TTP a observables de bajo nivel, y en ocasiones la telemetría necesaria simplemente no está disponible en ese entorno. El propio proyecto reconoce que hay propiedades que no ha investigado a fondo: el coste de construir una detección, el de recoger sus datos y el de ejecutarla a escala.
Queda lo obvio, que es también lo más caro. Los puntos ciegos del EDR no se arreglan escribiendo mejores reglas para los sitios donde sí hay agente.
El desfase entre el marco y el catálogo
El marco se mueve más deprisa que los catálogos internos, y hay una prueba reciente. La versión v19.2 de ATT&CK, del 6 de agosto de 2026, incorporó como grupos a ShinyHunters y TeamPCP, y como software a Shai-Hulud y Mini Shai-Hulud. Son, respectivamente, el actor detrás del abuso de OAuth en Salesforce y el gusano de npm que planta ganchos de ejecución. Entre que una técnica aparece en un incidente y entra en el marco pasan meses; entre que entra en el marco y existe una analítica validada en un SIEM concreto, suele pasar bastante más.
Ese desfase es el terreno real de la ingeniería de detección, y explica por qué la cobertura envejece mal como métrica: describe el mapa de hace dos versiones. Un programa no se ordena contando técnicas marcadas. Se ordena sabiendo cuántas de sus analíticas volverías a escribir hoy y cuáles seguirían disparando si el adversario supiera exactamente cómo están escritas.
Este artículo describe metodologías públicas de ingeniería de detección con la información disponible el 20 de agosto de 2026. Las versiones de los marcos citados, sus niveles de puntuación y los rankings de prevalencia cambian con cada publicación: contrasta siempre contra la documentación vigente de MITRE ATT&CK, del Center for Threat-Informed Defense y de tu propia plataforma antes de aplicar nada en producción.
