Wybór między testem penetracyjnym a operacją red team to jedna z najczęściej źle stawianych decyzji w cyberbezpieczeństwie. Nie chodzi o to, „który jest lepszy” — bo odpowiadają na zupełnie różne pytania. Pentest mówi „jakie techniczne luki mamy w tym konkretnym systemie”, a red team mówi „czy nasz program bezpieczeństwa — ludzie, procesy, technologia razem — wytrzyma realistyczny, ukierunkowany atak”. Pomylenie tych dwóch ćwiczeń kończy się jednym z dwóch scenariuszy: organizacja niedojrzała kupuje red team, dostaje raport pełen rzeczy do naprawienia w obronie, której jeszcze nie ma, i marnuje 6-cyfrowy budżet. Albo dojrzała organizacja z działającym SOC zamawia kolejny pentest aplikacji i otrzymuje listę CVE bez odpowiedzi na pytanie, które naprawdę spędza sen z powiek zarządowi: „czy gdyby grupa APT chciała nas dziś przejąć, to byśmy to w ogóle zauważyli?”.
Ten przewodnik daje Ci matrycę 12 wymiarów porównawczych, prosty algorytm decyzyjny oraz przewodnik po hybrydowych modelach (purple team, continuous pentest + roczny red team), tak abyś po jednej lekturze umiał obronić wybór ćwiczenia przed zarządem, audytorem i CISO sąsiada.
Definicje — najkrótsza możliwa wersja
Test penetracyjny (pentest) to systematyczne, ograniczone czasowo poszukiwanie podatności technicznych w zdefiniowanym, wąskim zakresie (np. jedna aplikacja webowa, segment sieci, zestaw API). Cel: maksymalizacja liczby znalezionych luk; produkt końcowy: lista podatności z oceną CVSS i rekomendacjami naprawczymi. Blue Team zwykle wie o teście — detekcja nie jest priorytetem.
Operacja red team to realistyczna symulacja działań ukierunkowanego adwersarza (najczęściej grupy APT) zmierzająca do osiągnięcia konkretnego celu biznesowego („flagi”) — np. eksfiltracji bazy klientów lub przejęcia kontrolera domeny. Zakres jest szeroki (cała organizacja), czas długi (tygodnie–miesiące), wektory dowolne (technika + socjotechnika + fizyczny dostęp), a kluczowym elementem jest unikanie detekcji. Blue Team o operacji nie wie (wie tylko white team — wąska grupa decyzyjna).
Purple team to nie trzeci zespół, lecz format ćwiczenia, w którym red team i blue team współpracują w czasie rzeczywistym, wspólnie analizując każdą technikę ataku i strojąc detekcję na żywo. To pętla zwrotna zamiast werdyktu.
📚 Przeczytaj kompletny przewodnik: Testy Penetracyjne: Testy penetracyjne — rodzaje, metodologie, przebieg
Matryca 12 wymiarów porównawczych
Najczęściej spotykane porównania pentestu i red teamu sprowadzają się do trzech-czterech wymiarów. W praktyce decyzja powinna uwzględniać przynajmniej dwanaście. Poniższa matryca jest tym, co dajemy klientom przed warsztatem zakresowym.
| # | Wymiar | Test penetracyjny | Operacja red team |
|---|---|---|---|
| 1 | Cel główny | Identyfikacja maksymalnej liczby podatności technicznych | Weryfikacja zdolności detekcji i reakcji na realny atak |
| 2 | Zakres (scope) | Wąski, technicznie zdefiniowany (aplikacja, IP range, API) | Szeroki, definiowany przez cel biznesowy (flagę) |
| 3 | Czas trwania | Od kilku dni do 2-3 tygodni | Od 6 tygodni do 6 miesięcy (TLPT zwykle 12 tygodni) |
| 4 | Narzędzia (TTP) | Skanery (Nessus, Burp, ZAP), eksploitacja manualna, kontrolowane PoC | Emulacja TTP konkretnej grupy APT, malware in-house, OST, C2 framework (Cobalt Strike, Sliver, Mythic) |
| 5 | Koszt | 20–150 tys. PLN (zależnie od zakresu) | 250 tys.–2 mln PLN (zależnie od scope i czasu trwania) |
| 6 | Wymagana dojrzałość | Każda — pentest to higiena | Wysoka — działający SOC/MDR, EDR/SIEM, procedury IR, wdrożone podstawowe kontrole |
| 7 | Produkt końcowy (raport) | Katalog podatności z CVSS + rekomendacje techniczne | Narracyjna oś czasu ataku + ocena detekcji + rekomendacje strategiczne |
| 8 | Świadomość Blue Team | Pełna lub większa grupa techniczna | Brak — wie tylko white team (CISO + 1-3 osoby) |
| 9 | Zakres fizyczny | Nieobecny | Opcjonalny — próby wejścia do biura, podłączenie urządzenia, tailgating |
| 10 | Socjotechnika | Pojedyncze testy phishingowe poza pentestem aplikacji | Integralna część — spear phishing, vishing, czasem deepfake-vishing jako wektor initial access |
| 11 | Atrybucja działań | Każda akcja oznaczona w logach, koordynowana z zespołem klienta | Działania pod fałszywą tożsamością; debriefing dopiero po zakończeniu |
| 12 | Debriefing / lessons learned | Sesja techniczna z dev/admin (1-2h) | Wielogodzinny board-level briefing + osobny techniczny + plan poprawy detekcji |
Kiedy wybrać pentest — pięć sygnałów
Wybór pentestu jest właściwy, gdy organizacja spełnia co najmniej jeden z poniższych warunków:
1. Niska lub średnia dojrzałość programu bezpieczeństwa. Jeśli firma nie ma jeszcze SOC, nie wdrożyła EDR, a procedury reakcji na incydenty istnieją głównie w formie dokumentu w SharePoincie — red team pokaże tylko to, co już wiesz: że obrony nie ma. Zacznij od pentestu, popraw fundamenty, dopiero potem inwestuj w testowanie zaawansowane.
2. Wymóg compliance dyktuje wąski zakres. PCI DSS 4.0 (req 11.4) wymaga pentestu segmentacji CDE; ISO/IEC 27001:2022 (A.8.29) wymaga regularnego testowania zabezpieczeń; ustawa o KSC oraz NIS2 wymagają okresowych testów penetracyjnych. W każdym z tych przypadków produktem końcowym musi być raport pentestu z konkretnymi podatnościami i rekomendacjami — nie narracja red teamu.
3. Zakres jest znany i ograniczony. Wdrażacie nową aplikację webową, dodajecie publiczne API do mobilnej, migrujecie infrastrukturę do chmury. Cel testu jest jasny: zweryfikuj, czy w tym konkretnym artefakcie nie ma podatności krytycznych przed go-live.
4. Budżet ograniczony, oczekiwany konkretny ROI. Pentest aplikacji za 40-80 tys. PLN da listę 20-60 podatności do naprawy. Red team za 500 tys. PLN da odpowiedź, której zarząd nie zawsze będzie umiał skomercjalizować, jeśli organizacja jeszcze nie ma dojrzałej obrony.
5. Pierwszy cykl testów bezpieczeństwa. Jeśli to Wasz pierwszy zewnętrzny test w danym obszarze — pentest. Zawsze. Red team przed pierwszym pentestem to jak sparing zawodowy przed pierwszym treningiem na siłowni.
📚 Przeczytaj o naszej metodyce: Metodyki testów penetracyjnych — OWASP, PTES, NIST
Kiedy wybrać red team — pięć sygnałów
Operacja red team daje wartość mierzalną tylko wtedy, gdy spełnione są warunki dojrzałości. Sygnały, które mówią „jesteście gotowi”:
1. Działający SOC (własny lub MDR) z mierzonym MTTD/MTTR. Bez zespołu, który może wykryć i zareagować, nie ma czego testować. Jeśli mierzycie czas wykrycia (Mean Time To Detect) i czas reakcji (Mean Time To Respond) w godzinach lub minutach — jesteście gotowi do weryfikacji tych metryk w boju.
2. Wdrożone narzędzia detekcji: SIEM, EDR, NDR. Red team weryfikuje skuteczność reguł detekcji, korelacji w SIEM, alertów EDR. Bez tych narzędzi raport będzie składał się z jednego zdania: „nie wykryto nic, ponieważ nie ma czego wykrywać”.
3. Formalny plan reagowania na incydenty + zespół, który go przećwiczył. Red team wygeneruje incydent. Jeśli IR plan istnieje tylko na papierze, operacja kończy się chaosem — nie nauką. Tabletop exercise wykonany w ciągu ostatnich 12 miesięcy to minimum.
4. Wymóg regulacyjny TLPT (DORA, TIBER-EU). Sektor finansowy w UE jest obejmowany rozporządzeniem DORA (2022/2554). Podmioty uznane za istotne (banki, ubezpieczyciele, CCP, część dostawców ICT) muszą przeprowadzać TLPT (Threat-Led Penetration Testing) co najmniej raz na trzy lata. TIBER-EU jest punktem odniesienia metodycznym.
5. Potrzeba demonstracji breachu dla zarządu/board. Czasami jedynym sposobem na uzyskanie budżetu na kolejną fazę dojrzałości jest pokazanie zarządowi w raporcie i podczas debriefingu, co adwersarz może osiągnąć w ciągu 6 tygodni. To narzędzie zarządzania ryzykiem na poziomie strategicznym, nie technicznym.
Algorytm decyzyjny w 4 pytaniach
Jeśli matryca i sygnały nie wystarczyły, użyj poniższego algorytmu. Odpowiedz po kolei:
- Czy macie wdrożone EDR + SIEM + procedurę IR?
- Nie → pentest (najpierw zbuduj obronę, potem ją testuj)
- Tak → idź dalej
- Czy macie SOC (własny lub MDR) z mierzonym MTTD/MTTR?
- Nie → pentest + audyt gotowości do red teamu w perspektywie 12 mies.
- Tak → idź dalej
- Czy wymóg compliance to TLPT/TIBER-EU, audyt DORA, lub board explicit ask „prove we can stop a real attack”?
- Tak → red team (lub TLPT pod DORA)
- Nie → idź dalej
- Czy celem jest mierzalne podniesienie skuteczności detekcji w 3-6 miesięcy, nie ocena niezależna?
- Tak → purple team (najlepszy ROI dla dojrzewającego SOC)
- Nie → red team (niezależna ocena całego programu)
Purple team — kompromis, który najczęściej ma sens
Najczęstszy błąd dojrzałej organizacji to zamawianie kolejnych operacji red team co rok, dostawanie raportu „wykryto 3/12 technik” i niewiele więcej. To kosztowne, frustrujące i nie podnosi obrony tak szybko, jak mogłoby.
Purple team rozwiązuje ten problem: zamiast jednorazowego werdyktu — ciągła pętla zwrotna. W praktyce wygląda to tak:
- Planowanie. Red i blue team wspólnie wybierają zestaw technik z MITRE ATT&CK do przetestowania (np. credential dumping, lateral movement via WMI, persistence via scheduled task).
- Symulacja. Red team ogłasza: „wykonuję teraz T1003.001 — OS Credential Dumping: LSASS Memory”. Wykonuje atak z konkretnym narzędziem.
- Wspólna analiza. Blue team sprawdza konsole SIEM/EDR i mówi „widzimy alert niski priorytet, brak kontekstu” lub „nie widzimy nic”.
- Strojenie detekcji. Inżynier SOC na żywo modyfikuje regułę w SIEM/EDR.
- Re-test. Red team powtarza atak. Sprawdzamy, czy alert jest precyzyjny i bogaty w kontekst.
- Cykl. Kolejna technika.
Jedna sesja purple team (zwykle 2-3 dni) potrafi dodać kilkanaście wytrenowanych w boju reguł detekcji. To realnie podnosi MTTD znacznie bardziej niż coroczny red team.
📚 Pogłębienie: Jak zorganizować purple teaming — ćwiczenia, które realnie wzmocnią Twój SOC
Model hybrydowy — continuous pentest + roczny red team
Najdojrzalsze programy bezpieczeństwa stosują dziś model hybrydowy zamiast wybierać „pentest albo red team”:
- Continuous pentest (ciągły). Krótkie iteracje (1-2 tygodnie) per artefakt — przy każdym dużym wdrożeniu aplikacji, API, infrastruktury. Cel: nie pozwolić podatnościom „dorosnąć” do red teamu.
- Kwartalne purple team. 2-3 dniowe sesje z konkretnym zestawem TTP z aktualnego threat landscape (np. techniki obserwowane w atakach na sektor energetyczny w ostatnim kwartale).
- Roczny red team. Pełna operacja 6-12 tygodni z niezależnym zespołem (lub wewnętrznym, ale z innej linii raportowania niż defenders), z celem biznesowym i pełną emulacją adwersarza.
- TLPT co 3 lata. Jeśli pod DORA — formalna kampania zgodna z TIBER-EU, z udziałem regulatora i niezależnego TI providera.
Ten model rozkłada koszty w czasie, daje stały feedback technicznym zespołom, regularnie podnosi detekcję, i raz w roku weryfikuje całość pod realnym atakiem.
Pojęcia, które warto znać
- TTP (Tactics, Techniques, Procedures) — taksonomia działań adwersarza. Taktyka to „co” (np. exfiltration), technika to „jak” (np. exfiltration over C2 channel), procedura to „dokładnie jakim narzędziem”.
- TIBER-EU (Threat Intelligence-Based Ethical Red Teaming) — framework Europejskiego Banku Centralnego dla testów red team opartych na threat intelligence w sektorze finansowym. Punkt odniesienia metodyczny dla TLPT pod DORA.
- OST (Offensive Security Testing) — szersza kategoria obejmująca pentest, red team, purple team, threat hunting i adversary simulation. Często używana w nomenklaturze zachodnich providerów.
- MITRE ATT&CK — globalna baza wiedzy o TTP atakujących, używana zarówno przez red team (do planowania), jak i blue team (do tuningowania detekcji).
- Assumed breach — model operacji, w której zaczyna się od założenia, że adwersarz jest już w środku (np. otrzymał laptop pracownika). Eliminuje fazę initial access i pozwala skupić się na lateral movement i detection.
Najczęstsze pułapki przy zamawianiu
W rozmowach z klientami widzimy te same błędy co kwartał:
- „Chcemy red team, bo to brzmi dojrzalej.” Bez SOC i EDR — to wyrzucenie budżetu.
- „Pentest aplikacji wystarczy, mamy zespół IT.” Aplikacja to jeden artefakt. Realny atak rzadko wchodzi przez aplikację — wchodzi przez phishing do pracownika, potem lateral movement do aplikacji. Pentest pokazuje 5% powierzchni.
- „Red team wykryje wszystko, co pentest, plus więcej.” Nie. Red team z definicji unika hałasu — pominie wiele podatności technicznych, których wykorzystanie generowałoby alert. Pentest i red team to różne narzędzia.
- „Robimy red team raz, wystarczy.” Bez purple team między red teamami detekcja nie poprawia się systematycznie.
- „Białe pole zamiast ukrytego, oszczędzimy 30%.” Tak, ale tracicie 80% wartości — realistyczna obrona testowana jest tylko wtedy, gdy obrońcy nie wiedzą o ataku.
Jak nFlo dobiera ćwiczenie do dojrzałości klienta
W nFlo zaczynamy od dwugodzinnego warsztatu zakresowego, podczas którego weryfikujemy dojrzałość programu bezpieczeństwa wg powyższego algorytmu. W naszej praktyce z 200+ klientami i 500+ zrealizowanymi projektami widzimy, że około 70% organizacji, które proszą o ofertę red team, w rzeczywistości potrzebuje pentestu (lub serii pentestów) plus purple team. Pozostałe 30% — głównie sektor finansowy pod DORA, energetyka pod NIS2 oraz duzi operatorzy usług kluczowych — rzeczywiście jest gotowych na pełną operację red team.
Pomagamy zbudować program OST, który skaluje się z dojrzałością: zaczynając od pojedynczych testów penetracyjnych (web, mobile, API, infrastruktura, OT/ICS), przechodząc przez symulacje phishingowe jako odrębną usługę treningową dla pracowników, do purple team i pełnych operacji red team dla najdojrzalszych klientów. Czas reakcji na zgłoszenie i pierwsze warsztat zakresowy — poniżej 15 minut w godzinach pracy. Retencja klientów 98% — bo nie sprzedajemy red teamu firmie, która powinna kupić pentest.
Jeśli nie wiesz, które ćwiczenie pasuje do Waszej organizacji, najszybszą drogą jest 15-minutowa rozmowa, podczas której przejdziemy przez algorytm decyzyjny i podpowiemy, jaka jest sensowna sekwencja kolejnych 6-12 miesięcy.
Powiązane pojęcia
Poznaj kluczowe terminy związane z tym artykułem w naszym słowniku cyberbezpieczeństwa:
- Red Team — Red Team to zespół etycznych hakerów symulujący działania realnego adwersarza…
- Blue Team — Blue Team to zespół specjalistów odpowiedzialny za obronę systemów…
- Testy penetracyjne — Test penetracyjny to kontrolowany proces oceny bezpieczeństwa…
- MITRE ATT&CK — MITRE ATT&CK to baza wiedzy o taktykach i technikach atakujących…
- Phishing — Phishing to rodzaj ataku socjotechnicznego, mającego na celu oszukanie ofiary…
Dowiedz się więcej
Zapoznaj się z powiązanymi artykułami w naszej bazie wiedzy:
- Red Team, Blue Team, Purple Team — jak symulacje ataków wzmacniają cyberodporność firmy
- Testy penetracyjne — rodzaje, metodologie, przebieg
- DORA — testy penetracyjne i zaawansowane TLPT w sektorze finansowym
- Jak zorganizować purple teaming — ćwiczenia, które realnie wzmocnią Twój SOC
- Symulowane ataki hakerskie — skuteczna metoda na podniesienie bezpieczeństwa firmy
Sprawdź nasze usługi
Potrzebujesz wsparcia w zakresie cyberbezpieczeństwa? Sprawdź:
- Testy penetracyjne — kompleksowe testy bezpieczeństwa aplikacji, API i infrastruktury
- Symulacje phishingowe — treningowe kampanie spear phishing i vishing dla pracowników
- Red Team — zaawansowane operacje emulacji adwersarza i TLPT
