Wpisz w wyszukiwarkę „modelowanie zagrożeń” i przejrzyj kilka pierwszych wyników. Niemal wszystko, co znajdziesz (artykuły, szkolenia, prezentacje), opisuje SESJĘ: spotkanie, diagram, karteczki, STRIDE. Jakby poza tym jednym spotkaniem nie istniało nic więcej.
A potem organizacja robi jedną świetną sesję… i po kwartale nikt nie pamięta, po co była, gdzie leży jej wynik ani kiedy miała być następna. Tak wygląda sesja bez procesu modelowania zagrożeń.
Teza tego artykułu jest prosta: rynek sprzedaje Ci sesję, a wygrywa się procesem. Pod hasłem „modelowanie zagrożeń” (ang. threat modeling) kryją się trzy różne rzeczy, które branża notorycznie zlewa w jedno: proces, sesja i model. Rozplączemy je w trzech krokach. Po pierwsze: co jest czym i do kogo należy. Po drugie: skąd ta zbitka i ile kosztuje. Po trzecie: z czego składa się proces, czyli warstwa, której prawie nikt nie opisuje. Zapraszamy do lektury.
Trzy słowa, jedna zbitka
Zacznijmy od definicji, bo dobre definicje od razu ustawiają całą resztę.
Proces modelowania zagrożeń żyje na poziomie organizacji i odpowiada na pytania: jak często modelujemy, dla których systemów, kto uczestniczy, co z tego powstaje, gdzie ten wynik żyje i jak zasila resztę pracy (testy bezpieczeństwa, backlog, analizę ryzyka). Proces jest praktyką rozpiętą w czasie, a nie wydarzeniem w kalendarzu. Nie odhaczasz go, tylko utrzymujesz.
Sesja modelowania zagrożeń to jedna instancja robocza: konkretne spotkanie, na którym zespół patrzy na reprezentację systemu i przepuszcza ją przez driver, na przykład STRIDE. Sesję da się zaplanować, zmieścić w 90 minutach i przeprowadzić krok po kroku. To jest ta fotogeniczna część z karteczkami.
Model zagrożeń to artefakt, który (czasem) z sesji wychodzi. Jego forma zależy od poziomu, na którym modelujesz: od formalnego dokumentu, przez zdjęcie tablicy, po… nic. Na poziomie pojedynczej funkcjonalności formalnego modelu często w ogóle nie ma; z sesji wychodzą kryteria akceptacji i wpisy do backloga, i to jest w porządku (pełna macierz poziomów).
Zbierzmy to w tabelę, bo kontrast widać najlepiej obok siebie:
| Proces | Sesja | Model | |
|---|---|---|---|
| Czym jest | praktyką organizacji | jednym spotkaniem roboczym | artefaktem (bywa opcjonalny) |
| Na co odpowiada | jak, kiedy, dla kogo i po co modelujemy | „co może pójść źle?" tu i teraz | co ustaliliśmy i co przekazujemy dalej |
| Kto jest właścicielem | dział bezpieczeństwa | facylitator z zespołem | zależnie od poziomu |
| Horyzont czasowy | miesiące i lata | godziny | do następnej aktualizacji |
Analogia: restauracja
Mamy analogię w rękawie, bo dobrze tu pasuje. Sesja to jeden serwis: konkretny wieczór, zespół przy kuchni, na stoły wychodzą dania. Da się go poprowadzić lepiej lub gorzej, ale zawsze jest punktowy.
Proces to cała restauracja: menu, dostawy, grafik zmian, standardy. To restauracja decyduje, czy serwis w ogóle się odbywa, dla kogo gotujemy i po co. Bez niej najlepszy kucharz zrobi jedną dobrą kolację, po czym lokal stoi ciemny do odwołania.
A model? Model to karta dania z przepisem. Przy daniach popisowych przepis bywa spisany krok po kroku, bo odtwarza go cała zmiana. Przy prostych daniach kucharz gotuje z głowy i nikogo to nie oburza.
Nikt rozsądny nie ocenia restauracji po jednym serwisie, z pominięciem menu i dostaw. Nie oceniaj praktyki bezpieczeństwa po jednej sesji.
Skąd ta zbitka? Bo rynek opisuje tylko sesję
Diagnoza jest dość niewygodna. Materiały o modelowaniu zagrożeń niemal zawsze uczą prowadzenia SESJI. I trudno się dziwić: facylitacja jest dobrze opisana w branży (choćby w nurcie Agile Threat Modelling), a samo spotkanie jest wdzięcznym tematem. Karteczki dobrze wyglądają na zdjęciach.
Proces wygląda przy tym nudno. Kalendarz, właściciel, rejestr artefaktów, przeglądy. Żadnych karteczek.
Gdzie w takim razie powstaje wartość? Obniżenie kosztu bezpieczeństwa bierze się z proaktywności: z tego, że unikasz zagrożeń na etapie projektu, zanim zamienią się w kosztowne podatności. Ale żeby ta proaktywność objęła więcej niż jeden wycinek systemu, potrzebny jest rytm. Pojedyncza sesja daje częściowy obraz i to jest w porządku, o ile istnieje proces, w którym powstanie kolejny kawałek. Mała dawka, ale często: dopiero powtarzalność stopniowo pokrywa przestrzeń zagrożeń. Bez procesu „częściowy obraz” nigdy nie doczeka się ciągu dalszego.
Jedna sesja bez procesu to event. Proces bez sesji to teoria. Wygrywa rytm.
Z czego składa się proces (ta warstwa, której nikt nie opisuje)
Dobra wiadomość: proces modelowania zagrożeń nie jest projektem na rok. To siedem decyzji, które podejmujesz raz, a potem ich pilnujesz.
- Wyzwalacze. Kiedy modelujemy? U nas sprawdza się krótka lista: nowy system, duża zmiana architektury (na przykład migracja do chmury), nowa integracja. Do tego dochodzi rytm bieżący: wycinek sprintu na to, co właśnie budujesz.
- Zakres i poziomy. Które systemy obejmujemy i na których poziomach: od organizacji po pojedynczą funkcjonalność. Prosty klucz doboru na start: zaczynaj tam, gdzie krzyżują się krytyczność biznesowa i ekspozycja, czyli od systemów, które przetwarzają ważne dane i wystawiają je na świat (poziomy modelowania zagrożeń).
- Ludzie i właściciel. Kto uczestniczy natywnie na którym poziomie i, co ważniejsze, kto jest WŁAŚCICIELEM procesu. Tego nauczyliśmy się w boju: dział bezpieczeństwa musi zaprojektować proces i być jego właścicielem; zrzucenie całości na Security Championów kończy się dryfem.
- Tryby. Co robimy globalnie (punktowo, kompletnie, rzadziej), a co iteracyjnie (mało, ale często, w rytmie zmian). Na wyższych poziomach naturalny jest tryb globalny, im bliżej kodu, tym mocniej wygrywa iteracyjny.
- Artefakty i ich dom. Co powstaje na którym poziomie i gdzie ŻYJE. Zasada jest jedna: artefakt musi mieszkać tam, gdzie pasuje to organizacji, czyli w narzędziach, które ona realnie akceptuje. Najfajniejsza tablica świata nie pomoże, jeśli stoi poza oficjalnym obiegiem: wynik sesji, do którego organizacja nie ma dostępu, z jej perspektywy nie istnieje.
- Zasilanie reszty. Model trafia do testerów bezpieczeństwa, którzy go walidują i wzbogacają; wyniki sesji lądują w backlogu w konkretnych formatach; formalny artefakt bywa wkładką do analizy ryzyka i wymogów regulacyjnych. Proces, który niczego nie zasila, jest sztuką dla sztuki.
- Miara. Czwarte pytanie („Czy zrobiliśmy to wystarczająco dobrze?”) domyka nie sama sesja, lecz przegląd backloga po ~30 dniach. A czym mierzyć sam proces? Klasyczna odpowiedź konsultanta brzmi: to zależy. Od organizacji, od kontekstu, od celu, który ustalisz z biznesem. Nie zostawimy Cię jednak bez kierunku: na start wystarczy najprostsza miara, czyli przyrost samych modeli zagrożeń (pokrycie systemów krytycznych). Potem iterujesz proces i wraz z jego dojrzałością wprowadzasz kolejne miary.
Proces to siedem decyzji podjętych raz i pilnowanych, a nie siedem spotkań.
Model zagrożeń: artefakt, nie cel
Skoro proces i sesja są odplątane, zostaje trzeci element zbitki. „Chwila, przecież prawdziwe modelowanie musi kończyć się dokumentem?” Właśnie nie musi.
Forma artefaktu zmienia się z poziomem: od formalnego dokumentu, który czytają zarząd, testerzy i audytor, przez zdjęcie tablicy, po kryteria akceptacji w backlogu (dlaczego to wystarcza).
Pamiętaj też, że mapa to nie teren. Model z definicji upraszcza i pomija; ma być przydatny, nie kompletny. Model, którego nikt nie czyta i nie aktualizuje, nie jest dowodem dojrzałości, tylko PDF-em w folderze. Jak utrzymać go przy życiu? Najskuteczniej przez testerów: walidują go i uzupełniają o to, czego zespół nie przewidział (jak działa ta pętla).
Brak formalnego modelu na niskim poziomie to nie brak dojrzałości. To dojrzałość.
Co tracisz, gdy mylisz te trzy rzeczy
Każda para pomyłek ma swój koszt. Z naszego doświadczenia trzy scenariusze wracają najczęściej.
Mylisz proces z sesją. Organizacja mówi „robimy modelowanie zagrożeń” i ma na myśli jedno spotkanie sprzed roku. Nie ma wyzwalaczy, nie ma właściciela, nie ma rytmu. Aktywność została odhaczona, praktyka nie powstała. To jest teatr bezpieczeństwa w czystej postaci.
Mylisz sesję z modelem. Celem spotkania staje się ładny diagram zamiast decyzji. Zespół poleruje notację, a z listy zagrożeń nie wynika ani jedna akcja. Sesja bez choćby jednej decyzji i akcji w backlogu poszła na marne, niezależnie od urody artefaktu.
Mylisz model z procesem. Organizacja kupuje narzędzie „do modeli zagrożeń” i uznaje temat za załatwiony. Czemu to nie działa? Ponieważ narzędzie skaluje proces, nie osąd; jeśli procesu nie ma, narzędzie wyskaluje jego brak.
I tak, i nie. AI może (i powinno!) pomagać skalować proces modelowania zagrożeń. Tyle że mieć modele i realnie podnieść poprzeczkę bezpieczeństwa to dwie różne rzeczy. Jest jeden uczciwy wyjątek: jeśli generujesz modele pod compliance i robisz to ŚWIADOMIE, wszystko gra. Cały niuans siedzi właśnie tam: w świadomej decyzji, a nie w wierze, że wygenerowany artefakt równa się bezpieczniejszemu systemowi.
Każda z tych pomyłek ma tę samą sygnaturę: aktywność jest, wartości nie ma.
Co robić, jak żyć?
Zamiast powtarzać listę decyzji, damy Ci plan na pierwsze 30 dni:
- Dziś. Nazwij uczciwie, co masz: sesje ad hoc, model zrobiony pod audyt, nic? Diagnoza bez upiększeń to punkt startu.
- Tydzień 1. Wyznacz właściciela procesu (dział bezpieczeństwa) i wybierz jeden system na pilotaż: ważne dane plus ekspozycja na świat.
- Tydzień 2. Poprowadź sesję pilotażową według przewodnika krok po kroku i zapisz wyniki w konkretnych formatach, w narzędziu, które organizacja akceptuje.
- Tydzień 3. Ustal wyzwalacze i rytm na kolejne miesiące (mała dawka, ale często) i zaplanuj, że model pojedzie do testerów przy najbliższych testach.
- Dzień 30. Zrób pierwszy przegląd backloga (to on domyka czwarte pytanie) i ustal z biznesem pierwszą miarę procesu, choćby pokrycie systemów krytycznych modelami. Właśnie domknęła się Twoja pierwsza pętla.
Bo bezpieczeństwo to proces, nie produkt. Modelowanie zagrożeń też: sesje i modele są środkami, a praktyka jest celem.
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; ThoughtWorks — Agile Threat Modelling (Jim Gumbley; facylitacja sesji jako koncepcja branżowa); OWASP.