SEC01-BP07 Identifier les menaces et hiérarchiser les atténuations à l’aide d’un modèle de menaces
Effectuez une modélisation des menaces pour identifier et gérer un registre actualisé des menaces potentielles et des mesures d’atténuation connexes pour votre charge de travail. Hiérarchisez vos menaces et adaptez vos atténuations des contrôles de sécurité pour les prévenir, les détecter et y répondre. Ajustez et maintenez ces mesures en fonction de votre charge de travail et de l’évolution de l’environnement de sécurité.
Niveau d’exposition au risque si cette bonne pratique n’est pas établie : élevé
Directives d’implémentation
Qu’est-ce que la modélisation des menaces ?
« La modélisation des menaces permet d’identifier, de communiquer et de comprendre les menaces et les atténuations dans le contexte de la protection de quelque chose de valeur. » – The Open Web Application Security Project (OWASP) Application Threat Modeling
Quel est l’intérêt de la modélisation des menaces ?
Les systèmes sont complexes et deviennent de plus en plus complexes et compétents au fil du temps, offrant plus de valeur opérationnelle, ainsi qu’une satisfaction et un engagement client accrus. Cela signifie que les décisions de conception informatique doivent tenir compte d’un nombre toujours croissant de cas d’utilisation. Cette complexité et ce nombre de permutations des cas d’utilisation nuisent généralement à l’efficacité des approches non structurées pour trouver et atténuer les menaces. Dans ces conditions, il est préférable d’adopter une approche systématique pour recenser les menaces potentielles qui pèsent sur le système, concevoir les atténuations et d’établir la priorité de ces atténuations afin de veiller à ce que les ressources limitées de votre organisation aient un impact maximal sur l’amélioration de la posture de sécurité globale du système.
La modélisation des menaces est conçue pour fournir cette approche systématique, dans le but de trouver et de régler les problèmes au début du processus de conception, lorsque les atténuations impliquent un coût relatif et des efforts limités par rapport à plus tard dans le cycle de vie. Cette approche est conforme au principe de sécurité shift left
Quand la modélisation des menaces doit-elle être effectuée ?
Commencez la modélisation des menaces le plus tôt possible dans le cycle de vie de votre charge de travail, afin de bénéficier de plus de flexibilité pour la gestion des menaces identifiées. Comme pour les bogues logiciels, plus vous identifiez les menaces rapidement, plus leur résolution est économique. Un modèle de menace est un document évolutif et il doit continuer à évoluer avec vos charges de travail. Revoyez vos modèles de menaces au fil du temps, y compris lorsqu’il y a un changement majeur, une évolution du contexte des menaces ou lorsque vous adoptez une nouvelle fonctionnalité ou un nouveau service.
Étapes d’implémentation
Comment pouvons-nous modéliser les menaces ?
Il existe de nombreuses façons de modéliser les menaces. Comme pour les langages de programmation, chaque méthode a ses avantages et ses inconvénients. À vous de choisir celle qui fonctionne le mieux pour votre organisation. Une approche consiste à commencer par le cadre des 4 questions de Shostack pour la modélisation des menaces
-
Sur quoi travaillons-nous ?
Le but de cette question est de vous aider à comprendre et à vous mettre d’accord sur le système que vous créez et les détails associés qui sont pertinents pour la sécurité. La création d’un modèle ou d’un diagramme est la solution la plus populaire pour répondre à cette question, car elle vous aide à visualiser ce que vous créez, par exemple en utilisant un diagramme de flux des données
. Le fait de noter les hypothèses et les détails importants sur votre système vous aide également à définir ce qui est inclus dans le champ d’application. Cela permet à tous ceux qui contribuent au modèle de menaces de se concentrer sur la même chose et d’éviter les détours fastidieux pour étudier des sujets qui ne rentrent pas dans le champ d’application (y compris les versions obsolètes de votre système). Par exemple, si vous créez une application Web, il n’est probablement pas intéressant de consacrer du temps à la modélisation de la séquence de démarrage autorisé du système d’exploitation pour les clients du navigateur, car vous ne pouvez pas avoir un impact sur ce point avec votre conception. -
Quels problèmes pouvez-vous rencontrer ?
C’est là que vous identifiez les menaces qui pèsent sur votre système. Les menaces sont des actions ou des événements accidentels ou intentionnels qui ont des impacts indésirables et pourraient affecter la sécurité de votre système. Sans une compréhension claire de ce qui pourrait poser un problème, vous n’avez aucun moyen de faire quoi que ce soit.
Il n’existe pas de liste standard des problèmes potentiels. La création de cette liste nécessite un brainstorming et une collaboration entre tous les membres de votre équipe et les décideurs pertinents impliqués
dans l’exercice de modélisation des menaces. Vous pouvez faciliter votre brainstorming en utilisant un modèle pour identifier les menaces, par exemple STRIDE , qui suggère différentes catégories à évaluer : Usurpation d’identité, Altération, Répudiation, Divulgation d’informations, Déni de service et Élévation de privilège. De plus, vous pouvez faciliter le brainstorming en examinant les listes et les recherches existantes afin de vous en inspirer, y compris l’OWASP Top 10 , le HiTrust Threat Catalog , ainsi que le catalogue des menaces de votre organisation. -
Qu’allons-nous faire à ce sujet ?
Comme pour la question précédente, il n’existe pas de liste standard avec toutes les atténuations possibles. Lors de cette étape, les informations utilisées sont les menaces, les acteurs et les domaines d’amélioration identifiés par rapport à l’étape précédente.
La sécurité et la conformité sont une responsabilité partagée entre vous et AWS
. Il est important de comprendre que lorsque vous demandez « Qu’allons-nous faire à ce sujet ? », vous demandez également qui est responsable de ce qui doit être fait. En comprenant l’équilibre des responsabilités entre vous-même et AWS, vous pouvez évaluer votre exercice de modélisation des menaces en fonction des atténuations qui sont sous votre contrôle, c’est-à-dire, en règle générale, une combinaison des options de configuration du service AWS et vos propres atténuations spécifiques au système. Pour la partie AWS de la responsabilité partagée, vous constaterez que les services AWS sont couverts par de nombreux programmes de conformité
. Ces programmes vous aident à comprendre les contrôles rigoureux en place chez AWS afin de garantir la sécurité et la conformité du cloud. Les rapports d’audit de ces programmes peuvent être téléchargés pour les clients AWS à partir d’AWS Artifact . Quels que soient les services AWS utilisés, il y a toujours un élément de responsabilité client et les atténuations correspondant à ces responsabilités doivent être incluses dans votre modèle de menaces. En ce qui concerne les atténuations en matière de contrôle de sécurité pour les services AWS eux-mêmes, envisagez l’implémentation de contrôles de sécurité dans tous les domaines, y compris la gestion des identités et des accès (authentification et autorisation), la protection des données (au repos et en transit), la sécurité de l’infrastructure, la journalisation et la surveillance. La documentation de chaque service AWS comporte un chapitre dédié à la sécurité qui fournit des conseils sur les contrôles de sécurité à implémenter à des fins d’atténuation. Il est surtout important de réfléchir au code que vous écrivez et à ses dépendances, ainsi que de penser aux contrôles que vous pourriez mettre en place pour résoudre ces menaces. Ces contrôles peuvent notamment prendre les formes suivantes : validation des entrées
, gestion des sessions et gestion des limites . La plupart des vulnérabilités sont souvent introduites dans le code personnalisé, c’est pourquoi il est important de se concentrer sur ce domaine. -
Avons-nous fait du bon travail ?
L’objectif est que votre équipe et votre organisation améliorent la qualité des modèles de menaces et la vitesse à laquelle vous effectuez la modélisation des menaces au fil du temps. Ces améliorations découlent d’une combinaison de pratique, d’apprentissage, d’enseignement et de révision. Pour approfondir ces notions et vous exercer, votre équipe et vous-même pouvez suivre le cours de formation
ou l’atelier sur les bons principes de modélisation des menaces pour les créateurs. De plus, si vous souhaitez obtenir des conseils sur l’intégration de la modélisation des menaces dans le cycle de développement des applications de votre organisation, consultez la publication How to approach threat modeling sur le Blog de sécurité d’AWS.
Threat Composer
Pour vous aider et vous guider dans la modélisation des menaces, pensez à utiliser l’outil Threat Composer
-
Rédiger des déclarations de menaces utiles, qui respectent la grammaire des menaces
et fonctionnent dans un flux de travail naturel et non linéaire -
Générer un modèle de menaces lisible par l’homme
-
Générer un modèle de menaces lisible par machine pour vous permettre de traiter les modèles de menaces comme du code
-
Identifier rapidement les domaines dans lesquels la qualité et la couverture peuvent être améliorées à l’aide du tableau de bord
Pour en savoir plus, accédez à Threat Composer et basculez vers l’exemple d’espace de travail défini par le système.
Ressources
Bonnes pratiques associées :
Documents connexes :
-
How to approach threat modeling
(Blog de sécurité AWS)
Vidéos connexes :
Formations associées :
Outils associés :
