playbook

Playbook to spisany scenariusz postępowania przy określonym typie incydentu albo zadania bezpieczeństwa: kolejne kroki, punkty decyzyjne i osoby odpowiedzialne. Specyfikacja OASIS CACAO definiuje playbook jako przepływ pracy dla orkiestracji bezpieczeństwa, zawierający zestaw kroków wykonywanych według logicznego procesu, uruchamiany doraźnie, okresowo albo przez zdarzenie automatyczne lub ręczne ^[1]. Playbook może być dokumentem czytanym przez człowieka, programem wykonywanym przez maszynę albo jednym i drugim.

Jak działa

Playbook przekłada ogólny proces reagowania na incydenty na konkretne czynności. Podręcznik CISA z listopada 2021 roku opisuje standardowy przebieg reakcji w fazach zdefiniowanych w NIST SP 800-61 Rev. 2: przygotowanie, wykrycie i analiza, powstrzymanie, usunięcie i odtworzenie oraz działania po incydencie ^[2]. Fazy są iteracyjne i mogą się powtarzać aż do zamknięcia incydentu, a do śledzenia wykonania służy dołączona lista kontrolna ^[2]. Obecną wersją wytycznych NIST jest Rev. 3 z kwietnia 2025 roku, która osadza reagowanie na incydenty w zarządzaniu ryzykiem według NIST Cybersecurity Framework 2.0 ^[3].

RYS. 1Fazy reakcji w podręczniku CISA

Ten sam dokument zawiera drugi scenariusz, dla podatności, z fazami identyfikacji, oceny, usuwania i raportowania ^[2]. CISA określa cel obu jako ujednolicenie wspólnych praktyk reagowania ^[2].

Składniki

Playbook ma punkt wejścia, czyli zdarzenie, które go uruchamia, oraz kroki z warunkami. Specyfikacja CACAO 2.0, zatwierdzona 27 listopada 2023 roku, nazywa osiem typów kroków przepływu ^[1].

CACAO wyróżnia też rodzaje playbooków według celu, m.in. powiadamianie, wykrywanie, dochodzenie, zapobieganie, łagodzenie i naprawę ^[1]. Wspólny format ma umożliwić dzielenie się playbookami między organizacjami i narzędziami ^[1].

W praktyce zespołu SOC (Security Operations Center) playbook jest przypięty do alarmu. Kapitan Hack wymienia wśród elementów poprawnie skonstruowanego alarmu odnośnik do runbooka, playbooka lub procedury, dodatkowe zapytania śledcze oraz przykłady trafień prawdziwych i fałszywych alarmów ^[5]. Dzięki temu triaż nie zależy od pamięci dyżurnego.

Playbook a automatyzacja

Playbook wykonywany przez maszynę to podstawa systemów SOAR (Security Orchestration, Automation and Response). Część platform XDR (Extended Detection and Response) także ich używa: dokumentacja Microsoft Defender XDR opisuje automatyczne działania i playbooki, które przywracają przejęte urządzenia, tożsamości i skrzynki do stanu bezpiecznego ^[8]. Automatyzacja nadaje się do kroków powtarzalnych, takich jak blokada adresu, izolacja maszyny czy zebranie logów. Decyzje o skutkach biznesowych, na przykład o wyłączeniu sklepu, zwykle zostają punktem decyzyjnym dla człowieka.

W WordPressie

Dla typowej witryny na WordPressie najważniejszy jest playbook „strona przejęta”. Oficjalna dokumentacja WordPressa daje gotowy szkielet takiego scenariusza ^[4]:

1. Dokumentacja. Zapisać objawy i czas ich zauważenia oraz ostatnie zmiany, na przykład nową wtyczkę; to podstawa raportu z incydentu ^[4].
2. Skanowanie. Przeskanować stronę skanerem wtyczkowym i zewnętrznym, a także komputer administratora ^[4].
3. Kontakt z hostingiem. Sprawdzić, czy włamanie nie dotyczy innych stron na serwerze ^[4].
4. Odcięcie dostępu. Wymusić zmianę haseł wszystkich użytkowników i wymienić klucze bezpieczeństwa i sole w wp-config.php, co wylogowuje wszystkie sesje ^[4].
5. Kopia stanu. Wykonać kopię zapasową także zainfekowanej strony, na wypadek awarii przy czyszczeniu ^[4].
6. Czyszczenie. Podmienić katalogi /wp-admin i /wp-includes na te same wersje, sprawdzić .htaccess i pliki motywu ^[4].
7. Po czyszczeniu. Zaktualizować WordPress, ponownie zmienić hasła i ustalić, którędy weszli atakujący ^[4].

Punkty 4–6 odpowiadają fazom opanowania incydentu i usunięcia zagrożenia, opisanym szerzej w haśle czyszczenie przejętej strony. Dobry playbook dopisuje do tego szkieletu dane konkretnej strony: kto ma dostęp do panelu hostingu, gdzie leżą kopie, kto decyduje o wyłączeniu witryny i kogo trzeba zawiadomić.

Znaczenie

Playbook skraca czas reakcji, bo decyzje podejmuje się przed incydentem, a nie w jego trakcie. Ma też znaczenie dla obowiązków prawnych. Dyrektywa NIS2 wymaga od podmiotów kluczowych i ważnych wczesnego ostrzeżenia w ciągu 24 godzin od powzięcia wiedzy o poważnym incydencie, zgłoszenia w ciągu 72 godzin i sprawozdania końcowego nie później niż miesiąc po zgłoszeniu ^[7]. Sekurak, opisując wdrożenie wymagań NIS2 na narzędziach Wazuh i Zabbix, wymienia wśród elementów integracji z CSIRT szablon zgłoszenia i playbook 24/72 h ^[6]. Szerzej o terminach w haśle obowiązek zgłaszania incydentów.

Dobre praktyki

• Jeden playbook na jeden typ zdarzenia: przejęcie konta, ransomware, wyciek danych, podmiana treści strony (defacement).
• Każdy krok ma właściciela i kryterium zakończenia; lista kontrolna ułatwia śledzenie wykonania ^[2].
• Ćwiczyć scenariusze, na przykład w formie tabletop exercise, i poprawiać je po każdym post-incident review.
• W playbooku wycieku danych osobowych przewidzieć ocenę, czy potrzebne jest zgłoszenie naruszenia ochrony danych.
• Przechowywać playbook poza systemem, którego dotyczy, tak aby był dostępny, gdy strona lub serwer nie działa.

Historia i przykłady

Jednym z najczęściej przywoływanych publicznych wzorców są podręczniki CISA dla federalnej administracji cywilnej USA. Powstały na podstawie sekcji 6 rozporządzenia wykonawczego EO 14028, które poleciło CISA opracować standardowe procedury reagowania na incydenty i podatności ^[2]. Dokument opublikowano w listopadzie 2021 roku, z oznaczeniem TLP:CLEAR, czyli bez ograniczeń w udostępnianiu ^[2]. Obejmuje on playbook reagowania na incydenty i osobny playbook reagowania na podatności ^[2].

Równolegle rozwija się standard zapisu playbooków wykonywanych maszynowo. Specyfikacja CACAO 2.0 ma pozwolić organizacjom wykrywać, badać, zapobiegać, łagodzić i usuwać zagrożenia w czasie istotnym dla obrony, dzięki jednolitemu sposobowi tworzenia, dokumentowania i wymiany playbooków między organizacjami i narzędziami ^[1].