Purple teaming: połączenie testów ofensywnych i defensywnych

Przez lata branża cyberbezpieczeństwa operowała według jasno wytyczonego podziału ról: red team atakuje, blue team broni, a wyniki obu stron trafiają do raportu, który trafia na półkę. Taki model ma swoją logikę — symulacja realnego atakującego wymaga izolacji, żeby blue team nie wiedział, co i kiedy nadejdzie. Jednak ta sama izolacja staje się systematycznym hamulcem postępu. Red team odkrywa słabości, których blue team nie widzi, a blue team wdraża reguły detekcji bez wiedzy o tym, jak realni atakujący naprawdę działają. Efekt? Organizacja wychodzi z ćwiczenia bogatszą o raport, ale biedniejszą o szansę na faktyczne podniesienie swojej zdolności do obrony.

Purple teaming jest odpowiedzią na tę dysfunkcję. Nie jest to trzecia kategoria zespołu — to model współpracy, w którym ofensywa i defensywa działają jednocześnie, dzielą się obserwacjami w czasie rzeczywistym i wspólnie weryfikują, czy konkretna technika ataku zostaje wykryta, zablokowana i poprawnie zaraportowana. Efektem nie jest raport — jest mierzalny wzrost dojrzałości detekcyjnej organizacji, technika po technice, według ustrukturyzowanej mapy MITRE ATT&CK.

Czym jest purple teaming i jak różni się od klasycznych testów red/blue team?

Purple teaming to metodologia testowania bezpieczeństwa, w której red team i blue team współpracują w czasie rzeczywistym, aby ocenić i poprawić skuteczność mechanizmów detekcji i reakcji organizacji. Nazwa pochodzi bezpośrednio z mieszania kolorów — czerwonego (red team) i niebieskiego (blue team) — i reprezentuje fuzję perspektyw ofensywnej i defensywnej.

Klasyczny red team działa w stylu black-box: symuluje realnego atakującego, ukrywa swoje działania, stosuje techniki evasion i mierzy sukces liczbą przejętych systemów oraz danymi, do których uzyskał dostęp. Raport końcowy trafia do blue teamu tygodnie lub miesiące po ćwiczeniu. Blue team dowiaduje się wówczas, że był kompromitowany, ale często nie wie, dlaczego jego reguły SIEM milczały ani jak konkretna technika wyglądała w logach. Luka wiedzy pozostaje — i cały cykl powtarza się przy kolejnym teście.

Purple team odwraca tę dynamikę. Zamiast pełnej izolacji, ćwiczenie odbywa się jako seria skoordynowanych sesji. Red team wykonuje konkretną technikę ataku i natychmiast powiadamia blue team: “Właśnie wykonałem technikę T1059.001 — PowerShell Execution — na hoście WORKSTATION-04. Sprawdź, czy widzisz ten event w SIEM”. Blue team przegląda logi, analizuje, czy detekcja zadziałała, identyfikuje brakujące dane telemetryczne i na bieżąco dostosowuje reguły. Następnie red team wykonuje kolejną technikę.

Fiszka: Red team vs. Blue team vs. Purple team

Red team — symuluje atakującego w warunkach izolacji. Mierzy zdolność przełamania obrony.
Blue team — monituje środowisko, reaguje na alerty, zarządza incydentami. Mierzy czas wykrycia i reakcji.
Purple team — łączy oba podejścia w iteracyjną pętlę feedbacku. Mierzy coverage ATT&CK i poprawę detekcji w czasie.

Kluczowa różnica leży w celu. Red team odpowiada na pytanie: “Czy atakujący może się dostać?”. Purple team odpowiada na pytanie: “Kiedy atakujący się dostaje — czy my to widzimy?”. To subtelna, ale fundamentalna zmiana perspektywy. Organizacje, które regularnie prowadzą ćwiczenia purple team, przestają pytać o sam fakt włamania i zaczynają zadawać pytania dojrzałości: jaki procent technik ATT&CK mamy pokryty detekcją? Gdzie są nasze największe ślepe punkty? Które technologie nie dostarczają nam telemetrii, której potrzebujemy?

Purple teaming nie zastępuje tradycyjnych red team engagements. Pełne, zaślepione ćwiczenie symulujące realny APT nadal ma wartość — testuje procesy, czas reakcji i koordynację w warunkach zbliżonych do rzeczywistego incydentu. Purple teaming uzupełnia te ćwiczenia, wypełniając lukę między testami penetracyjnymi a operacyjnym doskonaleniem SOC.

Jak purple team wykorzystuje MITRE ATT&CK do strukturyzowania testów?

MITRE ATT&CK (Adversarial Tactics, Techniques, and Common Knowledge) jest otwartą bazą wiedzy, dokumentującą taktyki, techniki i procedury (TTP) realne obserwowane w kampaniach atakujących. Dla purple teamingu jest to podstawowa rama — wspólny język, który pozwala zarówno red teamowi, jak i blue teamowi mówić o tej samej rzeczywistości.

Framework jest zorganizowany hierarchicznie. Na najwyższym poziomie znajdują się taktyki — cele, które atakujący chce osiągnąć: Initial Access, Execution, Persistence, Privilege Escalation, Defense Evasion, Credential Access, Discovery, Lateral Movement, Collection, Command and Control, Exfiltration, Impact. Każda taktyka zawiera techniki — konkretne sposoby realizacji celu, identyfikowane identyfikatorem w formacie T[numer] (np. T1566 — Phishing). Wiele technik posiada pod-techniki uszczegóławiające wariant (np. T1566.001 — Spearphishing Attachment, T1566.002 — Spearphishing Link).

W praktyce purple teamingu ATT&CK spełnia trzy funkcje. Po pierwsze, służy jako lista do odhaczenia — organizacja systematycznie przechodzi przez techniki istotne dla swojego środowiska i profilu zagrożeń, testując każdą z nich. Po drugie, pełni rolę wspólnego języka komunikacji — gdy red team wykonuje technikę T1003.001 (OS Credential Dumping: LSASS Memory), blue team dokładnie wie, czego szukać w logach Windows Security Event ID 10 (process access do lsass.exe). Po trzecie, ATT&CK pozwala na gap analysis — wizualizację, które techniki są pokryte detekcją, a które pozostają niewidoczne dla SOC.

Fiszka: Struktura MITRE ATT&CK Enterprise

14 taktyk — etapy kill chain atakującego (od Initial Access do Impact)
200+ technik i 400+ pod-technik — konkretne metody działania
Grupy APT — mapowanie TTP do znanych aktorów zagrożeń (np. APT28, Lazarus, Cozy Bear)
Oprogramowanie — malware i narzędzia powiązane z technikami
Mitigations i Detections — zalecane środki zaradcze i wskazówki detekcyjne

Praktyczny workflow wygląda następująco: przed ćwiczeniem purple team określa zakres taktyczny — zazwyczaj pełen kill chain lub wybrany podzbiór taktyk istotny dla danego środowiska (np. Lateral Movement + Credential Access dla organizacji z rozbudowanym Active Directory). Następnie dla każdej techniki z zakresu red team przygotowuje procedurę wykonania, a blue team przegląda istniejące reguły detekcji. Podczas sesji red team wykonuje technikę, blue team weryfikuje detekcję, a wynik — detected / not detected / partially detected — jest rejestrowany w systemie śledzenia (np. Vectr). Na koniec organizacja posiada zmierzony coverage ATT&CK i priorytetyzowaną listę luk detekcyjnych do naprawienia.

Kluczowy wybór w strukturyzacji tesów to priorytetyzacja technik. Nie wszystkie 600+ technik z macierzy Enterprise są równie istotne dla każdej organizacji. Dobry program purple teaming zaczyna od analizy zagrożeń specyficznych dla sektora i środowiska (threat-informed defense), a następnie mapuje techniki używane przez grupy APT atakujące podobne organizacje. Dane z raportów Mandiant, CrowdStrike i CISA Advisory są tutaj nieocenionym źródłem.

Jak zaplanować i przeprowadzić ćwiczenie purple team?

Planowanie ćwiczenia purple team wymaga precyzji organizacyjnej porównywalnej z planowaniem pełnego red team engagement, ale z dodatkowymi warstwami koordynacji z blue teamem. Dobra sesja purple team nie jest improwizacją — jest starannie przygotowanym scenariuszem z jasno zdefiniowanymi celami, zakresem i metrykami sukcesu.

Faza 1: Threat Profiling i wybór zakresu. Przed ćwiczeniem organizacja musi odpowiedzieć na pytanie: “Które techniki są dla nas najbardziej istotne?”. Odpowiedź pochodzi z analizy zagrożeń — jakie grupy APT atakują nasz sektor? Jakie techniki dominowały w incydentach branżowych w ostatnich 12 miesiącach? Jakie podatności w naszym środowisku są najbardziej eksploatowalne? Na tej podstawie powstaje lista priorytetowych technik ATT&CK — zazwyczaj 20-50 technik na kwartalne ćwiczenie, pogrupowanych w logiczne kill chain.

Faza 2: Przygotowanie środowiska testowego i procedur. Red team przygotowuje szczegółowe procedury wykonania każdej techniki — konkretne komendy, narzędzia, parametry. Blue team przegląda istniejące reguły detekcji w SIEM, EDR i innych narzędziach. Kluczowe jest upewnienie się, że środowisko testowe ma pełną telemetrię — brakujące logi to gwarantowany fałszywy wynik “not detected”.

Faza 3: Sesja ćwiczeniowa. Ćwiczenie odbywa się jako seria iteracji. Dla każdej techniki: red team informuje o zamiarze wykonania → wykonuje technikę → blue team analizuje przez zdefiniowany czas (np. 15 minut) → wynik jest rejestrowany → prowadzona jest dyskusja o tym, co zadziałało, co nie i dlaczego → dokumentowane są action items dla blue teamu. Tempo sesji powinno być realistyczne — próba przejścia przez 40 technik w jeden dzień prowadzi do powierzchownej analizy.

Faza 4: Remediacja i retest. Fundamentalna różnica między purple teamingiem a tradycyjnym raportem polega na tym, że ćwiczenie nie kończy się na liście luk. Blue team implementuje brakujące reguły detekcji, uzupełnia telemetrię, dostosowuje konfiguracje EDR, a następnie — w kolejnej sesji lub w ramach tej samej — red team retestuje te same techniki. Wzrost wykrywalności jest mierzalny i powtarzalny.

Faza 5: Raportowanie i planowanie kolejnego cyklu. Raport z ćwiczenia zawiera statystyki coverage ATT&CK (before/after), zmapowane luki, zaimplementowane poprawki i rekomendacje dla następnej sesji. Ten cykl — testuj, poprawiaj, retestuj — jest rdzeniem programu ciągłego doskonalenia.

Kluczowe role w ćwiczeniu: Purple Team Lead (koordynuje całe ćwiczenie, często zewnętrzny konsultant lub doświadczony wewnętrzny specjalista), Red Team Operator (wykonuje techniki), Blue Team Analyst (analizuje telemetrię), SIEM Engineer (dostępny do modyfikacji reguł w czasie sesji), Scribe (dokumentuje wyniki w czasie rzeczywistym).

Jak testować poszczególne techniki ATT&CK — od initial access do exfiltration?

Testowanie technik ATT&CK wymaga praktycznej wiedzy o tym, jak wyglądają w rzeczywistości — na poziomie konkretnych komend, zachowań procesowych i eventów w logach. Poniżej przykłady reprezentatywne dla każdego etapu kill chain, które stanowią typowy zakres ćwiczenia purple team.

Initial Access (T1566 — Phishing): Red team wysyła symulowaną wiadomość spearphishingową z załącznikiem lub linkiem do kontrolowanego środowiska. Blue team weryfikuje, czy email gateway zaalarmował o podejrzanym załączniku, czy proxy/DNS zablokował połączenie do C2, czy EDR wykrył otwarcie dokumentu z makrem. Technika T1566.001 (Spearphishing Attachment) w logach to charakterystyczny ciąg: winword.exe spawning cmd.exe lub powershell.exe, Event ID 4688 z podejrzanym command line.

Execution (T1059.001 — PowerShell): Red team wykonuje złośliwy kod PowerShell — encoded command, downloadstring z internetu, AMSI bypass. Blue team weryfikuje, czy Script Block Logging (Event ID 4104) jest włączony i zbierany przez SIEM, czy reguły detekcji reagują na encoded commands (-enc, -EncodedCommand), czy EDR blokuje AMSI bypass techniques. Wiele organizacji odkrywa tutaj, że Script Block Logging jest wyłączony lub logi nie docierają do SIEM.

Persistence (T1547.001 — Registry Run Keys): Red team dodaje klucz do HKCU\Software\Microsoft\Windows\CurrentVersion\Run. Blue team weryfikuje, czy Sysmon Event ID 13 (RegistryEvent — Value Set) jest zbierany i powiązany z regułą. Typowa luka: organizacje zbierają eventy Registry, ale nie mają reguł korelacji, które wyróżniają złośliwe wpisy na tle legalnych.

Credential Access (T1003.001 — LSASS Memory Dump): Red team używa Mimikatz, ProcDump lub własnego narzędzia do zrzutu pamięci procesu lsass.exe. Blue team weryfikuje Event ID 10 w Sysmonie (ProcessAccess targeting lsass.exe), alerty EDR, reguły wykrywające znane narzędzia (Mimikatz strings, ProcDump argumenty). To jeden z kluczowych testów — kompromis LSASS to często punkt zwrotny w ataku.

Lateral Movement (T1021.002 — SMB/Windows Admin Shares): Red team używa PsExec, SMBExec lub wbudowanych komend do bocznego ruchu przez SMB. Blue team weryfikuje Event ID 4624 (logon type 3), 4648 (explicit credential use), 7045 (nowa usługa). Sysmon Event ID 3 (NetworkConnect) z docelowym portem 445 i Event ID 11 (FileCreate) w ścieżkach ADMIN$, C$ to charakterystyczne ślady.

Exfiltration (T1048.003 — Exfiltration over HTTP): Red team przesyła syntetyczne dane do kontrolowanego serwera przez HTTPS. Blue team weryfikuje, czy proxy/DLP wykrył duże transfery outbound do nieznanego hosta, czy UEBA/NDR zaznaczył anomalny wzorzec komunikacji, czy reguły oparte na wielkości transferu w czasie działają prawidłowo. Exfiltration to technicznie prosty etap, który organizacje często wykrywają najgorzej, bo ruch “wychodzący” jest historycznie mniej monitorowany niż “wchodzący”.

Fiszka: Priorytety testowania wg fazy kill chain

Initial Access — weryfikuje skuteczność email security gateway i proxy
Execution — weryfikuje script logging, AMSI, Application Control
Credential Access — weryfikuje ochronę LSASS, PAM/Privileged Access
Lateral Movement — weryfikuje segmentację sieci i monitoring ruchu wewnętrznego
Exfiltration — weryfikuje DLP, proxy i UEBA

Jak mierzyć detekcyjność organizacji — coverage gap analysis?

Coverage gap analysis to systematyczna ocena tego, jaką część technik ATT&CK istotnych dla organizacji pokrywają jej obecne mechanizmy detekcji. Jest to fundament programu purple teaming — bez pomiaru nie ma poprawy, a bez struktury pomiaru wyniki są nieporównywalne między ćwiczeniami.

Model oceny detekcji dla każdej techniki powinien być czterostopniowy. Detected and Alerted — technika wygenerowała alert w SIEM lub EDR, który trafił do analityka. To najwyższy poziom skuteczności. Detected, No Alert — telemetria zawiera ślady techniki, ale żadna reguła nie wygenerowała alertu; analityk musiałby samodzielnie wyszukać te dane podczas threat huntingu. Data Available, Not Correlated — logi istnieją, ale nie zawierają wystarczająco kontekstowego zakresu techniki do pewnego wykrycia. Not Detected — brak jakichkolwiek danych telemetrycznych wskazujących na wykonanie techniki; technika jest całkowicie niewidoczna.

Wyniki coverage gap analysis powinny być prezentowane w trzech wymiarach. Po pierwsze, jako procent pokrycia taktyk ATT&CK — ile technik w każdej z 14 taktyk jest pokrytych na poziomie Detected and Alerted. Organizacja dojrzała security powinna dążyć do 70%+ coverage dla priorytetowych technik. Po drugie, jako heatmapa ATT&CK Navigator — wizualizacja macierzy z kolorami reprezentującymi poziom detekcji dla każdej komórki. Ta wizualizacja jest niezwykle efektywna w komunikacji z CISO i zarządem — pokazuje ślepe punkty wprost na mapie atakującego. Po trzecie, jako trend coverage w czasie — porównanie wyników między kolejnymi ćwiczeniami pokazuje, czy program faktycznie podnosi dojrzałość, czy stoi w miejscu.

Fiszka: Cztery poziomy detekcji w coverage gap analysis

Poziom 4 — Detected and Alerted — automatyczny alert trafia do analityka SOC
Poziom 3 — Detected, No Alert — dane w logach, brak reguły korelacji
Poziom 2 — Partial Data — telemetria niepełna lub zbyt szumna do pewnej detekcji
Poziom 1 — Not Detected — technika całkowicie poza widocznością

Kluczowa pułapka coverage gap analysis to fałszywe poczucie bezpieczeństwa z powodu niekompletnej telemetrii. Jeśli organizacja nie zbiera logów z konkretnego źródła (np. brak Sysmon na stacjach roboczych, brak Windows Advanced Audit Policy na serwerach), wynik “not detected” może wynikać z braku telemetrii, a nie z braku reguły detekcji. Dlatego gap analysis musi zawierać warstwę oceny kompletności telemetrii — mapowanie źródeł logów do wymagań detekcyjnych poszczególnych technik.

Praktyczne narzędzia do prowadzenia gap analysis: ATT&CK Navigator (bezpłatne narzędzie MITRE do wizualizacji i adnotacji macierzy), Vectr (platforma do śledzenia wyników ćwiczeń), DeTT&CT (framework do mapowania jakości telemetrii i detekcji do ATT&CK). Organizacje z dojrzałym SOC często integrują wyniki gap analysis bezpośrednio ze swoimi platformami SOAR lub SIEM, aby automatycznie priorytetyzować prace nad nowymi regułami detekcji.

Jak purple teaming doskonali reguły SIEM i procesy SOC?

SIEM (Security Information and Event Management) jest centrum nerwowym każdego SOC, ale bez regularnego kalibrowania jego reguły szybko się starzeją. Reguły pisane przed dwoma laty mogą nie wykrywać technik, które atakujący odkryli rok temu. Purple teaming jest najbardziej efektywnym mechanizmem utrzymania aktualności reguł SIEM — bo testuje je w kontrolowanych warunkach, dokładnie tak jak działają realni atakujący.

Typowy cykl doskonalenia reguły SIEM przez purple teaming wygląda następująco. Red team wykonuje technikę T1547.001 (Run Key Persistence). SIEM milczy — brak alertu. Blue team sprawdza, czy Event ID 13 z Sysmona dociera do SIEM: dociera. Sprawdza istniejące reguły: reguła istnieje, ale filtruje legalny software przez listę allow, która nie była aktualizowana od 18 miesięcy. Inżynier SIEM aktualizuje regułę, usuwa przestarzałe wyjątki, retestuje. Przy kolejnym uruchomieniu tej samej techniki — alert generowany w ciągu 2 minut od wykonania.

Ten cykl ujawnia kilka kategorii problemów, które inaczej pozostają niewidoczne. False positive suppression — reguły, które były celowo wyciszone lub obarczone zbyt szerokim filtrem whitelist, bo generowały za dużo szumu. Purple teaming pozwala zidentyfikować, które z tych wyciszeń były uzasadnione, a które ukrywają realną aktywność. Missing data sources — często nie chodzi o brakującą regułę, ale o brakujący log. Sysmon nie zainstalowany na 30% stacji roboczych, Windows Advanced Audit Policy niepoprawnie skonfigurowana na kontrolerach domeny, brak logowania z urządzeń sieciowych. Stale correlation logic — reguły oparte na konkretnych nazwach plików lub hashach malware, które atakujący dawno zmienili. Purple teaming wymusza przejście na behawioralne reguły detekcji — oparte na wzorcach działania, nie sygnaturach.

Doskonalenie procesów SOC idzie równolegle z doskonaleniem reguł technicznych. Gdy purple team testuje technikę, która generuje alert — ale blue team analizuje go 45 minut, bo playbook jest nieaktualny lub analityk nie wiedział, jak zinterpretować dany event — to jest sygnał, że nie tylko reguła wymaga uwagi, ale i playbook reagowania na incydent. Purple teaming regularnie ujawnia luki w dokumentacji proceduralnej SOC: brakujące playbooki dla konkretnych technik ATT&CK, niespójne priorytety alertów, brak eskalacji dla high-severity eventów w godzinach nocnych.

Fiszka: Typy problemów SIEM wykrywanych przez purple teaming

Brak telemetrii — logi nie docierają do SIEM lub zbierane są selektywnie
Martwe reguły — reguły oparte na sygnaturach, które atakujący dawno ominęli
Zbyt szerokie whitelisy — legalne wyjątki ukrywające złośliwą aktywność
Brak korelacji — dane są, ale nie ma reguł łączących je w sensowny alert
Stare priorytety — krytyczne techniki oznaczone jako “low” z powodu historycznych decyzji

Jedną z najbardziej wartościowych praktyk jest tworzenie Detection-as-Code — przechowywanie reguł SIEM w repozytorium Git, wraz z metadanymi ATT&CK (taktyka, technika, pod-technika), datą ostatniego testu i wynikiem. Dzięki temu organizacja ma pełną historię ewolucji reguł, może wracać do poprzednich wersji i automatycznie retestować reguły przy każdej zmianie środowiska. To zamyka pętlę między purple teamingiem a codziennymi operacjami SOC.

Jak integrować purple teaming z programem threat hunting?

Threat hunting i purple teaming to dwie komplementarne praktyki, które wzajemnie się wzmacniają. Threat hunting pyta: “Czy atakujący już tu jest?”. Purple teaming pyta: “Czy zobaczylibyśmy go, gdyby był?”. Organizacja, która prowadzi obydwa programy jednocześnie, osiąga poziom dojrzałości bezpieczeństwa, który jest niedostępny dla żadnego z tych programów osobno.

Integracja działa w obu kierunkach. Purple teaming zasila threat hunting na kilka sposobów. Po pierwsze, ćwiczenia purple team produkują szczegółowe informacje o tym, jak konkretne techniki wyglądają w telemetrii danego środowiska — jakie eventy generują, jakie nazwy procesów, jakie parametry command line. Są to gotowe hipotezy i wskazówki dla hunterów. Jeśli purple team odkrył, że technika T1218.011 (Signed Proxy Execution: Rundll32) nie jest wykrywana przez SIEM, hunter może proaktywnie przeszukać historyczne logi w poszukiwaniu oznak, że ta technika była już wcześniej używana przez realnego atakującego.

Po drugie, luki coverage zidentyfikowane przez purple teaming wyznaczają priorytety kampanii huntingowych. Hunter nie powinien szukać wszędzie — powinien koncentrować się tam, gdzie detekcja jest słaba i gdzie organizacja ma największe ślepe punkty. Coverage gap analysis z purple teamingu jest idealną mapą do planowania kampanii huntingowych.

Threat hunting zasila purple teaming z kolei przez dostarczanie hipotez opartych na obserwacjach realnego środowiska. Jeśli hunter podczas kampanii huntingowej zauważył niewyjaśnioną aktywność PowerShell na kilku stacjach roboczych w godzinach nocnych — ta obserwacja staje się priorytetem dla następnego ćwiczenia purple team: przetestuj techniki PowerShell i zweryfikuj, czy SIEM jest skonfigurowany do ich wykrycia.

Fiszka: Pętla integracji Purple Team + Threat Hunting

Purple team testuje technikę → identyfikuje lukę detekcji
Luka staje się hipotezą huntingową → hunter przeszukuje historyczne logi
Hunter odkrywa potencjalną realną aktywność → eskalacja do incident response lub nowe ćwiczenie purple team
Wyniki huntingu zasilają zakres kolejnego ćwiczenia purple team

Wspólnym mianownikiem obu programów jest framework MITRE ATT&CK. Hunter buduje hipotezy na podstawie technik ATT&CK. Purple team strukturyzuje ćwiczenia wokół technik ATT&CK. Dzięki wspólnej nomenklaturze, wyniki obu programów można porównywać, łączyć i raportować w spójny sposób. Organizacja posiada jeden, zunifikowany widok swojego coverage ATT&CK — zarówno z perspektywy testów kontrolowanych (purple team), jak i analizy historycznych danych (threat hunting).

Dojrzałe organizacje formalizują tę integrację przez wspólne spotkania planistyczne między zespołem purple team a threat hunterami, wspólne platformy zarządzania wynikami i zunifikowany raport coverage ATT&CK aktualizowany po każdym ćwiczeniu i każdej kampanii huntingowej.

Jakie narzędzia automatyzują purple teaming — Atomic Red Team, Caldera, Vectr?

Ekosystem narzędzi do purple teamingu rozwinął się w ostatnich latach w odpowiedzi na rosnące zainteresowanie tą metodologią. Najważniejsze narzędzia można podzielić na trzy kategorie: biblioteki atomów testowych, platformy automatyzacji ataków i systemy śledzenia wyników.

Atomic Red Team (Red Canary, open source) to biblioteka ponad 1100 “atomowych” testów — minimalnych, izolowanych procedur wykonania pojedynczych technik ATT&CK. Każdy atom to konkretny skrypt (PowerShell, Bash, Python) wykonujący jedną technikę w możliwie prosty sposób. Atomic Red Team nie próbuje symulować pełnego atakującego — zamiast tego dostarcza standaryzowane, powtarzalne wykonanie każdej techniki. Dla purple teamingu jest to idealne narzędzie do weryfikacji detekcji: czy EDR wykrywa T1003.001 wykonany przez ten konkretny atom? Jeśli nie — jest to luka detekcji. Atomy uruchamiają się z linii komend (Invoke-AtomicTest T1003.001) lub przez dedykowany framework.

MITRE CALDERA (open source) to zaawansowana platforma do automatyzacji operacji adversarial. W przeciwieństwie do Atomic Red Team, CALDERA symuluje pełne kampanie — sekwencje technik tworzące spójny kill chain. Agent (Sandcat) instalowany na celu autonomicznie wykonuje przypisane techniki i raportuje wyniki do serwera CALDERA. Dla purple teamingu, CALDERA jest szczególnie przydatna do testowania technik Lateral Movement, Command and Control i Persistence w zautomatyzowany sposób. Plugin “Stockpile” zawiera bibliotekę gotowych zdolności operacyjnych, a plugin “ATT&CK Evaluations” mapuje wyniki do macierzy ATT&CK.

Vectr (Security Risk Advisors, freemium) to platforma do zarządzania ćwiczeniami purple team i śledzenia wyników. Vectr pozwala planować kampanie testowe, rejestrować wyniki każdej techniki (detected / not detected / alerted), śledzić remediację i generować raporty coverage ATT&CK. Jest to de facto standard do zarządzania programem purple teaming — wiele organizacji i zewnętrznych konsultantów używa Vectr jako głównego systemu dokumentacji. Integracje z Atomic Red Team i CALDERA pozwalają automatycznie importować wyniki testów.

Fiszka: Porównanie kluczowych narzędzi purple teamingu

Atomic Red Team — biblioteka atomów testowych; idealny do weryfikacji detekcji pojedynczych technik; open source
CALDERA — platforma automatyzacji kampanii adversarial; symuluje pełny kill chain; open source (MITRE)
Vectr — platforma zarządzania wynikami purple team; coverage tracking, raportowanie; freemium
ATT&CK Navigator — wizualizacja macierzy ATT&CK; heat mapy coverage; open source (MITRE)
Prelude Operator — komercyjna platforma purple team z gotowymi scenariuszami APT; płatna
DeTT&CT — framework do mapowania jakości telemetrii i detekcji na macierz ATT&CK; open source

Oprócz tych narzędzi, w ćwiczeniach purple team używa się standardowego zestawu red team tools: Cobalt Strike lub Havoc C2 do symulacji zaawansowanego C2, Mimikatz do testowania Credential Access, BloodHound do analizy i testowania ścieżek w Active Directory, Metasploit do Initial Access i Exploitation. Kluczowe jest, że w purple teamingu te narzędzia są używane w sposób kontrolowany i transparentny — red team ujawnia blue teamowi, co i jak wykonał, żeby blue team mógł nauczyć się rozpoznawać ślady tych narzędzi w logach.

Automatyzacja przez Atomic Red Team i CALDERA ma swoje granice. Autonomiczne atomy nie zastąpią doświadczonego red team operatora, który potrafi adaptować techniki do specyfiki środowiska, stosować custom evasion i symulować realne zaawansowanie APT. Najlepsza praktyka to połączenie: automatyczne testy dla szerokiego coverage dziesiątek technik, ręczne ćwiczenia dla kluczowych scenariuszy wymagających kreatywności i adaptacji.

Jak wygląda cykl purple teamingu w organizacji?

Skuteczny program purple teaming nie jest jednorazowym projektem — jest ciągłym cyklem, który wbudowuje się w rytm operacyjny organizacji. Poniższa tabela opisuje dojrzały model cyklu purple teamingu, od organizacji stawiających pierwsze kroki po te z programem w pełni operacyjnym.

Faza dojrzałości	Opis	Częstotliwość	Zakres	Metryki sukcesu
Faza 1: Inicjacja	Pierwsza sesja purple team; ustalenie baseline coverage ATT&CK; identyfikacja krytycznych luk telemetrii	Jednorazowo / kickoff	10-20 technik wysokiego priorytetu	Baseline coverage score; lista krytycznych luk
Faza 2: Budowanie fundamentów	Regularne kwartalne sesje; uzupełnianie telemetrii; pisanie pierwszych dedykowanych reguł detekcji	Kwartalnie	20-40 technik; retesty z poprzednich sesji	Coverage score per taktyka; % luk zaadresowanych
Faza 3: Optymalizacja	Miesięczne sesje focused na konkretne taktyki; integracja z threat huntingiem; Detection-as-Code	Miesięcznie	30-50 technik; scenariusze APT	MTTD dla testowanych technik; false positive rate
Faza 4: Ciągłe doskonalenie	Bi-tygodniowe atomic tests; ciągłe monitorowanie coverage; purple team wbudowany w pipeline CI/CD bezpieczeństwa	Bi-tygodniowo / ciągle	Pełne ATT&CK Enterprise dla priorytetu; custom APT scenarios	Coverage 70%+ dla priorytetowych technik; trend detekcji r/r
Faza 5: Program dojrzały	Purple team operacyjnie zintegrowany z SOC; threat hunting zasilany wynikami; zewnętrzne walidacje i porównania z benchmarkami sektorowymi	Ciągle + półroczny audit	Pełne ATT&CK Enterprise; custom TTPs; supply chain scenarios	Full-spectrum coverage; MTTD <15 min dla critical; 0 critical blind spots

Kwartalny rytm jest punktem startowym dla większości organizacji. W ciągu roku cztery sesje pozwalają przejść przez pełny zakres priorytetowych technik i zmierzyć postęp między sesjami. Dla organizacji z dojrzałym SOC i dedykowanym zespołem red team, przejście do miesięcznych sesji focused na konkretne taktyki przyspiesza iterację i pozwala na bardziej granularną optymalizację.

Kluczowe czynniki sukcesu programu: wsparcie CISO i przełożonych dla alokacji czasu blue teamu na ćwiczenia (to jest największa bariera organizacyjna — analitycy SOC są zawsze pod presją alertów produkcyjnych), dedykowane środowisko testowe lub szczegółowy protokół wykonywania testów w środowisku produkcyjnym bez ryzykownych skutków ubocznych, system śledzenia wyników i remediacji (Vectr lub odpowiednik), oraz kultura organizacyjna, w której “not detected” jest wynikiem do naprawienia, a nie powodem do ukrywania problemów.

Jak nFlo prowadzi ćwiczenia purple team dla klientów?

nFlo prowadzi ćwiczenia purple team jako część kompleksowej oferty Advanced Security Testing, łącząc doświadczenie 500+ projektów bezpieczeństwa z ustrukturyzowaną metodologią opartą na MITRE ATT&CK. Nasze podejście jest oparte na filozofii “threat-informed defense” — zanim cokolwiek przetestujemy, rozumiemy profil zagrożeń konkretnej organizacji, jej sektor i historię incydentów branżowych.

Typowe zaangażowanie nFlo w ćwiczeniu purple team składa się z trzech etapów. W fazie przygotowawczej przeprowadzamy threat profiling: analizujemy, które grupy APT i techniki są istotne dla klienta na podstawie sektora (finanse, przemysł, administracja publiczna, healthcare), analizujemy istniejący stack technologiczny (jaką telemetrię ma SOC klienta?) i ustalamy priorytetowy zakres ATT&CK dla ćwiczenia. Wynikiem jest spersonalizowany “adversary profile” i lista 25-50 technik do przetestowania.

W fazie ćwiczenia nasi red team operatorzy wykonują każdą technikę w dedykowanym środowisku klienta lub w ścisłej koordynacji z jego zespołem IT, w oknie serwisowym minimalizującym ryzyko zakłócenia operacji. Używamy kombinacji Atomic Red Team dla standaryzowanych atomów, customowych narzędzi dla technik wymagających adaptacji do środowiska klienta i pełnego zestawu red team tooling (C2, post-exploitation frameworks). Każda technika jest natychmiast weryfikowana z blue teamem — wyniki rejestrujemy w czasie rzeczywistym w Vectr.

Po ćwiczeniu dostarczamy raport coverage ATT&CK z heatmapą Navigator, priorytetyzowaną listą luk detekcyjnych z rekomendacjami implementacji reguł SIEM/EDR, mapowaniem brakującej telemetrii do źródeł logów, które należy uzupełnić, oraz planem retestów. Jeśli klient zdecyduje się na wsparcie remediacyjne, wspieramy blue team w implementacji poprawek i prowadzimy sesję retestową potwierdzającą skuteczność zmian.

Z doświadczenia 200+ klientów nFlo wynika, że organizacje przystępujące do pierwszego ćwiczenia purple team odkrywają średnio, że 40-60% przetestowanych technik nie generuje żadnego alertu w SIEM. Najczęstsze przyczyny to niekompletna telemetria (brak Sysmona, nieprawidłowa konfiguracja Windows Advanced Audit Policy), reguły SIEM oparte na sygnaturach zamiast behawiorze, oraz whitelisy zbyt szerokie, wytworzone w czasie historycznych prób redukcji false positive. Po pierwszym cyklu ćwiczeń i remediacji ten wskaźnik spada do 15-25%, a organizacje raportują 90% redukcję ryzyka dla kluczowych scenariuszy atakujących.

Oferujemy też program ciągły — miesięczne sesje purple team jako subskrypcja, integrację z usługą Managed SOC nFlo (czas reakcji <15 minut na krytyczne incydenty) i dostęp do naszego threat intelligence o grupach APT aktywnych w Polsce i Europie Środkowej. 98% klientów, którzy wdrożyli program purple teaming z nFlo, kontynuuje współpracę w kolejnym roku — bo widzą mierzalną, powtarzalną poprawę swojego bezpieczeństwa.

Powiązane zagadnienia

Jeśli interesuje Cię purple teaming, warto zapoznać się z powiązanymi tematami z naszej bazy wiedzy:

Threat Hunting — proaktywne polowanie na zagrożenia w sieci (hipotezy, MITRE ATT&CK, narzędzia huntingowe)
Red Team Engagements — pełne symulacje APT w warunkach izolacji
SIEM i korelacja logów — podstawy budowania efektywnego centrum monitorowania
MITRE ATT&CK Framework — przewodnik po taktykach, technikach i procedurach adversarial
SOC i Security Operations — organizacja i dojrzałość centrum operacji bezpieczeństwa
Testy penetracyjne infrastruktury — różnice między pentestem a purple teamingiem

Dowiedz się więcej

MITRE ATT&CK Enterprise Matrix — oficjalna baza wiedzy MITRE
Atomic Red Team — biblioteka atomów testowych (GitHub)
MITRE CALDERA — platforma automatyzacji adversarial (GitHub)
Vectr — platforma zarządzania ćwiczeniami purple team
ATT&CK Navigator — narzędzie do wizualizacji coverage
DeTT&CT — framework mapowania jakości telemetrii

Sprawdź nasze usługi

Chcesz wdrożyć program purple teaming w swojej organizacji? nFlo oferuje:

Purple Team Engagements — jednorazowe lub cykliczne ćwiczenia z reportingiem coverage ATT&CK
Red Team / Adversary Simulation — zaawansowane symulacje APT
SOC Advisory — doradztwo w zakresie dojrzałości operacji bezpieczeństwa
Managed SOC — ciągłe monitorowanie z czasem reakcji poniżej 15 minut

Skontaktuj się z nFlo i umów bezpłatną konsultację dotyczącą potrzeb testów bezpieczeństwa Twojej organizacji.

FAQ

Czym różni się purple teaming od tradycyjnego red teamingu?

Red teaming to symulacja atakującego w warunkach pełnej izolacji — blue team nie wie, kiedy i co nastąpi. Celem jest ocena zdolności przełamania obrony. Purple teaming to model współpracy, w którym red team i blue team działają razem, dzieląc się obserwacjami w czasie rzeczywistym. Celem jest poprawa detekcji i doskonalenie reguł SIEM. Red teaming symuluje realna kampanię APT; purple teaming jest systematyczną weryfikacją i poprawą mechanizmów wykrywania. Obie metody się uzupełniają — nie wykluczają.

Jak często organizacja powinna przeprowadzać ćwiczenia purple team?

Minimalna częstotliwość dla organizacji z dojrzałym SOC to raz na kwartał. Pozwala to na pokrycie wszystkich priorytetowych technik ATT&CK w ciągu roku i zmierzenie postępu między sesjami. Organizacje z dedykowanym zespołem bezpieczeństwa powinny dążyć do miesięcznych sesji focused na konkretne taktyki. Najbardziej dojrzałe programy łączą automatyczne testy atomiczne (Atomic Red Team) uruchamiane regularnie z manualnymi sesjami dla scenariuszy wymagających eksperckiej wiedzy red teamu.

Jakie narzędzia są potrzebne, żeby zacząć program purple teaming?

Do rozpoczęcia wystarczą trzy elementy: biblioteka Atomic Red Team (open source) do wykonywania standardowych testów technik ATT&CK, ATT&CK Navigator (open source) do wizualizacji wyników coverage i Vectr (freemium) do śledzenia wyników i remediacji. Środowisko SIEM i EDR po stronie blue teamu to warunek konieczny — bez telemetrii nie ma czego weryfikować. Pełne platformy jak CALDERA i komercyjne narzędzia red team (Cobalt Strike) wchodzą w grę na wyższym poziomie dojrzałości programu.

Czy purple teaming wymaga zewnętrznego red teamu?

Nie, choć zewnętrzny red team wnosi wartość w postaci świeżego spojrzenia i doświadczenia z wielu środowisk. Wewnętrzny red team lub nawet pojedynczy operator security może prowadzić ćwiczenia purple team używając Atomic Red Team — wymagana wiedza to znajomość technik ATT&CK i umiejętność interpretacji logów, nie zaawansowane zdolności ofensywne. Zewnętrzny red team jest szczególnie wartościowy dla scenariuszy zaawansowanego APT, custom evasion i pierwszych ćwiczeń, gdy organizacja buduje swoją metodologię. Dla regularnych, operacyjnych sesji — wewnętrzny team jest w pełni wystarczający.

Jak mierzyć sukces programu purple teaming?

Kluczowe metryki to: coverage score ATT&CK — procent priorytetowych technik wykrywanych na poziomie Detected and Alerted (cel: >70% po 12 miesiącach programu); trend coverage między sesjami — poprawa o 10-20 punktów procentowych po każdym cyklu remediacji; Mean Time to Detect (MTTD) dla testowanych technik — jak szybko SIEM/EDR generuje alert po wykonaniu techniki; liczba zaadresowanych luk detekcyjnych — ile z listy action items z poprzedniej sesji zostało zaimplementowanych. Sukces programu to nie jeden wynik — to powtarzalny, mierzalny trend poprawy dojrzałości detekcyjnej organizacji w czasie.

Źródła

MITRE Corporation. (2025). MITRE ATT&CK Enterprise Matrix v15. https://attack.mitre.org/
Red Canary. (2025). Atomic Red Team — Library of adversary emulation tests. https://github.com/redcanaryco/atomic-red-team
MITRE Corporation. (2024). CALDERA — Cybersecurity Operations Research. https://github.com/mitre/caldera
Security Risk Advisors. (2024). VECTR Purple Team Exercise Platform. https://vectr.io/
Rabobank CDC. (2024). DeTT&CT — Detect Tactics, Techniques & Combat Threats. https://github.com/rabobank-cdc/DeTTECT
CISA. (2024). Known Exploited Vulnerabilities Catalog. https://www.cisa.gov/known-exploited-vulnerabilities-catalog
Mandiant. (2024). M-Trends 2024: Special Report. https://www.mandiant.com/m-trends
CrowdStrike. (2025). 2025 Global Threat Report. https://www.crowdstrike.com/global-threat-report/
Scythe. (2024). Purple Teaming: The Definitive Guide. https://scythe.io/library/purple-team-guide
Pols, P. (2021). The Unified Kill Chain: Designing a Complementary ATT&CK-based Kill Chain for Threat Intelligence. SANS Institute.

Tematy powiązane

Zobacz również:

EDR vs XDR vs NDR — porównanie technologii detection

Purple teaming — jak połączyć ofensywne i defensywne testy bezpieczeństwa dla lepszej ochrony