Sicurezza OT e NIS2: mappatura ISO 27001 e IEC 62443

Alle 02:17 di un lunedì, un operatore di un impianto di trattamento delle acque riceve un allarme da un sistema di dosaggio. L’alimentazione chimica è ancora entro i limiti di sicurezza, ma un PLC segnala comandi irregolari, la workstation di ingegneria mostra tentativi di accesso non riusciti da un account VPN di un fornitore e l’analista SOC di turno pone una domanda a cui nessuno vuole rispondere sotto pressione.

Si tratta di un incidente IT, di un incidente OT, di un evento di sicurezza fisica o di un incidente significativo soggetto a notifica ai sensi di NIS2?

L’impianto dispone di firewall. Ha documentazione ISO. Ha un foglio di calcolo dei fornitori. Ha persino un piano di risposta agli incidenti. Ma quel piano è stato scritto per compromissioni della posta elettronica e indisponibilità dei servizi cloud, non per un controller legacy che non può essere aggiornato con patch durante la produzione, per un fornitore che necessita di accesso remoto per ripristinare il servizio e per un’autorità di regolamentazione che si aspetta evidenze entro le tempistiche di segnalazione NIS2.

Lo stesso problema si presenta nei consigli di amministrazione. Un CISO presso un fornitore regionale di energia può disporre di un sistema di gestione della sicurezza delle informazioni certificato ISO/IEC 27001:2022 per l’IT aziendale, mentre il patrimonio di tecnologia operativa resta un intreccio di PLC, RTU, HMI, historian, workstation di ingegneria, switch industriali e percorsi di accesso dei fornitori. La domanda dell’amministratore delegato è semplice: “Siamo coperti? Puoi dimostrarlo?”

Per molte entità essenziali e importanti, la risposta onesta è scomoda. Sono coperte solo in parte. Possono dimostrarlo solo in parte. Ma la sicurezza OT NIS2 richiede più della generica conformità IT.

Richiede un modello operativo unificato che colleghi la governance ISO/IEC 27001:2022, il linguaggio dei controlli ISO/IEC 27002:2022, le pratiche di ingegneria industriale IEC 62443, le misure di gestione dei rischi di cibersicurezza previste dall’Article 21 di NIS2 e le evidenze di segnalazione degli incidenti previste dall’Article 23 di NIS2.

Questa guida costruisce esattamente quel collegamento.

Perché la sicurezza OT NIS2 è diversa dalla normale conformità IT

NIS2 si applica a molte entità pubbliche e private che forniscono servizi inclusi nell’ambito di applicazione nell’UE, comprese entità essenziali e importanti in settori quali energia, trasporti, banche, infrastrutture dei mercati finanziari, sanità, acqua potabile, acque reflue, infrastrutture digitali, gestione dei servizi ICT, pubblica amministrazione, spazio, servizi postali, gestione dei rifiuti, manifattura, chimica, alimentare, fornitori digitali e ricerca.

La direttiva richiede misure tecniche, operative e organizzative adeguate e proporzionate per gestire i rischi cyber, prevenire o ridurre al minimo l’impatto degli incidenti e proteggere la continuità dei servizi. L’Article 21 include un approccio multirischio che copre analisi dei rischi, politiche di sicurezza, gestione degli incidenti, continuità operativa, gestione delle crisi, sicurezza della catena di fornitura, acquisizione e manutenzione sicure, gestione e divulgazione delle vulnerabilità, valutazione dell’efficacia, igiene informatica, formazione, crittografia, sicurezza delle risorse umane, controllo degli accessi, gestione degli asset, MFA o autenticazione continua, comunicazioni sicure e comunicazioni di emergenza ove appropriato.

Questi requisiti suonano familiari a un team ISO/IEC 27001:2022. In OT, ciascuno di essi si comporta in modo diverso.

Una vulnerabilità in un web server può spesso essere corretta con patch entro pochi giorni. Una vulnerabilità in un controller di turbina può richiedere convalida del fornitore, una finestra di manutenzione, un riesame di sicurezza fisica e procedure operative di fallback. Un laptop può essere ricostruito. Una HMI di produzione può dipendere da un sistema operativo legacy perché l’applicazione industriale non è stata certificata per una piattaforma più recente. Un playbook SOC può indicare “isolare l’host”, mentre l’ingegnere OT risponde: “non prima di sapere se l’isolamento incide sul controllo della pressione”.

La differenza non è solo tecnica. L’IT in genere privilegia riservatezza, integrità e disponibilità. L’OT privilegia disponibilità, integrità del processo e sicurezza fisica. Un controllo di sicurezza che introduce latenza, richiede un riavvio o interrompe un processo fisico può essere inaccettabile senza approvazione ingegneristica.

NIS2 non esenta l’OT dalla gestione dei rischi di cibersicurezza. Si aspetta che l’organizzazione dimostri che i controlli sono adeguati al rischio e proporzionati alla realtà operativa.

Lo stack dei controlli: NIS2, ISO/IEC 27001:2022, ISO/IEC 27002:2022 e IEC 62443

Un programma di sicurezza OT NIS2 difendibile inizia con uno stack di controlli stratificato.

ISO/IEC 27001:2022 fornisce il sistema di gestione. Richiede all’organizzazione di definire contesto, parti interessate, obblighi normativi, ambito del SGSI, interfacce e dipendenze. Richiede inoltre leadership responsabile, una politica per la sicurezza delle informazioni, valutazione del rischio, trattamento del rischio, una Dichiarazione di Applicabilità, informazioni documentate, audit interno, riesame della direzione e miglioramento continuo.

ISO/IEC 27002:2022 fornisce il vocabolario dei controlli. Per l’OT, i controlli più importanti includono spesso sicurezza dei fornitori, gestione del rischio della catena di fornitura ICT, pianificazione degli incidenti, prontezza ICT per la continuità operativa, requisiti legali e contrattuali, gestione degli asset, controllo degli accessi, gestione delle vulnerabilità, backup, logging, monitoraggio, sicurezza della rete e segregazione delle reti.

IEC 62443 fornisce il modello di ingegneria della sicurezza industriale. Aiuta a tradurre i requisiti del sistema di gestione in pratiche OT quali zone, conduit, livelli di sicurezza, responsabilità del proprietario dell’asset, responsabilità dell’integratore di sistema, aspettative verso i fornitori di prodotto, restrizioni dell’accesso remoto, principio di minima funzionalità, gestione degli account, configurazione sicura e controlli lungo il ciclo di vita.

Clarysec utilizza questo stack perché evita due errori comuni. Primo, impedisce che l’attuazione ISO diventi troppo generica per l’OT. Secondo, impedisce che il lavoro ingegneristico IEC 62443 resti scollegato dalla responsabilità del consiglio di amministrazione, dagli obblighi di segnalazione NIS2 e dalle evidenze di audit.

La Politica di sicurezza IoT / OT di Clarysec esplicita direttamente questo collegamento:

Garantire che tutte le implementazioni siano allineate ai controlli ISO/IEC 27001 e alle linee guida settoriali applicabili (ad es. IEC 62443, ISO 27019, NIST SP 800-82).

Questa frase è importante. La politica non è solo una checklist di configurazione sicura dei dispositivi. Collega governance ISO, linee guida settoriali OT e sicurezza operativa.

Partire dall’ambito: quale servizio OT deve essere protetto?

Prima di mappare i controlli, occorre definire il servizio OT in termini aziendali e normativi.

Un responsabile di stabilimento può dire: “Gestiamo la linea di confezionamento”. Una valutazione NIS2 dovrebbe dire: “Questo processo produttivo supporta un servizio essenziale o importante e dipende da PLC, HMI, workstation di ingegneria, historian, switch industriali, accesso remoto dei fornitori, un appaltatore per la manutenzione, un flusso di analisi cloud e un servizio aziendale di identità”.

Le clausole 4.1-4.4 di ISO/IEC 27001:2022 sono utili perché obbligano l’organizzazione a identificare fattori interni ed esterni, parti interessate, requisiti legali e contrattuali, confini del SGSI, interfacce e dipendenze. Per la sicurezza OT NIS2, questo significa mappare non solo la rete della sede centrale, ma anche i sistemi industriali e le dipendenze di servizio che incidono su continuità, sicurezza fisica ed erogazione regolamentata.

NIST CSF 2.0 rafforza la stessa logica. La funzione GOVERN richiede di comprendere missione, stakeholder, dipendenze, obblighi legali e normativi, servizi critici e servizi da cui l’organizzazione dipende. Gli Organizational Profiles forniscono un metodo pratico per delimitare lo stato corrente, definire lo stato target, analizzare le lacune e produrre un piano d’azione prioritizzato.

Per un ambiente OT, Clarysec in genere parte da cinque domande:

1. Quale servizio regolamentato o critico supporta questo ambiente OT?
2. Quali asset OT, reti, flussi di dati e terze parti sono necessari per quel servizio?
3. Quali vincoli di sicurezza fisica, disponibilità e operatività incidono sui controlli di sicurezza?
4. Quali obblighi legali, contrattuali e settoriali si applicano, inclusi NIS2, GDPR, DORA ove rilevanti, contratti con i clienti e norme nazionali?
5. Quali parti dell’ambiente sono incluse nel SGSI e quali sono dipendenze esterne che richiedono controlli sui fornitori?

Molti programmi NIS2 falliscono qui. Definiscono l’ambito intorno all’IT aziendale perché è più facile inventariarlo. Auditor e autorità di regolamentazione non saranno favorevolmente impressionati se la dipendenza di servizio più critica compare solo come una voce generica chiamata “rete di fabbrica”.

Una mappatura pratica dei controlli OT NIS2

La tabella seguente mostra come trasformare i temi dell’Article 21 di NIS2 in evidenze ISO/IEC 27001:2022, ISO/IEC 27002:2022 e IEC 62443. Non sostituisce una valutazione del rischio formale, ma offre a CISO, responsabili OT e team di conformità un punto di partenza pratico.

Questa mappatura è intenzionalmente orientata alle evidenze. Ai sensi di NIS2, affermare “abbiamo la segmentazione” non è sufficiente. Occorre dimostrare perché la segmentazione è adeguata, come è implementata, come vengono approvate le eccezioni e come il disegno riduce l’impatto sul servizio regolamentato.

Segmentazione: il primo controllo OT che gli auditor testeranno

Se l’incidente delle 02:17 avesse coinvolto un attaccante in movimento da un laptop d’ufficio a una workstation di ingegneria, la prima domanda di audit sarebbe ovvia: perché quel percorso poteva esistere?

La Politica di sicurezza IoT / OT è esplicita:

I sistemi OT devono operare all’interno di reti dedicate isolate dall’IT aziendale e dai sistemi esposti a Internet.

Per ambienti più piccoli, la Politica di sicurezza dell’Internet delle cose (IoT) / tecnologia operativa (OT) - SME fornisce una base di riferimento pratica:

Tutti i dispositivi Internet of Things (IoT) e Operational Technology (OT) devono essere collocati su una rete Wi-Fi o VLAN separata

Per un operatore maturo di infrastrutture critiche, la segmentazione dovrebbe essere progettata intorno a zone e conduit OT. Gli utenti aziendali non dovrebbero accedere direttamente alle reti PLC. Le connessioni dei fornitori dovrebbero terminare in zone di accesso controllate. La replica degli historian dovrebbe utilizzare percorsi approvati. I sistemi di sicurezza dovrebbero essere isolati in base al rischio e ai requisiti ingegneristici. Le reti OT wireless dovrebbero essere giustificate, configurate in modo sicuro e monitorate.

Zenith Blueprint: roadmap in 30 fasi per auditor, nella fase Controlli in azione, fase 20, spiega il principio alla base della sicurezza di rete in ISO/IEC 27002:2022:

I sistemi di controllo industriale dovrebbero essere isolati dal traffico d’ufficio.

Avverte inoltre che la sicurezza della rete richiede architettura sicura, segmentazione, controllo degli accessi, cifratura dei dati in transito, monitoraggio e difesa in profondità.

In Zenith Controls: guida alla conformità trasversale, il controllo ISO/IEC 27002:2022 8.22, segregazione delle reti, è trattato come un controllo preventivo a supporto di riservatezza, integrità e disponibilità, allineato al concetto di cibersicurezza Protect, con la sicurezza dei sistemi e delle reti come capacità operativa e Protection come dominio di sicurezza.

Questa classificazione è utile per le evidenze NIS2 perché la segmentazione non è un diagramma decorativo. È un controllo preventivo progettato per ridurre il raggio d’impatto e preservare la continuità dei servizi essenziali.

Gestione delle vulnerabilità quando i sistemi OT non possono essere semplicemente aggiornati con patch

NIS2 richiede acquisizione, sviluppo e manutenzione sicuri dei sistemi informativi e di rete, inclusi gestione e divulgazione delle vulnerabilità. Nell’IT, la gestione delle vulnerabilità spesso significa rilevare, prioritizzare, applicare patch e verificare. L’OT aggiunge vincoli.

Una HMI critica potrebbe essere aggiornabile con patch solo durante un fermo pianificato. Un aggiornamento del firmware di un PLC potrebbe richiedere il coinvolgimento del fornitore. Un sistema certificato per la sicurezza fisica potrebbe perdere la certificazione se modificato in modo errato. Alcuni dispositivi legacy potrebbero non avere più alcun supporto del fornitore.

Zenith Blueprint, fase Controlli in azione, fase 19, fornisce la corretta logica di audit per le vulnerabilità tecniche:

Per i sistemi che non possono essere aggiornati immediatamente con patch, magari a causa di software legacy o restrizioni di indisponibilità, implementare controlli compensativi. Ciò può includere l’isolamento del sistema dietro un firewall, la limitazione degli accessi o l’aumento del monitoraggio. In tutti i casi, registrare e accettare formalmente il rischio residuo, dimostrando che la problematica non è stata dimenticata.

La base di riferimento della politica SME è analogamente pratica:

L’inventario deve essere riesaminato trimestralmente per identificare dispositivi obsoleti, non supportati o non aggiornati con patch

In Zenith Controls, il controllo ISO/IEC 27002:2022 8.8, gestione delle vulnerabilità tecniche, è mappato come controllo preventivo a supporto di riservatezza, integrità e disponibilità, allineato a Identify e Protect, con la gestione delle minacce e delle vulnerabilità come capacità operativa nei domini Governance, Ecosystem, Protection e Defense.

Un solido fascicolo delle vulnerabilità OT dovrebbe includere:

• Identificativo dell’asset, proprietario, zona e criticità
• Fonte della vulnerabilità, ad esempio avviso del fornitore, scanner, comunicazione dell’integratore o intelligence sulle minacce
• Vincoli di sicurezza fisica e disponibilità
• Fattibilità della patch e finestra di manutenzione pianificata
• Controlli compensativi, quali isolamento, liste di controllo degli accessi, servizi disabilitati o monitoraggio rafforzato
• Approvazione del proprietario del rischio e accettazione del rischio residuo
• Evidenze di verifica dopo la remediation o l’implementazione del controllo compensativo

Questo trasforma “non possiamo applicare patch” da una giustificazione debole in un trattamento del rischio verificabile in audit.

Accesso remoto dei fornitori: il punto critico tra NIS2 e IEC 62443

La maggior parte degli incidenti OT presenta in qualche punto una dimensione di terza parte. Un account di fornitore. Un laptop di un integratore. Uno strumento di manutenzione remota. Una credenziale condivisa. Un’eccezione firewall che doveva essere temporanea tre anni fa.

L’Article 21 di NIS2 include esplicitamente la sicurezza della catena di fornitura, le vulnerabilità specifiche dei fornitori, le pratiche di cibersicurezza dei fornitori e le procedure di sviluppo sicuro. Anche NIST CSF 2.0 è dettagliato su questo punto attraverso criticità del fornitore, requisiti contrattuali, due diligence, monitoraggio continuativo, coordinamento degli incidenti e clausole di uscita.

La Politica di sicurezza delle terze parti e dei fornitori - SME di Clarysec esprime il principio in modo diretto:

Ai fornitori deve essere concesso accesso solo ai sistemi e ai dati minimi necessari per svolgere la loro funzione.

Per l’OT, l’accesso minimo significa più del semplice accesso basato sui ruoli in un’applicazione. L’accesso dei fornitori dovrebbe essere:

• Pre-approvato per una finalità di manutenzione definita
• Limitato nel tempo e disabilitato per impostazione predefinita
• Protetto da MFA o autenticazione continua ove appropriato
• Instradato attraverso un jump host sicuro o una piattaforma di accesso remoto controllata
• Limitato alla zona o all’asset OT pertinente
• Registrato, monitorato e, per gli accessi ad alto rischio, soggetto a registrazione della sessione
• Riesaminato al completamento
• Coperto da obblighi contrattuali di sicurezza e di notifica degli incidenti

La Politica di sicurezza IoT / OT enterprise include un requisito dedicato per l’accesso remoto:

L’accesso remoto (per la gestione o l’assistenza da parte dei fornitori) deve:

Questa clausola fissa il punto di governance, mentre i requisiti dettagliati dovrebbero essere attuati nelle procedure di accesso, negli accordi con i fornitori, nella configurazione tecnica e nei flussi di monitoraggio.

In Zenith Controls, il controllo ISO/IEC 27002:2022 5.21, gestione della sicurezza delle informazioni nella catena di fornitura ICT, è classificato come controllo preventivo a supporto di riservatezza, integrità e disponibilità, allineato al concetto Identify, con la sicurezza dei rapporti con i fornitori come capacità operativa e Governance, Ecosystem e Protection come domini.

Per l’OT, questa mappatura aiuta a spiegare perché le evidenze dell’accesso remoto appartengono contemporaneamente ai fascicoli di rischio dei fornitori, governance delle identità, sicurezza della rete, risposta agli incidenti e continuità.

Risposta agli incidenti: il cronometro NIS2 incontra la sala controllo

Torniamo all’allarme delle 02:17. L’organizzazione deve decidere se l’evento sia significativo ai sensi di NIS2. L’Article 23 richiede la notifica senza indebito ritardo degli incidenti significativi che incidono sulla fornitura del servizio. La sequenza include un preallarme entro 24 ore dalla presa di conoscenza, una notifica dell’incidente entro 72 ore, aggiornamenti intermedi se richiesti e una relazione finale entro un mese dalla notifica dell’incidente, oppure una relazione sullo stato di avanzamento se l’incidente è ancora in corso.

In OT, la risposta agli incidenti deve rispondere a domande che i playbook IT spesso ignorano:

• Il dispositivo interessato può essere isolato senza creare un rischio per la sicurezza fisica?
• Chi ha l’autorità di fermare la produzione o passare alla modalità manuale?
• Quali log sono volatili e devono essere preservati immediatamente?
• Quale fornitore o integratore deve essere contattato?
• L’evento è doloso, accidentale, ambientale o causato da una configurazione errata?
• Potrebbe esserci un impatto transfrontaliero o sui destinatari del servizio?
• Sono coinvolti dati personali, ad esempio log dei badge, CCTV, dati dei dipendenti o registrazioni del servizio clienti?

La politica OT SME fornisce una semplice regola di escalation delle anomalie:

Qualsiasi anomalia deve essere segnalata immediatamente al Direttore generale per ulteriori azioni

Include inoltre un principio di contenimento consapevole della sicurezza fisica:

Il dispositivo deve essere disconnesso immediatamente dalla rete, quando ciò può essere fatto in sicurezza

Quelle ultime cinque parole sono critiche. La risposta OT non può copiare ciecamente le azioni di contenimento IT. “Quando ciò può essere fatto in sicurezza” dovrebbe riflettersi in runbook, matrici di escalation, formazione ed esercitazioni tabletop.

NIST CSF 2.0 si mappa bene su questo punto. Gli esiti Respond e Recover coprono triage, categorizzazione, escalation, analisi della causa radice, integrità delle evidenze, notifica agli stakeholder, contenimento, eradicazione, ripristino, verifiche di integrità dei backup e comunicazioni di ripristino.

Costruire una linea di evidenza dal rischio al controllo

Un modo pratico per evitare una conformità frammentata è costruire una linea unica di evidenza dal rischio alla normativa, al controllo e alla prova.

Scenario: un fornitore remoto di compressori richiede accesso a una workstation di ingegneria nella rete OT. La workstation può modificare la logica PLC. L’account del fornitore è sempre abilitato, condiviso da più ingegneri del fornitore e protetto solo da una password. La workstation esegue software che non può essere aggiornato fino al prossimo fermo di manutenzione.

Scrivere lo scenario di rischio nel registro dei rischi:

“Un accesso remoto non autorizzato o compromesso del fornitore alla workstation di ingegneria OT potrebbe determinare modifiche non autorizzate alla logica PLC, interruzione della produzione, impatto sulla sicurezza fisica e interruzione del servizio soggetta a notifica NIS2.”

Quindi mappare controlli e obblighi.

Il piano di trattamento del rischio dovrebbe disabilitare l’accesso permanente dei fornitori, richiedere identità nominative dei fornitori, imporre MFA, instradare l’accesso attraverso un jump server controllato, limitare l’accesso alla workstation di ingegneria, richiedere l’approvazione tramite ticket di manutenzione, registrare le sessioni privilegiate, monitorare comandi e traffico anomalo, documentare la workstation non aggiornata con patch come eccezione di vulnerabilità e testare la risposta agli incidenti per attività sospette dei fornitori.

Zenith Blueprint, fase Gestione del rischio, fase 13, fornisce la logica di tracciabilità della SoA:

Riferimenti incrociati alle normative: se determinati controlli sono implementati specificamente per conformarsi a GDPR, NIS2 o DORA, è possibile annotarlo nel Registro dei rischi (come parte della giustificazione dell’impatto del rischio) oppure nelle note della SoA.

La lezione pratica è semplice. Non mantenere le evidenze NIS2, ISO e di ingegneria OT in silos separati. Aggiungere colonne nel registro dei rischi e nella SoA per tema Article 21 NIS2, controllo ISO/IEC 27002:2022, famiglia di requisiti IEC 62443, proprietario delle evidenze e stato di audit.

Dove si inseriscono GDPR e DORA nella sicurezza OT

La sicurezza OT non riguarda sempre solo le macchine. Gli ambienti di infrastrutture critiche trattano spesso dati personali tramite CCTV, sistemi di controllo degli accessi, log dei badge, sistemi di sicurezza del personale, ticket di manutenzione, tracciamento dei veicoli, sistemi visitatori e piattaforme di servizio clienti.

GDPR richiede che i dati personali siano trattati in modo lecito, corretto e trasparente, raccolti per finalità determinate, limitati a quanto necessario, mantenuti accurati, conservati solo per il tempo necessario e protetti con misure tecniche e organizzative adeguate. Richiede inoltre accountability, ossia che il titolare del trattamento sia in grado di dimostrare la conformità.

Per l’OT, ciò significa che i log di accesso e le registrazioni di monitoraggio non devono diventare archivi di sorveglianza incontrollati. Conservazione, diritti di accesso, limitazione delle finalità e valutazione delle violazioni devono essere progettati nei processi di logging e monitoraggio.

DORA può applicarsi quando sono coinvolte entità finanziarie, o quando un fornitore terzo di servizi ICT supporta la resilienza operativa del settore finanziario. DORA copre gestione del rischio ICT, segnalazione degli incidenti, test di resilienza e rischio ICT di terze parti. Per le entità finanziarie che sono anche entità essenziali o importanti ai sensi delle norme di recepimento NIS2, DORA può fungere da regime settoriale specifico per gli obblighi sovrapposti, mentre il coordinamento con le autorità NIS2 può restare rilevante.

Si applicano le stesse discipline sulle evidenze: identificazione degli asset, protezione, rilevazione, continuità, backup, rischio di terze parti, test, formazione e supervisione della direzione.

La lente dell’audit: un controllo, più prospettive di assurance

Una solida implementazione della sicurezza OT NIS2 dovrebbe resistere a più prospettive di audit.

Per questo Clarysec considera Zenith Controls una bussola di conformità trasversale. Gli attributi dei controlli aiutano a spiegare la finalità dei controlli ufficiali ISO/IEC 27002:2022, mentre l’approccio di mappatura collega tali controlli a NIS2, NIST CSF, governance dei fornitori, continuità ed evidenze di audit.

Errori comuni nell’implementazione OT NIS2

I fallimenti più comuni della sicurezza OT sono raramente causati dalla mancanza di documenti. Sono causati da documenti che non rispecchiano lo stabilimento.

Errore 1: l’IT possiede il programma NIS2, ma l’OT possiede il rischio. Operazioni, ingegneria, sicurezza fisica e manutenzione devono essere coinvolte.

Errore 2: l’inventario degli asset si ferma ai server. Un inventario OT deve includere PLC, RTU, HMI, historian, workstation di ingegneria, switch industriali, sensori, gateway, apparati di accesso remoto e componenti gestiti dai fornitori.

Errore 3: la segmentazione esiste su un diagramma ma non nelle regole firewall. Gli auditor chiederanno evidenze di applicazione, controllo delle modifiche e monitoraggio.

Errore 4: le eccezioni relative alle vulnerabilità sono informali. I vincoli legacy sono accettabili solo se documentati, approvati, monitorati e riesaminati.

Errore 5: l’accesso dei fornitori è trattato solo come tema di fornitura. È anche un tema di controllo degli accessi, logging, monitoraggio, sicurezza della rete, risposta agli incidenti e continuità.

Errore 6: la risposta agli incidenti ignora la sicurezza fisica. I playbook OT devono definire chi può isolare dispositivi, arrestare processi, cambiare modalità o contattare le autorità di regolamentazione.

Errore 7: la segnalazione NIS2 non viene esercitata. Il processo decisionale a 24 e 72 ore dovrebbe essere testato prima di un evento reale.

Il percorso di implementazione Clarysec dalla responsabilità del consiglio di amministrazione alle evidenze OT

Un’implementazione pratica della sicurezza OT NIS2 può seguire questa sequenza:

1. Confermare l’ambito NIS2, la classificazione dell’entità e la criticità del servizio.
2. Definire l’ambito OT all’interno del SGSI, incluse interfacce e dipendenze.
3. Costruire un inventario degli asset OT e dei flussi di dati.
4. Identificare obblighi legali, contrattuali, di sicurezza fisica, privacy e settoriali.
5. Condurre workshop di valutazione del rischio specifici per l’OT con ingegneria, operazioni, IT, SOC, approvvigionamento e direzione.
6. Mappare il trattamento del rischio sui controlli ISO/IEC 27002:2022, sui temi NIS2 e sui pattern di implementazione IEC 62443.
7. Aggiornare la Dichiarazione di Applicabilità con la giustificazione OT e i proprietari delle evidenze.
8. Implementare i controlli prioritari: segmentazione, accesso dei fornitori, gestione delle vulnerabilità, monitoraggio, backup e risposta agli incidenti.
9. Aggiornare politiche e procedure, incluse sicurezza OT, sicurezza dei fornitori, accesso remoto, risposta agli incidenti e continuità operativa.
10. Eseguire esercitazioni tabletop e attività di convalida tecnica.
11. Preparare pacchetti di audit per NIS2, ISO/IEC 27001:2022, assurance dei clienti e governance interna.
12. Far confluire le risultanze nel riesame della direzione e nel miglioramento continuo.

Questo riflette il modello operativo di Zenith Blueprint, in particolare la fase 13 per il trattamento del rischio e la tracciabilità della SoA, la fase 14 per lo sviluppo delle politiche e i riferimenti incrociati normativi, la fase 19 per la gestione delle vulnerabilità e la fase 20 per la sicurezza della rete.

Lo stesso approccio utilizza le politiche Clarysec per trasformare il linguaggio dei quadri di riferimento in regole operative. La Politica di sicurezza IoT / OT enterprise richiede il riesame dell’architettura di sicurezza prima del deployment:

Tutti i nuovi dispositivi IoT/OT devono essere sottoposti a un Riesame dell’architettura di sicurezza prima del deployment. Questo riesame deve convalidare:

Dichiara inoltre:

Tutto il traffico all’interno e tra le reti IoT/OT deve essere monitorato continuativamente mediante:

Queste clausole creano ancoraggi di governance. Le evidenze di implementazione possono includere allarmi IDS OT, log firewall, correlazione SIEM, profili di traffico di baseline, ticket di anomalie e registrazioni di risposta.

Come si presentano buone evidenze OT NIS2

Un pacchetto di evidenze OT NIS2 dovrebbe essere sufficientemente pratico per gli ingegneri e sufficientemente strutturato per gli auditor.

Per la segmentazione, includere architettura approvata, diagrammi di zone e conduit, esportazioni delle regole firewall, registrazioni delle modifiche, riesami periodici delle regole, registrazioni delle eccezioni e allarmi di monitoraggio.

Per l’accesso dei fornitori, includere valutazione della criticità del fornitore, clausole contrattuali, procedura di accesso approvata, account nominativi, evidenze MFA, log degli accessi, registrazioni delle sessioni, riesame periodico degli accessi e registrazioni di offboarding.

Per la gestione delle vulnerabilità, includere inventario, fonti di avviso, output di discovery passiva, ticket di vulnerabilità, piani di patch, controlli compensativi, accettazione del rischio ed evidenze di chiusura.

Per la risposta agli incidenti, includere playbook, contatti di escalation, albero decisionale per la segnalazione NIS2, risultati tabletop, ticket degli incidenti, bozze di notifica all’autorità, regole di gestione delle evidenze e lezioni apprese.

Per la continuità, includere strategia di backup OT, backup offline o protetti, risultati dei test di ripristino, elenco dei ricambi critici, procedure operative manuali, priorità di ripristino e piani di comunicazione di crisi.

Per la governance, includere approvazione del consiglio di amministrazione o della direzione, assegnazioni dei ruoli, registrazioni della formazione, risultati dell’audit interno, KPI, verbali di riesame dei rischi e decisioni del riesame della direzione.

Questo modello di evidenze si allinea a ISO/IEC 27001:2022 perché supporta trattamento del rischio, informazioni documentate, valutazione delle prestazioni e miglioramento continuo. Si allinea a NIS2 perché dimostra misure adeguate e proporzionate. Si allinea a IEC 62443 perché può essere tracciato verso l’architettura OT e i controlli ingegneristici.

Trasformare il programma di sicurezza OT in preparazione NIS2 verificabile in audit

Se il tuo ambiente OT supporta un servizio critico o regolamentato, attendere che un’autorità di regolamentazione, un cliente o un incidente esponga le lacune è la strategia sbagliata.

Inizia con un caso d’uso ad alto impatto: accesso remoto dei fornitori a una zona OT critica, gestione delle vulnerabilità per asset industriali non supportati, oppure segmentazione tra IT aziendale e OT. Costruisci lo scenario di rischio, mappalo sull’Article 21 di NIS2, seleziona i controlli ISO/IEC 27002:2022, traducili in pattern di implementazione IEC 62443 e raccogli le evidenze.

Clarysec può aiutarti ad accelerare questo lavoro con Zenith Blueprint, Zenith Controls, la Politica di sicurezza IoT / OT, la Politica di sicurezza dell’Internet delle cose (IoT) / tecnologia operativa (OT) - SME e la Politica di sicurezza delle terze parti e dei fornitori - SME.

Prossima azione: scegli un servizio OT, mappa i relativi asset e dipendenze e crea questa settimana una linea di evidenza dal rischio al controllo. Se vuoi un percorso di implementazione strutturato, la roadmap in 30 fasi di Clarysec e il toolkit di conformità trasversale possono trasformare quella prima linea in un programma completo di sicurezza OT NIS2.