Riesame delle regole firewall per ISO 27001, NIS2, DORA e GDPR
Sono le 07:42 di lunedì mattina. Il CISO di un fornitore SaaS fintech in crescita sta leggendo tre messaggi distinti.
Il primo arriva dal SOC. Una workstation di sviluppo compromessa ha tentato durante la notte di connettersi a una subnet interna di database. Il traffico è stato bloccato, ma l’analista vuole conferma che la regola firewall sia intenzionale, aggiornata e approvata.
Il secondo arriva da un grande cliente aziendale. Chiede evidenze che gli ambienti di produzione, sviluppo, aziendali e di supporto siano segmentati, che le regole firewall siano riesaminate e che le eccezioni abbiano una scadenza.
Il terzo arriva dal responsabile compliance. L’organizzazione rientra nell’ambito NIS2 come fornitore digitale importante, ha responsabilità GDPR in qualità di responsabile del trattamento e ha clienti nei servizi finanziari che richiedono evidenze sul rischio ICT in linea con DORA. Il consiglio di amministrazione vuole sapere se le stesse evidenze ISO/IEC 27001:2022 possano rispondere a tutte e tre le esigenze.
Poi arriva il riesame post-incidente. Un server di sviluppo ha rischiato di essere esposto a Internet durante una modifica notturna. Nessun dato cliente è andato perso, ma il team di analisi forense ha scoperto qualcosa di peggiore dell’errore iniziale: una regola firewall di “test temporaneo” vecchia di cinque anni consentiva ancora un ampio movimento tra sviluppo e produzione. Se un attaccante avesse ottenuto accesso, la rete avrebbe opposto poca resistenza.
È in quel momento che molte organizzazioni scoprono una verità scomoda. Possono avere firewall, VLAN, security group cloud e diagrammi, ma non hanno una governance su zone di segmentazione, titolarità delle regole, accessi temporanei, approvazioni delle modifiche, ricertificazione ed evidenze di audit.
Nel 2026, “abbiamo un firewall” non è una risposta sostenibile. Auditor, autorità di regolamentazione, clienti e assicuratori vogliono prova che le reti siano separate intenzionalmente, che il traffico sia controllato in base a esigenze aziendali, che le eccezioni rischiose siano governate e che i log dimostrino il funzionamento dei controlli.
Perché la governance dei firewall è ormai un tema da consiglio di amministrazione
La segmentazione di rete era in passato trattata come un tema tecnico di ingegneria. I team infrastrutturali erano responsabili delle VLAN, gli amministratori firewall mantenevano i set di regole, i team cloud gestivano i security group e la funzione compliance vedeva solo un diagramma durante gli audit.
Quel modello operativo non funziona più.
La direttiva NIS2 richiede agli enti essenziali e importanti di applicare misure tecniche, operative e organizzative adeguate e proporzionate per gestire i rischi per i sistemi informatici e di rete. Article 21 include politiche su analisi dei rischi, gestione degli incidenti, continuità operativa, sicurezza della supply chain, sicurezza nell’acquisizione e nella manutenzione, valutazione dell’efficacia, igiene informatica di base, controllo degli accessi e gestione degli asset. Gli organi di gestione devono approvare tali misure di gestione del rischio di cibersicurezza e vigilarne l’attuazione.
DORA si applica dal 17 gennaio 2025 a molte entità finanziarie e rende la gestione del rischio ICT una disciplina governata e documentata. Articles 5, 6 and 8 richiedono governance, un quadro per la gestione del rischio ICT e l’identificazione delle funzioni aziendali supportate dall’ICT, degli asset informativi, degli asset ICT, delle dipendenze, degli asset critici e delle interconnessioni. Articles 9, 10 and 11 riguardano protezione, prevenzione, rilevazione, risposta e ripristino. Articles 24 to 27 richiedono test di resilienza operativa digitale, inclusi test avanzati per determinati soggetti. Questo rende la segmentazione un tema di resilienza, non solo un tema di firewall.
GDPR aggiunge il livello di responsabilizzazione privacy. Article 32 richiede misure tecniche e organizzative adeguate a garantire un livello di sicurezza adeguato al rischio, incluse riservatezza, integrità, disponibilità e resilienza. Article 5(1)(f) richiede integrità e riservatezza, e Article 5(2) richiede accountability. Se i sistemi con dati personali sono raggiungibili da endpoint compromessi, reti guest o percorsi di terze parti non gestiti, un’autorità di controllo può chiedere perché quei percorsi esistessero.
ISO/IEC 27001:2022 fornisce la base del sistema di gestione che collega questi obblighi. Richiede ambito di applicazione, requisiti delle parti interessate, valutazione del rischio, trattamento del rischio, Dichiarazione di applicabilità, pianificazione e controllo operativi, responsabilità della leadership, obiettivi misurabili, informazioni documentate e miglioramento continuo. L’Allegato A, supportato dalle linee guida ISO/IEC 27002:2022, include le aree di controllo necessarie per rischio dei fornitori, servizi cloud, logging, monitoraggio, architettura sicura, separazione degli ambienti e gestione delle modifiche.
Il punto è semplice: la segmentazione di rete e il riesame delle regole firewall sono ormai evidenze di governance.
Il modello operativo Clarysec: 8.20, 8.22 e 8.32
Clarysec tratta la segmentazione e il riesame dei firewall come un unico modello operativo trasversale ai controlli ISO/IEC 27002:2022, non come attività tecniche isolate.
I tre controlli principali sono:
| Area ISO/IEC 27002:2022 | Domanda di governance | Evidenze attese dagli auditor |
|---|---|---|
| 8.20 Sicurezza della rete | Le reti sono progettate, gestite, monitorate e protette in base al rischio? | Diagrammi architetturali, standard firewall, procedure di rete sicure, log di monitoraggio, evidenze IDS/IPS, campioni di configurazione VPN e reti cloud |
| 8.22 Segregazione delle reti | Le zone sono separate per sensibilità, funzione e livello di fiducia? | Modello di zonizzazione, matrice dei flussi di dati, progettazione VLAN e subnet, confini DMZ, regole firewall inter-zona, risultati dei test di segmentazione |
| 8.32 Gestione delle modifiche | Le modifiche alle regole sono valutate, approvate, testate, registrate e riesaminate? | Ticket di modifica, valutazioni del rischio, approvazioni, piani di rollback, riesami post-implementazione, registrazioni delle modifiche di emergenza |
In Zenith Blueprint: roadmap in 30 passaggi per auditor [ZB], Clarysec colloca la sicurezza della rete nella fase Controlli in azione, passaggio 20: controlli 8.18 to 8.26. La guida formula con chiarezza la domanda centrale dell’audit:
“In sostanza, questo controllo richiede alle organizzazioni di assicurare che le reti siano sicure per architettura, non semplicemente aggiungendo firewall o antivirus in un secondo momento. Ciò significa ragionare strategicamente su segmentazione di rete, controllo degli accessi, cifratura dei dati in transito, monitoraggio e difesa in profondità. Si parte da una domanda semplice: chi e che cosa stanno comunicando, e dovrebbero farlo?”
Quella domanda, “chi e che cosa stanno comunicando, e dovrebbero farlo?”, è il miglior punto di partenza pratico per il riesame delle regole firewall. Sposta la conversazione da migliaia di voci ACL criptiche verso flussi giustificati dal business.
La stessa Zenith Blueprint indica ai team di valutare l’architettura di rete verificando che le regole firewall, le configurazioni IPS/IDS e di accesso remoto siano aggiornate e configurate in modo sicuro, e di confermare che i security group cloud, il routing e le regole VPC o di subnet corrispondano all’architettura prevista. Indica inoltre agli auditor di aspettarsi un documento di architettura della sicurezza di rete che mostri firewall, gateway VPN, zone DMZ, separazione VLAN e confini di fiducia.
Per la gestione delle modifiche, Zenith Blueprint colloca il controllo ISO/IEC 27002:2022 8.32 nella fase Controlli in azione, passaggio 21: controlli 8.27 to 8.34, ed evidenzia perché la governance dei firewall fallisce quando il controllo delle modifiche è debole:
“Questo controllo riconosce una verità difficile nell’IT: molti incidenti non sono causati da attacchi, ma da modifiche gestite male. Una regola firewall aperta in modo troppo ampio. Un’impostazione di debug lasciata abilitata. Una dipendenza dimenticata dopo una migrazione.”
È esattamente così che aperture firewall temporanee diventano percorsi di attacco permanenti.
Come si presenta una buona segmentazione di rete
Un programma maturo di segmentazione ha quattro livelli.
In primo luogo, ha un modello di zonizzazione. Le zone non sono subnet arbitrarie. Sono confini di fiducia allineati alla funzione aziendale e alla sensibilità dei dati, come DMZ esposta a Internet, tier applicativo di produzione, tier database di produzione, rete utenti aziendale, rete di gestione privilegiata, ambiente di sviluppo, ambiente di test, rete di backup, Wi‑Fi guest, zona OT o IoT e zona di accesso di terze parti.
In secondo luogo, ha una matrice dei flussi. Per ogni coppia di zone, l’organizzazione documenta origine, destinazione, protocollo, porta, applicazione, responsabile di business, proprietario del sistema, tipo di dati, giustificazione e requisito di logging consentiti.
In terzo luogo, ha la titolarità delle regole. Ogni regola firewall, regola di security group cloud o politica di perimetro definito dal software ha un proprietario, una data di scadenza o ricertificazione, un ticket di modifica collegato e una giustificazione aziendale. Le regole “any-to-any” devono essere trattate come risultanze, salvo che siano oggetto di accettazione formale del rischio, limitate nel tempo e supportate da controlli compensativi.
In quarto luogo, ha un riesame ricorrente. Il riesame significa più che esportare una base di regole firewall una volta l’anno. Include ricertificazione da parte del proprietario, confronto con il traffico osservato, rilevazione di regole inutilizzate, validazione delle eccezioni temporanee, riesame dell’esposizione a Internet, test di segmentazione e riconciliazione con l’inventario degli asset.
La Politica di sicurezza della rete [P-NS] di Clarysec definisce chiaramente l’aspettativa aziendale:
“Tutto il traffico inter-zona deve essere controllato da firewall o da soluzioni di perimetro definito dal software, con configurazioni esplicite deny by default.”
Dalla Politica aziendale, Politica di sicurezza della rete, sezione “Requisiti di governance”, clausola 5.2.
La stessa politica collega direttamente le modifiche ai firewall alla gestione delle modifiche:
“Qualsiasi modifica ai set di regole firewall, alle tabelle di routing o alle configurazioni dei security group deve seguire la Politica di gestione delle modifiche (P5) dell’organizzazione, inclusi piani di rollback e registrazione di audit.”
Dalla Politica aziendale, Politica di sicurezza della rete, sezione “Requisiti di governance”, clausola 5.4.
Per le PMI, la Politica di sicurezza della rete per PMI [P-NS-SME] di Clarysec fornisce lo stesso principio in termini operativi:
“Le regole deny by default devono essere applicate per tutte le connessioni in ingresso salvo che siano esplicitamente richieste e approvate”
Dalla Politica PMI, Politica di sicurezza della rete per PMI, sezione “Requisiti di applicazione della politica”, clausola 6.1.2.
E, specificamente per la segmentazione:
“Il traffico tra segmenti deve essere filtrato e l’accesso inter-segmento deve seguire il principio del privilegio minimo”
Dalla Politica PMI, Politica di sicurezza della rete per PMI, sezione “Requisiti di applicazione della politica”, clausola 6.2.3.
Queste clausole di policy consentono a un auditor di tracciare il percorso dal rischio al controllo, dal controllo alla regola, dalla regola all’approvazione e dall’approvazione ai log.
Un unico pacchetto di evidenze per ISO 27001, NIS2, DORA e GDPR
L’errore commesso da molti team è costruire pacchetti di evidenze separati: uno per ISO/IEC 27001:2022, uno per NIS2, uno per GDPR, uno per i clienti DORA e uno per l’assicurazione cyber.
Un approccio migliore consiste nel costruire un unico pacchetto di evidenze per la governance della segmentazione e dei firewall, mappato sui diversi quadri di riferimento.
Zenith Controls: la guida alla conformità trasversale [ZC] mappa il controllo ISO/IEC 27002:2022 8.22 Segregazione delle reti come controllo preventivo a supporto di riservatezza, integrità e disponibilità, allineato al concetto di cybersecurity Protect e alla capacità operativa di sicurezza dei sistemi e della rete. Collega 8.22 a 8.20 Sicurezza della rete, 8.21 Sicurezza dei servizi di rete, 8.7 Protezione contro il malware, 8.27 Principi di architettura e ingegneria dei sistemi sicuri e 8.31 Separazione degli ambienti di sviluppo, test e produzione.
La guida spiega così la rilevanza NIS2 della segmentazione:
“La segregazione delle reti è una risposta diretta a questi obblighi, riduce le superfici di attacco e previene il movimento laterale nei sistemi connessi in rete.”
Questa frase spiega perché i programmi di igiene informatica NIS2 non devono trattare la segmentazione come opzionale. Il contenimento del ransomware non riguarda solo la protezione degli endpoint. Riguarda la limitazione del movimento laterale quando la prevenzione fallisce.
Per GDPR, Zenith Controls mappa 8.22 ad Article 32 e al Recital 49, osservando che i diagrammi di rete e le politiche di zonizzazione diventano evidenze chiave di conformità. Per DORA, Zenith Controls mappa la sicurezza della rete e la segregazione alla gestione del rischio ICT e al contenimento degli incidenti. I test di segmentazione possono supportare le evidenze di resilienza ICT, soprattutto quando dimostrano che una compromissione in una zona non può spostarsi liberamente verso servizi finanziari critici, repository di dati personali o sistemi di gestione privilegiata.
| Evidenza | Uso per ISO/IEC 27001:2022 e ISO/IEC 27002:2022 | Uso NIS2 | Uso DORA | Uso GDPR |
|---|---|---|---|---|
| Documento di architettura della sicurezza di rete | Supporta l’ambito di applicazione del SGSI, il controllo operativo, 8.20 e 8.22 | Mostra misure tecniche per la sicurezza dei sistemi informatici e di rete | Mostra interconnessioni ICT e dipendenze dei servizi critici | Mostra i confini di protezione attorno ai sistemi con dati personali |
| Matrice di zone e flussi | Dimostra segregazione basata sul rischio e principio del privilegio minimo | Supporta igiene informatica e valutazione dell’efficacia | Supporta classificazione degli asset ICT e delle dipendenze | Supporta misure tecniche e accountability ai sensi di Article 32 |
| Registrazioni dei riesami delle regole firewall | Evidenza del monitoraggio dei controlli e del miglioramento continuo | Mostra che le misure sono riesaminate, non statiche | Supporta riesame del rischio ICT e test di resilienza | Dimostra la sicurezza continuativa del trattamento |
| Ticket di modifica per le regole firewall | Supporta 8.32 Gestione delle modifiche | Supporta manutenzione sicura e tracciabilità | Supporta modifiche ICT controllate e resilienza | Mostra che le modifiche che interessano i sistemi con dati personali sono valutate in base al rischio |
| Registro delle eccezioni | Supporta trattamento del rischio e accettazione del rischio residuo | Mostra la supervisione della direzione sulle deviazioni | Supporta tolleranza al rischio e governance | Mostra accountability per l’esposizione temporanea |
| Log del traffico inter-zona bloccato e consentito | Supporta logging, monitoraggio ed efficacia dei controlli | Supporta rilevazione e risposta agli incidenti | Supporta classificazione e segnalazione degli incidenti | Supporta valutazione della violazione e conservazione delle evidenze |
Questa tabella non è solo una mappatura di conformità. È una roadmap per la raccolta delle evidenze.
Il riesame delle regole firewall che funziona davvero
Un riesame delle regole firewall fallisce quando chiede solo: “Questa regola serve ancora?” I proprietari delle regole spesso rispondono sì perché temono di interrompere qualcosa.
Un riesame migliore pone sei domande:
- Quale servizio aziendale supporta questa regola?
- Quale proprietario dell’asset e quale proprietario delle informazioni hanno approvato il flusso?
- La destinazione è nella zona corretta per dati e funzione?
- La regola è più permissiva di quanto richieda il traffico osservato?
- Il logging è abilitato per i flussi ad alto rischio?
- La regola ha una data di riesame, una data di scadenza o una registrazione di eccezione?
La Politica di sicurezza della rete per PMI richiede un riesame periodico:
“Il fornitore di supporto IT deve condurre un riesame annuale delle regole firewall, dell’architettura di rete e delle configurazioni wireless”
Dalla Politica PMI, Politica di sicurezza della rete per PMI, sezione “Requisiti di governance”, clausola 5.6.1.
Il riesame annuale è la baseline, non il limite massimo. Le regole ad alto rischio richiedono una ricertificazione più frequente.
| Categoria di regola | Esempio | Frequenza di riesame | Aspettativa di approvazione |
|---|---|---|---|
| Inbound Internet verso produzione | API pubblica verso application gateway | Trimestrale o dopo un rilascio rilevante | Proprietario del servizio, sicurezza, autorità approvante della modifica |
| Accesso inter-zona al database di produzione | Tier applicativo verso tier database | Trimestrale | Proprietario dell’applicazione e proprietario delle informazioni |
| Accessi amministrativi | Jump server verso porte di gestione dei server | Mensile o trimestrale | Proprietario dell’infrastruttura e delegato del CISO |
| Accesso di terze parti | VPN del fornitore verso subnet di supporto | Mensile o a milestone contrattuale | Responsabile del rapporto con il fornitore e sicurezza |
| Eccezione temporanea | Accesso di emergenza durante una migrazione | Prima della scadenza, massimo 90 giorni | Responsabile del SGSI o CISO |
| Regola interna standard a basso rischio | Server di monitoraggio verso endpoint gestiti | Annuale | Proprietario del servizio |
La Politica di sicurezza della rete è esplicita sulle eccezioni:
“La richiesta deve essere riesaminata e approvata dal Responsabile del SGSI o dal CISO e registrata nel Registro delle eccezioni del SGSI, con un periodo massimo di approvazione di 90 giorni, rinnovabile previa rivalutazione.”
Dalla Politica aziendale, Politica di sicurezza della rete, sezione “Trattamento del rischio ed eccezioni”, clausola 7.3.
Per le PMI, la Politica di sicurezza della rete per PMI richiede che le richieste di eccezione includano i fatti minimi corretti:
“La richiesta deve includere giustificazione, ambito di applicazione, durata e controlli compensativi (ad es. IP allowlisting, logging)”
Dalla Politica PMI, Politica di sicurezza della rete per PMI, sezione “Trattamento del rischio ed eccezioni”, clausola 7.3.3.
Questa clausola trasforma la gestione delle eccezioni da chat informale in trattamento del rischio verificabile in audit.
Esempio pratico: rimuovere una regola rischiosa verso un database di produzione
Si supponga che un’azienda trovi la seguente regola durante il riesame:
| Campo | Valore corrente |
|---|---|
| Origine | VLAN utenti aziendale |
| Destinazione | Subnet database di produzione |
| Porta | TCP 5432 |
| Azione | Consenti |
| Commento | Accesso temporaneo per migrazione reporting |
| Creata | 14 mesi fa |
| Proprietario | Sconosciuto |
| Logging | Disabilitato |
Questa è una classica risultanza di audit. Viola il principio del privilegio minimo, non ha un proprietario chiaro, non ha scadenza, non ha una giustificazione attuale e non ha logging. Crea inoltre un’esposizione GDPR Article 32 se il database di produzione contiene dati personali dei clienti.
Il processo di remediation deve creare evidenze, non solo rimuovere una regola errata.
| Passaggio | Azione | Riferimento Clarysec | Evidenza di audit creata |
|---|---|---|---|
| 1. Mappare la regola al modello di zona | Confermare se gli utenti aziendali debbano mai raggiungere la subnet database di produzione | Zenith Blueprint, Controlli in azione, passaggio 20 | Note aggiornate di riesame dell’architettura e classificazione delle zone |
| 2. Creare o aggiornare la registrazione del flusso | Documentare origine, destinazione, porta, tipo di dati, proprietario, giustificazione e rischio | Zenith Controls, mappatura 8.22 | Voce della matrice di zone e flussi |
| 3. Aprire un ticket di modifica | Proporre la rimozione o la sostituzione con un percorso controllato per il servizio di reporting | Politica di sicurezza della rete, clausola 5.4 | Registrazione della modifica con analisi dei rischi, piano di test e piano di rollback |
| 4. Decidere il trattamento | Rimuovere la regola ampia o sostituirla con replica in sola lettura, bastion, IP allowlisting e logging | Politica di sicurezza della rete, clausola 7.3 | Decisione di trattamento del rischio o eccezione limitata nel tempo |
| 5. Abilitare il logging per i flussi approvati | Inviare gli eventi firewall inter-zona ad alto rischio al monitoraggio | Politica di logging e monitoraggio, clausola 6.1.1.6 | Registrazioni SIEM, regole di allerta e screenshot di monitoraggio |
| 6. Validare la segmentazione | Verificare che la subnet database non sia raggiungibile salvo tramite percorsi approvati | Zenith Blueprint, passaggio 20 | Risultato del test di segmentazione e chiusura della remediation |
La Politica di logging e monitoraggio [P-LM] di Clarysec include le comunicazioni esterne e i trigger delle regole firewall tra gli eventi rilevanti ai fini dei log:
“Comunicazioni esterne e trigger delle regole firewall”
Dalla Politica aziendale, Politica di logging e monitoraggio, sezione “Requisiti di applicazione della politica”, clausola 6.1.1.6.
Per le regole inter-zona ad alto rischio, i trigger firewall devono alimentare il SIEM o la piattaforma di monitoraggio, con allerte per host sorgente, volumi o finestre temporali anomali.
La politica PMI richiede anche disciplina sulle modifiche:
“Tutte le modifiche alle configurazioni di rete (regole firewall, ACL degli switch, tabelle di routing) devono seguire un processo documentato di gestione delle modifiche”
Dalla Politica PMI, Politica di sicurezza della rete per PMI, sezione “Requisiti di applicazione della politica”, clausola 6.9.1.
Una singola attività di pulizia di questa regola crea evidenze per il controllo operativo ISO/IEC 27001:2022, ISO/IEC 27002:2022 8.20, 8.22 e 8.32, igiene informatica NIS2, GDPR Article 32 e gestione del rischio ICT in linea con DORA.
Cloud, SaaS e reti ibride devono essere inclusi
La segmentazione moderna non riguarda solo VLAN e firewall fisici. Include security group AWS, network security group Azure, policy di rete Kubernetes, tabelle di routing cloud, liste di autorizzazione per l’amministrazione SaaS, endpoint privati, VPN, SD-WAN, proxy identity-aware e controlli di perimetro definito dal software.
Per un fornitore SaaS o un servizio digitale regolamentato, il riesame delle regole firewall deve includere almeno:
- Load balancer e application gateway esposti a Internet
- Security group cloud e ACL di rete
- Tabelle di routing delle subnet private
- Percorsi di peering e transit gateway
- Percorsi VPN e di amministrazione remota
- Interfacce amministrative e piani di gestione
- Ingress Kubernetes e policy di rete
- Accesso dei runner CI/CD in produzione
- Copertura dei log per flussi ad alto rischio negati e consentiti
- Accesso di supporto di terze parti e percorsi break-glass
Se un security group cloud consente traffico database in ingresso da un ampio intervallo IP aziendale, deve essere trattato come una regola firewall. Necessita di titolarità, giustificazione, approvazione, riesame, logging e scadenza.
È anche il punto in cui gli standard ISO di supporto rafforzano la narrazione. ISO/IEC 27017 supporta la chiarezza sulle responsabilità di sicurezza cloud. ISO/IEC 27033 fornisce indicazioni più approfondite su architettura della sicurezza di rete, DMZ, zone di segmentazione, filtraggio del traffico e comunicazioni sicure tra reti. ISO/IEC 27701 rafforza la governance della privacy quando dati personali identificabili si muovono tra reti. ISO/IEC 27035 supporta il contenimento degli incidenti e ISO/IEC 27005 supporta la selezione della segmentazione come trattamento del rischio per accesso non autorizzato, diffusione di malware e movimento laterale.
Come gli auditor testano lo stesso controllo in modo diverso
Uno dei punti di forza di Zenith Controls è che spiega come diverse metodologie di audit esaminano lo stesso controllo. Le evidenze possono essere riutilizzate, ma le domande cambiano.
| Prospettiva di audit | Domanda probabile | Migliore evidenza |
|---|---|---|
| Auditor ISO/IEC 27001:2022 | La segmentazione è selezionata, attuata e riesaminata in base al rischio? | Valutazione del rischio, SoA, politica di rete, diagrammi, registrazioni dei riesami |
| Auditor in stile ISO/IEC 27007 | Le regole firewall e gli schemi VLAN implementati corrispondono alla politica documentata? | Campioni di regole firewall, ACL dei router, progettazione VLAN, interviste agli amministratori |
| Approccio di audit di certificazione ISO/IEC 27006-1:2024 | I confini di rete critici sono verificati con competenze adeguate e pianificazione basata sul rischio? | Piano di audit, campionamento tecnico, evidenze dei security group cloud, risultati dei test |
| Auditor orientato a NIST | I confini e i flussi informativi sono applicati e monitorati? | Regole firewall, ACL, test di segmentazione, registrazioni di monitoraggio |
| Auditor COBIT 2019 | La sicurezza della rete è governata, monitorata e rendicontata? | Matrice di titolarità, KPI, reporting gestionale, registro dei rischi |
| Auditor ISACA ITAF | I controlli generali IT operano in modo coerente? | Ticket di modifica, approvazioni delle eccezioni, log, campioni di ricertificazione delle regole |
| Autorità di controllo GDPR | I sistemi con dati personali erano protetti da misure tecniche adeguate? | Mappe dei flussi di dati, isolamento delle zone PII, percorsi di accesso, log firewall |
| Valutatore focalizzato su DORA | La segmentazione supporta resilienza ICT e contenimento degli incidenti? | Mappa delle dipendenze degli asset ICT, flussi delle funzioni critiche, playbook degli incidenti, registrazioni dei test |
Un valutatore focalizzato su DORA può chiedere se una compromissione in un gateway di pagamento possa pivotare verso i database dei clienti. Un’autorità competente NIS2 può chiedere se un ransomware su una workstation amministrativa possa raggiungere i sistemi core di erogazione del servizio. Un’autorità GDPR può chiedere quali restrizioni a livello di rete proteggevano i sistemi che trattano dati personali. Un auditor ISO può semplicemente chiedere valutazione del rischio, SoA, politica, procedura ed evidenza che i riesami siano avvenuti.
I programmi migliori rispondono a tutte queste domande con le stesse evidenze.
Metriche che rendono visibile la segmentazione alla leadership
NIS2 e DORA spingono entrambe sulla responsabilità della direzione. ISO/IEC 27001:2022 richiede leadership, obiettivi, ruoli, risorse, reporting e miglioramento continuo. Questo significa che la segmentazione necessita di metriche comprensibili alla leadership.
Metriche di gestione utili includono:
- Percentuale di regole firewall con proprietario assegnato
- Percentuale di regole con giustificazione aziendale documentata
- Numero di regole temporanee scadute
- Numero di regole con origine, destinazione o servizio “any”
- Numero di servizi esposti a Internet per criticità
- Percentuale di flussi inter-zona ad alto rischio con logging abilitato
- Numero di modifiche firewall di emergenza per trimestre
- Percentuale di regole campionate abbinate a ticket di modifica approvati
- Numero di fallimenti dei test di segmentazione
- Tempo medio di correzione delle regole rischiose o inutilizzate
- Numero di eccezioni più vecchie di 90 giorni
- Numero di regole di accesso di terze parti riesaminate e ricertificate
La Politica di sicurezza della rete identifica l’“efficacia delle regole firewall” come considerazione di conformità e applicazione nella sezione “Applicazione e conformità”, clausola 8.2.2. Questa espressione è importante perché l’esistenza delle regole non basta. Le regole devono essere efficaci, riesaminate e allineate al rischio attuale.
Costruire il pacchetto di evidenze 2026 per la segmentazione
Un pacchetto pratico di evidenze per la segmentazione e il riesame delle regole firewall deve essere pronto prima che l’auditor lo richieda.
Come minimo, mantenere:
- Diagramma attuale dell’architettura di rete, incluse zone cloud e ibride
- Standard di classificazione delle zone, inclusi sensibilità e livello di fiducia
- Matrice dei flussi per servizi critici e sistemi con dati personali
- Export delle regole firewall e dei security group cloud
- Registro dei proprietari delle regole e della ricertificazione
- Procedura di riesame dei firewall e calendario dei riesami
- Registrazioni delle modifiche per le modifiche firewall campionate
- Registro delle eccezioni con approvazioni, scadenza e controlli compensativi
- Risultati dei test di segmentazione e registrazioni di remediation
- Evidenze di logging e monitoraggio per i flussi ad alto rischio
- Playbook degli incidenti che dimostrano il contenimento per zona
- Metriche di reporting gestionale e verbali di riunione
Mappa queste evidenze sulle clausole ISO/IEC 27001:2022 e sulle aree di controllo dell’Allegato A. Quindi fai riferimento incrociato a NIS2 Article 21, GDPR Article 32, ai requisiti DORA di gestione del rischio ICT e test, agli outcome NIST CSF 2.0 come GOVERN, PROTECT, DETECT e RESPOND, e alle pratiche di governance COBIT.
NIST CSF 2.0 è particolarmente utile come livello di comunicazione verso il consiglio di amministrazione. La sua funzione GOVERN si concentra su requisiti legali, normativi e contrattuali, propensione al rischio, ruoli, politiche e vigilanza. I suoi outcome operativi riguardano gestione della configurazione, logging, monitoraggio, protezione dei dati, risposta agli incidenti e ripristino. Questo aiuta la leadership a comprendere il rischio senza leggere le ACL firewall.
Risultanze comuni osservate da Clarysec negli audit di segmentazione
Tra SaaS, fintech, fornitori di servizi gestiti e PMI regolamentate, le stesse risultanze si presentano ripetutamente:
- Rete piatta tra endpoint utente e servizi di produzione
- Database di produzione raggiungibili da reti di sviluppo o aziendali
- Security group cloud ampi copiati da vecchi template
- Regole temporanee per fornitori senza scadenza
- Modifiche firewall effettuate fuori dal processo di modifica
- Regole senza proprietario o giustificazione aziendale
- Logging disabilitato su regole allow ad alto rischio
- Wi‑Fi guest non completamente isolato
- Interfacce amministrative raggiungibili da reti generali
- Diagrammi che non corrispondono al routing effettivo
- Nessuna evidenza del completamento dei riesami delle regole
- Nessun test di segmentazione dopo modifiche architetturali rilevanti
- Nessuna mappatura tra sistemi con dati personali e zone di rete
- Nessun reporting gestionale sull’esposizione di rete
Queste risultanze non sono solo debolezze tecniche. Indeboliscono la capacità dell’organizzazione di dimostrare igiene informatica NIS2, resilienza operativa DORA e accountability GDPR Article 32.
Dalla pulizia reattiva al controllo difendibile
La segmentazione di rete e il riesame delle regole firewall sono il punto in cui l’architettura di sicurezza incontra la realtà dell’audit. Se puoi mostrare un modello di zonizzazione basato sul rischio, flussi inter-zona controllati, modifiche firewall approvate, eccezioni limitate nel tempo, evidenze di logging e validazione periodica, puoi rispondere a un ampio insieme di domande ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST e COBIT con una narrazione coerente.
Clarysec può aiutarti a costruire questa narrazione.
Usa Zenith Blueprint: roadmap in 30 passaggi per auditor per strutturare il percorso di attuazione, in particolare Controlli in azione, passaggio 20, per sicurezza della rete e segmentazione, e passaggio 21 per gestione delle modifiche. Usa Zenith Controls: la guida alla conformità trasversale per mappare i controlli ISO/IEC 27002:2022 8.20, 8.22 e 8.32 sulle aspettative di audit NIS2, DORA, GDPR, NIST e COBIT. Ancora le tue regole operative nella Politica di sicurezza della rete, nella Politica di sicurezza della rete per PMI e nella Politica di logging e monitoraggio di Clarysec.
Il prossimo passo è semplice e ad alto valore: seleziona un servizio critico, come produzione clienti, elaborazione dei pagamenti o Identity Management, ed esegui questa settimana un riesame a campione di 10 regole. Per ogni regola, conferma proprietario, giustificazione, origine, destinazione, porta, logging, ticket di modifica e scadenza. Se non puoi dimostrare questi sette fatti, hai l’inizio del tuo piano di miglioramento della segmentazione 2026.
Frequently Asked Questions
About the Author
Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council
