Cartographier sa détection sur ATT&CK sans se mentir

La première fois qu’on colorie sa matrice ATT&CK en vert, on se sent invincible. Puis on rejoue une technique basique en conditions réelles, l’alerte ne part pas, et la belle heatmap se transforme en aveu : on avait cartographié des intentions, pas des détections.

ATT&CK est un langage formidable et un piège tendre. Formidable parce qu’il donne un vocabulaire commun pour parler de ce que font réellement les attaquants. Piège parce qu’il est trop facile de marquer une technique « couverte » dès qu’on a une vague règle, un log quelque part, une bonne intention. La couverture déclarée et la détection réelle sont deux choses différentes · et seule la seconde compte la nuit.

La seule cartographie honnête est celle qu’on a testée. Pour chaque technique que je prétends couvrir, je veux une trace : une exécution contrôlée (Atomic Red Team, un script maison), l’événement attendu dans les logs, et l’alerte qui part vraiment. Si l’un des trois manque, la case n’est pas verte · elle est jaune, « instrumentée mais non prouvée », ou rouge, « angle mort assumé ». Le jaune et le rouge sont les couleurs les plus utiles de la matrice.

Vient ensuite la priorisation. On ne couvre pas tout, et c’est très bien · à condition de choisir en fonction de la menace réelle, pas de l’ordre des colonnes. Quelles techniques sont effectivement utilisées contre des cibles comme la mienne ? Lesquelles précèdent un impact grave ? On y met l’effort, on documente le reste comme dette assumée, et on arrête de se mentir avec un dégradé de vert.

# T1059.001 · PowerShell · exécution encodée
attack_technique: T1059.001
test:
  name: "Encoded command"
  executor: powershell
  command: |
    powershell -enc <base64>
expected_event: "4104 ScriptBlock + EncodedCommand"
must_alert: true   # si false en test -> case NON couverte