Purple teaming: jak połączyć atak, detekcję i obronę
Purple team zamienia techniki atakujących w mierzalne testy detekcji. Zobacz, jak ustalić zakres, prowadzić ćwiczenie i zamykać luki obronne.
- AUTOR
- Karol Rapacz / Pentester (OSCP, PNPT)
- PUBLIKACJA
- 5 lipca 2026
- CZAS CZYTANIA
- 9 min czytania
- TEMAT
- Red Team i Blue Team
Purple team to sposób współpracy ofensywy i obrony, w którym techniki przeciwnika są testowane, obserwowane i poprawiane w krótkiej pętli. Nie musi oznaczać osobnego zespołu. Najważniejsze są wspólne cele red teamu, SOC, inżynierii detekcji i właścicieli systemów.
Klasyczny pentest odpowiada głównie na pytanie, czy podatność można wykorzystać. Purple team pyta dodatkowo: czy organizacja widzi aktywność, potrafi ją poprawnie zaklasyfikować i reaguje w wymaganym czasie.
Wybierz techniki z uzasadnieniem
Nie zaczynaj od losowej listy ATT&CK. Wykorzystaj ocenę ryzyka, Cyber Threat Intelligence, incydenty i architekturę. Wybierz scenariusz istotny dla firmy, np. kradzież sesji administratora, nadużycie OAuth albo ruch boczny z konta serwisowego.
Dla każdej techniki określ warunki wstępne, system docelowy, bezpieczne ograniczenia, spodziewaną telemetrię i kryterium sukcesu. Ustal osoby mogące zatrzymać test.
Najpierw pomiar bazowy
Uruchom technikę w kontrolowanych warunkach i zapisz pełną oś czasu. Sprawdź, czy zdarzenie dotarło ze źródła do SIEM, czy reguła zadziałała, jaki otrzymało priorytet i co zobaczył analityk.
Brak alertu może wynikać z braku logu, błędnego parsera, niewłaściwego pola, słabej reguły albo procesu triage. Każda przyczyna wymaga innej naprawy.
Pętla test–poprawa–retest
Po każdym teście wspólnie zbuduj lub zmodyfikuj kontrolę. Może to być nowe logowanie, reguła korelacji, kontekst zasobu, playbook albo ograniczenie prewencyjne. Następnie powtórz dokładnie ten sam scenariusz.
Zachowaj artefakty: polecenia, identyfikatory zdarzeń, zapytania, zrzuty osi czasu i wersję reguły. Dzięki temu test może wejść do regresji w detection-as-code.
Co mierzyć
Przydatne wskaźniki to:
- pokrycie priorytetowych technik wiarygodną telemetrią;
- czas od wykonania do alertu i triage;
- odsetek scenariuszy wykrytych bez podpowiedzi;
- false positives po wdrożeniu reguły;
- liczba luk zamkniętych i ponownie zweryfikowanych;
- odporność detekcji na małe warianty techniki.
Mapa ATT&CK jest indeksem, nie oceną do maksymalizacji. Sto słabych reguł może dać gorszy wynik niż dziesięć dobrze przetestowanych detekcji chroniących krytyczne ścieżki.
Bezpieczne prowadzenie ćwiczenia
Używaj kont testowych i danych syntetycznych. Ogranicz prędkość, zakres sieci, trwałość i skutki payloadu. Uzgodnij okno, monitoring oraz plan awaryjny. Test nie powinien tworzyć realnego backdoora ani omijać zasad ochrony danych.
Wyniki połącz z planem reagowania na incydenty i backlogiem właścicieli kontroli. Ćwiczenie kończy się dopiero po reteście.
Minimalny format sesji
- Ustal zagrożenie i cel biznesowy.
- Wybierz jedną do trzech technik.
- Zdefiniuj dowody, ograniczenia i stop conditions.
- Wykonaj test oraz zmierz telemetrię.
- Znajdź przyczynę luki.
- Wdroż poprawkę i powtórz test.
- Dodaj scenariusz do regresji.
Purple teaming jest skuteczny, gdy skraca czas uczenia się obrony. Raport bez poprawionej i sprawdzonej detekcji jest tylko opisem problemu.
Jak mierzyć wynik techniki
Dla każdego kroku zapisz warunek wstępny, telemetrię, oczekiwany alert i reakcję analityka. Wynik nie jest binarny: osobno oceniaj prewencję, widoczność danych, detekcję, triage i ograniczenie skutków. Brak alarmu może oznaczać złą regułę, ale też brak logu, niewłaściwe pole lub opóźnienie ingestu.
Po zmianie reguły powtórz dokładnie tę samą czynność i zachowaj dowód. Następnie wykonaj wariant techniki, aby uniknąć detekcji dopasowanej wyłącznie do jednego polecenia. Purple team nie zastępuje niezależnego red teamu; służy szybkiemu uczeniu się i walidacji znanych hipotez obronnych.
Zakres powinien zawierać warunki bezpieczeństwa i procedurę przerwania, zwłaszcza przy testach tożsamości, poczty i systemów produkcyjnych. Oznaczaj aktywność testową w sposób dostępny dla kontrolera, ale niekoniecznie analityka. Po ćwiczeniu usuń konta, payloady i wyjątki, a powstałe detekcje objąć testami regresji.
Źródła: MITRE ATT&CK, MITRE CTID — Adversary Emulation Library, NIST SP 800-61 Rev. 3.