Art. 21(2)(e) NIS 2 + CIR §6.7 + §6.8

Securitatea rețelei în NIS 2 conform Articolului 21(2)(e)

NIS 2 spune că rețelele și sistemele voastre informatice trebuie să fie sigure pe durata achiziției, dezvoltării și întreținerii. Articolul 21(2)(e) este locul în care se află obligația, CIR (UE) 2024/2690 §6.7 și §6.8 detaliază elementele specifice rețelei, iar §30(2)(5) BSIG este transpunerea germană.

Simon OrzelSimon Orzel·

Pe scurt

Articolul 21(2)(e) este al cincilea din lista celor zece obligații de securitate cibernetică din NIS 2. El acoperă întregul ciclu de viață al rețelelor și sistemelor informatice: cum le cumpărați, cum le construiți și cum le mențineți în funcțiune în siguranță. CIR (UE) 2024/2690 §6 îl operaționalizează apoi pe mai multe subsecțiuni. Elementele specifice rețelei sunt §6.7 (securitatea rețelei) și §6.8 (segmentarea rețelei).

§6.7 este cel mai greu de parcurs dintre cele două. Douăsprezece acțiuni concrete, de la documentarea arhitecturii rețelei până la igiena DNS și securizarea e-mailului. §6.8 este cel mai simplu: împărțiți rețeaua în zone în funcție de ceea ce trebuie să facă fiecare zonă și țineți traficul de producție, de test și de administrare separate.

Germania pune aceeași obligație în legislația națională prin §30(2)(5) BSIG. BSI indică IT-Grundschutz NET.1 (Netze und Kommunikation) și NET.3.2 (Firewall) drept calea practică de implementare. Această pagină parcurge directiva, CIR și stratul german, în această ordine.

Sursa juridică
Trei straturi suprapuse. Directiva. Regulamentul de punere în aplicare. Transpunerea germană. Toate trei spun același lucru, în cuvinte diferite.

Articolul 21(2)(e) Directiva NIS 2 (2022/2555)

Securitatea în achiziția, dezvoltarea și întreținerea rețelelor și sistemelor informatice, inclusiv gestionarea și divulgarea vulnerabilităților.

Litera (e) din lista Articolului 21(2). Acoperă întregul ciclu de viață al rețelei și al sistemelor IT, nu doar starea de funcționare. CIR §6 împarte apoi asta în mai multe subsecțiuni. §6.7 și §6.8 sunt cele specifice rețelei.

CIR (UE) 2024/2690, Anexa §6.7 și §6.8

§6.7 Securitatea rețelei. Entitățile vizate iau măsurile adecvate pentru a-și proteja rețelele și sistemele informatice împotriva amenințărilor cibernetice. §6.8 Segmentarea rețelei. Entitățile vizate își segmentează sistemele […] în rețele sau zone în conformitate cu rezultatele evaluării riscurilor […]; de asemenea, își segmentează propriile sisteme și rețele de sistemele și rețelele terților.

Deoarece acesta este un regulament (nu o directivă), constituie legislație UE direct obligatorie. §6.7 enumeră douăsprezece acțiuni concrete, de la arhitectura de rețea documentată până la igiena DNS și a e-mailului. §6.8 enumeră opt acțiuni de segmentare, inclusiv DMZ, separarea rețelelor de administrare și separarea producției de dezvoltare și test.

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

Măsuri de securitate în achiziția, dezvoltarea și întreținerea sistemelor, componentelor și proceselor de tehnologia informației, inclusiv managementul și divulgarea vulnerabilităților.

Germania copiază textul UE aproape cuvânt cu cuvânt. BSI indică apoi IT-Grundschutz NET.1 (Netze und Kommunikation) și NET.3.2 (Firewall) drept calea de implementare recunoscută pentru detaliile din §6.7 și §6.8.

Cele trei piese ale CIR §6.7 și §6.8
CIR împarte securitatea rețelei pe două subsecțiuni. Noi le grupăm în trei: documentația și controalele de acces din §6.7, igiena protocoalelor și a dispozitivelor din §6.7 și regulile de segmentare din §6.8.
§6.7.2(a)-(f)

Documentați rețeaua, controlați accesul intern

Mențineți o diagramă actuală și clară a arhitecturii rețelei. Definiți și aplicați controale pentru a proteja domeniile interne de accesul neautorizat. Blocați conexiunile și serviciile de care nu este nevoie. Definiți controale separate pentru accesul la distanță, inclusiv pentru accesul la distanță al furnizorilor. Nu lăsați sistemele de administrare să fie folosite pentru altceva. Dezactivați sau interziceți explicit conexiunile și serviciile pe care nu le folosiți.

§6.7.2(g)-(l)

Igienă la nivel de dispozitiv, protocol, DNS și e-mail

Acolo unde este cazul, restricționați accesul doar la dispozitivele aprobate. Permiteți conexiunile furnizorilor doar după o cerere de aprobare și doar pentru un interval de timp definit (de exemplu, întreținere). Rulați comunicarea sistem-la-sistem pe canale de încredere, separate logic, criptografic sau fizic, cu identificare sigură a punctelor terminale. Planificați și accelerați trecerea la protocoale moderne la nivel de rețea. Adoptați standarde moderne și interoperabile de e-mail pentru a închide vulnerabilitățile legate de e-mail. Aplicați practici dovedite de securitate DNS și de igienă a rutării pentru traficul de intrare și de ieșire.

§6.8

Segmentați după risc, separați producția de test și administrare

Segmentați sistemele în rețele sau zone folosind rezultatul evaluării riscurilor din §2.1, nu doar din comoditate. Luați în considerare legăturile funcționale, logice, fizice și de localizare dintre sistemele de încredere. Acordați accesul la zonă pe baza cerințelor de securitate ale acelei zone. Plasați sistemele indispensabile operațiunilor sau securității în interiorul unor zone securizate. Rulați un DMZ pe rețelele de comunicații. Restricționați accesul la și în interiorul zonelor la ceea ce au nevoie operațiunile. Rulați o rețea de administrare dedicată pentru sisteme, separată de rețeaua operațională. Țineți canalele de administrare a rețelei separate de celălalt trafic. Țineți sistemele de producție pentru serviciile live separate de dezvoltare și test, inclusiv copiile lor de rezervă.

Două reguli care modelează tot restul
Două reguli de bază stau în spatele atât al §6.7, cât și al §6.8. Ele determină dacă rețeaua voastră chiar îndeplinește standardul sau doar pare să-l îndeplinească.

Segmentați după risc, nu după comoditate

CIR §6.8.2 leagă segmentarea înapoi de §2.1: evaluarea riscurilor este cea care vă spune de ce zone aveți nevoie și cât de stricte trebuie să fie granițele dintre ele. O rețea plată cu un singur firewall nu este segmentare. Zonele bazate pe ceea ce face de fapt fiecare parte a afacerii și pe riscul pe care îl poartă sunt segmentare. Dacă nu puteți indica linia din evaluarea riscurilor care justifică o zonă, nu aveți segmentare în sensul definiției standardului.

Documentați arhitectura, mențineți-o actuală

§6.7.2(a) este prima acțiune din listă dintr-un motiv. Tot restul din §6.7 și §6.8 se bazează pe o diagramă de rețea documentată și actuală. Auditorii se uită mai întâi la diagramă. Dacă nu există sau este veche de doi ani, fiecare alt control devine mai greu de verificat. Tratați diagrama ca pe un document viu, nu ca pe un fișier Visio făcut o singură dată.

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 / §30(2)(5) BSIG / IT-Grundschutz

BSI indică IT-Grundschutz NET.1 (Netze und Kommunikation) pentru proiectarea generală a rețelei și NET.3.2 (Firewall) pentru controalele de perimetru și de segmentare. Ambele Bausteine se mapează pe acțiunile din §6.7 și §6.8 aproape unu la unu. Dacă rulați deja o rețea conformă cu Grundschutz, puteți folosi documentația existentă ca bază de probe.

În întreaga UE

Ghidul tehnic de implementare al ENISA

TIG-ul ENISA acoperă Art. 21(2)(e) și subsecțiunile CIR §6, inclusiv securitatea și segmentarea rețelei. El mapează cerințele pe controale ISO/IEC 27001:2022 (A.8.20 Securitatea rețelei, A.8.21 Securitatea serviciilor de rețea, A.8.22 Segregarea rețelelor) și pe NIST CSF 2.0 PR.IR (Reziliența infrastructurii tehnologice). Dacă rulați deja unul dintre acestea, puteți reutiliza controalele.

Alte state membre

Legi naționale de transpunere

Alte state membre transpun Art. 21(2)(e) în propriile legi (Țările de Jos: Cyberbeveiligingswet, Austria: NISG, Belgia: NIS2-Wet). Substanța este identică, deoarece detaliile din CIR §6 obligă direct sectoarele desemnate. Ceea ce diferă este cu ce agenție discutați și ce ghid național de implementare citiți alături de CIR.

Trei capcane pe care le vedem mereu
Trei replici pe care le auzim în aproape fiecare apel de pregătire a auditului. Toate trei lasă o lacună la §6.7 sau §6.8 pe care un auditor o va găsi.
  • Avem un firewall, deci suntem acoperiți.

    Un firewall este bun. Nu este tot §6.7. §6.7.2(a) cere o arhitectură de rețea documentată și actuală. §6.7.2(c) cere blocarea implicită a conexiunilor și serviciilor neutilizate. §6.7.2(f) cere ca serviciile neutilizate să fie interzise explicit sau dezactivate. §6.8 cere segmentare după risc. Un firewall fără aceste patru piese îndeplinește o singură linie din §6.7, nu secțiunea.

  • Producția și testul stau pe aceeași rețea pentru că e mai ușor.

    §6.8.2(h) este explicit: sistemele de producție pentru serviciile live trebuie separate de dezvoltare și test, inclusiv copiile lor de rezervă. Aceasta este una dintre cele mai greu de remediat lacune retroactiv și una dintre cele mai ușor de identificat de către un auditor. Un subnet comun pentru producție și test nu va supraviețui revizuirii §6.8.

  • Administratorii noștri se conectează la firewall de pe stațiile lor obișnuite de lucru.

    §6.8.2(f) cere o rețea de administrare separată pentru sisteme. §6.8.2(g) cere ca acele canale de administrare să fie separate de celălalt trafic de rețea. Conectarea la un firewall de pe o stație care rulează și e-mail și un browser încalcă ambele. Folosiți o gazdă de salt dedicată sau o stație de lucru cu acces privilegiat, pe un VLAN de management separat.

Cum fac de fapt asta operatorii reali din Mittelstand

O rețea tipică de Mittelstand, cu 60 până la 250 de persoane, are deja un firewall și adesea un DMZ. Lacunele §6.7 și §6.8 pe care le vedem sunt de obicei aceleași trei: lipsa unei diagrame de rețea documentate, lipsa unei rețele de administrare dedicate și producția și testul stând pe același subnet. Fiecare dintre acestea este ieftin de notat o singură dată și dureros de remediat ulterior.

Ordinea pragmatică: desenați rețeaua actuală pe o pagină, segmentați după ceea ce face de fapt fiecare zonă (birou, server, DMZ, OT sau producție, administrare), notați ce conexiuni sunt permise între zone și de ce și aduceți accesul de administrare într-un VLAN de management separat cu o gazdă de salt. Asta acoperă §6.7.2(a), nucleul de segmentare al §6.8 și separarea rețelei de administrare din §6.8.2(f) și (g). Restul este igienă care decurge de aici.

Cum gestionăm acest lucru pe platformă

Modulul PRO de pe platformă deține inventarul arhitecturii de rețea, regulile de segmentare și registrul rețelei de administrare. Înregistrați fiecare zonă, ce face, la ce se conectează și ce linie din evaluarea riscurilor o justifică. Diagrama și logica de segmentare se află într-un singur loc, nu împărțite între un fișier Visio și o pagină Confluence.

Modificările aduse rețelei sunt înregistrate pe măsură ce au loc, astfel încât §6.7.2(a) rămâne un document viu, nu o fotografie de moment. Pista de audit captează cine a schimbat ce și când, ceea ce constituie proba pe care un auditor vrea să o vadă când întreabă dacă documentația reflectă realitatea.

Surse
  • Directiva (UE) 2022/2555 (NIS 2), Articolul 21(2)(e). eur-lex.europa.eu/eli/dir/2022/2555/oj
  • Regulamentul de punere în aplicare al Comisiei (UE) 2024/2690 (CIR), Anexa §6.7 și §6.8. eur-lex.europa.eu/eli/reg_impl/2024/2690/oj
  • Legea BSI (BSIG), §30(2)(5) astfel cum a fost modificată prin Legea de implementare a NIS2 și de consolidare a securității cibernetice
  • BSI IT-Grundschutz, Bausteine NET.1 (Netze und Kommunikation) și NET.3.2 (Firewall). bsi.bund.de/grundschutz
  • Ghidul tehnic de implementare al ENISA pentru CIR (UE) 2024/2690 (valabil în mai 2026)
Rulați probele de securitate a rețelei fără teancul de foi de calcul
Arhitectura de rețea, regulile de segmentare și registrul rețelei de administrare pe o singură platformă, legate de evaluarea voastră a riscurilor. Gratuit, open source, fără lock-in.