Red teaming a test penetracyjny - czym się różnią, gdzie jest TLPT i purple teaming

Pod hasłem „red team” często kryje się potrzeba testu penetracyjnego. Bywa też odwrotnie: organizacja zamawia kolejny pentest tych samych systemów, choć jej prawdziwe pytanie brzmi „czy ktoś by nas zauważył?”. Porównujemy cztery pojęcia, które często padają razem - test penetracyjny, red teaming, TLPT i purple teaming - z perspektywy zespołu, który prowadzi testy bezpieczeństwa. Stan na: październik 2026 r.

Red teaming, test penetracyjny, TLPT i purple teaming - porównanie

Najkrócej: test penetracyjny mierzy system, red teaming mierzy obronę, TLPT to red teaming w procedurze nadzorczej DORA, a purple teaming to sposób pracy nad wynikami. Tabela pokazuje różnice w sześciu wymiarach, które decydują o wyborze testu.

Pierwsze dwie kolumny to wybór, którego dokonuje sama organizacja. Trzecia - TLPT - nie jest wyborem, tylko obowiązkiem wskazanych podmiotów finansowych. Czwarta nie jest osobnym testem, ale formatem, który można dołożyć do każdego z nich.

Na jakie pytanie odpowiada każdy test

• Test penetracyjny: jakie podatności ma ten system i jak poważne są w naszym kontekście?
• Red teaming: czy ktoś, kto chce dostać się do naszych najcenniejszych danych, dojdzie do nich - i czy zauważymy go, zanim to zrobi?
• TLPT: czy krytyczne funkcje podmiotu finansowego wytrzymają realistyczny atak w procedurze, którą uzna organ nadzoru?
• Purple teaming: które etapy ataku umiemy już wykrywać, a których jeszcze nie - i jak szybko to zmienić?

Jeśli zarząd pyta „czy jesteśmy bezpieczni?”, zwykle chodzi mu o drugie pytanie. Odpowiedź na nie ma jednak sens dopiero wtedy, gdy pierwsze ma już odpowiedź - inaczej red team wejdzie przez lukę, którą znalazłby zwykły pentest.

Ten sam system, dwa różne raporty - przykład demonstracyjny

Fikcyjna firma ubezpieczeniowa ma portal klienta, API dla aplikacji mobilnej i systemy rozliczeń w sieci wewnętrznej. Zamawia najpierw test penetracyjny portalu i API, a pół roku później red teaming z celem „odczyt pliku testowego z serwera rozliczeń”. Wszystkie dane w tym przykładzie są demonstracyjne.

• Raport z pentestu zawiera kilkanaście ustaleń dla portalu i API, każde z dowodem, oceną CVSS i zaleceniem. Jedno z nich - zbyt szerokie uprawnienia konta technicznego API - dostaje ocenę średnią, bo samo w sobie nie daje dostępu do danych klientów.
• Raport z red teamingu opisuje jedną ścieżkę: to samo konto techniczne, którego uprawnień nie ograniczono po pentestach, staje się mostem do sieci wewnętrznej, a stamtąd do serwera rozliczeń. Oś czasu pokazuje, że system monitorowania zarejestrował dwa z pięciu kroków, ale alert pojawił się dopiero przy czwartym, a zespół dyżurny nie miał procedury izolowania serwera aplikacyjnego.

Pentest dał listę rzeczy do naprawy. Red teaming pokazał, które z nich naprawdę prowadziły do celu, i dołożył ustalenia, których w pentestach nie ma wcale: brakujące reguły wykrywania i lukę w procedurze reagowania.

Red team, blue team i zespół kontrolny - kto jest kim

Nazwy ról są opisane w słownikach bezpieczeństwa, m.in. w glosariuszu NIST, który przytacza definicje z CNSSI 4009-2022:

• red team - grupa upoważniona i zorganizowana do naśladowania możliwości ataku potencjalnego przeciwnika; jej zadaniem jest pokazać skutki udanego ataku i to, co w obronie działa,
• blue team - grupa odpowiedzialna za obronę systemów organizacji przed pozorowanymi atakującymi (red teamem); w firmie to dział bezpieczeństwa, administratorzy i SOC, także zewnętrzny,
• white team - mała grupa, która wie o działaniach red teamu z wyprzedzeniem, obserwuje je i pilnuje, żeby ćwiczenie nie wyszło poza ustalony zakres; w TLPT tę funkcję pełni zespół kontrolny (control team) po stronie podmiotu.

W praktyce najważniejsza jest trzecia rola. To zespół kontrolny decyduje, co się dzieje, gdy blue team podniesie alarm, kiedy przerwać działania i jak chronić poufność ćwiczenia. Bez niego red teaming jest albo zbyt ostrożny, żeby coś pokazać, albo zbyt ryzykowny dla produkcji.

Purple teaming - format pracy, a nie osobny test

Purple teaming to wspólna praca atakujących i obrońców: red team pokazuje krok po kroku, co zrobił, a blue team sprawdza, co widział w swoich narzędziach, uzupełnia brakujące logi i reguły, a potem prosi o powtórzenie kroku, żeby zobaczyć, czy alert się pojawia. Nikt nikogo nie zaskakuje - celem jest nauka, nie ocena. Kroki ataku można opisać taktykami i technikami z bazy MITRE ATT&CK - publicznej bazy wiedzy o działaniach przeciwników - co pozwala obrońcom zestawić każdy krok z własnymi regułami wykrywania.

W TLPT ten element jest obowiązkowy: w fazie zamknięcia po raportach red i blue team odbywa się odtworzenie ataku i warsztat purple team. Europejski Bank Centralny opublikował też osobne wytyczne, jak prowadzić purple teaming w ramach TIBER-EU, w fazie testów albo zamknięcia. Poza TLPT purple teaming warto stosować:

• po każdym red teamingu - jako sposób omówienia wyników, który od razu zamienia ustalenia w poprawki,
• po wdrożeniu nowego narzędzia monitorowania - żeby sprawdzić, czy wykrywa to, co miało,
• gdy zespół obrony jest nowy albo zmienił się dostawca SOC - jako przegląd procedur na realistycznych przykładach.

Gdzie w tym wszystkim jest TLPT

TLPT (testy penetracyjne ukierunkowane przez analizę zagrożeń) to red teaming ujęty w procedurę z art. 26-27 DORA i rozporządzenia delegowanego (UE) 2025/1190. Od „zwykłego” red teamingu różni go przede wszystkim to, kto o nim decyduje i jak jest nadzorowany:

• test przeprowadzają tylko podmioty finansowe wskazane przez organ - w Polsce przez KNF w drodze decyzji (art. 18zk ustawy o nadzorze nad rynkiem finansowym) - nie rzadziej niż co trzy lata (art. 26 ust. 1 DORA),
• scenariusze przygotowuje zewnętrzny dostawca analizy zagrożeń, a nie sam red team,
• aktywna faza testów red team trwa co najmniej 12 tygodni (art. 11 ust. 5 rozporządzenia delegowanego 2025/1190) i obejmuje działające systemy produkcyjne (art. 26 ust. 2 DORA),
• testerzy muszą spełniać wymagania art. 27 DORA i rozporządzenia delegowanego,
• organ nadzoruje przebieg i na końcu wydaje poświadczenie przeprowadzenia testu.

Terminy etapów, role i wymagania wobec testerów TLPT opisujemy na stronie o przygotowaniu do TLPT, a relację TLPT do programu testowania z art. 24-25 w artykule testy penetracyjne a TLPT.

Każde TLPT jest red teamingiem, ale nie każdy red teaming jest TLPT. Ćwiczenie zamówione przez organizację samodzielnie, nawet bardzo rozbudowane, nie zastępuje TLPT i nie daje poświadczenia organu. Może natomiast przygotować do niego zespół kontrolny i obrońców.

Który test zamówić - ścieżka dojrzałości

Testy ofensywne układają się w kolejność. Pomijanie kroków zwykle kończy się tym, że droższy test odkrywa to, co tańszy znalazłby szybciej:

1. Skan podatności i testy penetracyjne najważniejszych systemów - zaczynając od tego, co widać z internetu, i od systemów z danymi klientów.
2. Naprawy i retest - dopóki znane podatności czekają na poprawkę, kolejny test powie niewiele nowego.
3. Monitoring i reagowanie - logi w jednym miejscu, ktoś, kto analizuje alerty, i procedura eskalacji.
4. Red teaming z celami zarządu - sprawdzenie, czy to wszystko działa razem na realistycznej ścieżce ataku.
5. Purple teaming - zamiana wyników red teamingu w lepsze wykrywanie i ponowne sprawdzenie poprawionych reguł.
6. TLPT - gdy KNF wskaże podmiot finansowy decyzją; wcześniejsze kroki skracają drogę do dobrego wyniku.

Wybór między podejściami do samego testu penetracyjnego - ile tester wie o systemie na starcie - opisujemy w artykule black box, grey box czy white box, a różnice między skanem, pentestem i audytem - w artykule pentest, skan podatności czy audyt.

Najczęstsze nieporozumienia

• „Red team znajdzie wszystkie nasze podatności.” Nie znajdzie i nie ma takiego zadania. Szuka jednej drogi do celu; do pełnego przeglądu podatności służy test penetracyjny.
• „Red teaming to pentest bez ograniczeń.” Jest odwrotnie: im większa swoboda wyboru drogi, tym dokładniejsze reguły zaangażowania, warunki przerwania i nadzór zespołu kontrolnego.
• „Jeśli blue team nas wykrył, test się nie udał.” Wykrycie to dobry wynik. Raport pokaże, jak szybko do niego doszło i czy reakcja zadziałała.
• „Wewnętrzne ćwiczenie red team spełnia wymóg TLPT.” Nie. TLPT ma własną procedurę, nadzór organu i poświadczenie.
• „Purple teaming zastępuje red teaming.” Jawna współpraca dobrze uczy wykrywania technik, ale nie sprawdza, jak organizacja reaguje na atak, o którym nie wie.

Czy red teaming bez socjotechniki ma sens?

Wiele ćwiczeń red team zaczyna się od wiadomości do pracowników. My tego nie robimy: nie prowadzimy phishingu, socjotechniki, testów fizycznych ani testów DoS. Etap wejścia zastępujemy scenariuszem założonego incydentu (assumed breach) - zespół kontrolny przygotowuje komputer zwykłego pracownika w sieci firmy, a ćwiczenie sprawdza, co atakujący może zrobić dalej i czy obrona go zatrzyma.

Takie podejście nie odpowiada na pytanie, ilu pracowników kliknęłoby w złośliwy link. Odpowiada natomiast na pytanie, które przy realnym incydencie decyduje o skali szkód: co się dzieje po pierwszym przejętym komputerze. Obok scenariusza wewnętrznego można prowadzić scenariusze startujące z internetu, z konta klienta w aplikacji albo z przejętego klucza w chmurze.

Jak możemy pomóc

Prowadzimy red teaming dla organizacji, które mają za sobą testy penetracyjne: z celami uzgodnionymi z zarządem, zespołem kontrolnym po stronie klienta, raportem z osią czasu wykrycia i sesją z zespołem obrony. Jeśli dopiero zaczynasz, punktem wyjścia są testy penetracyjne aplikacji, API, infrastruktury i chmury. Nie jesteśmy testerem TLPT - podmiotom finansowym pomagamy w testach z art. 24-25 DORA i w przygotowaniu do TLPT.