Atelier modélisation des menaces avec STRIDE : concevoir et animer un exercice en 3 heures
Pourquoi STRIDE plutôt qu'un autre cadre de threat modeling ?
La modélisation des menaces est l'une des compétences les plus précieuses en sécurité applicative — et l'une des moins enseignées en tant que telle. La plupart des cursus abordent la théorie des vecteurs d'attaque, mais peu d'entre eux proposent un exercice structuré où l'étudiant doit, lui-même, identifier systématiquement ce qui pourrait mal tourner dans un système donné.
Plusieurs cadres existent pour structurer cet exercice. Pourquoi choisir STRIDE en contexte de formation plutôt que PASTA, LINDDUN ou une autre approche ?
Comparaison des cadres de threat modeling en contexte pédagogique
PASTA (Process for Attack Simulation and Threat Analysis) est un cadre en sept étapes orienté risque métier. Il est puissant pour les environnements d'entreprise car il relie les menaces techniques aux objectifs business, mais il présuppose une maturité organisationnelle que les étudiants n'ont pas encore acquise. Son déroulé complet dépasse facilement deux jours de travail.
LINDDUN est spécialisé dans les menaces liées à la vie privée et au RGPD. Il est très pertinent pour les formations orientées conformité ou protection des données personnelles, mais sa portée thématique le rend moins adapté à un premier atelier généraliste de sécurité.
STRIDE, développé à l'origine par des ingénieurs de Microsoft, repose sur six catégories de menaces : Spoofing (usurpation d'identité), Tampering (altération), Repudiation (répudiation), Information Disclosure (divulgation d'information), Denial of Service (déni de service) et Elevation of Privilege (élévation de privilèges). Cet acronyme mnémotechnique est son premier avantage pédagogique : les étudiants peuvent le mémoriser en une session et l'appliquer sans aide-mémoire dès la deuxième heure.
L'avantage pédagogique de STRIDE
Ce qui fait de STRIDE un cadre idéal pour un premier atelier, c'est sa structure orthogonale. Chaque composant d'un système — processus, flux de données, entité externe, zone de confiance — se voit associer un sous-ensemble de catégories STRIDE applicables. Cette grille systématique empêche les étudiants de n'analyser que les menaces qu'ils connaissent déjà, et les force à parcourir l'espace des menaces de manière exhaustive.
Le cadre est également documenté de manière abondante, notamment par l'OWASP et Microsoft, ce que les étudiants apprécient pour approfondir par eux-mêmes après l'atelier. Pour un cours sécurité web ou un cours DevSecOps, STRIDE s'intègre naturellement comme la brique d'analyse préalable à l'écriture de user stories sécurisées ou à la définition de critères d'acceptation.
Prérequis et contexte pédagogique
Niveau minimal recommandé
Un atelier STRIDE bien cadré peut fonctionner dès la troisième année de cursus informatique, à condition que les étudiants aient déjà vu les notions suivantes : couches réseau (au moins OSI ou TCP/IP à un niveau conceptuel), mécanismes d'authentification et d'autorisation de base (session, JWT, OAuth), et notions élémentaires de chiffrement (symétrique, asymétrique, certificats). Sans ce socle, les étudiants peinent à identifier des menaces crédibles et les contre-mesures proposées restent superficielles.
Pour des formations plus courtes ou des publics non-informaticiens (profils juridiques ou managériaux en sensibilisation cyber), le formateur peut pré-remplir la colonne "Exemple de menace" du tableau STRIDE et demander uniquement aux participants d'identifier les contre-mesures. C'est une version allégée qui conserve la logique du cadre sans en exiger la maîtrise technique.
Matériel nécessaire
L'atelier peut se dérouler entièrement sur papier ou tableau blanc : c'est même recommandé pour une première session, car cela oblige les équipes à se consulter physiquement et à débattre de chaque menace plutôt que de travailler en silos sur leurs propres postes.
Pour une version numérique, OWASP Threat Dragon est l'outil open source de référence. Il s'utilise directement dans le navigateur sans installation, permet de dessiner un DFD interactif, d'associer des menaces STRIDE à chaque composant, et d'exporter le résultat en JSON pour la correction. Sa prise en main prend moins de quinze minutes pour un étudiant ayant déjà vu un DFD.
Taille de groupe optimale
Les équipes de 3 à 4 étudiants sont le format idéal. En dessous de 3, les angles morts sont trop fréquents — un seul regard ne suffit pas pour parcourir exhaustivement les six catégories sur chaque composant. Au-delà de 4, la dynamique de groupe dilue la participation : certains étudiants restent passifs pendant que d'autres monopolisent l'analyse.
Pour une promotion de 20 à 25 étudiants, on obtient 5 à 6 équipes, ce qui permet une consolidation inter-équipes productive lors de la troisième heure.
Construire le système à analyser
Choisir un cas fictif simple
Le choix du système à analyser conditionne largement la réussite de l'atelier. La règle principale : le système doit être fictif mais réaliste. Un système trop abstrait (« une API générique ») ne produit pas d'ancrage mental suffisant. Un système trop complexe (un ERP multi-tenant avec microservices) dépasse ce qu'une équipe peut modéliser en 90 minutes.
Trois exemples de cas bien calibrés pour un atelier de 3 heures :
- Application de vote en ligne : un utilisateur s'authentifie, soumet un vote, un backend l'enregistre en base de données, un administrateur consulte les résultats. Couverture complète des six catégories STRIDE avec une surface d'attaque lisible.
- Bibliothèque connectée : des lecteurs réservent des ouvrages via une appli mobile, un serveur synchronise les disponibilités, un système de carte RFID valide les emprunts. Cas utile pour aborder les menaces physiques et les flux IoT.
- API de commande e-commerce : un client passe commande, l'API transmet au système de paiement, le back-office met à jour le stock. Cas classique, bien documenté dans la littérature OWASP.
Dessiner le Data Flow Diagram (DFD)
Le DFD est le point de départ de toute analyse STRIDE. Il représente le système sous forme de cinq éléments :
- Les entités externes (rectangles) : acteurs humains ou systèmes tiers qui interagissent avec le système sans en faire partie (navigateur utilisateur, service de paiement externe).
- Les processus (cercles ou ovales) : traitements logiciels qui transforment ou transmettent des données (serveur applicatif, service d'authentification).
- Les flux de données (flèches) : transferts d'information entre composants (requête HTTP, réponse JSON, appel API).
- Les entités de stockage (rectangles à double trait) : bases de données, fichiers, journaux.
- Les limites de confiance (lignes pointillées) : frontières entre zones de confiance différentes (Internet vs réseau interne, frontend vs backend).
Chaque franchissement de limite de confiance est un point d'attention particulier pour l'analyse STRIDE.
Exemple de DFD pour l'application de vote fictive
Pour l'application de vote, le DFD se compose des éléments suivants. L'entité externe Électeur envoie une requête de vote via HTTPS vers le processus Serveur web applicatif, qui se trouve dans la zone de confiance "DMZ". Ce serveur communique avec le processus Service d'authentification (zone réseau interne) pour vérifier l'identité. Une fois l'authentification validée, le serveur applicatif écrit dans l'entité de stockage Base de données des votes (zone réseau interne). Un second acteur, l'entité externe Administrateur, accède à un processus Interface d'administration pour consulter les résultats agrégés lus depuis la même base de données. La limite de confiance sépare Internet (Électeur, Administrateur) de la DMZ (Serveur web) et de la zone interne (Service d'authentification + Base de données).
Ce DFD simple suffit à générer plus de quinze menaces STRIDE distinctes, ce qui est amplement suffisant pour 90 minutes de travail en équipe.
Déroulé de l'atelier heure par heure
H0 – H0:30 : Introduction STRIDE et présentation du système
Les 30 premières minutes sont entièrement magistrales. Le formateur présente les six catégories STRIDE avec un exemple concret pour chacune, issu du quotidien des étudiants (le Spoofing illustré par l'usurpation d'un compte mail, le DoS par une attaque sur un service d'inscription universitaire). Il distribue ensuite le DFD du système fictif — ou, selon le niveau du groupe, le fait construire collectivement au tableau en 20 minutes.
Il est essentiel de terminer cette phase avec un DFD validé par tout le groupe. Si les équipes partent sur des DFD divergents, la consolidation inter-équipes de la troisième heure devient impossible.
H0:30 – H2:00 : Travail en équipe
C'est le cœur de l'atelier. Chaque équipe reçoit un tableau vierge à compléter (voir section suivante) et parcourt le DFD composant par composant. La consigne est de s'interroger, pour chaque composant, sur chacune des six catégories STRIDE.
Le formateur circule entre les équipes et intervient en cas de blocage. Les erreurs fréquentes à cette phase : confondre une vulnérabilité avec une menace (une menace est un scénario d'attaque, pas une faiblesse de configuration), se limiter aux menaces déjà connues sans parcourir systématiquement les six catégories, ou négliger les flux de données au profit des seuls processus.
Une règle de facilitation utile : interdire d'écrire une contre-mesure avant que la menace soit complètement formulée. Cette contrainte force les étudiants à décrire précisément le scénario d'attaque avant de chercher la parade, ce qui produit une analyse beaucoup plus rigoureuse.
H2:00 – H2:30 : Consolidation inter-équipes et priorisation
Chaque équipe présente en 5 à 7 minutes les menaces qu'elle a identifiées. Le groupe entier réagit : certaines menaces seront dupliquées entre équipes (signe qu'elles sont critiques), d'autres n'apparaîtront que dans une seule équipe (opportunité de discussion sur pourquoi les autres ne les ont pas vues).
La consolidation aboutit à une liste commune de menaces, que le formateur fait prioriser collectivement selon deux axes : probabilité perçue et impact potentiel. Cette priorisation n'a pas besoin d'être quantitative — un tri en trois niveaux (critique, modéré, faible) suffit pour ancrer la notion de gestion du risque.
H2:30 – H3:00 : Débrief collectif et contre-mesures
La dernière demi-heure est dédiée aux enseignements. Le formateur revient sur les menaces critiques identifiées et présente les contre-mesures standards associées : chiffrement des flux pour l'Information Disclosure, journalisation signée pour la Repudiation, contrôles d'accès stricts pour l'Elevation of Privilege.
Il souligne également les erreurs typiques observées pendant l'exercice : DFD incomplet (frontières de confiance absentes), menaces formulées à un niveau trop abstrait pour produire des contre-mesures actionnables, ou contre-mesures proposées qui ne répondent pas à la catégorie STRIDE identifiée.
Tableau STRIDE par composant
Voici un exemple de tableau à compléter pour l'application de vote fictive. C'est le document central de l'atelier : chaque équipe en remplit un par composant du DFD.
| Composant | Catégorie STRIDE | Exemple de menace | Contre-mesure suggérée |
|---|---|---|---|
| Flux HTTPS (Électeur → Serveur web) | Information Disclosure | Interception du vote en transit si TLS mal configuré | Forcer TLS 1.2 minimum, désactiver les suites faibles, activer HSTS |
| Service d'authentification | Spoofing | Usurpation d'identité d'un électeur par rejeu d'un token expiré | Vérification de l'expiration côté serveur, rotation des tokens, invalidation après usage |
| Base de données des votes | Tampering | Modification directe d'enregistrements de votes par un administrateur sans traçabilité | Journalisation immuable (append-only), séparation des droits lecture / écriture |
| Interface d'administration | Elevation of Privilege | Un électeur accède à l'interface admin par escalade de privilèges via faille d'autorisation | Contrôle d'accès basé sur les rôles (RBAC), vérification côté serveur de chaque action admin |
| Serveur web applicatif | Denial of Service | Saturation du serveur par envoi massif de requêtes de vote simultanées | Rate limiting par IP et par compte, limitation du nombre de votes par électeur, CAPTCHA |
Ce tableau est délibérément simplifié pour illustrer la méthode. Dans un atelier complet, chaque composant génère plusieurs menaces par catégorie, et certaines catégories STRIDE ne s'appliquent pas à tous les composants (la Repudiation, par exemple, est plus pertinente sur les processus que sur les flux de données).
Variantes selon le niveau
L3 / BUT : version guidée avec DFD fourni
Pour des étudiants de licence, le formateur fournit le DFD pré-dessiné et limite l'analyse à 2 ou 3 composants identifiés en avance comme les plus critiques. L'objectif de niveau est d'identifier au moins une menace par catégorie STRIDE applicable et de proposer une contre-mesure crédible pour chacune. L'évaluation porte sur la compréhension du raisonnement, pas sur l'exhaustivité.
M1 : version semi-autonome
Les étudiants de master 1 construisent le DFD en autonomie à partir d'une description textuelle du système fournie par le formateur. Ils sont responsables de l'analyse complète de tous les composants et doivent proposer des contre-mesures avec une justification technique. Cette version introduit naturellement les notions de architecte sécurité : quelle décision de design réduit la surface d'attaque en amont ?
M2 / Expert : version supply chain et dépendances tierces
Pour les niveaux avancés, le système fictif inclut des dépendances de bibliothèques open source (un framework web, une librairie de chiffrement) et des intégrations avec des services SaaS tiers (provider d'authentification, API de paiement). Les étudiants doivent modéliser les menaces liées à la chaîne d'approvisionnement logicielle : compromission d'une dépendance, exfiltration via un service tiers, ou délégation de confiance excessive à un fournisseur externe. Ce niveau fait le lien avec les certifications professionnelles comme le CISSP, qui aborde la sécurité de la supply chain dans son domaine dédié.
Grille d'évaluation formative
L'évaluation d'un atelier STRIDE sans QCM repose sur une rubric à trois niveaux. Elle est communiquée aux étudiants en début d'atelier pour qu'ils sachent ce qui est attendu.
| Critère | Insuffisant | Satisfaisant | Excellent |
|---|---|---|---|
| Exhaustivité des menaces identifiées | Moins de la moitié des composants analysés, catégories STRIDE manquantes | Tous les composants couverts, au moins 4 catégories STRIDE sur 6 appliquées | Tous les composants couverts, les 6 catégories STRIDE appliquées avec pertinence, y compris les interactions entre composants |
| Pertinence des menaces formulées | Menaces trop abstraites ("une attaque possible") ou confondues avec des vulnérabilités | Menaces formulées sous forme de scénarios compréhensibles par un tiers | Menaces formulées avec le contexte du système fictif, le vecteur d'attaque et la condition d'exploitation précisés |
| Qualité des contre-mesures proposées | Contre-mesures génériques non liées à la menace identifiée | Contre-mesures techniquement correctes et alignées avec la catégorie STRIDE | Contre-mesures hiérarchisées avec justification du choix, incluant des alternatives et leurs compromis |
| Lisibilité et complétude du DFD | DFD incomplet (entités ou flux manquants), limites de confiance absentes | DFD complet avec les 5 types d'éléments présents | DFD complet, limites de confiance explicites, annotations sur les éléments critiques |
Pour les groupes qui présentent à l'oral, un passage de 10 minutes par équipe permet de vérifier que chaque membre peut expliquer individuellement une menace identifiée et sa contre-mesure. Cette vérification orale distingue les équipes qui ont vraiment raisonné collectivement de celles où un ou deux étudiants ont porté l'analyse seuls.
Outils recommandés
OWASP Threat Dragon
C'est l'outil open source de référence pour la modélisation des menaces. Il fonctionne directement dans le navigateur (application web hébergeable localement ou en SaaS), permet de dessiner un DFD interactif, d'associer des menaces STRIDE à chaque composant, et d'exporter le résultat en JSON. Pour les établissements préoccupés par la confidentialité des données, Threat Dragon peut être déployé en local en quelques minutes avec Docker.
Microsoft Threat Modeling Tool
Disponible uniquement sur Windows, cet outil génère automatiquement des suggestions de menaces STRIDE à partir d'un DFD. L'onglet "View Reports" produit un rapport structuré exportable. Son principal intérêt pédagogique est de montrer aux étudiants la logique des règles de génération automatique — et leurs limites : les suggestions automatiques ne remplacent pas le raisonnement humain et produisent régulièrement des faux positifs ou des omissions.
Draw.io pour les DFD
Pour les établissements qui préfèrent un outil généraliste de dessin numérique, Draw.io (également disponible sous le nom diagrams.net) dispose de bibliothèques de formes adaptées aux DFD et s'intègre avec Google Drive ou les outils de l'établissement. Il est moins spécialisé que Threat Dragon mais plus accessible à des étudiants qui n'ont jamais fait de modélisation de menaces.
Un rappel important sur ces outils
Ces outils sont des aides à la structuration, pas des oracles. Aucun d'entre eux ne génère automatiquement une analyse complète et fiable. Ils aident à ne rien oublier, à documenter le travail, et à collaborer. La valeur de l'atelier réside dans le raisonnement collectif, pas dans la liste de menaces que l'outil propose. Insistez sur ce point avec vos étudiants : un outil qui "trouve" les menaces à leur place ne leur apprend pas à penser comme un attaquant.
Ce qu'il faut retenir
La modélisation des menaces avec STRIDE est l'un des rares exercices pédagogiques qui force les étudiants à raisonner de manière systématique sur la sécurité d'un système complet — pas composant par composant, pas attaque par attaque, mais en parcourant méthodiquement un espace de menaces structuré.
Voici les quatre points essentiels à emporter de cet article :
- STRIDE est le cadre d'entrée le plus adapté pour un premier atelier de modélisation des menaces : son acronyme mnémotechnique, sa documentation abondante et sa structure orthogonale en font un outil pédagogique immédiatement opérationnel.
- Le DFD est le fondement de l'exercice : un DFD incomplet ou mal délimité produit une analyse lacunaire. Investir du temps sur sa construction collective est toujours rentable.
- Le format 3 heures est optimisé pour ancrer les apprentissages : le survol en 90 minutes laisse des traces, mais ne produit pas la même maîtrise qu'un exercice complet avec consolidation et débrief.
- L'évaluation formative par rubric est plus pertinente qu'un QCM pour mesurer la compétence de modélisation : elle distingue la compréhension superficielle de la capacité à raisonner sur un système réel.
- Les outils comme OWASP Threat Dragon facilitent la documentation et la collaboration, mais ne remplacent pas le jugement humain — il est essentiel de le rappeler explicitement aux étudiants.
Pour intégrer ce type d'atelier dans votre programme avec un intervenant spécialisé en modélisation des menaces et sécurité applicative, découvrez les profils disponibles sur Cyber Teachers.