Jedna luka w aplikacji nie mówi jeszcze, czy firma potrafi obronić się przed rzeczywistym atakiem. Dopiero kontrolowane starcie ofensywnego zespołu z obrońcami pokazuje, czy monitoring, procedury i ludzie działają razem. Wyjaśniam, czym różnią się red team i blue team, jak zaplanować takie ćwiczenie, czym różni się ono od pentestu oraz jak wyciągnąć z niego konkretne usprawnienia dla środowiska IT.
Dwa zespoły sprawdzają, czy organizacja naprawdę potrafi się obronić
- Red team odtwarza działania przeciwnika i próbuje osiągnąć wcześniej ustalony cel.
- Blue team wykrywa, analizuje i zatrzymuje symulowany atak.
- White team pilnuje zasad, bezpieczeństwa ćwiczenia i zakresu autoryzacji.
- Purple teaming łączy atakujących i obrońców, aby szybciej poprawiać detekcję.
- Najlepszym wynikiem nie jest samo włamanie, lecz krótszy czas wykrycia i reakcji.
Red team i blue team to dwa spojrzenia na ten sam problem
Red team działa jak przeciwnik. W ramach pisemnie zatwierdzonego scenariusza szuka drogi do określonego celu, na przykład dostępu do danych testowych, konta uprzywilejowanego albo krytycznej aplikacji. Nie chodzi o bezmyślne „łamanie wszystkiego”, ale o sprawdzenie, jak daleko można zajść bez uruchomienia skutecznej obrony.
Blue team odpowiada za ochronę środowiska. Zwykle tworzą go analitycy SOC, administratorzy, inżynierowie bezpieczeństwa i osoby zajmujące się reagowaniem na incydenty. Ich zadaniem jest rozpoznanie podejrzanej aktywności, ocena jej znaczenia, ograniczenie skutków i udokumentowanie reakcji.
NIST opisuje oba zespoły jako element operacyjnego ćwiczenia bezpieczeństwa, w którym atakujący emulują potencjalnego przeciwnika, a obrońcy pracują w warunkach zbliżonych do rzeczywistych. Nad całością często czuwa white team, czyli neutralna grupa odpowiedzialna za reguły, komunikację awaryjną i ochronę biznesu.
| Zespół | Główne zadanie | Przykładowy rezultat |
|---|---|---|
| Red team | Emulowanie technik atakującego | Dotarcie do określonego celu i pokazanie ścieżki ataku |
| Blue team | Wykrywanie i odpieranie działań | Alert, analiza, blokada i raport z reakcji |
| White team | Nadzór nad ćwiczeniem | Zakres, reguły zaangażowania i bezpieczne zakończenie |
| Purple team | Wspólna poprawa zabezpieczeń | Lepsze reguły detekcji i ponowny test |
Najczęstsze nieporozumienie polega na traktowaniu tych ról jak zawodów, w których jedna strona ma „wygrać”. W praktyce wygrana organizacji następuje wtedy, gdy atak ujawnia słabość, obrona potrafi ją zauważyć, a zespół usuwa przyczynę problemu.
Jak wygląda ćwiczenie od celu do raportu
Dobre ćwiczenie zaczyna się od pytania biznesowego, a nie od listy narzędzi. Firma może chcieć sprawdzić, czy napastnik przejmie konto administratora, czy SOC wykryje kradzież sesji albo czy zespół potrafi odłączyć zainfekowaną stację bez zatrzymania całej produkcji.
1. Ustalenie zakresu i zasad
Przed rozpoczęciem trzeba określić systemy objęte testem, godziny działań, dopuszczalne techniki, dane wyłączone z ćwiczenia oraz osoby uprawnione do przerwania operacji. W przypadku środowisk chmurowych i usług zewnętrznych potrzebne mogą być dodatkowe zgody dostawców.
Zakres powinien obejmować także procedurę awaryjną. Jeśli symulowany atak wpłynie na dostępność usługi, white team musi wiedzieć, kto podejmuje decyzję o zatrzymaniu działań i jak odróżnić ćwiczenie od prawdziwego incydentu.
2. Przygotowanie scenariusza
Red team wybiera realistyczny profil przeciwnika i cel operacji. Pomocny jest MITRE ATT&CK, czyli baza taktyk i technik obserwowanych w rzeczywistych kampaniach. Dzięki niej ćwiczenie można opisać konkretnie, na przykład jako próbę uzyskania dostępu, eskalacji uprawnień, ruchu bocznego i dostępu do danych.
Nie każda organizacja potrzebuje pełnej, wielotygodniowej operacji. Mniejsza firma może zacząć od jednego celu i kilku technik, a dopiero później rozszerzyć test o phishing, fizyczny dostęp, pracę zdalną czy dostawców.
3. Wykonanie i obserwacja
Red team działa zgodnie z ustalonymi regułami, a blue team pracuje tak, jak podczas normalnego dyżuru. Jeżeli obrońcy wiedzą dokładnie, kiedy nastąpi atak i z jakiego adresu, wynik będzie mało miarodajny. Z drugiej strony całkowity brak informacji może stworzyć ryzyko operacyjne, dlatego zakres wiedzy warto podzielić według ról.
W trakcie ćwiczenia mierzy się między innymi czas do wykrycia, czas do kwalifikacji zdarzenia, czas do ograniczenia zagrożenia oraz jakość komunikacji. Sam fakt zadziałania narzędzia EDR lub SIEM nie wystarcza, jeśli alert pozostaje nieprzeanalizowany przez kilka godzin.
4. Omówienie i ponowny test
Raport powinien opisywać pełną ścieżkę ataku, użyte techniki, obserwowane logi, reakcję zespołu i wpływ na cel biznesowy. Dobre zalecenie brzmi konkretnie, na przykład „dodać detekcję dla określonego zachowania i przetestować ją w ciągu 14 dni”, zamiast „poprawić monitoring”.
Największą wartość daje retest, czyli ponowne wykonanie kluczowego fragmentu ćwiczenia po wdrożeniu poprawek. Bez tego organizacja często zakłada, że problem został rozwiązany, choć zmieniono tylko konfigurację, a nie rzeczywistą zdolność do wykrywania ataku.
Red teaming nie jest tym samym co pentest
Test penetracyjny zwykle koncentruje się na znalezieniu podatności w określonym systemie, aplikacji lub infrastrukturze. Red teaming ma szerszy cel. Sprawdza nie tylko technologię, lecz także ludzi, procesy, monitoring i reakcję operacyjną.
| Kryterium | Test penetracyjny | Red teaming |
|---|---|---|
| Główny cel | Znalezienie i potwierdzenie podatności | Osiągnięcie celu przypominającego realny atak |
| Zakres | Zwykle określony system lub aplikacja | Cała ścieżka ataku, często wiele obszarów |
| Widoczność testu | Najczęściej znana właścicielom systemu | Ograniczona do wybranych osób |
| Główna miara | Podatności i ich ważność | Wykrycie, reakcja, odporność i osiągnięcie celu |
| Raport | Lista luk z rekomendacjami | Opis operacji, detekcji, decyzji i skutków |
Oba podejścia się uzupełniają. Pentest jest dobrym wyborem, gdy trzeba zweryfikować bezpieczeństwo nowego API, aplikacji webowej albo konfiguracji serwera. Red team ma większy sens, gdy organizacja chce sprawdzić, czy potrafi obronić się przed ciągiem powiązanych działań, a nie tylko pojedynczą luką.
Zdarza się, że firmy zamawiają red team, choć nie mają podstawowej widoczności w logach ani ustalonego procesu obsługi incydentów. W takim przypadku lepiej najpierw wykonać przegląd konfiguracji, test penetracyjny i ćwiczenie reakcji. Atak bez przygotowanej obserwacji nie pokaże odporności, tylko brak danych.
Praktyczny scenariusz dla aplikacji Python
Wyobraźmy sobie firmę, która udostępnia klientom aplikację napisaną w Pythonie. Celem ćwiczenia nie musi być „zdobycie serwera”. Bardziej użyteczne pytanie brzmi: czy przeciwnik może przejąć konto użytkownika, wykorzystać błędną konfigurację API i dotrzeć do danych, a następnie czy blue team zauważy tę sekwencję.
Co sprawdza strona ofensywna
- czy proces logowania wymusza wieloskładnikowe uwierzytelnianie dla kont uprzywilejowanych,
- czy API poprawnie kontroluje dostęp do obiektów należących do innych użytkowników,
- czy sekrety i tokeny nie trafiają do repozytorium, obrazu kontenera albo logów,
- czy możliwe jest przejście z aplikacji do innych usług w tej samej sieci,
- czy mechanizmy blokowania i limitowania żądań reagują na nietypową aktywność.
W tym miejscu Python może pomóc także stronie defensywnej. Krótkie skrypty mogą normalizować logi, korelować zdarzenia z wielu usług albo automatycznie sprawdzać, czy po wdrożeniu poprawki nadal występuje określony wzorzec. Automatyzacja nie zastępuje analityka, ale skraca drogę od zdarzenia do decyzji.
Przeczytaj również: Podman vs Docker - Co wybrać? Porównanie i decyzja
Co obserwuje blue team
Obrońcy powinni mieć dostęp do logów aplikacyjnych, reverse proxy, systemu tożsamości, chmury i urządzeń końcowych. Liczy się nie tylko obecność danych, ale też ich jakość: poprawny czas, identyfikator użytkownika, adres źródłowy, identyfikator żądania i informacja o wyniku operacji.
Jeśli alert pojawia się dopiero po masowym pobraniu danych, monitoring zadziałał zbyt późno. Lepszy sygnał może powstać z połączenia kilku zdarzeń, na przykład nowego logowania z nietypowej lokalizacji, zmiany uprawnień i serii żądań do zasobów, których użytkownik wcześniej nie otwierał.
Po ćwiczeniu zespół może zbudować test regresyjny. W praktyce oznacza to bezpieczną, powtarzalną symulację wybranego zachowania i sprawdzenie, czy reguła detekcji nadal generuje właściwy alert. Takie podejście dobrze pasuje do zespołów, które już używają CI/CD i chcą włączyć kontrolę bezpieczeństwa do procesu wytwarzania oprogramowania.
Purple team przyspiesza naukę obu stron
Purple team nie musi oznaczać trzeciego, dużego działu. To przede wszystkim sposób pracy, w którym red team i blue team wymieniają informacje wystarczająco szybko, aby każda próba ataku prowadziła do poprawy obrony.
Przykładowy cykl wygląda prosto. Red team wykonuje jedną technikę, blue team pokazuje, co zobaczył, inżynier detekcji poprawia regułę, a red team powtarza działanie. Po kilku iteracjach organizacja wie nie tylko, czy atak jest możliwy, ale też jakie ślady zostawia i jak szybko można go zatrzymać.
Takie podejście jest szczególnie przydatne przy budowie SOC, wdrażaniu nowego SIEM-a lub przechodzeniu na środowisko chmurowe. Ma jednak ograniczenie. Jeżeli zespoły omawiają każdy ruch natychmiast, test traci część realizmu. Dlatego często łączy się niezapowiedzianą fazę oceny z późniejszą fazą wspólnego doskonalenia.
Błędy, które psują wynik ćwiczenia
Najpoważniejszy błąd to brak jednoznacznego celu. Raport pełen technicznych szczegółów niewiele daje zarządowi, jeśli nie wiadomo, czy organizacja ochroniła dane, utrzymała dostępność usługi albo spełniła wymagania konkretnego procesu.
- Brak autoryzacji i nieprecyzyjny zakres, który może doprowadzić do niekontrolowanego incydentu.
- Testowanie tylko technologii bez sprawdzenia eskalacji, komunikacji i decyzji podejmowanych przez ludzi.
- Uzależnienie od jednego narzędzia, na przykład uznanie, że sam EDR lub SIEM gwarantuje skuteczną obronę.
- Ocenianie blue teamu wyłącznie po liczbie alertów, bez sprawdzenia ich trafności i czasu reakcji.
- Brak retestu, przez co nie wiadomo, czy poprawka rzeczywiście zamknęła ścieżkę ataku.
- Traktowanie ćwiczenia jak rywalizacji, co sprzyja ukrywaniu informacji zamiast poprawie bezpieczeństwa.
Unikałbym też ślepego dążenia do pełnego pokrycia macierzy ATT&CK. Organizacja nie musi testować każdej techniki. Powinna zacząć od tych, które pasują do jej branży, danych, architektury i najbardziej prawdopodobnych scenariuszy zagrożeń.
Dobry plan na początek może obejmować jeden cel biznesowy, jeden krytyczny przepływ danych i 3-5 technik ataku. Po zakończeniu należy przypisać właściciela każdej poprawki, termin realizacji i sposób ponownego sprawdzenia. To wystarczy, aby pierwsze ćwiczenie przyniosło więcej pożytku niż efektowny, ale nieukierunkowany pokaz możliwości.
Najlepszy wynik to szybsza reakcja, nie efektowny atak
Red team pokazuje, jak może zachować się przeciwnik, a blue team sprawdza, czy organizacja potrafi go zauważyć i zatrzymać. Największą wartość daje połączenie obu perspektyw z rozsądnym nadzorem, jasnym celem i powtarzaniem testów po wdrożeniu poprawek.
Własne ćwiczenie można zacząć skromnie, nawet od aplikacji, kilku logów i jednego scenariusza przejęcia konta. Liczy się to, aby wynik przełożyć na konkretne działania: lepszą widoczność, sprawniejsze alerty, krótszy czas reakcji i mniejsze ryzyko dla biznesu.
