Uczestnicy budują istotny dla bezpieczeństwa obraz systemu, identyfikują wiarygodne zagrożenia i ścieżki nadużycia, wybierają reakcje i sprawdzają, czy powstałe wymagania są adekwatne. Jest najbardziej użyteczne wcześnie w fazie projektowania i powinno ewoluować razem z systemem.
Model może obejmować zasoby, użytkowników, przepływy danych, zależności, granice zaufania, uprawnienia, założenia i potencjalnych przeciwników. Zespoły mogą stosować metody takie jak STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege), drzewa ataku (attack trees), przypadki nadużycia (misuse cases) lub podejścia skupione na ryzyku; żadna pojedyncza metoda nie jest poprawna dla każdego systemu.
Najważniejsze punkty
Kluczowe pytaniaCo budujemy, co może pójść nie tak, co z tym zrobimy i czy wystarczająco dobrze zbadaliśmy system oraz reakcje?
Użyteczne wynikiDiagramy lub inne modele systemu, udokumentowane założenia, priorytetyzowane scenariusze zagrożeń, wymagania bezpieczeństwa, właściciele, zaakceptowane ryzyka i testowalne kryteria walidacji.
Praktyka pracyAngażuj odpowiednio inżynierię, operacje, produkt, prywatność, bezpieczeństwo fizyczne i interesariuszy domenowych, a model przeglądaj, gdy zmienia się architektura, zależności, dane, użycie lub zagrożenia.
Istotne ograniczenieModel zagrożeń odzwierciedla swój zakres, uczestników, dowody i założenia; nie potrafi wyliczyć każdego przyszłego ataku. Nie skanuje działających systemów, nie dowodzi jakości implementacji ani nie zastępuje przeglądu kodu, testów bezpieczeństwa czy monitoringu operacyjnego.