Les participants construisent une vue de sécurité du système, identifient les menaces crédibles et les chemins de mésusage, choisissent des réponses et vérifient si les exigences résultantes sont adéquates. Elle est le plus utile tôt dans la conception et doit évoluer avec le système.
Le modèle peut couvrir les actifs, les utilisateurs, les flux de données, les dépendances, les frontières de confiance, les privilèges, les hypothèses et les adversaires potentiels. Les équipes peuvent employer des méthodes comme STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service et Elevation of Privilege), les arbres d'attaque, les cas de mésusage ou des approches centrées sur le risque ; aucune méthode unique ne convient à tous les systèmes.
Points clés
Questions centralesQue construisons-nous, que peut-il mal se passer, qu'allons-nous y faire, et avons-nous assez bien examiné le système et les réponses ?
Sorties utilesDiagrammes ou autres modèles du système, hypothèses documentées, scénarios de menace priorisés, exigences de sécurité, responsables, risques acceptés et critères de validation testables.
Pratique de travailImpliquer l'ingénierie, les opérations, le produit, la vie privée, la sûreté et les parties prenantes du domaine selon le cas, puis réviser le modèle quand l'architecture, les dépendances, les données, l'usage ou les menaces changent.
Limite importanteUn modèle de menace reflète son périmètre, ses participants, ses preuves et ses hypothèses ; il ne peut énumérer chaque attaque future. Il ne scanne pas les systèmes en cours, ne prouve pas la qualité de l'implémentation et ne remplace ni la revue de code, ni les tests de sécurité, ni la supervision opérationnelle.