STRIDE : méthodologie threat modeling de Microsoft

STRIDE est la méthodologie de threat modeling la plus déployée au monde en 2026, créée chez Microsoft en 1999 par Praerit Garg et Loren Kohnfelder (mémo interne avril 1999, publié 2002 dans MSDN), intégrée au Security Development Lifecycle (SDL) de Microsoft en 2002, popularisée par Adam Shostack dans son livre « Threat Modeling: Designing for Security » (Wiley, 2014, 624 pages). L'acronyme couvre 6 catégories de menaces qui violent les propriétés CIA + non-repudiation + authorization : Spoofing (auth), Tampering (intégrité), Repudiation (non-répudiation), Information disclosure (confidentialité), Denial of service (disponibilité), Elevation of privilege (autorisation). En 2026, deux variantes coexistent : STRIDE-per-element (matrice catégorie × type d'élément DFD, version pédagogique) et STRIDE-per-interaction (Larry Osterman, Microsoft 2007, granulaire et précise). Microsoft a publié en novembre 2023 une extension STRIDE-AI pour les systèmes IA/LLM, à combiner avec MITRE ATLAS et OWASP Top 10 for LLM v2.0 (octobre 2024). Le scoring DREAD historique est abandonné chez Microsoft depuis 2008, remplacé par CVSS ou H/M/L simple. Cet article documente les 6 catégories en détail, le mapping vers CWE et OWASP, le workflow opérationnel, l'adaptation à l'IA, et les anti-patterns persistants.

Pour la vue d'ensemble des méthodologies threat modeling : voir Threat modeling : STRIDE, PASTA, LINDDUN. Pour le catalogue des classes de bugs : CWE.

Origine et utilité réelle de STRIDE

Avril 1999 : Praerit Garg et Loren Kohnfelder, ingénieurs sécurité Microsoft, rédigent un mémo interne intitulé « The STRIDE Threat Model » pour structurer l'identification de menaces sur les produits Windows. L'objectif n'est pas académique : Microsoft sortait du Trustworthy Computing Memo de Bill Gates (15 janvier 2002, après les vagues virales Code Red, Nimda, SQL Slammer) et avait besoin d'une méthode reproductible pour entraîner 9000 développeurs en quelques mois. STRIDE remplit ce cahier des charges : 6 catégories simples, mémorables, mappables sur des contrôles connus.

Trois propriétés expliquent sa longévité :

1. Couverture exhaustive des propriétés sécurité, chaque catégorie viole une propriété nommable (authentication, integrity, non-repudiation, confidentiality, availability, authorization). Rien de critique n'est oublié structurellement.
2. Apprentissage rapide, un dev senior assimile la méthode en 2-4 heures de formation. Rare dans le threat modeling.
3. Compatibilité outillage, Microsoft Threat Modeling Tool, OWASP Threat Dragon, pytm, IriusRisk implémentent tous STRIDE en première classe.

Critique légitime : STRIDE ne hiérarchise pas les menaces (DREAD est mort, voir plus bas), ne capture pas les chaînes d'attaques (utiliser les attack trees pour cela), et reste centré système IT classique (les apps IA/ML demandent STRIDE-AI ou ATLAS). Mais comme point de départ universel, rien ne l'a remplacé en 25 ans.

Les 6 catégories STRIDE en détail

Spoofing (S), usurpation d'identité

Propriété violée : Authentication.

Définition : un attaquant prétend être quelqu'un ou quelque chose qu'il n'est pas, utilisateur, service, machine.

Exemples concrets 2024-2026 :

• Vol JWT par XSS, replay sur autre session.
• Session fixation (CWE-384) sur cookie sans HttpOnly + SameSite=Strict.
• DNS spoofing / ARP poisoning sur LAN sans 802.1X.
• IP spoofing pour bypass IP whitelist en upstream sans X-Forwarded-For validé.
• AS-REP roasting Active Directory (Kerberos pre-auth disabled), toujours observé chez ANSSI.
• OAuth2 mismatch entre redirect_uri et conf serveur (CVE-2024-32487, mars 2024).

Mitigations canoniques : MFA (TOTP, FIDO2/WebAuthn), mTLS pour service-to-service, certificats X.509 pour machines, signatures cryptographiques sur tokens (JWT signé HS256 ou RS256, jamais alg: none).

Mapping : CWE-287 (Improper Authentication), CWE-290 (Authentication Bypass by Spoofing), CWE-384 (Session Fixation). OWASP A07:2021.

Tampering (T), modification non autorisée

Propriété violée : Integrity.

Définition : un attaquant modifie des données en transit, au repos, ou dans la mémoire.

Exemples concrets :

• MITM TLS sans certificate pinning (mobile principalement, beaucoup d'apps banque encore vulnérables 2026).
• Modification d'un cookie role=user → role=admin côté client.
• Tampering avec un objet sérialisé Java/PHP (CVE-2024-1597 Postgres JDBC, février 2024).
• Modification de fichier sur un volume Docker mal isolé (CWE-732, Incorrect Permission Assignment).
• Race condition sur write to file (CWE-362, TOCTOU).
• Supply chain : modification d'un package npm publié (CVE-2024-3094 XZ Utils backdoor liblzma 5.6.0/5.6.1, mars 2024, CVSS 10.0).

Mitigations : signatures (HMAC, Sigstore, in-toto), TLS avec pinning, hash-and-verify (SBOM signé, image Docker signée Cosign), input validation server-side, parameterized queries.

Mapping : CWE-345 (Insufficient Verification), CWE-494 (Download of Code Without Integrity Check), CWE-502 (Deserialization of Untrusted Data). OWASP A08:2021.

Repudiation (R), désaveu d'action

Propriété violée : Non-repudiation.

Définition : un acteur (utilisateur ou attaquant) peut nier avoir effectué une action faute de preuve.

Exemples concrets :

• Logs d'audit absents ou supprimables par l'utilisateur dont on veut auditer les actions.
• Transactions financières sans signature électronique (eIDAS QSCD obligatoire pour signature qualifiée en UE).
• Logs centralisés sans intégrité (modifiables par admin local).
• Absence de write-once storage pour preuves (S3 Object Lock désactivé, ou rétention insuffisante).
• Pas de timestamp signé (RFC 3161) sur transactions critiques.

Mitigations : audit log centralisé immuable (S3 Object Lock, append-only Splunk index), signatures électroniques eIDAS qualifiées, journalisation structurée JSON avec signing chain (Sigsum, in-toto attestations), timestamp servers RFC 3161.

Mapping : CWE-778 (Insufficient Logging), CWE-117 (Improper Output Neutralization for Logs), CWE-223 (Omission of Security-relevant Information). OWASP A09:2021.

Information disclosure (I), divulgation

Propriété violée : Confidentiality.

Définition : exposition d'information à un acteur non autorisé.

Exemples concrets :

• SQL injection sur API publique (CWE-89, OWASP A03:2021), Top 1 historique.
• IDOR (Insecure Direct Object Reference, CWE-639), accès /api/users/123 sans check ownership.
• Verbosité erreurs en prod (stack trace Java révélant version Spring 5.3.18 vulnérable).
• Headers HTTP révélant version (Server: Apache/2.4.41 (Ubuntu), guidé sur les CVE 2.4.x).
• Path traversal (/api/file?path=../../etc/passwd, CWE-22).
• Cloud storage publique non intentionnellement (S3 buckets world-readable).
• Side channels timing (login user-or-pass-wrong, CWE-208).

Mitigations : input validation, parameterized queries (Prisma, SQLAlchemy), authorization checks au niveau objet (RBAC + ABAC), error handling générique, headers minimaux (server_tokens off nginx), monitoring expositions cloud (CSPM Wiz/Prisma Cloud).

Mapping : CWE-200 (Exposure of Sensitive Information), CWE-22 (Path Traversal), CWE-89 (SQL Injection), CWE-639 (IDOR). OWASP A01:2021 + A03:2021 + A04:2021.

Denial of service (D), déni de service

Propriété violée : Availability.

Définition : rendre le système indisponible ou dégradé pour les utilisateurs légitimes.

Exemples concrets 2024-2026 :

• DDoS L7 HTTP/2 Rapid Reset (CVE-2023-44487, octobre 2023, record 398M req/s sur Google Cloud).
• ReDoS (Regex Denial of Service, CWE-1333), regex catastrophique sur input user.
• Compression bomb (CWE-409), zip 1MB qui devient 10GB extrait.
• Resource exhaustion via création illimitée de comptes / sessions / fichiers.
• DoS algorithmique : hash collision DoS (CVE-2011-4815 historique, toujours observé sur API custom).
• DoW (Denial of Wallet) sur LLM API : épuisement budget OpenAI/Anthropic via prompt injection.

Mitigations : rate limiting (1-5 req/s anonymous, 10-50 req/s authenticated), connection limits, timeouts agressifs (5-30s), circuit breakers (Hystrix patterns), CDN avec DDoS protection (Cloudflare, Fastly), resource quotas (cgroups, Kubernetes limits).

Mapping : CWE-400 (Uncontrolled Resource Consumption), CWE-770 (Allocation Without Limits), CWE-1333 (ReDoS), CWE-409 (Improper Handling of Highly Compressed Data).

Elevation of privilege (E), élévation de privilèges

Propriété violée : Authorization.

Définition : un attaquant gagne des droits qu'il ne devrait pas avoir.

Exemples concrets :

• Buffer overflow → RCE root (CVE-2024-6387 regreSSHion OpenSSH, juillet 2024, CVSS 8.1).
• IDOR vertical : ?role=admin accepté côté serveur.
• Container escape via privileged + hostPath mount (CVE-2024-21626 runc, janvier 2024).
• Sudo bug (CVE-2023-22809 sudoedit, vieux mais reproduit).
• Linux kernel exploit (CVE-2024-1086 nf_tables, mars 2024, CVSS 7.8).
• JWT alg: none accepté → forge token admin.
• Path traversal vers fichier de config sensible permettant escalation.

Mitigations : least privilege strict (drop capabilities Linux, no-new-privileges Kubernetes), seccomp profiles, AppArmor/SELinux, validation explicite des autorisations à chaque endpoint, principe de zero trust côté authorization (RBAC/ABAC), patching agressif (J+7 max sur CVSS ≥ 8 sur composant exposé).

Mapping : CWE-269 (Improper Privilege Management), CWE-285 (Improper Authorization), CWE-863 (Incorrect Authorization), CWE-787 (Out-of-bounds Write). OWASP A01:2021.

STRIDE-per-element vs STRIDE-per-interaction

Microsoft a documenté deux variantes opérationnelles. Différences :

Matrice STRIDE-per-element classique :

Lecture : sur un process (API REST par ex.), les 6 catégories s'appliquent toutes. Sur un data flow, seuls T/I/D s'appliquent (le flow lui-même ne s'authentifie pas, ne nie pas, n'élève pas de privilège).

Workflow opérationnel : faire un STRIDE en 4 phases

# Setup pytm pour threat model as code
pip install pytm
mkdir threat-models && cd threat-models

# threat_model_api_users.py, exemple complet pytm + STRIDE
from pytm import TM, Server, Datastore, Dataflow, Boundary, Actor, Lambda
 
tm = TM("API Users, STRIDE threat model")
tm.description = """
API REST exposant CRUD users avec PostgreSQL backend.
Auth via JWT signé RS256.
"""
 
# --- Boundaries ---
internet = Boundary("Internet")
dmz = Boundary("DMZ")
internal = Boundary("Internal Network")
 
# --- Actors / Entities ---
user = Actor("Authenticated User")
user.inBoundary = internet
 
attacker = Actor("Anonymous attacker")
attacker.inBoundary = internet
 
# --- Processes ---
waf = Server("Cloudflare WAF + reverse proxy")
waf.inBoundary = dmz
waf.controls.sanitizesInput = True
waf.controls.handlesResourceConsumption = True
 
api = Server("API REST /users")
api.inBoundary = internal
api.OS = "Alpine 3.20"
api.controls.usesEncryptionAlgorithm = "AES-256-GCM"
api.controls.checksInputBounds = True
api.controls.encodesOutput = True
api.controls.authenticatesSource = True
api.controls.authorizesSource = True
 
# --- Datastores ---
db = Datastore("PostgreSQL 16")
db.inBoundary = internal
db.controls.isEncryptedAtRest = True
db.controls.implementsAuthenticationScheme = True
 
audit = Datastore("Audit log S3 Object Lock")
audit.inBoundary = internal
audit.controls.isEncryptedAtRest = True
audit.controls.implementsAuthenticationScheme = True
 
# --- Dataflows (HTTPS in/out) ---
ingress = Dataflow(user, waf, "GET /api/users/:id (JWT bearer)")
ingress.protocol = "HTTPS"
ingress.dstPort = 443
ingress.controls.isEncrypted = True
ingress.controls.authenticatesDestination = True
 
forward = Dataflow(waf, api, "Forward request")
forward.protocol = "HTTPS"
forward.dstPort = 8443
forward.controls.isEncrypted = True
 
query = Dataflow(api, db, "SELECT u.* FROM users WHERE id = 0.9 €")
query.protocol = "TCP/TLS"
query.dstPort = 5432
query.controls.usesParameterizedQueries = True
 
logging = Dataflow(api, audit, "Append audit event")
logging.protocol = "HTTPS"
logging.dstPort = 443
 
attack = Dataflow(attacker, waf, "Probe / scan / exploit attempts")
attack.protocol = "HTTPS"
attack.dstPort = 443
 
if __name__ == "__main__":
    tm.process()

# Génération du threat model
python threat_model_api_users.py --report template.md > threat_report.md
python threat_model_api_users.py --dfd | dot -Tsvg -o dfd.svg
python threat_model_api_users.py --json > threat_model.json

Workflow en 4 phases :

1. Diagrammer (1-2h) : DFD avec boundaries, processes, flows, stores. Whiteboard ou Threat Dragon ou pytm.
2. Énumérer (3-6h) : appliquer STRIDE-per-element à chaque élément, lister les menaces concrètes (pas génériques).
3. Mitiger (2-4h) : pour chaque menace, contrôle existant ou à ajouter. Ticket Jira nominatif.
4. Valider (1-2h) : review par pair, mise à jour Confluence + Git, intégration backlog.

Total : 1-2 jours pour app web standard. Multiplier par ~3-5 si système distribué complexe.

STRIDE-AI : extension Microsoft 2023 pour systèmes IA

Microsoft Responsible AI a publié en novembre 2023 une extension STRIDE pour systèmes ML/LLM. Mapping :

À combiner avec MITRE ATLAS (Adversarial Threat Landscape for AI Systems, juin 2021, MAJ continue 2024-2026) qui catalogue 70+ techniques adverses, et OWASP Top 10 for LLM Applications v2.0 (octobre 2024) qui codifie les 10 risques majeurs.

Pourquoi DREAD est mort (et ce qui le remplace)

DREAD (Damage, Reproducibility, Exploitability, Affected users, Discoverability) a accompagné STRIDE dans les premiers documents Microsoft (2002-2008). Score 0-10 par critère, moyenne pour priorisation. Microsoft l'a retiré du SDL en 2008, confirmé par Adam Shostack (Microsoft 2006-2014, livre 2014) et Steve Lipner (créateur du SDL).

Raisons documentées :

1. Subjectivité massive : deux analystes notent un même threat avec écart 30-50% sur le score moyen.
2. Pas de corrélation avec impact réel : threats notés haut DREAD parfois jamais exploités, threats notés bas DREAD parfois critiques en breach réel.
3. Effet de fausse précision : un score 7.4 paraît plus rigoureux qu'un score 7.2, alors que la différence est dans le bruit.
4. Hostilité avec scoring CVSS : pourquoi maintenir deux échelles quand CVSS est devenu universel ?

Remplacements actuels en 2026 :

Position : utiliser H/M/L pour démarrer, basculer CVSS-style ou FAIR quand maturité acquise. Ne pas écrire DREAD dans un nouveau process en 2026.

Erreurs fréquentes en STRIDE

Pour aller plus loin

• Threat modeling : STRIDE, PASTA, LINDDUN, vue d'ensemble des méthodologies, outillage et workflow.
• CWE (Common Weakness Enumeration), pour cataloguer les classes de bugs identifiées par STRIDE.
• CVE, pour mapper menaces théoriques vers CVE concrètes.
• SAST, pour valider en CI/CD que les mitigations identifiées sont implémentées.
• Zero Trust Architecture (ZTA), modèle architectural qui transforme les trust boundaries STRIDE.
• Sources externes : Microsoft STRIDE chart, Adam Shostack book, Threat Modeling Manifesto, MITRE ATLAS, OWASP Top 10 for LLM v2.0.

Points clés à retenir

• STRIDE créée chez Microsoft en avril 1999 par Praerit Garg & Loren Kohnfelder, popularisée par Adam Shostack (livre 2014, 624 pages, référence canonique).
• 6 catégories : Spoofing (auth), Tampering (intégrité), Repudiation (non-répudiation), Information disclosure (confidentialité), Denial of service (disponibilité), Elevation of privilege (autorisation).
• Mapping CWE/OWASP : Spoofing → CWE-287/A07, Tampering → CWE-345/A08, Repudiation → CWE-778/A09, Info disclosure → CWE-200/A03/A04, DoS → CWE-400, EoP → CWE-269/A01.
• 2 variantes : STRIDE-per-element (matrice 6×4, pédagogique, 1999) vs STRIDE-per-interaction (Larry Osterman 2007, plus précis, 2-3x plus de lignes).
• DREAD abandonné chez Microsoft en 2008, trop subjectif, pas corrélé impact réel. Remplacé par H/M/L simple ou CVSS v3.1/v4.0 ou FAIR.
• STRIDE-AI publié par Microsoft en novembre 2023, extension pour ML/LLM : training data poisoning, model inversion, prompt injection, jailbreak, DoW.
• À combiner pour systèmes IA avec MITRE ATLAS (juin 2021, MAJ 2024) et OWASP Top 10 for LLM v2.0 (octobre 2024).
• ROI Microsoft mesuré : 0.9 € en threat modeling design phase = 90 € économisés en correction post-prod. Toujours en design.
• Outillage 2026 : OWASP Threat Dragon v2.4 (gratuit, GUI), pytm (threat model as code Python), Microsoft Threat Modeling Tool 2016 (gratuit Win-only, figé), IriusRisk (commercial, 50-200€/user/mois).
• Workflow STRIDE 4 phases : Diagrammer (1-2h) → Énumérer (3-6h) → Mitiger (2-4h) → Valider (1-2h). Total 1-2 jours pour app standard.
• Anti-pattern n°1 : faire STRIDE post-design ou post-prod = trop tard. Anti-pattern n°2 : DREAD revival = bikeshed sur scoring subjectif.
• Position : démarrer STRIDE-per-element avec H/M/L scoring, ajouter STRIDE-AI/ATLAS si système IA, basculer per-interaction quand maturité acquise.