Art. 21(2)(b) NIS 2 + CIR §3.2

Jurnalizare și monitorizare NIS 2 în temeiul articolului 21(2)(b)

Jurnalizarea este stratul de vizibilitate al gestionării incidentelor. Articolul 21(2)(b) este locul unde se află obligația, CIR §3.2 enumeră cele douăsprezece tipuri de evenimente și regulile operaționale, iar Germania pune aceeași regulă în §30(2)(2) BSIG.

Simon OrzelSimon Orzel·

Pe scurt

Jurnalizarea și monitorizarea nu sunt o obligație separată în NIS 2. Ele se află în interiorul măsurii de gestionare a incidentelor de la articolul 21(2)(b). Logica este simplă: dacă nu puteți vedea ce se întâmplă în rețeaua dumneavoastră, nu puteți detecta un incident de securitate și nu îl puteți limita.

CIR (UE) 2024/2690 §3.2 completează detaliile. Enumeră douăsprezece tipuri de evenimente pe care trebuie să le jurnalizați, stabilește regulile pentru alerte și răspuns calificat, fixează o perioadă de retenție definită și cere sisteme sincronizate în timp plus monitorizare redundantă. Acesta este pragul minim pentru sectoarele enumerate în Anexa CIR.

Germania pune aceeași regulă în §30(2)(2) BSIG. Baza practică este IT-Grundschutz OPS.1.1.5 'Protokollierung' și DER.1 'Detektion'. Această pagină parcurge directiva, regulamentul UE de punere în aplicare și transpunerea germană, în această ordine.

Sursa juridică
Trei straturi. Directiva (obligatorie pentru fiecare țară a UE). Regulamentul de punere în aplicare (drept UE direct aplicabil pentru sectoarele enumerate în anexa sa). Transpunerea națională (în Germania: BSIG).

Articolul 21(2)(b) din Directiva NIS 2 (2022/2555)

Gestionarea incidentelor.

Acesta este punctul (b) de pe lista celor zece măsuri de securitate cibernetică pe care fiecare entitate esențială și importantă trebuie să le pună în aplicare. CIR §3 îl operaționalizează apoi. Jurnalizarea și monitorizarea se află în interiorul §3.2.

CIR (UE) 2024/2690, Anexa §3.2.1

Entitățile relevante stabilesc proceduri și utilizează instrumente pentru a monitoriza și a jurnaliza activitățile din rețelele și sistemele lor informatice, astfel încât evenimentele care ar putea fi considerate incidente de securitate să poată fi detectate și gestionate pentru a le limita impactul.

Întrucât acesta este un regulament (nu o directivă), este drept UE direct obligatoriu. §3.2 se împarte apoi în șapte subpuncte care acoperă tipurile de evenimente de jurnalizat, alertarea, retenția, sincronizarea timpului și redundanța. Nu este nevoie de transpunere națională.

§30(2)(2) BSIG (Germania)

Gestionarea incidentelor.

Germania copiază textul UE cuvânt cu cuvânt. Partea practică, 'cum', vine prin IT-Grundschutz: OPS.1.1.5 'Protokollierung' pentru proiectarea jurnalizării și DER.1 'Detektion' pentru partea de alertare și răspuns.

Cele trei lucruri pe care CIR §3.2 le cere efectiv
CIR 2024/2690 §3.2 împarte jurnalizarea în trei părți operaționale. Lista evenimentelor, bucla de alertare și protecția jurnalelor în sine. Aveți nevoie de toate trei.
§3.2.3

Jurnalizați cele douăsprezece tipuri de evenimente

Construiți lista pornind de la inventarul activelor dumneavoastră. Acolo unde este cazul, captați: traficul de rețea de intrare și de ieșire, modificările de utilizatori și de privilegii, accesul la sisteme și aplicații, evenimentele de autentificare, toată activitatea privilegiată și de administrare, accesul la fișiere de configurare sau de backup critice, jurnalele instrumentelor de securitate (AV, IDS, firewall), utilizarea resurselor de sistem, accesul fizic, utilizarea echipamentelor de rețea, activarea sau suspendarea jurnalelor în sine și evenimentele de mediu.

§3.2.4

Revizuire, alarmă, răspuns calificat

Colectarea jurnalelor nu este suficientă. Verificați-le cu o cadență regulată pentru tendințe neobișnuite sau nedorite. Acolo unde este cazul, stabiliți praguri. Când un prag este depășit, declanșați o alarmă automată. Și asigurați-vă că cineva calificat răspunde efectiv la timp. Stocarea fără revizuire nu înseamnă jurnalizare în temeiul §3.2.

§3.2.5 + §3.2.6

Protejare, retenție, sincronizare a timpului, redundanță

Jurnalele în sine sunt probe. Păstrați-le pentru o perioadă de retenție definită, protejați-le împotriva accesului neautorizat și a modificărilor, sincronizați în timp toate sistemele astfel încât evenimentele să poată fi corelate și rulați sistemul de monitorizare în mod redundant. Monitorizarea sistemului de monitorizare este ea însăși independentă de sistemele pe care le monitorizează.

Două reguli care modelează tot restul
Două idei stau la baza întregului text al §3.2. Ele vă arată cum să citiți lista celor douăsprezece evenimente și regulile de alertare fără a rata esențialul.

Jurnalele sunt un activ, nu un produs secundar

§3.2.5 tratează jurnalele ca pe date critice. Perioadă de retenție definită, protecție împotriva alterării, protecție împotriva accesului neautorizat. Dacă un atacator poate șterge jurnalele care arată ce a făcut, obligația de jurnalizare nu este îndeplinită. Tocmai de aceea §3.2.3(k) enumeră explicit 'activarea, dezactivarea sau suspendarea' jurnalelor ca un eveniment pe care trebuie să îl jurnalizați.

Revizuirea jurnalelor este o obligație, nu un lucru opțional

§3.2.4 cere verificări regulate pentru tendințe neobișnuite, praguri acolo unde este cazul, alarme automate la depășirea pragului și un răspuns calificat în timp util. Un SIEM la care nu se uită nimeni nu îndeplinește această cerință. Un auditor va întreba cine a revizuit ce alerte, când și ce a făcut în privința lor.

Cum aplică efectiv autoritățile naționale acest lucru
UE stabilește regula. Fiecare țară o transpune. Substanța este aceeași. Mecanica locală diferă puțin.
Germania

BSI / IT-Grundschutz OPS.1.1.5 + DER.1

BSI indică IT-Grundschutz ca rută practică. OPS.1.1.5 'Protokollierung' este locul unde se află proiectarea jurnalizării (ce se jurnalizează, retenția, protecția). DER.1 'Detektion' acoperă partea de alertare și răspuns (cadența de revizuire, regulile SIEM, gestionarea calificată). Cele două împreună se mapează pe CIR §3.2.

La nivelul UE

Ghidul tehnic de implementare al ENISA

TIG al ENISA oferă exemple concrete de probe pentru §3.2: șabloane de politici de jurnalizare, exemple de praguri de alertă, valori implicite de retenție și o mapare pe ISO/IEC 27001:2022 Anexa A (A.8.15 Jurnalizare, A.8.16 Activități de monitorizare). Dacă rulați deja ISO 27001, reutilizați majoritatea controalelor.

Alte state membre

Legile naționale de transpunere

Fiecare stat membru are propria transpunere (Țările de Jos: Cyberbeveiligingswet, Austria: NISG, Belgia: NIS2-Wet). Obligația §3.2 este aceeași deoarece CIR este direct aplicabil. Ce diferă: cu ce autoritate națională discutați și cum sunt gestionate local canalele de raportare și cadențele de audit.

Trei capcane pe care le vedem tot timpul
Trei presupuneri care apar în aproape fiecare apel de pregătire pentru audit. Toate trei creează lacune pe care un auditor le va găsi.
  • Păstrăm toate jurnalele pe veci, deci suntem acoperiți.

    §3.2.5 cere o perioadă de retenție definită, nu una infinită. Păstrarea tuturor jurnalelor pe veci este o problemă de protecție a datelor (art. 5(1)(e) GDPR, limitarea stocării) și o problemă de cost. Stabiliți o fereastră de retenție pe fiecare tip de jurnal, scrieți-o, justificați-o în raport cu profilul dumneavoastră de risc și respectați-o.

  • SIEM-ul le are, deci suntem în regulă.

    Aproape, dar nu chiar. §3.2.4 nu cere doar stocare. Cere revizuire regulată, praguri acolo unde este cazul, alarme automate la depășire și o persoană calificată care răspunde efectiv. Un SIEM care rulează fără reguli, sau cu reguli pe care nimeni nu le ajustează, nu respectă §3.2.4.

  • Jurnalizăm activitatea utilizatorilor, dar nu și activitatea de administrare.

    §3.2.3(e) este explicit: tot accesul privilegiat la sisteme și aplicații plus activitățile conturilor de administrare. Administratorii sunt utilizatorii cu cel mai mare impact din rețeaua dumneavoastră. Faptul că nu îi jurnalizați este lacuna pe care un auditor o găsește prima.

Cum fac efectiv acest lucru operatorii Mittelstand reali

Ce vedem în practică: majoritatea firmelor Mittelstand au jurnale de firewall și jurnale Active Directory. Rareori au acoperite sistematic cele douăsprezece tipuri de evenimente din §3.2.3. Accesul privilegiat, modificările fișierelor de configurare și accesul fizic sunt cele trei lacune obișnuite.

Soluția cea mai ieftină: construiți lista din §3.2.3 pornind de la inventarul activelor (RSK 2.2), trimiteți totul într-un singur loc (un depozit central de jurnale sau un SIEM mic), stabiliți praguri pe evenimentele de mare valoare și revizuiți săptămânal. Nu aveți nevoie de un SOC gestionat din prima zi. Aveți nevoie de cineva care se uită la alerte și știe ce să facă.

Cum gestionăm acest lucru pe platformă

Modulul INC acoperă strategia de jurnalizare din §3.2: ce tipuri de evenimente jurnalizați, în raport cu ce active, cu ce fereastră de retenție. Scrieți o singură dată, semnați și devine politica dumneavoastră de jurnalizare pregătită pentru audit.

Modulul EFF acoperă partea de revizuire din §3.2.4: praguri de alarmă, cadența de revizuire, probe de răspuns calificat. Semnăturile și pista de audit îi arată unui auditor că cineva s-a uitat la alerte și a acționat în privința lor. Niciun morman de fișiere de calcul. Niciun al doilea instrument.

Surse
  • 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.2. 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
  • IT-Grundschutz Kompendium, OPS.1.1.5 'Protokollierung' și DER.1 'Detektion'. bsi.bund.de/grundschutz
  • Ghidul tehnic de implementare al ENISA pentru CIR (UE) 2024/2690 (la data de mai 2026)
Rulați jurnalizarea fără mormanul de fișiere de calcul
Active, strategie de jurnalizare, retenție, alarme și probe de revizuire pe o singură platformă. Gratuit, open source, fără lock-in.