Představte si, že v pátek odpoledne váš IT tým zjistí, že firemní servery jsou zašifrovány ransomwarem. Útočník požaduje výkupné. Zálohy jsou poškozeny. Systémy stojí. Co uděláte jako první? Kdo rozhoduje? Kdo koho kontaktuje? Kdy a jak to oznámíte zákazníkům a regulátorům?
Pokud na tyto otázky nemáte písemně odpovědi připravené dopředu, vaše firma nemá Incident Response plán. A to je vážný problém — nejen bezpečnostní, ale i právní. Průzkumy konzistentně ukazují, že organizace s připraveným IR plánem snižují průměrné náklady na bezpečnostní incident o více než 50 % oproti organizacím bez plánu.
Proč musí plán existovat předem
Při kybernetickém incidentu panuje chaos: systémy nefungují, zaměstnanci jsou vystrašení, vedení tlačí na rychlé řešení a zákazníci volají. V takovém prostředí není čas vymýšlet postupy, hledat kontakty a diskutovat o odpovědnostech. Každá minuta zdržení prodlužuje dobu výpadku a zvyšuje škody.
IR plán je základní dokument, který definuje, kdo co dělá a v jakém pořadí — ještě předtím, než k incidentu dojde. Vytváří se v klidu, promyšleně a testuje se pravidelně prostřednictvím cvičení (tzv. tabletop exercise). Teprve pak má hodnotu.
NIS2 a povinnost hlášení incidentů
Pro firmy podléhající směrnici NIS2 (zákon o kybernetické bezpečnosti) má IR plán i regulatorní rozměr. NIS2 ukládá tzv. povinnost hlášení: závažný kybernetický incident musí být nahlášen NÚKIB do 24 hodin od jeho zjištění (předběžné hlášení) a podrobná zpráva pak do 72 hodin. Firmy zpracovávající osobní údaje mají navíc povinnost hlásit relevantní incidenty ÚOOÚ do 72 hodin dle GDPR.
Bez IR plánu, který tyto lhůty a postupy zakotvuje, je dodržení zákonných povinností v chaosu incidentu téměř nemožné — s rizikem sankcí nad rámec škod způsobených samotným útokem.
Šest fází Incident Response
Standardní IR framework (vycházející z metodiky NIST SP 800-61) definuje šest fází. Plán musí pokrýt všechny z nich.
1. Příprava (Preparation)
Přípravná fáze zahrnuje vše, co se dělá před incidentem: sestavení IR týmu a definice rolí, vytvoření kontaktního seznamu (interní tým, externí forenzní specialisté, právníci, pojišťovna, regulátoři, PR), nastavení komunikačních kanálů pro případ výpadku primárních systémů, nákup a příprava nástrojů pro analýzu, pravidelná cvičení a testování plánu.
Do přípravy patří i technická opatření, která incidentu předchází nebo zjednodušují reakci: monitoring a logování, zálohy, EDR/SIEM nástroje, síťová segmentace. Příprava je investice, která se vrátí v momentě krize.
2. Identifikace (Identification)
Identifikace znamená rozpoznat, že incident nastává nebo nastal. Zdroje detekcí mohou být různé: upozornění ze SIEM nebo EDR, hlášení zaměstnance, upozornění externího partnera, nebo bohužel — oznámení útočníka. Klíčové otázky v této fázi: Co přesně se děje? Kdy to začalo? Které systémy jsou postiženy? Je útok stále aktivní?
Výsledkem identifikace je prvotní klasifikace incidentu podle závažnosti — od bezpečnostní události (podezřelá aktivita) přes incident (potvrzené narušení) po krizi (výpadek kritických systémů nebo únik citlivých dat).
3. Omezení (Containment)
Cílem containmentu je zastavit šíření incidentu a omezit škody. Krátkodobý containment zahrnuje okamžitá opatření — izolaci postižených systémů, zablokování kompromitovaných účtů, zastavení podezřelé síťové komunikace. Dlouhodobý containment pak zahrnuje přechod na záložní systémy, dočasná omezení přístupu a přípravu prostředí pro obnovu.
Při containmentu je důležité zachovat forenzní důkazy — ne mazat logy, ne vypínat stroje bez konzultace s forenzním specialistou. Tyto důkazy budou potřeba pro analýzu příčin, právní řízení a regulatorní zprávy.
4. Odstranění (Eradication)
Po omezení incidentu se odstraňuje příčina — malware ze systémů, backdoor zanechané útočníkem, kompromitované účty, zneužité zranitelnosti. Eradikace musí být důkladná — neúplné odstranění znamená riziko opakovaného incidentu ze stejné příčiny. Součástí eradikace je i analýza, jak útočník vstoupil, a záplatování nebo rekonfigurace, která vstup umožnila.
5. Obnova (Recovery)
Recovery zahrnuje obnovení systémů do produkčního provozu — ze záloh, z čistých instalací nebo z forenzně ověřených systémů. Obnova probíhá postupně a každý systém je před opětovným zapojením do sítě ověřován. Monitorování po obnovení je zesíleno — útočníci se někdy vrátí a zkusí opakovaný útok, jakmile uvidí, že systémy jsou znovu online.
6. Poučení (Lessons Learned)
Poslední a pro mnohé firmy nejpodceňovanější fáze. Do 2 týdnů po incidentu by měl IR tým provést retrospektivu: co se stalo, jak útočník vstoupil, co fungovalo dobře, co selhalo, jak zlepšit plán a technická opatření. Výsledky se dokumentují a implementují — jinak je incident promarněnou příležitostí ke zlepšení.
Co IR plán musí obsahovat
Dobrý IR plán je živý dokument, ne archivovaný PDF. Musí být dostupný i při výpadku firemních systémů (tištěná kopie, offline úložiště). Klíčové součásti:
- IR tým a role: kdo je v týmu, kdo je vedoucí, kdo ho zastupuje, jaké má kdo kompetence.
- Kontaktní seznam: jména, telefony, e-maily — interní i externí (forenzní firma, právníci, pojišťovna, NÚKIB, ÚOOÚ, ČTÚ pro telco, Policie ČR).
- Klasifikace incidentů a eskalační matice — kdo se volá při jaké závažnosti.
- Postupy pro konkrétní typy incidentů — ransomware, únik dat, DDoS, kompromitace e-mailu, insider threat.
- Komunikační šablony — pro interní komunikaci, zákazníky, média a regulátory.
- Lhůty pro hlášení regulátorům dle NIS2 a GDPR.
- Přehled aktiv — co kde běží, kde jsou zálohy, jak se obnovuje.
Pokud vaše firma nemá IR plán nebo si nejste jisti, zda stávající plán obstojí při skutečném incidentu, kontaktujte tým SecureOn.cz. Nabízíme tvorbu IR plánů, tabletop cvičení i 24/7 Incident Response podporu pro případ, kdy k incidentu skutečně dojde. Více o našich službách reakce na incidenty najdete na secureon.cz.