cyber / cybersecurite-fondamentale
Threat modeling avec la méthode STRIDE
Explication
Ce que vous allez apprendre
- Comprendre la différence entre corriger une vulnérabilité et anticiper une menace en amont
- Appliquer la grille STRIDE pour identifier systématiquement six catégories de menaces
- Construire un diagramme de flux de données et repérer les frontières de confiance
- Analyser chaque flux traversant une frontière de confiance sous les six angles STRIDE
- Maintenir un registre de menaces vivant, avec risque, mitigation, statut et responsable
Dans quel contexte ?
Une équipe s'apprête à concevoir un nouveau microservice de paiement qui communiquera avec un service d'authentification interne et une API tierce (Stripe). Avant d'écrire la moindre ligne de code, l'équipe sécurité organise une session de threat modeling pour identifier, à chaque frontière entre ces composants, ce qui pourrait mal tourner — plutôt que de découvrir ces failles lors d'un audit de sécurité une fois le service déjà en production.
Anticiper les menaces avant même d'écrire le code
Toutes les leçons précédentes traitaient des vulnérabilités APRÈS qu'elles existent déjà dans un système. Le threat modeling (modélisation des menaces) inverse la démarche : il se pratique idéalement AVANT ou pendant la conception d'un système, pour identifier les menaces possibles avant qu'elles ne deviennent des vulnérabilités réelles dans le code.
STRIDE, une grille de lecture mémorisable
STRIDE est un acronyme qui associe six catégories de menaces à six propriétés de sécurité violées : Spoofing (usurpation d'identité, viole l'authenticité), Tampering (falsification, viole l'intégrité), Repudiation (déni d'action, viole la non-répudiation/traçabilité), Information disclosure (fuite d'information, viole la confidentialité), Denial of service (déni de service, viole la disponibilité), Elevation of privilege (élévation de privilège, viole l'autorisation). L'intérêt de cette grille est qu'elle est systématique : elle force à se poser six questions précises plutôt que de "réfléchir aux menaces" de façon vague et incomplète.
| Lettre STRIDE | Menace | Propriété violée |
|---|---|---|
| S | Spoofing (usurpation) | Authentification |
| T | Tampering (falsification) | Intégrité |
| R | Repudiation (déni d'action) | Non-répudiation |
| I | Information disclosure (fuite) | Confidentialité |
| D | Denial of service (déni de service) | Disponibilité |
| E | Elevation of privilege (élévation) | Autorisation |
Pourquoi commencer par un diagramme de flux de données
On ne peut pas analyser des menaces dans l'abstrait : il faut d'abord dessiner comment les données circulent réellement dans le système (utilisateur → API → base de données → service externe, par exemple) et identifier les "frontières de confiance" — les points où les données passent d'une zone de confiance à une autre (par exemple, du navigateur non fiable de l'utilisateur vers le serveur). C'est précisément à ces frontières que les menaces STRIDE doivent être examinées une à une.
Prérequis
Un threat modeling efficace suppose de connaître déjà l'architecture réelle du système (composants, flux de données, dépendances externes). Sans diagramme de flux à jour, l'exercice devient une discussion abstraite plutôt qu'une analyse ciblée sur les frontières de confiance réelles.
Le threat modeling comme processus vivant, pas un document figé
Une erreur fréquente est de faire un threat modeling une seule fois, au début d'un projet, puis de l'oublier. Le résultat attendu est un registre de menaces VIVANT — mis à jour à chaque évolution significative de l'architecture — avec pour chaque menace un niveau de risque, une mitigation prévue, un statut et un responsable identifié. C'est cette maintenance continue qui distingue un vrai threat modeling d'un exercice ponctuel oublié après l'audit initial.
Commandes & code
Threat modeling avec la méthode STRIDE
STRIDE catégorise les menaces par violation d'une propriété de sécurité, ce qui rend la modélisation systématique plutôt qu'intuitive.
# STRIDE - une lettre = une propriété de sécurité violée
S - Spoofing (usurpation) -> viole l'Authentification
T - Tampering (altération) -> viole l'Intégrité
R - Repudiation (répudiation) -> viole la Non-répudiation (auditabilité)
I - Information Disclosure (fuite) -> viole la Confidentialité
D - Denial of Service (déni) -> viole la Disponibilité
E - Elevation of Privilege (élévation) -> viole l'Autorisation# Étape 1 : décomposer le système en diagramme de flux de données (DFD)
# Éléments à identifier : processus, flux de données, magasins de données, acteurs externes,
# et surtout les FRONTIÈRES DE CONFIANCE (trust boundaries) - c'est là que les menaces se concentrent
[Utilisateur] --HTTPS--> (Frontière: Internet/DMZ) --> [API Gateway] --> (Frontière: réseau interne) --> [Service Auth] --> [DB Users]
|
+--> [Service Paiement] --> [API externe Stripe]# Étape 2 : appliquer STRIDE à CHAQUE élément traversant une frontière de confiance
# Exemple sur "API Gateway -> Service Auth" (flux traversant la frontière Internet -> réseau interne)
S - Spoofing : un attaquant peut-il se faire passer pour l'API Gateway auprès du Service Auth ?
-> mitigation : mTLS entre gateway et service interne, pas de confiance implicite au réseau
T - Tampering : la requête peut-elle être modifiée en transit (montant, rôle demandé) ?
-> mitigation : TLS + validation stricte du schéma côté Service Auth
R - Repudiation : peut-on nier avoir effectué une action sensible (changement de rôle) ?
-> mitigation : logs d'audit horodatés et signés, incluant l'identité de l'appelant
I - Info Disclosure : les messages d'erreur révèlent-ils une info exploitable (stack trace, existence d'un compte) ?
-> mitigation : messages d'erreur génériques côté client, détails complets uniquement en log serveur
D - DoS : le Service Auth peut-il être saturé par un flot de requêtes de la gateway compromise ?
-> mitigation : rate-limiting, circuit breaker, quotas par client
E - Elevation : un utilisateur standard peut-il obtenir un token avec des scopes admin ?
-> mitigation : les scopes du token sont dérivés du rôle en base, jamais du payload de la requête# Formaliser le résultat : un registre de menaces exploitable par l'équipe (à tenir à jour, pas un document figé)
threat_register = [
{
"id": "T-001",
"element": "API Gateway -> Service Auth",
"category": "Spoofing",
"description": "Un service compromis sur le réseau interne pourrait usurper l'identité de la gateway",
"risk": "Élevé", # basé sur DREAD ou une matrice probabilité x impact
"mitigation": "mTLS avec rotation de certificats + allowlist réseau",
"status": "à implémenter",
"owner": "équipe plateforme",
},
{
"id": "T-002",
"element": "Service Paiement -> API Stripe",
"category": "Information Disclosure",
"description": "Les logs applicatifs pourraient contenir des numéros de carte en cas de mauvaise config",
"risk": "Critique",
"mitigation": "Filtrage systématique des champs PCI-DSS avant tout logging (middleware de sanitization)",
"status": "implémenté",
"owner": "équipe paiement",
},
]Résumé
- STRIDE mappe six catégories de menaces à six propriétés de sécurité violées : mémorisable et systématique.
- Le threat modeling démarre toujours par un diagramme de flux de données identifiant les frontières de confiance.
- Chaque flux traversant une frontière de confiance doit être analysé sous les six angles STRIDE.
- Le résultat doit être un registre de menaces vivant (risque, mitigation, statut, owner), pas un document ponctuel oublié après l'audit.
Exercices pratiques
Mission : le threat modeling du nouveau microservice de paiement
Objectif : Appliquer la grille STRIDE à un flux précis d'un diagramme d'architecture et produire une entrée de registre de menaces exploitable.
Contexte
Technologik conçoit un nouveau microservice de paiement. Le diagramme de flux de données est : [App mobile] --HTTPS--> (frontière Internet/DMZ) --> [API Gateway] --> (frontière réseau interne) --> [Service Paiement] --> [API externe Stripe]. Avant d'écrire la moindre ligne de code, l'équipe sécurité organise une session de threat modeling sur le flux Service Paiement -> API Stripe.