Autor: securing
Przeprowadzając testy penetracyjne w wielu krajach od ponad 20 lat, regularnie widzimy ten sam schemat: wiele problemów bezpieczeństwa można byłoby wyeliminować znacznie wcześniej, gdyby na etapie projektowania systemów stosowano modelowanie zagrożeń (Threat Modeling). Myślenie o realnych zagrożeniach już na samym początku zyskuje na popularności, a zagrożenia jako takie coraz częściej pojawiają się także w kontekście regulacyjnym, m.in. przy Threat-Led Penetration Testing.
Prawo
23 października, 2026
Modelowanie zagrożeń - brakujące ogniwo w podejściu do bezpieczeństwa
Z tego artykułu dowiesz się:
-
Czym jest modelowanie zagrożeń?Modelowanie zagrożeń, czyli Threat Modeling, to proces analizowania działania systemu, jego użytkowników oraz możliwych sposobów nadużycia. SecuRing pokazuje na podstawie ponad 20 lat doświadczenia w testach penetracyjnych, dlaczego najważniejsze pytania o zagrożenia warto zadawać już podczas projektowania aplikacji, a nie dopiero po jej wdrożeniu.
Przejdź do fragmentu w dokumencie → -
Dlaczego modelowanie zagrożeń jest ważne dla bezpieczeństwa aplikacji?Brak analizy zagrożeń na etapie projektowania sprawia, że system może być poprawny funkcjonalnie, a jednocześnie podatny na nadużycia wynikające z logiki biznesowej. W materiale SecuRing wyjaśnia, dlaczego wcześniejsze rozpoznanie takich scenariuszy pozwala ograniczyć ryzyko jeszcze przed testami penetracyjnymi i wdrożeniem produkcyjnym.
Przejdź do fragmentu w dokumencie → -
Jakie błędy może wykryć modelowanie zagrożeń?Przykłady kodów rabatowych pokazują dwa różne problemy: możliwość wielokrotnego użycia tego samego rabatu oraz akceptowanie przez API wartości ustawionej w przeglądarce użytkownika. SecuRing wykorzystuje te przypadki z systemów produkcyjnych, aby pokazać, że analiza zagrożeń powinna obejmować również scenariusze nadużyć funkcji biznesowych.
Przejdź do fragmentu w dokumencie → -
Gdzie najczęściej pojawiają się zagrożenia w architekturze aplikacji?Szczególnej uwagi wymagają integracje między komponentami, zaufane interfejsy API oraz granice zaufania pomiędzy usługami. Publikacja SecuRing wskazuje również na ryzyko rozproszonej odpowiedzialności, gdy problem bezpieczeństwa powstaje na styku dwóch zespołów lub elementów systemu.
Przejdź do fragmentu w dokumencie → -
Jak modelowanie zagrożeń wspiera testy penetracyjne?Threat Modeling pozwala przełożyć zagrożenia i ich potencjalne skutki na konkretne scenariusze testowe. Z doświadczeń SecuRing wynika, że gdy analiza zagrożeń jest częścią procesu projektowego, problemy wykrywane podczas testów penetracyjnych są zwykle mniej złożone, a ich usunięcie nie wymaga przebudowy dużych elementów systemu.
Przejdź do fragmentu w dokumencie → -
Jakie są koszty braku modelowania zagrożeń?DORA wprowadza koncepcję Threat-Led Penetration Testing dla wybranych podmiotów sektora finansowego. Materiał SecuRing pokazuje, że punktem wyjścia do TLPT jest scenariusz opracowany na podstawie threat intelligence, uwzględniający profil organizacji, sektor działalności oraz najbardziej prawdopodobnych przeciwników.
Przejdź do fragmentu w dokumencie → -
Czym różnią się Threat Modeling i Threat-Led Penetration Testing?Threat Modeling służy rozpoznawaniu zagrożeń podczas projektowania i rozwoju systemu, natomiast Threat-Led Penetration Testing opiera test na konkretnym scenariuszu przygotowanym z wykorzystaniem threat intelligence. SecuRing wyjaśnia, dlaczego TLPT nie jest tym samym co modelowanie zagrożeń, mimo że oba podejścia odchodzą od testowania opartego wyłącznie na ogólnych checklistach.
Przejdź do fragmentu w dokumencie → -
Jaki związek mają DORA, TLPT i threat intelligence?DORA wprowadza koncepcję Threat-Led Penetration Testing dla wybranych podmiotów sektora finansowego. Materiał SecuRing pokazuje, że punktem wyjścia do TLPT jest scenariusz opracowany na podstawie threat intelligence, uwzględniający profil organizacji, sektor działalności oraz najbardziej prawdopodobnych przeciwników.
Przejdź do fragmentu w dokumencie →
Dlaczego ten temat ma znaczenie z perspektywy praktyka?
Z naszego doświadczenia w testach penetracyjnych wynika, że część najpoważniejszych błędów bezpieczeństwa wynika z braku świadomości zagrożeń w zespole tworzącym aplikacje.
PRZYKŁAD
Świetnymi przykładami są kody rabatowe w sklepach internetowych. W jednej z aplikacji twórcy nie pomyśleli, żeby sprawdzać, czy ktoś dany kod rabatowy wprowadził dwa razy i można było zwielokrotniać rabat. W drugiej wartość rabatu była ustawiana w przeglądarce użytkownika i można było ustawić cokolwiek, bo API po stronie serwera każdą wartość akceptowało.
Obie kwestie wydają się oczywiste dla kogoś zajmującego się bezpieczeństwem aplikacji na co dzień, co nie zmienia faktu, że te błędy zostały znalezione na systemach produkcyjnych. Brak modelowania zagrożeń powoduje, że zagrożenia nie są identyfikowane na etapie, na którym ich usunięcie byłoby najprostsze i najtańsze.
W praktyce oznacza to, że testy penetracyjne wykrywają problemy dopiero wtedy, gdy system jest już zbudowany, zintegrowany i często już działa produkcyjnie. Na tym etapie zmiany są kosztowne, a część decyzji architektonicznych jest bardzo trudna do cofnięcia.
Gdzie najczęściej widać brak modelowania zagrożeń?
Podczas pracy z różnymi organizacjami, od firm technologicznych, korporacji i startupów, przez sektor finansowy widzimy, że modelowanie zagrożeń wciąż nie jest standardem. Często jest pomijane albo traktowane jako jednorazowe ćwiczenie, które nie wraca iteracyjnie wraz z rozwojem systemu.
Tam, gdzie modelowanie zagrożeń nie jest stosowane, regularnie pojawiają się problemy wynikające z:
- rosnącej złożoności aplikacji czy systemu, nieprzemyślanych integracji pomiędzy komponentami systemu, które umożliwiają nieautoryzowany dostęp do danych poprzez zaufane interfejsy API;
- braku jasno określonych granic zaufania pomiędzy usługami;
- nieuwzględnienia scenariuszy nadużyć i nieautoryzowanego użycia funkcji;
- rozproszonej odpowiedzialności pomiędzy zespołami technicznymi, gdzie często problem bywa na styku dwóch komponentów.
Są to dokładnie te obszary, w których atakujący najłatwiej znajdują punkt zaczepienia.
Czym w praktyce jest modelowanie zagrożeń?
Modelowanie zagrożeń to przede wszystkim proces zadawania właściwych pytań na odpowiednio wczesnym etapie. Nie chodzi wyłącznie o identyfikację podatności, ale o zrozumienie, jak system działa, kto z niego korzysta i w jaki sposób może zostać nadużyty.
W dobrze przeprowadzonym modelowaniu zagrożeń analizuje się m.in.:
- założenia biznesowe oraz techniczne dla danej aplikacji;
- komponenty aplikacji i ich wzajemne zależności, architekturę, istniejące integracje zewnętrzne;
- aktorów istniejących w aplikacji i infrastrukturze;
- zagrożenia, zaczynając od ogólnych (np. straty finansowe) i dochodząc do coraz bardziej specyficznych (nadużycie kodów rabatowych);
- ich potencjalne skutki biznesowe i operacyjne;
- priorytety działań zabezpieczających.
Najważniejsze jest zrozumienie założeń biznesowych i technicznych aplikacji, czyli domeny, dla której będziemy identyfikować zagrożenia. Bez tego kroku albo jeśli mamy niepełną wiedzę, możemy pominąć niektóre zagrożenia i źle określić priorytet dla tych, które znaleźliśmy. Takie podejście pozwala spojrzeć na bezpieczeństwo nie tylko przez pryzmat kodu, czy technicznych aspektów, ale całościowo, szczególnie uwzględniając perspektywę biznesową.
Modelowanie zagrożeń pozwala też przygotować konkretne scenariusze testowe dla aplikacji. Dzięki temu można skupić testy na tych aspektach, które potencjalnie mogą wykryć błędy niosące największe ryzyko dla aplikacji.
Co pokazują testy penetracyjne?
W testach, które prowadzimy, bardzo często widać, że brak wcześniejszego modelowania zagrożeń prowadzi do sytuacji, w których:
- podatności są „oczywiste” dopiero z perspektywy atakującego;
- zabezpieczenia zostały wdrożone punktowo, bez spójnej koncepcji;
- system jest poprawny funkcjonalnie, ale podatny na nadużycia wynikające z logiki biznesowej.
Tam, gdzie modelowanie zagrożeń było częścią procesu projektowego, wyniki testów penetracyjnych są zwykle inne: problemy są mniej złożone, a ich usunięcie nie wymaga przebudowy dużych elementów systemu.
Koszty i konsekwencje braku modelowania zagrożeń
Z perspektywy organizacji brak modelowania zagrożeń to nie tylko ryzyko techniczne. To także:
- wyższe koszty naprawy podatności wykrytych na późnym etapie;
- opóźnienia we wdrożeniach;
- zwiększone ryzyko incydentów bezpieczeństwa;
- trudności w wykazaniu należytej staranności w kontekście audytów i regulacji.
Modelowanie zagrożeń pozwala przesunąć punkt ciężkości z reakcji na zapobieganie.
Modelowanie zagrożeń a regulacje
Warto zauważyć, że podejście oparte na analizie realistycznych zagrożeń coraz częściej pojawia się także w kontekście regulacyjnym. Przykładem jest DORA, która wprowadza koncepcję Threat-Led Penetration Testing (TLPT) dla wybranych podmiotów sektora finansowego. TLPT nie jest tym samym co modelowanie zagrożeń, ale oba podejścia odchodzą od testowania opartego wyłącznie na ogólnych checklistach bezpieczeństwa.
W przypadku TLPT punktem wyjścia jest konkretny scenariusz zagrożenia przygotowany na podstawie threat intelligence[MO8.1], z uwzględnieniem profilu organizacji, jej sektora działalności oraz najbardziej prawdopodobnych przeciwników. Testy będą nakierowane na realizację scenariuszy, które są zbudowane na bazie realnych zagrożeń i technik stosowanych przez atakujących.
Włączenie modelowania zagrożeń do standardowych praktyk organizacji pozwala budować bardziej świadome podejście do zarządzania ryzykiem i ułatwia projektowanie systemów z uwzględnieniem realistycznych scenariuszy ataku, a nie wyłącznie hipotetycznych założeń.
Źródła uzupełniające:
https://www.securing.pl/en/light-agile-approach-to-threat-modeling/
https://www.securing.pl/en/threat-led-penetration-testing-tlpt-how-to-be-dora-compliant-in-2025/
Autor i partner technologiczny:
Powiązane analizy
-
PodcastPrawopaździernika 27, 2026
Prawo na Oko #76 | Co dzieje się z danymi po kradzieży? O anatomii wycieku mówi Krzysztof Niemiec
Wyciek danych to dopiero początek. Co dzieje się później ze skradzionymi informacjami i dlaczego niektóre z nich mogą stanowić zagrożenie jeszcze przez wiele lat? -
Raport/od redakcjiPrawopaździernika 23, 2026
Threat-Led Penetration Testing - kompleksowy atak cybernetyczny na organizację
Threat-Led Penetration Testing (TLPT) to testowanie odporności organizacji oparte na rzeczywistych zagrożeniach. Artykuł wyjaśnia rolę Threat Intelligence, Red Team oraz znaczenie TLPT w DORA jako elementu oceny cyfrowej odporności operacyjnej. -
Raport/od redakcjiPrawopaździernika 22, 2026
Zmiany w przepisach o dyskryminacji i mobbingu – nowe obowiązki dla pracodawców i firm
Sama polityka antymobbingowa nie wystarczy. Sprawdź, jak nowelizacja Kodeksu pracy od 5 listopada 2026 r. wpłynie na regulaminy, postępowania wyjaśniające, ochronę danych osobowych i prowadzenie spraw sądowych. -
PodcastPrawopaździernika 13, 2026
PODCAST #75: Mieszkaniec kontra rada gminy. Kto ma większy wpływ mówi Jakub Dorosz-Kruczyński
Najważniejsze decyzje często zapadają wtedy, gdy nikt nie patrzy. Jakub Dorosz-Kruczyński pokazuje, jak monitorować działania samorządu i skutecznie korzystać z praw mieszkańca.