Modélisation des menaces avec STRIDE pour des systèmes réels

La modélisation des menaces est la discipline consistant à réfléchir à la façon dont un système peut échouer face à un adversaire avant que cet adversaire ne fasse la réflexion à votre place. STRIDE, un moyen mnémotechnique que Microsoft a popularisé au début des années 2000, reste l'une des manières les plus durables de structurer cette réflexion, car il se projette proprement sur les propriétés qui comptent vraiment pour un défenseur. Cet article parcourt STRIDE du point de vue de la blue team : comment mener une session de modélisation sur un système de production réel, comment chaque catégorie se projette sur des signaux de détection concrets, et comment transformer les constats en travail de durcissement qui survit au contact d'un environnement en fonctionnement. L'objectif n'est pas de produire un joli diagramme qui décore un wiki, mais de changer ce que vous surveillez et ce que vous construisez.

Ce que signifie réellement STRIDE#

STRIDE est un acronyme pour six catégories de menace : Usurpation (se faire passer pour quelqu'un ou quelque chose que l'on n'est pas), Altération (modification non autorisée de données ou de code), Répudiation (nier une action sans que le système puisse prouver le contraire), Divulgation d'information (exposition de données à ceux qui ne devraient pas les voir), Déni de service (dégrader ou supprimer la disponibilité) et Élévation de privilèges (obtenir des capacités au-delà de celles accordées). Chaque catégorie est le miroir d'une propriété de sécurité que vous voulez préserver : authentification, intégrité, non-répudiation, confidentialité, disponibilité et autorisation. Cette symétrie rend STRIDE utile. Lorsque vous trouvez une menace, vous savez déjà quelle propriété elle attaque et donc quelle classe de contrôle la défend.

Comment se déroule une session de modélisation en pratique#

Une session utile commence par un diagramme de flux de données, non par un diagramme réseau. Vous dessinez les entités externes (utilisateurs, services tiers), les processus (vos services et workers), les magasins de données (bases de données, caches, stockage d'objets) et les flux entre eux. Puis vous dessinez les frontières de confiance : les lignes qu'une requête franchit lorsqu'elle passe d'une zone moins fiable à une zone plus fiable, comme la limite entre l'internet public et votre passerelle, ou entre une API orientée locataire et un service interne. C'est aux frontières de confiance que STRIDE gagne sa place, car presque toute menace intéressante vit sur un franchissement de frontière. Pour chaque élément et chaque flux, vous demandez lesquelles des six catégories s'appliquent et vous consignez la réponse comme une affirmation concrète et testable plutôt que comme une inquiétude vague.

Appliquer les catégories à un franchissement de frontière#

Considérez une requête arrivant à un point de terminaison d'API authentifié. L'usurpation demande si un attaquant peut présenter un jeton qui n'est pas le sien ; la défense est la validation complète du jeton, y compris signature, expiration, audience, émetteur et une liste blanche d'algorithmes. L'altération demande si le corps de la requête ou un enregistrement stocké peut être modifié en dehors des règles ; la défense est la validation côté serveur et la persistance paramétrée. La répudiation demande si vous pourriez prouver plus tard qui a fait quoi ; la défense est un journal d'audit en ajout seul avec un identifiant de trace. La divulgation d'information demande si les messages d'erreur, les réponses verbeuses ou les lectures inter-locataires fuient des données ; le déni de service demande si un corps illimité ou une requête coûteuse peut épuiser les ressources ; et l'élévation de privilèges demande si un appelant à faible privilège peut atteindre une action privilégiée, la racine classique des failles d'autorisation comme les références directes d'objet non sécurisées.

Surface d'attaque et où se concentrer#

Tous les éléments ne méritent pas la même attention. Les cibles de plus grande valeur sont les frontières de confiance qui séparent les locataires, les frontières qui séparent le trafic non authentifié de l'authentifié, et tout processus qui détient un secret ou peut agir au nom d'autrui. Dans les systèmes multi-locataires, la question la plus précieuse est de savoir si un identifiant de locataire est jamais pris depuis une entrée contrôlée par le client plutôt que depuis un jeton vérifié, car une seule faille de ce type fait s'effondrer tout le modèle d'isolation. Concentrez votre budget de modélisation sur les flux qui portent les décisions d'identité et d'autorisation, et traitez les flux purement internes au sein d'une même zone de confiance comme moins prioritaires, sauf s'ils touchent des secrets ou des données de masse.

Signaux de détection projetés sur STRIDE#

La modélisation des menaces n'est défensive que si elle change votre télémétrie. L'usurpation se projette sur les journaux d'authentification : échecs répétés de validation de jeton, jetons présentés après expiration et connexions depuis des géographies improbables. L'altération se projette sur la surveillance d'intégrité : vérifications d'intégrité de fichiers sur les binaires et la configuration, déclencheurs de base de données ou colonnes d'audit signalant une modification hors bande, et écarts de sommes de contrôle. La répudiation se projette directement sur la complétude de votre journal d'audit ; une lacune dans le journal est elle-même un signal. La divulgation d'information se projette sur la surveillance de sortie et sur des alertes en cas de résultats de requête anormalement grands ou larges. Le déni de service se projette sur les tableaux de bord de latence, de saturation et de taux d'erreur. L'élévation de privilèges se projette sur les événements d'autorisation refusée et, surtout, sur les événements d'autorisation accordée pour les actions sensibles, qui devraient être assez rares pour être revus.

Atténuation et mesures de durcissement#

Chaque catégorie STRIDE possède une famille de contrôles bien comprise. Contre l'usurpation : authentification forte, multifacteur pour les humains, TLS mutuel ou requêtes signées entre services, et identifiants de courte durée. Contre l'altération : validation d'entrée sur le serveur, requêtes paramétrées, signature de code et infrastructure immuable. Contre la répudiation : journalisation centralisée et infalsifiable avec horloges synchronisées. Contre la divulgation d'information : chiffrement en transit et au repos, accès aux données au moindre privilège, rédaction du détail d'erreur interne avant qu'il n'atteigne un client, et examen soigneux de ce que renvoie toute réponse 5xx. Contre le déni de service : plafonds de taille de requête, limites de pagination, délais d'expiration sur chaque appel sortant, files bornées et limitation de débit en périphérie. Contre l'élévation de privilèges : autorisation décidée sur le serveur à partir d'une identité vérifiée, politiques de refus par défaut et vérifications au niveau de l'objet sur chaque route par identifiant.

Pièges courants qui vident un modèle de menaces#

Le premier piège est de modéliser l'architecture que l'on souhaiterait avoir plutôt que celle qui est déployée ; vérifiez sur le système en fonctionnement, non sur le document de conception, car la dérive est universelle. Le deuxième est de s'arrêter au diagramme et de ne jamais convertir les menaces en travail suivi avec responsables et échéances. Le troisième est de traiter STRIDE comme une liste à cocher une seule fois, alors qu'il devrait être réexaminé dès qu'une nouvelle frontière de confiance apparaît, comme une nouvelle intégration ou un nouveau palier de locataire. Le quatrième est de sur-modéliser des flux internes de faible valeur tout en sous-modélisant les chemins d'authentification et d'autorisation qui décident réellement qui peut faire quoi. Le cinquième est de confondre probabilité et gravité et d'ignorer les menaces à fort impact et faible probabilité, comme un pipeline de build compromis.

Une liste de contrôle reproductible#

Menez votre session selon cette séquence. Dessinez le diagramme de flux de données à partir de la réalité. Marquez chaque frontière de confiance. Pour chaque franchissement de frontière, parcourez les six catégories STRIDE et écrivez une affirmation de menace testable. Évaluez chaque menace par impact et probabilité. Pour chaque menace acceptée, nommez un contrôle et, séparément, un signal de détection, car un contrôle dont vous ne pouvez pas observer l'échec est un contrôle auquel vous ne pouvez pas vous fier. Attribuez un responsable et un ticket. Enfin, injectez les signaux de détection dans votre surveillance afin que le modèle produise des alertes, non de simples documents. Recommencez toute la boucle chaque fois que la carte des frontières change.

FAQ : STRIDE est-il encore pertinent pour les systèmes cloud-native et à microservices ?#

Oui, sans doute plus que jamais. Les architectures à microservices multiplient les frontières de confiance, car chaque appel inter-services est un franchissement potentiel, et STRIDE vous donne une manière cohérente de raisonner sur chacun. Le cadre est indépendant du transport : qu'une frontière soit franchie par un appel HTTP, un message dans une file ou un flux gRPC, les mêmes six questions s'appliquent. Ce qui change dans les environnements cloud-native, c'est le volume de frontières, ce qui plaide pour automatiser des parties du processus, comme générer un diagramme de flux de données de base à partir des métadonnées de service.

FAQ : En quoi STRIDE diffère-t-il des arbres d'attaque ou de la kill chain ?#

STRIDE est un cadre de catégorisation qui aide à énumérer les menaces de manière exhaustive contre un modèle de système ; il répond à la question de ce qui peut mal tourner. Les arbres d'attaque décomposent un seul objectif d'attaquant en étapes et conviennent mieux à la profondeur sur un objectif précis. La cyber kill chain et MITRE ATT&CK décrivent le comportement de l'adversaire au fil d'une campagne et conviennent mieux à l'organisation de l'ingénierie de détection. Ils sont complémentaires : utilisez STRIDE à la conception pour trouver les menaces, ATT&CK en exploitation pour organiser la détection des techniques qui les réalisent, et les arbres d'attaque lorsque vous devez raisonner en profondeur sur une cible de grande valeur.

Conclusion#

STRIDE perdure parce qu'il est assez simple pour être mené dans une salle et assez rigoureux pour changer ce que vous construisez et surveillez. Sa force vient de la projection entre chaque catégorie de menace et à la fois un contrôle et un signal de détection, ce qui transforme un exercice de modélisation abstrait en travail concret de blue team. Modélisez le système réellement déployé, concentrez-vous sur les frontières de confiance qui portent l'identité et l'autorisation, et exigez que chaque menace acceptée produise quelque chose d'observable. Menée ainsi, la modélisation des menaces cesse d'être un rituel de conformité et devient le mécanisme par lequel vos défenses restent au niveau de la façon dont votre système est réellement construit.