Red Team vs pentest: różnice, koszt i właściwy wybór

Red Team vs pentest to nie spór o lepszą usługę, lecz o właściwe pytanie. Pentest odpowiada przede wszystkim: „jakie podatności da się wykorzystać w tym systemie?”. Red Team pyta: „czy realistyczny przeciwnik osiągnie cel biznesowy i czy organizacja go wykryje oraz zatrzyma?”. Oba ćwiczenia korzystają z technik ofensywnych, ale mają inny zakres, tempo, zasady i rezultat.

Firma bez podstawowego programu łatania zwykle wyciągnie więcej wartości z pentestu. Organizacja z SOC, EDR-em, procesem reagowania i regularnymi testami może potrzebować Red Teamu, aby sprawdzić cały łańcuch obrony. Poniżej pokazujemy różnice bez marketingowych skrótów oraz prostą ścieżkę decyzji.

Red Team vs pentest — tabela porównawcza

Kryterium	Pentest	Red Team
Główny cel	Znaleźć i potwierdzić podatności w ustalonym zakresie	Osiągnąć konkretny cel przeciwnika i sprawdzić obronę
Zakres	Aplikacja, API, sieć, chmura lub wybrana infrastruktura	Wiele wektorów: technologia, ludzie, procesy, czasem fizyczne wejście
Pokrycie	Dąży do szerokiego pokrycia uzgodnionego systemu	Wybiera najskuteczniejszą ścieżkę do celu, nie wszystkie luki
Wiedza obrońców	Zespół zwykle wie o teście	Tylko mała grupa kontrolna zna szczegóły
Detekcja	Nie zawsze jest głównym przedmiotem oceny	Kluczowa część ćwiczenia
Czas	Najczęściej dni lub kilka tygodni	Najczęściej kilka tygodni lub miesięcy
Raport	Lista znalezisk, dowody, ryzyko i rekomendacje	Narracja ataku, oś czasu, punkty detekcji, cele i wnioski operacyjne
Dojrzałość klienta	Od podstawowej do wysokiej	Zwykle średnia lub wysoka
Koszt	Niższy i łatwiejszy do oszacowania	Wyższy ze względu na czas, infrastrukturę i koordynację
Sukces	Potwierdzone pokrycie i wartościowe znaleziska	Realistyczna ocena zdolności zapobiegania, wykrycia i reakcji

Najważniejsza różnica to filozofia pokrycia. Pentester może sprawdzić pięć niezależnych dróg do przejęcia konta. Red Team wykorzysta jedną, jeśli wystarczy do uzyskania dostępu do wskazanych danych, i skupi się na pozostaniu niewykrytym oraz dalszym ruchu.

Czym jest pentest w praktyce

Test penetracyjny ma zdefiniowany zakres i ramy czasowe. Przykładem jest aplikacja SaaS z API, zewnętrzna powierzchnia pięćdziesięciu adresów IP albo wewnętrzna domena Active Directory. Celem jest znalezienie możliwie wielu istotnych, wykorzystywalnych słabości w tym obszarze i pokazanie ich wpływu.

Pentest łączy automatyczny rekonesans z manualnym sprawdzaniem. Skaner może wskazać nieaktualną usługę, ale człowiek ocenia logikę biznesową, relacje uprawnień, możliwość połączenia błędów i rzeczywisty skutek. Dobre zasady opisują m.in. NIST SP 800-115, OWASP WSTG i PTES.

Wynikiem jest techniczny raport: podatność, dowód, dotknięte zasoby, scenariusz ataku, ocena ryzyka oraz sposób naprawy. Zarząd powinien otrzymać krótsze podsumowanie priorytetów i ryzyka biznesowego. Po poprawkach wykonuje się retest.

Pentest jest właściwy, gdy firma:

wdraża nową aplikację, API lub platformę mobilną;
znacząco zmieniła infrastrukturę albo architekturę;
musi spełnić wymóg klienta, ubezpieczyciela lub regulacji;
nie zna realnej ekspozycji systemu;
chce zweryfikować poprawki i bezpieczny proces rozwoju;
nie ma jeszcze dojrzałego monitoringu, który można sensownie ocenić.

Jeżeli to pierwszy test, pomocny będzie poradnik jak przygotować się do pentestu.

Czym jest Red Teaming

Red Team symuluje przeciwnika dążącego do określonego celu. Celem nie jest „znaleźć wszystkie luki”, lecz na przykład uzyskać dostęp do dokumentacji projektowej, przejąć konto uprzywilejowane, dotrzeć do systemu płatności albo wykonać kontrolowaną operację na wybranym zasobie.

Ćwiczenie może łączyć OSINT, phishing, nadużycie tożsamości, wejście przez publiczną aplikację, ruch boczny, ataki na Active Directory, chmurę i obejście detekcji. Każdy wektor musi być jawnie dozwolony w Rules of Engagement. Red Team nie otrzymuje automatycznej zgody na wszystko tylko dlatego, że test ma być realistyczny.

Techniki można mapować do MITRE ATT&CK, ale mapa nie zastępuje modelu zagrożeń. Zespół powinien odwzorować przeciwnika istotnego dla organizacji: cyberprzestępcę, grupę szpiegowską, insidera lub operatora ransomware. Inne cele i tolerancję ryzyka ma bank, inne producent, a inne mały SaaS.

Kluczowym uczestnikiem jest Blue Team — SOC, administratorzy, zespół reagowania i właściciele procesów. Red Team sprawdza nie tylko, czy można wejść, lecz także czy działania zostały zauważone, prawidłowo sklasyfikowane, eskalowane i ograniczone.

Dlaczego Red Team nie jest „większym pentestem”

Jeśli zespół ofensywny ominie dziewięć podatności i wykorzysta jedną skuteczną ścieżkę, Red Team może być udany. Ten sam wynik byłby słabym pentestem aplikacji, ponieważ nie dał klientowi oczekiwanego pokrycia.

Red Team często działa ciszej i dłużej. Może świadomie użyć legalnych narzędzi administracyjnych, rozłożyć aktywność w czasie i ograniczyć liczbę prób. Pentest w krótkim oknie generuje więcej rozpoznawalnego ruchu, bo jego celem jest szeroka weryfikacja.

Różni się też raport. Oprócz technicznych znalezisk potrzebna jest oś czasu: kiedy nastąpiło wejście, jakie alerty powstały, kto je zobaczył, gdzie przerwano eskalację i jak decyzje organizacyjne wpłynęły na wynik. Wnioski dotyczą konfiguracji EDR, reguł SIEM, procedur, komunikacji oraz uprawnień, nie tylko patchowania.

Purple Team — kiedy warto połączyć oba światy

Purple Team nie musi być osobnym stałym zespołem. To model współpracy ofensywy i obrony, w którym techniki są wykonywane jawnie, a detekcje są od razu analizowane i poprawiane. Zamiast kilkutygodniowego oczekiwania na końcowy raport Blue Team obserwuje kolejne kroki i dostraja kontrolki.

Ten format jest dobry, gdy firma chce szybko podnieść pokrycie detekcji, ale nie jest jeszcze gotowa na pełne, skryte ćwiczenie. Można przejść przez wybrane techniki ATT&CK: dump poświadczeń, nietypowe użycie PowerShell, ruch boczny, modyfikację reguł poczty i eksfiltrację testowych danych.

Purple Team nie zastępuje niezależnej oceny. Jeśli obrońcy znają każdy krok, nie sprawdzamy pełnej zdolności samodzielnego wykrycia. Zyskujemy za to szybszy cykl uczenia i mierzalne usprawnienia reguł.

Jak wybrać właściwe ćwiczenie — decyzja w pięciu krokach

Krok 1: nazwij pytanie biznesowe

Jeśli pytasz „czy nowa aplikacja ma luki?”, wybierz pentest. Jeśli pytasz „czy wykryjemy próbę kradzieży danych z systemu X?”, rozważ Red Team. Jeśli pytasz „czy nasze alerty widzą techniki ransomware?”, wybierz Purple Team lub adversary emulation.

Krok 2: oceń podstawy

Red Team ma niewielką wartość, gdy firma nie wdrożyła MFA, nie usuwa kont byłych pracowników i nie zbiera logów. Ćwiczenie szybko potwierdzi oczywistą drogę, którą taniej wykazałby audyt albo pentest. Najpierw warto uporządkować MFA, Active Directory i zarządzanie podatnościami.

Krok 3: sprawdź zdolność detekcji i reakcji

Czy istnieje SOC lub odpowiedzialny zespół? Czy logi są kompletne i zsynchronizowane czasowo? Czy organizacja ma plan reagowania na incydenty i dyżurny kanał eskalacji? Bez tego trudno mierzyć część obronną Red Teamu.

Krok 4: określ tolerancję ryzyka

Socjotechnika, testy fizyczne, ataki na produkcję i działania poza godzinami pracy wymagają dodatkowych zgód. Należy ustalić zakazane techniki, dane testowe, bezpieczne cele, kontakty awaryjne i warunki natychmiastowego przerwania.

Krok 5: dopasuj budżet i czas

Pentest zwykle trwa krócej i ma łatwiejszy do policzenia zakres. Red Team potrzebuje infrastruktury, przygotowania legendy, dłuższej obserwacji i analizy telemetrii. Szczegółowe czynniki opisuje artykuł ile kosztuje test penetracyjny.

Przykładowa ścieżka dojrzałości

Organizacja może rozwijać testy etapami:

Inwentaryzacja i skanowanie — widoczność aktywów oraz podstawowych braków.
Pentesty krytycznych systemów — manualne sprawdzenie aplikacji, API, chmury i infrastruktury.
Regularne retesty i testy zmian — potwierdzanie poprawek oraz nowych funkcji.
Ćwiczenia tabletop — sprawdzenie decyzji i komunikacji bez technicznego ataku.
Purple Team — wspólna walidacja technik oraz detekcji.
Red Team — skryta, celowa symulacja wybranego przeciwnika.
Program ciągły — powtarzanie scenariuszy, pomiar zmian i testowanie nowych zagrożeń.

Nie każda firma musi dojść do etapu siódmego. Mały biznes może uzyskać więcej wartości z dobrze wykonanego pentestu i ćwiczenia reagowania niż z kosztownej operacji Red Team.

Zasady bezpiecznego Red Teamu

Rules of Engagement powinny określać cele, dozwolone techniki, godziny, dane i systemy krytyczne. Potrzebna jest biała komórka kontrolna, która zna ćwiczenie i może je przerwać. Dowody muszą być szyfrowane, dostęp ograniczony, a artefakty po teście usunięte zgodnie z listą cleanup.

Phishing wymaga dodatkowej ostrożności. Nie należy zbierać prawdziwych haseł, upokarzać pracowników ani publikować rankingów „najgorszych użytkowników”. Celem jest sprawdzenie procesu, filtrów, zgłoszeń i reakcji. Wnioski powinny prowadzić do lepszych zabezpieczeń technicznych, nie wyłącznie kolejnego szkolenia. Mechanikę ataków opisuje przewodnik phishing w 2026.

Red Team nie może też niszczyć danych, zakłócać produkcji ani rozszerzać zakresu bez zgody. Realizm kończy się tam, gdzie zaczyna się nieakceptowalne ryzyko biznesowe.

Jak powinien wyglądać raport

Raport pentestu powinien zapewniać pokrycie i szczegółowe rekomendacje dla każdego znaleziska. Raport Red Team powinien dodatkowo zawierać:

cele i kryteria sukcesu;
profil symulowanego przeciwnika;
pełną oś czasu działań oraz detekcji;
łańcuch ataku od wejścia do celu;
mapowanie technik do ATT&CK;
telemetrię widoczną i niewidoczną dla Blue Teamu;
ocenę decyzji, eskalacji i czasu reakcji;
listę usprawnień zapobiegania, detekcji i procesu;
plan Purple Team do zweryfikowania poprawek.

Najlepszym zakończeniem jest warsztat obu zespołów. Sama efektowna demonstracja „udało się wejść” nie daje trwałej poprawy bez przełożenia na konkretne kontrolki i właścicieli działań.

Najczęstsze pytania

Czy Red Team zawsze obejmuje phishing? Nie. Socjotechnika jest jednym z możliwych wektorów i wymaga zgody. Ćwiczenie może być ograniczone do chmury, infrastruktury lub konkretnego łańcucha technicznego.

Czy pentest sprawdza SOC? Może dostarczyć telemetrii i okazji do obserwacji, ale zwykle nie jest projektowany jako pełny test detekcji. Jeśli to ważny cel, trzeba zapisać go w zakresie albo wybrać Purple Team.

Czy Red Team spełni wymóg corocznego pentestu? Nie zawsze. Regulacja lub klient może oczekiwać określonego pokrycia systemu i raportu podatności. Red Team wybiera drogę do celu, więc może nie zweryfikować całego wymaganego zakresu.

Czy najpierw trzeba zrobić pentest? Zwykle tak. Regularne testy krytycznych systemów i podstawowy monitoring zwiększają wartość Red Teamu. Wyjątkiem może być precyzyjny cel zarządczy dotyczący procesu lub konkretnego przeciwnika.

Jak często wykonywać Red Team? To zależy od ryzyka, zmian i dojrzałości. Ważniejsze od kalendarza jest potwierdzenie, że poprzednie wnioski wdrożono i można zmierzyć postęp.

Podsumowanie

Pentest szuka możliwie wielu istotnych słabości w ustalonym systemie. Red Team wybiera realistyczną ścieżkę do celu i ocenia całą obronę: ludzi, procesy, zapobieganie, detekcję oraz reakcję. Purple Team pomaga szybko przekształcić techniki atakującego w lepsze alerty i procedury.

Jeśli firma nie ma jeszcze regularnych pentestów, kompletnego logowania i procesu reagowania, zacznij od fundamentów. Jeśli te elementy działają, Red Team może odpowiedzieć na znacznie trudniejsze pytanie: nie „czy mamy luki?”, lecz „czy potrafimy zatrzymać prawdziwy łańcuch ataku?”. W doborze zakresu pomoże krótka konsultacja.

Źródła i dalsza lektura: NIST SP 800-115, MITRE ATT&CK, Penetration Testing Execution Standard, OWASP Web Security Testing Guide.