Repérer avant de cambrioler
Reprenons Les Arcades, le centre commercial qui sert de fil rouge à cette série. Avant un casse, personne n'arrive en force le jour J sans préparation. On commence par traîner dans les galeries, l'air de rien. On note où sont les caméras, à quelle heure tourne la ronde des vigiles, par quelle porte arrivent les livreurs, où mène le couloir « réservé au personnel ».
Ce repérage s'appuie sur un document qui existe déjà : le plan du centre affiché à chaque entrée, avec sa signalétique. Sorties, escalators, boutiques, zones réservées, issues de secours. Ce plan a été dessiné pour aider le client. Il aide aussi l'attaquant.
L'idée du threat modeling tient là-dedans. Prends le plan de ton système, regarde-le avec les yeux de quelqu'un qui veut lui nuire, et liste tout ce qui peut mal tourner, avant d'ouvrir le centre au public.
Le threat modeling, c'est dessiner le plan de son système puis le relire comme un cambrioleur relit le plan du centre commercial : non pas « par où je passe » mais « par où je rentre ».
Le réflexe habituel est inverse. On construit d'abord, on sécurise après, souvent après le premier incident. Modéliser les menaces déplace l'effort en amont, à la conception, là où une parade coûte une ligne de schéma plutôt qu'un correctif en urgence.
Les quatre questions de Shostack
Avant tout vocabulaire, le threat modeling se résume à une démarche. Adam Shostack, qui a porté la pratique chez Microsoft et signé le livre de référence Threat Modeling: Designing for Security, la condense en quatre questions. Elles structurent le Threat Modeling Manifesto et la fiche OWASP consacrée au sujet.
- Que construit-on ? On dessine le système : ses composants, ses flux, ses frontières.
- Qu'est-ce qui peut mal tourner ? On cherche les menaces contre ce dessin.
- Qu'est-ce qu'on fait ? On décide des parades pour chaque menace retenue.
- A-t-on bien travaillé ? On relit, on vérifie que les parades tiennent et que rien n'a été oublié.
Pour Les Arcades, ça donne : le plan du centre (question 1), le repérage du cambrioleur (question 2), les rideaux de fer et les rondes (question 3), la commission de sécurité qui repasse derrière (question 4).
La quatrième question est la plus négligée. Un modèle de menaces n'est pas un livrable qu'on archive : c'est un document vivant qu'on relit à chaque évolution du système. Une nouvelle porte dans le centre, et tout le repérage est à refaire.
STRIDE est l'outil de la deuxième question. Il ne dit pas comment dessiner le système ni quelles parades choisir : il donne une grille pour ne rien oublier quand on cherche ce qui peut mal tourner.
STRIDE : six familles de menaces
STRIDE est un acronyme inventé chez Microsoft en 1999 par Loren Kohnfelder et Praerit Garg. Chaque lettre nomme une famille de menaces, et surtout, chaque famille correspond à la violation d'une propriété de sécurité. C'est ce qui rend la grille utile : derrière chaque menace, il y a une garantie qu'on cherchait à offrir et qui tombe.
Cette correspondance prolonge directement la triade DICP du premier billet de la série. Là où DICP dit ce qu'on protège, STRIDE dit comment on l'attaque. Chaque lettre vise une propriété.
| Lettre | Menace | Propriété violée | Aux Arcades |
|---|---|---|---|
| S | Spoofing (usurpation) | Authentification | Un faux livreur se fait passer pour le transporteur habituel |
| T | Tampering (altération) | Intégrité (le I de DICP) | On rééditionne les étiquettes de prix en rayon |
| R | Repudiation (répudiation) | Non-répudiation, preuve (le P de DICP) | Un employé nie avoir ouvert la réserve, faute de registre |
| I | Information disclosure (divulgation) | Confidentialité (le C de DICP) | Le fichier clients fuite hors du bureau de la direction |
| D | Denial of service (déni de service) | Disponibilité (le D de DICP) | On bloque les entrées et les issues, plus personne ne circule |
| E | Elevation of privilege (élévation) | Autorisation | Un agent met la main sur le passe maître et ouvre tout |
Trois lettres tapent pile sur la triade DICP (tampering sur l'intégrité, disclosure sur la confidentialité, DoS sur la disponibilité). Repudiation vise le quatrième pilier français, la preuve. Spoofing et elevation of privilege couvrent les deux faces du contrôle d'accès : prouver qui on est, puis ne faire que ce qu'on a le droit de faire.
Retiens la logique, pas l'acronyme : à chaque menace correspond une promesse de sécurité qui se brise. Si tu sais quelle propriété tu garantis, tu sais déjà quelle famille STRIDE la menace.
Spoofing : se faire passer pour un autre
Aux Arcades, c'est le faux livreur en gilet jaune qui pousse un diable vide jusqu'à la réserve. Il n'a pas forcé la porte, il a usurpé une identité de confiance.
En informatique, le spoofing recouvre les identifiants volés, le phishing qui les récolte, l'usurpation d'adresse e-mail ou d'adresse IP. C'est le vecteur d'entrée le plus banal. Le rapport Verizon DBIR 2024 attribue une part majeure des intrusions à l'usage d'identifiants légitimes volés plutôt qu'à une faille technique. La propriété visée est l'authentification. La parade tient en un mot, prouver l'identité : MFA, certificats, signatures.
Tampering : modifier ce qui ne doit pas l'être
Au centre, c'est rééditer les étiquettes pour payer un article à un prix qu'on a choisi. La marchandise n'est pas volée, sa donnée de prix est falsifiée.
Côté système, le tampering vise l'intégrité des données ou du code : modifier une requête en transit, altérer un fichier, injecter du code dans une dépendance. L'attaque de la chaîne d'approvisionnement SolarWinds, où un code malveillant a été glissé dans des mises à jour signées du logiciel Orion, en est le cas d'école. La parade : hachage, signatures, contrôle d'intégrité, et défiance envers les entrées non vérifiées.
Repudiation : nier sans qu'on puisse prouver le contraire
Un agent ouvre la réserve, sert un complice, et jure plus tard n'avoir rien fait. S'il n'existe aucun registre d'accès ni image exploitable, sa parole vaut la tienne.
En informatique, la répudiation prospère partout où les journaux manquent, sont incomplets ou modifiables. Sans piste d'audit fiable, impossible d'établir qui a fait quoi. La parade est la non-répudiation, le P de DICP : journaux horodatés, signés, conservés hors de portée de celui qui agit.
Information disclosure : laisser fuir ce qui est confidentiel
C'est le fichier clients qui sort du bureau de la direction et se retrouve dans la nature. La donnée n'a pas été détruite, juste exposée à qui ne devait pas la voir.
Les fuites de données sont la matérialisation la plus connue de cette famille. La base Have I Been Pwned, tenue par Troy Hunt, recense des milliards de comptes exposés au fil d'incidents publics et vérifiables. La propriété visée est la confidentialité. La parade : chiffrement au repos et en transit, cloisonnement, moindre privilège sur l'accès aux données.
Denial of service : bloquer l'accès
Aux Arcades, on barre les entrées et les issues. Le centre est intact, mais plus personne n'y entre ni n'achète. Le préjudice est l'indisponibilité.
L'équivalent réseau est le déni de service distribué. En octobre 2016, l'attaque contre le fournisseur DNS Dyn, menée par le botnet Mirai composé d'objets connectés compromis, a rendu inaccessibles de nombreux services en ligne sans toucher à leurs serveurs eux-mêmes. La propriété visée est la disponibilité. La parade : redondance, limitation de débit, filtrage anti-DDoS, dimensionnement.
Elevation of privilege : franchir un palier d'autorisation
Le scénario qui fait le plus peur à la direction : un employé met la main sur le passe maître. Il était entré légitimement, badge en poche, mais il accède maintenant à tout, des coffres aux locaux techniques.
L'élévation de privilège est l'aboutissement de beaucoup d'attaques : un accès limité qui devient administrateur. Elle s'appuie souvent sur une vulnérabilité documentée. PrintNightmare, la faille du spouleur d'impression de Windows référencée CVE-2021-34527, permettait justement à un utilisateur ordinaire d'exécuter du code avec les privilèges système. La propriété visée est l'autorisation. La parade : moindre privilège, cloisonnement, correctifs à jour.
Appliquer STRIDE à un système concret
La grille ne sert à rien dans le vide. Elle s'applique à un dessin. Prenons un système que tout le monde connaît : le formulaire de connexion d'une application web. Un internaute saisit identifiant et mot de passe, l'application vérifie, puis ouvre une session.
Étape 1 : dessiner le flux de données
La première question de Shostack appelle un diagramme de flux de données (DFD). On y représente les acteurs, les traitements, les stockages, et surtout les frontières de confiance, ces lignes que les données franchissent en changeant de niveau de confiance. C'est le plan du centre, version système.
La frontière qui compte ici est celle entre le navigateur, hors de tout contrôle, et le service d'authentification. Tout ce qui la traverse mérite la méfiance.
Étape 2 : passer STRIDE sur chaque élément
La deuxième question consiste à appliquer les six lettres, élément par élément et flux par flux. On ne se demande pas « ce composant est-il vulnérable » mais « parmi S, T, R, I, D, E, lesquelles s'appliquent ici ». La grille force l'exhaustivité.
| Lettre | Menace sur le formulaire de connexion | Parade |
|---|---|---|
| S | Attaque par force brute ou identifiants volés pour usurper un compte | MFA, limitation des tentatives, détection des connexions anormales |
| T | Manipulation du jeton de session pour changer d'identité | Jeton signé, contrôle d'intégrité côté serveur |
| R | Connexion contestée sans trace exploitable | Journalisation horodatée des tentatives, réussites et échecs |
| I | Vol de la base d'empreintes, ou mots de passe en clair en cas de fuite | Empreintes avec algorithme adapté et sel, chiffrement TLS du flux |
| D | Saturation du service par un flot de requêtes de connexion | Limitation de débit, filtrage, dimensionnement |
| E | Faille du service permettant de passer compte standard à administrateur | Moindre privilège, séparation des rôles, correctifs |
Le tableau n'est pas exhaustif, et c'est le but. Il montre la mécanique : un flux, six angles d'attaque, une parade par menace retenue. Sur un vrai système, on répète l'exercice pour chaque flux et chaque stockage du diagramme.
Étape 3 : décider, puis vérifier
La troisième question, agir, ne signifie pas tout corriger. Comme le risque du premier billet (vraisemblance multipliée par gravité), chaque menace se hiérarchise. Certaines justifient une parade immédiate, d'autres un risque assumé, d'autres un report. Le modèle aide à décider en connaissance de cause, pas à promettre l'invulnérabilité.
La quatrième question clôt la boucle. On relit le modèle, on confronte les parades à la réalité du code, et on recommence à la prochaine évolution. Un champ ajouté au formulaire, une nouvelle dépendance, et le repérage est à refaire.
STRIDE ne sécurise pas un système. Il garantit qu'on a regardé chaque composant sous six angles avant de décider quoi protéger. Le reste est une affaire de priorités.
Points clés
- Le threat modeling répond aux quatre questions de Shostack : que construit-on, qu'est-ce qui peut mal tourner, qu'est-ce qu'on fait, a-t-on bien travaillé.
- STRIDE outille la deuxième question avec six familles de menaces : spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege.
- Chaque lettre attaque une propriété de sécurité, en prolongement direct de la triade DICP : tampering vise l'intégrité, disclosure la confidentialité, DoS la disponibilité, repudiation la preuve, spoofing et EoP le contrôle d'accès.
- L'exercice s'applique à un diagramme de flux de données : on passe les six lettres sur chaque composant et chaque frontière de confiance, puis on décide des parades par priorité.
- Un modèle de menaces est vivant : il se relit à chaque évolution du système, sinon le repérage devient obsolète.
Dans la série
Palier 1 : Connaître les lieux. Domaine : Menaces.
- Précédent : CVE, CVSS et zero-day
- Suivant : Le modèle OSI côté sécurité
- Vue d'ensemble : Par où commencer dans Les Arcades
Pour aller plus loin
- OWASP Threat Modeling : la fiche de référence, processus et ressources.
- Threat Modeling Manifesto : les valeurs et principes derrière la pratique, coécrit par Adam Shostack.
- OWASP Threat Dragon : outil libre pour dessiner des DFD et dérouler STRIDE.
- Verizon DBIR : le rapport annuel sur les schémas d'attaque réels, utile pour pondérer les menaces.
- Pour relier cette démarche au cycle de développement, voir Qu'est-ce que le DevSecOps ?.
