Modelowanie zagrożeń: jak znaleźć luki, zanim zrobi to atakujący
Threat modeling to najtańszy sposób na wykrycie błędów projektowych — zanim trafią do kodu. Wyjaśniamy metodę STRIDE, diagramy przepływu danych i praktyczne podejście.
Najdroższa podatność to ta, którą wykrywasz na produkcji. Najtańsza — ta, którą wyłapiesz na tablicy, zanim ktokolwiek napisze linijkę kodu. Modelowanie zagrożeń (threat modeling) to właśnie takie systematyczne zadawanie pytania „co może pójść nie tak?” na etapie projektu. To jedna z najbardziej opłacalnych praktyk bezpieczeństwa — a mimo to wciąż rzadko stosowana poza dużymi organizacjami.
Czym jest modelowanie zagrożeń
Threat modeling to ustrukturyzowana analiza projektu systemu pod kątem tego, kto i jak mógłby go zaatakować oraz co należy z tym zrobić. Nie wymaga działającego kodu ani narzędzi — wystarczy diagram architektury, kilka osób i dyscyplina w zadawaniu właściwych pytań.
Ramą, którą polecił Adam Shostack i którą stosuje się najczęściej, są cztery pytania:
- Nad czym pracujemy? — zrozumienie i zamodelowanie systemu.
- Co może pójść nie tak? — identyfikacja zagrożeń.
- Co z tym zrobimy? — dobór zabezpieczeń.
- Czy dobrze wykonaliśmy zadanie? — weryfikacja i iteracja.
Cała reszta — metody, diagramy, klasyfikacje — to jedynie narzędzia wspierające odpowiedzi na te cztery pytania.
Krok 1: zamodeluj system (diagram przepływu danych)
Punktem wyjścia jest diagram przepływu danych (DFD) — prosty schemat pokazujący, jak informacje wędrują przez system. Cztery podstawowe elementy:
- Procesy — komponenty przetwarzające dane (usługa, API, aplikacja).
- Magazyny danych — bazy, kolejki, pliki, cache.
- Encje zewnętrzne — użytkownicy, systemy trzecie, integracje.
- Przepływy danych — strzałki łączące powyższe.
Kluczowe są granice zaufania (trust boundaries) — linie, które dane przekraczają, zmieniając poziom zaufania: wejście z internetu do aplikacji, z aplikacji do bazy, z Twojego systemu do zewnętrznego API. To właśnie na tych granicach koncentruje się większość ryzyka i to na nich skupia się analiza.
Krok 2: znajdź zagrożenia metodą STRIDE
Najpopularniejszą metodą systematycznego szukania zagrożeń jest STRIDE — akronim sześciu kategorii, z których każda jest przeciwieństwem pożądanej właściwości:
| Kategoria | Zagrożenie | Narusza |
|---|---|---|
| Spoofing | Podszywanie się pod kogoś/coś | Uwierzytelnianie |
| Tampering | Nieuprawniona modyfikacja danych | Integralność |
| Repudiation | Wyparcie się wykonanej akcji | Niezaprzeczalność |
| Information disclosure | Wyciek informacji | Poufność |
| Denial of service | Odmowa usługi | Dostępność |
| Elevation of privilege | Podniesienie uprawnień | Autoryzacja |
Metoda jest prosta: przechodzisz przez każdy element diagramu i pytasz, czy podlega którejś z kategorii. Czy tego użytkownika da się podszyć (S)? Czy ten przepływ danych da się zmodyfikować w tranzycie (T)? Czy ta baza może wyciec (I)? Czy ten endpoint pozwala eskalować uprawnienia (E)? STRIDE nie gwarantuje kompletności, ale skutecznie zmusza do przemyślenia zagrożeń, o których łatwo zapomnieć.
Szczególną uwagę poświęć granicom zaufania — to tam podszycie, manipulacja danymi i eskalacja uprawnień są najbardziej prawdopodobne.
Krok 3: zdecyduj, co zrobić z każdym zagrożeniem
Dla każdego zidentyfikowanego zagrożenia masz cztery możliwe decyzje:
- Ograniczyć (mitigate) — wdrożyć zabezpieczenie redukujące ryzyko. Najczęstszy wybór.
- Wyeliminować (eliminate) — usunąć funkcję lub komponent generujący ryzyko.
- Przenieść (transfer) — przekazać ryzyko innej stronie (np. dostawcy, ubezpieczycielowi).
- Zaakceptować (accept) — świadomie przyjąć ryzyko, jeśli koszt obrony przewyższa potencjalną stratę.
Ważne, by decyzja była świadoma i udokumentowana. „Zaakceptowaliśmy to ryzyko” jest w porządku, o ile ktoś uprawniony faktycznie je rozumiał i przyjął — a nie po prostu przeoczył.
Kiedy modelować zagrożenia
Threat modeling nie jest jednorazowym wydarzeniem, lecz praktyką, którą warto powtarzać:
- Przy projektowaniu nowego systemu lub większej funkcji — wtedy jest najtańszy.
- Przy istotnej zmianie architektury — nowa integracja, migracja do chmury, dodanie kolejki czy nowego magazynu danych zmienia mapę zagrożeń.
- Po incydencie — realny atak to najlepszy powód, by przejrzeć model i sprawdzić, czego zabrakło.
Nie musisz modelować całego systemu naraz. Skuteczniejsze bywa skupienie się na najbardziej krytycznych przepływach — uwierzytelnianiu, obsłudze płatności, przetwarzaniu danych osobowych — i stopniowe rozszerzanie.
Modelowanie zagrożeń a inne warstwy
Threat modeling nie zastępuje testów, lecz je ukierunkowuje. Model powstały na etapie projektu staje się mapą dla późniejszego testu penetracyjnego: tester wie, gdzie są granice zaufania i które przepływy uznano za krytyczne. Z kolei znaleziska z pentestu i z zarządzania podatnościami wracają do modelu i go uaktualniają. To komplementarne warstwy: modelowanie działa „w lewo” (na etapie projektu), testy — „w prawo” (na działającym systemie).
Warto też zauważyć, że część klas zagrożeń z STRIDE mapuje się wprost na OWASP Top 10 — eskalacja uprawnień to Broken Access Control, wyciek informacji to często Security Misconfiguration czy Cryptographic Failures. Modelowanie pomaga wychwycić je, zanim staną się kodem.
Nowy wymiar: zagrożenia w systemach AI
Wraz z wdrożeniami modeli językowych threat modeling zyskuje nową warstwę. Klasyczny STRIDE trzeba uzupełnić o zagrożenia specyficzne dla AI: prompt injection, wyciek danych przez kontekst RAG, nadmiarowe uprawnienia agentów. Granice zaufania przebiegają tu w nieoczywistych miejscach — treść dokumentu, który przeczyta model, staje się potencjalnym wektorem ataku. Piszemy o tym szerzej w artykule Bezpieczeństwo AI w firmie.
Podsumowanie
Modelowanie zagrożeń to najtańsza inwestycja w bezpieczeństwo, jaką można zrobić — bo działa na etapie, na którym poprawka kosztuje minuty, a nie wdrożenie awaryjne. Nie wymaga drogich narzędzi: wystarczy diagram, metoda STRIDE i dyscyplina zadawania czterech pytań. Kluczem jest regularność i skupienie na granicach zaufania.
Jeśli projektujecie system, który będzie przetwarzał wrażliwe dane, i chcecie przeprowadzić modelowanie zagrożeń z udziałem praktyków bezpieczeństwa — albo zweryfikować gotowy projekt — porozmawiajmy. Doradztwo w projektowaniu architektury bezpieczeństwa to jeden z obszarów, w których wspieramy zespoły IT i deweloperskie.
Najczęstsze pytania (FAQ)
Czy modelowanie zagrożeń wymaga specjalistycznych narzędzi? Nie. Można je przeprowadzić na tablicy, w dokumencie albo w darmowym narzędziu do diagramów. Istnieją dedykowane aplikacje (np. do STRIDE), ale to metoda i dyscyplina zadawania pytań, a nie narzędzie, decydują o wartości. Zespół zaczynający przygodę zyska więcej z prostej sesji przy tablicy niż z drogiego oprogramowania.
Kto powinien uczestniczyć w sesji modelowania? Najlepiej połączenie perspektyw: architekt lub deweloper znający system, ktoś z wiedzą o bezpieczeństwie oraz osoba rozumiejąca kontekst biznesowy. Deweloperzy najlepiej znają system, ale mogą nie dostrzegać wektorów ataku — dlatego wartościowy jest udział kogoś, kto myśli jak napastnik.
Czym różni się modelowanie zagrożeń od analizy ryzyka? Modelowanie zagrożeń jest techniczne i konkretne — dotyczy pojedynczego systemu i jego architektury. Analiza ryzyka działa na wyższym poziomie organizacji i procesów. Uzupełniają się: threat modeling dostarcza szczegółowych zagrożeń, które zasilają organizacyjną ocenę ryzyka.
Czy warto modelować zagrożenia dla istniejącego, działającego systemu? Tak. Choć największą wartość daje na etapie projektu, model działającego systemu porządkuje wiedzę o jego słabych punktach, ukierunkowuje testy i pomaga priorytetyzować poprawki. To dobry punkt wyjścia przed zaplanowaniem pentestu.
