Modélisation des menaces : transformer l’architecture en décisions de sécurité

La modélisation des menaces consiste à se demander ce qui pourrait mal tourner dans un système donné et ce que l’équipe doit faire pour y remédier. Son résultat utile n’est pas un catalogue de possibilités effrayantes. C’est un ensemble de décisions de conception et de mise en œuvre liées à l’architecture, avec des responsables et des preuves que les défenses retenues fonctionnent.

Pour un CTO, la question centrale est de savoir si l’ingénierie peut expliquer comment les propriétés de sécurité importantes résistent au comportement réel du système : nouvelles tentatives, tâches en arrière-plan, actions privilégiées du support, pannes de fournisseurs et entrées malveillantes. Un schéma rend ces discussions concrètes. Un modèle de menaces tenu à jour transforme les conclusions en travaux de livraison.

Les recommandations de l’OWASP sur la modélisation des menaces offrent une base utile : comprendre le système, identifier les menaces, décider comment y répondre et évaluer si le travail est suffisant. La démarche ci-dessous applique ce raisonnement aux décisions d’ingénierie.

Décrire le système avant de parler d’attaques

Commencez par une fonctionnalité délimitée, comme les exports clients, l’initiation de paiements ou les mises à jour d’appareils. Modéliser une plateforme entière d’un seul coup produit souvent des observations superficielles, car personne ne peut expliquer chaque dépendance avec suffisamment de détail.

Formulez les actifs et les objectifs de sécurité en termes opérationnels. « Protéger les données clients » est trop large. « Un utilisateur authentifié ne peut exporter que les enregistrements appartenant au tenant auquel il est autorisé » donne à l’équipe une propriété à tester. D’autres objectifs peuvent porter sur l’intégrité des transactions, la disponibilité du service, le rétablissement ou l’imputabilité des actions d’administration.

Identifiez les utilisateurs, les services, les magasins de données, les dépendances externes, les points d’entrée et les frontières de confiance. Dessinez les flux de données importants, y compris les traitements asynchrones et les chemins d’administration. Annotez les flux avec les données transportées, le mécanisme d’authentification et le contexte d’autorisation lorsque ces éléments influent sur l’analyse.

Une frontière de confiance marque un changement d’hypothèses ou d’autorité, pas nécessairement un périmètre réseau. Un navigateur qui appelle une API franchit une frontière. Un worker partagé agissant pour le compte d’un client en franchit une autre, même si les deux services s’exécutent dans le même cluster.

Pour une application multi-tenant, montrez où l’identité du tenant est établie et comment elle parvient aux contrôles d’autorisation, aux tâches en arrière-plan et aux exports. Incluez les identités de service, l’accès au stockage d’objets, les outils de support et les callbacks externes. Sinon, le schéma risque de décrire le chemin nominal tout en omettant les chemins les plus susceptibles de contourner l’isolation.

Consignez les hypothèses séparément des faits. « La file d’attente ne peut pas être alimentée par les clients » doit être étayé par des preuves de configuration. Les inconnues doivent devenir des tâches d’investigation, et non des défenses acceptées tacitement.

Choisir une méthode qui aide l’équipe à raisonner

Une méthode fournit des pistes de questionnement et une structure. Elle ne détermine pas quelles menaces comptent le plus, ne prouve pas qu’une conception est sûre et ne remplace pas la connaissance du système.

STRIDE pour un questionnement systématique

STRIDE examine six catégories. Appliquez-les aux composants, flux et frontières pertinents plutôt que d’imposer chaque catégorie à chaque élément du schéma.

Un même scénario peut relever de plusieurs catégories. Conservez alors un seul enregistrement actionnable plutôt que de créer des tickets en double pour satisfaire la taxonomie.

D’autres méthodes pour d’autres questions

PASTA (Process for Attack Simulation and Threat Analysis) propose une approche en sept étapes, orientée risques, qui relie les objectifs métier, le périmètre technique, la décomposition, l’analyse des menaces et des vulnérabilités, la modélisation des attaques et le traitement des risques. Elle convient aux analyses plus approfondies lorsque le comportement des attaquants et les conséquences métier doivent être explicitement pris en compte.

Les arbres d’attaque partent d’un objectif de l’attaquant et le décomposent en chemins alternatifs ou combinés. Pour « obtenir l’export d’un autre tenant », les alternatives peuvent inclure le contournement de l’autorisation de l’API, la confusion du contexte de tenant du worker ou le vol d’un identifiant de téléchargement. Les relations ET représentent des conditions qui doivent être réunies simultanément ; les relations OU représentent des alternatives.

VAST (Visual, Agile, and Simple Threat modeling) met l’accent sur une modélisation qui passe à l’échelle, selon des perspectives applicatives et opérationnelles. Les équipes qui l’envisagent doivent vérifier si leur outillage et leur processus de développement permettent de tenir ces vues à jour de manière cohérente.

Une recommandation pratique pour démarrer consiste à combiner un schéma de flux de données et STRIDE, puis à réaliser un arbre d’attaque pour le scénario le plus lourd de conséquences. Davantage de méthodologie n’est utile que si elle améliore les décisions.

Conduire la revue autour de scénarios concrets

Réunissez les personnes qui comprennent la mise en œuvre et l’exploitation : un développeur, un architecte ou responsable technique, un relecteur sécurité et quelqu’un qui connaît le comportement en production. Associez des spécialistes produit, protection des données ou fournisseurs lorsque leurs connaissances influent sur le périmètre.

Avant la séance, diffusez le schéma, les objectifs de sécurité, la configuration pertinente et les hypothèses non résolues. Pendant la revue, suivez une requête ou un événement de son entrée à son achèvement. Demandez où l’identité change, où les données sont persistées, ce qui fait l’objet de nouvelles tentatives et quel composant a l’autorité pour approuver une action.

Rédigez les menaces sous forme de scénarios, pas d’étiquettes. « Problème d’autorisation » n’est pas assez utile. Une formulation plus solide serait : « Un utilisateur authentifié substitue l’identifiant d’export d’un autre tenant ; le point de terminaison de téléchargement vérifie la connexion mais pas la propriété de l’objet, ce qui expose des dossiers clients. »

Distinguez trois notions :

• Une menace décrit une action ou un événement préjudiciable, comme la récupération non autorisée d’un export.
• Une vulnérabilité est une faiblesse qui pourrait la permettre, comme un contrôle de propriété manquant.
• Le risque prend en compte la vraisemblance et la conséquence du scénario dans l’environnement réel.

Une menace peut mériter d’être examinée avant qu’une vulnérabilité ne soit confirmée. De même, découvrir une faiblesse n’établit pas que toutes les attaques imaginables sont réalisables.

Incluez l’usage abusif par des utilisateurs légitimes, les initiés disposant de privilèges, les erreurs de configuration et les défaillances de fournisseurs, en plus des attaques externes. Demandez ce qui se passe lorsqu’une dépendance dépasse le délai imparti ou renvoie une réponse inattendue. Les comportements en mode « fail-open » et les nouvelles tentatives incohérentes ressortent souvent de ces discussions.

Exemple concret : un pipeline d’export multi-tenant

L’exemple suivant est illustratif. Supposons qu’une application SaaS comporte un client navigateur, une API, une base de données partagée, une file de tâches, un worker d’export et un stockage d’objets. Les utilisateurs des tenants demandent des exports CSV ; le worker génère les fichiers et l’API émet des liens de téléchargement temporaires. Les administrateurs du support disposent d’une interface de dépannage distincte.

Les objectifs de sécurité sont l’isolation des tenants, le déclenchement autorisé des exports, une consommation de ressources bornée et l’imputabilité des actions du support. Supposons que le worker dispose d’un accès à la base de données suffisamment large pour servir plusieurs tenants. Sa gestion du contexte de tenant devient alors une décision centrale plutôt qu’un détail de mise en œuvre mineur.

Suivre l’autorité tout au long du flux

Au niveau de l’API, le principal authentifié est associé à l’appartenance autorisée à un tenant. Un identifiant de tenant fourni par le navigateur est une demande de sélection, pas une preuve d’autorisation. L’API vérifie l’appartenance et le droit d’export avant de créer un enregistrement de tâche immuable contenant le tenant autorisé, le demandeur et le périmètre d’export autorisé.

Le message en file d’attente fait référence à cet enregistrement. Le worker valide la tâche et applique un accès aux données limité au tenant lors de la production de l’export. Les métadonnées de stockage associent l’objet obtenu à la tâche et au tenant. Avant d’émettre un lien de téléchargement, l’API vérifie l’autorisation actuelle du demandeur au regard de cette association.

Cette conception exige encore des décisions explicites sur la révocation des accès : un utilisateur qui perd son appartenance après avoir demandé un export doit-il conserver l’accès au fichier généré ? L’équipe doit définir cette règle et l’appliquer de manière cohérente.

Convertir les scénarios en mesures et en tests

Les liens temporaires introduisent une fenêtre d’exposition résiduelle : selon le mécanisme, leur simple possession peut permettre l’accès jusqu’à l’expiration. L’équipe doit décider si cela est acceptable pour les données concernées ou si les téléchargements doivent passer par un intermédiaire authentifié qui vérifie l’autorisation actuelle.

Ne clôturez pas le modèle après avoir testé uniquement l’API synchrone. Vérifiez les tâches différées, les nouvelles tentatives, les requêtes annulées, les appartenances expirées, les tenants supprimés et les échecs partiels. Par exemple, une tâche relancée ne doit pas réutiliser un objet associé à un autre tenant ni publier comme réussi un export incomplet.

Le livrable obtenu est une architecture examinée, un registre des menaces, des tâches de mise en œuvre et des résultats de vérification liés. Ce n’est pas seulement le schéma.

Hiérarchiser selon l’exposition et les conséquences

Hiérarchisez les scénarios plausibles selon l’exposition, l’impact, les conditions préalables et les défenses existantes. Distinguez une défaillance d’autorisation directement atteignable d’un scénario exigeant plusieurs compromissions non démontrées. Prenez en compte, le cas échéant, les données concernées, l’interruption du service, les conséquences financières, les implications en matière de sûreté et la difficulté du rétablissement.

Utilisez une échelle simple et cohérente si elle aide l’équipe, mais consignez la justification de la cotation. Un score numérique fondé sur des données non expliquées crée une fausse précision. Le CVSS peut éclairer l’évaluation d’une vulnérabilité concrète ; il ne remplace pas la compréhension de l’impact métier ni d’un cas d’abus architectural.

Les choix de traitement comprennent la modification de la conception, la réduction de l’exposition, l’ajout de mesures préventives ou de détection, l’abandon de la fonctionnalité ou l’acceptation du risque restant. Les contrats avec les fournisseurs peuvent répartir les responsabilités, mais ils ne suppriment pas les modes de défaillance techniques.

Le risque résiduel doit avoir un décideur nommément désigné, une justification, une échéance ou un déclencheur de revue, ainsi que d’éventuelles conditions d’exploitation. L’achèvement de l’ingénierie et l’acceptation du risque sont des décisions différentes. Un ticket peut être clos alors qu’un risque significatif subsiste.

Porter le modèle jusque dans la livraison et les preuves

Pour chaque scénario important, consignez son identifiant, les composants concernés, les conditions préalables, la conséquence, les défenses existantes, le traitement, le responsable et la méthode de vérification. Reliez l’enregistrement à la version de l’architecture et aux travaux de mise en œuvre pertinents afin que les relecteurs sachent quelle conception a été évaluée.

Traduisez les traitements en critères d’acceptation testables. « Améliorer le contrôle d’accès » est vague. « Le tenant A ne peut ni demander, ni interroger, ni annuler, ni télécharger l’export du tenant B par aucun point de terminaison pris en charge » identifie un comportement que l’ingénierie peut vérifier.

Utilisez des preuves adaptées à l’affirmation :

• La revue de code peut établir où l’autorisation est appliquée.
• L’inspection de la configuration peut établir les autorisations des services et l’exposition du stockage.
• Les tests d’intégration négatifs peuvent éprouver les frontières entre tenants et entre niveaux de privilèges.
• Les tests de charge et d’injection de fautes peuvent examiner la disponibilité et le comportement en cas de défaillance.
• Des tests d’intrusion ciblés peuvent explorer des chemins d’attaque qui nécessitent un examen indépendant.

Aucun artefact ne prouve à lui seul l’ensemble du modèle. Une capture d’écran d’un paramètre ne prouve pas que chaque worker l’utilise, et un test réussi ne démontre rien sur un chemin non testé. Consignez l’environnement de test, le périmètre, les résultats et les limites.

La modélisation des menaces complète le développement sécurisé, l’évaluation des dépendances, l’analyse de vulnérabilités et les tests d’intrusion. Sa contribution propre est le raisonnement architectural : elle peut révéler une répartition dangereuse de l’autorité même lorsque les composants pris isolément n’ont aucune vulnérabilité connue.

Garder l’outillage et l’automatisation au service du modèle

Un schéma partagé et un registre structuré peuvent suffire pour une première revue ciblée. Des outils dédiés deviennent utiles lorsque les équipes ont besoin de bibliothèques de composants réutilisables, d’identifiants cohérents, de collaboration et de liens fiables entre les menaces et les enregistrements de livraison.

Vérifiez si un outil prend en charge les frontières de confiance, les scénarios personnalisés, l’historique des versions, l’export des enregistrements, les responsabilités et les références aux preuves. Les menaces générées automatiquement sont des pistes à examiner, pas des constats confirmés. De longues listes sans contexte peuvent masquer les quelques décisions qui comptent.

L’assistance de l’IA peut rédiger des descriptions de scénarios, suggérer des chemins manquants ou comparer des changements avec un modèle antérieur. Des relecteurs humains doivent toujours valider l’architecture, la faisabilité, la couverture des mesures d’atténuation et le risque résiduel. Tenez les schémas confidentiels et les identifiants à l’écart des services non approuvés. La génération de modèles de menaces est en outre distincte de la détection à l’exécution ; produire un modèle n’établit ni surveillance continue ni remédiation automatisée.

Réexaminer lorsque l’architecture ou les hypothèses changent

Mettez à jour le modèle lors de nouvelles intégrations, de modifications de l’authentification, d’actions privilégiées, de nouvelles catégories de données, de changements d’exposition réseau et d’évolutions majeures des dépendances. Un incident ou un résultat de test inattendu peut aussi invalider une hypothèse antérieure.

Les différents systèmes appellent des priorités différentes. Les applications cloud exigent une attention particulière aux autorisations des identités et à l’accès au plan de gestion. Les clients mobiles doivent être traités comme des environnements contrôlés par l’attaquant plutôt que comme des points d’application de confiance. Les objets connectés introduisent l’accès physique, l’intégrité des mises à jour, le rétablissement et, potentiellement, des conséquences en matière de sûreté. Les fonctionnalités intégrant de l’IA ajoutent des contenus non fiables et des frontières d’utilisation d’outils ; l’autorisation doit encadrer les actions quel que soit le résultat produit par le modèle.

Mesurez si les flux importants disposent de modèles à jour, si les traitements prioritaires ont des preuves de vérification, si des hypothèses restent non résolues et si des revues de risques acceptés sont en retard. Compter uniquement les menaces récompense le volume plutôt que l’analyse utile. Demandez périodiquement à un relecteur indépendant de remettre en cause un scénario critique et ses preuves.

Faire une première revue assez petite pour être menée à terme

Secani peut préserver le fonctionnement autour de ces décisions en modélisant les systèmes et dépendances pertinents, en désignant des responsables et des relecteurs, et en reliant les preuves aux exigences, aux mesures et aux décisions. Les hypothèses non résolues deviennent des tâches ; les sources et les approbations humaines restent rattachées à la revue. Toute suggestion assistée par l’IA doit être vérifiée avant approbation.

Commencez par un flux de données critique. Suivez son autorité de bout en bout, identifiez quelques scénarios plausibles et terminez avec des traitements attribués et des critères de vérification explicites. Planifiez la revue suivante en fonction des évolutions d’architecture susceptibles d’invalider ces décisions.