Il percorso verso la sicurezza OT
Come orientare gli investimenti e cosa serve davvero
Ciao, sono Ale.
Il vendor di segmentazione ti dice che hai bisogno della sua piattaforma; il vendor di monitoring ti spiega che senza visibilità sei cieco; il vendor di threat detection ti mostra quanto sei vulnerabile.
Hanno tutti ragione, su un punto specifico, ma hanno tutti torto se pensano che comprare una singola tecnologia risolva il problema della sicurezza OT.
Le soluzioni puntuali possono essere ottimi passi avanti, ma quello che serve, come sempre, è un po’ di metodo.
Nell’IT abbiamo avuto il tempo di evolvere i nostri modelli gestionali assieme all’evolvere della complessità degli ambienti e delle minacce; ora dobbiamo fare lo stesso nell’OT ma in tempi decisamente più compressi.
A darci una grossa mano sono strumenti, come lo standard di riferimento internazionale IEC 62443, che mettono un po’ d’ordine nella lista di cose da fare e che ho usato come base teorica per questa newsletter.
Cosa abbiamo imparato nell’IT
Nell’IT abbiamo consolidato una cultura della sicurezza che oggi diamo per scontata.
Abbiamo l’inventario dei dispositivi, sappiamo gestire il patching, monitoriamo le vulnerabilità, abbiamo un framework dentro il quale ragionare quando dobbiamo aggiungere una funzione o coprire un nuovo bisogno.
È questo framework a permetterci di risolvere i problemi, e a integrare le tecnologie nel nostro ambiente, non le tecnologie in sé. Quando oggi nell’IT valutiamo una nuova tecnologia di sicurezza, sappiamo dove inserirla e quale gap deve aiutarci a chiudere.
Come nel mio sport, lo sci alpinismo, vengono prima la padronanza della tecnica e la capacità di pianificazione di una gita, e poi il modello di sci d’ultima gamma, quando abbiamo anche la capacità di distinguere le differenze tra un modello e l’altro, così nell’IT vengono prima le competenze, i processi e la visibilità e dopo i prodotti inseriti nel nostro contesto per quella feature esatta che ci risolve quell’esatto bisogno.
Nell’OT questo contesto non esiste ancora
La sicurezza OT è relativamente nuova come disciplina organizzata.
Gli ambienti operativi sono stati progettati per funzionare, non per essere sicuri. Prima la protezione era garantita dall’isolamento fisico: se la rete OT non era connessa al resto del mondo, non servivano le stesse misure di sicurezza dell’IT. Invece ora l’isolamento non esiste più. Le reti OT sono connesse, integrate, esposte.
Dobbiamo costruire quel contesto in cui muoverci consapevolmente che nell’IT abbiamo impiegato vent’anni a sviluppare, ma dobbiamo farlo in tempi molto più brevi.
Il problema è che molte organizzazioni saltano i passaggi fondamentali.
Vedono il rischio, cercano la soluzione, comprano la tecnologia. Ma senza il framework di base, quella tecnologia non può produrre i risultati attesi.
Inoltre, se il livello più alto dell’architettura OT non è adeguatamente protetto, è difficile salvaguardare anche i livelli sottostanti, rischiando di installare un’accozzaglia di dispositivi inutilmente.
Lo standard parla di “Defense in Depth”, in cui la sicurezza deve avvenire ed essere garantita in modo stratificato per ciascun layer, e non può essere in carico a pochi dispositivi vista l’eterogeneità dei collegamenti e delle comunicazioni tra sistemi.
Questo riduce la probabilità che, durante un attacco, tutto il sistema venga danneggiato, visto che ogni livello viene protetto.
La cultura che serve
Il percorso, come sempre, inizia “a secco” prima dell’acquisto di qualsiasi tecnologia. Inizia con domande semplici e fondamentali:
Primo: sai cosa hai? Hai l’inventario completo dei dispositivi OT, dei controller, dei sensori, delle connessioni?
Molte organizzazioni scoprono dispositivi che non sapevano di avere quando fanno il primo assessment, o più semplicemente si accorgono di quanto sia una superficie di attacco sensibile il traffico OT off-net che non passa per i gateway perimetrali o che non ci sono controlli sui protocolli proprietari.
Secondo: e per quanto riguarda la sicurezza fisica? come è gestita? Sì, perché nell’OT la sicurezza fisica/prossimale conta più che nell’IT. L’accesso fisico a un PLC può compromettere un intero processo produttivo. Alzare il livello di protezione fisica è un prerequisito, non un optional e visto il design delle reti OT non è raro trovare AP di terzi, modem 4G, laptop collegati alle linee.
Lo standard sottolinea e differenzia le misure di sicurezza che un asset owner dovrebbe garantire o quanto meno valutare in sede di risk assessment, prevedendo diverse escalation di livelli di sicurezza raggiungibili e lasciando intendere che la limitazione fisica degli accessi sia importante tanto quanto la limitazione tramite firewall.
Terzo: quali strumenti usare? Solo dopo aver costruito visibilità e controllo di base ha senso introdurre tecnologie specializzate di monitoring avanzato, threat detection.
Mentre, in parallelo o come approccio di base è un punto chiave la segmentazione. Il concetto fondamentale dello standard è, infatti, la separazione, ove possibile, dell’ambiente IT da quello OT, segmentando il sistema in Zone per raggruppare asset con le stesse caratteristiche di sicurezza.
Questo permette di porre una base di sicurezza per l’ambiente OT garantendo che tutti i sistemi abbiano un livello di sicurezza minimo adeguato al rischio associato.
Come abbiamo già visto parlando di NIS2, anche in questo caso, la IEC non fa riferimento a un livello di sicurezza generale, ma sottolinea che questo deve essere specifico per ogni asset e valutato in sede di risk assessment.
Inoltre, una delle linee guida dello standard prevede di riportare i livelli di sicurezza per ogni dispositivo inserito all’interno delle varie Zone, permettendo all’asset owner e al service provider di focalizzarsi sui livelli di sicurezza specifici che non si sono raggiunti e che devono essere raggiunti per assicurare un livello di salvaguardia maggiore.
Perché non funziona comprare la soluzione
Se compri una piattaforma di segmentazione OT senza avere l’inventario completo dei dispositivi, come fai a segmentare correttamente?
Se introduci monitoring avanzato senza conoscere i pattern di traffico normali, come distingui le anomalie dal rumore?
Se implementi threat detection senza aver alzato la sicurezza fisica di base, stai proteggendo la porta mentre lasci la finestra aperta.
La tecnologia è l’ultimo anello della catena, non il primo.
E questo vale ancora di più nell’OT che nell’IT, perché gli ambienti OT hanno vincoli specifici: disponibilità come priorità assoluta, impossibilità di fermare i processi per fare manutenzione, dispositivi legacy che non possono essere aggiornati, accessi di terzi, ambienti difficili da presidiare fisicamente.
Costruire il framework
Il framework della sicurezza OT si costruisce per strati. Ogni strato supporta quello successivo.
Base: visibilità completa. Sai cosa hai, dove si trova, come comunica, con chi comunica. Un buon inventario dei sistemi è necessario per la sicurezza. La stessa IEC lo indica come un passaggio fondamentale per eseguire un risk assessment completo.
Primo strato: controllo degli accessi. Chi può accedere fisicamente e logicamente ai sistemi OT, con quali permessi, in quali condizioni.
Secondo strato: gestione delle vulnerabilità. Fare patching con la frequenza tipica degli ambienti IT e con le stesse modalità è rischioso, se non addirittura impossibile. Lo standard definisce un programma strutturato e documentato per le patch (SPMP), fondamentale da conoscere per gestire le vulnerabilità in modo sicuro.
Terzo strato: segmentazione e isolamento. Limiti la superficie d’attacco separando i sistemi critici da quelli meno critici, l’OT dall’IT, i processi tra loro.
Quarto strato: detection e response. Identifichi le anomalie, hai procedure per rispondere, sai come contenere un incidente senza fermare la produzione.
La sicurezza dei sistemi IACS deve essere vista nel suo intero ciclo di vita, dalla fase iniziale di risk assessment alla fase di mantenimento e dismissione. È la stessa IEC che lo prevede, riconoscendo nei sistemi IACS l’importanza di garantire continuità operativa lungo la sua intera catena funzionale.
Insomma, ogni strato richiede competenze, processi, governance. La tecnologia entra in ogni strato, ma non è il punto di partenza.
Da dove iniziare
Se devi costruire o migliorare la sicurezza OT nella tua organizzazione, il primo passo, da standard, non è sfogliare brochure o fare demo. È fare l’assessment. Capire dove sei, cosa hai, quali sono i gap più critici.
Il secondo passo è definire le priorità basandoti sul rischio reale. Quali sistemi, se compromessi, causano il danno maggiore? Quali sono più esposti? Quali hanno vulnerabilità note e non mitigabili?
Il terzo passo è costruire le competenze interne. La sicurezza OT richiede persone che capiscono sia l’OT che la sicurezza. Questa combinazione è rara, va coltivata.
Il nostro consiglio pragmatico è, parallelamente, iniziare con quello che hai a disposizione: uso puntuale dei firewall, sicurezza all’edge se hai una LAN evoluta, sistemi NAC.
Solo dopo arrivano gli investimenti in tecnologie puntuali e quando arrivano sai esattamente dove inserirle, cosa devono fare, come misurarne l’efficacia.
Come sempre, non inseguire la tecnologia: usala consapevolmente.
Ale
Alcune cose che, se ti va, possiamo fare insieme:
LAB Bolzano — Sei in zona Bolzano e stai valutando le soluzioni SASE? Allora il nostro LAB è perfetto per te.
Condividiamo — se hai un progetto che vuoi condividere con me o cerchi confronto su un argomento specifico.
Restiamo in contatto — ogni settimana condivido sul mio profilo LinkedIn insight legati alla tecnologia e soprattutto al suo impatto sul business.