# Un modèle de menace pratique pour votre projet hébergé | SwissOctet Insights https://swissoctet.com/fr/insights/threat-model-a-hosted-project/ SwissOctet / Analyses / Opérations du deuxième jour Opérations du deuxième jour Appliqué · 6 min de lecture Un modèle de menace pratique pour votre projet hébergé Cartographiez les actifs et les frontières de confiance, choisissez quelques scénarios de défaillance réalistes et transformez-les en contrôles que vous pouvez tester. Par SwissOctet Editorial Enregistrer le guide Copier le lien SUR CETTE PAGE 01 Définir un périmètre assez restreint pour raisonner 02 Tracer les endroits où la confiance change 03 Choisir des scénarios de défaillance concrets 04 Prioriser selon l'impact et un chemin crédible 05 Tester les contrôles dans un environnement autorisé 06 Garder le modèle connecté aux changements Votre liste de contrôle pratique Sources et lectures complémentaires Retour à la bibliothèque LA RÉPONSE DIRECTE 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. 01 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. 02 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. 03 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 04 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. 05 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. 06 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. PASSEZ À L'ACTION 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. Télécharger la liste de contrôle QUESTIONS FRÉQUENTES 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. RÉFÉRENCES PRINCIPALES 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. CONNECTEZ LES CONNAISSANCES Infrastructure associée. Vector VPS Suisse Metal Atlas Suisse Canvas Web Suisse GARDEZ LE FIL Vos prochaines notes de terrain. Explorez tous les guides NOTE DE TERRAIN / 01 + Opérations du deuxième jour Appliqué Construisez une sauvegarde que vous pouvez réellement restaurer Choisissez un objectif de récupération, protégez une copie indépendante et entraînez-vous à la restauration avant qu'un incident ne force la décision. 4 min de lecture Lire le guide NOTE DE TERRAIN / 02 + Opérations du deuxième jour Appliqué Administration sécurisée de Windows RDP sans perdre l'accès Séparez l'accessibilité réseau, l'authentification et les privilèges, puis vérifiez une voie de récupération avant de restreindre l'accès distant. 6 min de lecture Lire le guide NOTE DE TERRAIN / 03 + Opérations du deuxième jour Appliqué Une base de durcissement Linux VPS que vous pouvez maintenir Sécurisez l'administration, n'exposez que les services requis et établissez les mises à jour et la récupération sans vous verrouiller dehors. 6 min de lecture Lire le guide