Protéger le système ou traquer l'attaquant ? Choisir l'approche

La modélisation de menaces identifie des menaces et trouve des façons de réduire le risque, mais avant de trouver quoi que ce soit il faut décider où regarder. Il y a deux questions sur la table : ce qui doit être protégé et comment un attaquant pourrait opérer. Avoir la bonne approche adapte l'exercice pour générer des résultats de qualité : on peut concevoir une application de partage de fichiers en se concentrant sur la protection de ses processus, magasins de données et flux, ou en obtenant plus d'informations sur l'attaquant (motifs et moyens possibles). « Approach your data-flow diagram with the right threat model focus » sur Microsoft Learn présente trois approches possibles sur le même diagramme de flux de données (DFD), et ce post les parcourt avec l'exemple qu'utilise la source : une application de partage de fichiers.

Centrée sur le système : protéger tout ce qui est dessiné

L'approche centrée sur le système a un grand objectif : protéger tout le système. Chaque processus, magasin de données, flux de données, entité externe et limite de confiance du DFD est examiné, et avec cette information on sélectionne des contrôles de sécurité. Le cadre aide aussi à analyser comment le système affecte d'autres ressources, de deux types : logiques (code source, API, contrôles de sécurité logiques) et physiques (serveurs et ressources de contrôle de sécurité physique).

La source plante un pique qu'il vaut la peine de souligner : authentifier les utilisateurs avec Azure c'est bien, mais comprendre comment chaque partie du système fonctionne et interagit c'est mieux, et ça évite de créer des risques inconnus après l'implémentation. Les objectifs de la modélisation, vus depuis cette approche, sont de valider les hypothèses antérieures, d'identifier d'éventuelles menaces et de réduire le risque plus tôt dans le cycle de vie.

L'avantage concret de l'approche, selon la source elle-même, est qu'elle permet de se concentrer sur comment le système contrôle les utilisateurs et les données, en validant les hypothèses de sécurité sur les ressources physiques et logiques utilisées avec le service. Les ressources logiques et physiques ne sont pas une abstraction : du côté logique sont le code source, les API et les contrôles de sécurité logiques ; du côté physique, les serveurs et les ressources de contrôle de sécurité physique. S'authentifier avec Azure est une hypothèse ; la valider en parcourant le système pièce par pièce est un résultat.

Centrée sur l'attaquant : regarder de l'autre côté

L'approche centrée sur l'attaquant met l'accent sur l'attaquant, son motif, ses moyens et toutes les façons dont il peut causer des dégâts. La différence avec la précédente est l'unité d'analyse : au lieu du système dans son ensemble, elle examine les points d'entrée. La question qui gouverne l'exercice change complètement : pas « mon système est-il protégé ? » mais « depuis où peut-on le toucher, avec quoi, et pourquoi quelqu'un voudrait le faire ? ».

Elle ne remplace pas l'approche système ; elle la complète. Un système peut être intégralement protégé sur le papier et avoir un point d'entrée que personne n'a modélisé, parce que le dessin a priorisé ce que l'équipe connaissait. Le changement de regard a un coût pratique qu'il vaut aussi nomner : penser comme un attaquant exige un muscle que les équipes produit n'exercent pas tous les jours, et c'est pourquoi ceux qui le pratiquent professionnellement sont les testeurs de pénétration.

Centrée sur la ressource : protéger d'abord le classifié

L'approche centrée sur la ressource évalue le risque de chaque ressource. Elle identifie les ressources critiques selon des aspects comme le contrôle des données classifiées et se concentre principalement sur la protection de ces ressources. C'est la plus économique des trois : elle ne couvre pas le système entier, elle couvre ce qui fait mal si c'est perdu. Sa limite est le miroir de la précédente : tout ce qui n'est pas la ressource classifiée reste hors de la portée de l'exercice, et il faut le dire à voix haute avant de commencer.

Qui utilise quoi

Le partage des regards en pratique est le suivant : les ingénieurs Microsoft se concentrent principalement à protéger le système ; les équipes de test de pénétration se concentrent à protéger le système et comprendre l'attaquant. Et une précision qui évite les malentendus : l'approche centrée sur le système incorpore certaines des autres approches, mais chacune peut s'essayer individuellement pour obtenir des résultats plus granulaires.

Le motif qui reste du partage est cohérent avec ce que chaque équipe livre : l'équipe produit a besoin que le système tienne son usage normal et sa configuration réelle ; l'équipe de pénétration a besoin de penser comme quelqu'un qui veut entrer. Aucune des deux ne travaille depuis la ressource, même si toutes deux protègent des ressources.

L'exemple : application de partage de fichiers, vue trois fois

La source applique les approches sur un même cas. Dans l'application de partage de fichiers, le DFD montre les flux principaux : l'utilisateur demande l'accès à l'application, le flux d'authentification démarre, et l'utilisateur partage des fichiers avec d'autres utilisateurs.

flowchart LR
    U([Utilisateur]) -->|"demande l'accès"| SW((Service web))
    SW -->|"flux d'authentification"| SA[(Service d'authentification)]
    SW <-->|"fichiers partagés"| AD[(Magasin de données)]
    SW -->|"partage avec d'autres"| U2([Autres utilisateurs])
    subgraph Zone [Internet - Azure]
        SW
        SA
        AD
    end

En clair : le dessin a trois flux et cinq éléments, et chaque approche le parcourt avec une question différente.

Avec l'approche centrée sur le système, la visite analyse et protège chaque élément du diagramme : l'utilisateur, le service web, le service d'authentification, le magasin de données, la limite de confiance entre Internet et Azure et les flux de données. Le résultat est une liste de menaces par élément, avec la couverture complète du dessin comme propriété de l'approche.

Avec l'approche centrée sur l'attaquant, la même figure se lit à l'envers : les points d'entrée du dessin sont le formulaire où l'utilisateur demande l'accès, le flux d'authentification et les canaux par lesquels circulent les fichiers partagés. Le résultat indique où viser le test de pénétration et avec quels motifs s'attendre à une tentative.

Avec l'approche centrée sur la ressource, la première question est quel est l'actif classifié de cette application. Les fichiers que les utilisateurs partagent sont la donnée ; le service web et l'authentification comptent en tant que chemin vers cette donnée. Le résultat concentre l'effort de protection là où la perte ferait mal, et rend explicite, pour tout réviseur futur, pourquoi certaines parties du système ont reçu moins d'attention.

Les trois résultats sont corrects et aucun ne couvre ce que couvrent les deux autres. C'est le vrai choix : il n'y a pas d'approche qui maximise la couverture, la poursuite de l'attaquant et l'économie d'effort en même temps. Les flux du dessin aident à décider : si l'exercice porte sur une app de fichiers partagés dont la valeur est dans les fichiers, la ressource mène ; si le système est déjà en ligne avec des détracteurs probables, l'attaquant mène ; si c'est le premier passage de sécurité sur un nouveau produit, le système mène.

Choisir, c'est aussi accepter un coût

Choisir l'approche définit quelles questions restent sans réponse. L'approche ressource laisse dehors tout ce qui n'est pas la donnée classifiée ; celle de l'attaquant laisse dehors les défaillances sans adversaire derrière, comme la mauvaise configuration d'un magasin que personne ne vise. L'approche système laisse dehors la créativité de l'attaquant, qui ne suit pas l'organigramme de l'équipe.

La source ne vend pas d'approche universelle : elle enseigne à en choisir une et à savoir ce que vous ne voyez pas. Pour la plupart des équipes produit, le système est le point de départ sensé, et le reste s'ajoute quand l'exercice tourne déjà tout seul. Le signe que l'exercice est mature, c'est quand la question de l'approche cesse de sonner comme une discussion abstraite et commence à sonner comme l'ordre du jour de la prochaine revue.

De la lecture à l'exécution

Ce parcours a été de lecture : je n'ai pas appliqué les trois approches à un vrai système. Ce que la source rend clair, c'est ce que chacune produit et qui l'utilise en pratique ; ce qui manque, c'est de tester la différence sur un cas à soi, en dessinant le même DFD et en le passant par les trois regards pour voir combien de menaces nouvelles chacune apporte. La source elle-même laisse ouverte la question de comment combiner les approches sans doubler l'effort, et c'est probablement le premier vrai doute de quelqu'un qui a déjà modélisé avec une seule.

---

*Source : le module « Approach your data-flow diagram with the right threat model focus » de Microsoft Learn.*