Gestionarea incidentelor NIS 2 conform articolului 21(2)(b)
Articolul 21(2)(b) este obligația internă: detectați, izolați, recuperați, documentați, învățați. Articolul 23 este obligația externă: anunțați BSI sau CSIRT-ul dumneavoastră național. Două obligații diferite, adesea confundate. CIR (UE) 2024/2690 §3 o detaliază pe cea internă.
Pe scurt
Gestionarea incidentelor este punctul (b) din lista celor zece obligații de securitate cibernetică de la articolul 21(2). Este vorba despre ce faceți în interiorul companiei când ceva nu merge bine: identificați, izolați, recuperați, consemnați ce s-a întâmplat, învățați din asta.
CIR (UE) 2024/2690 §3 completează detaliile în șase subsecțiuni: §3.1 un concept scris de gestionare a incidentelor, §3.2 monitorizare și jurnalizare, §3.3 escaladarea internă a evenimentelor, §3.4 clasificare, §3.5 răspunsul propriu-zis (izolare, eradicare, recuperare), §3.6 revizuirea post-incident. Dacă operați DNS, cloud, un centru de date, un MSP sau orice alt sector din anexa CIR, acest lucru vă obligă direct.
Germania introduce aceeași obligație în dreptul național prin §30(2)(2) BSIG. Sintagma este "Bewältigung von Sicherheitsvorfällen", aceleași cuvinte ca în directivă. Această pagină parcurge directiva, regulamentul de punere în aplicare al UE și transpunerea germană, în această ordine.
Articolul 21(2)(b) din Directiva NIS 2 (2022/2555)
Gestionarea incidentelor.
Punctul (b) din lista celor zece măsuri de securitate cibernetică. Două cuvinte în textul directivei. CIR §3 transformă aceste două cuvinte în detalii operaționale. Important: aceasta este obligația de gestionare internă. Obligația externă de a notifica CSIRT-ul se află în articolul 23 și constituie o pagină separată.
CIR (UE) 2024/2690, anexa §3
În sensul articolului 21 alineatul (2) litera (b) din Directiva (UE) 2022/2555, entitățile relevante stabilesc și pun în aplicare o politică privind gestionarea incidentelor, care definește rolurile, responsabilitățile și procedurile pentru detectarea, analiza, izolarea sau răspunsul în timp util, recuperarea, precum și documentarea și raportarea incidentelor.
Întrucât acesta este un regulament, este drept al UE direct obligatoriu. Nu este necesară nicio transpunere națională. Anexa §3 împarte obligația în șase subsecțiuni: concept (§3.1), jurnalizare (§3.2), escaladare internă (§3.3), clasificare (§3.4), răspuns (§3.5), revizuire post-incident (§3.6).
§30(2)(2) BSIG (Germania)
Bewältigung von Sicherheitsvorfällen.
Germania copiază formularea directivei cuvânt cu cuvânt. Substanța este identică cu articolul 21(2)(b). BSI folosește apoi blocurile de construcție IT-Grundschutz (în special DER.2 "Vorfall-Bewältigung") pentru a arăta cum arată în practică un concept scris de gestionare a incidentelor.
Un concept scris de gestionare a incidentelor
Consemnați cine ce face când ceva nu merge bine. Roluri, responsabilități, pașii pentru detectare, analiză, izolare, recuperare, documentare și raportare internă. CIR §3.1.1 cere ca conceptul să existe înaintea incidentului, nu după. Organul de conducere trebuie să îl aprobe.
Monitorizare și jurnalizare
Nu puteți gestiona ce nu puteți vedea. CIR §3.2 enumeră douăsprezece tipuri de evenimente pe care trebuie să le jurnalizați (tentative de autentificare, modificări de privilegii, detectări de malware, anomalii de rețea și altele). Jurnalele trebuie să fie rezistente la manipulare și păstrate suficient de mult pentru a susține analiza. Acesta este stratul de detectare.
Fazele de răspuns: izolare, eradicare, recuperare
CIR §3.5 împarte răspunsul în trei faze. Izolarea oprește propagarea incidentului. Eradicarea înlătură cauza-rădăcină. Recuperarea readuce sistemele la o stare bună cunoscută. Fiecare fază trebuie documentată pe măsură ce se desfășoară, astfel încât §3.6 (revizuirea post-incident) să aibă cu ce lucra.
Gestionarea internă nu este raportarea externă
Articolul 21(2)(b) este ce faceți în interiorul companiei. Articolul 23 este ce comunicați autorității de reglementare (avertizare timpurie în 24 de ore, notificare a incidentului în 72 de ore, raport final într-o lună către BSI sau CSIRT-ul dumneavoastră național). Două obligații separate. Efectuarea raportării nu vă eliberează de gestionare, iar efectuarea gestionării nu vă eliberează de raportare.
Revizuirea post-incident alimentează înapoi managementul riscurilor
CIR §3.6 închide bucla. Învățămintele din fiecare incident se întorc în cadrul de management al riscurilor din CIR §2. Se adaugă riscuri noi, se actualizează planurile de tratare, se ajustează controalele. Acesta este ciclul PDCA. Un incident pe care îl gestionați, dar din care nu învățați, este o treabă făcută pe jumătate.
BSI / §30(2)(2) BSIG
BSI enumeră gestionarea incidentelor în Infopakete ca a doua dintre cele zece măsuri de la articolul 21(2). Transpunerea germană folosește aceeași sintagmă ca directiva. BSI indică blocul de construcție IT-Grundschutz DER.2 ("Vorfall-Bewältigung") ca traseu practic. DER.2 vă conduce prin concept, manualul de proceduri, rolurile și revizuirea post-incident.
Ghidul tehnic de implementare ENISA
TIG-ul ENISA preia CIR §3 și vă arată cum arată dovezile în practică: conceptul scris, manualul de proceduri, evidențele simulărilor, notele de revizuire post-incident. De asemenea, mapează §3 pe controale consacrate din ISO/IEC 27001:2022 (clauzele A.5.24 până la A.5.28) și NIST CSF 2.0 (funcțiile Respond și Recover), astfel încât o certificare existentă vă oferă un avans.
Legi naționale de transpunere
Fiecare stat membru are propria lege de transpunere (Țările de Jos: Cyberbeveiligingswet, Austria: NISG, Belgia: NIS2-Wet). Obligația este aceeași deoarece directiva stabilește un singur standard la nivelul UE. Ce diferă: cu ce CSIRT comunicați pentru raportarea conform articolului 23 și cum formulează fiecare autoritate națională îndrumarea practică.
Raportăm către BSI când se întâmplă ceva, deci suntem acoperiți.
Asta acoperă articolul 23, nu articolul 21(2)(b). Raportarea către CSIRT este obligația externă. Articolul 21(2)(b) este cea internă: detectați, izolați, recuperați, documentați, revizuiți. Ambele trebuie să existe. Un auditor va cere să vadă conceptul de gestionare a incidentelor (CIR §3.1) pe lângă jurnalul de raportare conform articolului 23.
Vom scrie manualul de proceduri când se va întâmpla ceva.
CIR §3.1.1 este explicit: conceptul trebuie să fie "stabilit și pus în aplicare" înaintea incidentului. Roluri, responsabilități, proceduri, toate pe hârtie, aprobate de conducere. Scrierea lui în timpul incidentului nu este gestionare, este improvizație. Auditorii verifică mai întâi conceptul datat și semnat.
Echipa IT se ocupă de asta, e suficient.
CIR §3.1.1 cere roluri și responsabilități documentate. Cine declară un incident. Cine decide asupra izolării. Cine vorbește cu departamentul juridic. Cine aprobă recuperarea. Organul de conducere trebuie să aprobe conceptul. "Echipa IT se ocupă de asta" nu este o structură, este o presupunere.
Lacuna tipică în Mittelstand este documentarea, nu capacitatea. Detectarea se întâmplă (cineva observă, IT-ul investighează, problema se rezolvă). Documentarea nu se întâmplă. Fără evidența datată a cine ce a făcut, auditorul nu are cum să verifice că §3 a fost respectat. Soluția este să construiți mai întâi manualul de proceduri, apoi să simulați de două ori pe an, apoi să captați învățămintele în modelul de revizuire post-incident.
Două simulări pe an este ceea ce ajung să facă majoritatea practicienilor cu care vorbim. Una de tip tabletop (oameni în jurul unei mese, parcurgând manualul de proceduri printr-un scenariu), una tehnică (o restaurare controlată din copie de rezervă, un exercițiu de răspuns la phishing, ceva care pune la încercare instrumentele). Scopul este să găsiți lacunele înaintea unui auditor sau înaintea unui incident real. Proporționalitatea din articolul 21(1) vă permite să dimensionați simularea în funcție de dimensiunea și profilul dumneavoastră de risc; nu vă permite să le omiteți.
Am integrat CIR §3 în platformă sub forma modulului INC. Înregistrați un incident, captați clasificarea conform §3.4, parcurgeți fazele de răspuns (izolare, eradicare, recuperare) cu marcaje temporale și rulați revizuirea post-incident la final. Pista de audit înregistrează fiecare pas. Fără teancuri de foi de calcul.
Revizuirea post-incident din §3.6 este partea pe care majoritatea echipelor o sar. Am făcut-o un câmp obligatoriu înainte ca un incident să poată fi închis: ce a mers prost, ce a funcționat, ce schimbări sunt alimentate înapoi în cadrul de risc din CIR §2. Raportarea conform articolului 23 (24h / 72h / o lună) este un modul separat care folosește aceeași înregistrare de incident, astfel încât nu tastați faptele de două ori.
- Directiva (UE) 2022/2555 (NIS 2), articolul 21(2)(b). eur-lex.europa.eu/eli/dir/2022/2555/oj
- Regulamentul de punere în aplicare (UE) 2024/2690 al Comisiei (CIR), anexa §3. eur-lex.europa.eu/eli/reg_impl/2024/2690/oj
- Legea BSI (BSIG), §30(2)(2), astfel cum a fost modificată prin Legea de implementare a NIS2 și de consolidare a securității cibernetice
- Blocul de construcție BSI IT-Grundschutz DER.2 "Vorfall-Bewältigung". bsi.bund.de/grundschutz
- Ghidul tehnic de implementare ENISA pentru CIR (UE) 2024/2690, maparea §3 pe ISO/IEC 27001:2022 și NIST CSF 2.0