Vytváříme playbooky pro řešení kybernetických incidentů

Playbook musí poskytnout návod pro řešení závažného bezpečnostního incidentu, kdy je nutné pod tlakem dělat ty správné kroky, a kdy mozek často jede na autopilota. Proto musí být napsaný jednoduše, jasně a akčně.

Každý krok musí být jednoznačný a srozumitelný i pod kognitivním zatížením, neboť mozek ve stresu ztrácí schopnost komplexního uvažování. Takže žádné filozofování, ale naprosto jasné pokyny, kdo, co  a kdy má udělat.

Pro jaké incidenty by měl být vytvořen playbook

Nemá smysl se snažit napsat playbooky úplně pro všechny incidenty, které mohou nastat, ale velmi efektivním způsobem je vytváření playbooků dle analýzy rizik. Kritická rizika na základě hodnocení zranitelností a hrozeb jsou ideálním startem pro tvorbu.. V současné době jsou obecně považovány za největší rizika ransomwarové útoky ( z důvodu ztráty dat), cílené phishingové útoky, které jsou díky AI stále přesvědčivější, nebo eskalace oprávnění a následná kompromitace systémů, případně únik citlivých informací (jako jsou osobní údaje, know-how atp.)

Kdo by měl psát playbook

A tady začíná první problém. Když se má psát playbook, což je de facto procesní instrukce pro řešení kybernetických incidentů, tak se asi všichni shodneme, že by jej měl psát ten, kdo danou činnost skutečně vykonává. V realitě však zpravidla nikdy dané činnosti nevykonává pouze jedna osoba, nýbrž více osob a tak je nutné s nimi tento postup konzultovat. Dost často není s těmito osobami rozumná řeč, mají plno připomínek a dokončení dokumentu se vzdaluje.

Někteří lidé navíc občas nechtějí spolupracovat, a tak místo aby něco napsali, radši hodiny diskutují, proč to nejde, a vymýšlejí varianty, které se nikdy nerealizují. Proto je často nejefektivnější prosté rozhodnutí shora: „Ty to napíšeš.“ Žádné další workshopy, žádné kolečko připomínek. Jakmile ten člověk musí text sepsat, většina jeho „ale“ se náhle rozplyne a rovněž už ani netrvá na dokonalosti a vzniká tak celkem rychle prvotní verze pokrývající většinu případů.

Dejte autorovi konkrétní šablonu nebo příklad z jiné oblasti, ať nemusí začínat od prázdného papíru. Řekněte: „Napiš to tak, jak bys to potřeboval ty, kdybys v noci řešil incident.“

Jak by měl vypadat playbook

Neexistuje univerzální šablona. Každá organizace má jinou strukturu, jiné procesy, jinou kulturu a jiné lidi. Šablonu lze použít jako výchozí DRAFT, ale nakonec ji stejně budete muset celou přepsat podle sebe. Nicméně je vhodné dodržet tuto strukturu:

• Název playbooku, aby se vždy postupovalo podle toho správného dokumentu
• Verze a datum poslední revize, aby se dalo ověřit, že se postupuje podle poslední verze
• Klasifikační stupeň – zpravidla interní nebo důvěrný, protože obsahuje citlivé informace o postupech, rolích a infrastruktuře a nechcete, aby se vaše postupy šířily po internetu
• Vlastník dokumentu, protože ten jej pak bude upravovat po incidentech a testech
• Úvod a rozsah, tj. co playbook pokrývá a jaké jsou jeho limity
• Cíl playbooku – Jaký je konečný, ověřitelný cíl? (Např. „Identifikovat a eliminovat hrozbu, obnovit dostupnost služby po incidentu daného typu.
• Spouštěcí podmínky – kdy se podle tohoto playbooku postupuje
• RAM matice, která zobrazuje role ve sloupcích a aktivity v řádcích. Pokud má playbook málo kroků, může pokrývat všechny aktivity. U rozsáhlejších dokumentů je vhodné matice zjednodušit a shrnout role po fázích.
• Workflow diagram (Swimlane/BPMN) je vhodné dát hned na začátek, aby poskytl přehled celého procesu. Jednoduché schéma ukazující hlavní větve (Detekce, Analýza, Zamezení šíření, Eliminace, Obnova, Poučení) a rozhodovací body hodně napoví.
• Kontakty by měly obsahovat jména konkrétních osob, telefonní čísla, e-mail
• Podrobné kroky v tabelární formě – Role – Aktivita – Vstup – Výstup – Odpovědnost. Začínáme rolí, protože každý v playbooku hledá to svoje, ale v digitální podobě je možné formu snadno pozměnit podle toho, kdo do něj nahlíží.
• Časové limity na jednotlivé kroky – ty by měly být provázány s kontinuitou činností dané organizace
• Reference na runbooky – odkazy na detailní technické postupy „jak“, protože playbook přináší výhradně odpověď na otázku, kdo, co a kdy.

Podrobné kroky

Podle playbooku by měla být schopna postupovat i osoba, která se na něm nepodílela. Stěžejní část celého dokumentu je právě kapitola, kde je uveden sled  jednotlivých kroků. které se musí udělat. Tabulka, s podrobnými kroky, které je nutné učinit, by měla obsahovat následující sloupce:

• Fáze incidentu – aby bylo jasné v jaké fázi jsme (obzvláště důležité, protože zde máme různé standardy)
• Krok – víceúrovňové – číslo a fáze a krok v rámci dané fáze
• Role – kdo danou aktivitu vykonává
• Aktivita – co se má udělat – sloveso v přít. čase, aktivní rod)
• Vstup – co je vstupem a může to být i výsledek předchozího kroku.
• Výstup – explicitně definuje, jak vypadá úspěšné dokončení kroku a umožňuje i jeho kontrolu.
• Ověření času – splnění nastavených časových limitů pro daný krok
• Ověření – Zde se uvede, jak je možné ověřit, že bylo dosaženo požadovaného cíle v rámci daného kroku.

Playbook není o tom, jak přesně danou činnost provést (to patří do runbooku), ale kdo co udělá, kdy a s jakým cílem. Jasně definované role a činnosti a zvyšují odolnost vůči stresu a tabulka nutí k disciplíně, struktuře a dodržení stanovených časů.

Měření času, komunikace a dokumentace

Mnoho organizací má tendenci měřit úplně všechno, bohužel i tam, kde to postrádá smysl. U incidentů to bývá obzvlášť vidět: každý krok má mít časový limit, analytik má co pět minut hlásit stav a někdo v managementu se snaží sledovat rychlost reakce. Jenže takto se skutečný incident zvládat nedá. Analýza malwaru může trvat deset minut, ale také tři dny, podle kontextu, nástrojů, zkušenosti i rozsahu škody.

V krizové situaci je třeba nechat odborníky dělat jejich práci a měřit až zpětně, při analýze po incidentu. Snaha měřit čas jednotlivých kroků během incidentu vede jen k většímu stresu a chybám. Proto je dobré dodržovat stanovené časy pro předávání informací v návaznosti na případné spuštění alternativních scénářů pro zachování kontinuity činností, ale detailní analýzu časových intervalů nechat až na vyhodnocení v rámci PDCA cyklu.

Časy reakcí ale smysl mají, obzvláště pokud víme, proč je měříme. V praxi sledujeme reálné TTD (Time To Detect – doba do odhalení incidentu), TTC (Time To Contain – doba do zamezení šíření) a TTR (Time To Recover – doba do obnovy služby) a porovnáváme je s RTO a maximální tolerovanou dobou výpadku. Snažíme se do nich vejít, ale rovnou si přiznáme, že u některých typů incidentů (nový malware, kombinované útoky, rozsáhlý postranní pohyb) to prostě vždycky nevyjde. RTO je byznysový cíl, ne kladivo na analytiky, kterým je budeme během incidentu mlátit po hlavě.

Cílové časy jednotlivých fází playbooku by neměly vznikat od stolu, ale z testů playbooku a navazujících runbooků. Scénář si nanečisto zahrajeme, projdeme celý playbook, spustíme příslušné runbooky, změříme reálné TTD, TTC a TTR a teprve podle těchto výsledků si spočítáme, do jakého časového okna se vůbec můžeme reálně vejít. Až potom má smysl řešit, jestli jsou nastavené RTO a očekávání byznysu realistické, nebo zda je potřeba upravit technologie, kapacity týmu, nebo samotné cíle.

Měřené TTD, TTC a odhadované TTR nám pak u živého incidentu neslouží k mikromanagementu (hlášení každých pět minut), ale k tomu, abychom včas poznali, že se do RTO už nevejdeme a playbook mohl spustit příslušný runbook: přechod do náhradního provozu, krizovou komunikaci se zákazníky nebo aktivaci scénáře disaster recovery. Smyslem měření tedy není trestat tým za to, že nestihl nemožné, ale dát vedení včas jasný signál: „Do RTO se už nevejdeme, přecházíme do plánu B podle tohoto runbooku.“

Komunikaci během incidentu má zajišťovat konkrétní osoba (například Incident Manager), ne každý zvlášť. Analytik nebo forenzní specialista má pracovat, ne vyplňovat tabulky nebo odpovídat na otázky typu „jak jsme na tom“. Playbook by měl explicitně obsahovat komunikační plán: Kdo, komu, co a jakým kanálem hlásí. (Např. „Incident Manager -> Vedení společnosti: Okamžitě telefonicky, následně e-mailem s šablonou X.“ a Checklist externích subjektů: Kontakty na CERT týmy, policii, externí forenzní firmy, apod.

Zapomínat nesmíme ani dokumentaci, která je důležitá pro vyhodnocení průběhu incidentu a přijetí příslušných opatření v rámci neustálého zlepšování. Je však důležité, aby byla tato odpovědnost přiřazena jiné osobě, než zaměstnancům, kteří daný incident reálně řeší (např. Incident Manager).

Samotný playbook by měl být uložen v zabezpečeném systému s verzováním a přístupovými právy, synchronizován do lokálního úložiště osob, které v něm hrají určitou roli a rovněž i vytištěný pro případ výpadku IT.

Závěr

Playbook je návod, podle kterého by měla být schopna postupovat i osoba, která jej nepsala ani se na jeho přípravě nepodílela. Cílem není sepsat dokonalý dokument. Kvalitní playbook je výsledkem kombinace hlubokých praktických znalostí, robustního procesního rámce, kultury a neustálého zlepšování na základě testů a proběhnuvších incidentů.

Pokud se vám líbí naše články, tak zvažte podporu naši práce – Naskenujte QR kód a přispějte libovolnou částkou.

Děkujeme!