Red Team nie jest pokazem sztuczek ani polowaniem na pracowników. To kontrolowana symulacja przeciwnika, której celem jest sprawdzenie ludzi, procesów, technologii i reakcji organizacji. Najlepszy red team daje organizacji wiedzę, której nie da się uzyskać z samego skanera podatności.
W przeciwieństwie do klasycznego pentestu, red team często zaczyna się od celu: uzyskać dostęp do określonego systemu, sprawdzić detekcję konkretnej techniki, przejść przez proces akceptacji, zweryfikować odporność na phishing lub sprawdzić, czy SOC widzi i eskaluje zdarzenia. Zakres musi być precyzyjny, bezpieczny i uzgodniony.
Red Team a pentest — różnica w celu
Pentest zwykle szuka podatności w określonym zakresie: aplikacji, API, infrastrukturze, mobile. Red Team sprawdza ścieżkę działania przeciwnika. Może używać podatności technicznych, socjotechniki, błędów procesowych i luk w monitoringu, ale nie chodzi o znalezienie jak największej liczby błędów. Chodzi o odpowiedź: czy organizacja potrafi zapobiec, wykryć i zareagować?
| Element | Pentest | Red Team |
|---|---|---|
| Cel | znaleźć i opisać podatności w zakresie | osiągnąć uzgodniony cel przeciwnika |
| Metryka | liczba i ryzyko podatności | ścieżka ataku, detekcja, reakcja, odporność procesu |
| Zakres | aplikacja, API, sieć, mobile | ludzie, procesy, technologia, monitoring |
| Wynik | raport podatności i rekomendacje | narracja ataku, timeline, punkty detekcji, wnioski |
Kontrolowana socjotechnika
Testy socjotechniczne muszą być prowadzone odpowiedzialnie. Celem nie jest zawstydzanie pracowników. Celem jest sprawdzenie procesu i przygotowanie organizacji do realnych prób wyłudzenia dostępu. Dobrze zaplanowany test ma reguły, ograniczenia, osoby kontaktowe, scenariusze awaryjne, zasady przetwarzania danych i jasną komunikację po zakończeniu.
Przykładowe scenariusze to phishing edukacyjny, próba wyłudzenia poświadczeń do kontrolowanego portalu, test reakcji helpdesku, weryfikacja procedury resetu hasła, test procesu akceptacji płatności albo sprawdzenie, czy zgłoszenie podejrzanej wiadomości trafia do właściwego zespołu.
Bezpieczne zasady gry
Każdy scenariusz powinien mieć ustalone punkty stop. Jeśli test osiąga określony poziom dostępu, działania są zatrzymywane i raportowane. Jeżeli pojawi się ryzyko zakłócenia pracy, scenariusz jest przerywany. Jeżeli pracownik zgłasza próbę ataku, to jest sukces procesu, nie porażka testera.
W praktyce ustalamy: daty, zakres osób lub działów, wyłączone grupy, kanały kontaktu awaryjnego, dozwolone techniki, zakazane techniki, sposób zbierania danych, format raportu i zasady komunikacji po ćwiczeniu.
Test detekcji i reakcji
Red Team ma dużą wartość, gdy organizacja posiada SOC, SIEM, EDR lub procedury incydentowe. Wtedy nie chodzi tylko o to, czy uda się wykonać działanie, ale czy systemy i ludzie je zobaczą. Raport powinien zawierać timeline: kiedy wykonano akcję, czy pojawił się alert, kto go obsłużył, jaki był czas reakcji i czy eskalacja była poprawna.
Przykładowy timeline:
09:14 - wysłano kontrolowaną wiadomość phishingową
09:22 - pierwszy użytkownik kliknął link
09:26 - użytkownik zgłosił wiadomość do IT
09:41 - SOC utworzył incydent
10:05 - zablokowano domenę testową
Wniosek: zgłoszenie działa, ale brakuje automatycznej blokady podobnych wiadomości
Taki wynik jest dużo bardziej wartościowy niż proste „20% kliknęło”. Pokazuje, gdzie proces działa, a gdzie wymaga usprawnienia.
Raport bez obwiniania ludzi
Najgorszy raport socjotechniczny to lista nazwisk i procent kliknięć bez kontekstu. Dobry raport opisuje wzorce: dlaczego wiadomość była wiarygodna, jakie mechanizmy ostrzegawcze zadziałały, jakie nie zadziałały, czy proces zgłaszania był prosty, czy szkolenia są praktyczne, czy organizacja potrafi szybko ograniczyć skutki.
Rekomendacje powinny dotyczyć procesu, komunikacji, zabezpieczeń poczty, MFA, polityk resetu hasła, uprawnień, detekcji i ćwiczeń. Pracownicy nie mogą być jedyną linią obrony.
Kiedy Red Team ma sens
Red Team ma największy sens, gdy organizacja ma już podstawowe bezpieczeństwo: aktualizacje, MFA, monitoring, procedury i wykonane pentesty krytycznych systemów. W przeciwnym razie ćwiczenie może tylko potwierdzić oczywiste problemy. Czasem lepszym pierwszym krokiem jest pentest infrastruktury i aplikacji, a dopiero później scenariusz red team.
Red Team ma sens wtedy, gdy organizacja chce mierzyć odporność procesu
Klasyczny pentest odpowiada na pytanie, jakie podatności ma system. Red Team odpowiada szerzej: czy przy realistycznym scenariuszu ataku organizacja wykryje działania, ograniczy skutki, zareaguje właściwie i wyciągnie wnioski. Dlatego zakres musi być kontrolowany, uzgodniony i bezpieczny operacyjnie.
Co mierzyć poza samym kliknięciem
- czy użytkownicy zgłaszają podejrzane wiadomości,
- czy SOC/IT widzi nietypowe logowania, ruch i próby eskalacji,
- czy MFA, EDR, filtr poczty i proxy działają zgodnie z założeniami,
- czy istnieje jasna ścieżka reakcji i eskalacji,
- czy po teście powstaje plan poprawy, a nie tylko ranking osób, które kliknęły.
Profesjonalny test socjotechniczny powinien minimalizować szkody, chronić prywatność pracowników i dostarczać wnioski dla procesów, szkoleń oraz kontroli technicznych.