NIS2 e ambienti OT: verifica tecnica e penetration test

La Direttiva NIS2 non riguarda solo governance, policy e procedure. Per aziende industriali, utility, operatori energetici, trasporti, sanità, manifattura critica e fornitori della supply chain, la domanda concreta è un’altra: come si dimostra che l’ambiente OT è davvero sotto controllo?

La Direttiva (UE) 2022/2555 chiede ai soggetti essenziali e importanti di adottare misure tecniche, operative e organizzative adeguate e proporzionate per gestire i rischi cyber sui sistemi informativi e di rete. L’articolo 21 elenca esplicitamente: gestione del rischio, sicurezza della supply chain, gestione degli incidenti, business continuity, vulnerability handling, controllo degli accessi, asset management, crittografia, formazione e autenticazione multifattore dove appropriata.

In Italia la direttiva è stata recepita con il D.Lgs. 4 settembre 2024, n. 138, in vigore dal 16 ottobre 2024. L’Agenzia per la cybersicurezza nazionale è l’Autorità competente NIS.

Per gli ambienti OT questo significa una cosa precisa: non basta avere una policy di sicurezza IT. Occorre verificare reti industriali, accessi remoti, segmentazione, account fornitori, PLC, HMI, SCADA, gateway, sistemi di telemetria e interconnessioni IT/OT. ISGroup interviene su questa parte come partner tecnico-offensivo, con penetration test OT, security assessment, vulnerability assessment controllato, threat modeling, reverse engineering, firmware analysis e security auditing.

Perché NIS2 riguarda anche l’OT

La NIS2 amplia il perimetro rispetto alla precedente direttiva: secondo ACN il campo di applicazione copre 18 settori, di cui 11 altamente critici e 7 critici, con oltre 80 tipologie di soggetti distinti tra essenziali e importanti. Molti di questi settori hanno una forte componente OT: energia, trasporti, acqua potabile, acque reflue, sanità, infrastrutture digitali, gestione servizi ICT, spazio, fabbricazione di prodotti critici, chimica, alimentare, manifattura e utility.

Il problema è che l’OT spesso non viene percepito come “sistema informativo”. Nei fatti lo è: PLC, HMI, SCADA, DCS, historian, engineering workstation, gateway industriali, accessi remoti e piattaforme di manutenzione sono sistemi digitali usati per attività operative critiche. Se una compromissione cyber può fermare una linea, alterare una configurazione, manipolare telemetria o interrompere un servizio essenziale, l’OT rientra nel cuore del rischio NIS2.

Dal requisito organizzativo al controllo tecnico

La NIS2 opera su tre livelli: governance (responsabilità, approvazione delle misure, formazione), gestione del rischio (misure tecniche, operative e organizzative) e notifica e risposta agli incidenti (capacità di rilevare, valutare, comunicare e mitigare). L’articolo 20 della Direttiva prevede che gli organi di gestione approvino le misure di risk management, ne supervisionino l’implementazione e possano essere ritenuti responsabili per violazioni.

In Italia, ACN distingue gli obblighi tra organi di amministrazione e direttivi, gestione dei rischi per la sicurezza informatica e notifiche di incidente, collegati agli articoli 23, 24 e 25 del decreto. Questo non significa che il management debba diventare tecnico OT, ma non può limitarsi a dichiarare che “la sicurezza è presidiata”. Serve evidenza, e nell’OT l’evidenza è una verifica tecnica.

Perché l’OT è il punto debole di molti percorsi NIS2

Molte aziende sono più mature sulla sicurezza IT che sulla sicurezza OT. Hanno EDR sui client, firewall perimetrali, procedure di backup, MFA sugli account cloud e vulnerability scan sui server. L’ambiente industriale, però, resta spesso fragile: reti OT piatte, PLC e HMI raggiungibili da segmenti non necessari, accessi remoti permanenti dei fornitori, VPN condivise, account tecnici non nominali, password deboli o mai ruotate, workstation di engineering non presidiate, protocolli industriali senza autenticazione, firmware obsoleto, asset inventory incompleta, regole firewall “temporanee” mai rimosse e backup non testati.

Il rischio concreto è trattare NIS2 come un progetto IT, lasciando fuori la parte che sostiene produzione, continuità operativa e servizi reali.

Dall’articolo 21 NIS2 alle verifiche tecniche OT

Le misure elencate dalla NIS2 vanno tradotte in verifiche pratiche sull’ambiente industriale. La lettera f dell’articolo 21 richiede esplicitamente policy e procedure per valutare l’efficacia delle misure di gestione del rischio cyber: in ambiente OT questo significa chiedersi se un attaccante che compromette un account, un accesso remoto o un gateway può raggiungere la rete industriale. Una risposta affidabile richiede una verifica tecnica, non una dichiarazione.

Misura NIS2	Evidenza tecnica utile in ambiente OT
Risk analysis e sicurezza dei sistemi informativi	OT risk assessment, asset mapping, threat modeling
Incident handling	Logging review, detection test, tabletop tecnico
Business continuity, backup e disaster recovery	Backup review, restore test, recovery scenario
Supply chain security	Supplier access review, remote access assessment
Sicurezza in acquisizione, sviluppo e manutenzione	Firmware assessment, code review, patch process review
Valutazione efficacia misure	Penetration test OT, segmentation test, re-test
Cyber hygiene e formazione	Review processi, phishing mirato non invasivo, training tecnico
Crittografia	Traffic analysis, protocol review, crypto configuration review
Controllo accessi e asset management	Access review, privilege test, asset inventory validation
Autenticazione multifattore	MFA validation, account abuse test, remote access review

NIS2 e supply chain: il fornitore OT come vettore di rischio

La supply chain occupa un posto centrale nella NIS2. La Direttiva richiede di includere la sicurezza della catena di fornitura tra le misure di gestione del rischio e di considerare le vulnerabilità specifiche di ciascun fornitore diretto, la qualità dei prodotti e dei servizi e le pratiche di cybersecurity dei fornitori, incluse le procedure di sviluppo sicuro.

In ambiente OT questo è particolarmente delicato perché i fornitori possono avere accesso tecnico diretto a router industriali, VPN, jump server, HMI, PLC, sistemi di teleassistenza, ambienti SCADA, software di manutenzione, gateway edge, piattaforme cloud industriali, aggiornamenti firmware e account amministrativi. Una supply chain insicura può diventare un canale diretto verso l’impianto.

Situazioni tipiche: fornitore con VPN sempre attiva, account condiviso tra più tecnici, accesso remoto senza MFA, laptop del manutentore non controllato, software di teleassistenza non tracciato, password identica su più macchine, assenza di log degli accessi fornitore, aggiornamenti firmware non verificati, mancata segregazione tra accesso fornitore e rete OT. La domanda tecnica da porsi non è “il fornitore ha una certificazione?”, ma cosa può fare concretamente una volta connesso.

NIS2, Cyber Resilience Act e prodotti connessi

La NIS2 guarda all’organizzazione e alla sua capacità di gestire il rischio. Il Cyber Resilience Act guarda invece ai prodotti con elementi digitali. Nel mondo industriale i due piani si incontrano: un soggetto NIS2 può usare gateway, software, dispositivi radio, componenti IoT o sistemi OT forniti da terzi, e se quei prodotti sono vulnerabili l’organizzazione che li usa eredita parte del rischio.

Il CRA spinge i produttori a progettare e mantenere prodotti digitali più sicuri; la NIS2 spinge gli operatori a governare anche il rischio introdotto da prodotti e fornitori. Il denominatore comune resta la verifica tecnica: testare il prodotto prima che entri in campo, verificare l’accesso remoto del fornitore, validare la segmentazione IT/OT, analizzare firmware e software industriale, testare API, backend e gateway, verificare remediation e controlli compensativi.

Come si conduce un assessment OT: approccio progressivo

In OT uno scanner aggressivo su PLC, HMI o sistemi legacy può creare problemi operativi. Alcuni asset non possono essere patchati rapidamente, alcuni protocolli non sono progettati per resistere a test invasivi e alcuni sistemi devono restare disponibili 24/7. Per questo un assessment OT serio segue una logica progressiva.

Raccolta informazioni e perimetro. Si definiscono ambienti, asset, reti, criticità, finestre operative, sistemi esclusi, contatti di emergenza e regole di ingaggio.

Mappatura asset e superfici d’attacco. Si identificano reti OT, segmenti IT/OT, DMZ industriale, PLC, HMI, SCADA, DCS, historian, engineering workstation, gateway, router industriali, accessi remoti, account fornitori, protocolli, servizi esposti e connessioni cloud.

Threat modeling. Si costruiscono scenari realistici: compromissione account fornitore, accesso VPN abusato, movimento laterale da IT a OT, compromissione HMI, accesso a PLC, abuso di gateway IoT, manipolazione telemetria, uso improprio di credenziali tecniche, modifica di parametri, interruzione di servizi critici.

Vulnerability assessment controllato. Si usano tecniche non invasive o calibrate, con attenzione a protocolli, sistemi legacy e disponibilità operativa.

Penetration test OT mirato. Si validano percorsi di attacco specifici, sempre concordati: autenticazione, autorizzazione, segmentazione, firewall, VPN, jump server, HMI, API, accessi remoti, account vendor, protocolli, escalation di privilegi e possibilità di raggiungere asset critici.

Remediation e re-test. Le correzioni vanno priorizzate, implementate e ritestate. La verifica non si chiude con un report.

Segmentazione IT/OT: il controllo che va dimostrato

Molte aziende dichiarano di avere separazione IT/OT, ma in fase di assessment emergono regole firewall troppo ampie, regole “any-any” temporanee mai rimosse, jump server multiuso, VPN che entrano troppo in profondità, asset OT raggiungibili da subnet IT, credenziali condivise, accessi remoti non segregati, DMZ industriale assente o mal progettata e asset legacy esposti per comodità operativa.

Un test tecnico può rispondere a domande molto concrete: da una postazione IT si può raggiungere una HMI? Da una VPN fornitore si può raggiungere un PLC? Da un gateway cloud si può entrare nella rete OT? Un account manutentore ha privilegi eccessivi? La DMZ industriale filtra davvero i flussi? I protocolli industriali passano solo dove previsto? Gli eventi vengono loggati e correlati? Queste sono evidenze molto più solide di una dichiarazione di intenti.

Scenario applicativo: fornitore con accesso remoto alla linea produttiva

Un’azienda manifatturiera rientra nel perimetro NIS2 come soggetto importante o essenziale. Ha linee produttive connesse, teleassistenza dei fornitori e gateway industriali per manutenzione predittiva. La situazione iniziale: fornitori con VPN permanente, MFA non obbligatoria, account condivisi, accesso alla rete OT più ampio del necessario, assenza di log dettagliati, nessuna revisione periodica degli account, backup delle configurazioni PLC non verificato e segmentazione documentata ma non testata.

Il problema NIS2 non è l’assenza di una policy: è che un attaccante potrebbe compromettere un fornitore e usare quell’accesso per muoversi verso l’ambiente OT. Le verifiche consigliate includono review degli accessi remoti, test MFA e account abuse, verifica privilegi, segmentation test, controllo log e tracciabilità, vulnerability assessment controllato, simulazione tecnica del percorso d’attacco, remediation plan e re-test. L’output utile comprende evidenza delle superfici esposte, lista vulnerabilità, scenari realistici, impatto operativo, priorità di remediation, controlli compensativi e prove di correzione.

Checklist: postura OT e NIS2

Questa checklist non sostituisce un assessment, ma aiuta a capire se l’ambiente OT è pronto per una verifica seria.

Esiste un inventario aggiornato di asset OT, PLC, HMI, SCADA, gateway, router industriali e accessi remoti?
È noto quali fornitori hanno accesso alla rete OT?
Gli accessi remoti sono temporanei, tracciati e approvati?
Gli account fornitore sono nominali e protetti da MFA?
La rete OT è realmente segmentata dalla rete IT?
La segmentazione è stata testata tecnicamente?
Esiste una DMZ industriale per i flussi IT/OT?
Le workstation di engineering sono protette e monitorate?
Le configurazioni PLC/HMI sono sottoposte a backup verificato?
Gli aggiornamenti firmware e software sono valutati prima della messa in produzione?
I protocolli industriali critici sono mappati e controllati?
Esistono log utili per ricostruire un incidente OT?
Le vulnerabilità OT sono gestite con priorità basata sul rischio operativo?
Sono previste misure compensative per sistemi legacy non patchabili?
Dopo una remediation viene eseguito un re-test?

Se molte risposte sono “no” o “non lo sappiamo”, la postura NIS2 dell’OT è probabilmente più debole di quanto sembri.

Output di un assessment OT orientato NIS2

Un assessment utile non produce solo una lista tecnica di vulnerabilità, ma evidenze adatte a più interlocutori.

Documento	Destinatario	Utilità
Sintesi direzionale	Direzione, CISO, risk manager	Comprendere rischio, priorità e impatto
Report tecnico	IT, OT, automation, security	Evidenze tecniche e remediation
Mappa della superficie d’attacco	IT/OT manager	Capire cosa è esposto e raggiungibile
Threat model	Security e operations	Scenari realistici di compromissione
Validazione segmentazione	Team OT/network	Verifica reale dei confini IT/OT
Review accessi remoti	Manutenzione, fornitori, OT	Controllo accessi e teleassistenza
Vulnerabilità rilevate	Team tecnici	Vulnerabilità, severità e contesto OT
Piano di remediation	Tutti i team coinvolti	Priorità operative e tecniche
Report di re-test	Compliance, audit, management	Evidenza delle correzioni

Frequenza delle verifiche

La sicurezza OT non è statica. Un assessment dovrebbe essere ripetuto dopo modifiche architetturali IT/OT, dopo l’apertura di nuovi accessi remoti, dopo l’onboarding di nuovi fornitori, dopo l’installazione di gateway o piattaforme cloud, dopo upgrade SCADA/HMI, dopo aggiornamenti firmware, dopo remediation, prima di audit, dopo incidenti o near miss e periodicamente, almeno come verifica annuale o secondo la criticità dell’ambiente. Questo approccio è coerente con il principio NIS2 di gestione continua del rischio.

Il ruolo di ISGroup

ISGroup supporta aziende industriali, utility, operatori essenziali e importanti, system integrator e produttori con attività tecniche mirate alla verifica del rischio OT. Le attività includono penetration test OT, IoT/OT Security Assessment, vulnerability assessment controllato, threat modeling, segmentation review, remote access security review, supplier access review, security auditing, firmware analysis, reverse engineering, source code review, protocol security testing, API security testing, hardening review, remediation plan e re-test.

ISGroup non vende consulenza NIS2 “chiavi in mano”, non rilascia certificazioni e non sostituisce consulenti legali o compliance advisor. Il valore è tecnico: verificare se reti OT, accessi remoti, fornitori, macchine connesse e sistemi industriali sono realmente esposti prima che lo scopra un attaccante.

Domande frequenti su NIS2 e ambienti OT

La NIS2 si applica anche agli ambienti OT?
Sì, quando i sistemi OT sono usati per attività o servizi rilevanti dell’organizzazione e un incidente può avere impatti operativi, economici o sui servizi erogati. La Direttiva parla di sistemi informativi e di rete usati per operazioni o servizi: negli ambienti industriali questo include reti OT, SCADA, HMI, PLC, gateway, accessi remoti e sistemi di telemetria.
La NIS2 obbliga a fare penetration test OT?
La Direttiva richiede misure tecniche proporzionate e policy per valutare l’efficacia delle misure di gestione del rischio. In ambiente OT, penetration test controllati e security assessment sono le evidenze tecniche più efficaci per dimostrare che i controlli funzionano, anche se la norma non prescrive uno strumento specifico.
Qual è il ruolo della supply chain nella NIS2?
La supply chain è centrale: la Direttiva include la sicurezza della catena di fornitura tra le misure di gestione del rischio e richiede di considerare vulnerabilità, qualità dei prodotti e pratiche di cybersecurity dei fornitori diretti e dei service provider.
Uno scanner di vulnerabilità è sufficiente per l’OT?
No. In OT uno scanner può essere insufficiente o rischioso se usato senza metodo. Serve un approccio controllato, con threat model, analisi architetturale, test mirati, limiti chiari e attenzione alla continuità operativa.
Con quale frequenza ripetere le verifiche OT?
Dopo ogni modifica architetturale significativa, dopo l’onboarding di nuovi fornitori o l’apertura di nuovi accessi remoti, dopo upgrade di sistemi critici e comunque almeno una volta l’anno. La NIS2 richiede una gestione continua del rischio, non una verifica una tantum.

NIS2 e ambienti OT: dalla governance alla verifica tecnica