Sicurezza ICS/OT/IoT: sfide e strategie di protezione

È tempo di tornare a parlare del mondo ICS/OT perché ha delle peculiarità che ne influenzano processi e strumenti.

Per prima cosa raggrupperei questo vasto mondo in categorie:

sistemi localizzati all’interno di un’area ridotta (edificio, campus)
sistemi distribuiti geograficamente ma accessibili tramite reti protette/dedicate (spesso i sistemi SCADA rientrano in questa tipologia)
sistemi distribuiti geograficamente e collegati ad Internet senza possibilità di controlli aggiuntivi (spesso i sistemi IoT rientrano in questa tipologia).

Ho scelto questa suddivisione perché, come vedremo nei post seguenti, determina le nostre possibilità di mitigare i rischi implementando misure di sicurezza aggiuntive. Chiaramente ci sono altre categorizzazioni che dovremmo fare (ad esempio basandoci sul rischio), ma questa è quella che vorrei usare come base di partenza.

Sempre in base alla mia esperienza vorrei dire che la maggior parte dei sistemi ICS/OT/IoT hanno una vita più lunga di quanto lo sia il supporto dei singoli componenti. E questo a mio parere è fondamentale per pianificare una strategia realistica. Anche se, come previsto da alcune normative, i componenti sono aggiornabili, ci troveremo prima o poi nella situazione di dover proteggere componenti che non sono più venduti, supportati, mantenuti.

Tempo di vita vs tempo supporto

Abbiamo accennato al fatto che, nella mia esperienza, vedo sistemi ICS/OT/IoT attivi per un tempo superiore a quanto previsto dai fornitori dei singoli componenti. O, in altre parole, i componenti (il software in particolare, ma non solo) non sono più supportati ma il sistema integrato viene ancora usato.

Chi bazzica il mondo industriale, medicale, navale, oil&gas… (vorrei dire anche bancario) lo sperimenta quotidianamente: i sistemi sono basati su componenti (ad esempio Windows) e risultano attivi ben oltre la data ultima di supporto. Questo è inevitabile per tre ragioni:

I sistemi di cui sopra sono generalmente intoccabili: non è prevista alcuna modifica, alcun aggiornamento perché non se ne conoscono gli effetti. In alcuni casi ho fornitori sconsigliare vivamente di aggiornare prodotti certificati IEC62443, sebbene la normativa ne prevedesse la funzionalità.
Molti sistemi di cui sopra hanno un costo di acquisto molto elevato (in termini di M o decine di M). La dismissione o il semplice refit ha dei costi non giustificabili per un impianto che funziona (inteso come svolge il suo lavoro).
Mi è capitato spesso di vedere impianti funzionanti forniti da aziende fallite e quindi senza alcun supporto. Anche qui il costo di acquisto di un impianto nuovo non è giustificato.

I tre punti di cui sopra nascono principalmente dall’approccio delle aziende e delle persone che progettano tali impianti. Tali sistemi sono progettati per svolgere il loro lavoro in sicurezza anche sotto stress. Ma… nel momento che abbiamo cominciato a parlare di Industry 4.0 e abbiamo cominciato a connettere impianti progettati per lavorare ad una rete IP, abbiamo introdotto un nuovo rischio: il rischio Cyber.

Parlando con fornitori e clienti di sistemi ICS/OT/IoT mi rendo conto che il rischio Cyber non sia nemmeno preso in considerazione. A dirla tutta, da professionista, trovo bizzarre alcune scelte topologiche.

In questo senso produttori e integratori devono ancora realmente prendere in mano le implicazioni di aver portato su IP e aver connesso ad Internet, tecnologie che sono particolarmente fragili (sempre dal punto di vista Cyber ovviamente).

Visto il tema aggiungerei che il mondo normativo sta prendendo una certa direzione (vedi NIS, regolamento macchine, IMO…). Vedremo finalmente dei risultati concreti? Personalmente non sono così ottimista.

Tempo di vita dei componenti

Abbiamo parlato di normative e realtà. Vediamo ora qualche esempio che dimostra che il tempo di vita dei componenti non può che essere inferiore al tempo di vita dell’impianto. Come detto precedentemente ci basiamo sul fatto che un impianto continua ad essere utilizzato fintanto che non si guasta e la riparazione risulta antieconomica rispetto all’acquisto di un nuovo sistema.

Vediamo qualche esempio.

Bluetooth

Nel mondo ICS, negli ultimi anni sto notando una preferenza per l’uso di Bluetooth per semplificare attività di riconfigurazione degli impianti. In particolare Bluetooth viene usato per remotizzare parte della comandistica (non di emergenza). In questo caso dovremmo considerare i rischi introdotti da un protocollo wireless, ma per limitiamoci per il momento a considerare le varie release del protocollo. Un nuovo standard del protocollo Bluetooth viene rilasciato ogni 2-3 anni circa. Questo significa che in un impianto industriale con una durata di 15 anni possiamo trovare release del protocollo molto vecchie e forse vulnerabili.

WiFi

Un discorso analogo vale per lo standard WiFi che invece è già da anni utilizzato in ambito ICS per gestire le parti mobili. Per quanto riguarda la sicurezza, in poco meno di 20 anni, abbiamo visto nel tempo quattro standard (WEP, WPA, WPA2, WPA3) che si sono susseguiti per sanare problematiche di sicurezza.

È molto facile oggigiorno trovare impianti ICS basati su WEP, dove la rete WiFi è un’estensione della rete di campo cablata.

HMI

Ancora oggi la quasi totalità dei sistemi HMI che vedo è basata su Microsoft Windows. Partendo da Windows XP, in 23 anni abbiamo visto 6 diverse versioni, una ogni 4 anni circa. Come in precedenza è altrettanto facile trovare impianti ICS/OT basati ancora su Windows XP.

E come ha dimostrato il recente passato, esistono impianti con versioni ancora più vecchi, rilasciate più di 30 anni fa, e, appunto, il fatto che siano vecchi non significa automaticamente che debbano essere sostituiti.

Passando invece ad Ubuntu, che noto abbastanza diffuso, una LTS ha una durata di circa 5 anni. Considerando che nessuno sviluppo è allineato con l’ultima release, possiamo ipotizzare che un impianto di circa 3 anni sia già fuori supporto. E questo non impatta solo i sistemi ICS, ma tipicamente anche quelli OT e IoT.

Vulnerability management

Gestire vulnerabilità non significa per forza aggiornare. Gestire vulnerabilità significa gestirne il rischio. E il rischio può essere gestito inserendo misure di sicurezza aggiuntive che lo riducano.

Quando mi trovo a fare dei vulnerability assessment, generalmente sconsiglio di farlo sulla parte ICS/OT. Questo per tre ragioni:

I sistemi ICS/OT sono estremamente fragili ed è assai probabile (direi certo) che una attività di VA influisca negativamente sui sistemi.
I sistemi ICS/OT generalmente sono intoccabili. Questo significa che anche se troviamo delle vulnerabilità, non possiamo mitigarle mediante aggiornamenti o EDR.
Come già detto i sistemi ICS/OT hanno una vita molto lunga, è quindi probabile (direi certo) che troveremo vulnerabilità dovute a sistemi obsoleti.

Il punto dove voglio arrivare è che in ambito ICS/OT possiamo dare per certo che ci siano vulnerabilità gravi non sanabili. Partendo da questo assunto (che nella mia esperienza è sempre risultato vero), possiamo sviluppare la nostra strategia.

Nel mondo IoT possiamo trarre simili deduzioni, con una complicazione: i sistemi IoT sono generalmente collegati direttamente ad Internet, con tutte le conseguenze del caso.

Strategie di difesa

Abbiamo visto che possiamo arrivare ad un assunto: i sistemi ICS/OT sono vulnerabili e non sanabili. Nel nostro piano di vulnerability management non possiamo fare affidamento sul patching. Non ci resta che costruire una serie di layer che riducano il rischio in modo adeguato.

Per prima cosa partirei dal cosiddetto Purdue model che ci offre una base per approcciare correttamente il problema. In linea generale non dovrebbe esistere traffico diretto da reti OT a reti IT/Internet e viceversa. Il condizionale è d’obbligo perché la mia esperienza mi dice che il Purdue model oggi non è applicabile. Spesso trovo sistemi ICS/OT che hanno necessità (contrattuale, non tecnica) di accedere direttamente a indirizzi Internet.

Il mio approccio oggi è quello di creare un perimetro di sicurezza particolarmente stringente attorno al mondo ICS/OT, ispirandomi a concetto di ZTA (Zero Trust Architecture). In particolare una combinazione di firewall e IDS mi permettono di controllare l’ingresso ai sistemi ICS/OT e in generale qualsiasi anomalia si presenti all’interno delle reti. Detta così sembra semplice tuttavia occorre considerare che:

molti sistemi ICS/OT risiedono assieme su enormi reti (ho visto migliaia di IP su una singola rete 10.0.0.0/8)
quello che vediamo non è necessariamente quello che c’è (esistono numerosi gateway 3/4/5G che implementano un accesso Internet indipendente, invisibile che termina direttamente nella rete ICS/OT)
in molti ambienti, per contratto, vengono installati dei terminatori VPN always on che permettono l’assistenza remota (e, una volta individuati, questi forse sono il male minore).

La sicurezza ICS/OT passa quindi per un assessmet che permetta di capire quanto è caotica la situazione e quali siano le possibili strade.

Segmentazione delle reti

Abbiamo visto alcune criticità da considerare all’interno di una corretta strategia per la sicurezza. Uno in particolare merita un approfondimento che risulterà, nella maggior parte dei casi, non praticabile.

Abbiamo visto che spesso i sistemi ICS/OT dell’azienda risiedono tutti all’interno di un’unica rete, spesso abbastanza larga. Questo significa che una compromissione di un singolo componente espone tutti i sistemi allo stesso rischio. Sappiamo anche che i sistemi ICS/OT sono intoccabili e non è possibile proporre un cambio di indirizzamento. In questo caso ci vengono in aiuto tecnologie che ci permettono di segmentare in modo trasparente reti L2. Personalmente ho avuto esperienza con la funzionalità di VLAN Insertion proposta da Palo Alto Networks. Vendor diversi hanno implementazioni simili che si pongono lo stesso scopo: segmentare/microsegmentare una rete L2 in modo trasparente.

Il motivo per cui considero questa misura di sicurezza poco praticabile, sta nel fatto che il mondo produttivo è spesso sotto la responsabilità dell’OT Manager che, appunto, viene dal mondo OT e non dal mondo IT. Noto un certo scetticiscmo, per non dire paura, quando vengono proposte “tecnologie IT” nel mondo OT. Il risultato è che l’OT Manager si oppone facendo ricadere la responsabilità di qualsiasi fermo di produzione su chi altera la topologia.

Se in alcuni casi ho visto persone mettersi davanti ad un tavolo cercando un compromesso che soddisfi tutte le parti, in molti casi nessuno vuole accettare il rischio di modificare lo status quo e tutto rimane come prima.

Accesso alle reti

Precedentemente abbiamo parlato di come segmentare le reti ICS riducendo l’impatto in caso di compromissione, tocchiamo ora un argomento tanto di moda quando delicato. L’idea delle soluzioni NAC è quella di poter abilitare alla rete i dispositivi permessi, lasciando fuori tutti gli altri. In pratica però ci sono delle riflessioni da fare:

il fatto che un dispositivo sia ammesso, non riduce la possibilità che esso sia compromesso;
le soluzioni NAC oggi si basano sul protocollo 802.1x e su una serie di compromessi nel caso tale protocollo non possa essere usato.

E proprio nel mondo ICS troviamo la maggior parte dei dispositivi (vorrei dire la totalità) che non parla 802.1x e che quindi necessita di compromessi, come MAB. Inoltre occorre tenere presente il rischio dei dispositivi “silenti”, ossia quelli che tendono a ricevere traffico più che a mandarne: i dispositivi “silenti” potrebbero richiedere ulteriori compromessi.

Non sto demonizzando le soluzioni di NAC, ma vorrei far riflettere sul fatto che la sicurezza è fatta a layer, le soluzioni di NAC ne implementano uno, e come qualsiasi misura di sicurezza ha degli impatti. Ulteriori riflessioni le trovate nella puntata 802.1x bypass nel podcast che tengo con podcast.

Sicurezza del codice

Infine volevo trattare un argomento ancora molto di nicchia (putroppo): la sicurezza del codice in ambito PLC. Sappiamo che una parte delle vulnerabilità relative ai PLC è causata da come essi sono programmati. Su questo possiamo agire, o meglio prevenire, scrivendo un codice corretto. Non è assolutamente il mio mestiere, quindi vi lascio le Top 20 Secure PLC Coding Practices e vi invito a seguire su LinkedIn Sarah Flucks.