Un modèle de menace utile explique ce que vous protégez, qui ou quoi peut l'affecter, où la confiance change et comment vous réduirez et testerez les risques les plus importants. Commencez par le projet réel plutôt que par une liste générique d'outils.
Définir un périmètre assez restreint pour raisonner
Commencez par un service fonctionnel : un portail client, un site de publication ou une application interne. Notez les composants que vous exploitez et les systèmes externes sur lesquels vous vous appuyez. Un modèle de menace doit rendre les hypothèses visibles, sans suggérer que toutes les attaques possibles ont été résolues. Gardez la première version assez petite pour que les personnes qui déploient l'application puissent l'expliquer sans qu'un consultant séparé interprète le schéma.
Listez les résultats et les actifs précieux. Ceux-ci peuvent inclure les données client, l'accès administrateur, l'état des paiements, le contenu publié et la capacité de rétablir le service. La disponibilité peut être un actif même lorsque l'information est publique. Décidez quelles défaillances seraient gênantes et lesquelles nuiraient aux personnes ou à l'organisation. Cette distinction vous aide à prioriser les contrôles au lieu de traiter chaque avertissement de la même manière.
Tracer les endroits où la confiance change
Les recommandations d'OWASP en matière de modélisation des menaces utilisent les flux de données et les frontières de confiance pour rendre une conception compréhensible. Pour une petite application hébergée, dessinez le navigateur, le processus web, la base de données, l'administrateur, la destination de sauvegarde et les intégrations externes. Marquez les informations qui circulent entre eux. Une requête franchissant la frontière d'un client non fiable vers une opération serveur privilégiée mérite une validation et une autorisation explicites.
Ne supposez pas que le fait d'être sur la même machine rend tous les composants également dignes de confiance. Un processus de téléversement public ne devrait pas avoir les mêmes permissions que l'administration de la base de données. Une tâche de sauvegarde peut avoir besoin d'un accès en lecture sans pouvoir modifier les enregistrements de l'application en production. Séparer ces rôles facilite le confinement de l'effet d'un composant compromis et la revue des permissions requises.
Choisir des scénarios de défaillance concrets
Utilisez une poignée d'événements plausibles pour remettre en question la conception. Un attaquant vole un mot de passe administrateur ; un utilisateur demande l'enregistrement d'un autre utilisateur ; un téléversement remplit le disque ; un déploiement expose un fichier de configuration ; une copie de récupération ne peut pas être restaurée. Décrivez la condition de départ, le composant affecté et la conséquence. Un scénario spécifique est plus facile à tester qu'une instruction générale d'améliorer la sécurité.
Incluez les erreurs et l'abus de flux de travail légitimes ainsi que l'intrusion externe. Une nouvelle tentative peut créer deux opérations précieuses, ou deux requêtes peuvent entrer en concurrence pour modifier le même objet. Les recommandations d'OWASP sur la logique métier mettent en évidence ces hypothèses de processus. Vérifiez qui est autorisé à faire passer un flux de travail à l'état suivant et si la répétition ou la réorganisation d'une requête modifie le résultat de manière inattendue.
| Scénario | Contrôle à examiner | Preuves à collecter |
|---|---|---|
| Identifiant d'administration volé | Accès restreint et second facteur lorsque pris en charge | Une connexion non autorisée ne peut pas aboutir |
| Objet d'un autre utilisateur demandé | Autorisation des objets côté serveur | Un test isolé renvoie un résultat refusé |
| Disque saturé par les téléversements | Contrôles de taille, de quota et de conservation | Une limite est appliquée avant la défaillance du service |
| Requête de flux de travail en double | Idempotence et limites de transaction | Une requête répétée crée un seul résultat |
Prioriser selon l'impact et un chemin crédible
Pour chaque scénario, enregistrez son impact potentiel et les conditions nécessaires à sa survenue. Évitez de prétendre qu'un score numérique estimé est une probabilité précise. Vous pouvez toujours distinguer un mot de passe faible exposé à Internet d'un événement local hautement conditionnel. Attribuez un responsable et une prochaine étape pratique aux risques importants afin que le modèle crée un travail que quelqu'un peut réellement accomplir.
Tenez compte du cycle de vie des informations ainsi que de la compromission de l'application. Un export de diagnostic peut divulguer des données inutiles lors d'un fonctionnement par ailleurs normal. Un champ de compte conservé peut créer une exposition longtemps après la fin de sa finalité. L'examen de la confidentialité peut donc supprimer des informations ou raccourcir la conservation, tandis que l'examen de sécurité restreint l'accès à ce qui reste. Les deux changements ont leur place dans le modèle lorsqu'ils protègent le projet.
Tester les contrôles dans un environnement autorisé
Créez un environnement de préproduction avec des permissions représentatives et des enregistrements fictifs. Testez le refus d'accès, les limites de requêtes, les nouvelles tentatives de flux de travail et la récupération. N'utilisez pas de données client réelles lorsqu'un jeu de données synthétique peut démontrer le comportement. L'objectif est de vérifier le contrôle, non de générer un trafic d'attaque impressionnant. Restez dans les systèmes que vous possédez ou que vous êtes explicitement autorisé à évaluer.
Consignez ce qui a réussi, ce qui a échoué et ce qui reste inconnu. Un résultat de scanner peut apporter des preuves, mais ne remplace pas un test des règles métier de l'application. De même, une option de protection réseau ne vérifie pas l'autorisation d'accès aux objets ni la gestion des fichiers secrets. Joignez les résultats utiles au scénario afin que les futurs responsables comprennent pourquoi un contrôle particulier existe.
Garder le modèle connecté aux changements
Réexaminez les parties concernées lorsque vous ajoutez une intégration, exposez un nouveau point de terminaison, modifiez un privilège ou déplacez des données vers une autre destination. Vous n'avez pas besoin de redessiner toute l'architecture pour une simple modification de texte. Le déclencheur est un changement d'hypothèse sur l'accès, l'information ou le comportement du système. Conservez le modèle à côté de la documentation de déploiement et de reprise, plutôt que de le laisser comme résultat d'un atelier ponctuel.
SwissOctet fournit un catalogue de choix d'infrastructure, et non un modèle de menaces applicatif complet. Choisissez la configuration et les options qui soutiennent vos contrôles, puis vérifiez le déploiement que vous construisez. Un petit modèle maintenu avec des actions testées est plus utile qu'une vaste collection de produits de sécurité sans explication claire des risques qu'ils traitent.
Votre liste de contrôle pratique.
- Listez les actifs et les conséquences d'une défaillance.
- Dessinez les flux de données et les frontières de confiance.
- Choisissez des scénarios précis d'intrusion, d'erreur et de flux de travail.
- Attribuez des contrôles et des responsables aux risques importants.
- Testez avec des données synthétiques dans un environnement autorisé.
- Réexaminez le modèle lorsqu'une hypothèse pertinente change.
Les détails qui comptent.
Ai-je besoin d'un cadre formel pour commencer ?+
Non. Un petit diagramme et un ensemble documenté de scénarios peuvent être utiles. Un cadre aide à garantir que vous examinez les risques de manière cohérente.
Un scanner de vulnérabilités remplace-t-il la modélisation des menaces ?+
Non. Les scanners peuvent trouver des faiblesses techniques, tandis qu'un modèle de menaces examine aussi les hypothèses de conception, les permissions et les flux de travail métier.
À quelle fréquence dois-je mettre à jour le modèle ?+
Mettez à jour les parties concernées lorsque les flux de données, les intégrations, les privilèges ou les fonctionnalités exposées changent, et réexaminez régulièrement les risques non résolus.
Allez à la source.
Ces références soutiennent les concepts techniques de ce guide. Suivez la documentation actuelle avant de modifier un système de production.
- OWASP : Aide-mémoire sur la modélisation des menaces cheatsheetseries.owasp.org
- OWASP : La modélisation des menaces en pratique devguide.owasp.org
- OWASP : Sécurité de la logique métier cheatsheetseries.owasp.org
Conseils éditoriaux par SwissOctet. Les exemples sont illustratifs. Les spécifications de service, les options disponibles et les conditions contractuelles doivent être vérifiées séparément.