Modélisation des menaces : architecture, scénarios d’attaque et mesures de sécurité
Sytance · Mis à jour
La modélisation des menaces est une méthode structurée pour identifier comment un produit pourrait être attaqué et choisir des mesures de réduction des risques. L’analyse part de l’architecture du produit et explique comment une attaque pourrait réussir, ce qu’elle affecterait et comment vérifier la protection proposée.
Version du produit et déploiement
Un modèle de menace s’applique à une version et à un déploiement précis du produit. Une passerelle connectée à Internet et la même passerelle sur un réseau de maintenance isolé peuvent présenter des points d’entrée et des hypothèses d’exploitation différents.
Faites participer les personnes qui connaissent l’architecture, le développement, l’utilisation du produit et la sécurité. Avant la séance, rassemblez suffisamment d’informations pour expliquer le fonctionnement normal du début à la fin.
- La version, le déploiement pris en charge et les utilisateurs prévus.
- L’architecture, les interfaces externes et les données échangées.
- Les privilèges de chaque utilisateur, service et processus local.
- Les données sensibles, identifiants et fonctions du produit à protéger.
- Les contrôles existants et les hypothèses qui doivent encore être confirmées.
Flux de données et limites de confiance
Un diagramme de flux de données (DFD) présente les entités externes, processus, magasins de données et mouvements de données. Une limite de confiance indique un changement de niveau de confiance ou d’autorité. Elle peut exister entre un navigateur et une API, entre deux comptes du système d’exploitation ou entre un appareil et un service distant.
Attribuez à chaque flux une direction, une description des données et un mécanisme de protection. Une boîte intitulée « cloud » masque trop de détails si plusieurs services ont des identités et des autorisations différentes. Divisez-la lorsque cette différence change l’analyse.
Pour l’exemple de la passerelle industrielle, commencez par le navigateur de l’opérateur, l’API de gestion de la passerelle, le magasin de configuration local, le contrôleur local, le service de télémétrie et le service de mise à jour. Représentez la gestion et la télémétrie comme des connexions TLS. Considérez la vérification de la signature des mises à jour comme une mesure proposée tant que sa mise en œuvre n’est pas établie.
Des catégories STRIDE aux scénarios d’attaque
STRIDE regroupe les menaces en usurpation d’identité, falsification, répudiation, divulgation d’informations, déni de service et élévation de privilèges. Utilisez ces catégories pour susciter des questions sur chaque processus et flux pertinent. Le nom d’une catégorie ne décrit pas à lui seul une attaque.
Par exemple : un utilisateur disposant d’un accès en lecture envoie directement une demande de modification de configuration à l’API de gestion. Si l’API vérifie la connexion, mais pas le droit d’effectuer cette action, l’utilisateur peut modifier la configuration de la passerelle. Cela identifie un acteur, un point d’entrée, un contrôle manquant et un impact.
Reliez chaque scénario à l’interface, au processus ou au flux pertinent du diagramme. Les scénarios présentant des conditions d’attaque ou des contrôles différents nécessitent une analyse distincte. Si une condition est inconnue, par exemple l’authentification sur l’interface du contrôleur, consignez ce qui doit être confirmé.
Priorités de risque et mesures de sécurité
Les priorités de risque dépendent de l’accès et des capacités nécessaires à l’attaquant, de la probabilité de réussite et des conséquences pour le produit. Une méthode de risque convenue rend ces jugements cohérents. La justification d’une note permet à d’autres de l’examiner.
Choisissez une réponse que l’équipe peut mettre en œuvre. Pour le scénario de modification de configuration, l’API doit vérifier les autorisations de l’appelant lors de chaque opération d’écriture. Désignez un responsable, une version cible et un contrôle permettant de vérifier l’efficacité de la mesure.
Le TLS existant protège une connexion de transport ; il ne prouve pas qu’un utilisateur connecté peut modifier la configuration. Évaluez la mesure par rapport à l’étape d’attaque précise qu’elle doit empêcher. Si l’équipe accepte un risque résiduel, consignez la raison et la personne autorisée à prendre cette décision.
Vérification et mise à jour du modèle
Une mesure proposée et une mesure vérifiée correspondent à des états différents. Reliez une mesure mise en œuvre à la modification concernée et à son résultat de vérification. Pour l’exemple de l’API, envoyez une demande d’écriture avec un utilisateur en lecture seule et confirmez son rejet ainsi que l’absence de changement de configuration.
Réexaminez le modèle lorsqu’une interface, une autorisation, un composant, un déploiement ou un mécanisme de mise à jour change. De nouvelles informations sur une vulnérabilité peuvent également invalider une hypothèse précédente. Conservez le modèle antérieur pour que l’équipe puisse préciser les versions auxquelles une décision s’appliquait.