Modelowanie zagrożeń dla ISO 27001, NIS2 i DORA

Anya, CISO szybko rosnącej firmy fintech, została poproszona o zatwierdzenie planu wdrożenia nowej platformy B2B do oceny ryzyka płatności. Zarząd oczekiwał wejścia na rynek przed końcem kwartału. Dział sprzedaży miał już przygotowanych klientów bankowych. Zespół inżynieryjny naszkicował architekturę natywną dla chmury, obejmującą atrybuty tożsamości, sygnały z urządzeń, metadane transakcji, behawioralne oceny ryzyka, zarządzaną bazę danych oraz zewnętrznego dostawcę analityki.

Na papierze platforma wyglądała jak przełom biznesowy. Dla Anyi oznaczała pięć równoległych rozmów o zgodności.

Jako dostawca technologii finansowej firma podlegała presji DORA. Jako dostawca usług chmurowych i platformy cyfrowej musiała zrozumieć swoją ekspozycję na NIS2. Ponieważ platforma przetwarzała dane osobowe osób z UE, zastosowanie miał GDPR. Klienci korporacyjni oczekiwali certyfikacji ISO/IEC 27001:2022. Jeżeli usługa stałaby się częścią połączonego produktu programowego, oczekiwania Cyber Resilience Act dodałyby wymóg dowodów bezpieczeństwa produktu już na etapie projektowania.

Zespół rozwojowy zaproponował typowy plan bezpieczeństwa: przeskanować zależności, wykonać skan podatności, zaplanować test penetracyjny i usunąć ustalenia krytyczne przed wdrożeniem produkcyjnym. Anya wiedziała, że to za mało. Te działania testują to, co już zbudowano. Nie dowodzą, że architektura była bezpieczna już na etapie projektowania, że zrozumiano granice zaufania, że przepływy danych osobowych zostały zminimalizowane, że zweryfikowano założenia dotyczące dostawców ani że przed wdrożeniem rozważono scenariusze zakłócenia usługi.

Dlatego zatrzymała spotkanie czterema pytaniami:

1. Gdzie znajdują się granice zaufania?
2. Które scenariusze nadużyć mogą prowadzić do oszustwa, ujawnienia danych lub zakłócenia usługi?
3. Które decyzje projektowe ograniczają ryzyko jeszcze przed napisaniem kodu?
4. Jakie dowody będą wystarczające dla osób oceniających ISO 27001, NIS2, DORA, CRA i GDPR za sześć miesięcy?

Właśnie na czwartym pytaniu wiele organizacji zawodzi. Modelowanie zagrożeń często traktuje się jako przydatny warsztat inżynieryjny, po czym chowa w jednej stronie wiki. W 2026 roku to już nie wystarcza. Dla dostawców SaaS, firm fintech, platform chmurowych, MSP, MSSP, operatorów infrastruktury cyfrowej i producentów oprogramowania modelowanie zagrożeń stało się mechanizmem wytwarzania dowodów zgodności.

Dojrzały proces modelowania zagrożeń przekształca ustalenia STRIDE, scenariusze nadużyć i decyzje architektoniczne we wpisy w rejestrze ryzyka, wymagania bezpieczeństwa, plany postępowania z ryzykiem, przypadki testowe, zadania zapewnienia po stronie dostawców, dowody privacy by design oraz identyfikowalność z Deklaracją stosowania.

Dlaczego dowody bezpieczeństwa na etapie projektowania mają dziś znaczenie

Współczesne regulacje zbiegają się wokół tego samego oczekiwania: organizacje muszą wcześnie identyfikować ryzyka bezpieczeństwa i prywatności, przypisywać odpowiedzialność, wdrażać proporcjonalne zabezpieczenia oraz przechowywać dowody.

ISO/IEC 27001:2022 wymaga opartego na ryzyku systemu zarządzania bezpieczeństwem informacji. Klauzule 6.1.2 i 6.1.3 wymagają oceny ryzyka bezpieczeństwa informacji oraz postępowania z ryzykiem. Klauzula 8.1 wymaga planowania operacyjnego i nadzoru operacyjnego. Załącznik A zawiera zabezpieczenia, które należy dobrać w Deklaracji stosowania na podstawie ryzyka, wymagań prawnych i potrzeb biznesowych.

NIS2 przenosi tę samą zasadę na ład cyberbezpieczeństwa. Article 20 wymaga, aby organy zarządzające zatwierdzały środki zarządzania ryzykiem cyberbezpieczeństwa i nadzorowały ich wdrożenie. Article 21 wymaga odpowiednich i proporcjonalnych środków technicznych, operacyjnych i organizacyjnych, w tym analizy ryzyka, obsługi incydentów, ciągłości działania, bezpieczeństwa łańcucha dostaw, bezpieczeństwa przy nabywaniu, rozwoju i utrzymaniu systemów, obsługi podatności, cyberhigieny, szyfrowania, kontroli dostępu, zarządzania aktywami oraz MFA tam, gdzie jest to właściwe.

DORA stosuje perspektywę odporności operacyjnej sektora finansowego od 17 stycznia 2025 roku. Wymaga od objętych zakresem podmiotów finansowych utrzymywania solidnych, kompleksowych i udokumentowanych ram zarządzania ryzykiem ICT, identyfikowania aktywów ICT i zależności, stosowania środków ochronnych i zapobiegawczych, wykrywania anormalnej aktywności, testowania cyfrowej odporności operacyjnej, zarządzania ryzykiem związanym z zewnętrznymi dostawcami usług ICT oraz przygotowania zdolności reagowania i odtwarzania. Dla objętych zakresem podmiotów finansowych DORA jest sektorowym unijnym aktem prawnym dla nakładających się obowiązków NIS2.

GDPR dodaje rozliczalność oraz ochronę danych w fazie projektowania i domyślnie. Każdy system przetwarzający dane osobowe musi móc wykazać zgodne z prawem, rzetelne, przejrzyste, ograniczone do celu, zminimalizowane, ograniczone czasowo i bezpieczne przetwarzanie. Model zagrożeń, który mapuje przepływy danych osobowych, ścieżki dostępu, logi, okresy przechowywania, usuwanie i przekazywanie danych stronom trzecim, jest bezpośrednio istotny dla GDPR Articles 5, 25, 32 i 35.

Cyber Resilience Act zwiększa presję na produkty z elementami cyfrowymi. Zespoły produktowe potrzebują dowodów z całego cyklu życia pokazujących, że ryzyka cyberbezpieczeństwa, możliwe do przewidzenia niewłaściwe użycie, interfejsy, mechanizmy aktualizacji, przepływy uwierzytelniania oraz założenia dotyczące obsługi podatności rozważono wcześnie.

Wniosek jest prosty: jeżeli przeglądu architektury nie można powiązać z ryzykami, zabezpieczeniami, właścicielami, działaniami mitygującymi i testami, trudno będzie go obronić podczas audytu lub przeglądu regulacyjnego w 2026 roku.

Model Clarysec: jeden model zagrożeń, wiele rezultatów

Podejście Clarysec zaczyna się od praktycznej zasady: model zagrożeń nie jest kompletny, dopóki nie prowadzi do decyzji możliwych do prześledzenia w audycie.

W Zenith Blueprint: 30-etapowa mapa drogowa audytora [ZB], w fazie zarządzania ryzykiem, krok 9, daje zespołom prosty format przekształcania obserwacji technicznych w język ryzyka:

„Teraz połącz aktywo + zagrożenie + podatność w zwięzły opis scenariusza ryzyka. W praktyce opisz potencjalny incydent. Później stanie się on pozycją w rejestrze ryzyka. Użyj prostego formatu: ‘[Zagrożenie] wykorzystuje [podatność] w [aktywie], co skutkuje [wpływem]’.”

To zdanie stanowi pomost między inżynierią a zgodnością.

Notatka z tablicy, taka jak „ryzyko podszycia się pod partnerskie API”, staje się:

„Atakujący wykorzystuje słabe uwierzytelnianie partnerskiego API w API oceny ryzyka transakcji, co skutkuje nieuprawnionym dostępem do decyzji dotyczących ryzyka płatności i ujawnieniem danych osobowych.”

Ustalenie ma teraz aktywo, zagrożenie, podatność i wpływ. Można je ocenić, przypisać, objąć postępowaniem z ryzykiem, przetestować i zaakceptować.

Warstwa polityk zapewnia powtarzalność. P24 Polityka bezpiecznego rozwoju oprogramowania [P24] stanowi:

„Wszystkie nowe aplikacje i istotne zmiany muszą przed rozpoczęciem prac rozwojowych przejść przegląd bezpiecznej architektury i modelowanie zagrożeń.”
Z sekcji „Wymagania dotyczące wdrożenia polityki”, klauzula polityki 6.1.1.

Wymaga także:

„Przeglądy projektu muszą dokumentować diagramy przepływu danych, granice zaufania oraz środki mitygacji dla zidentyfikowanych ryzyk.”
Z sekcji „Wymagania dotyczące wdrożenia polityki”, klauzula polityki 6.1.2.

Te dwie klauzule są mocnymi punktami odniesienia w audycie. Pokazują, że modelowanie zagrożeń nie jest opcjonalne oraz że dowody projektowe muszą obejmować diagramy, granice i decyzje dotyczące mitygacji.

P06 Polityka zarządzania ryzykiem [P06] łączy modelowanie zagrożeń z zarządzaniem ryzykiem w skali przedsiębiorstwa:

„Wszystkie jednostki biznesowe muszą proaktywnie identyfikować ryzyka przy użyciu ustrukturyzowanych technik opartych na ISO/IEC 27005:2024, w tym modelowania zagrożeń, mapowania zależności aktywów i identyfikacji opartej na scenariuszach.”
Z sekcji „Wymagania dotyczące wdrożenia polityki”, klauzula polityki 6.1.1.

Stanowi również:

„Zidentyfikowane ryzyka należy dokumentować z odniesieniem do właściciela aktywa, aktora zagrożeń, podatności oraz potencjalnego wpływu na poufność, integralność i dostępność (CIA).”
Z sekcji „Wymagania dotyczące wdrożenia polityki”, klauzula polityki 6.1.4.

To jest łańcuch dowodowy, którego oczekują audytorzy: wymóg polityki, działanie projektowe, scenariusz ryzyka, dobór zabezpieczeń, wdrożenie, testowanie i zatwierdzenie.

STRIDE zapewnia systematyczne pokrycie, a scenariusze nadużyć nadają mu realizm

STRIDE pozostaje jedną z najbardziej użytecznych metod modelowania zagrożeń na etapie projektowania, ponieważ wymusza rozważenie sześciu typowych trybów nieskuteczności zabezpieczeń:

• Podszywanie się
• Manipulacja
• Wyparcie się działań
• Ujawnienie informacji
• Odmowa usługi
• Podniesienie uprawnień

W przypadku platformy Anyi do oceny ryzyka płatności zespół zastosował STRIDE do każdego komponentu, przepływu danych i granicy zaufania.

Podszywanie się wywołało pytanie, czy klient partnerskiego API mógłby podszyć się pod klienta bankowego, gdyby wzajemne uwierzytelnianie było słabe. Manipulacja ujawniła ryzyko, że sygnały z urządzeń lub kwoty transakcji mogłyby zostać zmienione przed ich przyjęciem. Wyparcie się działań wskazało potrzebę logów audytowych administratorów i transakcji. Ujawnienie informacji skoncentrowało uwagę na wyciekach przez logi, eksporty analityczne, narzędzia wsparcia i raportujące API. Odmowa usługi wymusiła analizę szczytowych okien transakcyjnych i zalewania systemu błędnie sformułowanymi żądaniami. Podniesienie uprawnień ujawniło ryzyka w rolach wsparcia, tokenach sesji i funkcjach administracyjnych.

Scenariusze nadużyć przekształciły te kategorie w realistyczne historie:

• Oszust przesyła zmodyfikowane sygnały z urządzenia, aby wpłynąć na ocenę ryzyka.
• Przejęte poświadczenie partnera zalewa API fałszywymi żądaniami.
• Programista używa produkcyjnych danych osobowych w środowisku testowym.
• Złośliwy insider eksportuje identyfikatory klientów i logikę scoringową.
• Niedostępność dostawcy analityki chmurowej blokuje decyzje ryzyka w oknie płatności.
• Błędna konfiguracja pamięci masowej ujawnia przesłane dokumenty tożsamości.
• Proces usuwania usuwa rekord aplikacji, ale pozostawia kopie zapasowe i kopie u dostawców.

Każdy scenariusz nadużyć stał się zapisem ryzyka projektowego z określeniem objętego aktywa, aktora zagrożeń, podatności, wpływu, istniejących założeń, wymaganej mitygacji, właściciela ryzyka rezydualnego, dowodów testowych i znaczenia regulacyjnego.

Taka struktura zapobiega ogólnikowym ustaleniom typu „ryzyko bezpieczeństwa API”. Wytwarza deklaracje ryzyka o jakości dowodowej, takie jak:

„Atakujący używa skradzionych poświadczeń partnera do wysyłania fałszywych żądań scoringowych przez API oceny ryzyka transakcji, co skutkuje naruszeniem integralności decyzji ryzyka, możliwą stratą finansową klientów oraz nieuprawnionym przetwarzaniem danych osobowych.”

Mapowanie modelowania zagrożeń na ISO/IEC 27001:2022 i ISO/IEC 27002:2022

ISO/IEC 27001:2022 nie wymaga modelowania zagrożeń z nazwy. Wymaga spójnej, udokumentowanej oceny ryzyka i postępowania z ryzykiem. Modelowanie zagrożeń jest jedną z najsilniejszych metod generowania takich dowodów w środowiskach oprogramowania, chmury obliczeniowej i produktów.

Kluczowa jest identyfikowalność. W ZB, w fazie zarządzania ryzykiem, krok 13, zaleca mapowanie zabezpieczeń do ryzyk i klauzul, w tym odniesienia do Załącznika A w planach postępowania z ryzykiem oraz odnotowanie, gdzie zabezpieczenia wspierają GDPR, NIS2 lub DORA.

Zenith Controls: przewodnik zgodności przekrojowej [ZC] pomaga uporządkować tę identyfikowalność przez mapowanie zabezpieczeń ISO/IEC 27002:2022 do powiązanych zabezpieczeń, oczekiwań audytowych i zewnętrznych ram.

Dla modelowania zagrożeń zabezpieczenie ISO/IEC 27002:2022 5.8, bezpieczeństwo informacji w zarządzaniu projektami, jest punktem zakotwiczenia ładu projektowego. Pokazuje, że bezpieczeństwo jest zintegrowane z inicjowaniem, planowaniem, realizacją i odbiorem projektu.

Zabezpieczenie 8.25, bezpieczny cykl życia rozwoju oprogramowania, jest punktem zakotwiczenia SDLC. ZC łączy 8.25 ze wspierającymi zabezpieczeniami, takimi jak 8.26 wymagania bezpieczeństwa aplikacji, 8.27 bezpieczna architektura systemów i zasady inżynierii, 8.28 bezpieczne kodowanie, 8.29 testowanie bezpieczeństwa w rozwoju i odbiorze, 8.30 rozwój oprogramowania w modelu outsourcingowym oraz 8.31 rozdzielenie środowisk rozwojowych, testowych i produkcyjnych.

To mapowanie pomaga przekształcić warsztat projektowy w dowody do Deklaracji stosowania. Wspiera również klauzule od 4 do 6 ISO/IEC 27001:2022, ponieważ widoczne są wymagania stron zainteresowanych, zakres SZBI, zobowiązania kierownictwa oraz decyzje dotyczące postępowania z ryzykiem.

Mapa zgodności przekrojowej dla NIS2, DORA, CRA, GDPR i NIST CSF

Dobrze przeprowadzony model zagrożeń nie powinien tworzyć pięciu odrębnych strumieni prac związanych ze zgodnością. Powinien wytworzyć jeden pakiet dowodów ryzyka projektowego, który można ponownie wykorzystać w różnych ramach.

NIST CSF 2.0 jest szczególnie użyteczny w komunikacji z kierownictwem. Jego funkcja GOVERN wspiera obowiązki prawne, regulacyjne, umowne i dotyczące prywatności, a wyniki dotyczące łańcucha dostaw pomagają powiązać krytyczność dostawców, wymogi umowne, due diligence, monitorowanie i planowanie incydentów z tym samym zestawem dowodów modelu zagrożeń.

GDPR wymaga szczególnej uwagi, ponieważ modelowanie zagrożeń i prace DPIA powinny się wzajemnie wzmacniać. P17 Polityka ochrony danych i prywatności [P17] stanowi:

„Modelowanie zagrożeń i oceny skutków dla ochrony danych (DPIA) są obowiązkowe dla systemów przetwarzania wysokiego ryzyka.”
Z sekcji „Wymagania dotyczące wdrożenia polityki”, klauzula polityki 6.3.4.

Dla mniejszych zespołów P17S Polityka ochrony danych i prywatności - MŚP [P17S] stanowi:

„Privacy by design i privacy by default muszą być egzekwowane we wszystkich nowych systemach i usługach.”
Z sekcji „Wymagania dotyczące ładu zarządczego”, klauzula polityki 5.3.1.

W rezultacie powstaje praktyczny model operacyjny: te same diagramy przepływu danych, granice zaufania i scenariusze nadużyć należy wykorzystywać na potrzeby ryzyka bezpieczeństwa, ryzyka dla prywatności, przeglądu dostawców i dowodów regulacyjnych.

90-minutowy sprint ryzyka projektowego dla funkcji wysokiego ryzyka

Modelowanie zagrożeń nie musi zaczynać się jako rozbudowany program. Dla nowego API płatności, procesu onboardingu, funkcji wykorzystującej AI, usługi tożsamości, migracji do chmury obliczeniowej lub integracji zewnętrznej 90-minutowy sprint ryzyka projektowego może wytworzyć wartościowe dowody.

1. Otwórz punkt kontrolny bezpieczeństwa projektu

Użyj klauzuli 6.1.1 P24 jako wyzwalacza. Dla każdej nowej aplikacji lub istotnej zmiany utwórz folder dowodowy zawierający:

• Diagram architektury
• Diagram przepływu danych
• Mapę granic zaufania
• Wykaz aktywów
• Notatki dotyczące danych osobowych
• Wykaz dostawców i zależności ICT
• Wstępne wymagania bezpieczeństwa
• Arkusz modelu zagrożeń
• Wpisy w rejestrze ryzyka
• Identyfikowalność mitygacji i testów
• Zapis zatwierdzenia

Dla mniejszych organizacji P24S Polityka bezpiecznego rozwoju oprogramowania - MŚP [P24S] wspiera tę samą dyscyplinę, łącząc procesy bezpiecznego rozwoju oprogramowania z kontrolą dostępu programistów, testowaniem, modelowaniem zagrożeń i dokumentacją. Wymaga również scentralizowanego przechowywania list kontrolnych, zatwierdzeń przeglądów, raportów z testów i inwentarzy komponentów do celów audytowych. Klauzula 11.3.1 odwołuje się do SA-3 do SA-15 w celu zdefiniowania procesów bezpiecznego rozwoju oprogramowania, w tym modelowania zagrożeń.

2. Narysuj minimalny użyteczny przepływ danych

Nie zaczynaj od dopracowanego diagramu. Zacznij od przepływów, które tworzą ryzyko:

• Użytkownik przesyła dokumenty tożsamości lub dane transakcyjne.
• Aplikacja internetowa wysyła żądania do API.
• API zapisuje dane w zarządzanej pamięci masowej lub bazie danych.
• Dostawca otrzymuje dane weryfikacyjne lub analityczne.
• Wewnętrzny portal analityków wyświetla wyniki.
• System klienta pobiera status lub decyzje.
• Logi, narzędzia monitorowania i kopie zapasowe otrzymują kopie.

Oznacz każdą granicę zaufania: Internet do aplikacji, aplikacja do API, usługa wewnętrzna do dostawcy, system produkcyjny do analityki, administrator do funkcji uprzywilejowanej oraz produkcja do środowiska nieprodukcyjnego.

3. Przeprowadź STRIDE i scenariusze nadużyć razem

Dla każdej granicy zadawaj pytania STRIDE i zapisuj scenariusze nadużyć prostym językiem biznesowym. Celem nie jest spisanie każdego możliwego ataku. Celem jest identyfikacja prawdopodobnych, istotnych scenariuszy wpływających na poufność, integralność, dostępność, prywatność, odporność lub bezpieczeństwo.

4. Przekształć ustalenia w scenariusze ryzyka

Użyj formuły z kroku 9 ZB:

„[Zagrożenie] wykorzystuje [podatność] w [aktywie], co skutkuje [wpływem]”.

Na przykład:

„Atakujący wykorzystuje słabe mechanizmy kontroli dostępu do obiektowej pamięci masowej w repozytorium dokumentów tożsamości, co skutkuje nieuprawnionym ujawnieniem danych osobowych i ekspozycją na zgłoszenia regulacyjne.”

Następnie dodaj właściciela, prawdopodobieństwo, wpływ, ryzyko inherentne, wariant postępowania z ryzykiem, docelowe zabezpieczenie, ryzyko rezydualne i dowody.

5. Wyprowadź wymagania i testy

Model zagrożeń nie jest zakończony w chwili spisania ryzyk. Jest zakończony wtedy, gdy mitygacje zostały wdrożone, przetestowane lub formalnie zaakceptowane.

Polityka zarządzania zmianami - MŚP daje praktyczny wyzwalacz:

„Jeżeli zmiana obejmuje dane wrażliwe, prawa dostępu do systemu lub integracje zewnętrzne, wymagany jest przegląd wpływu na bezpieczeństwo. Wyznaczona osoba kontaktowa ds. bezpieczeństwa lub zgodności musi ocenić, czy zmiana wprowadza dodatkowe ryzyka, i zalecić dodatkowe środki ochrony.”
Z sekcji „Postępowanie z ryzykiem i wyjątki”, klauzula polityki 7.5.1.

Dane wrażliwe, prawa dostępu i integracje zewnętrzne to dokładnie te zmiany, które wymagają przeglądu ryzyka projektowego.

O co zapytają różni audytorzy

Audytor ISO/IEC 27001:2022 zapyta, czy modelowanie zagrożeń jest częścią zdefiniowanego procesu oceny ryzyka, czy kryteria są spójne, czy właściciele ryzyka zatwierdzili ryzyka rezydualne, czy plany postępowania z ryzykiem są powiązane z SoA oraz czy dowody są przechowywane. Będzie szukał powtarzalności, historii wersji, widoczności w przeglądzie zarządzania i objęcia audytem wewnętrznym.

W przypadku Załącznika A audytor powiąże dowody z 5.8, 8.25, 8.26, 8.27 i 8.29. Krok 21 ZB, Zabezpieczenia w praktyce, wyróżnia bezpieczną architekturę systemów i zasady inżynierii, pytając, jakie zasady kierują bezpieczną architekturą. Audytorzy mogą zapytać, czy modelowanie zagrożeń jest prowadzone w fazie projektowania przy użyciu metod takich jak STRIDE lub drzewa ataków oraz czy decyzje architektoniczne są przeglądane przed wdrożeniem.

Osoba oceniająca NIS2 skupi się na ładzie zarządczym i proporcjonalności. Może zapytać, czy kierownictwo zatwierdziło podejście do zarządzania ryzykiem cyberbezpieczeństwa, czy objęto nim bezpieczne nabywanie, rozwój i utrzymanie, czy uwzględniono podatności dostawców, czy scenariusze incydentów są powiązane z procesami zgłaszania oraz czy analizowane są scenariusze ciągłości działania. Stopniowe raportowanie znaczących incydentów zgodnie z NIS2 Article 23, obejmujące wczesne ostrzeżenie w ciągu 24 godzin, zgłoszenie w ciągu 72 godzin i raport końcowy w ciągu miesiąca, sprawia, że klarowność scenariuszy jest szczególnie cenna.

Kontrolujący w zakresie DORA skupi się na ładzie ryzyka ICT, funkcjach krytycznych, aktywach ICT, zależnościach zewnętrznych, testowaniu odporności i usługach ICT świadczonych przez strony trzecie. Jeżeli system wspiera funkcję krytyczną lub istotną, oczekiwane będą silniejsze dowody łączące scenariusze zagrożeń z inwentarzami aktywów, mapami zależności, planami testów, umowami ze stronami trzecimi i środkami odtwarzania.

Osoba oceniająca prywatność przeanalizuje przepływy danych i zapyta, czy przetwarzanie danych osobowych jest niezbędne, zgodne z prawem, zminimalizowane i chronione. Zapyta, czy przetwarzane są szczególne kategorie danych, czy stosuje się pseudonimizację lub szyfrowanie, czy okres przechowywania jest uzasadniony oraz czy wymagana jest DPIA. Modelowanie zagrożeń i DPIA to różne działania, ale powinny współdzielić diagramy, scenariusze i mitygacje.

Osoba oceniająca zorientowana na NIST CSF lub COBIT 2019 będzie szukać ładu zarządczego, własności procesów, wyników, rozliczalności i ciągłego doskonalenia. Może mniej interesować się samym arkuszem STRIDE, a bardziej tym, czy proces jest niezawodny, mierzony, zatwierdzany i doskonalony.

Typowe błędy w dowodach modelowania zagrożeń

Najczęstsze błędy nie są techniczne. Są to błędy dowodowe.

Zespoły przeprowadzają modelowanie zagrożeń zbyt późno, gdy system jest już zbudowany. Wtedy warsztat staje się odprawą przed testem penetracyjnym, zamiast pełnić funkcję kontroli projektowej.

Ustalenia nie są przekształcane w język ryzyka. „Dodać auth” albo „problem z logowaniem” może pomagać inżynierom, ale audytorzy potrzebują aktywa, zagrożenia, podatności, wpływu, właściciela, sposobu postępowania z ryzykiem i ryzyka rezydualnego.

Prywatność i bezpieczeństwo są rozdzielone. Jeden zespół dokumentuje ryzyko podszywania się i wstrzyknięć, a drugi dokumentuje okresy przechowywania i podstawę prawną. Rozliczalność GDPR działa lepiej, gdy przepływy danych, scenariusze nadużyć i kryteria obowiązku przeprowadzenia DPIA są powiązane.

Założenia dotyczące dostawców pozostają nieudokumentowane. NIS2, DORA i NIST CSF podnoszą oczekiwania wobec ryzyka łańcucha dostaw ICT. Jeżeli mitygacja zależy od szyfrowania, rejestrowania, usuwania, odporności lub reagowania na incydenty po stronie dostawcy, należy zebrać dowody.

Testy nie są mapowane z powrotem do zagrożeń. Raport z testów penetracyjnych może być użyteczny, ale może nie dowodzić, że konkretne ryzyka projektowe zostały zmitygowane. Każde istotne ustalenie dotyczące zagrożenia powinno mieć dowód walidacji.

Akceptacja ryzyka rezydualnego jest nieformalna. „Akceptujemy to na potrzeby MVP” nie wystarcza. ISO/IEC 27001:2022 oczekuje akceptacji ryzyka rezydualnego przez właściwych właścicieli ryzyka jako udokumentowanej informacji.

Twój pakiet dowodów modelowania zagrożeń na 2026 rok

Dla każdego istotnego systemu lub znaczącej zmiany utrzymuj standardowy pakiet dowodów, który może wspierać ISO 27001, NIS2, DORA, CRA, GDPR i programy zapewnienia bezpieczeństwa dla klientów.

Polityka zarządzania ryzykiem - MŚP dobrze ujmuje ten model operacyjny:

„Zapewnia, że zarządzanie ryzykiem jest aktywnym elementem planowania, realizacji projektów, wyboru dostawców i reagowania na incydenty, zgodnie z ISO 27001, ISO 31000 oraz obowiązującymi wymaganiami regulacyjnymi.”
Z sekcji „Cel”, klauzula polityki 1.2.

To właściwy punkt docelowy. Modelowanie zagrożeń powinno wpływać na planowanie, inżynierię, wybór dostawców, reagowanie na incydenty i gotowość do audytu.

Przygotuj modelowanie zagrożeń do audytu przed kolejnym wydaniem

Organizacje, które najlepiej poradzą sobie z presją zgodności w 2026 roku, nie będą tymi z największą liczbą diagramów. Będą to te, które potrafią wykazać prosty łańcuch:

Ryzyko projektowe zostało zidentyfikowane. Ryzyko zostało ocenione. Zabezpieczenia zostały dobrane. Mitygacje zostały wdrożone. Testy zwalidowały mitygacje. Ryzyko rezydualne zostało zatwierdzone. Dowody mapują się na właściwe ramy.

Zacznij od jednej zmiany wysokiego ryzyka: integracji płatności, nowego API, procesu wykorzystującego AI, funkcji tożsamości, migracji do chmury obliczeniowej, wydania produktu dla klientów lub usługi połączonej z dostawcą. Przeprowadź 90-minutowy sprint ryzyka projektowego. Użyj ZB, aby przekształcić ustalenia w scenariusze ryzyka, plany postępowania z ryzykiem i identyfikowalność SoA. Użyj ZC, aby zmapować zabezpieczenia ISO/IEC 27002:2022, takie jak 5.8, 8.25, 8.26, 8.27 i 8.29, na wspierające zabezpieczenia, ryzyko dostawców, prywatność, testowanie i dowody audytowe. Dostosuj P24, P06, P17, P24S i procedurę zarządzania zmianami tak, aby modelowanie zagrożeń stało się wymagane, powtarzalne i podlegające przeglądowi.

Jeżeli chcesz, aby Clarysec pomógł, zacznij od przeglądu dowodów modelowania zagrożeń. Ocenimy jeden rzeczywisty projekt, zidentyfikujemy luki względem oczekiwań ISO/IEC 27001:2022, NIS2, DORA, CRA i GDPR oraz przekażemy praktyczną mapę działań naprawczych, którą zrozumieją inżynierowie, audytorzy i zarząd.