Sicurezza di rete NIS 2 ai sensi dell'articolo 21(2)(e)
NIS 2 stabilisce che i vostri sistemi informatici e di rete debbano essere sicuri lungo acquisizione, sviluppo e manutenzione. L'articolo 21(2)(e) è dove risiede l'obbligo, il CIR (UE) 2024/2690 §6.7 e §6.8 dettagliano gli aspetti specifici della rete e il §30(2)(5) BSIG è il recepimento tedesco.
La versione breve
L'articolo 21(2)(e) è il quinto nell'elenco dei dieci obblighi di cibersicurezza ai sensi di NIS 2. Riguarda l'intero ciclo di vita dei sistemi informatici e di rete: come li acquistate, come li costruite e come li mantenete in funzione in sicurezza. Il CIR (UE) 2024/2690 §6 operativizza poi tutto ciò in diverse sottosezioni. Gli aspetti specifici della rete sono il §6.7 (sicurezza di rete) e il §6.8 (segmentazione della rete).
Il §6.7 è il più difficile da leggere dei due. Dodici azioni concrete, dal documentare l'architettura della rete all'eseguire l'igiene del DNS e mettere in sicurezza la posta elettronica. Il §6.8 è quello più semplice: suddividete la rete in zone in base a ciò che ogni zona deve fare e tenete separati il traffico di produzione, di test e amministrativo.
La Germania trasferisce lo stesso obbligo nel diritto nazionale attraverso il §30(2)(5) BSIG. Il BSI indica IT-Grundschutz NET.1 (Netze und Kommunikation) e NET.3.2 (Firewall) come via di attuazione pratica. Questa pagina percorre la direttiva, il CIR e il livello tedesco in quest'ordine.
Articolo 21(2)(e) Direttiva NIS 2 (2022/2555)
Sicurezza dell'acquisizione, dello sviluppo e della manutenzione dei sistemi informatici e di rete, compresa la gestione e la divulgazione delle vulnerabilità.
Lettera (e) dell'elenco dell'articolo 21(2). Riguarda l'intero ciclo di vita dei vostri sistemi di rete e IT, non solo lo stato di esercizio. Il CIR §6 lo scompone poi in più sottosezioni. Il §6.7 e il §6.8 sono quelle specifiche della rete.
CIR (UE) 2024/2690, Allegato §6.7 e §6.8
§6.7 Sicurezza di rete. I soggetti interessati adottano le misure appropriate per proteggere i loro sistemi informatici e di rete dalle minacce informatiche. §6.8 Segmentazione della rete. I soggetti interessati segmentano i loro sistemi […] in reti o zone in conformità con i risultati della valutazione del rischio […]; segmentano inoltre i propri sistemi e reti dai sistemi e dalle reti di terzi.
Poiché si tratta di un regolamento (non di una direttiva), è diritto dell'UE direttamente vincolante. Il §6.7 elenca dodici azioni concrete, dall'architettura di rete documentata all'igiene di DNS e posta elettronica. Il §6.8 elenca otto azioni di segmentazione, tra cui la DMZ, la separazione delle reti di amministrazione e la separazione della produzione dallo sviluppo e dal test.
§30(2)(5) BSIG (Germania)
Misure di sicurezza nell'acquisizione, nello sviluppo e nella manutenzione di sistemi, componenti e processi informatici, compresa la gestione e la divulgazione delle vulnerabilità.
La Germania copia il testo dell'UE quasi parola per parola. Il BSI indica poi IT-Grundschutz NET.1 (Netze und Kommunikation) e NET.3.2 (Firewall) come via di attuazione riconosciuta per il dettaglio dei §6.7 e §6.8.
Documentate la rete, controllate l'accesso interno
Mantenete un diagramma attuale e chiaro dell'architettura della vostra rete. Definite e applicate controlli per proteggere i domini interni da accessi non autorizzati. Bloccate connessioni e servizi non necessari. Definite controlli separati per l'accesso remoto, compreso l'accesso remoto dei fornitori. Non consentite che i sistemi di amministrazione vengano usati per altro. Disattivate o vietate esplicitamente connessioni e servizi che non utilizzate.
Igiene a livello di dispositivi, protocolli, DNS e posta elettronica
Ove appropriato, limitate l'accesso ai soli dispositivi approvati. Ammettete le connessioni dei fornitori solo dopo una richiesta di approvazione e solo per una finestra temporale definita (ad esempio, per la manutenzione). Eseguite la comunicazione tra sistemi su canali fidati, separati logicamente, crittograficamente o fisicamente, con identificazione sicura degli endpoint. Pianificate e accelerate il passaggio a protocolli moderni a livello di rete. Adottate standard di posta elettronica moderni e interoperabili per chiudere le vulnerabilità legate alla posta. Applicate pratiche consolidate di sicurezza DNS e igiene del routing per il traffico in entrata e in uscita.
Segmentate per rischio, separate la produzione da test e amministrazione
Segmentate i vostri sistemi in reti o zone usando l'output della valutazione del rischio del §2.1, non solo per comodità. Considerate i legami funzionali, logici, fisici e di ubicazione tra sistemi fidati. Concedete l'accesso alle zone in base ai requisiti di sicurezza di quella zona. Collocate i sistemi indispensabili alle operazioni o alla sicurezza all'interno di zone protette. Gestite una DMZ sulle reti di comunicazione. Limitate l'accesso alle zone e al loro interno a quanto le operazioni richiedono. Gestite una rete di amministrazione dedicata per i sistemi, separata dalla rete operativa. Mantenete i canali di amministrazione della rete separati dal resto del traffico. Mantenete i sistemi di produzione per i servizi in esercizio separati dallo sviluppo e dal test, compresi i loro backup.
Segmentate per rischio, non per comodità
Il CIR §6.8.2 collega la segmentazione al §2.1: è la valutazione del rischio a dirvi di quali zone avete bisogno e quanto rigorosi debbano essere i confini tra di esse. Una rete piatta con un unico firewall non è segmentazione. Lo sono zone basate su ciò che ogni parte dell'azienda fa effettivamente e sul rischio che comporta. Se non potete indicare la riga della valutazione del rischio che giustifica una zona, non avete segmentazione secondo la definizione dello standard.
Documentate l'architettura, mantenetela aggiornata
Il §6.7.2(a) è la prima azione dell'elenco per un motivo. Tutto il resto nel §6.7 e nel §6.8 si basa su un diagramma di rete documentato e aggiornato. I revisori guardano per primo il diagramma. Se non esiste, o è vecchio di due anni, ogni altro controllo diventa più difficile da verificare. Trattate il diagramma come un documento vivo, non come un file Visio una tantum.
BSI / §30(2)(5) BSIG / IT-Grundschutz
Il BSI indica IT-Grundschutz NET.1 (Netze und Kommunikation) per la progettazione generale della rete e NET.3.2 (Firewall) per i controlli di perimetro e segmentazione. Entrambi i Bausteine si mappano sulle azioni dei §6.7 e §6.8 quasi uno per uno. Se gestite già una rete conforme al Grundschutz, potete usare la documentazione esistente come base di evidenza.
ENISA Technical Implementation Guidance
La TIG di ENISA copre l'art. 21(2)(e) e le sottosezioni del §6 del CIR, compresa la sicurezza e la segmentazione della rete. Mappa i requisiti sui controlli ISO/IEC 27001:2022 (A.8.20 Sicurezza di rete, A.8.21 Sicurezza dei servizi di rete, A.8.22 Segregazione delle reti) e su NIST CSF 2.0 PR.IR (Technology Infrastructure Resilience). Se ne gestite già uno, potete riutilizzare i controlli.
Leggi nazionali di recepimento
Gli altri Stati membri recepiscono l'art. 21(2)(e) nelle proprie leggi (Paesi Bassi: Cyberbeveiligingswet, Austria: NISG, Belgio: NIS2-Wet). La sostanza è identica perché il dettaglio del §6 del CIR vincola direttamente i settori indicati. Ciò che differisce è con quale agenzia parlate e quale guida nazionale all'attuazione leggete insieme al CIR.
Abbiamo un firewall, quindi siamo coperti.
Un firewall è una buona cosa. Non è l'intero §6.7. Il §6.7.2(a) richiede un'architettura di rete documentata e aggiornata. Il §6.7.2(c) richiede che connessioni e servizi non utilizzati siano bloccati per impostazione predefinita. Il §6.7.2(f) richiede che i servizi non utilizzati siano esplicitamente vietati o disattivati. Il §6.8 richiede segmentazione per rischio. Un firewall senza quei quattro elementi soddisfa una riga del §6.7, non la sezione.
Produzione e test stanno sulla stessa rete perché è più facile.
Il §6.8.2(h) è esplicito: i sistemi di produzione per i servizi in esercizio devono essere separati dallo sviluppo e dal test, compresi i loro backup. Questa è una delle lacune più difficili da correggere a posteriori e una delle più facili da individuare per un revisore. Una sottorete condivisa per produzione e test non supererà la revisione del §6.8.
I nostri amministratori accedono al firewall dalle loro normali postazioni di lavoro.
Il §6.8.2(f) richiede una rete di amministrazione separata per i sistemi. Il §6.8.2(g) richiede che i canali di amministrazione siano separati dal resto del traffico di rete. Accedere a un firewall da una postazione di lavoro che esegue anche posta elettronica e un browser viola entrambi. Usate un jump host dedicato o una postazione di lavoro ad accesso privilegiato, su una VLAN di management separata.
Una tipica rete del Mittelstand da 60 a 250 persone ha già un firewall e spesso una DMZ. Le lacune dei §6.7 e §6.8 che vediamo sono di solito le stesse tre: nessun diagramma di rete documentato, nessuna rete di amministrazione dedicata e produzione e test sulla stessa sottorete. Ciascuna di queste è economica da mettere per iscritto una volta e dolorosa da correggere a posteriori.
L'ordine pragmatico: disegnate la rete attuale su una pagina, segmentate in base a ciò che ogni zona fa effettivamente (ufficio, server, DMZ, OT o produzione, amministrazione), mettete per iscritto quali connessioni sono consentite tra le zone e perché, e portate l'accesso amministrativo in una VLAN di management separata con un jump host. Questo copre il §6.7.2(a), il nucleo di segmentazione del §6.8 e la separazione della rete di amministrazione nei §6.8.2(f) e (g). Il resto è igiene che ne consegue.
Il modulo PRO sulla piattaforma contiene l'inventario dell'architettura di rete, le regole di segmentazione e il registro della rete di amministrazione. Registrate ogni zona, cosa fa, a cosa si connette e quale riga della valutazione del rischio la giustifica. Il diagramma e la logica di segmentazione risiedono in un unico posto, non divisi tra un file Visio e una pagina Confluence.
Le modifiche alla rete vengono registrate man mano che avvengono, così il §6.7.2(a) resta un documento vivo invece di un'istantanea. La traccia di audit cattura chi ha modificato cosa e quando, che è l'evidenza che un revisore vuole vedere quando chiede se la documentazione rifletta la realtà.
- Direttiva (UE) 2022/2555 (NIS 2), Articolo 21(2)(e) — eur-lex.europa.eu/eli/dir/2022/2555/oj
- Regolamento di esecuzione (UE) 2024/2690 della Commissione (CIR), Allegato §6.7 e §6.8 — eur-lex.europa.eu/eli/reg_impl/2024/2690/oj
- BSI-Gesetz (BSIG), §30(2)(5) come modificato dalla NIS2-Umsetzungs- und Cybersicherheitsstärkungsgesetz
- BSI IT-Grundschutz, Bausteine NET.1 (Netze und Kommunikation) e NET.3.2 (Firewall) — bsi.bund.de/grundschutz
- ENISA Technical Implementation Guidance per il CIR (UE) 2024/2690 (al maggio 2026)