NIS2 e firewall: cosa deve dimostrare davvero una PMI

La direttiva NIS2 viene spesso trasformata in una lista di prodotti da comprare: firewall, EDR, SIEM, MFA. È una lettura comoda, ma sbagliata. Il D.Lgs. 138/2024, che recepisce NIS2 in Italia, non dice che una PMI è conforme perché installa un firewall specifico. Dice che i soggetti essenziali e importanti devono adottare misure tecniche, operative e organizzative adeguate e proporzionate al rischio.

Il firewall resta centrale, ma cambia ruolo. Non è più solo il dispositivo che blocca porte. Diventa una evidenza tecnica di governo del rischio: mostra come l'azienda separa le reti, protegge gli accessi amministrativi, controlla i flussi, registra gli eventi e riesamina le eccezioni.

Il firewall non è la conformità

L'articolo 24 del D.Lgs. 138/2024 elenca gli elementi minimi delle misure di gestione del rischio: analisi dei rischi, gestione degli incidenti, continuità operativa, supply chain, sicurezza nello sviluppo e manutenzione, verifica dell'efficacia, formazione, crittografia, controllo degli accessi, gestione degli asset e autenticazione a più fattori.

Dentro questo quadro il firewall copre solo una parte. Serve a rendere visibili e controllabili alcuni pezzi del sistema:

• segmentazione fra reti con livelli di fiducia diversi;
• controllo dei flussi fra internet, DMZ, rete interna, sistemi critici e backup;
• protezione degli accessi amministrativi;
• logging e rilevamento di traffico anomalo;
• tracciabilità delle eccezioni e delle modifiche.

Questo è il punto che un manager dovrebbe capire: non basta dire "abbiamo il firewall". Bisogna poter spiegare cosa protegge, da quali rischi, con quali regole e con quali evidenze.

Gli errori che vedo più spesso

Il primo errore è l'interfaccia di gestione raggiungibile da internet. SSH o HTTPS esposti sulla WAN, magari su porta non standard, non sono una misura di sicurezza. Sono una superficie d'attacco. L'amministrazione deve avvenire dalla rete interna o da VPN, con autenticazione a più fattori e utenze individuali.

Il secondo errore è la rete piatta. Se postazioni, server, backup, stampanti, sistemi gestionali e servizi esposti stanno nella stessa zona, il firewall sta proteggendo solo il perimetro esterno. Una compromissione interna può muoversi lateralmente senza attraversare controlli seri.

Il terzo errore è il firewall senza storia. Regole create anni prima, nessuna descrizione, nessun proprietario, nessun ticket collegato, nessun riesame. In un audit o in un incidente, una regola non commentata è una domanda aperta: perché esiste? chi l'ha chiesta? serve ancora?

Requisiti tecnici da tradurre in configurazione

Una configurazione difendibile parte da quattro decisioni.

1. Zone di rete esplicite. Al minimo: WAN, LAN, DMZ, rete amministrativa, rete backup. Se ci sono sistemi industriali, dati sanitari, ambienti di sviluppo o database critici, meritano zone dedicate. La DMZ non deve poter iniziare connessioni verso la LAN salvo eccezioni documentate.

2. Deny by default fra zone. Il traffico non passa perché "si è sempre fatto così". Passa se c'è una ragione. Ogni apertura fra zone deve indicare sorgente, destinazione, porta, servizio, proprietario e motivazione.

3. Accesso amministrativo blindato. Nessun pannello di gestione sulla WAN. VPN con MFA, account nominativi, log degli accessi, privilegi minimi. Gli account condivisi sono comodi fino al primo incidente: poi impediscono di capire chi ha fatto cosa.

4. Logging utile, non solo attivo. Il log deve finire su un sistema esterno al firewall, con retention definita, protezione da modifica non autorizzata e una procedura di revisione. NIS2 non chiede log per bellezza: chiede capacità di rilevare, gestire e notificare incidenti significativi.

IDS, IPS e GeoIP: utili, ma non magici

Un IDS/IPS come Suricata o un sistema equivalente può essere utile per riconoscere pattern di attacco, ma va trattato come un controllo da gestire, non come una spunta. Prima osservi, poi blocchi. Un IPS messo subito in blocco su regole non calibrate genera falsi positivi, disservizi e alla fine viene disattivato.

Il GeoIP ha lo stesso limite. Bloccare traffico da paesi non pertinenti può ridurre scansioni e tentativi opportunistici, ma non sostituisce patching, MFA, segmentazione e hardening. Inoltre va applicato con criterio: spesso ha senso in ingresso su servizi esposti, molto meno in uscita, dove può rompere CDN, servizi cloud o fornitori legittimi.

La regola pratica: ogni controllo deve avere un motivo, un perimetro e un riesame. Se non riesci a spiegare perché è attivo, non è governance: è accumulo.

pfSense e OPNsense sotto NIS2

Soluzioni open source come pfSense e OPNsense possono supportare bene un percorso NIS2, soprattutto in PMI con infrastrutture sobrie e bisogno di controllo diretto. Ma non "rendono conformi" da sole.

Per essere difendibile, una configurazione deve avere almeno:

• regole commentate e ordinate per zona;
• backup della configurazione dopo modifiche rilevanti;
• log inviati a un sistema esterno;
• aggiornamenti pianificati di sistema e pacchetti;
• VPN con MFA per l'accesso remoto;
• revisione periodica delle regole e delle eccezioni;
• evidenze dei test, inclusi restore della configurazione e verifica dei log.

La differenza fra un firewall installato e un firewall governato sta qui. Il primo funziona finché funziona. Il secondo lascia tracce, consente verifiche e riduce il tempo necessario per capire cosa è successo.

Cosa chiedere in un audit interno

Prima di parlare di tecnologia, farei queste domande:

Domanda	Evidenza attesa
Quali zone di rete esistono e perché?	Diagramma aggiornato, VLAN/interfacce, elenco sistemi per zona
Chi può amministrare il firewall?	Utenti nominativi, MFA, log accessi, procedura di revoca
Ogni regola ha una motivazione?	Description, ticket o registro modifiche, proprietario della richiesta
Le eccezioni sono riesaminate?	Verbale o registro di revisione periodica
I log sono utilizzabili dopo un incidente?	Invio a syslog/SIEM, retention definita, test di ricerca evento
La configurazione è ripristinabile?	Backup datati e test di restore della configurazione

Queste non sono domande da consulente. Sono le domande che separano un controllo tecnico da un controllo dimostrabile.

Fonti principali

• D.Lgs. 138/2024, art. 23 - organi di amministrazione e direttivi
• D.Lgs. 138/2024, art. 24 - misure di gestione dei rischi
• D.Lgs. 138/2024, art. 25 - notifica degli incidenti
• ACN - Portale NIS e specifiche di base

Il firewall, in ogni caso, resta un tassello. L'adeguamento completo a NIS2 comprende governance, incident management, supply chain, continuità operativa e verifica dell'efficacia: il quadro d'insieme è nella checklist di adeguamento NIS2 per le PMI.