Pour le cadre général (4 questions de Shostack, DFD, STRIDE, DREAD, PASTA, arbres d’attaque, CVSS, intégration SDLC), voir la note canonique [[Threat Modeling]]. Cette note se concentre sur l’usage défensif du threat modeling côté SOC : transformer un modèle de menace en couverture de détection.

Côté SOC, le threat modeling ne sert pas à concevoir un système sécurisé mais à répondre à une question opérationnelle : « contre quelles techniques d’attaque sommes-nous capables de détecter, et où sont nos angles morts ? »

De STRIDE/DFD vers la détection§

  1. Partir des trust boundaries du DFD (cf. [[Threat Modeling]]) : ce sont les points où une attaque devient observable (entrée utilisateur → backend, internet → DMZ).
  2. Pour chaque menace STRIDE identifiée, se demander quel artefact de log elle produirait (event Windows, log proxy, NetFlow, télémétrie EDR).
  3. Vérifier qu’une règle de détection existe pour cet artefact — sinon, c’est un angle mort à combler. Voir [[Detection Engineering]] et [[Sigma]].

MITRE ATT&CK Navigator comme carte de couverture§

C’est l’outil central du threat modeling défensif (mitre-attack.github.io/attack-navigator/) :

Priorisation par le risque§

Le SOC priorise ses efforts de détection avec les mêmes outils que la note canonique — CVSS, matrice probabilité × impact, et les stratégies de traitement (mitigate / transfer / accept / avoid) — mais appliqués à la capacité de détection plutôt qu’à la vulnérabilité elle-même : une technique à fort impact et fréquemment utilisée par les APT du secteur passe en tête du backlog de detection engineering.

Voir aussi§