Diagrammes de flux de données pour la modélisation des menaces : STRIDE pas à pas

Toute méthode de modélisation des menaces commence par la même question : sur quoi travaillons-nous ? La réponse habituelle est un diagramme de flux de données. C'est un schéma simple, avec cinq types d'éléments, et l'heure que vous y consacrez est la plus utile que vous puissiez passer avant une revue de sécurité, car la plupart des menaces se logent là où les données passent d'un niveau de confiance à un autre.

Ce guide montre comment tracer un diagramme de flux de données (DFD) pour la modélisation des menaces, où placer les frontières de confiance et comment parcourir le diagramme avec STRIDE. L'exemple est une fonctionnalité présente dans presque tous les produits : l'envoi d'une photo de profil par les utilisateurs.

Les quatre questions

Un modèle de menaces concret répond à quatre questions, popularisées par Adam Shostack et le Threat Modeling Manifesto :

1. Sur quoi travaillons-nous ?
2. Qu'est-ce qui peut mal tourner ?
3. Qu'allons-nous faire pour y remédier ?
4. Avons-nous fait un travail suffisamment bon ?

Le diagramme de flux de données répond à la première. STRIDE aide pour la deuxième. Les notes et les tickets que vous rattachez au diagramme répondent à la troisième, et une revue quelques semaines plus tard répond à la quatrième.

Les éléments d'un diagramme de flux de données

Élément	Ce que c'est	Forme habituelle
Entité externe	Une personne ou un système hors de votre contrôle : un utilisateur, l'API d'un partenaire	Rectangle
Processus	Du code que vous exécutez et qui transforme ou déplace des données	Cercle ou forme arrondie
Stockage de données	Là où les données sont au repos : une base de données, un bucket, une file d'attente, un journal	Deux lignes parallèles ou un cylindre
Flux de données	Des données qui circulent entre deux éléments	Flèche étiquetée avec les données
Frontière de confiance	Là où le niveau de confiance change	Ligne pointillée ou zone autour des éléments

Deux règles rendent un DFD utile pour la sécurité. Étiquetez chaque flux avec les données qu'il transporte, pas seulement avec le protocole : photo + session token en dit bien plus à un relecteur que HTTPS. Et ne reliez jamais directement deux stockages de données ou deux entités externes : les données ne circulent qu'à travers un processus, et c'est là que vous pouvez les contrôler.

L'exemple : l'envoi d'une photo de profil

Les utilisateurs envoient une photo de profil depuis le navigateur. L'API web vérifie leur session et stocke le fichier brut dans un bucket privé. Un service de traitement le récupère, envoie les octets à une API d'analyse antimalware tierce, réencode l'image, supprime ses métadonnées, réécrit la version nettoyée dans le bucket et enregistre l'URL de la photo dans la base de données des utilisateurs.

Il y a quatre zones de confiance : Internet, notre couche applicative, notre couche de données et le scanner tiers. Sous forme de DFD :

Comptez les flux qui franchissent une frontière de zone : du navigateur à l'API, de l'API au bucket, du bucket au service de traitement et retour, du service de traitement au scanner et retour, du service de traitement à la base de données. C'est là qu'il faut passer votre temps.

Parcourir le diagramme avec STRIDE

STRIDE nomme six types de menaces. L'approche « STRIDE par élément » de Microsoft ne vérifie chaque élément que pour les menaces qui s'appliquent à son type :

Type d'élément	S	T	R	I	D	E
Entité externe	✓		✓
Processus	✓	✓	✓	✓	✓	✓
Stockage de données		✓	✓ (journaux)	✓	✓
Flux de données		✓		✓	✓

Les six lettres désignent l'usurpation d'identité (Spoofing), la falsification (Tampering), la répudiation (Repudiation), la divulgation d'informations (Information disclosure), le déni de service (Denial of service) et l'élévation de privilèges (Elevation of privilege). En parcourant la fonctionnalité d'envoi élément par élément, on obtient une liste comme celle-ci :

• Usurpation d'identité (navigateur). Un jeton de session volé ou forgé sert à envoyer une photo au nom de quelqu'un d'autre. Contre-mesure : validez le jeton à chaque requête, gardez des sessions courtes et liez la clé d'objet à l'identifiant de l'utilisateur authentifié, jamais à une valeur issue de la requête.
• Falsification (du bucket au service de traitement). Un fichier nommé photo.jpg est en réalité tout autre chose. Contre-mesure : vérifiez le format réel du fichier, pas son nom ni son type déclaré, et réencodez chaque image avant que quiconque d'autre ne la voie.
• Répudiation (API). Un utilisateur nie avoir envoyé une image choquante, et rien ne prouve le contraire. Contre-mesure : journalisez l'identifiant de l'utilisateur, la clé d'objet, l'heure et l'adresse du client pour chaque envoi.
• Divulgation d'informations (bucket). Le bucket autorise le listage public, ou les photos conservent leurs coordonnées GPS dans leurs métadonnées EXIF. Contre-mesure : un bucket privé avec des URL signées de courte durée, et des métadonnées supprimées lors du réencodage.
• Déni de service (API et service de traitement). Des fichiers énormes ou des images qui, une fois décompressées, atteignent des tailles démesurées épuisent la mémoire. Contre-mesure : des limites de taille de fichier et de nombre de pixels, et des délais d'expiration dans le service de traitement.
• Élévation de privilèges (service de traitement). Un fichier piégé exploite un bug de la bibliothèque d'images et exécute du code avec les permissions du service de traitement. Contre-mesure : exécutez le service de traitement dans un bac à sable qui n'a accès à rien d'autre qu'à son préfixe de bucket et à son unique table.

Notez les menaces sur le diagramme, sous forme de lignes courtes et numérotées, dans une note placée à côté des éléments concernés, et reliez chacune au ticket qui suit le correctif. Le diagramme sert alors aussi de synthèse de la revue.

Règles pour les diagrammes de modélisation des menaces

• Dessinez la fonctionnalité, pas l'entreprise. Un DFD par fonctionnalité ou par service. Un diagramme de tout ne laisse aucune place aux détails qui comptent.
• Montrez où se fait l'authentification. Sur chaque flux qui franchit une frontière, marquez le processus qui vérifie l'identité.
• Incluez les chemins que personne ne montre en démo. Les outils d'administration, les accès du support, les traitements par lots et les sauvegardes franchissent aussi des frontières.
• Restez à un seul niveau de détail. Un DFD de niveau contexte montre le système comme un seul processus ; un DFD de niveau 1 le décompose en ses principaux processus. Choisissez-en un par diagramme.
• Versionnez-le avec la fonctionnalité. Quand la conception change, les menaces changent. Mettez à jour le diagramme dans la même pull request que le document de conception.

Outils spécialisés ou canevas partagé

Des outils gratuits comme OWASP Threat Dragon et Microsoft Threat Modeling Tool sont conçus pour ce travail et peuvent suggérer des menaces pour chaque élément. Ils fonctionnent bien quand une équipe sécurité pilote la démarche.

Un canevas partagé convient mieux quand les personnes qui construisent la fonctionnalité dessinent le diagramme ensemble pendant la conception : le DFD se trouve à côté des diagrammes d'architecture, tout le monde le modifie en direct et les notes restent rattachées aux éléments. Dans les deux cas, c'est la discussion autour du diagramme qui a de la valeur.

Le construire dans Archboard

1. Connectez-vous avec Google ou GitHub et créez un diagramme.
2. Ajoutez un Cadre du pack Base pour chaque zone de confiance et nommez-le d'après la zone, par exemple Trust zone: app tier.
3. Ajoutez les entités externes comme nœuds Boîte du pack Base, les processus comme formes Ellipse du même pack, et les stockages de données depuis le pack Données (Magasin d'objets, Postgres).
4. Connectez les ports et étiquetez chaque lien avec les données qu'il transporte.
5. Ajoutez une Note à côté des éléments concernés pour lister chaque menace avec sa lettre STRIDE, son numéro et son ticket.

L'exemple utilise 10 nœuds de diagramme plus trois notes qui listent sept menaces, dans les limites de l'offre Free. Pour le volet réseau de la sécurité, consultez le modèle diagramme d'architecture zero trust, et pour cartographier les données personnelles, le cas d'usage Cartographie des données RGPD.

FAQ

Un diagramme de flux de données est-il la même chose qu'un diagramme d'architecture ? Non. Un diagramme d'architecture montre les composants et la façon dont ils sont reliés ; un DFD montre comment les données circulent et où la confiance change. Ils ont souvent des boîtes en commun, mais le DFD est dessiné pour répondre à la question de sécurité.

STRIDE ou une autre méthode ? STRIDE est un bon choix par défaut pour les fonctionnalités logicielles. LINDDUN se concentre sur les menaces pour la vie privée, et PASTA est un processus centré sur les risques, pensé pour les programmes de plus grande ampleur. Le diagramme reste le même point de départ pour toutes ces méthodes.

Qui doit participer ? Les ingénieurs qui construisent la fonctionnalité, une personne qui l'exploitera et un ingénieur sécurité si vous en avez un. Ceux qui connaissent le code trouvent les menaces ; l'ingénieur sécurité veille à ce que l'exercice reste honnête.

Combien de temps faut-il compter ? Une heure est typique pour une fonctionnalité comme l'envoi de photo : 15 minutes pour dessiner, 30 pour parcourir STRIDE, 15 pour s'accorder sur les correctifs et leurs responsables.

À quelle fréquence faut-il mettre à jour le modèle ? Dès qu'un flux franchit une nouvelle frontière, qu'un nouveau stockage de données apparaît ou que la fonctionnalité change qui peut faire quoi.

Commencez gratuitement — un siège, sans carte bancaire.