In una fabbrica, obsoleto non significa necessariamente inutilizzabile. PLC, workstation e sistemi di controllo installati molti anni fa possono continuare a governare processi critici con elevata affidabilità, pur non rispondendo più agli standard di cyber security attuali.

Il problema dei sistemi legacy nasce proprio da questa contraddizione: tecnologie difficili da sostituire devono continuare a funzionare in un ambiente industriale sempre più connesso e quindi esposto a minacce per le quali non erano state progettate.

Cosa sono i sistemi legacy e i PLC datati nell’ambiente industriale

Il concetto di legacy nell’Operational Technology è diverso da quello che normalmente viene utilizzato nell’IT.

Un server aziendale può diventare obsoleto nel giro di pochi anni e rientrare in un normale ciclo di refresh tecnologico. Una macchina industriale, invece, può avere una vita operativa di decenni e continuare a produrre valore molto tempo dopo la fine del supporto commerciale di alcune delle sue componenti digitali.

All’interno dello stesso stabilimento possono così convivere tecnologie appartenenti a generazioni molto differenti.

Definizione di Operational Technology legacy e cause della loro permanenza in fabbrica

Un sistema OT può essere considerato legacy quando utilizza hardware, software, sistemi operativi, protocolli o componenti che non riflettono più lo stato corrente della tecnologia e, soprattutto, quando il loro supporto o la possibilità di aggiornarli risultano limitati o cessati.

Non significa necessariamente che il sistema sia malfunzionante.

Al contrario, una delle ragioni per cui queste tecnologie rimangono in produzione è proprio la loro affidabilità. Se un PLC controlla da quindici o vent’anni una linea senza problemi, sostituirlo può apparire economicamente poco conveniente.

Ma esistono anche vincoli più concreti.

Il componente può essere integrato in un macchinario certificato, utilizzare software proprietario, dipendere da periferiche non più disponibili oppure richiedere un fermo produttivo significativo per essere sostituito.

In altri casi manca persino la documentazione necessaria per ricostruire completamente configurazioni e dipendenze.

La permanenza dei sistemi legacy deriva quindi dall’incontro tra ciclo di vita industriale e ciclo di vita digitale, due dimensioni che procedono a velocità profondamente differenti.

Le caratteristiche dei controllori logici programmabili privi di sicurezza nativa

Molti PLC appartenenti alle generazioni precedenti sono stati progettati in un periodo nel quale le reti industriali erano prevalentemente isolate e la minaccia cyber aveva caratteristiche molto diverse da quelle attuali.

L’obiettivo principale era garantire determinismo, disponibilità e affidabilità del processo.

Di conseguenza, alcuni dispositivi e protocolli industriali storicamente utilizzati possono disporre di capacità limitate in materia di autenticazione, cifratura, logging o controllo granulare degli accessi.

In un ambiente isolato queste caratteristiche potevano rappresentare un rischio accettabile. Quando però lo stesso dispositivo viene inserito in un’infrastruttura interconnessa con sistemi IT, piattaforme di manutenzione remota, gateway IIoT o servizi cloud, il modello di minaccia cambia radicalmente.

Il problema non è quindi soltanto l’età del PLC, ma la distanza tra le condizioni per le quali era stato progettato e quelle nelle quali viene utilizzato oggi.

I principali rischi informatici associati all’uso di PLC e sistemi datati

La presenza di un asset legacy non equivale automaticamente a una vulnerabilità critica.

Il rischio dipende da esposizione, funzione svolta, architettura, vulnerabilità effettivamente presenti e misure compensative applicate.

Tuttavia, l’obsolescenza riduce spesso le possibilità di intervento e può trasformare una debolezza conosciuta in un rischio destinato a permanere per anni.

Assenza di aggiornamenti di sicurezza e vulnerabilità non correggibili

La situazione più complessa si verifica quando il produttore interrompe il supporto e non rilascia più patch o aggiornamenti di sicurezza.

Se venisse scoperta una vulnerabilità, l’organizzazione potrebbe non disporre di una correzione applicabile.

Anche quando una patch esiste, inoltre, installarla in un ambiente industriale può richiedere verifiche ulteriori. L’aggiornamento potrebbe modificare il comportamento del sistema, creare incompatibilità con applicazioni o periferiche oppure richiedere una finestra di manutenzione non immediatamente disponibile.

Nasce così una categoria di rischio tipicamente OT: la vulnerabilità conosciuta che non può essere eliminata nel breve periodo.

In questi casi la strategia deve spostarsi dalla remediation diretta alla mitigazione, riducendo esposizione e possibilità di sfruttamento attraverso controlli compensativi.

È fondamentale, però, che questa situazione venga documentata. Un asset non aggiornabile non dovrebbe diventare un’eccezione permanente semplicemente perché “ha sempre funzionato”.

Rischi di fermo produzione e danni fisici agli impianti di linea

Quando il sistema vulnerabile controlla un processo fisico, le conseguenze di una compromissione possono superare il perimetro informatico.

L’indisponibilità di un PLC può determinare il fermo di una macchina o di una linea. L’alterazione di parametri o logiche di controllo può, invece, interferire con il comportamento del processo.

La presenza di sistemi di safety indipendenti e correttamente progettati è essenziale per ridurre il rischio per persone e impianti, ma non elimina le possibili conseguenze operative ed economiche di un attacco.

Produzione persa, materie prime inutilizzabili, ritardi nelle consegne, manutenzione straordinaria e tempi necessari alla ricostruzione delle configurazioni possono trasformare una vulnerabilità tecnica in una perdita economica significativa.

Per questo, la criticità di un sistema legacy dovrebbe essere determinata anche sulla base del processo che controlla e delle conseguenze della sua indisponibilità o manipolazione.

Strategie di mitigazione per la protezione dei sistemi legacy senza interrompere i processi

Quando patching o sostituzione non sono immediatamente possibili, la domanda diventa: come ridurre il rischio senza interferire con la produzione?

La risposta passa attraverso un insieme di misure compensative progettate attorno alle caratteristiche dell’asset.

L’obiettivo è limitare ciò che può raggiungerlo, controllare le comunicazioni necessarie e aumentare la capacità di identificare rapidamente eventuali comportamenti anomali.

Segmentazione di rete e segregazione dei PLC vulnerabili mediante firewall dedicati

Un PLC legacy non dovrebbe essere raggiungibile da sistemi che non hanno necessità operative di comunicare con esso.

La segmentazione permette di separare asset con funzioni e livelli di rischio differenti, riducendo le possibilità di movimento laterale in caso di compromissione.

Firewall industriali e altri punti di controllo possono essere utilizzati per autorizzare soltanto i flussi necessari tra le diverse zone.

In presenza di sistemi particolarmente vulnerabili può essere opportuno creare segmenti dedicati, limitando fortemente comunicazioni e accessi amministrativi.

Il principio è semplice: se non è possibile correggere la vulnerabilità dell’asset, bisogna ridurre le opportunità che un attaccante possa raggiungerla e sfruttarla.

La segmentazione non deve tuttavia essere improvvisata.

Bloccare un flusso apparentemente non necessario può interferire con il processo. Prima di modificare l’architettura è quindi indispensabile conoscere protocolli, dipendenze e normali pattern di comunicazione.

Monitoraggio passivo del traffico e rilevamento delle anomalie di rete OT

La visibilità rappresenta il secondo pilastro della mitigazione.

Negli ambienti legacy, dove gli agent di sicurezza tradizionali possono essere incompatibili o impossibili da installare, il monitoraggio passivo della rete permette di osservare le comunicazioni senza interagire direttamente con il dispositivo.

Analizzando il traffico è possibile ricostruire asset e relazioni, identificare nuovi dispositivi, rilevare comunicazioni inattese e individuare cambiamenti rispetto al comportamento abituale.

Un PLC che normalmente comunica soltanto con un determinato HMI e improvvisamente riceve connessioni da un segmento differente dovrebbe generare un’indagine.

Il vantaggio dell’approccio passivo consiste nel fornire visibilità limitando il rischio di interferire con dispositivi sensibili.

Questo non significa che ogni anomalia sia necessariamente un attacco. La conoscenza del processo rimane indispensabile per distinguere manutenzione, variazioni legittime e comportamenti realmente sospetti.

Impatto economico e gestione dei costi per la sicurezza dell’hardware datato

L’obsolescenza è anche un problema finanziario.

Mantenere un sistema legacy produce costi e rischio, ma sostituirlo può richiedere investimenti elevati, fermi impianto e modifiche ad altre componenti della linea.

La decisione deve quindi essere costruita sul costo complessivo del rischio, non soltanto sul prezzo del nuovo hardware.

Valutazione dei costi tra intervento di isolamento e sostituzione dell’infrastruttura

La mitigazione può essere economicamente vantaggiosa quando permette di mantenere in sicurezza un asset ancora affidabile per un periodo definito.

Segmentazione, firewall, monitoraggio e controllo degli accessi hanno però anch’essi un costo e non eliminano la causa originaria del problema.

Inoltre, man mano che il sistema invecchia possono aumentare altri fattori: difficoltà nel reperire ricambi, riduzione delle competenze disponibili, dipendenza da singoli fornitori e impossibilità di ripristinare rapidamente l’hardware dopo un guasto.

Occorre quindi confrontare almeno due scenari: quanto costa continuare a proteggere il sistema e quanto costa sostituirlo.

La valutazione dovrebbe includere CAPEX, costi operativi, fermo necessario alla migrazione, rischio residuo, disponibilità dei ricambi e impatto economico di una possibile indisponibilità.

È qui che la cyber security diventa parte della gestione delle passività operative: un’infrastruttura obsoleta non rappresenta soltanto un problema tecnico, ma un debito tecnologico che può richiedere investimenti futuri e incidere sul profilo di rischio dell’impresa.

Continuità operativa e pianificazione degli investimenti di ammodernamento

La sostituzione dei sistemi legacy dovrebbe essere pianificata prima che diventi un’emergenza.

Un asset può essere classificato in base a criticità, stato del supporto, esposizione cyber, possibilità di applicare controlli compensativi e conseguenze di un guasto.

Da questa classificazione può nascere una roadmap pluriennale.

I sistemi più critici e meno mitigabili avranno priorità maggiore; quelli sufficientemente isolati e per i quali esistono ricambi e procedure di recovery potranno eventualmente essere mantenuti più a lungo.

È utile considerare anche il rischio di obsolescenza delle competenze.

Un PLC può continuare a funzionare perfettamente, ma se soltanto poche persone conoscono il software necessario per programmarlo o se gli strumenti di engineering non sono più disponibili, la capacità di recovery dell’organizzazione si riduce progressivamente.

La modernizzazione deve quindi riguardare hardware, software, documentazione e competenze.

Conformità normativa e responsabilità della governance nei sistemi industriali datati

L’obsolescenza tecnologica non elimina la responsabilità di gestire il rischio.

La presenza di un sistema non aggiornabile deve essere conosciuta, valutata e inserita nei processi di governance, stabilendo quali misure compensative siano necessarie e per quanto tempo l’organizzazione ritenga accettabile mantenere quel rischio.

È proprio la formalizzazione dell’eccezione a distinguere una scelta consapevole da una vulnerabilità semplicemente ignorata.

Obblighi della direttiva NIS2 relativi alla gestione dei sistemi non aggiornabili

La NIS2 non stabilisce uno specifico obbligo secondo cui ogni sistema legacy debba essere aggiornato o sostituito, né disciplina separatamente i PLC non aggiornabili.

Per i soggetti che ricadono nel suo perimetro, la direttiva richiede però misure tecniche, operative e organizzative adeguate e proporzionate per gestire i rischi relativi alla sicurezza dei sistemi informativi e di rete.

Tra gli ambiti previsti rientrano gestione degli incidenti, business continuity e disaster recovery, sicurezza della supply chain, sicurezza nell’acquisizione, sviluppo e manutenzione dei sistemi, gestione e divulgazione delle vulnerabilità, valutazione dell’efficacia delle misure adottate, controllo degli accessi e gestione degli asset.

Per un sistema non aggiornabile, quindi, la questione non è dimostrare semplicemente che “la patch non esiste”.

L’organizzazione deve essere in grado di valutare il rischio e adottare misure proporzionate: segmentazione, restrizioni degli accessi, monitoraggio, procedure di recovery o, quando il rischio non può essere adeguatamente mitigato, pianificazione della sostituzione.

La presenza di un asset legacy diventa così un tema di risk management documentabile, sul quale anche il management deve possedere una visibilità adeguata.

Standard IEC 62443 per il controllo del rischio e la gestione delle eccezioni

La famiglia IEC 62443 offre un riferimento particolarmente utile per affrontare la cyber security degli ambienti industriali nei quali convivono tecnologie moderne e legacy.

L’approccio basato sul rischio consente di partire dall’architettura e dalle caratteristiche del sistema anziché pretendere che ogni componente disponga delle stesse capacità di sicurezza.

I concetti di zone e conduits permettono, ad esempio, di raggruppare asset con caratteristiche e requisiti omogenei e controllare le comunicazioni tra aree differenti.

Questo è particolarmente importante quando un dispositivo non può implementare direttamente determinate funzionalità.

Una parte della protezione può essere trasferita all’architettura circostante attraverso controlli compensativi, purché la soluzione sia coerente con la valutazione del rischio e con i requisiti applicabili al sistema.

La gestione delle eccezioni deve comunque avere una scadenza e un responsabile.

Documentare che un PLC non può essere aggiornato, proteggerlo attraverso misure alternative e rivalutare periodicamente il rischio è molto diverso dal mantenerlo indefinitamente in produzione senza un piano.

Ed è probabilmente questa la questione centrale dei sistemi legacy industriali.

L’obsolescenza non è un incidente improvviso, ma un rischio che cresce nel tempo. Fine del supporto, vulnerabilità, indisponibilità dei ricambi e perdita delle competenze possono accumularsi lentamente fino a rendere il sistema sempre più difficile da proteggere e ripristinare.

La strategia efficace non consiste quindi nel pretendere di eliminare immediatamente ogni tecnologia datata, né nel considerarla sicura soltanto perché continua a funzionare.

Occorre conoscerla, isolarla, monitorarla e pianificarne l’uscita. In una fabbrica nella quale alcuni macchinari possono restare operativi per decenni, la vera misura della maturità cyber non è infatti l’assenza di sistemi legacy, ma la capacità dell’organizzazione di sapere quali rischi sta mantenendo, perché li sta accettando e fino a quando intende farlo.