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

Colorier une matrice ATT&CK en vert donne une belle image et une fausse assurance : une case verte ne prouve rien tant qu’aucune alerte n’est jamais partie. Je traite donc mes règles comme du code · versionnées, rejouées, validées en continu · pour que « couvert » veuille dire « déclenché lors d’un test », pas « une règle existe quelque part ».

Avoir le log ne veut pas dire voir l’attaque. Un journal collecté mais jamais corrélé, un capteur mal réglé, une règle générique qui ne correspond pas à la variante réelle : dans les trois cas la couverture est théorique, et l’attaquant passe pendant qu’on se croit couvert. La seule mesure qui compte est celle prise capteur allumé, sous attaque simulée.

Une cartographie intègre et exploitable doit s’appuyer sur des exercices de simulation contrôlés. Chaque technique réputée couverte doit faire l’objet d’une émulation (via des scénarios d’attaque standardisés), d’une vérification de la collecte télémétrique et de la levée effective de l’alerte de sécurité.

On ne couvre pas tout, et prétendre le contraire est le vrai risque. Je priorise la menace qui vient réellement chez moi, pas le remplissage de la matrice, et je liste noir sur blanc ce que je ne détecte pas encore. Un angle mort documenté est une tâche de la feuille de route · un angle mort ignoré est une brèche qu’on découvre après coup.

# T1059.001 · PowerShell · validation par exécution encodée
attack_technique: T1059.001
test:
  name: "Emulation encoded commands"
  executor: powershell
  command: |
    powershell -ExecutionPolicy Bypass -EncodedCommand <payload_base64>
expected_event: "4104 ScriptBlockLogging"
must_alert: true