STRIDE : six questions qui trouvent des menaces dans votre conception

Un diagramme de flux de données (DFD) bien dessiné n'est toujours pas une liste de menaces. Le pont entre les deux est un cadre, et celui que Microsoft utilise est STRIDE : le cadre examine chaque élément du DFD et ses interactions et guide à travers les six catégories principales de menaces, chacune avec son contrôle de sécurité correspondant. Il s'applique à tous les DFD de systèmes nouveaux ou existants, parce que plus on attend, plus le risque pour les clients est grand. « Use a framework to identify threats and find ways to reduce or eliminate risk » sur Microsoft Learn parcourt les six catégories en détail ; ce post les parcourt dans le même ordre.

Le tableau complet

Catégorie	Ce que c'est	Contrôle	Question guide
Usurpation	Faire passer pour quelqu'un ou quelque chose d'autre	Authentification	Les deux côtés de la communication sont-ils authentifiés ?
Altération	Changer des données sans autorisation	Intégrité	Comment sais-je que personne ne peut changer les données ?
Déni	Ne pas revendiquer la responsabilité d'une action	Non-répudiation	Puis-je lier chaque action à une identité ?
Divulgation	Voir des données sans permission	Confidentialité	Puis-je être sûr que personne ne les voit ?
Déni de service	Surcharger le système	Disponibilité	Y a-t-il des zones limitées en ressources ?
Élévation de privilèges	Avoir des permissions qu'on ne devrait pas	Autorisation	Comment sais-je que l'utilisateur peut le faire ?

Les six cohabitent dans une seule analyse : une seule flèche qui croise une limite de confiance non chiffrée peut tomber en altération et divulgation à la fois, et cette coïncidence décrit le canal tel qu'il est : une conversation non sécurisée entre zones. L'acronyme n'est pas décoratif : chaque lettre est une question qu'on pose sur chaque boîte et chaque flèche du dessin. La mécanique d'application est la même pour les six : le cadre examine chaque élément du DFD et ses interactions, et sur chacun les six questions du tableau se parcourrent. Un processus seul ne menace pas ; un processus qui reçoit l'entrée d'une entité externe, la stocke dans un magasin et renvoie une réponse produit des menaces qu'on peut nommer.

Un détail de processus qui économise des discussions : les catégories ne se discutent pas une par une contre le goût de l'équipe ; chaque question du tableau se répond avec une preuve du dessin. Si la réponse à « comment sais-je que personne ne peut voir les données ? » est « parce que le trafic passe par HTTPS sur cette flèche », la menace se documente comme couverte, et s'il n'y a pas de flèche HTTPS à pointer, elle se documente comme ouverte.

flowchart LR
    S[Usurpation] --> P[Processus]
    S --> E[Entité externe]
    M[Altération] --> P
    M --> A[Magasin de données]
    M --> F[Flux de données]
    R[Déni] --> P
    R --> E
    R --> A
    D[Divulgation] --> P
    D --> A
    D --> F
    DoS[Déni de service] --> P
    DoS --> A
    DoS --> F
    EP[Élévation de privilèges] --> P

Là est le motif que les sections suivantes répètent : le processus est le seul élément que les six catégories touchent, le magasin de données apparaît dans quatre et le flux de données dans trois, tandis que l'entité externe n'est touchée que par l'usurpation et le déni.

Usurpation : être quelqu'un d'autre

L'usurpation arrive quand une personne ou un programme malveillant se fait passer correctement pour l'utilisateur ou son système. Les exemples de la source sont d'école : un courriel d'un compte apparemment légitime avec des liens malveillants et des pièces jointses pour capturer identifiants, données et accès à l'appareil ; ou l'usurpation de SSID et d'adresses IP, en profitant du fait que TCP/IP est intrinsèquement non sécurisé.

En risque : les éléments processus et entité externe, et les interactions processus-processus, processus-magasin de données et processus-entité externe. Ça s'évite avec l'authentification : des messages signés avec des signatures numériques pour authentifier origine et intégrité, TLS/SSL pour chiffrer la transmission, et des identifiants uniques avec tokens d'expiration, mots de passe ou authentification multifacteur (MFA). Parmi les contrôles courants : codes de hachage, codes d'authentification de messages, authentification de cookies, Kerberos, certificats, IPSec et paquets signés numériquement.

Altération : changer les données

L'altération est lire, modifier, supprimer ou insérer des données sans autorisation. Les vecteurs de la source : modifier le cache, la connexion ou les bases de données ; insérer des charges dans les caches du navigateur ; modifier la mémoire avec une gestion inadéquate des appels d'API ; rediriger des données vers des machines compromises ; tromper des utilisateurs pour qu'ils rejoignent un réseau ou téléchargent un fichier.

En risque : processus, magasin de données et flux de données, avec les interactions processus-magasin et surtout le flux qui croise des limites de confiance. Le contrôle est l'intégrité : validation d'entrée, signatures numériques, listes de contrôle d'accès (ACL), TLS/SSL et tunnels IPSec, plus les contrôles d'intégrité du système d'exploitation et les codes d'authentification de messages.

Déni : nier ce qui a été fait

Le déni (ou répudiation), c'est quelqu'un qui réalise une action et affirme le contraire : nier la modification d'enregistrements, utiliser le compte d'un autre, affirmer n'avoir rien supprimé. Le détail qui rend cette catégorie plus dangereuse qu'elle n'en a l'air : les journaux du système sont une mine d'or pour un attaquant, qui ne veut pas seulement les manipuler, il veut aussi collecter des données sur les utilisateurs, les environnements et les points faibles.

En risque : processus, entité externe et magasin de données. Le contrôle est le non-répudiation : création et protection de journaux de sécurité pour suivre chaque action jusqu'à son origine, avec authentification solide, protection du journal et supervision, signatures numériques, horodatages sûrs et tiers de confiance.

Divulgation : voir ce qui ne vous regarde pas

La divulgation d'informations, ce sont des données confidentielles exposées à des personnes non autorisées, avec ou sans intention : messages d'erreur qui révèlent des données, accès à des documents avec contrôles faibles, données voyageant sur des réseaux non sûrs. L'intention de celui qui a exposé ne change pas la gravité de la donnée exposée, et c'est pourquoi la catégorie se modélise pareil pour un bug de log que pour une fuite délibérée. En risque : processus, magasin et flux de données, y compris les interactions qui croisent des limites de confiance. Le contrôle est la confidentialité : ACL pour que les bons utilisateurs accèdent aux bonnes données, chiffrement au repos, en transit et en usage, TLS/SSL et tunnels IPSec.

Déni de service : le laisser sans service

Le déni de service, c'est rendre le système indisponible : inonder le réseau de requêtes, absorber les processus mémoire et CPU, bloquer les magasins de données. En risque : processus, magasin et flux de données. Le contrôle est la disponibilité : listes de contrôle d'accès réseau pour le trafic, ressources élastiques pour un usage croissant ou décroissant, supervision d'anomalies et marques du système d'exploitation pour mémoire et CPU ; parmi les contrôles courants, filtres, quotas, autorisation et haute disponibilité. La question guide de la catégorie (y a-t-il des zones où mon service est limité en ressources ?) se répond en regardant le DFD avec des yeux de pénurie : chaque processus qui a un plafond de CPU, chaque magasin avec quota, chaque flux qui partage de la bande passante est un candidat à devenir le goulot d'étranglement que quelqu'un cherchera.

Élévation de privilèges : faire ce qu'on ne peut pas

L'élévation de privilèges, c'est accéder à des ressources sans permission : extraction de données en exploitant des faiblesses dans la logique ou la mémoire du contrôle d'entrée, recherche et usage de comptes privilégiés. La source avertit que cette catégorie s'utilise souvent en combinaison avec l'usurpation et l'altération, et c'est pourquoi l'élément en risque se modélise centré sur le processus, avec ses interactions processus-processus, processus-entité externe et processus-magasin. Le contrôle est l'autorisation : mécanismes qui vérifient les permissions de données et de ressources, exécuter le service avec le moins d'accès possible et supervision de l'accès pour détecter des anomalies ; les contrôles courants incluent ACL, contrôle d'accès basé sur les rôles (RBAC), accès basé sur les groupes, permissions et validation d'entrée.

Un seul contrôle, plusieurs menaces

L'avertissement qui ferme la boucle : un seul contrôle peut réduire plusieurs menaces à la fois. TLS/SSL crée des canaux sécurisés contre l'altération et la divulgation ; l'élévation de privilèges, combinée à l'usurpation et l'altération, se contrecarre en partie avec le même ensemble de contrôles. Les comptables de sécurité appellent ça défense en profondeur, et l'effet pratique est que la première mitigation que vous implémentez rapporte pour plus d'une catégorie du tableau.

La liste qui sort d'un passage complet a une forme reconnaissable : des menaces groupées par catégorie, chacune avec ses éléments en risque et son contrôle associé, et quelques contrôles répétés sur plus d'une ligne. Ces répétés sont les candidats à implémenter d'abord, parce que ce sont ceux qui paient deux fois. Et les catégories qui restent vides informent aussi : une catégorie sans menaces dans un système qui manipule des données classifiées mérite un second regard avant de signer le « sans constat ».

flowchart LR
    S[Usurpation] --> A[Authentification]
    M[Altération] --> I[Intégrité]
    R[Déni] --> NR[Non-répudiation]
    D[Divulgation] --> C[Confidentialité]
    DoS[Déni de service] --> D2[Disponibilité]
    E[Élévation de privilèges] --> AU[Autorisation]

En clair : chaque menace du tableau a son contrôle assigné, et la liste de menaces de votre DFD devient une liste de contrôles avec leur propre nom.

Au-delà de STRIDE

STRIDE n'est pas le seul cadre. La source mentionne LINDDUN, une méthodologie de modélisation de menaces de confidentialité pour trouver et résoudre des menaces de confidentialité dans les architectures logicielles, et les arbres d'attaque pour les équipes de test de pénétration, qui aident à déterminer comment une attaque pourrait se produire avec une mentalité de « violation supposée », ainsi que la chaîne d'élimination cybernétique, qui décrit les tactiques, techniques et procédés des attaquants. La fermeture de la source est sobre : STRIDE reste le cadre que Microsoft utilise traditionnellement pour trouver des problèmes de conception de sécurité, et le fait qu'il coexiste avec d'autres cadres ne l'affaiblit pas : il couvre le problème le plus fréquent, qui est la conception de sécurité d'un nouveau système.

La différence de mandat entre cadres est la clé pour choisir : STRIDE couvre la conception complète du système ; les arbres d'attaque assument une violation et tracent comment elle arriverait ; LINDDUN met le foc sur les données personnelles. Une équipe peut lancer STRIDE à chaque nouvelle conception et laisser les arbres d'attaque pour le système qui soutient déjà l'entreprise.

De la lecture à l'exécution

Ce parcours a été de lecture : je n'ai pas appliqué STRIDE à un vrai DFD. Ce que la source rend clair, c'est le cadre complet, catégorie par catégorie, avec ses contrôles ; ce qui manque, c'est la pratique, parce que c'est là qu'apparaissent les vrais doutes : combien de menaces sortent d'un DFD de deux services, lesquelles des six catégories restent vides sans que ça signifie qu'on est à l'abri, et comment on documente une menace sans contrôle peu coûteux. Le premier pas est mécanique : prenez un DFD dessiné et posez les six questions du tableau sur chaque flèche qui croise une limite de confiance.

---

*Source : le module « Use a framework to identify threats and find ways to reduce or eliminate risk » de Microsoft Learn.*