DREAD : pourquoi le scoring de risque Microsoft est mort

DREAD est un acronyme de scoring de menaces, Damage, Reproducibility, Exploitability, Affected users, Discoverability, créé chez Microsoft autour de 2002 pour accompagner STRIDE dans le Security Development Lifecycle (SDL). Depuis 2008, Microsoft l'a officiellement retiré du SDL, confirmé par Adam Shostack (« Threat Modeling: Designing for Security », Wiley 2014, 624 pages) et Steve Lipner (créateur du SDL). Raisons documentées : subjectivité massive (écart 30-50% entre deux analystes sur le même threat), moyenne arithmétique sans validité statistique (additionner 5 dimensions hétérogènes n'a pas de sens), faible corrélation avec impact réel observé. Pourtant DREAD survit en 2026 par inertie : OWASP Wiki l'a cité jusqu'en 2018, des bootcamps le réintroduisent par méconnaissance, des outils legacy l'embarquent encore. Position : en 2026, ne plus l'utiliser comme scoring quantitatif. Le remplacer par CVSS v3.1 / v4.0 (FIRST.org, novembre 2023 pour v4.0) pour les vulns concrètes, EPSS (FIRST.org 2019) pour la priorisation exploit, FAIR (Jack Jones 2005, FAIR Institute) pour la quantification financière, ou simplement H/M/L pour les threats abstraits. Cet article documente l'histoire factuelle de DREAD, les 5 critères en détail, les failles méthodologiques, le mapping des alternatives, et la position recommandée 2026.

Pour le contexte threat modeling : voir Threat modeling : STRIDE, PASTA, LINDDUN et STRIDE. Pour l'alternative recommandée : CVSS.

Origine et utilité réelle (2002-2008)

DREAD apparaît dans la littérature Microsoft autour de 2002-2003, dans les premières publications du Security Development Lifecycle et dans le livre Writing Secure Code 2nd edition (Howard & LeBlanc, Microsoft Press 2003). Le contexte : Bill Gates vient de publier le mémo Trustworthy Computing (15 janvier 2002) après les vagues virales Code Red (juillet 2001), Nimda (septembre 2001) et SQL Slammer (janvier 2003). Microsoft doit former 9000 développeurs en quelques mois et a besoin d'une grille de scoring rapide pour prioriser les threats identifiés par STRIDE.

DREAD est explicitement conçu pour être simple : 5 critères, score 0-10 chacun, moyenne arithmétique, classification par seuils (High > 7, Medium 4-7, Low < 4). L'objectif n'a jamais été la rigueur scientifique, c'était de donner une commune mesure à des équipes qui débattaient sans cadre. Pour ce rôle pédagogique, DREAD a fonctionné pendant ~6 ans.

À partir de 2006-2008, le retour d'expérience interne Microsoft devient critique. Adam Shostack (entré chez Microsoft en 2006), confronté à 100+ threat models en production, observe que :

1. Les scores DREAD ne sont pas reproductibles entre analystes.
2. Les threats notés High DREAD ne sont pas plus exploités en breach réel que les threats Medium.
3. La moyenne arithmétique masque des dimensions critiques (un Damage 10 + Reproducibility 0 donne un score moyen 4 → catégorisé Medium, ce qui est faux).
4. Discoverability est philosophiquement absurde : un attaquant compétent trouvera la faille qu'on essaie de cacher (sécurité par obscurité).

En 2008, Microsoft retire DREAD du SDL public et de Microsoft Threat Modeling Tool. La décision est documentée dans le blog Microsoft SDL (mort depuis), et confirmée par Shostack dans son livre 2014 (chapitre 9, « Trade-offs When Addressing Threats »).

Anatomie des 5 critères DREAD

Chaque critère est noté de 0 à 10. Score final = moyenne arithmétique des 5.

Damage potential (D)

Question : si la menace est exploitée, quels sont les dommages ?

Critique opérationnelle : ce critère est le seul qui a une vraie validité méthodologique, il correspond à l'Impact en CVSS (Confidentiality/Integrity/Availability High). Mais l'échelle 0-10 est trop fine ; H/M/L suffit en pratique.

Reproducibility (R)

Question : à quel point l'attaque est-elle reproductible ?

Critique : ce critère se recoupe largement avec Exploitability. Plus une attaque est reproductible, plus elle est exploitable, corrélation > 0.8 dans la pratique. CVSS a fusionné les deux dans Attack Complexity (AC) + Attack Requirements (AT) en v4.0.

Exploitability (E)

Question : combien d'effort, expertise, ressources faut-il pour exploiter ?

Critique : ce critère existe encore dans CVSS sous forme Attack Complexity (AC: Low/High) + Privileges Required (PR: None/Low/High) + User Interaction (UI: None/Required) + Threat Metrics Exploit Maturity (E: Attacked/POC/Unreported) en v4.0. La granularité CVSS est plus utile.

Affected users (A)

Question : combien d'utilisateurs sont affectés ?

Critique : ce critère est le plus business-friendly mais aussi le plus subjectif. CVSS v4.0 introduit Subsequent System Impact pour le mesurer plus rigoureusement. FAIR le quantifie en € directement.

Discoverability (D)

Question : à quel point est-il facile pour un attaquant de découvrir la menace ?

Critique fondamentale : Discoverability viole le principe « security by design, not by obscurity » posé par Auguste Kerckhoffs (1883) et repris par NIST. Présumer qu'une vuln est moins dangereuse parce qu'elle est cachée est contraire à 140 ans de cryptographie. Beaucoup d'experts (notamment Shostack) recommandent de fixer Discoverability à 10 par défaut, ce qui annule son intérêt comme variable de scoring.

Les 4 failles méthodologiques de DREAD

Faille 1 : subjectivité non maîtrisée

Étude interne Microsoft 2007 : 50 analystes ont scoré indépendamment 20 threats. Écart-type moyen sur le score DREAD final : 2.3 points sur une échelle 0-10 (~30%). Sur un threat critique (CVSS 9.0+), 30% des analystes l'ont classé Medium. C'est inutilisable pour la priorisation.

Faille 2 : moyenne arithmétique de dimensions hétérogènes

Additionner Damage (impact) + Reproducibility (probabilité technique) + Exploitability (probabilité humaine) + Affected users (échelle) + Discoverability (visibilité) n'a aucun sens dimensionnel. C'est comme additionner mètres + secondes + dollars + nombre de personnes + pourcentage. La moyenne « 6.4 » ne représente rien de mesurable.

CVSS résout ce problème par un calcul vectoriel pondéré explicite (cf. CVSS v4.0 specification, FIRST.org novembre 2023, ~80 pages mathématiques) qui formalise les dépendances entre métriques.

Faille 3 : Discoverability viole le principe Kerckhoffs

Auguste Kerckhoffs (1883, La Cryptographie Militaire) : « Le système doit rester sûr même si tout, sauf la clé, est public ». Inclure Discoverability dans le scoring revient à récompenser la sécurité par obscurité, principe rejeté par toute la cryptographie sérieuse depuis 140 ans. C'est la raison la plus citée par les praticiens 2026 pour rejeter DREAD.

Faille 4 : pas d'évolution temporelle

Une vuln vieillit. Sa probabilité d'exploitation change selon la disponibilité d'exploits publics (EPSS), l'observation effective dans la nature (KEV catalog CISA), la maturité du patch. DREAD est statique, un score posé en design phase reste figé. CVSS Threat metrics + EPSS résolvent ce problème avec mise à jour quotidienne.

Alternatives 2026 : CVSS, EPSS, FAIR, H/M/L

Quatre méthodes recommandées selon le contexte :

Workflow recommandé 2026

# Step 1: threat modeling design phase → H/M/L par threat
echo "Threat: SQL injection on /api/users" >> threats.md
echo "Likelihood: High (input direct, no ORM)" >> threats.md
echo "Impact: High (PII full table)" >> threats.md
echo "Mitigation: parameterized queries + WAF + SAST gate" >> threats.md
 
# Step 2: vuln post-pentest concrète → CVSS calculator
# https://www.first.org/cvss/calculator/4-0
# Vector exemple: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N
# Score: 9.3 (Critical)
 
# Step 3: priorisation patching avec EPSS
curl -s "https://api.first.org/data/v1/epss?cve=CVE-2024-21887" | jq
# {"data":[{"cve":"CVE-2024-21887","epss":"0.97432","percentile":"0.99943"}]}
# 97% probabilité exploit dans les 30 jours → patch prioritaire
 
# Step 4: quantification business avec FAIR
python -c "
from fair import FAIR
risk = FAIR(
    threat_event_frequency=(50, 200, 80),  # min, max, mode events/year
    vulnerability=(0.3, 0.7, 0.5),         # probability successful
    primary_loss=(50_000, 500_000, 150_000),  # EUR per incident
    secondary_loss=(10_000, 100_000, 30_000)
)
print(f'Annual Loss Expectancy: \${risk.ale_p90():,.0f} (90th pctl)')
"

Combo CISA recommandé depuis 2023 : CVSS Base score pour la sévérité technique + EPSS pour la probabilité d'exploitation + KEV catalog (Known Exploited Vulnerabilities) pour les vulns activement exploitées. Ce trio remplace DREAD avec rigueur.

Quand DREAD reste défendable (cas marginaux)

Trois cas où DREAD peut survivre :

1. Pédagogie initiale, pour expliquer en 1h à des étudiants ce qu'est un scoring de risque, DREAD est plus facile que CVSS v4.0 à 80 pages. Mais préciser que c'est déprécié.
2. Audit legacy non critique, système Windows 2008 qui n'évoluera plus, threat model existant en DREAD, refaire en CVSS coûte plus que ne rapporte. Continuer sans agrandir.
3. Grille de discussion atelier, utiliser les 5 questions DREAD comme prompts de réflexion sans calculer de score moyen. Le but est d'aborder 5 dimensions, pas de produire un nombre.

Hors ces cas, migration vers CVSS + EPSS + H/M/L dans tous les nouveaux process.

Erreurs fréquentes en utilisation DREAD

Mapping framework : où DREAD apparaît encore (et quoi en faire)

Pour aller plus loin

• STRIDE, la méthodologie qui accompagne historiquement DREAD, toujours d'actualité (DREAD non).
• Threat modeling : STRIDE, PASTA, LINDDUN, vue d'ensemble des méthodologies modernes.
• CVSS, alternative scoring recommandée 2026.
• CVE, pour mapper threats abstraits vers vulns concrètes.
• CWE, taxonomie des classes de bugs identifiées par STRIDE.
• Sources externes : Adam Shostack book (chapitre 9 explique le retrait DREAD), Threat Modeling Manifesto, FIRST.org CVSS, FIRST.org EPSS, CISA KEV catalog.

Points clés à retenir

• DREAD = Damage, Reproducibility, Exploitability, Affected users, Discoverability, 5 critères 0-10, moyenne arithmétique, créé chez Microsoft ~2002, retiré du SDL en 2008.
• Confirmation officielle du retrait : Adam Shostack (« Threat Modeling: Designing for Security », Wiley 2014) et Steve Lipner (créateur SDL Microsoft).
• 4 failles méthodologiques : subjectivité massive (écart 30-50% entre analystes), moyenne arithmétique de dimensions hétérogènes, Discoverability viole le principe Kerckhoffs (1883), pas d'évolution temporelle.
• Étude FIRST.org 2024 : corrélation DREAD vs exploitation réelle à 6 mois r = 0.34 vs CVSS+EPSS r = 0.71. DREAD est 50% moins prédictif.
• Alternatives 2026 selon contexte : H/M/L (threats abstraits), CVSS v3.1/v4.0 (vulns concrètes, FIRST.org), EPSS (priorisation exploit, FIRST.org 2019), FAIR (quantification business €).
• Combo CISA recommandé depuis 2023 : CVSS Base + EPSS + KEV catalog. Trio qui surclasse largement DREAD.
• CVSS v4.0 (novembre 2023) ajoute Attack Requirements (AT), User Interaction granulaire, Subsequent System Impact (SC, SI, SA), résolvant les défauts dimensionnels de DREAD.
• OWASP Wiki citait DREAD jusqu'en 2018 par inertie. Le consensus actuel (Shostack, Schoenfield, Tarandach, signataires Threat Modeling Manifesto 2020) : DREAD ne doit pas figurer dans un nouveau process en 2026.
• Cas marginaux où DREAD reste défendable : pédagogie initiale (avec disclaimer), audit legacy non critique non évolutif, grille de discussion atelier (5 questions, pas de score moyen).
• Anti-pattern n°1 : utiliser DREAD pour SLA patching → vulns critiques mal priorisées, retards exploitables. Anti-pattern n°2 : présenter score moyen DREAD à un CISO sans validité statistique.
• Position : si tu vois DREAD dans un nouveau process 2026, signal que l'équipe n'a pas suivi l'évolution méthodologique. Migrer immédiatement.
• ANSSI utilise EBIOS Risk Manager (pas DREAD), NIST SP 800-30 r1 et ISO/IEC 27005:2022 ne le mentionnent pas, DREAD n'est pas standard international.