Une équipe de développement peut réaliser le threat modeling d'une fonctionnalité en une heure, à condition de répondre à quatre questions dans l'ordre et de repartir avec des tickets plutôt qu'avec un document. Ces questions viennent du Threat Modeling Manifesto : sur quoi travaillons-nous, qu'est-ce qui peut mal tourner, que allons-nous faire à ce sujet, et avons-nous fait du assez bon travail. Nul besoin d'un architecte sécurité, car la démarche ne repose pas sur le talent inné d'une seule personne.
L'heure en un coup d'œil
| Minutes | Question | Résultat |
|---|---|---|
| Avant | - | Une personne rédige le schéma de flux de données |
| 0-10 | Sur quoi travaillons-nous | Schéma corrigé, points d'entrée numérotés |
| 10-30 | Qu'est-ce qui peut mal tourner | Liste des menaces, regroupées par catégorie STRIDE |
| 30-45 | Que allons-nous faire à ce sujet | Une réponse pour chaque menace |
| 45-55 | Tickets et tests | Un ticket et un test par mesure d'atténuation |
| 55-60 | Avons-nous fait du assez bon travail | Contrôle d'exhaustivité |
Avant la session
Choisissez une seule fonctionnalité, pas un produit entier. Repérer les problèmes au moment de la conception est bien plus efficace que corriger des failles en production : tenez donc la session avant le début du développement.
Invitez un développeur, le responsable des exigences et, si l'infrastructure est concernée, une personne de l'exploitation. L'un d'eux apporte une première version du schéma de flux de données, réalisée avec un outil dont l'équipe pourra modifier les fichiers par la suite.
Minutes 0-10 : sur quoi travaillons-nous
Le groupe corrige le brouillon. L'OWASP Threat Modeling Cheat Sheet demande une vision claire des frontières de confiance, des flux de données, des magasins de données, des processus et des entités externes, qui représentent souvent des points d'attaque potentiels. Vérifiez que chacun figure bien sur le schéma.
Si certains participants ne sont pas techniques, faites un brainstorming des flux sur un tableau blanc plutôt que d'imposer la notation DFD.
Numérotez les points d'entrée au fil de l'eau, en utilisant la notation majeur.mineur pour les points imbriqués (1, 1.2, 1.2.1), comme le fait la page du processus communautaire OWASP, et repérez aussi les points de sortie. Un message d'erreur sur une page de connexion peut permettre des attaques via le point d'entrée correspondant, comme l'énumération de comptes (« nom d'utilisateur introuvable ») ou l'injection SQL (via les erreurs d'exception SQL).
Minutes 10-30 : qu'est-ce qui peut mal tourner
Commencez par STRIDE pour une conception technique. Passez chaque composant, chaque flux de données et chaque frontière de confiance au crible des six catégories, et notez pour chaque menace l'identifiant du point d'entrée concerné.
| Catégorie | Propriété violée | Exemple |
|---|---|---|
| Spoofing | Authentification | Jeton d'authentification volé et utilisé pour usurper un utilisateur |
| Tampering | Intégrité | Modifications involontaires de la base de données via l'application |
| Repudiation | Imputabilité | Journaux manipulés pour dissimuler des actions |
| Information Disclosure | Confidentialité | Données extraites d'une base de comptes utilisateurs |
| Denial of Service | Disponibilité | Utilisateur verrouillé à la suite de nombreuses tentatives d'authentification échouées |
| Elevation of Privileges | Autorisation | Un JWT falsifié pour changer le rôle |
Pour une règle métier, ajoutez des misuse cases : actions réalisées dans le désordre, de façon répétée, en parallèle ou pour obtenir un résultat non prévu. Pour un objectif d'attaque en plusieurs étapes, utilisez un arbre d'attaque. N'ajoutez pas de techniques pour faire sérieux : expliquez pourquoi chacune convient et ce qu'elle laisse de côté.
Probabilité multipliée par impact paraît rigoureux, mais les deux sont difficiles à estimer et le produit ignore le coût de la correction. En une heure, une estimation approximative élevée, moyenne ou faible par menace suffit.
Un exemple concret : la réinitialisation de mot de passe
Prenons une réinitialisation de mot de passe. Le schéma montre le navigateur, l'application web, la base d'utilisateurs et un service de messagerie, avec une frontière de confiance entre Internet et l'application. La demande de réinitialisation est le point d'entrée 3 et le lien envoyé par e-mail est le 3.1 (identifiants donnés à titre d'illustration).
Le groupe identifie quatre menaces. Un lien de réinitialisation fonctionne pour une autre personne que le titulaire (spoofing). Un message « aucun compte associé à cette adresse » révèle qui est inscrit (information disclosure). Les réinitialisations ne sont pas journalisées (repudiation). Quelqu'un déclenche des réinitialisations en rafale contre une victime (denial of service).
Minutes 30-45 : que allons-nous faire à ce sujet
Chaque menace reçoit l'une des quatre réponses suivantes :
- Atténuer (mitigate) : réduire la probabilité que la menace se concrétise.
- Éliminer (eliminate) : supprimer la fonctionnalité ou le composant à l'origine de la menace.
- Transférer (transfer) : déplacer la responsabilité contractuelle ou financière vers un tiers.
- Accepter (accept) : ne rien faire, parce que les autres options ne cadrent pas avec les contraintes métier.
Le transfert ne réduit à lui seul ni la probabilité ni les dommages : notez donc qui est responsable des contrôles restants et du risque résiduel. Pour les menaces acceptées, consignez qui a accepté le risque et pourquoi.
Minutes 45-55 : tickets et tests
Transformez chaque mesure d'atténuation validée en une exigence qu'un développeur peut prendre en charge. Une ligne par menace suffit :
| ID de menace | STRIDE | Ticket | Test |
|---|---|---|---|
| 3.1-S | Spoofing | Rendre les liens de réinitialisation à usage unique et de courte durée | Un lien utilisé ou expiré est rejeté |
| 3-I | Information Disclosure | Renvoyer une réponse générique unique quelle que soit l'adresse | Les adresses connues et inconnues donnent des réponses identiques |
| 3-R | Repudiation | Journaliser chaque demande de réinitialisation | Une tentative de réinitialisation apparaît dans le journal |
La colonne des tests fait du modèle autre chose qu'un simple schéma. Chaque mesure d'atténuation a besoin d'une vérification qui échoue lorsque le contrôle est absent. Les abuse cases se traduisent directement : rejouer la requête, envoyer les étapes dans le désordre, envoyer deux requêtes en même temps. Placez les tickets dans le backlog propre à la fonctionnalité, avec l'identifiant de la menace dans le titre.
Minutes 55-60 : avons-nous fait du assez bon travail
Commencez par une vérification simple : existe-t-il des traces montrant un schéma, une liste de menaces et une liste de contrôles ? S'il en manque une, la session n'est pas terminée. Confirmez que chaque menace a une réponse, que chaque mesure d'atténuation précise comment l'équipe va la mettre en œuvre, et que les risques acceptés indiquent pourquoi.
Ensuite, gardez le modèle vivant. Mettez-le à jour en même temps que le système et, lorsque la conception change, ne rejouez que les parties concernées.
Par où commencer
- Choisissez une fonctionnalité à venir et réservez une heure avec un développeur, le responsable des exigences et une personne de l'exploitation.
- Faites rédiger le schéma de flux de données par une personne, avec les frontières de confiance repérées. Le groupe le corrige et numérote les points d'entrée pendant les dix premières minutes.
- Appliquez STRIDE à chaque composant et à chaque flux pendant 20 minutes, en notant avec chaque menace l'identifiant du point d'entrée concerné.
- Attribuez une réponse à chaque menace, notez qui est responsable de tout risque accepté ou transféré, puis créez un ticket et un test par mesure d'atténuation.
- Conservez le schéma, la liste des menaces et la liste des contrôles avec la documentation de la fonctionnalité. Si vous souhaitez un regard extérieur sur votre premier modèle, notre service de conseil peut le relire, et les menaces consignées constituent un bon périmètre pour un test d'intrusion ultérieur.
