Étape 1 - Conception
La phase de conception marque le début de vos activités de modélisation des menaces. Collectez le plus de données possible sur ce que vous créez et sur ce que vous utilisez pour le créer.
Objectifs
- Établir une image claire du fonctionnement de votre système
- Lister tous les services consommés par votre système
- Énumérer toutes les hypothèses sur l’environnement et les configurations de sécurité par défaut
- Créer un diagramme de flux de données qui utilise le bon niveau de profondeur de contexte
Important
Si vous n’effectuez pas cette phase, vous risquez de négliger des points importants sur la conception de la sécurité pour votre système, ce qui peut exposer vos clients à des risques.
Poser des questions sur votre système
Posez le plus de questions possible sur votre système. Voici quelques questions à prendre en compte :
Domaine | Questions |
---|---|
Description du système | Que fait le système ? Quels sont les processus métier gérés par le service ? Sont-ils clairement définis ? |
Environnement du système | Le système est-il créé dans le cloud ou en local ? Sur quel système d’exploitation est-il créé ? Utilise-t-il des conteneurs ? Le système est-il une application, un service ou quelque chose de totalement différent ? |
Scénarios | Pour quoi le système sera-t-il utilisé ? Pour quoi le système ne sera-t-il pas utilisé ? |
Autorisations | Le système a-t-il des exigences en matière d’exécution des scripts, de données ou d’accès au matériel ? Si oui, quelles sont-elles ? |
Fournisseur de cloud | Quel est le fournisseur de cloud utilisé par le système ? Quelles options de configuration de sécurité par défaut le fournisseur propose-t-il ? En quoi ces options affectent-elles les exigences de sécurité du système ? |
Système d’exploitation | Quel système d’exploitation utilisera le système ? Quelles options de configuration de sécurité par défaut le système d’exploitation propose-t-il ? En quoi ces options affectent-elles les exigences de sécurité du système ? |
Services internes et tiers | Quels services internes et tiers va utiliser le système ? Quelles options de configuration de sécurité par défaut offrent-ils ? En quoi ces options affectent les exigences de sécurité du système ? |
Comptes | Quels types de comptes sont utilisés par le système, comme les utilisateurs et les administrateurs ? Ces comptes sont-ils locaux ou dans le cloud ? De quel accès ont-ils besoin et pourquoi ? |
Contrôle des identités et des accès | Comment le système aide-t-il à sécuriser ces comptes ? S’appuie-t-il sur Microsoft Entra ID ? Utilise-t-il des fonctionnalités telles que les listes de contrôle d’accès (ACL), l’authentification multifacteur (MFA) et le contrôle de session ? |
Jetons et sessions | Le système traitera-t-il les requêtes comme SOAP ou les API REST ? Comment gère-t-il différentes sessions ? |
Contournement | Le système va-t-il utiliser ou nécessiter des portes dérobées ? Le cas échéant, comment fonctionne ce contournement ? |
Journalisation, supervision et sauvegarde | Quels mécanismes le système utilise-t-il pour journaliser les événements de sécurité, rechercher les anomalies et sauvegarder les données système ? Quels types d’événements capture-t-il ? |
Réseau | Quels systèmes de détection des intrusions et de protection va-t-il utiliser ? Comment la communication est-elle chiffrée ? |
Données | Quel type de données le système va-t-il créer ou gérer ? Quel sera le type de classification des données ? Comment le système approuve-t-il les sources de données ? Comment analyse-t-il les données ? Quels sont les comportements d’entrée et de sortie attendus ? Comment la validation est-elle gérée ? Comment les données sont-elles chiffrées dans tous les états ? |
Gestion des secrets | Comment le système gère-t-il les clés, les certificats et les informations d’identification ? |
Important
Cette liste est longue, mais pas exhaustive. Discutez avec vos collègues et votre équipe de sécurité pour réunir tout le contexte approprié pour le système.
Notes
Si vous avez une équipe de sécurité dédiée, planifiez une session avec elle pour revoir la conception initiale. Ce contact peut vous permettre de gagner un temps considérable.
Créer un diagramme de flux de données
Utilisez les réponses pour créer un diagramme de flux de données. Votre diagramme montre les données à chaque étape de leur cycle de vie et comprend les changements apportés aux zones d’approbation. Voici quelques exemples :
- Des utilisateurs humains se connectent à votre application web hébergée dans Azure pour accéder aux données
- Des administrateurs modifiant les configurations de sécurité par défaut pour les ressources élastiques utilisées par l’application web
- Des scripts quotidiens automatisés supervisent les journaux d’activité de l’application web et notifient les administrateurs en cas d’anomalie
Les équipes d’ingénierie Microsoft envoient des diagrammes de flux de données dans le cadre de leurs exigences de conformité de la sécurité. Avec ces diagrammes, les conversations sur la sécurité sont plus faciles à mener.
Outils de création de diagrammes
Les ingénieurs Microsoft recommandent d’utiliser l’un des deux outils actuellement disponibles :
- Threat Modeling Tool
- Visio
Éléments de diagramme
Un diagramme de flux de données montre le flux des données d’un système. Il commence généralement avec des demandes provenant d’utilisateurs ou de magasins de données et se termine avec des magasins de données ou des services d’analytique. Le diagramme de flux de données utilise des formes distinctes pour indiquer les éléments qu’il représente.
Élément | Forme | Définition |
---|---|---|
Processus | Tâche qui reçoit une entrée, la modifie ou la redirige vers la sortie, comme un service web. | |
Magasin de données | Stockage de données permanent et temporaire, comme un cache web et des bases de données managées par Azure. | |
Entité externe | Tâche, entité ou magasin de données hors de votre contrôle direct, comme les utilisateurs et les API tierces. | |
Flux de données | Déplacement de données entre les processus, magasins de données et entités externes, comme les chaînes de connexion et les charges utiles. | |
Limite de confiance | Évolutions de la zone de confiance à mesure que les données transitent dans le système, comme les utilisateurs qui se servent d’Internet pour accéder à un réseau d’entreprise sécurisé. |
Les éléments du diagramme de flux de données ont également besoin de contexte pour aider quiconque à comprendre comment ils sont utilisés et sécurisés dans le système.
Informations à inclure dans le diagramme de flux de données
La quantité d’informations à inclure dans le diagramme de flux de données dépend de quelques facteurs clés :
Facteur | Explication |
---|---|
Type de système que vous êtes en train de créer | Les systèmes qui ne gèrent pas de données sensibles ou qui ne sont utilisés qu’en interne peuvent ne pas avoir besoin d’autant de contexte qu’un système externe |
Contexte demandé par votre équipe de sécurité | Les équipes de sécurité sont précises dans ce qu’elles recherchent dans les modèles de menaces. Parlez avec votre équipe de sécurité pour confirmer la couche de profondeur requise. |
Si vous n’incluez pas le bon contexte, les révisions de sécurité seront incomplètes et les systèmes potentiellement vulnérables.
Couches de diagramme
Pour vous aider à comprendre la quantité d’informations à inclure, choisissez entre ces quatre couches de profondeur de contexte :
Couche de profondeur | Titre | Description |
---|---|---|
0 | Système | Point de départ de tout système. Un diagramme de flux de données contient les principales parties du système avec suffisamment de contexte pour vous aider à comprendre comment elles fonctionnent et interagissent. |
1 | Processus | Concentrez-vous sur les diagrammes de flux de données pour chaque partie du système en utilisant d’autres diagrammes de flux de données. Utilisez cette couche pour chaque système, en particulier s’il gère des données sensibles. Le contexte sur cette couche vous aide à identifier les menaces et les moyens d’atténuer ou d’éliminer les risques plus efficacement. |
2 | Sous-processus | Concentrez-vous sur les diagrammes de flux de données pour chaque sous-partie d’une partie du système. Utilisé pour les systèmes considérés critiques. Il peut notamment s’agir de systèmes pour environnements sécurisés, de systèmes qui gèrent des données hautement sensibles ou des systèmes exposés à un niveau de risque élevé. |
3 | Niveau inférieur | Concentrez-vous sur les systèmes très critiques et de niveau noyau. Les diagrammes de flux de données décrivent chaque sous-processus dans les moindres détails. |
Notes
La plupart des diagrammes de flux de données doivent contenir des couches de profondeur 0 et 1. Vérifiez auprès de votre équipe de sécurité quelle est la couche de profondeur indispensable.