MITRE ATT&CK en la práctica: de una matriz coloreada a detecciones probadas

Una matriz de ATT&CK con muchas casillas marcadas puede resultar convincente en una presentación. Sin embargo, no explica por sí sola si el equipo detectaría una actividad concreta en sus sistemas. El marco de MITRE ofrece un lenguaje para describir comportamientos adversarios y organizar el trabajo. Su utilidad aparece cuando cada relación con una técnica se acompaña de datos disponibles, lógica comprensible, pruebas y una respuesta que alguien puede ejecutar.

Elegir comportamientos relevantes para el entorno

Empieza por los activos y accesos que importan a la organización. Si la actividad depende de identidades cloud y equipos de usuario, esos entornos merecen atención antes que tecnologías que no existen en la empresa. Selecciona escenarios plausibles y evita intentar cubrir toda la matriz al mismo tiempo. Un alcance pequeño y comprobado permite aprender y ampliar con criterio.

Describe el comportamiento en lenguaje operativo antes de asignar una referencia. Por ejemplo, una cuenta que incorpora un método de autenticación inesperado o un proceso que modifica una configuración de inicio. La referencia de ATT&CK ayuda a relacionarlo con conocimiento compartido, pero no reemplaza la explicación local. El analista necesita saber por qué ese comportamiento importa en su infraestructura.

Identificar la evidencia disponible

Para cada escenario, pregunta qué fuente observaría la acción. Una técnica puede manifestarse de distintas formas según plataforma y configuración. Si no se recogen los eventos necesarios, una regla importada no aportará cobertura real. Comprueba campos, permisos de auditoría y retención antes de dedicar tiempo a ajustar una consulta que trabajará sobre datos ausentes o incompletos.

Documenta además los límites. Una detección puede observar cambios en ciertos equipos gestionados y no en otros, o depender de una licencia que solo cubre parte de las identidades. Esas limitaciones no invalidan el caso de uso, pero deben ser visibles. Presentar una cobertura parcial como total dificulta decidir dónde invertir en nuevas fuentes o controles.

Diseñar una lógica que se pueda investigar

Una buena detección produce contexto suficiente para revisar el comportamiento. Incluye entidad, acción, periodo y eventos relacionados. Si la regla utiliza umbrales, explica cómo se eligieron y qué actividad legítima puede superarlos. El objetivo es que otra persona pueda mantenerla y distinguir un cambio de patrón de un fallo de implementación.

• Relaciona cada caso de uso con un comportamiento y los activos donde quieres observarlo.
• Registra las fuentes y campos necesarios, junto con sus limitaciones de cobertura.
• Define qué evidencia recibirá el analista y qué comprobación realizará después.
• Conserva casos de prueba y revisa la lógica cuando cambien aplicaciones o fuentes.

Validar sin poner en riesgo la operación

Las pruebas necesitan autorización, alcance y un método seguro. No es necesario ejecutar una cadena ofensiva completa para comprobar cada evento. Se pueden reproducir acciones administrativas controladas o utilizar simulaciones adecuadas al entorno. Coordina con operaciones, evita datos reales innecesarios y define cómo distinguir el ejercicio de un incidente auténtico que ocurra al mismo tiempo.

Comprueba la cadena completa: generación del evento, llegada a la plataforma, activación de la regla, creación del caso y comprensión por parte del analista. Si falla una etapa, registra dónde ocurrió. Decir que una detección no funciona puede ocultar un problema de recogida, mientras que declarar éxito porque aparece un evento puede ignorar que nunca se generó la alerta prevista.

Medir calidad por caso de uso

Valora cobertura de activos, resultados de pruebas, calidad de contexto y carga de revisión. El porcentaje de técnicas relacionadas puede acompañar esos datos, pero no debe sustituirlos. Una técnica amplia puede tener varias variantes y una única regla cubrir solo una. La documentación debe permitir distinguir qué comportamiento se comprobó y en qué condiciones.

Revisa las alertas legítimas para ajustar la lógica sin excluir categorías completas. Si una herramienta administrativa aparece con frecuencia, incorpora contexto sobre usuarios y destinos autorizados. Conserva capacidad para detectar su uso fuera de ese patrón. El aprendizaje de incidentes y ejercicios aporta ejemplos reales para mejorar la detección de forma gradual.

Mantener una cartera de detecciones

Asigna propietario y fecha de revisión a cada caso de uso. Retira reglas que ya no tengan datos o que dupliquen otras sin aportar valor, conservando el motivo del cambio. Cuando MITRE actualice el marco, revisa referencias sin asumir que toda modificación exige rehacer la lógica. El objetivo es una cartera comprensible de comportamientos vigilados y pruebas reproducibles, capaz de orientar decisiones técnicas más allá del aspecto de una matriz.