Modelowanie Zagrożeń
Naprawa błędu bezpieczeństwa wykrytego w fazie projektowania kosztuje 100x mniej niż na produkcji. Zidentyfikujemy zagrożenia metodami STRIDE i PASTA zanim napiszesz pierwszą linię kodu. Zyskujesz bezpieczny produkt bez kosztownych przeprojektowań.
Czym jest modelowanie zagrożeń (Threat Modeling)?
Modelowanie zagrożeń to systematyczna analiza architektury aplikacji lub systemu w celu identyfikacji potencjalnych wektorów ataku i wymaganych kontroli bezpieczeństwa, przeprowadzana metodami STRIDE i PASTA. Usługa jest realizowana w fazie projektowania, zanim powstanie kod – naprawa błędu bezpieczeństwa na tym etapie kosztuje 100 razy mniej niż na produkcji. nFlo dostarcza Data Flow Diagrams, kompletną listę zagrożeń z priorytetyzacją DREAD oraz konkretny mitigation plan w 3–10 dni roboczych.
Błąd w architekturze to przepisywanie całego systemu
Threat Modeling - znajdź zagrożenia przed kodem
Data Flow Diagrams
Mapujemy przepływy danych i trust boundaries
STRIDE Analysis
Identyfikujemy zagrożenia dla każdego komponentu
Mitigation Plan
Konkretne zabezpieczenia do wdrożenia
Czym jest Modelowanie zagrożeń (Threat Modeling)?
Modelowanie zagrożeń (Threat Modeling) to systematyczna analiza architektury aplikacji lub systemu w celu identyfikacji potencjalnych zagrożeń, wektorów ataku i wymaganych kontroli bezpieczeństwa (STRIDE, PASTA).
| Atrybut | Wartość |
|---|---|
| Metodologie | STRIDE, PASTA, Attack Trees |
| Zakres | Aplikacja, system, architektura |
| Integracja | SDLC, Secure by Design |
| Czas realizacji | 3-10 dni roboczych |
| Cena | od 20 000 PLN (stan na 2026) |
Przeprojektowanie systemu płatności za 500 000 PLN
Fintech uruchomił system płatności. Po trzech miesiącach audyt PCI DSS wykazał fundamentalne błędy w architekturze - brak separacji środowisk, wrażliwe dane w logach, słabe szyfrowanie. Przeprojektowanie i reimplementacja: 500 000 PLN i 6 miesięcy opóźnienia.
Bez threat modeling:
- Fundamentalne błędy bezpieczeństwa w architekturze
- Kosztowne przeprojektowanie i przepisywanie kodu
- Opóźnienia w time-to-market, utrata przewagi konkurencyjnej
- Compliance violations i potencjalne kary
STRIDE + PASTA = kompletna mapa zagrożeń
Stosujemy sprawdzone metodyki threat modeling używane przez Microsoft, Google, banki. Identyfikujemy zagrożenia systematycznie, nie polegamy na “intuicji”.
Co dostajesz:
- Data Flow Diagrams z komponentami, przepływami danych, trust boundaries
- Kompletną listę zagrożeń dla każdego komponentu (STRIDE)
- Priorytetyzację według ryzyka (DREAD: Damage, Reproducibility, Exploitability, Affected users, Discoverability)
- Security requirements do implementacji
- Mitigation plan - konkretne zabezpieczenia dla każdego zagrożenia
- Attack trees pokazujące scenariusze ataków
Deliverables i format wyników
Modelowanie zagrożeń nFlo kończy się zestawem dokumentów, które bezpośrednio przekładają się na pracę zespołu deweloperskiego. Nie dostarczamy abstrakcyjnych raportów - każdy deliverable ma konkretnego odbiorcę i cel.
Data Flow Diagrams (DFD) dokumentują architekturę systemu z perspektywy bezpieczeństwa. Zawierają: procesy (komponenty aplikacji), data stores (bazy danych, cache, pliki), external entities (użytkownicy, systemy zewnętrzne, API) oraz trust boundaries (granice zaufania, np. DMZ, backend, baza danych). DFD stanowią referencję dla całego zespołu - developer wie, gdzie przechodzą granice zaufania i gdzie wymagana jest walidacja danych.
Threat Register to kompletna lista zidentyfikowanych zagrożeń z priorytetyzacją DREAD. Każde zagrożenie zawiera: kategorię STRIDE, opis scenariusza ataku, komponent którego dotyczy, scoring DREAD (1-10 dla każdego kryterium), rekomendowaną kontrolę bezpieczeństwa oraz status (do wdrożenia, zaakceptowane, zmitigowane). Rejestr jest bazą do tworzenia security stories w backlogu zespołu.
Security Requirements Specification tłumaczy zagrożenia na wymagania implementacyjne zrozumiałe dla developerów. Zamiast “ryzyko SQL injection” specyfikacja zawiera: “wszystkie zapytania do bazy danych muszą używać parametryzowanych prepared statements; ORM dopuszczalny z wyłączeniem raw queries; walidacja wejścia na warstwie API Gateway według schematu OpenAPI”. Wymagania są pogrupowane według komponentów architektury i priorytetów wdrożenia.
Attack Trees wizualizują wieloetapowe scenariusze ataków - od wektora wejścia (np. phishing, publiczne API) przez lateral movement do osiągnięcia celu atakującego (exfiltracja danych, przejęcie konta admin). Attack trees pomagają zrozumieć, które kontrole blokują najwięcej ścieżek ataku jednocześnie.
Dla kogo?
Ta usługa jest dla Ciebie, jeśli:
- Projektujesz nową aplikację lub feature i chcesz zrobić to bezpiecznie
- Musisz spełnić wymogi compliance (PCI DSS, ISO 27001, HIPAA)
- Budujesz aplikację obsługującą wrażliwe dane lub pieniądze
- Chcesz uniknąć kosztownych napraw błędów bezpieczeństwa później
- Potrzebujesz security requirements dla zespołu developerskiego
Metodyki threat modeling
STRIDE - analiza zagrożeń
Systematyczna identyfikacja 6 kategorii zagrożeń:
- Spoofing - podszycie się pod innego użytkownika/system
- Tampering - modyfikacja danych, kodu, konfiguracji
- Repudiation - zaprzeczenie wykonaniu akcji
- Information Disclosure - wyciek wrażliwych informacji
- Denial of Service - uniemożliwienie korzystania z systemu
- Elevation of Privilege - uzyskanie wyższych uprawnień
PASTA - Process for Attack Simulation and Threat Analysis
Risk-centric metodyka w 7 krokach:
- Definicja celów biznesowych
- Definicja zakresu technicznego
- Dekompozycja aplikacji (DFD)
- Analiza zagrożeń
- Analiza podatności
- Modelowanie ataków
- Analiza ryzyka i mitygacje
DREAD - priorytetyzacja ryzyka
Ocena każdego zagrożenia w skali 1-10:
- Damage - jak wielka szkoda?
- Reproducibility - jak łatwo powtórzyć atak?
- Exploitability - jak łatwo wykorzystać?
- Affected users - ilu użytkowników dotyczy?
- Discoverability - jak łatwo znaleźć podatność?
Dla jakich systemów?
Modelowanie zagrożeń stosujemy dla:
- Aplikacje webowe - SaaS, portale, e-commerce
- Aplikacje mobilne - iOS, Android, fintech, healthtech
- API - REST, GraphQL, microservices
- IoT - urządzenia connected, smart home
- Cloud - architektury AWS/Azure/GCP
- Blockchain - smart contracts, DeFi
Powiązane pojęcia
Dowiedz się więcej o kluczowych pojęciach związanych z tą usługą:
Skontaktuj się z opiekunem
Porozmawiaj o Modelowanie Zagrożeń z dedykowanym opiekunem handlowym.
Jak pracujemy
Sprawdzony proces realizacji usługi.
Scope Definition
Określamy zakres: aplikacja, feature, system
Architecture Mapping
Tworzymy DFD z komponentami i przepływami danych
Threat Identification
Stosujemy STRIDE do znalezienia zagrożeń
Risk Assessment
Priorytetyzujemy zagrożenia metodą DREAD
Mitigation Design
Projektujemy zabezpieczenia i security requirements
Korzyści dla Twojej firmy
Co zyskujesz wybierając tę usługę.
Drastyczne oszczędności
Unikasz kosztownych przeprojektowań i napraw
Szybsze time-to-market
Nie tracisz czasu na security bugs przed release
Security by Design
Produkt bezpieczny z założenia, nie z łatek
Zgodność z normami
Spełniasz wymogi ISO 27001, NIST, branżowe
Powiązane artykuły
Pogłęb swoją wiedzę z naszej bazy wiedzy.
Praktyczne modelowanie zagrożeń z wykorzystaniem MITRE ATT&CK
Połączenie klasycznych metodyk modelowania zagrożeń z bazą wiedzy MITRE ATT&CK pozwala na tworzenie realistycznych profili ryzyka. Poznaj sprawdzone podejście krok po kroku.
Czytaj więcej →Modelowanie zagrożeń: Klucz do zabezpieczenia Twojej organizacji - Co to jest i dlaczego warto je przeprowadzić?
Dowiedz się, czym jest modelowanie zagrożeń i dlaczego warto je przeprowadzić. Artykuł nFlo omawia proces identyfikacji i oceny zagrożeń w systemach IT oraz korzyści z tego płynące.
Czytaj więcej →Najczęściej zadawane pytania
Odpowiedzi na pytania dotyczące Modelowanie Zagrożeń.
Kiedy najlepiej przeprowadzić threat modeling - przed czy w trakcie rozwoju?
Najlepiej przed napisaniem kodu, w fazie projektowania architektury. Naprawa błędu bezpieczeństwa w designie kosztuje 100x mniej niż na produkcji. Można też przeprowadzić threat modeling dla istniejącego systemu przed dużą zmianą.
Czym różni się STRIDE od PASTA i którą metodykę stosujecie?
STRIDE identyfikuje 6 kategorii zagrożeń (Spoofing, Tampering, Repudiation, Information Disclosure, DoS, Elevation of Privilege) i sprawdza się dla pojedynczych komponentów. PASTA jest risk-centric i łączy zagrożenia z celami biznesowymi. Dobieramy metodykę do projektu - często łączymy obie.
Ile trwa threat modeling i co otrzymuję na koniec?
Realizacja trwa 3-10 dni roboczych. Dostarczamy Data Flow Diagrams, kompletną listę zagrożeń z priorytetyzacją DREAD, security requirements do implementacji oraz mitigation plan z konkretnymi zabezpieczeniami.
Czy threat modeling jest potrzebny jeśli robimy testy penetracyjne?
Tak - to komplementarne podejścia. Threat modeling znajduje błędy architekturalne (np. brak separacji środowisk, słaby model autoryzacji) zanim napiszesz kod. Pentesty weryfikują gotowy system. Bez threat modeling pentesterzy znajdą problemy, ale ich naprawa będzie wielokrotnie droższa.