Wpisałeś w Google „STRIDE” i prawie wszędzie czytasz to samo: że to metodyka modelowania zagrożeń (ang. threat modeling). Bierzesz diagram, dorzucasz STRIDE i (voilà) masz proces. Niestety, ale tak to nie działa.
Teza, którą tu obronimy, jest prosta. STRIDE to taksonomia zagrożeń (ang. threat taxonomy), czyli system klasyfikacji: lista sześciu kategorii, którymi można opisać dowolną grupę zagrożeń. Używasz jej jako drivera (napędu) burzy mózgów wokół jednego pytania: „co może pójść źle?”. STRIDE to mnemonik z Microsoftu, sześć liter, które podpowiadają Ci, o co pytać. Ale NIE jest metodyką: nie mówi, jak prowadzić sesję ani jak ułożyć proces.
Pójdziemy tak. Po pierwsze: co znaczy ten skrót i jak mapuje się na bezpieczeństwo. Po drugie: jak go realnie używać (i czemu nakładanie się kategorii to dobrze, a nie źle). Po trzecie: czego STRIDE NIE jest (nie jest metodyką, nie jest DFD) i gdzie się wykłada. Zapraszamy do lektury.
Co oznacza skrót STRIDE
STRIDE to akronim sześciu rodzin zagrożeń. I tu jest sedno: każda litera to działanie atakującego, które uderza w konkretną gwarancję bezpieczeństwa. Spoofing (podszywanie się) pozwala złamać uwierzytelnianie; Tampering (manipulacja danymi) — integralność; Denial of service — dostępność. Innymi słowy: litera nie mówi „co się zepsuło”, lecz co atakujący robi, żeby daną gwarancję naruszyć.
| Litera | Zagrożenie (ang. → PL) | Co atakuje | Przykład jednym zdaniem |
|---|---|---|---|
| S | Spoofing — podszywanie się | uwierzytelnianie (ang. authentication) | Ktoś udaje innego użytkownika albo inny serwis. |
| T | Tampering — manipulacja | integralność (ang. integrity) | Modyfikacja danych w tranzycie albo w bazie. |
| R | Repudiation — wyparcie się | niezaprzeczalność (ang. non-repudiation) | Brak logów, więc użytkownik wypiera się akcji. |
| I | Information disclosure — ujawnienie informacji | poufność (ang. confidentiality) | Wyciek danych, IDOR, zbyt gadatliwy komunikat błędu. |
| D | Denial of service — odmowa usługi | dostępność (ang. availability) | Zasób przestaje odpowiadać legalnym użytkownikom. |
| E | Elevation of privilege — eskalacja uprawnień | autoryzacja (ang. authorization) | Zwykły użytkownik robi to, co powinien tylko administrator. |
Drobne, ale ważne rozróżnienie, bo łatwo się tu pogubić. Trzy fundamentalne właściwości bezpieczeństwa systemu to poufność, integralność i dostępność (ang. confidentiality, integrity, availability); dochodzą do nich jeszcze autentyczność i niezaprzeczalność. Uwierzytelnianie i autoryzacja to nie właściwości, lecz mechanizmy, których zadaniem jest tych właściwości pilnować. STRIDE celuje w jedne i drugie: atakujący łamie właściwości, uderzając w mechanizmy, które ich strzegą.
I tu cała elegancja pomysłu: dla każdej gwarancji, którą chcesz utrzymać, STRIDE ma literę mówiącą, co atakujący musi zrobić, żeby ją złamać. Chcesz integralności? Zmierz się z Tamperingiem. Chcesz poufności? Z Information disclosure. Chcesz dostępności? Z Denial of service. I tak przez całą szóstkę. Nie musisz tego wkuwać na pamięć, wystarczy, że rozumiesz tę symetrię.
Skąd się wziął? Powstał w Microsofcie pod koniec lat 90. jako wewnętrzne narzędzie dla inżynierów, żeby mieli o co pytać, dbając o bezpieczeństwo już na etapie projektowania oprogramowania.
STRIDE to taksonomia, której używasz jako drivera — a NIE metodyka
Skoro znamy już litery, obalmy najpopularniejszy mit, jaki krąży na ten temat w sieci.
Mit: „STRIDE to metodyka modelowania zagrożeń”. Nie. STRIDE to taksonomia, czyli system klasyfikacji zagrożeń; tymi sześcioma kategoriami możesz opisać dowolną grupę zagrożeń. Metodyką jest dopiero cały sposób prowadzenia procesu i sesji, jak PASTA czy Agile Threat Modeling. To metodyka mówi, kto siada do stołu, w jakiej kolejności zadajemy pytania i co robimy z wynikiem. STRIDE tego nie robi i nie ma takich ambicji.
Niuans dla dociekliwych, żeby nie wpaść w drugą skrajność: STRIDE wchodzi w skład metodyki. Metodyki takie jak Agile Threat Modeling (ATM) czy Rapid Threat Model Prototyping (RTMP) narzucają preferowany driver sesji; akurat ATM preferuje właśnie STRIDE. Czyli: STRIDE nie jest metodyką, ale bywa jej częścią.
Czym więc STRIDE jest? Jest driverem sesji: sześcioma podpowiedziami, które rozruszają burzę mózgów wokół „co może pójść źle?”. Nie odpowiada za proces (od tego jest cały proces modelowania zagrożeń). Nie odpowiada za prowadzenie sesji (od tego jest sama sesja krok po kroku). Nie odpowiada za reprezentację systemu (od tego jest diagram przepływu danych). STRIDE to podpowiadacz pytań, nie szuflada na odpowiedzi.
I tu kryje się jego największa zaleta. STRIDE jest demokratyczny: każdy może go użyć. Nie musisz myśleć jak doświadczony atakujący; wystarczy, że przejdziesz przez sześć liter i przy każdej zapytasz: a co tu z S? a co z T? To zupełnie inny próg wejścia niż drzewa ataków (ang. attack trees), które wymagają eksperckiej wyobraźni ofensywnej. Tutaj wystarczy lista i odrobina dyscypliny.
Nie jesteśmy w tym osamotnieni. Jak ujął to Filip Brandt, architekt bezpieczeństwa BNP Paribas, na The Hack Summit 2024: „Wykorzystujemy STRIDE jako narzędzie. To nie jest metodyka. STRIDE nie mówi, jak przeprowadzać sesję… To mnemonik, który wskazuje potencjalne rodziny zagrożeń.” Dokładnie o to chodzi. To narzędzie w procesie, nie sam proces.
Mamy do tego jedną analogię w rękawie, bo dobrze tu pasuje. STRIDE to jak lista kontrolna pilota przed startem. Nie jest planem lotu i nie jest samolotem. To sześć pozycji, które przelatujesz po kolei, żeby nic istotnego nie umknęło. Pilot nie kłóci się, czy „sprawdzenie klap” należy do kategorii A czy B. Odhacza i leci dalej. I to nas prowadzi prosto do drugiej kontrowersji.
Redundancja jest cechą, nie błędem
Jednym z częstych błędów początkujących jest to, że znajdują zagrożenie, które pasuje i do S (Spoofing), i do E (Elevation of privilege)… i utykają na pół godziny, debatując, gdzie je „właściwie” przypisać. To czysta strata czasu.
Jeśli zagrożenie pasuje do S i do E: zapisz je RAZ i idź dalej. Liczy się liczba znalezionych zagrożeń, a nie idealna klasyfikacja.
Czemu? Ponieważ cel sesji to znaleźć jak najwięcej tego, co może pójść źle, a nie zbudować nieskazitelnie czysty katalog. Taksonomii używasz luźno, jak promptu do burzy mózgów, a nie jak sztywnej szafki na akta, do której trzeba „idealnie” posortować każde znalezisko. Redundancja, czyli nakładanie się kategorii, jest CECHĄ STRIDE, a nie błędem. To sieć z zakładką: jedno zagrożenie łapie się na kilka liter naraz, więc trudniej je przeoczyć. Im więcej liter „świeci” na dane znalezisko, tym mniejsza szansa, że umknie. „Sztywna szafka na akta” to antywzorzec; nie debatuj, zapisz raz i jedź dalej.
Branża się z tym zgadza, to nie nasze prywatne widzimisię; podobnie patrzą na to autorzy podejść takich jak RTMP czy Agile Threat Modeling (więcej w tekście o metodach modelowania zagrożeń).
I jeszcze jedno, żeby zdjąć z Ciebie presję: nie martw się o kompletność. Jedna sesja daje tylko częściowy widok systemu. I to jest OK. Wrócisz do tematu następnym razem, z innego kąta. Mała dawka, ale często.
STRIDE by element czy by flow?
Skoro już wiemy, że STRIDE napędza sesję, pojawia się praktyczne pytanie: jak konkretnie przez niego przechodzić? Są dwa tryby.
STRIDE-per-element (by element): bierzesz każdy element diagramu po kolei (proces, magazyn danych, encję zewnętrzną, przepływ danych) i pytasz o litery, które do niego pasują. STRIDE-per-interaction (by flow): analizujesz każdą interakcję, każdy przepływ między elementami z osobna.
Na czym polega różnica w praktyce? Elementów na diagramie jest tyle, ile jest; przechodzisz przez nie po kolei i kończysz. Ale interakcji między nimi bywa znacznie więcej: element A może wołać do B (i to na kilka różnych sposobów), B odpowiada A, dochodzą połączenia z elementem C… Im więcej elementów, tym liczba interakcji rośnie znacznie szybciej niż liczba samych elementów. Dlatego per-element zwykle domkniesz szybciej, a per-interaction łapie więcej szczegółu, kosztem czasu.
Który wybrać? Nie zostawimy Cię w „to zależy”, podamy kierunek. W praktyce, na poziomie aplikacji, per-element jest prostszy i szybszy dla zespołu i zwykle właśnie od tego zaczynamy. Zaznaczmy uczciwie: to praktyczny default, nasz nawyk z boju, a nie formalna doktryna wyryta w kamieniu. Per-interaction bywa dokładniejszy, ale jest ciężki i czasochłonny; zostaw go tam, gdzie naprawdę warto, czyli przy krytycznych integracjach.
Jeszcze drobiazg, który podpowie Ci zdrowy rozsądek: nie każdy element łapie wszystkie sześć liter. Encja zewnętrzna (na przykład użytkownik) nie podlega Tamperingowi w tym samym sensie co magazyn danych. To naturalne. STRIDE podpowiada, ale nie zmusza.
By-element = prościej i szybciej dla zespołu (nasz domyślny wybór); by-flow = dokładniej, ale tylko tam, gdzie warto.
STRIDE to nie DFD (driver kontra notacja)
Tu dochodzimy do drugiego wielkiego pomieszania pojęć, jakie krąży w internecie. Ludzie wrzucają STRIDE i DFD do jednego worka: „proces modelowania zagrożeń to DFD plus STRIDE i tyle”. To dwie różne rzeczy, które współpracują, a nie synonimy.
DFD (ang. Data Flow Diagram), czyli diagram przepływu danych, to notacja. To rysunek systemu, mapa „nad czym pracujemy” (jak ją narysować, opisujemy w osobnym tekście o DFD). STRIDE to driver — zestaw podpowiedzi do pytania „co może pójść źle?”. Jedno to teren narysowany na mapie. Drugie to lista pytań, które zadajesz, patrząc na tę mapę.
I tu rzecz, która pokazuje to dobitnie: te dwie rzeczy nie są ze sobą zrośnięte na stałe. Mając gotowy DFD, możesz puścić po nim zupełnie inny driver — choćby bibliotekę ataków jak OWASP Top 10. A samego STRIDE możesz użyć na innej reprezentacji systemu: na PFD, na diagramie C4, na zwykłym diagramie architektury, a nawet na spisanej liście wymagań (i to też będzie modelowanie zagrożeń). Działają w parze, ale nie muszą. I właśnie dlatego warto je rozróżniać.
Mantra, która to porządkuje: mapa to nie teren. DFD jest mapą systemu; STRIDE jest sposobem, w jaki tę mapę przepytujemy. Po samą notację zajrzyj do tekstu o DFD; jak to wszystko spina się w jedną sesję — do tekstu o sesji krok po kroku.
DFD mówi CO masz; STRIDE mówi O CO PYTAĆ. Nie myl notacji z driverem.
Konkretne przykłady: jak STRIDE wygląda w boju
Teoria teorią, ale STRIDE ma sens dopiero w robocie. Weźmy trzy przykłady z naszego doświadczenia. Każdy pokazuje to samo: jedno zagrożenie często „świeci” na kilku literach naraz, i właśnie dlatego ta siatka działa.
DoS przez bcrypt z nielimitowanym wejściem (D). Używasz bcrypt do haszowania haseł (dobra praktyka, brawo). Ale nie limitujesz długości wejścia. Ktoś wysyła ogromny payload, bcrypt rzuca się na niego całym procesorem, CPU pada i masz Denial of service. To klasyk, którego rada „myśl jak atakujący” łatwo nie wyłapie, a sześć liter STRIDE owszem: przy literze D po prostu pytasz „czym ktoś może nas tu położyć?”. Uczciwie: większość dzisiejszych implementacji bcrypta rozwiązuje to już na poziomie biblioteki: programista korzystający z bcrypta (np. w Javie) nie musi sam skracać wejścia, bo biblioteka robi to za niego pod spodem. Ale to nie znaczy, że taka podatność nie może pojawić się poziom niżej. Realny przypadek: Django w 2013 roku, DoS przez bardzo długie hasło podawane do bcrypta; poprawką było ograniczenie długości hasła. To CVE-2013-1443, opisane w oficjalnym advisory Django.
IDOR to Information disclosure (I), niekoniecznie eskalacja. IDOR (ang. Insecure Direct Object Reference): podmieniasz id=123 na id=124 w żądaniu i widzisz cudze dane. Pierwsza litera, która tu się zapala, to I (ujawnienie informacji), choć ktoś inny zaklasyfikowałby to jako E (eskalacja). I co robisz? Zapisujesz raz, idziesz dalej. Patrz: redundancja jest cechą, nie błędem. Niuans przy okazji: to, że dostawca tożsamości potwierdza, KIM jesteś, nie znaczy jeszcze, że pilnuje, CO wolno Ci robić. Uwierzytelnianie to nie autoryzacja, a IDOR i tak jest Twoim problemem do rozwiązania.
XXE, które przechodzi w DoS (T / I / D). XXE (ang. XML External Entity) zaczyna się jako manipulacja parsera XML (T), może doprowadzić do ujawnienia plików z serwera (I) i położyć usługę atakiem typu „billion laughs” (D). Jedno zagrożenie, trzy litery. I znowu ta sama zasada: nie debatuj, do której „naprawdę” należy, zapisz i leć dalej.
W boju zagrożenia rzadko siedzą w jednej szufladzie — i właśnie dlatego STRIDE działa jako siatka, a nie jako system segregacji.
Gdzie STRIDE się wykłada (i czym go uzupełnić)
STRIDE nie jest uniwersalny. Na poziomie infrastruktury i całej organizacji pasuje słabo: sześć liter pomyślanych do pytania „co może pójść źle z tym procesem albo przepływem danych” nie obejmuje dobrze portfolio systemów, ludzi (a więc socjotechniki) ani ryzyka biznesowego. To po prostu nie ta skala.
Czym go wtedy uzupełnić? Bibliotekami ataków (ang. attack libraries), czyli konkretnymi, domenowymi listami zagrożeń. Reguła doboru jest prosta i zależy od poziomu, na którym działasz:
- organizacja → MITRE ATT&CK,
- system → OWASP Top 10 for Kubernetes / for CI-CD (zależnie od tego, gdzie żyje system),
- aplikacja → OWASP Top 10,
- funkcjonalność → CWE Top 25 (uwaga: OWASP Top 10 i CWE Top 25 są na innym poziomie logicznym, nie stosuj ich zamiennie),
- systemy AI → OWASP LLM Top 10.
Tutaj wystarczy zasada doboru.
STRIDE jest generyczny i demokratyczny — pasuje na poziomie systemu, aplikacji i funkcjonalności; biblioteki są domenowe i konkretne. Najlepsze pokrycie daje STRIDE plus właściwa biblioteka do poziomu, na którym działasz.
Na którym poziomie używać STRIDE?
Krótko, bo pełną macierz „poziom × rola × driver × artefakt” mamy w artykule o poziomach modelowania zagrożeń. STRIDE jest natywny na poziomie systemu, aplikacji i funkcjonalności: tam, gdzie pracują architekci, programiści i Security Championi. DFD plus STRIDE jako driver sesji na poziomie systemu i aplikacji; lekki STRIDE albo abuse stories (historyjki z perspektywy atakującego) w sprincie na pojedynczą funkcję.
Na poziomie organizacji (infrastruktury) STRIDE pasuje słabo, bo zakres obejmuje całe portfolio systemów, ludzi i ryzyko biznesowe; a tam lepszym driverem jest MITRE ATT&CK. Ale uwaga: to gradient, nie sztywne ściany. Im bliżej dewelopera i kodu, tym lepiej STRIDE leży.
STRIDE to narzędzie poziomu systemu, aplikacji i funkcjonalności — im bliżej dewelopera, tym lepiej pasuje; na poziomie organizacji zastąp go biblioteką ataków.
Co robić, jak żyć?
Zbierzmy to w pięć kroków (plus jeden opcjonalny):
- Narysuj system jako DFD. To Twoja mapa „nad czym pracujemy” (jak to zrobić).
- Przejdź per-element przez sześć liter STRIDE, pytając przy każdej „co może pójść źle?” (jak prowadzić sesję).
- (opcjonalnie) Dorzuć bibliotekę ataków dopasowaną do poziomu, np. OWASP Top 10 dla aplikacji, a na infrastrukturze MITRE ATT&CK. To uzupełnia STRIDE o konkretne, domenowe zagrożenia.
- Zapisuj każde zagrożenie RAZ. Pasuje do dwóch liter? Trudno, idziesz dalej. Redundancja jest cechą.
- Wynik to nie ładny katalog, tylko konkretne akcje w backlogu w jednym z pięciu formatów (co zrobić z wynikami sesji).
- Nie celuj w kompletność. Wróć z innego kąta następnym razem. Mała dawka, ale często.
Bo bezpieczeństwo to proces, nie produkt — a STRIDE pomaga ten proces wzmacniać. Jest narzędziem w procesie, nie celem samym w sobie.
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; Microsoft (geneza STRIDE, koniec lat 90.); OWASP; MITRE ATT&CK.