Jak stworzyć dobry playbook dla operatora SOC

Podczas incydentu analityk nie powinien zastanawiać się, gdzie znaleźć logi, kto może zablokować konto i kiedy trzeba poinformować właściciela systemu. Dobry playbook zbiera te decyzje w jedną, krótką instrukcję, którą da się wykonać pod presją czasu.

W skrócie: playbook powinien określać wyzwalacz, role, kryteria oceny, kroki techniczne, zasady eskalacji i sposób dokumentowania. Musi też być regularnie testowany i aktualizowany.

Czym jest playbook SOC?

Playbook to operacyjna procedura dla konkretnego scenariusza, na przykład podejrzanego logowania, phishingu, infekcji stacji roboczej lub próby szyfrowania plików. Nie zastępuje wiedzy analityka. Ogranicza liczbę decyzji, które trzeba podejmować od zera, i zapewnia spójny sposób obsługi podobnych zdarzeń.

Warto odróżnić trzy pojęcia:

• polityka wyznacza zasady i odpowiedzialność,
• plan reagowania opisuje organizację obsługi incydentów,
• playbook prowadzi operatora przez jeden określony scenariusz.

Sześć elementów skutecznego playbooka

1. Warunek uruchomienia

Zapisz, jaki alert, zgłoszenie lub zestaw obserwacji uruchamia procedurę. Przykład: „EDR wykrył masową zmianę rozszerzeń plików” jest lepszy niż ogólne „podejrzenie ransomware”.

2. Cel i zakres

Określ, jaki wynik ma osiągnąć analityk i czego procedura nie obejmuje. Dla przejęcia konta celem może być potwierdzenie zdarzenia, zakończenie aktywnych sesji, zabezpieczenie dowodów i przywrócenie bezpiecznego dostępu.

3. Role i uprawnienia decyzyjne

Wskaż osobę wykonującą kroki, kierującego incydentem, właściciela systemu oraz kontakty do zespołu prawnego i komunikacji. Najważniejsze jest jasne określenie, kto może odłączyć system, zablokować konto lub przerwać proces biznesowy.

4. Kroki techniczne i punkty decyzyjne

Każdy krok powinien mieć czasownik, konkretne narzędzie i oczekiwany wynik. Zamiast „sprawdź logi” napisz: „w SIEM wyszukaj logowania użytkownika z ostatnich 24 godzin; zapisz adresy IP i identyfikatory sesji w zgłoszeniu”.

Rozgałęzienia powinny odpowiadać na proste pytania, np. „czy logowanie pochodzi z zaakceptowanej lokalizacji?”. Operator musi wiedzieć, co zrobić po odpowiedzi „tak”, „nie” i „nie wiadomo”.

5. Komunikacja i eskalacja

Zapisz progi ważności, kanały komunikacji i maksymalny czas eskalacji. W procedurze powinien znaleźć się także kanał zapasowy na wypadek niedostępności poczty lub komunikatora.

6. Dowody, dokumentacja i metryki

Określ, które dane należy zachować, gdzie je umieścić i jak kontrolować dostęp. Mierz nie tylko czas reakcji, ale także jakość: odsetek fałszywych alarmów, liczbę niejasnych kroków oraz poprawki wynikające z testów.

Jak zbudować pierwszy playbook krok po kroku

Krok 1: wybierz jeden częsty scenariusz

Dobrym początkiem jest phishing, przejęcie konta pocztowego albo infekcja stacji roboczej. Scenariusz powinien być wystarczająco wąski, aby procedura mieściła się na kilku ekranach.

Krok 2: narysuj obecny proces

Porozmawiaj z osobami, które faktycznie obsługują alerty. Zapisz narzędzia, decyzje, zależności i miejsca, w których praca zwykle się zatrzymuje. Nie opisuj procesu idealnego, dopóki nie poznasz rzeczywistego.

Krok 3: uporządkuj reakcję

Aktualny NIST SP 800-61 Rev. 3 łączy reagowanie na incydenty z zarządzaniem ryzykiem w ramach Cybersecurity Framework 2.0. W praktyce playbook powinien wspierać przygotowanie, wykrycie i analizę, ograniczenie skutków, odzyskanie działania oraz wyciągnięcie wniosków.

Krok 4: dodaj bezpieczniki

Zaznacz działania odwracalne i te, które wymagają zgody. Automatyczna izolacja pojedynczej stacji może być uzasadniona, ale odłączenie systemu produkcyjnego powinno mieć jasno wskazanego decydenta.

Krok 5: opublikuj wersję 1.0

Nadaj dokumentowi właściciela, numer wersji i termin przeglądu. Umieść go w miejscu dostępnym dla dyżuru, z kontrolą zmian i kopią awaryjną.

Co automatyzować, a co zostawić człowiekowi

Automatyzacja dobrze sprawdza się przy tworzeniu zgłoszenia, wzbogacaniu danych, zbieraniu logów i wykonywaniu powtarzalnych zapytań. Decyzje o dużym wpływie biznesowym powinny mieć zatwierdzenie człowieka oraz czytelny zapis przyczyny.

Dobra zasada: najpierw ustabilizuj i przetestuj proces ręczny. Automatyzowanie niejasnej procedury jedynie przyspiesza popełnianie tych samych błędów.

Testowanie playbooka

Najprostszym testem jest ćwiczenie tabletop. Zespół otrzymuje scenariusz i przechodzi procedurę krok po kroku bez wykonywania zmian w systemie produkcyjnym. Prowadzący stopniowo dodaje nowe informacje, np. brak kontaktu z właścicielem systemu albo niedostępność podstawowego kanału komunikacji.

Po ćwiczeniu zapisz:

• które kroki były niejednoznaczne,
• jakich uprawnień lub danych zabrakło,
• gdzie zespół czekał na decyzję,
• co trzeba zmienić w narzędziach i dokumentacji,
• kto odpowiada za każdą poprawkę i do kiedy ją wdroży.

Checklista przed publikacją

• Czy wyzwalacz i cel procedury są jednoznaczne?
• Czy każdy krok wskazuje narzędzie i oczekiwany wynik?
• Czy operator wie, kiedy przerwać procedurę i eskalować?
• Czy kontakty i uprawnienia są aktualne?
• Czy opisano sposób zachowania dowodów?
• Czy istnieje właściciel, numer wersji i data kolejnego testu?

Dobry playbook nie musi być obszerny. Musi być wykonalny, zrozumiały i sprawdzony wtedy, gdy zespół nie znajduje się jeszcze pod presją prawdziwego incydentu.