Na naszych warsztatach z modelowania zagrożeń (ang. threat modeling) jedno pytanie wraca jak bumerang: „A jakiego narzędzia powinniśmy używać?”. Czasem pada też w drugiej wersji: „A jakiego narzędzia używają inni?”.

Na warsztacie przedstawiamy kilka narzędzi, ale wyboru nie narzucamy, bo to nie my będziemy z nim potem żyć. Jeśli nie odpowiadamy w organizacji za wdrożenie i projekt procesu, możemy najwyżej podpowiedzieć, w którą stronę sami byśmy poszli. I właśnie tym jest ten artykuł: naszą podpowiedzią, z werdyktami z wdrożeń.

Jedno ustalmy od razu, bo rynek chętnie sugeruje co innego. Modelowanie zagrożeń to nie jest coś, co się kupuje i instaluje. Narzędzie skaluje proces, ale go nie zastąpi. A jeśli procesu nie ma, narzędzie wyskaluje jego brak; pisaliśmy o tym przy okazji procesu modelowania zagrożeń. Dlatego wybór narzędzia to jedna z ostatnich decyzji w budowaniu praktyki, nie pierwsza.

Plan artykułu jest taki: najpierw kryteria wyboru, potem przegląd narzędzi z werdyktami (od tablicy, przez draw.io, po platformy komercyjne), a na końcu gotowe zestawy na 4 typowe scenariusze. Zapraszamy do lektury.

Zanim porównasz narzędzia, ustal, do czego mają służyć

Kiedy budowaliśmy proces modelowania zagrożeń w dużej instytucji finansowej, spisaliśmy sobie listę kryteriów wyboru narzędzia. Jakiś czas później trafiliśmy na taksonomię narzędzi z pracy IEEE z 2022 roku. Okazało się, że to zasadniczo ta sama lista. Skoro 2 niezależne drogi prowadzą do tych samych pytań, warto je zadać i u siebie:

1. Forma modelu. Diagram, tekst czy kod? Forma musi pasować do notacji, którą zespół zna; samą notację rozkładamy przy diagramie przepływu danych.
2. Reużywalność. Czy model da się wersjonować, kopiować między zespołami i aktualizować po zmianie architektury?
3. Biblioteka zagrożeń w środku. Czy narzędzie podpowiada zagrożenia, czy jest pustą kartką? Co konkretnie może podpowiadać i na jakim poziomie, sprawdzisz w tekście o bibliotekach ataków.
4. Sugestie mitygacji. Czy narzędzie mówi też, co z zagrożeniem zrobić, czy tylko je kataloguje?
5. Integracja z SDLC. Czy wynik trafia do backloga, czy umiera w narzędziu? Na koniec dnia liczą się akcje w backlogu, nie ładny katalog.

A nad tym wszystkim stoi jedno kryterium nadrzędne: czy zespół będzie w tym narzędziu ŻYŁ. Artefakty muszą mieszkać tam, gdzie organizacja realnie na to pozwala. W tym samym wdrożeniu wybraliśmy MS Whiteboard zamiast „lepszego” Miro z jednego powodu: był sankcjonowany, więc modele nie stały się shadow IT.

Od razu zastrzegamy: nie będziemy niżej punktować narzędzi tą listą. Taka ocena ma sens dopiero w konkretnej organizacji, przy jej poziomach i jej procesie. Potraktuj listę jako pomoc we własnej decyzji, a nasze werdykty jako doświadczenie z boju, nie ranking.

Najlepsze narzędzie to to, w którym zespół zostanie po trzeciej sesji.

Poziom zero: tablica, karteczki i aparat

Zacznijmy od odpowiedzi, która rozczarowuje na warsztatach, a wygrywa w praktyce. Sesja modelowania zagrożeń nie potrzebuje żadnego softu. Wystarczy tablica (fizyczna albo online’owa), karteczki i aparat w telefonie. Jak poprowadzić na tym pełną sesję, pokazujemy w przewodniku po sesji krok po kroku. A zdjęcie tablicy to pełnoprawny model zagrożeń na poziomie aplikacji, bo forma artefaktu zależy od poziomu, nie od ambicji.

Poziom zero w akcji: flipchart, karteczki i pisak. Zdjęcie z naszych warsztatów z modelowania zagrożeń.

Kiedy tablica wygrywa? Przez pierwsze miesiące praktyki, gdy zespół siedzi w jednym pokoju albo na jednym boardzie i modeluje aplikację czy pojedyncze funkcjonalności. Kiedy przestaje wystarczać? Gdy zespołów robi się więcej i potrzebna jest wspólna notacja, gdy model trzeba wersjonować, gdy audytor pyta o rejestr modeli.

Że prostota skaluje się dalej, niż myślisz, pokazuje GitLab. Ich proces modelowania zagrożeń, zbudowany na bazie metodyki PASTA, trzyma modele w zwykłych plikach markdown w repozytorium: prostota ponad wyszukane diagramy, świadomie i na skalę całej firmy.

Tablica to nie brak narzędzia, tylko narzędzie z najniższym progiem wejścia, jakie istnieje.

draw.io: nasz wybór

Gdy tablica przestaje wystarczać, naszym domyślnym wyborem jest draw.io (formalnie: diagrams.net). Powody są 3 i wszystkie są prozaiczne. Po pierwsze: w polskich organizacjach ludzie po prostu z niego korzystają, choćby do diagramów architektury i innych projektów, więc nie wprowadzasz nowego narzędzia, tylko nowy szablon do znanego. Po drugie: ma gotowy szablon DFD i threat modelingu. Po trzecie: model żyje jako plik, więc dokładasz go do repozytorium aplikacji albo do dokumentacji systemu na Confluence i wersjonujesz razem z resztą wiedzy o systemie.

Szablon threat modelingu w draw.io: przepływy, granice zaufania i legendy z assetami, zabezpieczeniami i aktorami. Ten sam przykładowy system, na którym rozkładamy DFD w osobnym tekście.

Na marginesie, bo w większych organizacjach ten wątek wraca: w Polsce spotkasz też Enterprise Architecta, popularne narzędzie do rysowania architektury, które ma również klocki do modelowania zagrożeń. Z naszej praktyki: do tej roboty jest zbyt toporny. A w wielu organizacjach, które go kupiły, realnie nie jest używany nawet do architektury. Draw.io widzieliśmy stosowany naprawdę, nie tylko na papierze. I to przesądza.

Draw.io wygrywa nie funkcjami, tylko tym, że już jest w organizacji, a model w pliku żyje przy systemie.

Popularne w poradnikach, u nas odradzane: Threat Dragon i MS TMT

Pora na 2 narzędzia, które znajdziesz w niemal każdym poradniku „jak zacząć threat modeling”, po polsku i po angielsku. Wymienia je nawet GitHub we wpisie o tym, jak sam modeluje zagrożenia. Właśnie dlatego jesteśmy Ci winni jasny werdykt.

OWASP Threat Dragon to open source’owy edytor diagramów zagrożeń. Brzmi dobrze, ale z naszej perspektywy nie daje nic ponad to, co draw.io, a dokłada złożoności i toporności. Całość sprawia wrażenie projektu, który bardziej istnieje, niż realnie służy zespołom. Odradzamy. Skoro i tak modelujesz na diagramie, zrób to w narzędziu, które organizacja już zna.

Microsoft Threat Modeling Tool (TMT) jest ciekawszy. To darmowe narzędzie z ekosystemu Microsoftu. Model budujesz od zera na wbudowanych stencilach (gotowych klockach): domyślnie są tam zestawy dla Azure i Windowsa oraz kilka bardziej generycznych. Po rozrysowaniu systemu narzędzie GENERUJE listę zagrożeń wynikających z użytych komponentów, w logice STRIDE. Własną bibliotekę stencili teoretycznie da się dobudować, ale nikt tego nie robi, bo dokłada złożoności: najpierw przy budowie, potem przy utrzymaniu. Częściowa automatyzacja robi wrażenie. Są jednak 2 „ale”: TMT wymaga Windowsa, a przede wszystkim jest toporny. Mnóstwo poradników go poleca, ale ani razu nie widzieliśmy, żeby jakiś zespół używał go zwinnie i z realnym pożytkiem.

Microsoft Threat Modeling Tool: z rozrysowanego diagramu narzędzie samo wygeneruje listę zagrożeń według STRIDE. Źródło: dokumentacja Microsoft Learn.

Jest jeden uczciwy wyjątek: compliance. Jeśli Twoim głównym celem jest POSIADANIE modeli zagrożeń, bo wymaga ich audyt, TMT zrobi robotę. Rozrysowujesz system, generujesz model, odkładasz do dokumentacji i przy zewnętrznym audycie pokazujesz czarno-na-białym, że modele są. W każdym innym scenariuszu: raczej nie.

Popularność w poradnikach to nie werdykt z boju: oba narzędzia produkują artefakt, żadne nie buduje praktyki.

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

Threat modeling as code: pytm i Deciduous

Zespoły, które wszystko trzymają w repozytorium, mają trzecią drogę: model zagrożeń jako kod. Piszesz model tekstem, narzędzie generuje z niego diagramy i raporty, a całość wersjonujesz jak każdy inny kod. Model aplikacji żyje wtedy w repozytorium tej aplikacji i zmienia się razem z nią.

Warto tu znać 2 narzędzia, bo różnią się tym, co generują. pytm to klasyka: opisujesz system w Pythonie, a narzędzie generuje diagram z elementami i raport zagrożeń, czyli odpowiednik STRIDE stosowanego element po elemencie. Deciduous generuje co innego: drzewa ataków. A te, jak pokazaliśmy w tekście o metodach modelowania zagrożeń, są zasadniczo innym spojrzeniem na system. Ciekawe, że oba podejścia mają dziś swoje narzędzia oparte na kodzie. Istnieją też Threagile i Threatspec; odnotowujemy je bez werdyktu, bo nie znamy ich z boju.

Deciduous: po lewej drzewo opisane tekstem, po prawej to, co narzędzie z niego generuje. To samo drzewo pokazujemy w tekście o metodach modelowania zagrożeń, tam bez kodu.

Ceną za wersjonowanie jest krzywa uczenia, bo składni trzeba się nauczyć. Tyle że tu sporo zmieniły LLM-y: opisujesz system po ludzku, a model językowy ogarnia składnię za Ciebie. Można pójść o krok dalej i próbować utrzymywać model zagrożeń LLM-em na podstawie zmieniającej się architektury aplikacji. To wciąż podejście dla zespołów o inżynierskiej kulturze, ale próg wejścia właśnie zjechał w dół.

Model as code wygrywa tam, gdzie zespół już traktuje wszystko jako kod. I tylko tam.

Komercyjne: IriusRisk i spółka

Na końcu spektrum siedzą platformy komercyjne, z IriusRiskiem na czele. Myśl o nim jak o enterprise’owym rozwinięciu pomysłu z TMT: biblioteka setek zagrożeń, kwestionariusze, integracja z Jirą. Problem w tym, że rozwinięcie pomysłu oznacza też rozwinięcie jego wad.

Nasze doświadczenie z dużego wdrożenia jest jednoznaczne. IriusRisk może pasować do trybu globalnego, ale na pewno nie do iteracyjnego. Jest zamknięty w GUI i w praktyce wymusza obecność bezpiecznika przy każdej sesji, więc zespoły deweloperskie wyłączają się, zanim zobaczą wartość. Jest drogi; licencjonowanie per model przy skali dużej organizacji robi się realnie zaporowe. Jest trudny w utrzymaniu. A przede wszystkim jest skupiony na tym, żeby zbudować artefakt i móc się nim pochwalić, a nie na tym, żeby zespół zaczął myśleć o zagrożeniach na etapie projektowania. To zresztą wspólny mianownik TMT, Threat Dragona i IriusRiska: celem jest produkcja artefaktu, nie zmiana myślenia zespołu.

IriusRisk: podobnie jak z MS TMT, tutaj również model powstaje z gotowych klocków i stref zaufania. Źródło: materiały producenta.

Kiedy platforma komercyjna ma sens? Duża organizacja, tryb globalny, twarde wymogi rejestru i compliance, osobny zespół bezpieczeństwa jako operator narzędzia.

Platforma komercyjna automatyzuje TWÓJ proces. Jeśli procesu nie ma, automatyzuje jego brak.

Zestawy na 4 scenariusze

Zbierzmy werdykty w gotowe zestawy:

1. Mały zespół, start praktyki: tablica (fizyczna albo online’owa) plus aparat. Koniec zestawu. Niczego więcej nie potrzebujesz, dopóki praktyka nie okrzepnie.
2. Zespoły z Security Championami, tryb iteracyjny: draw.io. Dostajesz wspólną notację między zespołami, różne spojrzenia na system i artefakt, który modyfikujesz przy okazji kolejnych sesji. Do tego biblioteka ataków dobrana do poziomu i technologii.
3. Kultura inżynierska, wszystko jako kod: pytm albo Deciduous, zależnie od tego, czy zespół myśli diagramem z elementami, czy łańcuchami ataku.
4. Enterprise, tryb globalny i compliance: MS TMT albo IriusRisk, ze świadomością ich celu (artefakt) i z operatorem po stronie bezpieczeństwa. Jest tu też opcja, którą łatwo przeoczyć: Deciduous. Drzewa ataków dla najbardziej krytycznych systemów, budowane w trybie globalnym, to naturalny sposób pracy tam, gdzie sięga się po cięższe metodyki w rodzaju PASTA.

Na koniec antywzorzec, który spina wszystkie 4 scenariusze: jedno narzędzie na wszystkie poziomy. Możesz tak zrobić, ale wtedy świadomie akceptujesz trade-offy, bo żadne pojedyncze narzędzie nie będzie idealne na każdym poziomie i dla każdej roli; dlaczego tak jest, tłumaczymy przy poziomach modelowania zagrożeń. Jak coś jest do wszystkiego, to jest do niczego.

Dobierz narzędzie do poziomu i kultury zespołu, nie odwrotnie.

Co robić, jak żyć?

Zbierzmy to w 5 praktycznych kroków:

1. Zrób pierwszą sesję bez żadnego nowego narzędzia. Tablica, karteczki, aparat. Nic więcej.
2. Daj artefaktom dom, który organizacja sankcjonuje. Lepszy sankcjonowany MS Whiteboard niż shadow IT w ładniejszym narzędziu.
3. Po 2–3 sesjach dobierz narzędzie według kryteriów z początku tekstu. Dla większości zespołów wynik będzie brzmiał: draw.io.
4. Platformę komercyjną rozważaj dopiero wtedy, gdy proces działa i dławi się skalą. Nie wcześniej.
5. Nie kupuj narzędzia „na zachętę”. Zachętą jest wynik sesji w backlogu, nie nowa ikonka na pulpicie.

Bo narzędzie skaluje proces, ale go nie zastąpi: najpierw praktyka, potem software.

Do zapamiętania — FAQ

Jakie narzędzie do modelowania zagrożeń wybrać na start?

Żadne nowe. Tablica (fizyczna albo online’owa) i aparat w telefonie w zupełności wystarczą na pierwsze sesje. Narzędzie dobiera się do działającego procesu, nie zamiast niego; drugim krokiem dla większości zespołów jest draw.io z szablonem DFD.

Czy są dobre darmowe narzędzia do modelowania zagrożeń?

Tak: draw.io (uniwersalny, z szablonem threat modelingu, model żyje jako plik przy repo), a w podejściu as-code pytm (model w Pythonie) i Deciduous (drzewa ataków jako kod). Microsoft Threat Modeling Tool ewentualnie, jeśli Twoim celem są modele pod compliance; poza tym scenariuszem go odradzamy.

Co to jest threat modeling as code?

Model zagrożeń zapisany jako kod w repozytorium: w pytm opisujesz system w Pythonie i generujesz diagram z zagrożeniami, w Deciduous opisujesz tekstem drzewo ataku. Zaletą jest wersjonowanie razem z aplikacją, a próg wejścia (składnię) skutecznie obniżają dziś LLM-y.

Czy IriusRisk się opłaca?

W dużej organizacji, w trybie globalnym, z twardymi wymogami compliance i osobnym operatorem po stronie bezpieczeństwa: może się bronić. W trybie iteracyjnym, z zespołami deweloperskimi: z naszego doświadczenia nie, bo zespoły wyłączają się, zanim zobaczą wartość.

Czy Excalidraw albo Miro nadają się do modelowania zagrożeń?

Tablica online’owa w zupełności wystarczy, pod jednym warunkiem: musi być sankcjonowana przez organizację. Artefakt modelowania ma żyć w miejscu, które organizacja akceptuje; inaczej praktyka produkuje shadow IT zamiast bezpieczeństwa.

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: IEEE (2022) — taksonomia narzędzi do modelowania zagrożeń; GitHub — How we threat model (github.blog); GitLab — Creating a threat model that works for GitLab (about.gitlab.com); diagrams.net (draw.io); OWASP Threat Dragon; Microsoft Threat Modeling Tool; pytm (OWASP); Threagile; Threatspec; Deciduous (deciduous.app); IriusRisk.