Red Team

Co to jest Red Team w cyberbezpieczeństwie?

Red Team to zespół specjalistów, który na zlecenie organizacji i za jej zgodą odtwarza działania realnego przeciwnika, aby sprawdzić, czy zabezpieczenia techniczne, procesy i pracownicy są w stanie wykryć atak oraz na niego zareagować. Według definicji NIST (CNSSI 4009-2022) jest to grupa osób upoważnionych i zorganizowanych w celu odtwarzania metod ataku i wykorzystywania podatności, jakimi może posłużyć się potencjalny przeciwnik organizacji. Działania takiego zespołu określa się mianem red teamingu.

W Polsce obowiązek przeprowadzania testów z udziałem zespołu Red Team wynika obecnie z przepisów dla sektora finansowego. Rozporządzenie DORA zobowiązuje podmioty finansowe wskazane przez właściwe organy do przeprowadzania nie rzadziej niż co trzy lata zaawansowanych testów TLPT (Threat-Led Penetration Testing), w których symulowany atak prowadzi zespół Red Team.

Skąd pochodzi nazwa „Red Team”?

Nazwa „Red Team” wywodzi się z wojskowości. Jak wyjaśnia Micah Zenko z Council on Foreign Relations, określenie to pochodzi z okresu zimnej wojny, a kolor czerwony oznaczał Armię Czerwoną, czyli przeciwnika.

Z czasem ćwiczenia z udziałem zespołu odgrywającego rolę przeciwnika zaczęto stosować w cyberbezpieczeństwie, gdzie służą one do oceny zabezpieczeń z perspektywy atakującego. Dzięki temu organizacja może sprawdzić nie tylko to, jak zaprojektowano jej zabezpieczenia, lecz także to, jak zachowują się one w zetknięciu z przeciwnikiem, który aktywnie szuka sposobu na ich obejście.

Czym red teaming różni się od testów penetracyjnych?

Test penetracyjny to kontrolowana próba wykorzystania podatności w ściśle określonym zakresie, na przykład w aplikacji internetowej, sieci wewnętrznej lub stacjach roboczych. Zgodnie z NIST SP 800-53 test penetracyjny jest wyspecjalizowanym rodzajem oceny bezpieczeństwa, przeprowadzanym na systemach lub ich pojedynczych komponentach. Celem testu penetracyjnego jest zwykle znalezienie jak największej liczby podatności w badanym zakresie. Zespół IT organizacji jest najczęściej poinformowany o teście.

Red teaming ma szerszy zakres niż test penetracyjny. Według NIST SP 800-53 ćwiczenia Red Team rozszerzają cele testów penetracyjnych o ocenę poziomu bezpieczeństwa całej organizacji oraz jej zdolności do skutecznej obrony. Zespół Red Team otrzymuje zwykle konkretny cel, na przykład uzyskanie dostępu do systemu płatności lub bazy danych klientów. Aby go osiągnąć, może łączyć ataki na systemy IT z socjotechniką, a w niektórych ćwiczeniach również z próbą uzyskania fizycznego dostępu do budynku. Zespół odpowiedzialny za obronę zwykle nie jest informowany o teście, dzięki czemu ćwiczenie pokazuje, jak organizacja reaguje na atak w warunkach zbliżonych do rzeczywistych.

Poniższa tabela przedstawia różnice między obiema metodami, które zwykle występują w branży. Konkretny zakres każdego testu zależy od ustaleń między organizacją a zespołem testującym.

Kryterium	Test penetracyjny	Red teaming
Cel	Znalezienie podatności w określonym zakresie	Sprawdzenie, czy przeciwnik może osiągnąć konkretny cel i czy organizacja go wykryje
Zakres	Wybrane systemy lub aplikacje	Organizacja jako całość: technologia, procesy i ludzie
Zespół obrony	Zwykle wie o teście	Zwykle nie wie o teście
Techniki	Głównie techniczne	Techniczne, socjotechniczne, czasem fizyczne
Wynik	Lista podatności z oceną ryzyka	Opis ścieżki ataku i ocena zdolności wykrywania i reagowania

Wybór metody zależy przede wszystkim od dojrzałości organizacji. Test penetracyjny jest zwykle punktem wyjścia, ponieważ pozwala wykryć i usunąć podatności w poszczególnych systemach. Red teaming jest zwykle najbardziej wartościowy dla organizacji, które mają już działający proces monitorowania i reagowania na incydenty (na przykład własny lub zewnętrzny SOC) i chcą sprawdzić skuteczność tego procesu.

Jak przebiega ćwiczenie Red Team?

Przebieg ćwiczenia zależy od jego celu i zakresu. W Europie punktem odniesienia są często ramy TIBER-EU, opracowane przez Europejski Bank Centralny w 2018 roku i zaktualizowane w latach 2024–2025. Według TIBER-EU test przebiega w trzech obowiązkowych fazach: przygotowania, testowania i zamknięcia.

Faza 1: Przygotowanie i ustalenie zakresu

W fazie przygotowania organizacja powołuje zespół kontrolny (Control Team, w starszych wersjach TIBER-EU nazywany White Team). Zespół kontrolny to wąska grupa osób, które wiedzą o teście, zarządzają związanym z nim ryzykiem, zatwierdzają plan działań i jego zmiany oraz mogą w każdej chwili wstrzymać ćwiczenie. W tej fazie ustala się zakres testu, w tym funkcje krytyczne, które zostaną nim objęte. Organizacja i testerzy uzgadniają również zasady prowadzenia testu (rules of engagement), które wyznaczają granice działań zespołu Red Team. Test odbywa się na systemach produkcyjnych, dlatego ramy TIBER-EU wskazują na ryzyko zakłóceń i awarii. Zespół kontrolny musi aktywnie zarządzać tym ryzykiem przez cały czas trwania ćwiczenia.

Faza 2: Rozpoznanie zagrożeń i aktywne testowanie

Faza testowania rozpoczyna się od analizy zagrożeń (threat intelligence). Dostawca analizy zagrożeń przygotowuje raport o grupach przestępczych, które mogą zaatakować daną organizację, oraz o stosowanych przez nie technikach. Na podstawie tego raportu zespół Red Team opracowuje scenariusze ataku. Następnie testerzy realizują przygotowane scenariusze. Ich działania mogą obejmować m.in. rozpoznanie infrastruktury, uzyskanie początkowego dostępu (na przykład za pomocą phishingu lub wykorzystania podatności w systemie dostępnym z internetu), lateral movement oraz eskalację uprawnień. Zespół odpowiedzialny za obronę pracuje w tym czasie w zwykłym trybie, a sposób, w jaki reaguje na kolejne działania testerów, jest jednym z najważniejszych wyników ćwiczenia.

Faza 3: Zamknięcie testu i plan naprawczy

Po zakończeniu fazy aktywnej zespół Red Team opisuje w raporcie przebieg ataku, wykorzystane techniki oraz momenty, w których jego działania zostały wykryte lub pozostały niezauważone. Zespół obrony przygotowuje własny raport, a obie strony omawiają wyniki podczas wspólnego odtworzenia przebiegu testu. Ramy TIBER-EU w wersji ogłoszonej przez Europejski Bank Centralny w lutym 2025 roku przewidują w tej fazie obowiązkowe ćwiczenie typu purple teaming. Polega ono na wspólnej pracy testerów i zespołu obrony nad lukami w mechanizmach wykrywania. Wynik testu nie ma formy oceny „zaliczony” lub „niezaliczony”. Rezultatem ćwiczenia jest przede wszystkim plan naprawczy, który określa działania i terminy ich wdrożenia.

Jak Red Team wykorzystuje MITRE ATT&CK do naśladowania przeciwnika?

Naśladowanie przeciwnika (adversary emulation) to podejście, w którym zespół Red Team odtwarza sposób działania konkretnej grupy przestępczej lub grupy APT, która rzeczywiście prowadzi ataki. Według MITRE Center for Threat-Informed Defense emulacja przeciwnika pozwala odtwarzać takie zachowanie w sposób bezpieczny i powtarzalny. Dzięki temu wyniki kolejnych testów można porównywać i sprawdzać, czy wprowadzone zmiany poprawiły wykrywanie.

Podstawą takich scenariuszy jest zwykle baza wiedzy MITRE ATT&CK, która opisuje taktyki i techniki stosowane przez grupy przestępcze oraz grupy APT. Zespół Red Team wybiera techniki przypisane do grupy, która według analizy zagrożeń może zaatakować organizację, i układa je w scenariusz testu. MITRE udostępnia również przykładowe plany emulacji opracowane na podstawie publicznych raportów o zagrożeniach.

Wspólna klasyfikacja ATT&CK ułatwia przełożenie wyników testu na konkretne zadania dla zespołu obrony. W ten sposób każdą technikę, która nie została wykryta przez system SIEM lub EDR, można jednoznacznie wskazać za pomocą nazwy i identyfikatora ATT&CK, a następnie przygotować dla niej regułę detekcji.

Czy DORA i NIS2 wymagają testów Red Team?

Obowiązek przeprowadzania testów z udziałem zespołu Red Team wynika wprost wyłącznie z rozporządzenia DORA i dotyczy podmiotów finansowych wskazanych przez właściwe organy. Dyrektywa NIS2 i Ustawa o Krajowym Systemie Cyberbezpieczeństwa wymagają oceny skuteczności zabezpieczeń, ale nie wskazują red teamingu jako obowiązkowej metody tej oceny.

Testy TLPT w rozporządzeniu DORA

Rozporządzenie DORA (Digital Operational Resilience Act, rozporządzenie (UE) 2022/2554), stosowane od 17 stycznia 2025 roku, wprowadza dla sektora finansowego zaawansowane testy TLPT. Zgodnie z art. 26 rozporządzenia podmioty finansowe wskazane przez właściwe organy przeprowadzają takie testy nie rzadziej niż co trzy lata, przy czym organ może tę częstotliwość zmienić. Obowiązek ten nie dotyczy wszystkich podmiotów finansowych, lecz tylko tych, które organ wskaże ze względu na ich wpływ na sektor, znaczenie dla stabilności finansowej oraz profil ryzyka ICT. Test obejmuje funkcje krytyczne lub istotne podmiotu i jest prowadzony na systemach produkcyjnych.

Szczegółowe zasady testów określa rozporządzenie delegowane Komisji (UE) 2025/1190, przygotowane zgodnie z ramami TIBER-EU. Rozporządzenie definiuje Red Team jako wewnętrznych lub zewnętrznych testerów zaangażowanych w przeprowadzenie testu TLPT. Zgodnie z tym aktem aktywna faza testu trwa co najmniej 12 tygodni. Art. 27 DORA określa również wymagania wobec testerów, m.in. w zakresie doświadczenia, certyfikacji (lub przestrzegania kodeksów etycznych) oraz ubezpieczenia od odpowiedzialności zawodowej.

W Polsce nadzór nad stosowaniem DORA w sektorze finansowym sprawuje Komisja Nadzoru Finansowego, która informowała również o przygotowaniach do polskiej adaptacji ram TIBER-EU pod nazwą TIBER-PL. Odpowiedzialność za przeprowadzenie testu i wdrożenie planu naprawczego pozostaje po stronie podmiotu finansowego, również wtedy, gdy test wykonują zewnętrzni testerzy.

Red teaming a NIS2 i Ustawa o Krajowym Systemie Cyberbezpieczeństwa

Dyrektywa NIS2 nie wymaga wprost przeprowadzania ćwiczeń Red Team. Art. 21 ust. 2 lit. f dyrektywy zobowiązuje podmioty kluczowe i ważne do wdrożenia polityk i procedur służących ocenie skuteczności środków zarządzania ryzykiem w cyberbezpieczeństwie, ale nie wskazuje konkretnej metody tej oceny. Podobnie Ustawa o Krajowym Systemie Cyberbezpieczeństwa wymienia wśród środków zarządzania ryzykiem m.in. testowanie systemu informacyjnego oraz polityki i procedury oceny skuteczności środków technicznych i organizacyjnych.

Red teaming może być jedną z metod realizacji tych wymagań obok testów penetracyjnych, skanowania podatności i audytów bezpieczeństwa. Wybór metody i jej uzasadnienie należą jednak do podmiotu zobowiązanego. Zakres testów warto przy tym dopasować do wyników analizy ryzyka, ponieważ to ona wskazuje, które systemy i scenariusze ataku są dla organizacji najistotniejsze.

Czym Red Team różni się od Blue Team i Purple Team?

Zespoły różnią się przede wszystkim rolą w ćwiczeniu. Red Team odtwarza działania atakującego, Blue Team odpowiada za wykrywanie i odpieranie ataku, a Purple Team łączy obie perspektywy, aby szybciej poprawić skuteczność wykrywania zagrożeń.

Red Team to zespół, który odtwarza działania przeciwnika i sprawdza, czy może osiągnąć wyznaczony cel bez wykrycia. Wartość takiego ćwiczenia polega na pokazaniu rzeczywistej ścieżki ataku, która może łączyć kilka pojedynczych podatności i błędów konfiguracji.

Blue Team to zespół odpowiedzialny za obronę systemów organizacji. Według NIST jest to grupa, która utrzymuje poziom bezpieczeństwa organizacji w trakcie ataków pozorowanych przez zespół Red Team. W praktyce funkcję tę pełni zwykle centrum operacji bezpieczeństwa (SOC), które monitoruje środowisko, analizuje alerty i reaguje na incydenty.

Purple Team to często forma współpracy zespołów Red Team i Blue Team, dlatego nie musi oznaczać powołania osobnego zespołu. Rozporządzenie delegowane (UE) 2025/1190 definiuje purple teaming jako wspólne działanie testowe, w którym uczestniczą zarówno testerzy, jak i zespół obrony. Podczas takich ćwiczeń testerzy mogą stosować techniki ataku jawnie, a członkowie zespołu obrony na bieżąco sprawdzają, czy zostały one wykryte. Dzięki temu luki w wykrywaniu można usuwać jeszcze w trakcie ćwiczenia. W testach TLPT ćwiczenie to odbywa się po zakończeniu fazy aktywnej.

Na czym polega red teaming systemów sztucznej inteligencji?

Red teaming systemów sztucznej inteligencji to zaplanowane i uporządkowane testy, których celem jest znalezienie wad i podatności systemu AI. Testy te prowadzi się często w kontrolowanym środowisku i we współpracy z twórcami systemu. Taką definicję podaje NIST w publikacji SP 800-218A. Testy tego rodzaju mogą obejmować m.in. próby obejścia zabezpieczeń modelu, wstrzykiwanie poleceń (prompt injection) oraz próby wydobycia z modelu danych, których nie powinien ujawniać.

Zgodnie z art. 55 aktu w sprawie sztucznej inteligencji (rozporządzenie (UE) 2024/1689) dostawcy modeli AI ogólnego przeznaczenia z ryzykiem systemowym są zobowiązani do przeprowadzania i dokumentowania testów kontradyktoryjnych (adversarial testing) modelu. Załącznik XI, który określa zakres dokumentacji technicznej modelu, wymienia red teaming jako przykład testów kontradyktoryjnych. Obowiązek ten spoczywa na dostawcach takich modeli i nie obejmuje organizacji, które z nich korzystają. Organizacje wdrażające rozwiązania AI mogą jednak stosować podobne testy, aby ocenić ryzyko związane z własnymi zastosowaniami.

Pojęcia powiązane z Red Team