Threat modeling avec STRIDE : intégrer la sécurité dès la phase de conception

Le threat modeling (modélisation des menaces) est l'art d'identifier les risques de sécurité avant d'écrire la moindre ligne de code. Microsoft a introduit STRIDE dans les années 2000 ; aujourd'hui, des entreprises comme Google, Amazon et Netflix l'intègrent systématiquement dans leur processus de développement. Résultat :un bug de sécurité détecté en phase de conception coûte 30× moins cherà corriger qu'en production (IBM SEIS).

1. Qu'est-ce que le threat modeling ?

Le threat modeling est un processus structuré qui répond à 4 questions fondamentales :

• Sur quoi travaille-t-on ? — Cartographie du système (data flow diagrams, composants, flux).
• Qu'est-ce qui peut mal tourner ? — Identification des menaces avec STRIDE ou autre cadre.
• Que fait-on à ce sujet ? — Contre-mesures, contrôles, décisions d'acceptation du risque.
• Avons-nous bien fait notre travail ? — Validation et documentation.

2. La méthode STRIDE en détail

STRIDE est un acronyme mnémotechnique qui couvre 6 catégories de menaces, chacune associée à une propriété de sécurité à protéger :

• S — Spoofing (Usurpation d'identité) : un attaquant se fait passer pour un utilisateur légitime ou un composant. Contre-mesure : authentification forte (MFA, certificats mutuels TLS).
• T — Tampering (Altération des données) : modification non autorisée de données en transit ou au repos. Contre-mesure : intégrité cryptographique (HMAC, signatures numériques), journalisation immuable.
• R — Repudiation (Répudiation) : un acteur nie avoir effectué une action. Contre-mesure : journalisation sécurisée, non-répudiation via signatures électroniques.
• I — Information Disclosure (Divulgation) : exposition de données confidentielles. Contre-mesure : chiffrement (TLS 1.3, AES-256), principe du moindre privilège.
• D — Denial of Service (Déni de service) : rendre le système indisponible. Contre-mesure : rate limiting, circuit breakers, auto-scaling, DDoS protection.
• E — Elevation of Privilege (Élévation de privilège) : obtenir des droits supérieurs non autorisés. Contre-mesure : RBAC strict, sandboxing, validation des entrées.

3. Les étapes d'un atelier de threat modeling

Étape 1 : Définir le périmètre

Délimiter le scope (une feature, un microservice, une API) et identifier les parties prenantes : architecte, développeur, responsable sécurité, product owner. Un atelier cible une seule feature pour rester actionnable (2 à 4 heures).

Étape 2 : Créer le Data Flow Diagram (DFD)

Le DFD représente visuellement les composants du système et leurs interactions :

• Entités externes (utilisateurs, systèmes tiers) — représentées par des rectangles.
• Processus (serveurs applicatifs, microservices) — représentés par des cercles.
• Flux de données — flèches avec direction et protocole (HTTPS, gRPC, SQL).
• Stockages (bases de données, S3, Redis) — représentés par des doubles barres.
• Frontières de confiance (Trust Boundaries) — zones délimitant les domaines de sécurité.

Étape 3 : Appliquer STRIDE sur chaque composant et flux

Pour chaque élément du DFD, poser systématiquement les 6 questions STRIDE. Une matrice composant × menace STRIDE permet de ne rien oublier. Chaque menace identifiée est documentée avec : description, impact, probabilité, contre-mesure proposée.

Étape 4 : Prioriser et planifier les contre-mesures

Utiliser le score DREAD ou une matrice risque (vraisemblance × impact) pour prioriser. Les remédiation sont intégrées dans le backlog produit avec une priorité définie. Les risques acceptés sont documentés et signés par le responsable produit ou RSSI.

Étape 5 : Valider et mettre à jour

Le threat model doit être revu à chaque changement architectural significatif. Intégrer un gate "Threat Model Review" dans le Definition of Done pour les nouvelles features.

4. Outils pour automatiser le threat modeling

• Microsoft Threat Modeling Tool : gratuit, basé sur STRIDE, génère automatiquement les menaces à partir des DFDs.
• OWASP Threat Dragon : open source, interface web, intégration Git pour versionner les modèles.
• IriusRisk : solution enterprise avec bibliothèques de menaces (cloud, API, IoT) et intégration JIRA.
• Tutamen Threat Modeler : automatisation des DFDs depuis le code source (analyse statique).
• Threagile : threat modeling as code (YAML), open source, génère des rapports PDF.

5. STRIDE vs PASTA vs LINDDUN

• STRIDE : idéal pour les équipes de développement — pratique, orienté technique.
• PASTA (Process for Attack Simulation and Threat Analysis) : 7 étapes orientées risque business, idéal pour les RSSI et architectes.
• LINDDUN : spécialisé dans la protection de la vie privée (RGPD) — Linkability, Identifiability, Non-repudiation, Detectability, Disclosure, Unawareness, Non-compliance.
• MITRE ATT&CK : complément au threat modeling pour aligner les menaces sur des TTPs réelles d'attaquants.

Conclusion

Le threat modeling n'est pas un audit ponctuel mais une pratique continueintégrée au cycle de développement. En appliquant STRIDE dès la phase de conception, les équipes détectent les failles architecturales avant qu'elles ne deviennent des vulnérabilités exploitables — réduisant à la fois le coût de correction et le risque d'incident en production. Pour les entités NIS2, c'est aussi un levier de conformité (art. 21 sur la sécurité de la chaîne d'approvisionnement et la sécurité dans le développement).