Threat Modeling (STRIDE/PASTA)

Définition

Le threat modeling (modélisation des menaces) est une démarche structurée qui consiste à identifier, documenter et hiérarchiser les menaces pesant sur un système dès sa phase de conception, avant qu'une seule ligne de code ne soit écrite. Là où un test d'intrusion constate des vulnérabilités sur un système déjà construit, la modélisation des menaces raisonne sur l'architecture : quels sont les actifs à protéger, qui pourrait vouloir les atteindre, par quels chemins, et que se passe-t-il si les contrôles échouent ?

Cette pratique repose sur des cadres formalisés — STRIDE, PASTA, LINDDUN, DREAD ou OCTAVE — qui évitent l'écueil du brainstorming non structuré, où l'équipe ne trouve que les menaces qu'elle connaît déjà. L'objectif final est la réduction de la surface d'attaque architecturale : corriger un défaut de conception coûte 30 à 100 fois moins cher en phase de design qu'en production.

Fonctionnement technique

La démarche se déroule classiquement en quatre temps, popularisés par Adam Shostack :

• Que construit-on ? Production d'un Data Flow Diagram (DFD) recensant les processus, les magasins de données, les entités externes, les flux et surtout les frontières de confiance (trust boundaries) — points où un flux change de niveau de privilège ou de zone réseau.
• Qu'est-ce qui peut mal tourner ? Application systématique d'un framework à chaque élément du diagramme.
• Que fait-on ? Décision par menace : atténuer, transférer, accepter ou éliminer la fonctionnalité.
• A-t-on bien travaillé ? Vérification que chaque contre-mesure est effectivement implémentée et testée.

STRIDE

Créé chez Microsoft en 1999, STRIDE est un acronyme mnémotechnique associant six catégories de menaces à six propriétés de sécurité violées :

• Spoofing (usurpation d'identité) → viole l'authentification
• Tampering (altération de données) → viole l'intégrité
• Repudiation (répudiation) → viole la non-répudiation
• Information disclosure (fuite d'information) → viole la confidentialité
• Denial of service → viole la disponibilité
• Elevation of privilege → viole l'autorisation

L'analyste parcourt chaque élément du DFD et se demande mécaniquement : « ce flux peut-il être usurpé ? altéré ? intercepté ? ». La variante STRIDE-per-interaction applique la grille non aux composants mais aux interactions, ce qui produit moins de faux positifs.

PASTA

PASTA (Process for Attack Simulation and Threat Analysis) est un processus en sept étapes, orienté risque métier plutôt que technique. Il part des objectifs business, définit le périmètre technique, décompose l'application, analyse les menaces à partir de la threat intelligence réelle, identifie les vulnérabilités, modélise des scénarios d'attaque, puis quantifie l'impact business. Plus lourd que STRIDE, il est adapté aux systèmes critiques (banque, santé, OIV) où la justification budgétaire des contrôles est exigée.

LINDDUN

LINDDUN transpose la logique aux menaces sur la vie privée : Linkability, Identifiability, Non-repudiation, Detectability, Disclosure of information, Unawareness, Non-compliance. C'est l'outil de référence pour instruire une AIPD/DPIA au sens du RGPD (article 35) et matérialiser le privacy by design.

Exemples concrets

API de paiement. Le DFD montre un flux « application mobile → API REST » franchissant une frontière de confiance. STRIDE produit : Spoofing — un attaquant rejoue un jeton JWT volé → contre-mesure : jetons courts + refresh token lié à l'empreinte de l'appareil. Tampering — modification du montant en transit → TLS 1.3 obligatoire + signature HMAC du corps de requête. Repudiation — le client nie la transaction → journalisation immuable horodatée et signée.

Cluster Kubernetes. Elevation of privilege : un pod compromis monte le socket /var/run/docker.sock et prend le contrôle du nœud → contre-mesures : Pod Security Standards en mode restricted, runAsNonRoot, désactivation de l'automount du token de ServiceAccount.

Portail RH. LINDDUN révèle un défaut de Linkability : les identifiants de session en clair dans l'URL permettent de corréler la navigation d'un salarié entre deux services distincts.

Liens avec les autres concepts

Le threat modeling est le pivot du Secure SDLC et de l'approche shift-left du DevSecOps. Il alimente naturellement le test d'intrusion (les scénarios modélisés deviennent des cas de test), le red teaming et le SOC, dont les règles de détection peuvent être dérivées des chemins d'attaque identifiés. Il s'articule avec MITRE ATT&CK — utilisé comme catalogue de techniques réalistes en phase d'analyse de menace de PASTA — et avec l'OWASP Top 10, qui fournit un vocabulaire de vulnérabilités applicatives. Sur le plan normatif, la démarche répond directement à l'ISO 27001 A.8.25 (cycle de vie de développement sécurisé), à l'ISO 21434 dans l'automobile, à la directive NIS 2 (article 21, sécurité de la chaîne d'approvisionnement) et au Cyber Resilience Act. Le modèle Zero Trust se nourrit des frontières de confiance cartographiées lors de l'exercice.

Bonnes pratiques

• Modéliser tôt et souvent : rattacher l'exercice au design d'une epic, pas à un audit annuel. Un modèle vieux de deux ans décrit un système qui n'existe plus.
• Impliquer les développeurs, pas seulement l'équipe sécurité : ce sont eux qui connaissent les raccourcis d'implémentation.
• Limiter le périmètre : une session de 60 à 90 minutes sur un composant précis est plus productive qu'une modélisation exhaustive du SI.
• Tracer chaque menace comme un ticket dans le backlog, avec un propriétaire et un statut — sinon le rapport reste lettre morte.
• Prioriser par risque (probabilité × impact) plutôt que par exhaustivité ; DREAD ou une matrice CVSS-like suffisent.
• Automatiser ce qui peut l'être : le threat modeling as code (pytm, threagile, OWASP Threat Dragon, Microsoft Threat Modeling Tool) versionne le modèle avec le code et le rejoue en CI.
• Documenter les risques acceptés et les hypothèses de sécurité : elles deviennent des exigences pour les équipes en aval.