„Mamy pentesty raz w roku. Po co nam jeszcze modelowanie zagrożeń?” To pytanie pada w niemal każdej rozmowie o bezpiecznym wytwarzaniu i jest w nim ukryte założenie, że chodzi o dwie wersje tej samej usługi. Obie w końcu „sprawdzają bezpieczeństwo”, więc po co płacić dwa razy?
Tylko że one nie sprawdzają tego samego. Ani w tym samym momencie.
Teza tego artykułu: pentest bada system, który już istnieje; modelowanie zagrożeń pracuje, zanim powstanie kod — a największa wartość rodzi się wtedy, gdy zepniesz je w pętlę. Plan jest taki: najpierw pięć cech, które je różnią; potem powód, dla którego nie są konkurentami; na końcu pętla, w której jedna praktyka obniża koszt drugiej. Zapraszamy do lektury.
Jedna oś porządkuje wszystko: proaktywne kontra reaktywne
Modelowanie zagrożeń (ang. threat modeling) jest jedyną w pełni PROaktywną praktyką bezpieczeństwa: działa na etapie projektowania, zanim powstanie pierwsza linijka kodu czy zanim postawisz serwer (pisaliśmy o tym w przewodniku). Pentest, audyt, skan podatności działają reaktywnie: badają to, co już zbudowano. Proaktywność to zresztą sedno security by design: bezpieczeństwo wbudowane w projekt, a nie doklejone po fakcie.
Czemu ta oś jest tak ważna? Ponieważ decyduje o koszcie. Im później łapiesz problem, tym drożej go usuwasz; błąd projektowy złapany na tablicy kosztuje rozmowę, a złapany przez pentest rok po wdrożeniu kosztuje przebudowę. Widać to też na poziomie pojęć: pentest znajduje podatności, które już siedzą w gotowym systemie, a modelowanie szuka zagrożeń, zanim ktokolwiek zdąży wprowadzić podatność (czym różni się zagrożenie od podatności).
Pentest znajduje błędy, które już popełniono. Modelowanie zapobiega ich popełnieniu.
Pięć cech, którymi porównuje się oceny bezpieczeństwa
W naszym cyklu o typach ocen bezpieczeństwa porównujemy wszystkie praktyki tego rodzaju pięcioma cechami: cel, zakres, moment, wysiłek i automatyzacja. Tu wystarczy wersja skrócona, dla tej jednej pary:
| Cecha | Modelowanie zagrożeń | Pentest |
|---|---|---|
| Cel | uniknąć zagrożeń, zanim staną się podatnościami | znaleźć i udowodnić podatności, które już istnieją |
| Zakres | projekt i architektura systemu | działający system lub aplikacja |
| Moment | etap projektowania, przed kodem | po zbudowaniu, zwykle przed wydaniem albo cyklicznie |
| Wysiłek | godziny (sesja plus przygotowanie) | dni lub tygodnie testów |
| Automatyzacja | zbędna na start (tablica wystarczy); pomaga utrzymywać modele | narzędzia wspierają, ale rdzeń pozostaje ręczną robotą testera |
Zwróć uwagę, że żadna z tych pozycji nie stawia praktyk przeciwko sobie. Cel, moment i zakres są różne, więc porównywanie ich wprost przypomina spór, czy lepsze jest koło, czy silnik.
Nie wybierasz między nimi. Ustawiasz je na jednej osi czasu.
Analogia: profilaktyka i leczenie
Posłużymy się analogią, bo dobrze tu pasuje. Modelowanie zagrożeń jest jak profilaktyka: nudna, powtarzalna, tania — i działa, ZANIM choroba się rozwinie. To regularne badania i szczepienia. Pentest jest natomiast jak dokładne badanie organizmu, który już żyje i pracuje: potrafi wykryć chorobę i udowodnić, że jest realna, ale jej nie cofnie. Leczenie to już osobny koszt.
I stąd nasza mantra: modelowanie zagrożeń to witamina, nie lek. Efekty przychodzą z czasem i z regularnością, nie po jednej tabletce. Kto oczekuje, że jedna sesja „wyleczy” system, przeżyje to samo rozczarowanie, co ktoś, kto jedną tabletką witaminy C chce zatrzymać grypę.
Pętla, w której obie praktyki pracują na siebie
Tu dochodzimy do sedna, czyli do tego, czemu ustawianie tych praktyk przeciwko sobie jest błędem. Dobrze ustawiona współpraca wygląda tak:
- Zespół buduje model zagrożeń na etapie projektowania, proaktywnie (jak wygląda sesja). Na poziomie systemu artefakt jest formalny: powstaje właśnie po to, żeby ktoś go później wykorzystał (kto i co buduje na którym poziomie).
- Artefakt trafia do testerów bezpieczeństwa PRZED testem. Zamiast pustej kartki i rekonesansu od zera dostają mapę systemu z zaznaczonymi zagrożeniami (jak czyta się taką mapę).
- Testerzy walidują model: potwierdzają, które zagrożenia są realne, i uzupełniają go o to, czego zespół nie przewidział. Poprawki wracają do modelu, a wyniki testu lądują w backlogu w konkretnych formatach.
- Zaktualizowany model ukierunkowuje kolejne testy. Z każdym obiegiem pętli testerzy startują coraz bliżej sedna, a koszt bezpieczeństwa spada.
Dobrze ujął to Serhii Pronin (Head of Security w Booksy) w komentarzu pod jednym z naszych materiałów: przekazanie wyników modelowania zespołowi testów to w praktyce „requirement-driven security testing”, czyli testowanie napędzane wymaganiami, a nie tylko eksploracją.
Spójrz na to też od strony testera. Każdy pentester i tak nieformalnie modeluje zagrożenia; szkoda tylko, że ta wiedza zwykle nigdzie potem nie wraca. Pętla formalizuje ten odruch i sprawia, że ustalenia przestają wyparowywać wraz z końcem zlecenia.
Model bez testów to hipoteza. Testy bez modelu to zgadywanie. Pętla robi z nich system.
„Czy pentest nam nie wystarczy?”
Wróćmy do obiekcji z początku, bo teraz można ją rozbroić rzeczowo. Nie, sam pentest nie wystarczy. Powody są trzy.
Po pierwsze: pentest przychodzi za późno dla błędów projektowych. Źle zaprojektowanego uwierzytelniania czy architektury, która wystawia na świat zbyt dużą powierzchnię ataku, nie naprawisz hotfixem po teście; to są decyzje z etapu projektu i tylko tam można je tanio zmienić.
Po drugie: pentest ma budżet czasowy. Bez modelu na wejściu spora część tego budżetu spala się na rozpoznanie systemu, zamiast na drążenie tego, co naprawdę groźne. Płacisz za godziny rozpoznania, których większość oszczędziłby model na wejściu.
Po trzecie: pentest jest z natury punktowym zdjęciem stanu, a system zmienia się codziennie. Między jednym zdjęciem a drugim żyje dalej, niezależnie od tego, jak często je robisz. Modelowanie działa w trybie „mała dawka, ale często”, więc towarzyszy zmianom dokładnie tam, gdzie powstają.
A gdyby budżetu starczyło tylko na jedno? Wybierz modelowanie: tanio zmienia decyzje projektowe, których pentest po fakcie już nie odkręci. Tylko że to w dużej mierze fałszywy wybór, bo modelowanie kosztuje godziny, a nie dni.
A teraz uczciwie w drugą stronę: modelowanie zagrożeń NIE zastępuje pentestu. Model to zbiór hipotez o systemie, a nie dowód z działającej aplikacji. Badanie SEI z udziałem 250 osób pokazało, że żadna pojedyncza metoda nie znajduje większości zagrożeń; walidacja nie jest więc dodatkiem, tylko częścią praktyki. Czwarte pytanie Shostacka („Czy zrobiliśmy to wystarczająco dobrze?”) domyka się właśnie testami. Bez nich model powoli odkleja się od rzeczywistości.
Pytanie nie brzmi „modelowanie czy pentest”, tylko „czemu Twój pentest nie dostaje modelu na wejściu”.
Co z tego wynika dla compliance
Ten wątek jest krótki, ale dla części organizacji decydujący. Audytor pyta o analizę ryzyka i o bezpieczne wytwarzanie; formalny model zagrożeń jest wkładką do jednego i drugiego, a udokumentowana pętla model–testy pokazuje, że proces żyje, zamiast leżeć w segregatorze (jak to mapuje się na NIS2, DORA i CRA).
Dla audytora to dowód, że proces żyje; dla zespołu tańsze testy. Jeden mechanizm, dwie korzyści.
Co robić, jak żyć?
Zbierzmy to w pięć praktycznych kroków:
- Masz pentest w kalendarzu? Zbuduj model zagrożeń PRZED nim (sesja krok po kroku) i przekaż go testerom razem z zakresem zlecenia.
- Zapisz pętlę w zleceniu. Poproś, żeby raport mapował znaleziska na model: co potwierdzone, co obalone, co nowe. Jedno zdanie w zamówieniu potrafi zmienić cały charakter raportu.
- Po teście domknij obieg. Nanieś wnioski na model, a wyniki przekuj w akcje w backlogu (5 formatów), triażując je według krytyczności.
- Ustaw rytm. Modelowanie często i lekko, przy każdej zmianie; testy okresowo i głęboko. Jedno nie zastępuje drugiego.
- Traktuj to jako element procesu. Pętla model–testy to fragment większej całości (proces, sesja i model), nie osobny projekt.
Bo bezpieczeństwo to proces, nie produkt. Pentest i modelowanie zagrożeń nie konkurują o budżet: to dwie praktyki na tej samej osi czasu, a największą wartość dają wtedy, gdy dopniesz je w pętlę.
Damy Ci znać, gdy opublikujemy coś nowego.
Artykuł albo odcinek podcastu. Bez spamu. W każdej chwili możesz się wypisać.
Zapisując się, akceptujesz politykę prywatności.
Referencje i wzmianki: Adam Shostack, Threat Modeling: Designing for Security (czwarte pytanie jako walidacja); SEI, badanie z udziałem 250 uczestników (żadna pojedyncza metoda nie znajduje większości zagrożeń); OWASP (WSTG — świat testów); nasz cykl o typach ocen bezpieczeństwa (Architecting Security, EN) jako źródło ramy pięciu cech.