Umówiłeś pierwszą sesję, zarezerwowałeś salę (albo tablicę online), zaprosiłeś kilka osób. I co dalej? Siadacie i… co się właściwie ma w tym pokoju wydarzyć? To pytanie zatrzymuje więcej zespołów, niż się wydaje. Nie dlatego, że modelowanie zagrożeń jest trudne, tylko dlatego, że mało kto pokazuje, jak taka sesja wygląda od środka.
Zanim zaczniemy, wyrównajmy spojrzenie: modelowanie zagrożeń (ang. threat modeling) to nie jest żaden rocket science. To ustrukturyzowana rozmowa o tym, co może pójść źle, prowadzona wokół czterech pytań. Tyle. Żadnej czarnej magii, żadnego drogiego narzędzia, które „samo” rozwiąże problem.
Jedno zastrzeżenie na wejściu, żeby nie pomylić pojęć: sesja to nie cały proces. Sesja jest instancją procesu: jednym spotkaniem w czymś szerszym. Rynek lubi sprowadzać całe modelowanie zagrożeń do pojedynczej sesji, ale proces obejmuje też to, co dzieje się wokół niej: przygotowanie, walidację, powrót do backloga. Tu skupiamy się celowo na samej sesji, bo to o nią pyta większość ludzi przed pierwszym spotkaniem.
W tym artykule pójdziemy tak: cztery pytania → sześć kroków sesji → kogo zaprosić, ile to trwa i kto prowadzi. Po kolei. Jeśli szukasz szerszego obrazu „czym w ogóle jest modelowanie zagrożeń”, zacznij od naszego kompletnego przewodnika. A jeśli już go znasz, zostań tu i zobacz, jak wygląda robota w praktyce.
Cztery pytania, wokół których kręci się cała sesja
Cały szkielet praktyki to cztery pytania spopularyzowane przez Adama Shostacka (powstały w Microsofcie, nie jest ich jedynym autorem), które od lat są kręgosłupem modelowania zagrożeń. Trzy z nich są fundamentalne, czwarte jest bonusowe (zaraz wyjaśnimy, czemu „bonusowe”):
- Nad czym pracujemy? — czyli reprezentacja systemu: co właściwie modelujemy.
- Co może pójść źle? — czyli szukanie zagrożeń.
- Co z tym zrobimy? — czyli decyzja i akcje (mitygacje).
- Czy zrobiliśmy to wystarczająco dobrze? — czyli walidacja.
I tu pada różnica, którą większość szkoleń przemilcza. Pytania 1–3 zadajesz na sesji. Ale pytanie czwarte pada PO sesji, nie domkniesz go tego samego dnia. Wracasz do niego przy przeglądzie backloga, mniej więcej po ~30 dniach: sprawdzasz, czy zagrożenia, które znaleźliście, faktycznie zostały zaadresowane. To nie jest punkt agendy na spotkanie. To retrospektywa po fakcie.
Dlatego mówimy o nim „bonusowe”: nie dlatego, że mniej ważne, tylko dlatego, że dzieje się poza samą sesją, już w procesie.
Sesja realizuje pierwsze trzy pytania. Czwarte to nie część spotkania, lecz retrospektywa po fakcie.
Sesja krok po kroku (6 kroków)
Mamy już szkielet (cztery pytania), więc przełóżmy go na konkretny przebieg spotkania. Sesja to sześć kroków: po pierwsze reprezentacja systemu, po drugie „co może pójść źle”, po trzecie nadanie krytyczności, po czwarte decyzja, po piąte retrospekcja, i po szóste walidacja modelu. Pięć pierwszych dzieje się na spotkaniu; szósty już poza nim. Przejdźmy po kolei.
Krok 1 — Reprezentacja systemu („nad czym pracujemy”)
Zaczynacie od wspólnego obrazu systemu: czegoś, na co wszyscy patrzą i co wszyscy rozumieją tak samo. Najczęściej rysujecie diagram przepływu danych (ang. data flow diagram, DFD): gdzie dane wpływają, gdzie wypływają, kto je przetwarza, gdzie przekraczają granice zaufania.
Ważne, żeby nie utknąć na tym kroku w pogoni za perfekcją. Mapa to nie teren. Diagram ma być wystarczająco dobry, żeby było o czym rozmawiać, a nie wiernym odwzorowaniem każdego szczegółu. Lepiej zgrubny obrazek, przy którym pada sensowna rozmowa, niż piękny diagram, na którym zeszło całe spotkanie. Jak rysować DFD i czego unikać, rozkładamy w osobnym artykule.
Krok 2 — „Co może pójść źle”
To serce sesji. Macie obraz systemu, teraz szukacie, co może w nim pójść nie tak. Robicie to w dwóch ruchach.
Zwyczajowo zaczynacie od STRIDE jako drivera (ang. driver) sesji: przejeżdżacie nim system element po elemencie diagramu. STRIDE to mnemonik sześciu rodzin zagrożeń (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege). I tu kluczowa uwaga: STRIDE to taksonomia używana jako driver, nie metodyka. To prompt do burzy mózgów na pytanie „co może pójść źle”, a nie sztywna szafka, do której musicie wszystko poukładać. Nie debatujcie, czy dane zagrożenie to S czy E: zapisz raz i jedź dalej (jak pasuje pod kilka liter, tym lepiej). Używaj STRIDE luźno, jak podpowiedzi. Dlaczego STRIDE działa jako driver, a nie metodyka, tłumaczymy osobno.
Potem, jako uzupełnienie, sięgacie po biblioteki ataków (ang. attack libraries): gotowe katalogi typowych zagrożeń, które podpowiadają konkrety i nie pozwalają wymyślać koła od nowa. Na poziomie aplikacji naturalnym wyborem jest OWASP Top 10. (Na innych poziomach pasują inne biblioteki; pełen przegląd, od MITRE ATT&CK po CWE Top 25, robimy gdzie indziej.)
Kolejność nie jest dogmatem. Domyślnie zaczynamy od STRIDE, bo zmusza do myślenia, a nie tylko odhaczania, a bibliotekę dokładamy jako wzbogacenie. Ale jeśli czasu jest mało i wolicie podejść bardziej checklistowo, możecie pojechać samą biblioteką ataków. Lepiej to niż nic.
Jeśli patrzycie też pod kątem prywatności, do STRIDE dokłada się TRIM — narzędzie zbudowane na wzór STRIDE, ale celujące w aspekty przetwarzania danych osobowych (jak migrują, czy trzeba je minimalizować). TRIM jest do prywatności, STRIDE do bezpieczeństwa, i spokojnie można je prowadzić jako osobne wątki.
I jeszcze jedno rozróżnienie, bo ciągle się myli: DFD (notacja, „na czym” rozmawiamy) to nie to samo co STRIDE (driver, „czym” napędzamy sesję). Diagram to sposób przedstawienia systemu. STRIDE to to, co popycha rozmowę do przodu. Dwie osobne osie, łatwo je pomylić, bo padają obok siebie.
Krok 3 — Nadawanie krytyczności (priorytetyzacja)
Po kroku 2 macie zwykle więcej zagrożeń, niż jesteście w stanie zaadresować od ręki. Trzeba je uszeregować, i tu pojawia się subtelna, ale ważna różnica.
Kiedy modelujecie w przód (zanim powstanie kod czy infrastruktura), podatności jeszcze nie ma, bo nie ma jeszcze czego atakować. Trudno więc mówić o ryzyku w klasycznym sensie. Dlatego nadajemy zagrożeniom KRYTYCZNOŚĆ (ang. criticality), czyli priorytet samego zagrożenia, nie wyliczone ryzyko. To rozróżnienie krytyczność ≠ ryzyko jest na tyle istotne, że rozwijamy je osobno.
Jak to robić w praktyce? Trzy popularne podejścia: DREAD (mnemonik atrybutów zagrożenia), macierz ryzyka (np. siatka 3×3: prawdopodobieństwo × wpływ) albo dot voting (szybkie głosowanie kropkami). Każde ma swoje trade-offy: DREAD bywa trudny do okiełznania w skali 1–3 i wymaga progów, dot voting jest błyskawiczny, ale „na czuja”. Pełne porównanie (który model kiedy) zostawiamy na osobny artykuł o priorytetyzacji. Tu wystarczy zasada: priorytetyzujesz po zebraniu zagrożeń, nie w trakcie.
Krok 4 — „Co z tym zrobimy” (DECYZJA)
To krok, który decyduje, czy cała sesja miała sens. Przeglądacie znalezione zagrożenia, zwykle od najpoważniejszych, i zamieniacie je w konkretne akcje w backlogu. I tu jest haczyk: „wrzucimy do backloga” to za mało. Trzeba zacommitować się do formatu: dług techniczny, kryteria akceptacji, Definition of Done, spike, epik. Cokolwiek, co realnie żyje dalej w procesie wytwórczym. Pięć formatów akcji do backloga rozpisujemy osobno.
I rzecz, którą warto powiedzieć wprost: nie musisz zaadresować wszystkiego, co znalazłeś. Zwłaszcza na poziomie funkcjonalności bywa, że bierzecie na warsztat tylko top 3 problemy: bo jesteście startupem, bo brakuje rąk i czasu, bo ograniczeń jest więcej. I to jest w porządku, lepiej zrobić coś niż nic. Liczy się zaufanie do procesu: im częściej modelujecie, tym pełniej z czasem przeszukujecie przestrzeń zagrożeń, więc główne problemy i tak wyjdą, sesja po sesji. Bezpieczeństwo nie ma nieograniczonego budżetu czasu, a rozsądny kompromis to też cel biznesowy.
Bez tego kroku cała robota idzie do kosza. Sesja, która kończy się na „znaleźliśmy zagrożenia” i niczym więcej, jest gorsza niż żadna, bo daje fałszywe poczucie, że coś zrobiliście. Sesja bez choćby jednej decyzji i akcji w backlogu to sesja na marne.
Krok 5 — Retrospekcja
Krótkie domknięcie spotkania: co poszło dobrze, co poprawić następnym razem, czego zabrakło. Pięć minut, nie pół godziny.
I tu mamy jedną analogię, którą warto zapamiętać: modelowanie zagrożeń to trochę jak retrospektywa zespołowa: celem jest ULEPSZANIE, nie wskazywanie palcem. Nie szukacie winnego, kto „wpuścił” zagrożenie do projektu. Szukacie, jak zrobić system bezpieczniejszym i jak następnym razem przeprowadzić lepszą sesję. To zmienia atmosferę: poprzeczka wejścia jest niska, nikt nie musi być ekspertem od bezpieczeństwa, nie gryziemy. Im mniej oceniania, tym więcej ludzie wnoszą.
Krok 6 — Walidacja modelu (poza samą sesją)
Po spotkaniu model nie jest „skończony” i nie powinien być. Gotowy artefakt przekazujecie testerom i pentesterom, którzy podczas testów go walidują i uzupełniają. To domyka pętlę i jest momentem, w którym modelowanie zagrożeń proaktywnie obniża koszt bezpieczeństwa: testerzy nie działają po omacku, tylko skupiają się na zagrożeniach, które wskazał model.
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ą. A przy tej walidacji testerzy zwykle wzbogacają sam model o rzeczy, których nie przewidzieliście. Jak ta pętla między modelem a testami wygląda w szczegółach, opisujemy osobno.
Zwróć uwagę na gradient: krok 6 i czwarte pytanie Shostacka („czy zrobiliśmy wystarczająco dobrze”) dzieją się poza sesją i są częścią szerszego procesu, nie samego spotkania.
Sesja to nie jednorazowy event. To kroki 1–5 na spotkaniu (~45–90 min zależnie od scope), a krok 6 i czwarte pytanie dzieją się później, już w procesie.
Kogo zaprosić?
Najczęstsze pytanie przed pierwszą sesją: kto ma w niej siedzieć? Odpowiedź zaczyna się od liczby: 3 do 6 osób. To sweet spot. Za mało osób = ślepe plamy, ktoś zna tylko swój kawałek systemu. Za dużo = chaos, rozmycie odpowiedzialności i spotkanie, na którym połowa milczy.
Konkretny skład zależy od poziomu, na którym modelujesz: inaczej dobierasz ludzi przy pojedynczej funkcjonalności, inaczej przy całej aplikacji, a zupełnie inaczej przy systemie czy organizacji. Nie będziemy tu powielać całej macierzy ról; rozpisaliśmy ją w przewodniku po poziomach modelowania zagrożeń.
W praktyce, na poziomie aplikacji (czyli domyślnym kontekście większości sesji), zapraszasz: kogoś, kto realnie zna system (tech lead albo architekt), deweloperów lub Security Championa, opcjonalnie kogoś od QA. Najważniejsza zasada: zaproś tego, kto faktycznie zna przepływy danych, bo bez tej osoby krok 1 (reprezentacja systemu) po prostu utknie.
Lepiej 4 właściwe osoby niż 10 „dla pewności”.
Ile to trwa? Timebox i tempo
Druga rzecz, którą każdy chce wiedzieć z góry: ile to zajmie? Klasyczna odpowiedź konsultanta: to zależy. Ale nie zostawimy Cię w sferze domysłów, podamy kierunek.
Czas skaluje się ze scope’em. Na poziomie pojedynczej funkcjonalności sesja to ~45–60 minut. Na poziomie aplikacji albo systemu do ~90 minut. Im szerszy zakres, tym dłużej; modelowanie całej organizacji potrafi rozłożyć się na tygodnie i wiele spotkań. Reguła jest prosta: więcej elementów do analizy = więcej czasu.
Niezależnie od długości: timeboxuj każdy krok. Ustal z góry, ile minut na diagram, ile na „co może pójść źle”, ile na priorytetyzację. Bez tego krok 1 zje całe spotkanie, a na decyzję (krok 4, ten najważniejszy) zabraknie czasu.
I trzecia rzecz, najważniejsza dla utrzymania tempa: little and often, czyli małe porcje, często. Jedna sesja daje częściowy widok systemu i to jest OK. Nie celuj w komplet za jednym podejściem. Wracaj do modelu z różnych kątów i poziomów przybliżenia, sesja po sesji. To właśnie czyni modelowanie zagrożeń wykonalnym w rytmie sprintu i zdejmuje z zespołu presję kompletności.
Nie martw się o kompletność. Lepiej krótka sesja co iterację niż jeden tygodniowy maraton raz na rok.
Kto prowadzi: facylitator ≠ bohater
Sesję prowadzi facylitator (ang. facilitator) i to jest rola, którą najczęściej rozumie się na opak.
Pokusa jest taka, żeby facylitator był gwiazdą: tym, kto zna się na bezpieczeństwie najlepiej i sam wymyśla wszystkie zagrożenia, a reszta przytakuje. To błąd. Prowadzisz proces, nie dostarczasz odpowiedzi. Facylitator pilnuje pytań, trzyma timebox i dba o to, żeby każdy się wypowiedział, a nie produkuje zagrożenia za zespół. Zagrożenia mają znaleźć ludzie, którzy znają system, bo to oni wiedzą, gdzie naprawdę leżą trupy.
To zresztą spina się z analogią o retrospektywie z kroku 5: facylitator dobrej retrospektywy nie ocenia ludzi, lecz tworzy przestrzeń, w której zespół sam dochodzi do wniosków. Tu jest tak samo. Niska poprzeczka wejścia, bez wskazywania palcem, nie gryziemy.
W praktyce facylitatorem często bywa Security Champion: osoba blisko zespołu deweloperskiego, która spina temat bezpieczeństwa. Jak wdrożyć taki program i wyznaczyć Championów, to osobny temat.
Facylitator prowadzi proces — zagrożenia znajdują ci, którzy znają system.
Jak się przygotować do sesji?
Dobra sesja zaczyna się przed sesją. Cztery rzeczy, które warto ogarnąć wcześniej:
- Wiedz, na jakim poziomie modelujesz, i pod to dobierz skład. Funkcjonalność, aplikacja, system czy organizacja: od tego zależy, kogo zapraszasz (→ poziomy modelowania zagrożeń).
- Miej choćby zgrubną dokumentację albo istniejący diagram. Żeby nie rysować całego systemu od zera na sesji: to marnotrawstwo cennego czasu, który lepiej spożytkować na „co może pójść źle”.
- Wybierz narzędzie techniczne i z góry rozplanuj timebox. Może być tablica i aparat w telefonie, może być draw.io, może być tablica online z timerem i naklejkami. Pełen przegląd narzędzi to osobny temat; tu liczy się, żeby narzędzie nie było wąskim gardłem.
- Ustal, kto konsumuje wynik i gdzie ląduje backlog. Bo krok 4 (decyzja) musi mieć dokąd trafić.
Czasem wyzwalacz sesji jest zewnętrzny, na przykład wymóg compliance. Regulacje takie jak NIS2, DORA czy CRA de facto wymagają, żebyś wiedział, co Ci zagraża, a modelowanie zagrożeń jest na to naturalną odpowiedzią.
Jedno, czego tu celowo nie ruszamy: metodyki. Pytasz pewnie „a gdzie w tym wszystkim Agile Threat Modeling albo RTMP?”. Już wyjaśniamy: to są metodyki, czyli sposoby prowadzenia całego procesu narzucające preferowany driver sesji. To osobna oś od tego, co opisaliśmy powyżej (driver: STRIDE/TRIM/biblioteka; notacja: DFD). Tu zostajemy przy pojdynczej sesji.
Co robić, jak żyć?
Zbierzmy całą sesję w praktyczną listę:
- Narysuj system (DFD). Wystarczająco dobrze. Mapa to nie teren.
- Przejedź „co może pójść źle”. Najpierw STRIDE jako driver, element po elemencie; potem ewentualnie biblioteka ataków jako uzupełnienie (na poziomie aplikacji: OWASP Top 10). Mało czasu? Sama biblioteka też zda egzamin. Prywatność? Dołóż TRIM.
- Nadaj zagrożeniom krytyczność. Priorytetyzuj. Pamiętaj: w przód nadajesz krytyczność, nie ryzyko (DREAD / macierz / dot voting).
- Podejmij decyzję. Zamień zagrożenia na konkretne akcje w backlogu. Bez tego kroku sesja była na marne.
- Zrób krótkie retro. Ulepszanie, nie wskazywanie palcem.
- Oddaj model testerom do walidacji (poza sesją): niech go sprawdzą i uzupełnią.
- Po ~30 dniach wróć do backloga i odpowiedz na czwarte pytanie Shostacka: „czy zrobiliśmy to wystarczająco dobrze?”.
Dwie mantry na koniec. Little and often: częściowy widok jest OK, nie musisz domknąć wszystkiego za jednym razem. I facylitator prowadzi proces, nie dostarcza odpowiedzi, zagrożenia znajdują ci, którzy znają system.
A sedno tego wszystkiego? Celem nie jest ładny artefakt ani odhaczone spotkanie. Celem jest uniknięcie zagrożeń, które znaleźliśmy. Cała reszta (diagram, STRIDE, backlog) to środki do tego jednego celu.
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 (cztery pytania); OWASP (Top 10).