Sicurezza SCADA e ICS tra persistenza degli attaccanti e opacità dei sistemi legacy
Quando parliamo di sicurezza dei sistemi SCADA e degli ambienti Industrial Control Systems (ICS), ci troviamo di fronte a un paradosso che raramente viene esplicitato con la necessaria chiarezza: stiamo applicando paradigmi di difesa concepiti per l’information technology a infrastrutture progettate in un’epoca in cui la connettività non era nemmeno contemplata come scenario di rischio. Questa discrasia temporale e concettuale non è una semplice curiosità storica, ma rappresenta il nucleo stesso delle vulnerabilità che caratterizzano gli ambienti di controllo industriale.
La convergenza IT-OT, termine divenuto quasi un mantra nel lessico della cybersecurity industriale, nasconde una verità scomoda: non stiamo assistendo a una vera convergenza, quanto piuttosto a una colonizzazione forzata di ecosistemi operativi da parte di tecnologie pensate per contesti radicalmente diversi. I sistemi SCADA che gestiscono infrastrutture critiche – dalle reti elettriche agli impianti di trattamento delle acque, dai processi petrolchimici ai sistemi di trasporto – sono nati in un paradigma di sicurezza basato sull’isolamento fisico e sull’oscurità attraverso la segretezza. L’air gap era la strategia difensiva per eccellenza, e la proprietà dei protocolli industriali garantiva una forma di sicurezza attraverso l’opacità.
Questo paradigma è stato progressivamente eroso non solo dalla necessità di interconnessione per finalità di efficienza operativa e manutenzione remota, ma anche dall’inevitabile obsolescenza tecnologica. I sistemi ICS hanno cicli di vita che possono estendersi per decenni, ben oltre qualsiasi orizzonte temporale concepibile per le tecnologie IT. Ne deriva una situazione in cui controllori logici programmabili (Programmable Logic Controller, PLC) che risalgono agli anni Novanta coesistono con interfacce web moderne, creando superfici d’attacco ibride che sfidano i tradizionali modelli di threat modeling.
Vulnerabilità endemiche: oltre la superficie del CVE
La narrazione comune sulla sicurezza ICS tende a concentrarsi sulle vulnerabilità software catalogate nei database CVE (Common Vulnerabilities and Exposures), sulle patch mancanti, sui protocolli industriali privi di autenticazione. Questa prospettiva, pur tecnicamente accurata, rischia di essere riduttiva. Le vulnerabilità più insidiose dei sistemi SCADA non risiedono necessariamente in falle di codice sfruttabili con exploit preconfezionati, ma nella stessa architettura epistemologica che sottende questi sistemi.
Consideriamo la questione dell’autenticazione nei protocolli industriali legacy come Modbus, DNP3 o IEC 60870-5-104. L’assenza di meccanismi crittografici in questi standard non è un difetto di progettazione nel senso convenzionale del termine: è la conseguenza di requisiti funzionali che privilegiavano la deterministica temporale, la semplicità di implementazione e la resilienza operativa rispetto a qualsiasi considerazione di sicurezza informatica. Questi protocolli, progettati decenni fa, non prevedevano autenticazione, trasmettevano in chiaro e operavano in ambienti considerati fisicamente isolati. Quando un PLC Modbus risponde a qualsiasi comando ricevuto senza verificare l’identità del mittente, non sta “sbagliando” – sta operando esattamente secondo le specifiche per cui è stato progettato.
La vulnerabilità vera, allora, non è tecnica ma sistemica: risiede nel fatto che questi protocolli sono oggi esposti a contesti di minaccia per i quali non erano stati concepiti. L’implementazione di wrapper crittografici o di soluzioni di network segmentation, per quanto necessarie, rappresentano toppe applicate a posteriori su una superficie che non era stata pensata per riceverle. Questo genera nuove categorie di rischi: l’overhead computazionale dei meccanismi di sicurezza può introdurre latenze incompatibili con i requisiti real-time dei processi industriali, mentre la complessità aggiuntiva aumenta la superficie di errori di configurazione.
Un’altra categoria di vulnerabilità frequentemente sottovalutata riguarda la dimensione fisica degli ambienti OT (Operational Technology). A differenza degli attacchi puramente informatici, gli scenari di compromissione ICS possono includere vettori che combinano accesso fisico e manipolazione digitale. La modifica di setpoint su un PLC accessibile fisicamente in un impianto poco presidiato, la sostituzione di sensori per fornire letture alterate, l’inserimento di dispositivi rogue nella rete industriale durante interventi di manutenzione: questi sono vettori d’attacco che sfuggono ai perimetri difensivi tradizionali e richiedono un approccio olistico che integri physical security, supply chain security e cybersecurity in senso stretto.
APT su ICS: anatomia di una persistenza strategica
Gli attacchi Advanced Persistent Threat (APT) che prendono di mira ambienti ICS si caratterizzano per elementi distintivi rispetto alle campagne APT convenzionali rivolte a reti corporate. La differenza fondamentale risiede negli obiettivi: mentre un’APT tradizionale mira tipicamente all’esfiltrazione di dati o all’accesso persistente per spionaggio, un’APT su ICS può avere finalità di sabotaggio, di preparazione del campo di battaglia per scenari di conflitto ibrido, o di intelligence sulla capacità di infrastrutture critiche avversarie.
L’analisi di casi paradigmatici come Stuxnet, Industroyer (anche noto come Crashoverride), Triton (anche denominato Trisis o Hatman) e gli attacchi attribuiti al gruppo Sandworm rivela pattern operativi ricorrenti che meritano attenzione analitica. La fase di reconnaissance in un’APT su ICS è significativamente più lunga e metodica rispetto agli attacchi informatici convenzionali. Gli attaccanti devono acquisire non solo competenze tecniche sui sistemi target, ma anche una comprensione profonda dei processi industriali che governano.
Nel caso di Stuxnet, scoperto nel 2010, gli operatori hanno dimostrato una conoscenza dettagliata delle centrifughe per arricchimento dell’uranio dell’impianto di Natanz in Iran e dei loro profili operativi. Il malware, sviluppato nell’ambito dell’Operation Olympic Games (attribuita a Stati Uniti e Israele), manipolava la velocità delle centrifughe da 1.064 Hz a 1.410 Hz e poi a 2 Hz, causando stress meccanico e danneggiamento di circa 1.000 centrifughe. Il worm sfruttava quattro vulnerabilità zero-day di Windows e mirava specificamente ai PLC Siemens S7-300 che controllavano i convertitori di frequenza. Particolarmente sofisticato era il meccanismo di man-in-the-middle che falsificava i dati dei sensori, facendo credere agli operatori che tutto funzionasse normalmente mentre le centrifughe venivano danneggiate.
Industroyer, utilizzato nell’attacco del 17 dicembre 2016 contro la rete elettrica ucraina, ha lasciato al buio circa un quinto di Kiev per oltre un’ora. A differenza di Stuxnet, questo malware non sfruttava vulnerabilità specifiche, ma agiva direttamente sui quattro protocolli di comunicazione utilizzati nelle sottostazioni elettriche (IEC 60870-5-101, IEC 60870-5-104, IEC 61850 e OPC DA). L’attacco era completamente automatizzato e rappresentava un’evoluzione significativa rispetto al precedente attacco del 2015 condotto con BlackEnergy, che richiedeva intervento manuale. Il framework modulare di Industroyer lo rendeva facilmente adattabile ad altre reti elettriche nel mondo.
Triton, scoperto nel 2017 presso un impianto petrolchimico in Arabia Saudita, rappresenta un caso particolarmente allarmante poiché mirava ai sistemi di sicurezza strumentata (Safety Instrumented Systems, SIS) Triconex di Schneider Electric. Questi sistemi sono progettati per prevenire incidenti catastrofici in ambienti industriali ad alto rischio. Il malware sfruttava una vulnerabilità zero-day nel firmware Triconex (versioni 10.0-10.4) e utilizzava il protocollo proprietario TriStation per comunicare con i controllori. L’attacco, tuttavia, non raggiunse il suo obiettivo finale a causa di un bug nel codice del malware stesso, che causò lo shutdown automatico dell’impianto per sicurezza, permettendo così la scoperta della compromissione. L’incidente evidenziò come un attacco riuscito avrebbe potuto causare il rilascio di sostanze tossiche o esplosioni con conseguenze potenzialmente letali.
Il gruppo Sandworm, attribuito all’unità militare russa GRU 74455, è responsabile di una serie prolungata di attacchi alle infrastrutture critiche ucraine dal 2015 in poi. Il gruppo ha utilizzato malware come BlackEnergy (attacco alla rete elettrica ucraina del dicembre 2015), Industroyer (dicembre 2016), NotPetya (giugno 2017, con danni globali stimati in oltre 10 miliardi di dollari), e più recentemente Industroyer2 (aprile 2022). L’approccio di Sandworm combina malware specifici per ICS con wiper per ostacolare il recupero, dimostrando una strategia di attacco multilivello particolarmente distruttiva.
La catena di attacco tipica prevede un ingresso attraverso la rete corporate (spesso mediante spear phishing o compromissione di fornitori), seguito da una fase di lateral movement che richiede il superamento delle segmentazioni tra IT e OT. Questa transizione è il momento critico dell’attacco e spiega perché le tecniche di compromissione dei jump host, delle engineering workstation e dei punti di accesso remoto siano così centrali nelle kill chain documentate. Una volta raggiunto l’ambiente OT, l’attaccante deve navigare architetture spesso prive di logging dettagliato, in cui l’installazione di malware persistente può avvenire con minori ostacoli rispetto agli ambienti IT altamente monitorati.
Un aspetto frequentemente trascurato nella discussione sulle APT ICS riguarda la dimensione temporale della persistenza. In ambienti corporate, la persistenza di un attaccante si misura in settimane o mesi. In ambienti ICS, può estendersi per anni. La stabilità operativa dei sistemi industriali, la riluttanza a effettuare riavvii o aggiornamenti che potrebbero interrompere la produzione, e la scarsa visibilità sulle anomalie comportamentali rendono possibile una permanenza prolungata che consente agli attaccanti di affinare la loro comprensione dell’ambiente e prepararsi per l’attivazione del payload in momenti strategicamente scelti.
Detection Engineering: limiti epistemologici e nuovi paradigmi
La detection di attività anomale in ambienti ICS solleva questioni metodologiche che vanno oltre la mera applicazione di tecnologie di sicurezza. Il principio fondamentale della detection basata su firme (signature-based), pilastro della sicurezza IT, mostra evidenti limiti in contesti dove i payload sono customizzati per target specifici e gli indicatori di compromissione hanno breve durata di vita. Le signature-based detection possono identificare varianti note di malware ICS, ma risultano inerti di fronte a zero-day tailored.
La detection anomaly-based, che rappresenta la frontiera evolutiva, si scontra però con un problema epistemologico: cosa costituisce “normale” in un ambiente ICS? A differenza delle reti IT, dove i pattern di traffico possono essere modellati statisticamente con relativa precisione, gli ambienti operativi presentano variabilità legate ai processi fisici controllati. Un impianto chimico ha profili operativi diversi a seconda della fase di produzione, delle condizioni ambientali, della domanda di output. Stabilire baseline comportamentali richiede una comprensione profonda del processo industriale stesso, non solo della dimensione cyber.
I protocolli di detection più promettenti integrano quindi approcci multi-layer: traffic analysis sui protocolli industriali per identificare anomalie di comunicazione (comandi non autorizzati, modifiche a setpoint, polling patterns inusuali), behavioral analysis sui sistemi di controllo per rilevare deviazioni dai pattern operativi normali, e process-aware detection che correla eventi cyber con dati dei sensori fisici per identificare manipolazioni che mirino a alterare il processo controllato mascherando le tracce digitali.
Un esempio paradigmatico di questa ultima categoria è rappresentato dalla detection di attacchi che manipolano i sensori per nascondere l’effetto fisico delle azioni maligne sui controllori. Se un attaccante modifica i comandi a una pompa ma simultaneamente falsifica i dati del flow meter, la detection puramente cyber potrebbe non rilevare l’anomalia. È necessaria una correlazione tra il comando inviato, l’energia consumata dalla pompa (dato tipicamente disponibile tramite smart meter o sottostazioni elettriche) e il flusso misurato per identificare la discrepanza.
Dal punto di vista forense, gli ambienti ICS presentano sfide uniche. La carenza di logging dettagliato, tipica di molti sistemi legacy, rende difficoltosa la ricostruzione delle timeline di attacco. I dati che vengono loggati sono spesso limitati a eventi operativi (allarmi di processo, cambi di stato) piuttosto che eventi di sicurezza. L’implementazione di soluzioni di centralized logging specifiche per OT (come i collector che parlano nativamente protocolli industriali e traducono gli eventi in formati SIEM-friendly) sta progressivamente migliorando questa situazione, ma rimane una sfida di deployment in ambienti dove l’inserimento di nuovi componenti di rete può richiedere lunghe validazioni e fermi impianto programmati.
La network forensics in ambiente ICS richiede competenze ibride: la capacità di analizzare capture di traffico Modbus o DNP3 per identificare comandi malformati o sequenze anomale deve combinarsi con la comprensione di cosa quei comandi significhino dal punto di vista del processo controllato. Un comando di apertura di una valvola può essere perfettamente legittimo in un contesto operativo e catastrofico in un altro; distinguere i due casi richiede knowledge engineering che vada oltre la pura analisi di network packets.
Dimensioni legali e responsabilità: il vuoto normativo operativo
Dal punto di vista del diritto digitale e della cyber law, gli ambienti ICS si collocano in una zona grigia particolarmente insidiosa. Le normative di cybersecurity settoriali stabiliscono requisiti di sicurezza, ma la loro implementazione pratica si scontra con le specificità operative degli ambienti industriali.
In ambito europeo, la Direttiva NIS2 (Direttiva UE 2022/2555), entrata in vigore il 17 gennaio 2023 e recepita dagli Stati membri entro ottobre 2024, rappresenta un passo importante verso un quadro normativo più robusto. La direttiva amplia significativamente il perimetro rispetto alla precedente NIS, includendo nuovi settori critici e introducendo obblighi più stringenti per soggetti essenziali e importanti. Tuttavia, l’applicazione retroattiva del principio di “security by design” a infrastrutture esistenti da decenni rimane più un’aspirazione che una possibilità concreta.
Negli Stati Uniti, gli standard NERC CIP (North American Electric Reliability Corporation Critical Infrastructure Protection) stabiliscono requisiti obbligatori per le utility elettriche che operano sul Bulk Electric System. Sviluppati a seguito del grande blackout del 2003 e approvati dalla Federal Energy Regulatory Commission (FERC) nel 2008, gli standard NERC CIP coprono 13 aree specifiche (da CIP-002 a CIP-014) che spaziano dall’identificazione degli asset critici alla gestione degli incidenti, dalla sicurezza fisica alla supply chain security. Il framework è prescrittivo e prevede sanzioni significative in caso di non conformità, ma la sua applicazione pratica richiede investimenti sostanziali e una trasformazione culturale delle organizzazioni.
La questione della responsabilità in caso di incidente cyber su ICS solleva interrogativi giuridici complessi. Se un attacco a un sistema SCADA causa danni fisici o feriti, la catena di responsabilità non è lineare: si articola tra il gestore dell’infrastruttura (che potrebbe aver omesso misure di sicurezza adeguate), i fornitori dei sistemi (che possono aver commercializzato prodotti con vulnerabilità note), i provider di servizi di sicurezza (che potrebbero non aver rilevato l’intrusione), e ovviamente gli attaccanti stessi (spesso attori statali o state-sponsored, quindi difficilmente perseguibili).
La disclosure di vulnerabilità in sistemi ICS rappresenta un altro nodo critico. A differenza del software consumer, dove la coordinated disclosure è pratica consolidata, le vulnerabilità ICS sollevano questioni di sicurezza nazionale. La pubblicazione di dettagli su una vulnerabilità in un sistema SCADA ampiamente deployed in infrastrutture critiche può de facto fornire una blueprint per attacchi su larga scala. Questo genera tensioni tra il principio di trasparenza, necessario per permettere ai difensori di proteggersi, e la necessità di non armare potenziali attaccanti.
Dal punto di vista della digital forensics nei procedimenti legali, la chain of custody delle evidenze da ambienti ICS presenta peculiarità: i dati possono risiedere su sistemi che non possono essere spenti per imaging tradizionale senza interrompere processi produttivi critici. Le metodologie di live forensics, già complesse in ambienti IT, diventano ulteriormente problematiche quando applicate a sistemi industriali real-time dove anche l’overhead di un’acquisizione di memoria può avere impatti operativi.
Quando la sicurezza assoluta è un’illusione: il paradigma della resilienza
La sicurezza dei sistemi SCADA e ICS richiede l’elaborazione di un framework epistemologico che superi la semplice trasposizione di paradigmi IT. Serve un approccio che integri nativamente la dimensione fisica del processo controllato, che accetti la coesistenza di tecnologie legacy con moderne soluzioni di sicurezza, che bilanci i requisiti di availability (prioritari in OT) con quelli di confidentiality (prioritari in IT).
Le tecniche di detection più efficaci saranno quelle che incorporano domain knowledge specifico del processo industriale, che utilizzano machine learning non per sostituire ma per aumentare le capacità di analisti con competenze OT. La forensics dovrà sviluppare metodologie specifiche per la preservazione di evidenze in sistemi che non possono essere fermati, per la ricostruzione di eventi in ambienti poveri di log, per la correlazione tra tracce digitali e impatti fisici.
Dal punto di vista normativo, servono framework che riconoscano la specificità degli ambienti OT senza creare vuoti di protezione. La sfida non è solo tecnica o legale, ma culturale: richiede la formazione di professionisti che parlino fluentemente sia il linguaggio della cybersecurity che quello dell’ingegneria di processo, che comprendano tanto i vettori d’attacco informatici quanto le dinamiche dei sistemi di controllo.
La sicurezza ICS rappresenta, in definitiva, un campo in cui la complessità tecnica si intreccia con implicazioni geopolitiche, questioni legali irrisolte e sfide operative concrete. È un dominio in cui l’eccellenza richiede umiltà: la consapevolezza che non esistono soluzioni universali, che ogni ambiente industriale è un ecosistema unico, e che la sicurezza assoluta è un’illusione. L’obiettivo realistico è la resilienza: la capacità di rilevare, contenere e recuperare da compromissioni che, in un mondo interconnesso, non sono più questione di “se” ma di “quando”.
Fonti:
Direttiva (UE) 2022/2555 (NIS2) sulla sicurezza delle reti e dei sistemi informativi
NERC CIP Standards – Critical Infrastructure Protection for Bulk Electric Systems
