La sicurezza IoT industriale è il lavoro di protezione di sensori, controllori, gateway e piattaforme cloud che collegano le apparecchiature fisiche alle reti, in modo che le letture siano affidabili e nessuno possa modificare un processo fisico senza autorizzazione. Riguarda il reparto produttivo e il sistema di controllo tanto quanto i servizi cloud verso cui oggi viaggiano i dati di stabilimento.

Collegare le apparecchiature al cloud conviene, ma cambia anche chi può raggiungerle. Un responsabile OT o IT che pianifica questo collegamento ha bisogno di un quadro chiaro di ciò che gli attaccanti fanno negli ambienti industriali, di quali debolezze sfruttano e di quali controlli fanno la differenza. Questo articolo li affronta uno per uno, dalle reti SCADA fino alla piattaforma cloud.

In breve

  • Gli incidenti industriali più comuni iniziano nell’IT, tramite phishing, credenziali di accesso remoto rubate o ransomware, e arrivano alla produzione perché le reti non sono separate.
  • I sistemi SCADA sono vulnerabili a causa di protocolli datati senza autenticazione, reti piatte, account condivisi e software che non si può aggiornare rapidamente.
  • La messa in sicurezza di un sistema SCADA inizia con un inventario degli asset e la segmentazione della rete, e prosegue con il controllo di accessi remoti, account e backup.
  • IEC 62443 e NIST SP 800-82 sono i framework principali; sul lato cloud contano soprattutto accessi individuali, chiavi con ambito limitato e una traccia degli accessi.

Quali sono le principali minacce alla sicurezza IoT industriale?

Gli incidenti industriali attirano l’attenzione quando sono spettacolari, ma le minacce che causano più danni sono ordinarie. Ciascuna delle minacce alla sicurezza IoT industriale descritte qui sotto ha un precedente reale.

Il ransomware che parte dall’IT è il problema più frequente. Nel maggio 2021 un ransomware ha colpito i sistemi gestionali di Colonial Pipeline negli Stati Uniti. Non risulta che i sistemi di controllo dell’oleodotto siano stati cifrati, eppure l’azienda ha fermato per precauzione l’esercizio dell’oleodotto per diversi giorni, perché non poteva essere certa che l’attacco non si sarebbe propagato e non riusciva a gestire normalmente la fatturazione. Ne sono seguite carenze di carburante lungo la costa orientale degli Stati Uniti, tutto a partire da un incidente nell’IT d’ufficio.

Subito dopo vengono gli accessi remoti rubati o deboli. Fornitori e integratori hanno spesso bisogno di raggiungere le apparecchiature, e uno strumento di desktop remoto o un account VPN con una password condivisa diventa anche per un attaccante la via d’ingresso più facile.

Le credenziali predefinite sui dispositivi connessi sono un’altra via d’ingresso comune. Nel 2016 la botnet Mirai ha preso il controllo di centinaia di migliaia di telecamere, router e altri dispositivi IoT semplicemente provando nomi utente e password di fabbrica, e li ha poi usati per massicci attacchi denial-of-service. Gateway e sensori industriali consegnati con credenziali di accesso predefinite comportano lo stesso rischio.

Gli attacchi mirati ai sistemi di controllo sono più rari e più gravi. Stuxnet, scoperto nel 2010, manipolava PLC Siemens per danneggiare le centrifughe per l’arricchimento dell’uranio in Iran, mostrando nel frattempo agli operatori valori normali. Triton, individuato nel 2017 in un impianto petrolchimico in Arabia Saudita, prendeva di mira un sistema strumentato di sicurezza Triconex di Schneider Electric, il livello che deve portare un processo in arresto sicuro.

Infine ci sono l’insider e l’errore involontario: un collaboratore esterno con più accessi del necessario, o un tecnico che collega un portatile alla rete di controllo per “controllare solo una cosa”.

I dispositivi connessi aggiungono un’ulteriore categoria: l’accesso fisico. Un gateway montato in un armadio esterno non chiuso a chiave, o un sensore la cui porta di configurazione si raggiunge con un cacciavite, può essere ripristinato, sostituito o usato come via d’ingresso nella rete. I siti remoti come stazioni di pompaggio e sottostazioni vengono visitati di rado, quindi una manomissione può passare inosservata per settimane, a meno che contatti porta o interruttori sugli armadi non la segnalino.

Le vulnerabilità più comuni dei sistemi SCADA

La sicurezza dei sistemi SCADA è difficile per ragioni strutturali, non perché i gestori siano negligenti. Le debolezze comuni si ripresentano in tutti i settori.

I protocolli senza autenticazione sono la debolezza più antica. Il Modbus classico e il DNP3 originale sono stati progettati per reti seriali chiuse; qualsiasi dispositivo che riesca a raggiungere un controllore può inviargli un comando valido. Esistono varianti sicure, ma le apparecchiature più vecchie spesso non possono usarle.

Le reti piatte peggiorano le cose. In molti stabilimenti la rete degli uffici, i server SCADA e i PLC si trovano in un’unica rete senza alcun firewall in mezzo, quindi un solo portatile infetto può raggiungere tutto.

Gli account condivisi su HMI e postazioni di engineering fanno sì che ogni operatore acceda come “operatore”, il che rende impossibile capire chi ha fatto cosa.

Gli aggiornamenti sono lenti. I server SCADA usano spesso sistemi operativi datati perché il software SCADA o un driver è certificato solo per quella versione, e uno stabilimento non può riavviare ogni mese un processo in funzione.

L’esposizione su internet è un riscontro ricorrente. I motori di ricerca che scansionano internet, come Shodan, trovano regolarmente HMI, PLC e gateway di accesso remoto raggiungibili direttamente da qualsiasi luogo.

Supporti rimovibili e portatili di engineering sono una via più silenziosa. Le postazioni di engineering contengono il software in grado di riprogrammare ogni controllore dello stabilimento, e spesso sono proprio le macchine a cui i collaboratori esterni si collegano con i propri portatili e le proprie chiavette USB. Si ritiene che Stuxnet abbia raggiunto la sua rete isolata tramite supporti rimovibili, ed è per questo che oggi molti stabilimenti scansionano i dispositivi USB in un chiosco prima di consentirne l’uso vicino a un sistema di controllo.

L’attacco del dicembre 2015 ai distributori di energia elettrica ucraini ha sfruttato contemporaneamente diverse di queste debolezze. Gli attaccanti sono entrati tramite email di phishing nelle reti d’ufficio, hanno raccolto credenziali, si sono spostati nell’ambiente di controllo e hanno aperto gli interruttori da remoto, lasciando senza corrente circa 225.000 utenti per diverse ore.

Come si mette in sicurezza un sistema SCADA?

Nessun singolo prodotto mette in sicurezza un sistema SCADA. I passaggi seguenti seguono l’ordine raccomandato dalla maggior parte dei framework, perché ognuno rende più facile il successivo.

  1. Creare un inventario degli asset. Elencare ogni controllore, server, postazione, gateway e connessione di rete, con le versioni del firmware.
  2. Segmentare la rete. Separare la rete aziendale dalla rete di controllo, con una DMZ (una zona cuscinetto) in mezzo per tutto ciò che serve a entrambe le parti, come una copia dell’historian. Consentire solo il traffico necessario, nella direzione in cui è necessario.
  3. Eliminare l’esposizione diretta su internet. Nulla nella rete di controllo dovrebbe essere raggiungibile da internet. I dati diretti ai servizi cloud dovrebbero uscire tramite connessioni in uscita da un gateway nella DMZ.
  4. Controllare l’accesso remoto. Usare un unico punto di accesso gestito con autenticazione a più fattori, account individuali per i fornitori e accessi attivati solo quando servono.
  5. Dare a ciascuno il proprio account. Sostituire le credenziali condivise con account personali e con i privilegi minimi richiesti da ogni mansione.
  6. Aggiornare dove si può, compensare dove non si può. Testare gli aggiornamenti su un sistema di riserva; dove una macchina non si può aggiornare, limitare chi può comunicare con essa.
  7. Monitorare la rete. Gli strumenti di rilevamento delle intrusioni industriali apprendono il traffico normale tra i controllori e segnalano nuovi dispositivi o comandi insoliti.
  8. Eseguire backup e provare il ripristino. Conservare copie offline dei programmi dei PLC, delle configurazioni SCADA e delle immagini dei server, e verificare di saperle ripristinare.

La cybersecurity dei sistemi SCADA dipende anche dalle persone. Operatori e tecnici dovrebbero sapere come segnalare un’email sospetta o una chiavetta USB trovata nel parcheggio, e il piano di risposta agli incidenti dovrebbe indicare chi decide se mantenere il processo in funzione.

Con un budget limitato, l’ordine conta più della completezza. Uno stabilimento che ha un inventario, un firewall tra rete d’ufficio e rete di controllo, nessuna esposizione diretta su internet e account personali con accesso remoto a più fattori ha eliminato le vie usate nella maggior parte degli incidenti descritti sopra. Conviene aggiungere il monitoraggio della rete e i livelli di sicurezza formali dopo, non al posto di questi passaggi.

Standard di sicurezza per l’IoT industriale

Tra gli standard di sicurezza per l’IoT industriale dominano due framework. La IEC 62443 è una serie di norme internazionali per la sicurezza dei sistemi di automazione e controllo industriale. Introduce le zone (gruppi di asset con le stesse esigenze di sicurezza) e i condotti (le connessioni controllate tra di esse), definisce livelli di sicurezza da 1 a 4 contro attaccanti via via più capaci e ha parti distinte per proprietari degli asset, integratori di sistemi e fornitori di prodotti.

La NIST SP 800-82, pubblicata dal National Institute of Standards and Technology statunitense, è una guida alla sicurezza della tecnologia operativa. La revisione 3, pubblicata nel settembre 2023, ha esteso il suo ambito dai sistemi di controllo industriale all’OT in generale e mette in corrispondenza le sue raccomandazioni con il NIST Cybersecurity Framework.

Anche la normativa si sta muovendo. Nell’Unione europea la direttiva NIS2 riguarda energia, acqua, manifattura e altri settori, e gli Stati membri sono tenuti ad applicarla da ottobre 2024. Il Cyber Resilience Act dell’UE aggiunge requisiti di sicurezza per i prodotti con elementi digitali, con la maggior parte degli obblighi applicabili da dicembre 2027, il che riguarderà i sensori e i gateway connessi venduti nell’UE.

Aiuta anche sapere come si collegano alla ISO/IEC 27001, la norma molto diffusa per i sistemi di gestione della sicurezza delle informazioni. La ISO/IEC 27001 descrive come un’organizzazione gestisce il rischio di sicurezza in generale, mentre la IEC 62443 aggiunge i requisiti tecnici e organizzativi specifici dei sistemi di controllo. Molte aziende industriali le usano entrambe: la 27001 per l’azienda e il suo IT, la 62443 per gli stabilimenti.

Best practice di sicurezza per l’IoT industriale

Il lato cloud di un collegamento IoT industriale richiede la stessa disciplina del lato stabilimento. Alcune best practice di sicurezza per l’IoT industriale valgono su qualsiasi piattaforma. I dati dovrebbero uscire dallo stabilimento tramite connessioni cifrate in uscita avviate dal gateway, così non resta aperta alcuna porta in ingresso. Le reti di sensori wireless portano con sé la propria protezione: LoRaWAN, per esempio, cifra ogni messaggio con chiavi di sessione AES-128, il che serve solo se le chiavi usate per il provisioning dei sensori vengono gestite con cura. Ogni gateway e ogni connessione hanno bisogno di credenziali proprie, anziché di un’unica credenziale condivisa tra i siti. Queste chiavi di provisioning dovrebbero essere conservate cifrate e visibili solo alle persone che ne hanno bisogno. Il firmware dei gateway merita la stessa attenzione agli aggiornamenti di quello di un PLC, perché il gateway si trova proprio sul confine tra lo stabilimento e internet.

Sul lato piattaforma, i controlli di accesso di Kilo funzionano per persona e per pagina, come Edit, View o No access, così un collaboratore esterno può consultare le dashboard senza poter toccare regole o connettori. Le chiavi API hanno un ambito limitato per area, con permessi di lettura e scrittura separati, possono avere una data di scadenza e smettono di funzionare immediatamente quando vengono ruotate. L’Audit Trail registra inviti, modifiche dei permessi e rimozioni, così si può dimostrare chi aveva accesso e quando.

Domande frequenti sulla sicurezza IoT industriale

Che differenza c’è tra sicurezza IoT industriale e sicurezza IT?

Nell’IT di solito viene prima la riservatezza; nei sistemi industriali vengono prima la disponibilità e la sicurezza delle persone e degli impianti, perché fermare un processo può essere pericoloso o costoso. Inoltre le apparecchiature industriali restano spesso in servizio per 10-15 anni, a volte più di 20, molto più a lungo dell’IT d’ufficio, quindi la sicurezza deve fare i conti con dispositivi che non si possono sostituire in fretta.

Chi è responsabile della cybersecurity dei sistemi SCADA?

Ne risponde il proprietario degli asset, cioè l’organizzazione che gestisce lo stabilimento. La IEC 62443 suddivide il lavoro: i fornitori di prodotti costruiscono dispositivi sicuri, gli integratori li configurano in modo sicuro e il proprietario degli asset gestisce e mantiene il sistema in modo sicuro per tutto il suo ciclo di vita.

Cos’è lo zero trust nella sicurezza IoT industriale?

Lo zero trust è un approccio, descritto nella NIST SP 800-207, in cui nessun utente o dispositivo è considerato affidabile in base alla sua posizione nella rete. Ogni richiesta viene autenticata e autorizzata. Negli stabilimenti di solito lo si applica gradualmente, partendo dall’accesso remoto e dal confine tra IT e OT.

Prima di collegare qualsiasi cosa da una linea di produzione, conviene provare il modello di accesso su un segnale innocuo. Si installa un sensore di temperatura in un locale tecnico con il piano gratuito di Kilo, che non richiede dati di pagamento, si invita un collega con il solo accesso View e si crea una chiave API con ambito di sola lettura e una data di scadenza. Poi si ruota quella chiave e si verifica che uno script che usa il vecchio valore smetta di funzionare.