Sicurezza industriale ICS/OT: guida a SCADA, PLC, NIS2 e infrastrutture critiche

La sicurezza industriale ICS/OT è il punto in cui la cybersecurity smette di proteggere soltanto dati, account, server e applicazioni, e inizia a incidere direttamente su processi fisici, continuità produttiva, sicurezza degli operatori e funzionamento delle infrastrutture critiche. Nei sistemi IT, un attacco può provocare furto di dati, interruzione di servizi digitali, compromissione di credenziali o blocco di un ambiente cloud. Nei sistemi OT, invece, un attacco può alterare la pressione in una condotta, fermare una linea ferroviaria, interrompere una catena manifatturiera, modificare parametri di trattamento dell’acqua, bloccare una centrale o sabotare un processo industriale. La differenza è sostanziale perché nei sistemi ICS, Industrial Control Systems, il software non resta confinato nel dominio digitale. Ogni istruzione può generare un effetto su sensori, attuatori, valvole, motori, pompe, turbine, forni, robot, linee di confezionamento, sistemi HVAC, impianti idrici e apparati di produzione. Il NIST SP 800-82 Rev. 3 definisce l’Operational Technology come l’insieme di sistemi programmabili e dispositivi che interagiscono con l’ambiente fisico, rilevando o causando cambiamenti attraverso il monitoraggio e il controllo di dispositivi, processi ed eventi. La stessa pubblicazione sottolinea che i sistemi OT hanno requisiti specifici di performance, affidabilità, safety e disponibilità, diversi da quelli del mondo IT tradizionale. Questa definizione chiarisce perché la sicurezza OT non possa essere trattata come una semplice estensione della cybersecurity enterprise. Un server aziendale può essere riavviato dopo una patch, un laptop può essere sostituito, un workload cloud può essere ripristinato in un’altra zona. Un impianto industriale, invece, può avere finestre di manutenzione rare, macchinari certificati, firmware legacy, sistemi progettati per durare decenni e processi che non possono essere interrotti senza produrre costi enormi o rischi fisici. In ambito OT, la disponibilità non è soltanto una metrica tecnica: è continuità del processo reale. Il dominio ICS/OT comprende SCADA, PLC, HMI, RTU, DCS, historian, engineering workstation, gateway industriali, reti di campo, sensori, attuatori e piattaforme di supervisione. Ogni elemento occupa una posizione precisa nella catena che trasforma un comando digitale in un effetto fisico. Una vulnerabilità su un server web può esporre dati. Una vulnerabilità su un sistema industriale può cambiare il comportamento di un impianto. È questa la ragione per cui il tema delle infrastrutture critiche deve essere trattato con una profondità diversa rispetto alla cronaca cyber ordinaria.

Nel quadro europeo, la protezione di energia, trasporti, sanità, acqua, servizi digitali, manifattura critica e infrastrutture essenziali è diventata una questione di resilienza nazionale. In Italia, l’Agenzia per la Cybersicurezza Nazionale indica che dal 16 ottobre 2024 è in vigore la nuova normativa Network and Information Security e opera come Autorità competente NIS e punto di contatto unico nazionale. ACN sulla normativa NIS Questo passaggio collega direttamente la sicurezza ICS/OT alla NIS2, perché il rischio industriale non riguarda più soltanto l’ingegneria di impianto, ma anche governance, responsabilità, incident response e continuità operativa. Dentro questa prospettiva si inseriscono le analisi di Matrice Digitale sulle vulnerabilità ICS segnalate da CISA e sui rischi per ambienti OT, sul ruolo del catalogo CISA KEV nella priorità delle vulnerabilità sfruttate, sulle vulnerabilità critiche in ambienti Linux, cPanel e ransomware e sulla cornice della NIS online e piattaforma ACN, dove la cybersicurezza diventa processo documentato, verificabile e continuo.

IT e OT: perché la sicurezza industriale segue regole diverse

La distinzione tra IT e OT non è una questione terminologica. È il fondamento di ogni strategia di difesa industriale. L’IT protegge dati, applicazioni, identità, endpoint, posta elettronica, cloud, API e servizi digitali. L’OT protegge processi fisici, macchinari, controllo industriale e continuità produttiva. Quando questi due mondi convergono, il rischio aumenta perché una minaccia nata nel perimetro IT può propagarsi verso sistemi industriali, dove gli effetti diventano molto più difficili da contenere.

Nel mondo IT, la priorità classica viene descritta dalla triade confidenzialità, integrità e disponibilità. Nelle reti industriali, invece, l’ordine cambia. La disponibilità e la safety diventano prioritarie perché un fermo impianto può provocare perdite economiche, disservizi pubblici, danni ambientali o rischi per gli operatori. Una patch applicata senza test può essere più pericolosa della vulnerabilità che dovrebbe correggere, se altera il comportamento di un PLC, blocca una HMI o interrompe una linea produttiva. Una scansione aggressiva, normale in un ambiente enterprise, può destabilizzare dispositivi industriali legacy. Questa differenza impone un cambio di mentalità. Nel mondo IT, un sistema vulnerabile può essere isolato, aggiornato e riavviato in tempi relativamente brevi. Nel mondo OT, ogni intervento deve essere compatibile con il processo fisico. Un aggiornamento del firmware può richiedere autorizzazioni, test su ambiente separato, verifica del vendor e finestra di fermo. Un riavvio può non essere banale. Una modifica di configurazione può produrre effetti sul comportamento della macchina. La sicurezza industriale non può essere separata dall’ingegneria. La convergenza IT/OT ha reso questa distinzione ancora più delicata. Per anni molte reti industriali sono state progettate assumendo isolamento, protocolli chiusi e accesso limitato. Oggi manutenzione remota, sensori IoT, telemetria, cloud industriale, piattaforme di analytics, supply chain digitale e integrazione con ERP e MES hanno aperto nuovi canali. Il confine tra ufficio e impianto è diventato poroso. Un malware arrivato via email può non colpire direttamente un PLC, ma può compromettere un account, raggiungere una workstation di engineering, attraversare un jump server e arrivare nella rete di controllo. È lo stesso principio che emerge nella guida Matrice Digitale alla Cloud Security: la superficie d’attacco moderna non coincide più con un singolo perimetro fisico. Identità, API, accessi remoti, configurazioni, fornitori e ambienti ibridi diventano parte dello stesso rischio. Nell’OT questa dinamica è ancora più critica perché il danno digitale può tradursi in danno operativo.

SCADA, PLC e HMI: la mappa degli obiettivi industriali

Per comprendere le vulnerabilità industriali bisogna mappare i componenti che gli attaccanti possono colpire. I sistemi SCADA, Supervisory Control and Data Acquisition, forniscono supervisione, raccolta dati e controllo su processi distribuiti. Sono usati in energia, acqua, trasporti, reti geografiche e impianti complessi. Una compromissione dello SCADA può alterare la visibilità dell’operatore, inviare comandi impropri, mascherare condizioni anomale o manipolare la percezione dello stato dell’impianto.

I PLC, Programmable Logic Controllers, sono i controllori programmabili che eseguono logiche di automazione. Leggono input dai sensori, applicano istruzioni e comandano attuatori. Sono il punto in cui il codice diventa movimento, apertura, chiusura, variazione di velocità, temperatura, pressione o sequenza produttiva. Una vulnerabilità nel firmware di un PLC, una configurazione debole o un accesso di engineering non protetto possono consentire modifiche ai programmi di controllo, caricamento di logiche alterate o interruzione del processo.

Le HMI, Human-Machine Interface, sono le interfacce con cui gli operatori osservano e comandano l’impianto. Spesso sono basate su sistemi Windows o Linux industrializzati, applicazioni legacy e software di supervisione. Sono bersagli appetibili perché combinano accesso umano, interfaccia di comando e connettività verso livelli inferiori. Una HMI compromessa può ingannare l’operatore, nascondere allarmi, mostrare dati falsati o diventare ponte verso PLC e SCADA.

A questi componenti si aggiungono RTU, Distributed Control Systems, historian, engineering workstation, server OPC, gateway industriali, sistemi di accesso remoto e piattaforme di manutenzione. La workstation di engineering è particolarmente sensibile perché permette di programmare o modificare logiche dei controllori. Un attaccante che compromette quell’ambiente può non aver bisogno di “rompere” il PLC: può usare strumenti legittimi per inviare comandi apparentemente validi.

La CISA pubblica advisory specifici per Industrial Control Systems, CISA ICS advisories, con informazioni su vulnerabilità, prodotti coinvolti, impatti e mitigazioni. Gli advisory ICS servono proprio a fornire informazioni tempestive su problemi di sicurezza, vulnerabilità ed exploit relativi ai sistemi di controllo industriale. Questo flusso è essenziale perché il mondo ICS/OT è frammentato: vendor, versioni firmware, componenti embedded, software di supervisione e configurazioni d’impianto possono variare enormemente. Le vulnerabilità ICS non riguardano solo grandi centrali o raffinerie. Possono colpire macchine utensili, linee di confezionamento, building automation, impianti idrici, dispositivi medicali, magazzini automatizzati, catene logistiche, impianti HVAC e piccole infrastrutture locali. La sicurezza industriale non è più una nicchia confinata ai grandi operatori dell’energia. È una superficie diffusa, spesso gestita da organizzazioni che non hanno maturità cyber proporzionata alla criticità fisica dei processi controllati. Per questo il collegamento con le vulnerabilità trattate da Matrice Digitale è diretto. I casi su CISA e vulnerabilità critiche in ambienti enterprise, sulle falle sfruttate in infrastrutture Microsoft, Apache e Linux e sulle catene di exploit contro SharePoint e ambienti aziendali mostrano che una compromissione nata nel dominio IT può diventare ponte verso sistemi molto più critici.

Protocolli industriali e debito storico della sicurezza

Molti protocolli industriali sono nati in un’epoca in cui la rete era considerata fidata. Modbus, Profinet, DNP3, EtherNet/IP, BACnet, OPC Classic e altri protocolli sono stati progettati per affidabilità, interoperabilità e controllo, non per resistere ad attaccanti remoti. In molte implementazioni storiche mancano autenticazione forte, cifratura, integrità dei comandi e logging adeguato. Il risultato è un debito strutturale: se un aggressore raggiunge il segmento giusto, può spesso osservare o manipolare traffico con meno ostacoli rispetto a un ambiente IT moderno. Questo non significa che ogni protocollo industriale sia insicuro nello stesso modo o che non esistano profili moderni più robusti. Significa però che molte installazioni reali convivono con configurazioni legacy, dispositivi non aggiornabili e architetture nate prima dell’esposizione verso reti aziendali, manutenzione remota e piattaforme cloud. La sicurezza dipende quindi più dall’architettura complessiva che dalla singola funzione del dispositivo. La segmentazione diventa il controllo fondamentale. Se un protocollo industriale non offre garanzie robuste, l’organizzazione deve compensare con separazione di rete, firewall industriali, access control list, jump server, controllo degli accessi remoti e monitoraggio passivo. L’obiettivo non è fingere che un protocollo nato senza sicurezza moderna diventi improvvisamente sicuro, ma impedirne l’abuso fuori dal contesto operativo previsto. Questa è una differenza cruciale rispetto al mondo IT. In un’applicazione web moderna, si può intervenire sul codice, aggiornare librerie, forzare TLS, introdurre autenticazione federata e applicare controlli applicativi. In una rete OT, spesso bisogna proteggere ciò che non può essere riscritto. Il controllo passa da architettura, segmentazione, visibilità e gestione rigorosa degli accessi. Il problema si intreccia con la nozione di vulnerabilità già descritta nell’enciclopedia delle vulnerabilità informatiche. Nel dominio ICS/OT, una vulnerabilità non è solo una debolezza software: può essere una configurazione storica, un protocollo privo di autenticazione, un accesso remoto dimenticato, un dispositivo non patchabile o una dipendenza industriale che nessuno ha più inventariato.

Patching nei sistemi legacy: perché aggiornare può essere rischioso

Il patch management OT è una delle attività più complesse della sicurezza industriale. Nel mondo IT, un aggiornamento viene testato e distribuito con cicli relativamente frequenti. Nel mondo OT, una patch può richiedere fermo impianto, validazione del vendor, test su ambiente di staging, verifica di compatibilità con software legacy e autorizzazioni operative. In alcuni casi il produttore non supporta più il dispositivo. In altri, la patch esiste ma non può essere applicata senza interrompere una funzione critica. La CISA, nelle buone pratiche per Industrial Control Systems, raccomanda di identificare, minimizzare e proteggere tutte le connessioni di rete, oltre a verificare, prioritizzare, testare e implementare patch di sicurezza ICS quando possibile. CISA best practices for Industrial Control Systems La sequenza è importante: non basta installare. Bisogna verificare, prioritizzare e testare, perché l’ambiente OT non tollera interventi improvvisati. Il dilemma è evidente. Non patchare lascia aperta una vulnerabilità. Patchare male può fermare un impianto. Questo produce un rischio specifico: molte organizzazioni possono essere tentate di rimandare indefinitamente gli aggiornamenti, creando un accumulo di vulnerabilità note. Gli attaccanti conoscono bene questa inerzia e cercano sistemi industriali esposti, gateway remoti, HMI obsolete, VPN non aggiornate e accessi di manutenzione deboli. Quando la patch non è possibile, entrano in gioco misure compensative. Il virtual patching tramite firewall industriali, IPS, regole di accesso e blocchi di protocollo può ridurre il rischio. La segmentazione può limitare la raggiungibilità del dispositivo vulnerabile. Il monitoraggio passivo può rilevare comandi anomali. L’accesso remoto può essere ristretto a jump host controllati. Le credenziali possono essere ruotate. Le funzioni non necessarie possono essere disabilitate. Il punto operativo è che una vulnerabilità non patchata in OT deve essere governata, non ignorata. Serve una decisione documentata: perché non si patcha subito, quale rischio resta, quali controlli compensativi sono stati applicati, quando verrà rivalutata la condizione e quali indicatori verranno monitorati. Nel quadro NIS2, questa tracciabilità diventa ancora più importante perché la gestione del rischio non può restare implicita. Il tema si collega direttamente alla guida Matrice Digitale su CISA e catalogo KEV, perché una vulnerabilità presente nel catalogo KEV e installata su un asset industriale esposto richiede una corsia preferenziale. Se la patch non può essere applicata subito, l’organizzazione deve almeno dimostrare di aver valutato esposizione, impatto, mitigazione, segmentazione e monitoraggio.

Air-gap, accessi remoti e mito dell’isolamento totale

L’air-gap è la separazione fisica tra una rete industriale e Internet o altre reti non fidate. In teoria rappresenta una barriera forte: se non esiste connessione, l’attaccante remoto non può raggiungere direttamente l’impianto. Nella pratica moderna, però, l’air-gap assoluto è raro. Chiavette USB, manutenzione remota, laptop dei fornitori, aggiornamenti manuali, sensori connessi, gateway IIoT, reti temporanee e trasferimenti di dati creano spesso ponti inattesi. Il problema non è dichiarare inutile l’air-gap. Il problema è smettere di considerarlo una garanzia magica. Un impianto isolato può comunque essere compromesso tramite supporti rimovibili, catena di fornitura, insider, strumenti di engineering infetti o procedure di manutenzione deboli. La sicurezza deve quindi includere controlli anche dentro la rete OT, non soltanto al confine. Gli accessi remoti sono diventati uno dei punti più delicati. Vendor, manutentori, integratori e operatori hanno spesso bisogno di collegarsi agli impianti per supporto, aggiornamenti e diagnostica. Ogni accesso remoto deve essere trattato come un canale ad alto rischio. Serve autenticazione forte, registrazione delle sessioni, autorizzazioni temporanee, segmentazione, jump server, approvazione preventiva e revoca rapida. Il modello corretto non è “nessun accesso remoto” in senso assoluto, perché molte infrastrutture moderne non possono funzionare senza supporto distribuito. Il modello corretto è accesso remoto controllato, tracciato e minimizzato. Ogni connessione verso OT deve avere una finalità chiara, una finestra temporale, un’identità nota e un perimetro limitato. Questa logica è la stessa che attraversa la privacy e l’hardening di Windows 11 quando il tema diventa riduzione della superficie d’attacco, controllo delle funzioni non necessarie e limitazione della telemetria. Nell’OT, però, la riduzione della superficie d’attacco non serve soltanto a proteggere dati: serve a evitare che un canale improprio arrivi fino a macchine e processi fisici.

Segmentazione e Purdue Model: contenere il movimento laterale

La segmentazione è il principio più importante nella difesa ICS/OT. Il Purdue Model offre una rappresentazione gerarchica dei livelli industriali, separando il livello enterprise, la DMZ industriale, i sistemi di supervisione, il controllo di processo e i dispositivi fisici. Non va trattato come dogma statico, ma resta utile per chiarire un principio: la rete IT non deve comunicare liberamente con la rete OT, e i livelli più bassi non devono essere raggiungibili senza controlli rigorosi. Una buona architettura separa l’IT dall’OT con firewall, DMZ industriale, broker di comunicazione, jump server e policy esplicite. I dati possono salire verso sistemi enterprise per report, manutenzione, analytics o supply chain, ma i comandi verso il basso devono essere strettamente controllati. Il traffico tra livelli deve essere previsto, documentato e monitorato. Le eccezioni devono essere rare e motivate. La segmentazione non serve solo a prevenire l’accesso iniziale. Serve soprattutto a contenere il movimento laterale. Se un malware compromette un endpoint IT, non deve poter raggiungere direttamente HMI o PLC. Se una HMI viene compromessa, non deve poter comunicare liberamente con tutti i controllori dell’impianto. Se un vendor accede da remoto, non deve avere visibilità sull’intera rete industriale. In questa logica, la sicurezza industriale si collega al principio Zero Trust, ma con adattamenti OT. Non si può applicare lo stesso modello di agent, controllo identità e policy dinamiche usato nel cloud a tutti i dispositivi industriali legacy. Si può però applicare il principio di base: nessuna comunicazione deve essere implicitamente fidata solo perché avviene “dentro” la rete. Ogni flusso deve essere giustificato, limitato e osservabile. Matrice Digitale ha già affrontato questo tema nei contenuti su Cloud Security, IAM, Zero Trust e protezione dei dati e nelle analisi sulle vulnerabilità RCE e exploit critici, perché la catena d’attacco non si ferma al primo accesso. In un ambiente industriale, il problema non è soltanto evitare l’exploit: è impedire che l’exploit diventi movimento laterale verso il processo.

Monitoraggio passivo e rilevazione delle anomalie

Il monitoraggio OT deve essere prudente. In ambienti enterprise è normale usare scanner attivi, query aggressive e agent endpoint. In reti industriali, questi approcci possono creare instabilità. Per questo il monitoraggio passivo è spesso preferibile: osserva il traffico senza interferire con il processo, ricostruisce comunicazioni, protocolli, asset e baseline, e segnala anomalie rispetto al comportamento atteso. Il valore del monitoraggio passivo sta nella conoscenza dell’ambiente. Molte organizzazioni non hanno un inventario completo dei dispositivi OT, delle versioni firmware, dei protocolli, delle connessioni e dei flussi tra sistemi. Senza inventario, non esiste vulnerability management efficace. Non si può proteggere ciò che non si conosce, e non si può valutare una vulnerabilità ICS se non si sa dove il prodotto è installato. La rilevazione OT deve guardare a segnali diversi da quelli IT. Un trasferimento di file può essere normale in ufficio, ma anomalo su una rete di controllo. Un comando Modbus fuori orario può essere sospetto. Una variazione improvvisa nella frequenza di scrittura verso un PLC può indicare manipolazione. Un nuovo engineering station che comunica con controllori sensibili può essere un campanello d’allarme. Un traffico verso Internet da una HMI può indicare compromissione. Il monitoraggio deve però essere integrato con competenza di processo. Un SOC tradizionale può vedere pacchetti, ma non sempre capisce l’impatto fisico. In OT serve collaborazione tra sicurezza, ingegneria, manutenzione e operatori. Un alert tecnico deve essere interpretato alla luce della produzione. Un comando può essere legittimo in manutenzione e pericoloso durante esercizio. Questa convergenza tra cyber e processo è il vero salto di maturità. Il collegamento con la threat intelligence è fondamentale. Un alert su una vulnerabilità sfruttata, un advisory CISA, un bollettino CSIRT Italia o un segnale KEV devono essere tradotti in una domanda concreta:

abbiamo questo asset? È esposto? È segmentato? È patchabile? Esistono indicatori di sfruttamento? Senza questa catena, l’informazione resta rumore.

NIS2, ACN e responsabilità nella sicurezza industriale italiana

La sicurezza industriale è ormai inserita in una cornice regolatoria precisa. La NIS2 allarga il perimetro dei soggetti coinvolti e spinge le organizzazioni verso gestione del rischio, misure tecniche e organizzative, governance, responsabilità degli organi di amministrazione e notifica degli incidenti. ACN, nella sezione dedicata agli obblighi NIS, richiama gli obblighi per organi di amministrazione e direttivi, la gestione dei rischi per la sicurezza informatica e la notifica degli incidenti. Per gli operatori industriali, questo significa che la sicurezza OT non può restare confinata al reparto automazione o alla manutenzione. Deve entrare nei processi di governance. Gli organi direttivi devono conoscere il rischio, approvare misure, garantire risorse, verificare continuità e assicurare che le decisioni siano documentate. Il linguaggio della sicurezza industriale diventa quindi anche linguaggio di compliance, audit e responsabilità. Le linee guida ACN sul processo di gestione degli incidenti di sicurezza informatica richiamano la gestione degli incidenti come uno dei pilastri del decreto legislativo 4 settembre 2024, n. 138, cioè il decreto NIS. Questo è particolarmente rilevante per ICS/OT perché un incidente industriale può avere tempi, effetti e priorità diverse da un incidente IT. Non basta ripristinare un server. Bisogna capire se il processo fisico è stato alterato, se i parametri sono affidabili, se gli operatori hanno visto dati corretti e se l’impianto può tornare in sicurezza. Per questa ragione, lo CSIRT Italia diventa un riferimento operativo per alert, bollettini e gestione degli incidenti. Gli avvisi nazionali devono essere letti insieme agli advisory internazionali, agli aggiornamenti vendor, ai segnali CISA KEV e alla mappa interna degli asset. Nel dominio industriale, una vulnerabilità non è mai solo una sigla: è una possibile interruzione del servizio essenziale. La guida Matrice Digitale su DORA 2026 aiuta a leggere un principio simile nel settore finanziario: resilienza, terze parti, continuità e governance non possono essere separate dalla sicurezza tecnica. Nell’OT questo vale ancora di più, perché la catena dei fornitori include vendor industriali, integratori, manutentori, produttori di componenti, software di supervisione, dispositivi embedded e operatori di accesso remoto.

Supply chain industriale e dipendenza dai fornitori

La supply chain OT è una delle superfici più difficili da governare. Un impianto industriale non è costruito da un solo soggetto. Include componenti di vendor diversi, software di supervisione, firmware, workstation, librerie, moduli di comunicazione, gateway, apparati di rete, sensori, attuatori e strumenti di manutenzione. Ogni fornitore introduce dipendenze, accessi e cicli di aggiornamento propri. Una vulnerabilità in un componente diffuso può propagarsi in molti impianti contemporaneamente. Una libreria vulnerabile integrata in prodotti industriali di più vendor può rendere esposti sistemi che non condividono lo stesso marchio finale. Un accesso remoto del fornitore mal gestito può diventare porta d’ingresso. Un aggiornamento software non verificato può introdurre instabilità. Una chiave privata compromessa può minare la fiducia nell’intera catena di update. La gestione della supply chain industriale richiede inventario, contratti chiari, clausole di sicurezza, procedure di accesso remoto, obblighi di disclosure, tempi di patch, verifica degli aggiornamenti, segregazione degli account vendor e controllo delle sessioni. Non basta sapere chi ha fornito il PLC. Bisogna sapere chi può accedere, quando, con quali privilegi, con quali strumenti e con quale tracciabilità. Questo tema si collega alle analisi di Matrice Digitale sulla supply chain software, Axios e nuove vulnerabilità KEV, sui pacchetti npm e sul rischio di hijacking nella catena software e sulle campagne cyber che colpiscono componenti condivisi e infrastrutture enterprise. Nell’OT, la supply chain non è solo software: è anche manutenzione, hardware, firmware, accessi e fiducia operativa. Il rischio aumenta quando gli impianti industriali inviano dati verso piattaforme cloud, digital twin, manutenzione predittiva o dashboard SaaS. La convergenza tra OT e cloud industriale crea valore, ma anche nuove responsabilità. Un errore IAM, una API esposta o un token compromesso possono diventare il punto d’ingresso verso dati di processo o sistemi di controllo. Qui il collegamento con Cloud Computing, multi-cloud e FinOps diventa concreto: il cloud industriale non può essere gestito come semplice estensione dell’ufficio.

Incident response OT: ripristinare non significa solo riaccendere

La risposta agli incidenti OT deve essere diversa da quella IT. In un attacco a un server aziendale, il ripristino può coincidere con isolamento, bonifica, restore da backup e hardening. In un incidente industriale, bisogna verificare anche lo stato fisico del processo, l’integrità delle logiche di controllo, la correttezza dei parametri, la sicurezza degli operatori e la possibilità di riavviare senza creare nuove condizioni di rischio. Il primo passo è la safety. Se un incidente può alterare macchinari, pressione, temperatura, velocità o composizione chimica, la priorità non è forense ma sicurezza fisica. I team cyber devono coordinarsi con operatori, ingegneri, responsabili impianto e sicurezza sul lavoro. Una risposta tecnicamente corretta ma scollegata dal processo può peggiorare la situazione. Il secondo passo è l’isolamento controllato. Spegnere o disconnettere in modo brutale un sistema OT può essere pericoloso. Alcuni processi richiedono arresti ordinati, sequenze di sicurezza, ridondanza e procedure fisiche. La segmentazione preventiva aiuta proprio in questo: se la rete è ben progettata, si può isolare un segmento senza fermare tutto l’impianto. Il terzo passo è la verifica dell’integrità. Dopo un attacco, bisogna controllare programmi PLC, configurazioni HMI, account, firmware, engineering workstation, historian, ricette di produzione, parametri e log. Un malware può essere rimosso da una macchina, ma una logica alterata può restare nel controllore. Un backup può essere integro dal punto di vista file, ma contenere configurazioni compromesse se creato dopo l’attacco. Il quarto passo è il ritorno in esercizio. Ripartire non significa soltanto accendere i sistemi. Significa validare che il processo funzioni secondo parametri sicuri, che gli operatori vedano dati affidabili, che gli allarmi siano attivi, che le comunicazioni siano controllate e che la causa dell’incidente sia stata contenuta. In OT, la recovery è una fase ingegneristica oltre che informatica. Questa impostazione dialoga con le analisi di Matrice Digitale sugli attacchi ransomware e sulle vulnerabilità sfruttate in ambienti SharePoint, sui rootkit e sulle compromissioni di apparati Fortinet e SonicWall e sulle campagne di exploit che trasformano vulnerabilità enterprise in accesso persistente.

Nel dominio industriale, la domanda non è solo “abbiamo ripristinato il server?”, ma abbiamo ripristinato la fiducia nel processo fisico?

Come costruire una difesa ICS/OT credibile

Una difesa ICS/OT credibile parte dall’inventario degli asset. Bisogna sapere quali dispositivi esistono, dove si trovano, quali versioni usano, quali protocolli parlano, quali sistemi li controllano, quali vendor li supportano e quali connessioni sono attive. Senza inventario, ogni discussione su patching, monitoraggio o rischio resta astratta. Non si può proteggere ciò che non si conosce. Il secondo elemento è la segmentazione IT/OT. La rete aziendale e la rete industriale devono essere separate, con una DMZ industriale e flussi controllati. Gli accessi remoti devono passare da punti governati. Le comunicazioni tra livelli devono essere ridotte al necessario. Le eccezioni devono essere tracciate. La logica “tutto comunica con tutto” è incompatibile con la sicurezza industriale. Il terzo elemento è il monitoraggio passivo. L’OT deve essere osservata senza destabilizzare. Serve visibilità su protocolli industriali, asset, anomalie, nuovi dispositivi, comandi fuori baseline e comunicazioni inattese. Il SOC deve ricevere segnali intelligibili, ma deve anche collaborare con chi conosce l’impianto. La sicurezza OT non può essere governata solo da dashboard IT. Il quarto elemento è il patch management adattato all’OT. Le patch devono essere valutate, testate e applicate quando possibile. Quando non è possibile, servono controlli compensativi documentati. Ogni vulnerabilità critica deve avere una decisione, non un silenzio. In questo senso, il collegamento tra KEV CISA, RCE ed exploit critici e sicurezza industriale diventa essenziale: una falla sfruttata su un componente esposto non può restare nel ciclo ordinario. Il quinto elemento è la governance. NIS2, ACN, CSIRT Italia, advisory CISA ICS e NIST SP 800-82 non sono documenti da archiviare. Sono riferimenti per costruire procedure, responsabilità, piani di risposta, formazione e audit. La sicurezza industriale matura quando il responsabile cyber, l’ingegnere di automazione e il vertice aziendale parlano dello stesso rischio con linguaggi diversi ma obiettivi comuni. La protezione ICS/OT richiede quindi un cambio di prospettiva: non basta bloccare il malware, non basta installare una patch, non basta avere un firewall. Serve una visione capace di collegare processo fisico, vulnerabilità tecnica, supply chain, accessi remoti, governance NIS2, threat intelligence e continuità operativa. È in questo punto che la cybersecurity diventa sicurezza nazionale, industriale e infrastrutturale.

FAQ sulla sicurezza industriale ICS/OT