Jest takie pytanie, na które zespół biorący się za modelowanie zagrożeń (ang. threat modeling) musi odpowiedzieć sobie na samym początku: którą metodykę wybrać? STRIDE, PASTA, a może LINDDUN? I tutaj klasyczna odpowiedź konsultanta brzmi: to zależy! My jednak nie zostawimy Cię w sferze domysłów; do końca tego tekstu podamy Ci konkretne kierunki.

Najpierw jednak musimy powiedzieć coś ważniejszego: to pytanie jest źle postawione. STRIDE, PASTA i LINDDUN nie są trzema odpowiedziami na to samo pytanie. Mimo że rynek (rankingi, porównywarki, materiały szkoleniowe) wrzuca je do jednego worka z etykietą „metody”, one jednak leżą na różnych osiach: jedno mówi, JAK prowadzić sesję, drugie mówi, CZYM generować zagrożenia. Zestawianie ich wprost to porównywanie rzeczy z różnych półek.

Plan tego artykułu jest taki: najpierw rozdzielimy 4 osie, które rynek skleja w jedną. Potem przejdziemy przez krajobraz: metodyki, drivery i drzewa ataków. Na końcu pokażemy naszych ulubieńców, z uzasadnieniem, i podpowiemy, jak dobrać własnych. Zapraszamy do lektury.

4 osie, które rynek skleja w jedną

Dobre definicje od razu ustawiają całą resztę, więc zacznijmy od ich ustalenia. Decyzje w modelowaniu zagrożeń zapadają na 4 osiach, a każda odpowiada na inne pytanie:

• Metodyka mówi, JAK prowadzimy sesję i cały proces: kto siada do stołu, w jakiej kolejności padają pytania, co dzieje się z wynikiem. Na tej osi leżą Agile Threat Modeling, RTMP i PASTA.
• Driver (napęd sesji) mówi, CZYM generujemy zagrożenia w burzy mózgów wokół pytania „co może pójść źle?”. Na tej osi leżą STRIDE, TRIM, LINDDUN i biblioteki ataków.
• Notacja mówi, NA CZYM modelujemy: może to być diagram przepływu danych (ang. Data Flow Diagram, DFD), PFD (ang. Process Flow Diagram) albo zwykły diagram architektury. Notacja jest przy tym zależna od poziomu, na którym pracujesz: właśnie dlatego nie ma jednej uniwersalnej.
• Priorytetyzacja mówi, CZYM oceniamy to, co znaleźliśmy: DREAD, macierzą ryzyka czy dot votingiem. Pełne porównanie zostawiamy na osobny artykuł o priorytetyzacji.

Jest jeszcze jeden niuans, który porządkuje wszystko powyżej: driver jest CZĘŚCIĄ metodyki. Co więcej, metodyka często narzuca preferowany driver; przykładowo Agile Threat Modeling preferuje STRIDE. Dlatego pytanie „STRIDE czy PASTA?” jest w większości przypadków porównaniem silnika z całym samochodem.

przewiń tabelę w bok

Oś	Na jakie pytanie odpowiada	Przykłady
Metodyka	jak prowadzimy sesję i proces	Agile Threat Modeling, RTMP, PASTA
Driver	czym generujemy zagrożenia	STRIDE, TRIM, LINDDUN, biblioteki ataków
Notacja	na czym modelujemy	DFD, PFD, diagram architektury
Priorytetyzacja	czym oceniamy znaleziska	DREAD, macierz ryzyka, dot voting

Zanim zaczniesz porównywać narzędzia, sprawdź, czy w ogóle leżą na tej samej osi.

Metodyki: ATM, RTMP i PASTA

Metodyka to warstwa, która z pojedynczych spotkań robi powtarzalną praktykę. 3 nazwy, które realnie spotkasz w tym krajobrazie, to Agile Threat Modeling, RTMP i PASTA.

Agile Threat Modeling (ATM) to koncepcja branżowa, spopularyzowana przez ThoughtWorks (opisał ją Jim Gumbley, a w 2025 roku opis odświeżył razem z Gayathri Mohan). Jej sednem jest dobrze opisana facylitacja: jak poprowadzić grupę przez timeboxowaną sesję, jak utrzymać energię, jak zamknąć spotkanie konkretem w backlogu. ATM najlepiej czuje się w iteracyjnym trybie modelowania: mała dawka, ale często, w rytmie pracy zespołu. Jak wygląda sesja modelowania zagrożeń krok po kroku, pokazujemy w osobnym przewodniku.

RTMP (Rapid Threat Model Prototyping) stawia na szybkie prototypowanie modelu w rytmie zmian: zamiast celebrować duże warsztaty, aktualizujesz model małymi krokami, blisko kodu i sprintu. Główny pomysł RTMP to skrócenie fazy burzy mózgów: wycinasz z niej część elementów. Filozofia jest pokrewna ATM: niski próg wejścia, powtarzalność ponad kompletność.

Obie te metodyki mają wspólny mianownik: pasują do poziomu systemu, aplikacji i funkcjonalności, a nie do poziomu całej organizacji. Jak zmienia się gra na kolejnych poziomach modelowania zagrożeń, opisujemy osobno; tu wystarczy jedno zdanie: tam, gdzie kończy się teren ATM i RTMP, driverem przestaje być STRIDE, a zaczyna biblioteka ataków.

PASTA (Process for Attack Simulation and Threat Analysis) to inna liga i jedyna pozycja z tej trójki, którą można nazwać ciężką metodyką. Ma 7 etapów i jest podejściem risk-centric, czyli zorientowanym na ryzyko: zaczyna od celów biznesowych i analizy ryzyka, przechodzi przez dekompozycję systemu i analizę zagrożeń, a kończy się symulacją ataków i wyceną ryzyka. Podejście opracowali Tony UcedaVélez i Marco Morana. Zwróć uwagę, jak to się ma do osi z początku tekstu: PASTA na 6. etapie formalnie sięga po drzewa ataków (o których za chwilę), a STRIDE bywa w niej techniką enumeracji zagrożeń na etapach dekompozycji i analizy zagrożeń. Widać więc, że porównanie „STRIDE czy PASTA?” zestawia część z całością i w tej formie nie ma racji bytu.

Na papierze wygląda to imponująco i w niektórych organizacjach właśnie tak działa: tam, gdzie analiza ryzyka jest dojrzałym, codziennym aparatem (sektor regulowany, duże instytucje), PASTA potrafi spiąć modelowanie zagrożeń z językiem zarządu. Ale ta kompletność ma cenę: pełny cykl wymaga ludzi, czasu i dyscypliny, zanim zobaczysz pierwszą realną wartość. W praktykach, które budujemy, o wartości decyduje rytm, a nie ceremonia. Czy to dyskwalifikuje PASTA? Nie; to kwestia dopasowania, do której wrócimy przy naszym zestawie.

Do tego dochodzi symetria poziomów. Tak jak ATM i RTMP pasują do modelowania iteracyjnego i do poziomu systemu, aplikacji czy funkcjonalności, tak PASTA pasuje do modelowania globalnego: punktowego, prowadzonego dla systemów w dłuższych odstępach czasu, na poziomie organizacji i systemu. To większe ćwiczenie i większy projekt: daje inną wartość, ale wymaga więcej zasobów (ludzi i know-how), a przez to narzuca inny rytm pracy. Sprawdza się też tam, gdzie modelujesz pod compliance.

Co ważne, te tryby się nie wykluczają. W jednym procesie modelowania zagrożeń może żyć i ATM, i PASTA: ATM pracuje w zespołach wytwórczych, w sprintach, na funkcjonalnościach i pojedynczych serwisach, a po PASTA sięgasz na przykład raz na rok, dla całego systemu albo zestawu systemów krytycznych w banku. Zespołów nie musisz wtedy uczyć PASTA: jak ją poprowadzić, musi wiedzieć facylitator (najpewniej architekt bezpieczeństwa albo ktoś równie doświadczony), a reszta uczestników wnosi wkład merytoryczny, ale nie dźwiga procesu.

Dla porządku odnotujmy jeszcze OCTAVE: to podejście do ryzyka organizacyjnego, nie do technicznego modelowania systemów, więc mimo podobnych haseł odpowiada na inne pytanie. A reszta krajobrazu (Trike, VAST, hTMM i podobne) to nazwy, które warto kojarzyć, ale żadnej z nich nie spotkaliśmy jako żywej praktyki w polskich zespołach; znajomość nazw nie jest praktyką.

Metodyka mówi, jak prowadzisz sesję, i już na starcie narzuca preferowany driver.

Drivery: STRIDE, TRIM, LINDDUN i biblioteki ataków

Driver to silnik burzy mózgów: zestaw podpowiedzi, które rozruszają dyskusję wokół pytania „co może pójść źle?”. To na tej osi leży większość nazw, które rynek błędnie sprzedaje jako „metody”.

STRIDE jest driverem bezpieczeństwa: 6 rodzin zagrożeń, których używasz jako podpowiedzi, przechodząc przez elementy systemu. Jest generyczny i demokratyczny, więc każdy w zespole może go użyć. Czym dokładnie jest i dlaczego NIE jest metodyką, wyjaśniamy w tekście o STRIDE.

Z prywatnością sprawa jest ciekawsza, bo tu mamy 2 drivery, które patrzą na prywatność z 2 różnych stron, a nie lepszą i gorszą wersję tego samego:

• TRIM (Transfer, Retention-Removal, Inference, Minimisation; opracowany przez F-Secure na wzór STRIDE) patrzy na prywatność przez pryzmat RODO/GDPR: transfer danych poza UE, retencja, wnioskowanie o osobie, minimalizacja zbierania. Jeżeli budujesz systemy na rynku europejskim i masz tu użytkowników, ten pryzmat dotyczy Cię zasadniczo zawsze.
• LINDDUN (opracowany na KU Leuven; 7 kategorii zagrożeń prywatności) patrzy na prywatność z punktu widzenia SYSTEMU i jego UŻYTKOWNIKA: co system wie, co potrafi powiązać, co zdradza obserwatorowi. Ta perspektywa staje się ważna tam, gdzie prywatność jest realnym wymogiem produktu, a nie tylko obowiązkiem regulacyjnym.

Używamy obu i wybieramy właściwe narzędzie do właściwej roboty i właściwej organizacji. Przy okazji prostujemy częsty błąd porównywarek: LINDDUN ląduje w nich obok PASTA i RTMP jako „metodyka prywatności”. Nie jest metodyką, dokładnie tak samo, jak STRIDE nią nie jest; to driver.

Driverem są wreszcie także biblioteki ataków: skatalogowane, domenowe listy tego, co naprawdę spotyka systemy danej klasy. Tam, gdzie STRIDE jest generyczny, biblioteka dosypuje konkretu; na właściwym poziomie trzeba po prostu wziąć właściwą listę, o czym piszemy w tekście o bibliotekach ataków.

Zostają jeszcze karcianki: Elevation of Privilege (w skrócie EoP; dla STRIDE) i Elevation of Privacy (EoPrivacy; dla TRIM). To nie osobne drivery, tylko forma sesji, po którą czasem sięgamy, żeby obniżyć próg wejścia i dodać grze trochę energii. Swoją karciankę, LINDDUN GO, ma też LINDDUN.

Driver to silnik burzy mózgów: dobierasz go do tego, co modelujesz, nie do mody.

Drzewa ataków: łańcuchy zamiast pojedynczych problemów

Drzewa ataków (ang. attack trees) spopularyzował Bruce Schneier pod koniec lat 90. Konstrukcja jest prosta: na szczycie drzewa stoi cel atakującego, a gałęzie (łączone warunkami AND/OR) pokazują kolejne sposoby dojścia do niego.

Drzewo ataku na przykładowy cel: dostęp do nagrań wideo w koszyku S3. Uwaga na kierunek: w tym narzędziu cel siedzi na dole, różowe pola to kroki atakującego, a niebieskie to zabezpieczenia po drodze.

Różnicę względem STRIDE widać najlepiej właśnie w tej konstrukcji. STRIDE patrzy na problemy atomicznie: wyłapuje pojedyncze zagrożenia, każde z osobna, ale nie pokazuje połączeń między nimi. Drzewo ataku robi coś odwrotnego: buduje pełne łańcuchy ataku, a jedno drzewo pokazuje zwykle kilka takich łańcuchów prowadzących do jednego i tego samego celu. Dlatego te podejścia się uzupełniają: STRIDE szybko zapełnia listę problemów, drzewo tłumaczy, jak te problemy składają się w realny scenariusz. Drzewa nie należą przy tym do żadnej metodyki: nawet PASTA na swoim 6. etapie modeluje ataki właśnie nimi.

Za tę głębię drzew ataków płacisz progiem wejścia: żeby sensownie poprowadzić łańcuch, ktoś w pokoju musi myśleć jak atakujący, a żeby myśleć jak atakujący, trzeba mieć doświadczenie w byciu atakującym. To nie jest codzienna praca programisty ani administratora (i to jest OK). Do rysowania drzew wystarczy tablica albo draw.io; gdy chcesz drzewa wersjonować, sięgnij po Deciduous, w którym drzewo opisujesz tekstem (jego składni trzeba się jednak nauczyć).

Drzewa ataków pasują do różnych metodyk i różnych spojrzeń na system, ale wymagają ofensywnego doświadczenia i nie zastępują STRIDE.

Newsletter Nowe artykuły i odcinki podcastu prosto na skrzynkę. Bez spamu.

Żadna metoda nie znajdzie większości zagrożeń

W tym momencie na naszych warsztatach zwykle pada pytanie: „OK, ale które z tych narzędzi jest najskuteczniejsze?”.

Badania empiryczne prowadzone w SEI (Carnegie Mellon) dają wynik, który warto przeczytać 2x: żadna pojedyncza metoda nie wykrywa większości zagrożeń obecnych w analizowanym systemie. Co ciekawsze, eksperci znajdują mniej typów zagrożeń niż mniej doświadczeni uczestnicy, za to celniej, bo patrzą węziej. A zgodność ocen między analitykami jest co najwyżej umiarkowana. Mówiąc krótko: nie istnieje narzędzie, które zapewni nam kompletność.

Wniosek z tego jest dla nas fundamentalny. Skoro pojedyncze przejście żadną metodą nie domyka tematu, przewagi nie szukaj w wyborze metody, tylko w rytmie. Jedna sesja daje częściowy obraz i to jest OK; wracasz następnym razem z innej strony. Mała dawka, ale często. Ta powtarzalność nie mieszka w nazwie metody, tylko w procesie modelowania zagrożeń: w wyzwalaczach, właścicielu i rytmie, które sprawiają, że sesje w ogóle się odbywają.

Z tego samego powodu odradzamy turystykę po metodykach: zmienianie podejścia co kwartał w pogoni za kompletnością, której żadna metoda nie da. Lepiej robić sesje jednym, dobrze opanowanym zestawem, niż wciąż zaczynać od zera z nowym.

Wybór narzędzi jest mniej ważny niż sprawne posługiwanie się nimi i utrzymanie rytmu.

Nasz zestaw (i dlaczego właśnie taki)

W naszej praktyce najczęściej używamy:

• metodyk ATM i RTMP na poziomie systemu, aplikacji i funkcjonalności,
• STRIDE jako drivera bezpieczeństwa,
• TRIM i LINDDUN jako driverów prywatności, dobieranych do tego, o co dba system (RODO/GDPR kontra system i jego użytkownik),
• biblioteki ataków dobranej do poziomu, na którym modelujemy, i technologii, której używamy,
• drzew ataków, gdy w pokoju jest ktoś z ofensywnym doświadczeniem.

Gdy sesja potrzebuje niższego progu wejścia, do gry wchodzą karcianki EoP i EoPrivacy.

PASTA znamy, ale używamy jej rzadko: zwykle nasi klienci jej nie potrzebują, bo mają inne cele związane z procesem modelowania zagrożeń. Tam, gdzie ma sens, możemy po nią sięgnąć. Resztę zestawu tłumaczy jedno kryterium: każdy element wybraliśmy tak, żeby zespół był w stanie pracować nim samodzielnie, bez bezpiecznika przy każdym stole.

Uczciwie dodajmy: to nie jest jedyny słuszny zestaw. To zestaw zoptymalizowany pod próg wejścia i powtarzalność w zespołach produktowych, z którymi mamy do czynienia na polskim rynku. Jeśli Twoja organizacja żyje analizą ryzyka na co dzień, pełna PASTA może być u Ciebie właściwym wyborem; wtedy wdrażaj ją świadomie.

Nasz zestaw wygrywa nie tym, że znajduje najwięcej, tylko tym, że zespół powtarza go w sposób ciągły.

Jak dobrać zestaw u siebie

Na koniec pora na obiecane kierunki. Przechodzisz przez 5 decyzji:

1. Zacznij od poziomu. Modelujesz pojedynczą aplikację albo funkcjonalność? ATM lub RTMP plus STRIDE. Modelujesz całą organizację? Tam metodyki sesyjne przestają pasować (to raczej teren globalnej PASTA), a driverem staje się biblioteka ataków, nie STRIDE.
2. Dopasuj zestaw do kultury zespołu. Zespoły iteracyjne, pracujące sprintami, naturalnie wchodzą w ATM. Organizacja formalna, regulowana, z dojrzałym aparatem ryzyka może udźwignąć PASTA; tylko wtedy ma to sens.
3. Sprawdź oś prywatności. Rynek europejski oznacza TRIM praktycznie zawsze. Prywatność jako realny wymóg produktu oznacza także LINDDUN.
4. Sprawdź, kogo masz w pokoju. Masz ludzi z ofensywnym doświadczeniem? Drzewa ataków pozwolą spojrzeć na system z perspektywy atakującego.
5. Priorytetyzację wybierz osobno. To inna oś: DREAD, macierz ryzyka i dot voting oceniają znaleziska, a nie je generują. Nie kupuj jej „w pakiecie” z metodyką.

Wybieraj po poziomie i zespole, nie po modzie na akronim.

Co robić, jak żyć?

Zbierzmy wszystko w 5 kroków:

1. Nie zaczynaj od porównywarki metod. Zacznij od jednej sesji: diagram przepływu danych plus STRIDE, na poziomie aplikacji.
2. Dołóż bibliotekę ataków dobraną do poziomu, na którym modelujesz, i technologii, której używasz.
3. Domknij oś prywatności: na rynku europejskim dołóż TRIM, a jeśli prywatność jest wymogiem Twojego produktu, sięgnij też po LINDDUN.
4. Gdy sesje staną się rytmem, nazwij metodykę. To, co już robisz, najpewniej nazywa się ATM albo RTMP; formalizuj praktykę, nie odwrotnie.
5. Resztę krajobrazu znaj z nazwy. PASTA, OCTAVE i spółka mają swoje zastosowania, ale niczego nie wdrażaj tylko dlatego, że brzmi poważnie.

Bo bezpieczeństwo to proces, nie produkt: sposób działania ustalasz i z czasem modyfikujesz, na podstawie doświadczenia i informacji, które zbierasz. Dopiero wtedy ma to sens na dłuższą metę i bezpieczeństwo faktycznie zaczyna działać.

Do zapamiętania — FAQ

Jakie są metody modelowania zagrożeń?

To, co rynek nazywa „metodami”, leży na 4 różnych osiach: metodyki (Agile Threat Modeling, RTMP, PASTA) mówią, jak prowadzić sesję i proces; drivery (STRIDE, TRIM, LINDDUN, biblioteki ataków) mówią, czym generować zagrożenia; osobno wybierasz notację (DFD, PFD) i sposób priorytetyzacji znalezisk.

STRIDE czy PASTA — co wybrać?

W większości przypadków to fałszywy dylemat: STRIDE jest driverem sesji, a PASTA pełną metodyką, więc nie konkurują wprost. Sama PASTA potrafi użyć STRIDE do enumeracji zagrożeń, a po drzewa ataków formalnie sięga na etapie modelowania ataków. Realne pytanie brzmi: lekka metodyka ze STRIDE (np. ATM) czy pełna PASTA? Odpowiedź zależy od kultury organizacji i poziomu, na którym modelujesz.

Czy LINDDUN to metodyka modelowania zagrożeń?

Nie. LINDDUN to driver prywatności, tak jak TRIM; żaden z nich nie jest metodyką. Różnią się tym, na co patrzą: LINDDUN patrzy na prywatność od strony systemu i jego użytkownika, a TRIM od strony RODO/GDPR. W praktyce używamy obu, zależnie od tego, o co dba system.

Która metoda modelowania zagrożeń jest najlepsza?

Żadna pojedyncza metoda nie wykrywa większości zagrożeń w systemie; pokazują to badania empiryczne SEI. Dlatego zamiast szukać najlepszej metody, zbuduj rytm: powtarzalne sesje jednym zestawem dadzą więcej niż jednorazowe przejście najmodniejszym.

Czym różni się metodyka od drivera?

Metodyka mówi, jak prowadzisz sesję i proces (kto uczestniczy, w jakiej kolejności, co z wynikiem). Driver mówi, czym generujesz zagrożenia podczas samej burzy mózgów. Driver jest częścią metodyki: metodyka często narzuca preferowany driver, np. ATM preferuje STRIDE.

Newsletter

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: ThoughtWorks — Agile Threat Modelling (Jim Gumbley; aktualizacja 2025 z Gayathri Mohan); Tony UcedaVélez, Marco Morana — Risk Centric Threat Modeling (PASTA); VerSprite — PASTA Threat Modeling: The 7 Stages Explained oraz PASTA vs. STRIDE, VAST, DREAD, OCTAVE, and Attack Trees (versprite.com); LINDDUN — KU Leuven (linddun.org); Bruce Schneier — Attack Trees (1999); SEI / Carnegie Mellon — badania empiryczne metod modelowania zagrożeń; Adam Shostack — Threat Modeling: Designing for Security; Threat Modeling Manifesto.