Řešení incidentů podle NIS 2 podle článku 21(2)(b)
Článek 21(2)(b) je interní povinnost: detekovat, zadržet, obnovit, zdokumentovat, poučit se. Článek 23 je externí povinnost: oznámit BSI nebo svému národnímu CSIRT. Dvě různé povinnosti, často zaměňované. CIR (EU) 2024/2690 §3 tu interní rozepisuje.
Stručně
Řešení incidentů je bod (b) na seznamu deseti povinností kybernetické bezpečnosti podle článku 21(2). Jde o to, co děláte uvnitř firmy, když se něco pokazí: zachytit to, zadržet to, obnovit, zapsat, co se stalo, a poučit se z toho.
CIR (EU) 2024/2690 §3 doplňuje detail v šesti pododdílech: §3.1 písemná koncepce řešení incidentů, §3.2 monitorování a logování, §3.3 interní eskalace událostí, §3.4 klasifikace, §3.5 samotná reakce (zadržení, odstranění, obnova), §3.6 přezkum po incidentu. Pokud provozujete DNS, cloud, datové centrum, MSP nebo jiné odvětví podle přílohy CIR, váže vás to přímo.
Německo zavádí stejnou povinnost do národního práva prostřednictvím §30(2)(2) BSIG. Formulace zní "Bewältigung von Sicherheitsvorfällen", stejná slova jako ve směrnici. Tato stránka prochází směrnici, navazující nařízení EU a německou transpozici v tomto pořadí.
Článek 21(2)(b) směrnice NIS 2 (2022/2555)
Řešení incidentů.
Bod (b) na seznamu deseti opatření kybernetické bezpečnosti. Dvě slova v textu směrnice. CIR §3 mění tato dvě slova v provozní detail. Důležité: jde o interní povinnost řešení. Externí povinnost oznámit CSIRT je v článku 23 a je na samostatné stránce.
CIR (EU) 2024/2690, příloha §3
Pro účely čl. 21 odst. 2 písm. b) směrnice (EU) 2022/2555 dotčené subjekty stanoví a zavedou politiku řešení incidentů, která vymezuje role, odpovědnosti a postupy pro včasnou detekci, analýzu, zadržení nebo reakci, obnovu, jakož i dokumentaci a hlášení incidentů.
Protože jde o nařízení, je to přímo závazné právo EU. Žádná národní transpozice není potřeba. Příloha §3 rozkládá povinnost do šesti pododdílů: koncepce (§3.1), logování (§3.2), interní eskalace (§3.3), klasifikace (§3.4), reakce (§3.5), přezkum po incidentu (§3.6).
§30(2)(2) BSIG (Německo)
Bewältigung von Sicherheitsvorfällen.
Německo kopíruje znění směrnice slovo od slova. Podstata je totožná s článkem 21(2)(b). BSI pak používá stavební bloky IT-Grundschutz (zejména DER.2 "Vorfall-Bewältigung") k ukázce, jak vypadá písemná koncepce řešení incidentů v praxi.
Písemná koncepce řešení incidentů
Zapište, kdo co dělá, když se něco pokazí. Role, odpovědnosti, kroky pro detekci, analýzu, zadržení, obnovu, dokumentaci a interní hlášení. CIR §3.1.1 vyžaduje, aby koncepce existovala před incidentem, ne po něm. Řídící orgán ji musí schválit.
Monitorování a logování
Nemůžete řešit to, co nevidíte. CIR §3.2 vyjmenovává dvanáct typů událostí, které musíte logovat (pokusy o přihlášení, změny oprávnění, detekce malwaru, síťové anomálie a další). Logy musí být odolné vůči manipulaci a uchovávané dostatečně dlouho, aby podpořily analýzu. To je vrstva detekce.
Fáze reakce: zadržení, odstranění, obnova
CIR §3.5 rozděluje reakci do tří fází. Zadržení zastaví šíření incidentu. Odstranění odstraní hlavní příčinu. Obnova vrátí systémy do známého dobrého stavu. Každá fáze musí být dokumentována průběžně, aby §3.6 (přezkum po incidentu) měl s čím pracovat.
Interní řešení není externí hlášení
Článek 21(2)(b) je to, co děláte uvnitř firmy. Článek 23 je to, co sdělujete regulátorovi (24hodinové včasné varování, 72hodinové oznámení incidentu, závěrečná zpráva do jednoho měsíce pro BSI nebo váš národní CSIRT). Dvě oddělené povinnosti. Provedení hlášení nevyřeší řešení a provedení řešení nevyřeší hlášení.
Přezkum po incidentu se vrací do řízení rizik
CIR §3.6 uzavírá smyčku. Poučení z každého incidentu se vrací do rámce řízení rizik podle CIR §2. Přidávají se nová rizika, aktualizují se plány zvládání, upravují se kontroly. To je cyklus PDCA. Incident, který vyřešíte, ale nepoučíte se z něj, je práce jen napůl.
BSI / §30(2)(2) BSIG
BSI uvádí řešení incidentů v Infopakete jako druhé z deseti opatření podle článku 21(2). Německá transpozice používá stejnou formulaci jako směrnice. BSI odkazuje na stavební blok IT-Grundschutz DER.2 ("Vorfall-Bewältigung") jako na praktickou cestu. DER.2 vás provede koncepcí, playbookem, rolemi a přezkumem po incidentu.
Technical Implementation Guidance ENISA
TIG od ENISA bere CIR §3 a ukazuje, jak důkazy vypadají v praxi: písemná koncepce, playbook, záznamy ze simulací, poznámky z přezkumu po incidentu. Mapuje také §3 na zavedené kontroly v ISO/IEC 27001:2022 (čl. A.5.24 až A.5.28) a NIST CSF 2.0 (funkce Respond a Recover), takže stávající certifikace vám dává náskok.
Národní transpoziční zákony
Každý členský stát má vlastní transpoziční zákon (Nizozemsko: Cyberbeveiligingswet, Rakousko: NISG, Belgie: NIS2-Wet). Povinnost je stejná, protože směrnice stanoví jeden standard pro celou EU. Co se liší: se kterým CSIRT mluvíte ohledně hlášení podle článku 23 a jak každý národní orgán formuluje praktické pokyny.
Když se něco stane, nahlásíme to BSI, takže jsme krytí.
To pokrývá článek 23, ne článek 21(2)(b). Hlášení CSIRT je externí povinnost. Článek 21(2)(b) je ta interní: detekovat, zadržet, obnovit, zdokumentovat, přezkoumat. Obojí musí existovat. Auditor bude chtít vidět koncepci řešení incidentů (CIR §3.1) nad rámec záznamu o hlášení podle článku 23.
Playbook napíšeme, až se něco stane.
CIR §3.1.1 je výslovný: koncepce musí být "stanovena a zavedena" před incidentem. Role, odpovědnosti, postupy, vše na papíře, schválené vedením. Psát to během incidentu není řešení, je to improvizace. Auditoři nejprve kontrolují datovanou, podepsanou koncepci.
Řeší to IT tým, to stačí.
CIR §3.1.1 vyžaduje zdokumentované role a odpovědnosti. Kdo vyhlašuje incident. Kdo rozhoduje o zadržení. Kdo mluví s právním oddělením. Kdo schvaluje obnovu. Řídící orgán musí koncepci schválit. "Řeší to IT tým" není struktura, je to předpoklad.
Typická mezera u středních firem je dokumentace, ne schopnost. Detekce probíhá (někdo si všimne, IT to prošetří, problém se vyřeší). Dokumentace ne. Bez datovaného záznamu o tom, kdo co udělal, nemá auditor jak ověřit, že byl §3 dodržen. Náprava spočívá v tom, nejprve sestavit playbook, pak dvakrát ročně simulovat a poté zachytit poučení v šabloně přezkumu po incidentu.
Dvě simulace ročně jsou tím, na čem se většina provozovatelů, se kterými mluvíme, ustálí. Jedna stolní (lidé kolem stolu procházejí playbook scénářem), jedna technická (řízené obnovení ze zálohy, nácvik reakce na phishing, něco, co procvičí nástroje). Smyslem je najít mezery dříve než auditor nebo skutečný incident. Proporcionalita podle článku 21(1) vám umožňuje přizpůsobit simulaci vaší velikosti a rizikovému profilu. Neumožňuje vám je vynechat.
CIR §3 jsme do platformy zabudovali jako modul INC. Zaregistrujete incident, zachytíte klasifikaci podle §3.4, projdete fáze reakce (zadržení, odstranění, obnova) s časovými razítky a na konci provedete přezkum po incidentu. Auditní stopa zaznamenává každý krok. Žádná hromada tabulek.
Přezkum po incidentu podle §3.6 je část, kterou většina týmů vynechává. Udělali jsme z ní povinné pole, než lze incident uzavřít: co se pokazilo, co fungovalo, jaké změny se vrací do rámce rizik podle CIR §2. Hlášení podle článku 23 (24h / 72h / jeden měsíc) je samostatný modul, který používá stejný záznam o incidentu, takže fakta nepíšete dvakrát.
- Směrnice (EU) 2022/2555 (NIS 2), článek 21(2)(b). eur-lex.europa.eu/eli/dir/2022/2555/oj
- Prováděcí nařízení Komise (EU) 2024/2690 (CIR), příloha §3. eur-lex.europa.eu/eli/reg_impl/2024/2690/oj
- Zákon o BSI (BSIG), §30(2)(2) ve znění zákona o zavedení NIS2 a posílení kybernetické bezpečnosti
- Stavební blok BSI IT-Grundschutz DER.2 "Vorfall-Bewältigung". bsi.bund.de/grundschutz
- Technical Implementation Guidance ENISA pro CIR (EU) 2024/2690, mapování §3 na ISO/IEC 27001:2022 a NIST CSF 2.0