Cinq axes, une moyenne, un chiffre
DREAD est née dans l'écosystème threat modeling de Microsoft, en complément de STRIDE (qui identifie les menaces) : là où STRIDE dit quoi craindre, DREAD dit à quel point le craindre. Le principe est brutalement simple. Chaque menace identifiée reçoit cinq notes indépendantes, sur une échelle 1–10 (ou 1–3 dans la variante allégée) :
| Lettre | Axe | Question posée |
|---|---|---|
| D | Damage | Quelle est l'ampleur du dégât en cas de succès ? (impact financier, données, réputation) |
| R | Reproducibility | L'attaque est-elle rejouable de façon fiable, ou dépend-elle de conditions rares ? |
| E | Exploitability | Faut-il un exploit sur mesure et un attaquant expert, ou un script kiddie s'en sort ? |
| A | Affected users | Combien d'utilisateurs, de systèmes ou de clients sont touchés par la compromission ? |
| D | Discoverability | À quel point la vulnérabilité est-elle facile à trouver pour un attaquant qui cherche ? |
Le score final est la moyenne des cinq notes. Deux menaces se comparent alors sur une échelle unique, et c'est là toute la promesse : transformer un désaccord d'opinion en un chiffre partagé.
Le vrai usage de DREAD : le threat modeling en amont
DREAD a été pensée pour un contexte précis : la revue de conception. On liste, au tableau, les menaces identifiées par STRIDE sur une nouvelle fonctionnalité ; on note ; on priorise ce qu'on va traiter avant la mise en production. Dans ce cadre, la méthode a deux vertus réelles :
- Un vocabulaire commun : cinq axes explicites forcent à ne pas noyer la conversation dans le seul « impact ». Un pentesteur, un architecte et un chef de produit posent enfin les mêmes questions.
- Une traçabilité de la décision : on garde en dossier pourquoi telle menace a été traitée et telle autre acceptée. Le jour de l'audit ou du RETEX, la logique n'a pas à être reconstituée de mémoire.
- Une échelle mémorisable : DREAD tient sur un post-it. En atelier de threat modeling, ce n'est pas un détail. La méthode que personne ne se rappelle est celle qui n'est jamais appliquée.
Utilisée pour ce à quoi elle sert (trancher entre menaces au stade design, dans un atelier limité dans le temps), DREAD reste défendable. Ce n'est pas là qu'elle échoue.
Trois défauts que Microsoft a fini par acter
Vers 2008, les équipes SDL de Microsoft (celles-là mêmes qui avaient poussé la méthode) l'ont retirée de leur cursus interne. Les raisons sont documentées, et elles tiennent en trois points.
| Défaut | Ce qu'il produit | Pourquoi c'est structurel |
|---|---|---|
| Subjectivité des notes | Deux analystes notent la même menace 4 et 8. La moyenne fait 6, l'écart est perdu. | Aucun barème public ne précise ce qui vaut 6 plutôt que 7, chacun ancre selon son expérience. |
| Discoverability = sécurité par l'obscurité | Une vuln non publiée reçoit un D faible, donc un score global rassurant. | L'axe pénalise la découverte publique et récompense l'ignorance : incompatible avec toute posture moderne. |
| Moyenne qui écrase les extrêmes | Un dommage catastrophique (10) sur peu d'utilisateurs (2) devient un 6, traité comme tiède. | La moyenne suppose que les axes sont commensurables. Un impact vital n'est pas rattrapable par un E bas. |
Ces trois défauts ne sont pas des maladresses d'implémentation, ils sont dans le modèle lui-même. On peut les patcher (pondération, retrait de la découvrabilité, remplacement de la moyenne par un max), mais à ce stade, on n'utilise plus DREAD, on utilise autre chose qui lui ressemble.
Comment utiliser DREAD sans se piéger
Si vous héritez d'un contexte où DREAD est déjà en place (habitude d'équipe, exigence d'un référentiel, formalisme d'un audit), quelques garde-fous suffisent à éviter les erreurs les plus grossières :
- Retirer purement et simplement la découvrabilité. Le score se calcule alors sur D-R-E-A : quatre axes, moyenne sur quatre. C'est la première chose que font les équipes qui gardent DREAD sérieusement.
- Écrire un barème documenté. Un 8 en Damage doit renvoyer à une liste explicite : perte de données régulées, indisponibilité > 24 h, atteinte à des vies. Sans ça, chaque revue redevient une négociation.
- Passer d'une moyenne à un max pondéré. Si Damage vaut 10, le score ne peut pas descendre sous un plancher, peu importe le reste. Un impact vital ne se dilue pas.
- Ne l'utiliser qu'au stade conception. Pour la priorisation d'alertes en production, il faut un scoring composite dynamique, pas une note figée en atelier.
Ce qui a pris la place de DREAD
Les usages historiques de DREAD se sont scindés entre plusieurs outils, chacun mieux adapté à un contexte :
Ces méthodes ne sont pas des extensions de DREAD : ce sont des approches structurellement différentes qui traitent, chacune, un morceau de ce que DREAD prétendait couvrir seule. Le bon réflexe n'est pas de choisir une méthode universelle, mais de choisir la méthode adaptée au moment du cycle.
C'est exactement le principe qui structure ARTEFACT côté production : la priorisation ne se fait pas sur un score figé, mais sur un risk_score composite qui recompose en temps réel la gravité de la technique, la criticité de l'actif touché, la fiabilité historique de la règle et l'accumulation de signaux sur une même entité. C'est ce qui manquait à DREAD pour tenir en production, et c'est ce qui a rendu la méthode obsolète pour cet usage, pas pour tous.