Projektowanie playbooków

Playbook to skodyfikowany proces reagowania: uporządkowany, rozgałęziający się zestaw kroków wykonywanych przez platformę SOAR po wyzwoleniu. Jest wykonywalną wersją runbooka, który wcześniej znajdował się w wiki.

Podczas gdy runbook mówi sprawdź reputację adresu IP, playbook faktycznie wywołuje API reputacji, analizuje wynik i wybiera ścieżkę na podstawie oceny. Umiejętne projektowanie playbooków jest kluczową kompetencją inżynierii automatyzacji w SOC.

Nigdy nie należy projektować playbooka w oderwaniu od rzeczywistości. Najpierw należy udokumentować, jak analitycy faktycznie obsługują dany alert, krok po kroku, uwzględniając podejmowane decyzje i sprawdzane dane.

Każdy krok należy przypisać do jednej z trzech kategorii:

• Działanie deterministyczne — te same dane wejściowe zawsze dają ten sam wynik (bezpieczne do automatyzacji).
• Wzbogacanie danych — gromadzenie danych bez skutków ubocznych (bezpieczne do automatyzacji).
• Ocena sytuacji — wymaga kontekstu lub odpowiedzialności (należy pozostawić udział człowieka).

Każdy playbook potrzebuje precyzyjnego wyzwalacza. Jeśli będzie zbyt szeroki, uruchomi się na podstawie szumu; jeśli będzie zbyt wąski, pominie rzeczywiste przypadki.

Wyzwalacze są zwykle powiązane z regułą korelacji SIEM, kategorią wykrycia EDR lub werdyktem bramy pocztowej. Należy jednoznacznie zdefiniować warunek wejściowy.

Playbook działa na artefaktach: wskaźnikach wyodrębnionych ze zdarzenia wyzwalającego, takich jak adresy IP, hashe plików, konta użytkowników, adresy URL i nazwy hostów.

Dobrze zaprojektowany proces normalizuje je na wczesnym etapie do spójnego obiektu kontekstu, dzięki czemu każdy kolejny krok odwołuje się do tych samych nazw pól, niezależnie od tego, które narzędzie wygenerowało zdarzenie.

• Wyodrębniać artefakty raz, na początku.
• Sprawdzać typy danych (czy to rzeczywiście prawidłowy adres IPv4?).
• Przenosić wspólny kontekst przez cały przebieg.

Rzeczywiste procesy mają rozgałęzienia. Po wzbogaceniu danych należy wybrać ścieżkę na podstawie dowodów. Rozgałęzienia powinny być jawne i wyczerpujące, aby żadne zdarzenie nie pozostało nieobsłużone.

Przed każdym działaniem destrukcyjnym, nieodwracalnym lub mającym duży zasięg skutków należy wstawić bramkę zatwierdzenia przez człowieka. Playbook gromadzi dowody, przedstawia je i blokuje wykonanie do czasu otrzymania decyzji.

Bramkę należy zaprojektować tak, aby przekroczenie limitu czasu miało bezpieczny skutek domyślny. W przypadku powstrzymywania zagrożenia przekroczenie limitu czasu bez odpowiedzi może spowodować eskalację do inżyniera dyżurnego, zamiast cichego kontynuowania działania lub pominięcia sprawy.

• Wyłączanie kont: wymaga bramki.
• Blokowanie dużych podsieci: wymaga bramki.
• Wzbogacanie danych o wskaźniku: bramka nie jest potrzebna.

Integracje ulegają awariom. Interfejsy API ograniczają częstotliwość żądań, przekraczają limit czasu i zwracają nieprawidłowo sformatowane dane. Procedura reagowania zakładająca, że każde wywołanie zakończy się powodzeniem, pozostawi incydenty przetworzone tylko częściowo.

Należy uwzględnić:

• Ponawianie prób z narastającym opóźnieniem w przypadku błędów przejściowych (HTTP 429, 503).
• Bezpieczne wartości domyślne — jeśli wzbogacanie danych się nie powiedzie, należy domyślnie eskalować sprawę do analityka, a nie zamykać jej automatycznie.
• Obsługę komunikatów dead-letter — kierowanie nieprzetwarzalnych zdarzeń do kolejki, którą analizuje analityk.

Playbook może uruchomić się dwukrotnie dla tego samego zdarzenia z powodu zduplikowanych alertów lub ponawiania prób. Działania muszą być idempotentne: ich dwukrotne wykonanie nie powinno powodować podwójnych szkód.

Izolowanie już odizolowanego hosta powinno być operacją bez efektu, a nie błędem. Przed utworzeniem zgłoszenia należy sprawdzić, czy dla tego samego klucza deduplikacji istnieje już zgłoszenie.

Należy unikać tworzenia jednego ogromnego playbooka dla każdego typu incydentu. Zamiast tego należy podzielić go na pod-playbooki wielokrotnego użytku: pod-playbook wzbogacania danych, pod-playbook powstrzymywania zagrożenia i pod-playbook powiadamiania.

Odzwierciedla to dobre zasady projektowania oprogramowania. Wielokrotnego użytku blok wzbogacania informacji o adresie IP, wywoływany z playbooków dotyczących phishingu, ataków brute force i C2, oznacza jedno miejsce do wprowadzenia poprawki, gdy zmieni się API threat intelligence.

Nowe playbooki należy najpierw uruchamiać w trybie dry-run / symulacji: wykonywać wzbogacanie danych i rejestrowanie zdarzeń, ale zastępować destrukcyjne działania atrapami. Należy porównać proponowane działanie playbooka z tym, co analitycy zrobiliby w przeszłych przypadkach.

Działania na żywo należy włączyć dopiero wtedy, gdy logika decyzyjna okaże się poprawna dla rzeczywistych, wcześniejszych incydentów. Nawet wówczas należy rozpocząć od bramki zatwierdzania wymagającej akceptacji każdego działania.

Playbooki są kodem i wymagają takiej samej dyscypliny. Należy przechowywać je w systemie kontroli wersji, aby każda zmiana była sprawdzona, możliwa do prześledzenia i odwrócenia.

• Dziennik zmian odpowiada na pytanie: dlaczego ten playbook działał inaczej w zeszłym miesiącu?
• Wzajemna weryfikacja pozwala wykryć niebezpieczną logikę, zanim trafi ona do środowiska produkcyjnego.
• Udokumentowanie zamierzonego wyzwalacza, decyzji i właściciela ułatwia utrzymanie playbooka podczas rotacji personelu.

Nieudokumentowany playbook, którego nikt nie rozumie, staje się obciążeniem w chwili, gdy zadziała nieprawidłowo.

Najważniejsze zasady projektowania playbooków:

• Playbook to wykonywalny, rozgałęziony proces reagowania; należy projektować go na podstawie rzeczywistego procesu ręcznego.
• Należy klasyfikować kroki jako działanie deterministyczne, wzbogacanie danych lub ocenę ekspercką; działania wymagające oceny należy zatwierdzać przez analityka.
• Należy definiować precyzyjne wyzwalacze, normalizować artefakty do wspólnego kontekstu i uwzględniać wszystkie możliwe rozgałęzienia.
• Błędy należy obsługiwać za pomocą ponawiania prób i bezpiecznych wartości domyślnych; nieudane wzbogacanie danych powinno prowadzić do eskalacji, a nie do automatycznego zamknięcia.
• Działania powinny być idempotentne, playbooki należy utrzymywać w formie modułowej z użyciem wielokrotnego użytku pod-playbooków, a przed uruchomieniem na żywo należy testować je w trybie dry-run na podstawie wcześniejszych incydentów.