Usuwanie luk w wykrywaniu i metryki

Purple teaming generuje bogaty zbiór danych, ale bez metryk pozostają one tylko anegdotami. Metryki zamieniają ćwiczenia w wiarygodny, oparty na danych obraz poprawy, który można przedstawić kadrze zarządzającej i osobom odpowiedzialnym za budżet.

• Pokazują, czy zabezpieczenia rzeczywiście się poprawiają
• Ułatwiają ustalenie, gdzie zainwestować ograniczone zasoby inżynieryjne
• Sprawiają, że abstrakcyjny „stan bezpieczeństwa” staje się konkretny i możliwy do śledzenia

Celem nie jest wysoki wynik sam w sobie, lecz mierzalna i trwała poprawa ochrony przed istotnymi zagrożeniami.

Najważniejszą metryką jest pokrycie detekcją: odsetek przetestowanych technik, dla których wygenerowano alert.

Należy obliczać je dla każdej taktyki oraz łącznie:

Odsetki pokrycia mogą wprowadzać w błąd. Zliczanie wyłącznie technik, które wybrano do testów, zawyża wynik, a uznanie kruchej reguły za objętą pokryciem przecenia rzeczywistą ochronę.

• Pokrycie należy mierzyć względem zestawu technik istotnych dla zagrożeń, a nie zestawu wybranego pod z góry założony wynik
• Wynik „wykryto” musi pochodzić z solidnej reguły opartej na zachowaniu
• Wyniki polegające wyłącznie na rejestrowaniu nie oznaczają pokrycia; wskazują jedynie na potencjalne pokrycie

Zawsze należy podawać procent wraz z mianownikiem: „80% technik FIN7” mówi znacznie więcej niż samo „80%”.

Szybkość ma takie samo znaczenie jak widoczność. Dwie metryki czasu pozwalają zmierzyć szybkość reakcji zabezpieczeń:

• MTTD — średni czas wykrycia: od znacznika czasu działania do znacznika czasu alertu
• MTTR — średni czas reakcji: od alertu do działania powstrzymującego

Ponieważ purple teaming rejestruje dokładny moment uruchomienia każdej techniki, można mierzyć te wartości precyzyjnie, zamiast szacować je na podstawie nieuporządkowanych danych o incydentach.

Nie każda luka wymaga takiej samej pilności. Luki należy uszeregować według ryzyka, łącząc prawdopodobieństwo zastosowania techniki z rozmiarem szkód, jakie mogłaby spowodować.

• Wysokie prawdopodobieństwo + duży wpływ (np. zrzut LSASS) = naprawić w pierwszej kolejności
• Niskie prawdopodobieństwo + mały wpływ = odłożyć do backlogu
• Uwzględnić, czy technika pojawia się w posiadanych danych wywiadowczych dotyczących zagrożeń

Prosta punktacja będąca iloczynem prawdopodobieństwa i wpływu daje uporządkowaną listę poprawek, która kieruje wysiłek tam, gdzie najbardziej ogranicza rzeczywiste ryzyko.

Przed napisaniem reguły należy zdiagnozować, dlaczego luka istnieje. Sposób naprawy zależy od przyczyny źródłowej:

• Brak telemetrii — włączyć brakujące źródło danych (np. konfigurację Sysmon lub rejestrowanie bloków skryptów)
• Telemetria, ale brak reguły — napisać detekcję
• Reguła istnieje, ale nie zadziałała — naprawić logikę lub filtr, który ją wyciszył
• Alert został wygenerowany, ale go zignorowano — to problem procesu lub triage'u, a nie luka w regułach

Naprawa błędu logiki jest stratą wysiłku, jeśli odpowiedni dziennik nigdy nie był zbierany.

Najbardziej podstawową luką jest brak danych. Na przykład rejestrowanie bloków skryptów PowerShell włącza się za pomocą Group Policy lub rejestru, aby dane z Event ID 4104 były dostępne.

Po zapewnieniu telemetrii należy napisać detekcję i dostroić ją pod kątem wartościowego sygnału. Niedostrojone reguły zasypują analityków fałszywymi alarmami i są ignorowane.

• Należy zacząć od szerokiej reguły, aby potwierdzić pojawianie się artefaktu
• Dodać wykluczenia dla znanej, prawidłowej aktywności bazowej
• Zmierzć odsetek fałszywych alarmów względem normalnego ruchu
• Ponownie uruchomić emulację, aby potwierdzić, że reguła nadal wykrywa atak

Detekcja jest „gotowa” dopiero wtedy, gdy niezawodnie reaguje na atak i pozostaje cicha podczas prawidłowej aktywności.

Liczby z pojedynczego ćwiczenia są tylko migawką; prawdziwy obraz pokazują trendy. Należy śledzić pokrycie i MTTD w kolejnych kwartałach.

• Q1: pokrycie 45%, MTTD 22 min
• Q2: pokrycie 62%, MTTD 14 min
• Q3: pokrycie 71%, MTTD 9 min

Poprawiający się trend pokazuje, że purple teaming przynosi efekty. Płaski lub pogarszający się trend sygnalizuje regresję detekcji albo to, że poprawki nie są wdrażane.

Detekcje mogą po cichu przestać działać wraz ze zmianami w środowisku. Należy traktować je jak kod i testować pod kątem regresji.

• Ponownie uruchamiać w każdym cyklu techniki, które wcześniej działały
• Automatyzować ciągłą walidację, aby uszkodzone detekcje generowały alert
• Przechowywać treść detekcji w systemie kontroli wersji i przeglądać zmiany

Detekcja, która po cichu przestała działać, może być wręcz gorsza niż brak detekcji, ponieważ zespół uważa, że jest chroniony, choć w rzeczywistości tak nie jest.

Raport należy dostosować do odbiorców. Inżynierowie potrzebują szczegółów na poziomie technik, a kadra zarządzająca — wyników i informacji o ryzyku.

• Dla inżynierów: wyniki dla poszczególnych technik, utworzone reguły, uwagi dotyczące dostrajania
• Dla kadry zarządzającej: trend pokrycia, trend MTTD, najważniejsze ograniczone i nadal istniejące ryzyka
• Wizualizacja: mapa cieplna ATT&CK Navigator pokazująca postęp w czasie

Przedstawianie wyników jako ograniczenia ryzyka, a nie surowych danych technicznych, pozwala utrzymać poparcie i finansowanie programu.

Proszę sprawdzić zrozumienie zamykania luk i stosowania metryk.

Można teraz rygorystycznie mierzyć i poprawiać pokrycie detekcją:

• Używać pokrycia, MTTD i MTTR jako podstawowych metryk, zawsze podając ich mianownik
• Unikać pozornego pokrycia wynikającego z wybiórczych lub kruchych detekcji
• Ustalać przyczynę źródłową każdej luki przed jej naprawą: telemetria, reguła, logika lub triage
• Włączać brakujące dane, a następnie dostrajać reguły pod kątem niskiego odsetka fałszywych alarmów
• Śledzić trendy i chronić się przed cichą regresją detekcji
• Raportować ograniczenie ryzyka, wykorzystując mapy cieplne ATT&CK, aby utrzymać program

Ukończono kurs Purple Teaming: łączenie zespołów red i blue w ciągłą, mierzalną pętlę, która pozwala potwierdzać poprawę skuteczności zabezpieczeń.