Casi todos los equipos que empiezan a usar MITRE ATT&CK pasan por la misma fase: pintar el Navigator de verde técnica a técnica hasta que la matriz entera parece cubierta. Es una sensación agradable y casi siempre falsa. Una celda verde no dice si la telemetría que necesitas llega, si la regla se ha probado alguna vez contra un ataque real o si cubre uno de los procedimientos de esa técnica o los quince que existen. Este módulo es el método para no quedarte en ese verde de mentira: cómo se elige una técnica por riesgo, cómo se lee su documentación para sacar observables reales, cómo se comprueba contra tu propia telemetría, y cómo se mide, con honestidad, lo que has cubierto de verdad.
El punto de partida es una técnica de ATT&CK como T1053.005. El punto de llegada es una regla escrita, probada con un atómico y con su cobertura anotada en una capa de Navigator que puedes enseñar sin que se te caiga la cara.
Qué aprenderás
- Por qué «cubrir ATT&CK» como objetivo, sin telemetría real detrás, es una promesa que no se puede cumplir.
- Qué son hoy las Detection Strategies y los Analytics de ATT&CK, qué sustituyeron y desde cuándo, con las cifras de la versión vigente.
- El método completo para convertir una técnica en un caso de uso: elegirla por riesgo, leer sus procedimientos documentados, listar observables, comprobarlos contra tu telemetría, formular la hipótesis y escribir la regla.
- Por qué un indicador basado en el nombre de un binario es frágil y uno basado en la relación padre-hijo o en el comportamiento aguanta mucho más.
- A medir tu cobertura con DeTT&CT: qué modela, cómo puntúa la visibilidad y la detección, y cómo genera capas para el Navigator.
- A leer dos capas de Navigator superpuestas (lo que ves frente a lo que detectas) sin confundir una cosa con la otra.
- Cómo decidir qué se detecta primero cuando no hay tiempo ni gente para detectarlo todo.
- Qué preguntas hace un auditor a un informe de cobertura y por qué un panel en verde no equivale a estar protegido.
El espejismo de «cubrir ATT&CK»
Enterprise ATT&CK, en su versión vigente (v19, publicada el 28 de abril de 2026), tiene 15 tácticas y 222 técnicas con 475 subtécnicas, según las notas de esa versión. Ningún equipo de detección del mundo, ni siquiera uno grande, escribe y mantiene una regla probada por cada una de esas casi setecientas entradas. Y aunque pudiera, tener una regla no es tener cobertura: cada técnica se puede ejecutar de docenas de formas distintas, con herramientas distintas, en sistemas operativos distintos, y una sola regla casi nunca las cubre todas.
Lo puedes comprobar tú mismo en la página de cualquier técnica bien documentada. T1053.005 («Scheduled Task», la subtécnica de tareas programadas de Windows dentro de T1053) lista, entre sus ejemplos de procedimiento documentados, a grupos tan distintos como APT29, APT3, Lazarus Group y Sandworm Team, junto con familias de malware como Agent Tesla y Emotet. Todos «usan tareas programadas», pero uno las crea con schtasks desde la línea de comandos con privilegios de sistema, otro las despliega vía objeto de directiva de grupo para ejecutar un wiper a una hora concreta, y otro las oculta manipulando directamente la clave de registro de la tarea. Fíjate en algo: eso no es una lista de casos raros, es la norma. Una técnica de ATT&CK describe un objetivo del atacante (persistir, moverse, exfiltrar), no un método único, así que «detectar la técnica X» sin más matiz no significa nada operativo hasta que decides cuál de esos procedimientos vas a poder ver y cuál no.
De ahí que la pregunta correcta no sea «¿cuánto de ATT&CK cubro?» sino «¿qué procedimientos concretos, contra qué activos, puedo ver con mi telemetría actual, y cuáles de esos tengo una regla que dispara de verdad?». Ese giro, de matriz completa a caso de uso concreto, es el resto del módulo.
Qué hay hoy en una página de técnica: Detection Strategies y Analytics
Si aprendiste ATT&CK con material de hace un par de años, es fácil que llegues aquí buscando el apartado «Data Sources» de cada técnica y no lo encuentres. No es un error tuyo, el modelo cambió, y conviene saber exactamente cuándo y en qué consiste el cambio antes de seguir.
El modelo vigente
La versión v18 de ATT&CK, publicada el 28 de octubre de 2025, sustituyó por completo el apartado de detección de cada técnica. Lo dicen así, sin rodeos, las notas oficiales de esa versión: «Detections in techniques have been replaced with Detection Strategies resulting in the addition of Detection Strategies and Analytics, major updates to Data Components, as well as the deprecation of Data Sources» (las detecciones de las técnicas se han sustituido por Detection Strategies, lo que añade Detection Strategies y Analytics, actualiza a fondo los Data Components y jubila los Data Sources). En esa versión, Enterprise pasó a tener 691 Detection Strategies y 1.739 Analytics; en la v19 vigente son 697 Detection Strategies y 1.758 Analytics para Enterprise, según la misma fuente de notas de versión de abril de 2026.
La jerarquía funciona así, de arriba abajo: una técnica (o subtécnica) puede tener una o varias Detection Strategies, cada una identificada con un ID DET#### y con un nombre que describe el enfoque de detección («Detección de creación y ejecución sospechosa de tareas programadas en Windows», por ejemplo). Cada Detection Strategy agrupa una o varias Analytics, con ID AN####, que son la parte concreta y aplicable: la lógica de detección en sí, atada a una plataforma. Cada Analytic trae, a su vez, sus Log Sources (de qué Data Component sale el dato, con qué canal y con qué evento concreto) y sus Mutable Elements (los campos que tú tienes que afinar para tu entorno, como una ventana de tiempo o una lista de nombres sospechosos).
Lo mejor es verlo con un caso real. La página de T1053.005 tiene, a fecha de esta sesión, una única Detection Strategy, DET0441: «Detection of Suspicious Scheduled Task Creation and Execution on Windows» (versión 1.0 del objeto, creado el 21 de octubre de 2025 y modificado por última vez el 12 de mayo de 2026). Contiene una sola Analytic, AN1221, que detecta «la creación, modificación o eliminación de tareas programadas a través del Programador de tareas, WMI, PowerShell o métodos basados en API, seguidas de ejecución desde svchost.exe o taskeng.exe«, incluyendo tareas ocultas o anómalas creadas bajo el contexto de SYSTEM o de un usuario sospechoso. Esta es la tabla real de Log Sources de esa Analytic, tal como la publica ATT&CK:
| Data Component | Canal | Evento |
|---|---|---|
| Scheduled Job Creation (DC0001) | WinEventLog:Security | EventCode=4698 |
| Scheduled Job Modification (DC0012) | WinEventLog:Security | EventCode=4702 |
| Process Creation (DC0032) | WinEventLog:Sysmon | EventCode=1 |
| File Creation (DC0039) | WinEventLog:Sysmon | EventCode=11 |
| Windows Registry Key Modification (DC0063) | WinEventLog:Sysmon | EventCode=13, 14 |
Ahí tienes, de fábrica, la lista de observables que ya viste dispersa en los módulos anteriores del curso: el 4698 de la categoría de auditoría avanzada «Other Object Access Events» (que ya trabajaste con auditpol), los eventos 1, 11, 13 y 14 de Sysmon con su configuración XML, y el canal de seguridad de Windows llegando por WEF o por agente hasta tu SIEM. La página de una Detection Strategy no te da la regla hecha, te da el mapa de qué debería estar sonando en tu tubería si el procedimiento ocurre.
El modelo anterior, para quien tenga apuntes de antes de 2025
Antes de octubre de 2025, cada técnica enlazaba directamente con una lista de Data Sources genéricos (por ejemplo «Process», «Command», «File») y, dentro de cada uno, sus Data Components («Process Creation», «Command Execution»…). Ese enlace era la única guía de detección: un texto breve, sin desglose por plataforma, sin ejemplos de canal ni de evento concreto, y sin distinción entre «esto detecta un aspecto» y «esto detecta el comportamiento completo». Si tienes un libro, un curso o unas notas que hablan de «40 data sources en Enterprise» como el corazón del modelo de detección de ATT&CK, es ese modelo antiguo. Sigue siendo útil como idea (list qué tipo de dato necesitas), pero como estructura de datos quedó retirada: la propia nota de v18 dice explícitamente «the deprecation of Data Sources».
El método: de la técnica al caso de uso
Con eso claro, el proceso para convertir una técnica en un caso de uso que funciona tiene cinco pasos. Los vas a ver aplicados sobre T1053.005, pero el orden vale para cualquier técnica que elijas.
1. Elegir la técnica por riesgo real, no por orden alfabético
No empieces por la primera técnica de la matriz. Empieza por lo que de verdad amenaza a tu organización: qué activos son críticos, qué grupos y qué campañas atacan a tu sector, y qué tan caro es escribir y mantener esa detección frente a lo que aporta. Una fuente pública que ayuda mucho aquí son los avisos conjuntos de agencias como CISA, que cada vez con más frecuencia publican sus tablas de TTP directamente en formato ATT&CK. Un ejemplo reciente y bien concreto: el aviso AA26-097A, sobre actores afiliados a Irán explotando autómatas programables (PLC) en infraestructura crítica de EE. UU., revisado por última vez el 22 de julio de 2026, usa explícitamente «the MITRE ATT&CK Matrix for Enterprise framework, version 19» y mapea la actividad observada a técnicas concretas: T1219 (Remote Access Tools, para el acceso remoto vía Dropbear SSH), T1041 (Exfiltration Over C2 Channel) y T1565 (Data Manipulation, incluida la alteración de lo que muestran las pantallas HMI/SCADA). El propio aviso recomienda «testing your existing security controls inventory to assess how they perform against the ATT&CK techniques described in this advisory». Eso es exactamente la lógica de priorización: no eliges qué detectar en abstracto, la eliges cruzando el riesgo de tu sector con lo que se ha visto usar de verdad contra organizaciones parecidas a la tuya.
2. Leer los procedimientos documentados, no solo el resumen
Una vez elegida la técnica, baja hasta la tabla de «Procedure Examples» de su página en ATT&CK. Ahí es donde está el trabajo real: no leas el párrafo genérico de arriba, lee fila por fila cómo la ejecutó cada grupo o cada pieza de software. Con T1053.005, por ejemplo, verás que APT3 crea tareas con schtasks y el parámetro /ru "System" para persistir con privilegios de sistema, mientras que Sandworm Team las programa a través de una GPO para lanzar su payload a una hora fijada de antemano. Son dos procedimientos del mismo T1053.005 y necesitan observables distintos: el primero deja rastro en la línea de comandos de schtasks.exe, el segundo puede no pasar nunca por ahí si la tarea la empuja el propio controlador de dominio.
3. Listar los observables y comprobarlos contra tu telemetría
Por cada procedimiento, anota qué debería quedar registrado y dónde. Aquí es donde conectas con lo que ya montaste en los módulos anteriores del curso: ¿tienes activada la subcategoría de auditoría avanzada que genera el 4698 (la viste al configurar la política de auditoría avanzada de Windows)? ¿tu configuración de Sysmon incluye un RuleGroup que no excluya ProcessCreate para schtasks.exe? ¿ese canal llega de verdad hasta tu SIEM por WEF o por el agente, o se está quedando en el endpoint? Este paso no es opinión, es verificación: abre tu propio índice de eventos y busca si el campo existe con datos reales, no si la documentación dice que «debería» existir. Un caso de uso que se basa en un Data Component que nunca llega a tu SIEM no es un caso de uso, es una aspiración con forma de regla.
4. Formular la hipótesis
Con los observables confirmados, escribe la hipótesis en una frase que se pueda falsar: «si alguien crea una tarea programada para ejecutarse con privilegios de SYSTEM fuera del proceso normal de despliegue de software, schtasks.exe aparecerá con /create y con /ru apuntando a SYSTEM en la línea de comandos, capturado por el evento 1 de Sysmon o por el 4698 de seguridad». Nota lo que hace esa frase: no dice «detecto tareas programadas», dice bajo qué condición concreta esperas ver qué campo con qué valor. Si no puedes escribir la hipótesis así de concreta, es que todavía no has terminado el paso 3.
5. Escribir la regla y probarla
La hipótesis se traduce en una regla, y la regla se prueba con un atómico antes de confiar en ella. No hace falta que la escribas desde cero pensando de memoria: esta es una regla real y vigente del repositorio de SigmaHQ, publicada bajo licencia Detection Rule License (DRL) 1.1 y firmada por su autor, tal como exige esa licencia. La copio literal, con su enlace permanente, para que veas cómo una hipótesis como la del paso anterior se convierte en condiciones concretas:
title: Schtasks Creation Or Modification With SYSTEM Privileges
id: 89ca78fd-b37c-4310-b3d3-81a023f83936
status: test
description: Detects the creation or update of a scheduled task to run with "NT AUTHORITYSYSTEM" privileges
references:
- https://www.elastic.co/security-labs/exploring-the-qbot-attack-pattern
- https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/schtasks
author: Nasreddine Bencherchali (Nextron Systems)
date: 2022-07-28
modified: 2025-02-15
tags:
- attack.privilege-escalation
- attack.execution
- attack.persistence
- attack.t1053.005
logsource:
product: windows
category: process_creation
detection:
selection_root:
Image|endswith: 'schtasks.exe'
CommandLine|contains:
- ' /change '
- ' /create '
selection_run:
CommandLine|contains: '/ru '
selection_user:
CommandLine|contains:
- 'NT AUT'
- ' SYSTEM '
filter_optional_teamviewer:
Image|endswith: 'schtasks.exe'
CommandLine|contains|all:
- '/TN TVInstallRestore'
- 'TeamViewer_.exe'
filter_optional_office:
CommandLine|contains|all:
- 'Subscription Heartbeat'
- 'HeartbeatConfig.xml'
- 'Microsoft SharedOFFICE'
filter_optional_avira:
CommandLine|contains:
- '/Create /F /RU System /SC WEEKLY /TN AviraSystemSpeedupVerify /TR '
- ':Program Files (x86)AviraSystem Speedupsetupavira_speedup_setup.exe'
- '/VERIFY /VERYSILENT /NOSTART /NODOTNET /NORESTART" /RL HIGHEST'
condition: all of selection_* and not 1 of filter_optional_*
falsepositives:
- Unknown
level: high(Regla original de SigmaHQ, ficha proc_creation_win_schtasks_system.yml, autoría de Nasreddine Bencherchali (Nextron Systems), copiada tal cual del repositorio.)
Fíjate en el bloque logsource: category: process_creation es la misma taxonomía de Sigma que ya viste en el módulo de normalización, el contrato que le dice al conversor a qué motor y a qué campo apuntar según tu origen. Y fíjate en los filter_optional_*: la regla no solo busca la condición positiva, también excluye explícitamente patrones conocidos de falso positivo (TeamViewer, la tarea de latido de suscripción de Office, el instalador de Avira), que es justo el tipo de ruido que solo se descubre probando la regla contra tráfico real, no pensándola en el escritorio.
Probarla significa, como mínimo, generar el evento tú mismo. El proyecto Atomic Red Team (licencia MIT) trae, para esta misma subtécnica, un test llamado «Scheduled Task Startup Script» que crea dos tareas con schtasks, una de ellas con /ru system:
schtasks /create /tn "T1053_005_OnLogon" /sc onlogon /tr "cmd.exe /c calc.exe"
schtasks /create /tn "T1053_005_OnStartup" /sc onstart /ru system /tr "cmd.exe /c calc.exe"(Test 1 de T1053.005 en Atomic Red Team.) La segunda línea dispara, en teoría, la regla de arriba. «En teoría» hasta que lo compruebas en tu propio laboratorio: verifica en tu entorno si el evento llega con los campos que la regla espera y si la condición se cumple. Ningún texto puede confirmarte eso, solo tu SIEM con el log delante.
Indicador frágil, indicador robusto
El mismo procedimiento se puede detectar con indicadores de calidad muy distinta, y la diferencia decide si la regla sobrevive dos semanas o dos años. Un indicador frágil es «el ejecutable se llama schtasks.exe«: es verdad casi siempre, pero un atacante que copie el binario con otro nombre, o que use la API de Task Scheduler directamente en vez de la utilidad de línea de comandos, se sale de esa condición sin esfuerzo. Un indicador robusto mira relación y comportamiento: no solo «existe schtasks.exe«, sino «existe schtasks.exe con /create o /change, con /ru apuntando a SYSTEM, salvo que el patrón coincida con software legítimo ya conocido». Eso es justo lo que hace la regla que acabas de leer: no dispara por el nombre del binario en solitario, exige la combinación de la acción (crear o cambiar) con el privilegio solicitado, y descarta explícitamente los patrones benignos ya identificados.
Esta idea ya la trabajaste, sin ponerle nombre formal, en los módulos anteriores del curso cuando insistíamos en que un evento de creación de proceso vale mucho más si trae el proceso padre. Tiene nombre: es la pirámide del dolor que David J. Bianco publicó en marzo de 2013, y cuya idea central (cuanto más arriba en la pirámide, más le cuesta al atacante evadir tu detección con un cambio trivial) es la misma que separa una regla que busca un nombre de fichero de una regla que exige una secuencia de comportamiento. En la práctica de escribir casos de uso, esto se traduce en una regla simple: si tu única condición es un valor que el atacante controla y puede cambiar gratis (un nombre de fichero, una IP, un hash), estás detectando el procedimiento de hoy, no la técnica.
Medir la cobertura con DeTT&CT
Hasta aquí has trabajado técnica a técnica. Para saber qué has cubierto de verdad, a nivel de todo tu programa de detección, existe DeTT&CT (Detect Tactics, Techniques & Combat Threats), un proyecto de código abierto (licencia GPL-3.0) impulsado originalmente por Rabobank. Su última versión etiquetada es la 2.2.0, publicada el 21 de enero de 2026, y el repositorio sigue activo: el 2 de junio de 2026 se fusionó un commit titulado «ATT&CK v19.1 support», así que no es un proyecto abandonado con material desfasado.
DeTT&CT modela tres cosas por separado, y la separación es el punto: no es lo mismo tener el dato que verlo, ni verlo que detectarlo.
- Calidad de las fuentes de datos: cuánto te puedes fiar de un origen concreto (cobertura de dispositivos, completitud de campos, retención, consistencia).
- Visibilidad: si, con esas fuentes, puedes llegar a observar los aspectos de una técnica, en una escala de 0 (ninguna) a 4 (excelente).
- Detección: si, aparte de verlo, tienes una regla escrita que dispara, en una escala de -1 (ninguna) a 5 (excelente).
La escala de detección, tal como la documenta la wiki del proyecto, es esta:
| Puntuación | Nivel | Qué significa |
|---|---|---|
| -1 | Ninguna | No hay detección. |
| 0 | Forense / contexto | No hay detección, pero el evento queda registrado y puede dar contexto en una investigación. |
| 1 | Básica | Hay una firma sencilla que cubre una parte concreta de los procedimientos. |
| 2 | Aceptable | Hay una regla, con correlación, que cubre más aspectos de los procedimientos. |
| 3 | Buena | Analítica más elaborada, con detección en tiempo real. |
| 4 | Muy buena | Muy eficaz detectando el uso malicioso de la técnica en tiempo real. |
| 5 | Excelente | Igual de eficaz que el nivel 4, y cubre todos los procedimientos conocidos. |
Cada técnica se administra en un fichero YAML (uno para fuentes de datos, otro para técnicas) que tú mismo rellenas y vas actualizando con fecha, puntuación y comentario cada vez que cambia algo. La herramienta, según la documentación de sus subcomandos, se invoca así para generar las capas de Navigator a partir de esos ficheros:
python dettect.py datasource -fd data-sources-endpoints.yaml -l
python dettect.py visibility -ft techniques-administration-endpoints.yaml -l -of visibilidad
python dettect.py detection -ft techniques-administration-endpoints.yaml -l -of deteccionEl flag -l pide la capa de Navigator, -fd y -ft apuntan al fichero de fuentes de datos y de técnicas respectivamente, y -of fija el nombre de salida. El propio repositorio trae ficheros de ejemplo con el esquema real; este es un fragmento tal cual, tomado de sample-data/techniques-administration-endpoints.yaml, para la propia T1053.005:
- technique_id: T1053.005
technique_name: Scheduled Task
detection:
- applicable_to:
- Windows workstations
location:
- Splunk use case X6
comment: ''
score_logbook:
- date: 2021-10-19T00:00:00Z
score: 2
comment: ''
visibility:
- applicable_to:
- Windows workstations
comment: ''
score_logbook:
- date: 2021-06-08
score: 2
comment: ''
auto_generated: trueEsos valores son del fichero de ejemplo del proyecto, no de tu entorno: cuando rellenes el tuyo, la puntuación y el comentario tienen que reflejar lo que has comprobado tú mismo en el paso 3 del método, no una copia de este ejemplo. El campo score_logbook es intencionadamente un histórico, no un valor único, para que quede constancia de cuándo mejoró (o empeoró) tu cobertura y por qué.
ATT&CK Navigator: dos capas superpuestas, no una capa mágica
El ATT&CK Navigator es una aplicación web (Apache-2.0, alojada oficialmente en mitre-attack.github.io/attack-navigator) que pinta y anota la matriz. No calcula nada por sí sola, solo visualiza capas JSON que tú le cargas, con el color, la puntuación y el comentario que cada capa trae para cada técnica.
Lo que la hace útil de verdad, más allá de pintar una matriz, es su función «Create Layer from other layers»: puedes cargar dos capas (por ejemplo, la de visibilidad y la de detección que generó DeTT&CT en el paso anterior), asignarles una letra (a, b) y combinarlas con una expresión. Según la propia guía de uso del proyecto, esa expresión puede ser aritmética (a+b, (a+b)/2, 100-a) o comparativa y booleana (a>b, que da puntuación 1 donde a es mayor que b y 0 en el resto, combinable con and, or, xor y not).
Esa segunda forma es la que de verdad importa para este módulo. Si a es tu capa de visibilidad y b tu capa de detección, la expresión a>b te pinta exactamente las técnicas donde ves más de lo que detectas: tienes el dato, pero no la regla. Eso es un hueco real y priorizable, distinto del hueco donde ni siquiera tienes el dato (visibilidad en 0). Confundir «no tengo regla» con «no tengo dato» es el error más común al leer un panel de cobertura, y separar las dos capas en vez de fundirlas en una sola puntuación es la forma de no caer en él.
Priorizar cuando no puedes con todo
Ningún equipo llega a cubrir cada procedimiento de cada técnica. La pregunta operativa es qué se aborda primero, y hay tres criterios que pesan más que los demás:
- El riesgo del activo: una técnica de movimiento lateral contra el controlador de dominio no pesa lo mismo que la misma técnica contra un puesto de soporte sin acceso a nada sensible.
- Lo que de verdad se usa contra tu sector: avisos como el AA26-097A citado antes, informes de amenaza de tu vertical y las técnicas que aparecen repetidas en campañas recientes pesan más que una técnica exótica sin uso documentado.
- El coste de detectarla: si la telemetría ya existe y solo falta la regla, el coste es bajo; si hace falta desplegar un agente nuevo, activar auditoría que hoy genera demasiado volumen, o construir una correlación entre varios orígenes, el coste sube y hay que sopesarlo contra el riesgo real.
Ninguno de los tres criterios se resuelve solo. Un activo crítico sin ningún indicio de que alguien lo ataque de esa forma concreta puede esperar; una técnica barata de cubrir pero contra un sistema irrelevante, también. La priorización buena cruza los tres a la vez, no elige uno y lo aplica en solitario a toda la matriz.
Por qué un panel en verde no significa que estés protegido
Una celda verde en Navigator, generada a partir de tu capa de detección de DeTT&CT, dice una cosa muy concreta: «existe un registro con una puntuación de detección igual o mayor que X para esta técnica en la fecha en que se anotó». No dice que la regla se haya probado esta semana, no dice que resista una variante nueva del procedimiento, y no dice que el origen de datos del que depende siga llegando (una integración que se rompe silenciosamente deja la regla viva en el papel y muerta en la práctica). Un auditor competente, al revisar un informe de cobertura, no se conforma con el color. Pregunta cosas como estas: ¿cuándo se validó por última vez cada regla marcada en verde con un atómico o un ejercicio de purple team? ¿qué procedimientos concretos de la técnica cubre la regla y cuáles quedan fuera? ¿la fuente de datos que sustenta la puntuación de visibilidad se ha comprobado con un log real esta semana, o la puntuación se puso una vez y no se ha vuelto a tocar? ¿qué pasa si el atacante usa la API en vez de la utilidad de línea de comandos que la regla vigila?
Ese ejercicio de validación sistemática, con Atomic Red Team y con un ciclo repetible de emular, observar y ajustar, es justo el contenido de un módulo posterior de este curso dedicado a validación y purple teaming. Aquí basta con quedarte con la idea: nunca afirmes que «esto detecta X» sin matiz, porque las tasas de falso positivo y falso negativo dependen del entorno de cada quien, y ni tú ni nadie las conoce hasta que las mide en su propio SIEM. Si el proceso te confirma una detección real, ese hallazgo pasa a manos del equipo de respuesta a incidentes, que ya no es trabajo tuyo. El tuyo es que el hueco entre lo verde del panel y lo que de verdad se detecta sea lo más pequeño posible, y que sepas, en todo momento, dónde está ese hueco.
Ejercicio de laboratorio
Vas a repetir el método completo con tu propia telemetría, usando software gratuito, y a producir un entregable real: una capa de Navigator con datos tuyos, no de ejemplo.
- Elige una técnica con presencia real en tu laboratorio (puedes seguir con
T1053.005o escoger otra que ya hayas instrumentado en el módulo de laboratorio del curso). Abre su página en attack.mitre.org y anota el ID de su Detection Strategy y de su Analytic, junto con la tabla de Log Sources. - En tu máquina Windows de laboratorio, confirma que la subcategoría de auditoría que genera el 4698 está activada y que tu configuración de Sysmon no excluye
ProcessCreateparaschtasks.exe. - Ejecuta el atómico de arriba (Test 1 de T1053.005 en Atomic Red Team) con privilegios de administrador.
- Busca en tu SIEM (Wazuh, Security Onion o el que montaste en el laboratorio) si el evento llegó, con qué campos exactos y con qué demora. Si no llegó nada, ese es tu resultado real: visibilidad 0, no lo maquilles.
- Si llegó, adapta la regla Sigma citada arriba a tu motor con sigma-cli (por ejemplo,
sigma convert -t splunk -p sysmon proc_creation_win_schtasks_system.yml, sustituyendo el backend por el tuyo) y comprueba si dispara contra el log que acabas de generar. - Rellena tu propio fichero de administración de técnicas de DeTT&CT con la puntuación de visibilidad y detección que has comprobado de verdad, con fecha de hoy y un comentario que explique de dónde sale ese número.
- Genera las dos capas con
dettect.py visibility -ft tu_fichero.yaml -lydettect.py detection -ft tu_fichero.yaml -l, cárgalas en Navigator y combínalas con la expresióna>bpara ver, en tu propio color, dónde ves más de lo que detectas. - Guarda esa capa combinada como el entregable del ejercicio: es tu medición real, no una simulación.
Preguntas frecuentes
¿Hace falta escribir una regla por cada Analytic que aparece en una técnica?
No necesariamente. Varios Analytics de la misma Detection Strategy pueden solaparse en la práctica, y una sola regla bien construida a veces cubre lo que ATT&CK documenta como dos Analytics distintos si comparten el mismo origen de datos y una lógica parecida. Lo importante no es igualar el número de reglas al número de Analytics, es no dejar sin cubrir ningún procedimiento que tu telemetría sí puede ver.
¿DeTT&CT sustituye a ATT&CK Navigator?
No, son complementarios. DeTT&CT es donde administras y puntúas tu cobertura (los ficheros YAML con tu histórico de puntuaciones); Navigator es donde la visualizas y la comparas. DeTT&CT genera las capas JSON, Navigator las pinta y permite combinarlas.
¿Por qué la tabla de Log Sources de una Analytic menciona Data Components si se supone que los Data Sources desaparecieron?
Porque son cosas distintas. Los Data Sources (el nivel genérico, tipo «Process») sí se retiraron como estructura de detección. Los Data Components (el nivel concreto, tipo «Process Creation» o «Scheduled Job Creation») siguen existiendo, pero ya no cuelgan directamente de la técnica: cuelgan de la Analytic, con su canal y su evento concretos, que es justo lo que los hace útiles para comprobar contra tu propia telemetría.
¿Puedo usar DeTT&CT si mi SIEM no es ninguno de los habituales del sector financiero o bancario?
Sí. DeTT&CT no depende de un producto concreto: tú decides, en tu propio fichero YAML, qué fuentes de datos tienes y con qué calidad, y la herramienta traduce eso a puntuaciones y capas. El origen del proyecto en Rabobank no limita su uso a ningún sector ni a ningún SIEM en particular.
Si mi capa de detección sale toda en verde, ¿ya puedo dar el programa de detección por terminado?
No. Una puntuación alta en tu propio fichero de DeTT&CT refleja lo que tú has anotado, y esa anotación puede estar desfasada si nadie ha vuelto a probar la regla desde que se puntuó. Trátala como un mapa que hay que revalidar con regularidad, no como un certificado permanente.