MITRE ATT&CK y los logs: sin telemetría, la cobertura es ficticia
Organizaciones mapeándose a MITRE sin resolver lo básico: qué logs tienen, de dónde vienen y con qué calidad llegan al SOC. Sin logs, las técnicas no son detectables.
El error más frecuente
Uno de los errores más frecuentes que observo: organizaciones intentando “mapearse a MITRE” sin resolver lo básico.
¿Qué logs tienes? ¿De dónde vienen? ¿Con qué calidad llegan al SOC?
ATT&CK no es magia
ATT&CK es un lenguaje común para describir comportamiento adversario.
Pero ese lenguaje solo se puede “leer” si la organización ve. Y ver significa registrar eventos.
Cada técnica deja huellas distintas según la capa:
| Capa | Qué registra |
|---|---|
| Endpoint | Procesos, DLLs, credenciales, acceso a archivos |
| Identidad | Autenticaciones anómalas, movimiento lateral, escalamiento |
| Red | C2, beaconing, exfiltración, escaneo |
| Correo | Phishing, OAuth abuse, adjuntos maliciosos |
Sin logs, las técnicas no son detectables. La cobertura ATT&CK se vuelve ficticia.
Cámaras que no graban
Decir “cubrimos ATT&CK” sin evidencias es como decir:
“Tenemos cámaras, pero no graban.”
Un mapa de cobertura lleno de verde sin fuentes de telemetría validadas es un ejercicio de autoengaño. Le dice al directorio que la organización está protegida cuando no lo está.
Por dónde empieza un SOC maduro
Un SOC maduro no empieza por reglas complejas de correlación. Empieza por:
1. Inventario de fuentes críticas
¿Qué fuentes de log existen? ¿Cuáles están conectadas al SIEM? ¿Cuáles faltan?
Las fuentes mínimas para cobertura básica:
- Logs de endpoint (EDR, Sysmon)
- Logs de autenticación (AD, IAM)
- Logs de red (firewall, proxy, DNS)
- Logs de correo (gateway, O365/Google Workspace)
2. Calidad y normalización
Un log que llega mal formateado, incompleto o con timestamp incorrecto es peor que no tener log — genera falsa confianza.
Verificar:
- Campos críticos presentes (usuario, IP origen, proceso, timestamp)
- Timestamps sincronizados (NTP)
- Formato consistente y parseable
- Retención suficiente para investigación
3. Casos de uso mapeados a técnicas
No crear reglas genéricas. Mapear cada caso de uso de detección a una técnica específica de ATT&CK:
- T1059.001 (PowerShell) → Detectar ScriptBlock con DownloadString
- T1078 (Valid Accounts) → Detectar login desde ubicación anómala
- T1071 (Application Layer Protocol) → Detectar beaconing en DNS
4. Validación continua
Las reglas de detección se degradan con el tiempo:
- Cambios en la infraestructura invalidan reglas existentes
- Actualizaciones de software cambian los formatos de log
- Los adversarios adaptan sus técnicas
Validar periódicamente que las detecciones siguen funcionando — con purple team, atomic tests o herramientas de simulación.
Para la dirección
Invertir en ATT&CK sin invertir en logging es construir sobre arena.
Los logs son el activo central de:
- Detección: sin logs, no hay alertas
- Respuesta: sin logs, no hay investigación forense
- Cumplimiento: sin logs, no hay evidencia ante reguladores
Si no sabes qué logs tienes, el riesgo ya está materializado.
Referencias
- MITRE Corporation. (2024). Data sources
- Scarfone, K., & Souppaya, M. (2023). Cybersecurity log management planning guide (Draft NIST SP 800-92 Rev. 1)
- Strom, B. E., et al. (2020). MITRE ATT&CK: Design and philosophy