Modéliser les menaces d'une fonctionnalité avec STRIDE en une seule séance de travail

Objectif

Repérer, avant qu'une fonctionnalité ne soit construite, les manières dont elle peut échouer sur le plan de la sécurité, en une séance assez courte pour qu'une équipe la répète à la fonctionnalité suivante, et laisser derrière soi des décisions qu'une revue ultérieure peut vérifier.

Prérequis

Une fonctionnalité ou une modification à la portée connue ; les personnes qui connaissent ses flux de données (typiquement une personne du développement et une personne de l'exploitation) ; un tableau blanc ou un outil de diagramme. Les quatre questions du Threat Modeling Manifesto servent d'ordre du jour : sur quoi travaille-t-on, qu'est-ce qui peut mal tourner, que va-t-on faire à ce sujet, a-t-on fait un travail suffisamment bon.

Étapes

1. Modéliser : dessiner un diagramme de flux de données de la fonctionnalité avec entités externes, processus, magasins de données, flux de données et frontières de confiance (navigateur vers serveur, service vers base de données, un locataire vers un autre). La fiche de synthèse OWASP qualifie le DFD d'approche sans doute la plus courante pour modéliser un système et désigne les frontières de confiance, les flux, les magasins, les processus et les entités externes comme les points d'attaque habituels.
2. Numéroter les éléments et les franchissements de frontière afin que chaque menace puisse s'y référer.
3. Énumérer : pour chaque élément, poser les six questions STRIDE. La documentation Microsoft définit les six catégories ; la fiche OWASP met en tableau la propriété que chacune viole : usurpation (authentification), altération (intégrité), répudiation (imputabilité), divulgation d'informations (confidentialité), déni de service (disponibilité), élévation de privilège (autorisation). Écrire une ligne par menace : élément, catégorie, ce que fait un attaquant.
4. Classer grossièrement par vraisemblance et impact. Ne pas consacrer la séance à la précision de la notation ; la fiche note que les deux sont difficiles à calculer.
5. Répondre : pour chaque menace, consigner l'une des quatre réponses listées par la fiche (atténuer, éliminer, transférer, accepter) et, pour les atténuations, une exigence testable telle que « chaque écriture dans le magasin 3 porte l'identifiant du locataire issu de la session ; couvert par le test X ».
6. Réviser : répondre à « a-t-on fait un travail suffisamment bon » avec les questions de la fiche : le diagramme correspond-il au système, chaque menace a-t-elle une réponse, chaque atténuation peut-elle être testée.
7. Conserver le diagramme et le tableau des menaces à côté de la conception (un ADR ou un document de conception) et les revoir lorsqu'une frontière de confiance change.

Résultat attendu

Un diagramme tenant sur une page, un tableau des menaces, et une liste d'exigences et de risques acceptés, chacun nommément attribué. Les revues ultérieures peuvent vérifier si les atténuations existent plutôt que de redériver les menaces.

Limites et base de vérification

STRIDE suggère des catégories, pas des attaques précises ; il ne fera pas apparaître les abus de logique métier ni les problèmes de chaîne d'approvisionnement à moins que le modèle n'inclue ces flux. Le résultat ne vaut que ce que vaut le diagramme. La procédure est une synthèse des recommandations citées ; aucun décompte de défauts trouvés par séance n'est avancé.