Le DFD et ses outils : lequel pense les menaces et lequel ne fait que dessiner

Un diagramme de flux de données (DFD) est la représentation graphique du fonctionnement du système, avec tous ses magasins de données, processus, entités externes, limites de confiance et flux de données. Il peut se créer sur n'importe quelle toile physique ou virtuelle, et c'est là que commence le piège : dessiner est facile, analyser le dessin demande une connaissance pratique de la modélisation de menaces. « Use recommended tools to create a data-flow diagram » sur Microsoft Learn compare les outils recommandés, et la différence qui compte entre eux n'est qu'une : certains ajoutent un moteur de génération de menaces et des stratégies de réduction des risques, et d'autres ne font que permettre de dessiner.

La Microsoft Threat Modeling Tool

La Microsoft Threat Modeling Tool fait quatre choses à la fois : créer des DFDs, communiquer sur la conception de sécurité des systèmes, analyser ces conceptions pour détecter d'éventuels problèmes de sécurité, et suggérer et administrer les atténuations. Elle est reconnue par la communauté et offre des modèles personnalisables avec un moteur de génération de menaces.

Le modèle par défaut s'appelle SDL TM Knowledge Base : il apporte un ensemble basique d'éléments et les fonctionnalités de génération de menaces, et pour l'utiliser il suffit d'une connaissance basique du DFD et de STRIDE (le cadre à six catégories de menaces : usurpation, altération, déni, divulgation d'information, déni de service et élévation de privilèges).

Les galeries de symboles sont des modèles composés d'éléments de processus, d'acteur externe, de magasin de données, de flux de données et de limites de confiance, qu'on fait glisser sur la toile. Des galeries secondaires peuvent être créées pour plus de granularité, et ce détail a des conséquences pratiques. L'élément primaire « flux de données » accepte les secondaires HTTP et HTTPS : choisir HTTP au lieu de HTTPS fait que le moteur génère plus de menaces, parce que l'altération, la divulgation d'information et l'usurpation sont courantes sur les canaux non chiffrés. La galerie secondaire n'est pas de la décoration ; c'est du contexte que le moteur utilise pour décider.

Chaque élément admet aussi des propriétés additionnelles, ajoutées depuis la vue administrateur et visibles au glisser-déposer. Et chaque menace générée apporte ses propres champs, les propriétés de la menace, où se documente le cas concret que le moteur a trouvé dans votre dessin.

Le moteur de génération, en trois étapes

Le moteur est le cœur de l'outil, et il fonctionne comme un moteur de règles sur votre dessin. Il examine des éléments individuels et connectés, et ses stratégies de réduction des menaces et des risques se spécifient en trois étapes :

flowchart LR
    E[Éléments du DFD<br/>processus, flux, magasins] --> R[Règles : phrases simples<br/>combinées avec ET / OU]
    R -->|Inclure| G[Menace générée<br/>avec son atténuation]
    R -->|Exclure| N[Menace omise]

En clair : vous dites au moteur quoi regarder avec des phrases quasi en espagnol, ces phrases se combinent avec des opérateurs logiques, et le résultat décide si une menace apparaît dans votre liste ou non.

L'étape 1 spécifie sources et destinations avec des phrases simples, au format {target.name} ou {source.name} (« la destination [nom de l'élément] », « la source est [nom de l'élément] »). L'étape 2 combine ces phrases avec des opérateurs ET/OU sur des propriétés : par ex. target.[propriété] est "Oui" AND source.[propriété] est "Non", ou « le flux croise [nom de limite de confiance] ». L'étape 3 définit de générer ou d'omettre des menaces avec deux champs : Inclure, qui génère la menace si les phrases sont vraies, et Exclure, qui l'omet si elles le sont.

Le modèle par défaut inclut un exemple qu'on comprend du premier coup : la menace « Scripting entre sites » est incluse si la destination est un serveur web ou une application web, et exclue si target.[Sanitiza entrada] vaut « Oui ». C'est-à-dire que la menace n'est générée que quand le processus est un serveur ou une application web et que les entrées et sorties ne sont pas assainies. La même structure à deux champs s'applique à toute menace que vous ajoutez : la règle Inclure décrit quand elle s'applique, la règle Exclure décrit quand l'équipe a déjà fait le travail que la menace dénonce.

La paire Inclure/Exclure est aussi la règle d'or pour ajouter vos propres menaces : toute menace que vous ajoutez décrit en phrases simples quand elle s'applique et quand l'équipe a déjà fait le travail que la menace dénonce. Une limite honnête : créer ses propres modèles est un sujet complexe que cette source ne couvre pas en profondeur. Et une clarification sur la portée du moteur qu'il faut garder en tête avant de faire confiance à la liste qu'il renvoie : les menaces générées ne se basent pas sur le diagramme entier, mais sur chaque élément ou interaction individuel. Le moteur examine des éléments individuels et connectés pour décider quelles menaces générer ; ce que l'outil apporte en contrepartie complète : il permet de changer des menaces, des galeries de symboles et leurs propriétés, et avec chaque menace générée il inclut les façons de réduire ou éliminer le risque. C'est-à-dire que la sortie se fait par élément et l'atténuation vient collée à chaque ligne.

Vues administrateur et utilisateur

L'outil sépare deux publics. Les administrateurs ajoutent du contexte et des étapes actionnables : priorité des problèmes, hyperliens vers de la documentation en ligne et assignation de risques externes avec des sources tierces de confiance comme l'OWASP Top 10 (la liste des risques de sécurité web les plus critiques, publiée par le projet Open Web Application Security Project) et les détails de CWE (Common Weakness Enumeration, le catalogue public des faiblesses logicielles). Les utilisateurs voient les changements en analysant leurs DFDs : la liste que vous recevez est déjà annotée par quelqu'un, avec priorité posée et lectures recommandées.

Le flux de travail que cette séparation suggère est celui attendu dans une équipe : celui qui modèle dessine et analyse ; celui qui administre la pratique de sécurité y met priorité et contexte externe ; l'analyse est relancée et les changements apparaissent dans la vue utilisateur. La séparation répond aussi à une réalité d'équipe : la personne qui dessine le DFD est rarement celle qui décide de l'appétit pour le risque de l'organisation, et les vues permettent à chacun de travailler sur le même artefact sans se marcher dessus.

Visio : dessine bien, ne pense pas

Visio offre une toile propre pour les DFD avec des applications web et de bureau pour voir, éditer et partager, en enregistrant sur SharePoint ou OneDrive. Ses avantages sont connus de quiconque utilise la suite : glisser-déposer avec annotation de diagrammes, interface intuitive et accessible avec une expérience Microsoft 365 familière, modèles pour démarrer vite et collaboration en temps réel avec commentaires et partage depuis l'application web ou dans Microsoft Teams.

L'inconvénient est de catégorie : Visio n'offre pas de fonctionnalités automatisées de modélisation de menaces. Il n'y a pas de moteur de génération de menaces, et l'utilisateur est responsable de modéliser manuellement les menaces de chaque élément et interaction. Dessiner le DFD dans Visio vous laisse exactement où vous étiez : avec un joli dessin et une liste de menaces qu'il vous reste à inventer. La conséquence opérationnelle est concrète : une équipe qui choisit Visio doit budgétiser des heures d'analyse manuelle à chaque itération de conception, et ces heures apparaissent rarement dans le plan de projet. L'outil avec moteur inverse le coût vers le modèle, qui se paie une fois et se réutilise sur chaque DFD.

	Threat Modeling Tool	Visio	Tableau blanc
Dessine le DFD	Oui	Oui	Oui
Génère des menaces	Oui, avec moteur et modèle	Non, manuel	Non, manuel
Collaboration	Vues admin/utilisateur	Temps réel (web, Teams)	Dans la salle
Courbe d'apprentissage	Connaître DFD et STRIDE	Familier si vous utilisez Microsoft 365	Basse

Le tableau résume le compromis : le choix se réduit à payer le coût de l'analyse à la main ou à laisser un modèle le faire pour vous.

Le tableau blanc et le reste du marché

Le parcours se ferme avec l'option la moins chère de toutes : un tableau blanc fonctionne avec une courbe d'apprentissage basse, mais exige des connaissances en modélisation de menaces, parce qu'il n'y a pas de moteur qui pense pour vous. Le tableau blanc reste légitime pour une première session avec l'équipe de sécurité ; ce qu'il ne fait pas, c'est laisser un artefact ré-analysable quand le système change.

Et il y a beaucoup d'autres outils, payants et open source, en plus des deux recommandés. La source ne les liste pas, et cette absence informe aussi : le standard que ce parcours laisse est le paire « modèle avec moteur + connaissance de STRIDE », avec le tableau blanc comme démarrage. N'importe quelle alternative que vous choisissez ensuite se mesure contre ce standard : si elle ne génère pas de menaces, c'est une toile.

De la lecture à l'exécution

Aucun de ces outils n'a été exécuté dans ce parcours : la comparaison vient de la description de la source, pas d'un test avec votre propre DFD. Ce que le parcours rend clair, c'est où finit le dessin et où commence l'analyse : l'outil avec moteur fait la moitié mécanique de la modélisation (générer des menaces candidates à partir de règles) et laisse à la personne l'autre moitié (bien concevoir le DFD et décider). Ce qui manque à tester, c'est la vraie expérience de s'asseoir avec la Threat Modeling Tool, de dessiner quelque chose de soi et de voir quelle liste de menaces sort ; et aussi comparer avec une alternative open source, qui est la question que cette source laisse ouverte.

---

*Source : le module « Use recommended tools to create a data-flow diagram » de Microsoft Learn.*