Modélisation des menaces : STRIDE, arbres d’attaque et diagrammes de flux de données

Ce qu’est la modélisation des menaces

La modélisation des menaces est l’activité qui consiste à examiner une conception pour trouver ce qui pourrait mal tourner du point de vue de la sécurité, et à décider quoi faire, avant que des attaquants ou des incidents ne le trouvent pour vous. C’est le principal moyen par lequel les principes de sécurité deviennent des décisions concrètes, et la réponse la plus directe à la catégorie OWASP de la conception non sécurisée : des failles qu’aucun codage correct, si soigné soit-il, ne peut corriger, parce que le contrôle nécessaire n’a jamais été prévu dans la conception.

Adam Shostack, qui a dirigé les travaux de modélisation des menaces chez Microsoft et écrit le livre de référence sur le sujet, ramène l’activité à quatre questions. Sur quoi travaillons-nous ? (un modèle du système, généralement un diagramme). Qu’est-ce qui peut mal tourner ? (les menaces, trouvées de façon systématique). Qu’allons-nous faire à ce sujet ? (atténuer, éliminer, transférer ou accepter chaque menace). Avons-nous fait un travail suffisant ? (revoir le modèle, les menaces et le suivi). Toute méthode qui répond aux quatre questions est de la modélisation des menaces ; la suite de cette section décrit les techniques que la plupart des équipes utilisent pour y répondre.

En 2020, un groupe de praticiens, dont Shostack, a publié le Threat Modeling Manifesto, sur le modèle du Manifeste agile. Il privilégie une culture qui consiste à trouver et à corriger les problèmes de conception plutôt que la conformité de pure forme, les personnes et la collaboration plutôt que les processus et les outils, un cheminement de compréhension plutôt qu’un instantané de sécurité ponctuel, le fait de pratiquer la modélisation des menaces plutôt que d’en parler, et l’amélioration continue plutôt qu’une livraison unique. Son message est que la modélisation des menaces est une habitude de l’équipe qui construit le système, et non un document produit une fois par an par des personnes extérieures.

Modéliser le système : diagrammes de flux de données et frontières de confiance

La première question exige un modèle du système qui montre où vont les données et où la confiance change. Le choix traditionnel est un diagramme de flux de données (DFD) comportant cinq types d’éléments : les entités externes (des personnes ou des systèmes hors de votre contrôle, dessinés sous forme de rectangles), les processus (du code que vous exécutez, dessiné sous forme de cercles ou d’ellipses), les stockages de données (bases de données, fichiers, files et caches, dessinés entre deux lignes parallèles), les flux de données (des flèches montrant les données qui circulent entre les autres éléments) et les frontières de confiance (des lignes ou des cadres en pointillés là où le niveau de confiance change).

Les DFD conviennent à la modélisation des menaces parce que les attaques suivent les données : chaque flux qui franchit une frontière de confiance est un endroit où un attaquant peut injecter, intercepter ou rejouer quelque chose. Un diagramme de conteneurs C4 du chapitre 4 est un bon point de départ : ajoutez les frontières de confiance, faites de chaque flèche un flux de données avec un sens et une étiquette, et incluez les stockages et les files que les diagrammes de conteneurs laissent parfois implicites. Gardez le diagramme au niveau où l’on trouve les menaces : un diagramme par fonctionnalité ou par flux important est plus utile qu’un seul diagramme géant de tout le système.

Trouver les menaces avec STRIDE

STRIDE a été créé chez Microsoft en 1999 par Loren Kohnfelder et Praerit Garg, comme moyen mnémotechnique pour aider les développeurs à réfléchir aux menaces qui pèsent sur leurs produits. Chaque lettre nomme une catégorie de menaces, et chaque catégorie correspond à l’atteinte à une propriété de sécurité, ce qui en fait l’utilité : c’est une incitation systématique, pas une liste d’attaques connues.

Une façon pratique d’appliquer STRIDE est le STRIDE par élément : parcourir chaque élément du DFD et ne poser que les questions qui s’appliquent à son type. Les entités externes peuvent être usurpées et peuvent répudier ; les processus sont exposés aux six catégories ; les stockages de données à la falsification, à la divulgation d’informations et au déni de service (et à la répudiation lorsque le stockage est un journal) ; les flux de données à la falsification, à la divulgation d’informations et au déni de service. Consacrer l’essentiel de l’attention aux flux qui franchissent des frontières de confiance permet de garder l’exercice ciblé.

STRIDE trouve des menaces ; il ne les classe pas et ne choisit pas les mesures d’atténuation. Ses catégories se recoupent aussi en pratique (une identité usurpée mène généralement à une divulgation d’informations ou à une élévation de privilèges), ce qui n’a pas d’importance : le but est de trouver la menace, pas de la classer parfaitement. Pour les menaces pesant sur la vie privée, comme le fait de relier ou d’identifier des personnes à partir de données d’apparence anodine, la méthode LINDDUN de la KU Leuven joue le rôle que STRIDE joue pour la sécurité ; elle est présentée avec la protection de la vie privée dès la conception.

Arbres d’attaque

Un arbre d’attaque, popularisé par Bruce Schneier dans un article de 1999 du Dr. Dobb’s Journal, regarde le système du côté de l’attaquant. La racine est un objectif, comme obtenir des repas sans payer ; chaque enfant est un moyen d’atteindre son parent. Les enfants d’un nœud OU sont des alternatives ; tous les enfants d’un nœud ET sont nécessaires ensemble. Les feuilles peuvent être annotées de propriétés comme le coût, la compétence nécessaire ou le fait que l’étape soit possible ou non, et ces valeurs remontent l’arbre : le coût d’un nœud OU est celui de son enfant le moins coûteux, le coût d’un nœud ET la somme de ses enfants.

Les arbres d’attaque complètent bien STRIDE. STRIDE parcourt la conception élément par élément et assure une bonne couverture ; un arbre d’attaque suit un attaquant motivé et montre bien quel chemin est le moins coûteux, donc où une mesure d’atténuation rapporte le plus. Dans l’arbre ci-dessous, payer avec une carte volée est relativement coûteux parce qu’il faut deux choses à la fois, alors que modifier le prix dans la requête du client est trivial si le serveur lui fait confiance. Le chemin le moins coûteux détermine le risque, si bien que recalculer chaque prix sur le serveur vaut davantage que n’importe quel réglage de la lutte contre la fraude à la carte.

Évaluer le risque

Un modèle de menaces trouve généralement plus de menaces qu’une équipe ne peut en traiter à la fois, si bien que chacune doit être évaluée. L’approche habituelle consiste à juger la probabilité (facilité, attrait, exposition) et l’impact (ce qui est perdu si la menace se réalise : argent, données à caractère personnel, disponibilité, réputation, exposition juridique) sur des échelles simples, par exemple faible, moyen et élevé, et à les combiner dans une matrice. La valeur de l’évaluation tient moins à la précision du chiffre qu’à une justification écrite que d’autres peuvent contester. Les organisations dotées d’une gestion des risques mature utilisent parfois des méthodes quantitatives comme FAIR (Factor Analysis of Information Risk) pour exprimer le risque sous forme d’une fourchette de pertes attendues.

Deux raccourcis populaires méritent d’être connus parce qu’ils sont souvent mal utilisés. DREAD (damage, reproducibility, exploitability, affected users, discoverability, soit dommages, reproductibilité, exploitabilité, utilisateurs touchés et découvrabilité), autrefois utilisé chez Microsoft, notait chaque menace sur cinq facteurs (souvent de 1 à 10) et en faisait la moyenne. Il est tombé en désuétude, y compris chez Microsoft, parce que différentes personnes notaient la même menace de façon très différente et que la moyenne donnait une fausse impression de précision ; la découvrabilité, en particulier, récompense l’obscurité, ce qui contredit la conception ouverte. CVSS, le Common Vulnerability Scoring System maintenu par le FIRST (version 4.0, 2023), est le bon outil pour une autre tâche : évaluer la gravité d’une vulnérabilité connue dans un produit, comme une faille dans une bibliothèque. Son score de base décrit la vulnérabilité, pas le risque d’une menace de conception dans votre contexte ; il ne faut donc pas l’utiliser pour classer les résultats d’un modèle de menaces.

Chaque menace se conclut par l’une de quatre décisions : atténuer (ajouter un contrôle), éliminer (supprimer la fonctionnalité ou les données, souvent la meilleure option), transférer (laisser quelqu’un de mieux placé la porter, comme un prestataire de paiement qui détient les données de carte) ou accepter (consigner qu’une personne habilitée à le faire a accepté le risque résiduel, et pourquoi). L’acceptation non consignée est l’échec le plus courant : la menace a été trouvée, personne ne l’a corrigée, et personne n’a décidé de ne pas le faire.

Les réponses aux deux dernières questions sont aussi importantes que le tableau. Chaque mesure d’atténuation devient un élément du backlog avec un responsable ; T3 et T4 deviennent aussi des scénarios de sécurité assortis de tests automatisés (un webhook avec une signature invalide doit être rejeté ; un appel à Paiements depuis toute identité autre que Commandes doit échouer). Les deux décisions architecturales, les champs de paiement hébergés et le TLS mutuel entre Commandes et Paiements, sont consignées sous forme d’ADR. Pour la quatrième question, l’équipe revoit le modèle un mois plus tard par rapport à ce qui a réellement été construit, et le référent sécurité vérifie que chaque élément à risque élevé a été soit atténué, soit explicitement accepté.

Quand et à quelle fréquence modéliser les menaces

La modélisation des menaces rapporte le plus au moment de la conception, quand changer une décision coûte un coup d’effaceur sur un tableau blanc. Elle doit ensuite être répétée chaque fois que quelque chose d’important change : une nouvelle frontière de confiance ou intégration externe, un nouveau type de données sensibles, une modification de l’authentification ou de l’autorisation, un nouvel environnement de déploiement, ou le passage d’un monolithe à des services. Une règle raisonnable consiste à faire de « ce changement modifie-t-il le modèle de menaces ? » une question des revues de conception et du modèle d’enregistrement de décision d’architecture, et à planifier une revue du modèle de chaque système au moins une fois par an et après chaque incident de sécurité.

L’effort doit être proportionné, dans l’esprit de l’approche guidée par les risques du chapitre 1. Un nouveau microservice qui traite des paiements mérite une séance d’une demi-journée avec un DFD complet ; ajouter un champ à une carte publique demande cinq minutes et un rapide coup d’œil STRIDE au flux modifié. Beaucoup d’équipes conservent leur DFD sous forme de code à côté du système (OWASP Threat Dragon et le Threat Modeling Tool de Microsoft sont des outils de diagrammes gratuits, et des bibliothèques comme OWASP pytm génèrent des diagrammes et des menaces candidates à partir du code), afin que le modèle soit relu et mis à jour avec le système qu’il décrit.