Gli esperti di cyber security industriale si trovano a fronteggiare, oltre alle minacce dirette del cyber crime, anche situazioni difficili in cui tecnologie desuete non possono essere aggiornate o implementate con sistemi di sicurezza.
Uno scenario colmo di vulnerabilità che possono mettere a rischio la produzione causandone un blocco, con tutte le conseguenze del caso.
Indice degli argomenti
Il caso: PLC in un impianto all’estero
Circa un anno fa fui contattato, da un responsabile sicurezza, da poco entrato nell’azienda, di una società che realizza impianti industriali. Lo scopo dell’incontro era quello di valutare una collaborazione per la definizione dei processi di sicurezza nella realizzazione, messa in sicurezza e manutenzione del software di automazione di cui erano equipaggiati i macchinari e gli impianti da loro realizzati.
Nell’illustrazione dei problemi che si dovevano affrontare, tra gli altri, citò, a titolo di esempio, il fatto che aveva da poco scoperto che un PLC (Programmable Logic Controller), presente in un impianto da loro fornito, installato da qualche parte in estremo oriente, era esposto su internet “per consentire di fare la manutenzione da remoto”. Di questo dispositivo non sapeva quali erano gli accorgimenti di sicurezza adottati, chi aveva fatto questa operazione, né quando e nemmeno se fossero state definite delle regole per l’accesso. Il suo scoramento, come si può intuire, era grande ed elencava una serie di motivi che destavano la sua preoccupazione.
L’impianto in cui si trovava il PLC specifico era ad alta capacità di produzione e se il PLC fosse stato compromesso, sarebbe stata compromessa la catena di produzione e le conseguenze per la sua società sarebbero di difficile stima:
- risarcimento danni diretti dovuti all’arresto della produzione;
- danni derivanti da tempi di fermo impianto e costi di ripristino (non sapeva nemmeno se c’era un backup recente e affidabile dei programmi);
- costi di reputazione conseguenti alla divulgazione di questa leggerezza di gestione, e per recuperare la credibilità sul mercato.
A cui si deve aggiungere il costo da affrontare, comunque, nel dover fare un’azione preventiva:
- dover mandare qualcuno in loco per chiudere la vulnerabilità (in un momento di arresto programmato della produzione);
- fare un check di tutto lo stato dell’impianto e via dicendo.
Dell’esistenza di questa esposizione era venuto a conoscenza in modo informale, quasi accidentalmente. Quindi, per scrupolo, si rendeva necessario fare verifiche preventive per tutti gli impianti che erano stati prodotti, ed ancora operativi.
Un impianto di produzione richiede un investimento significativo per un’azienda e viene dismesso solo per manifesta obsolescenza; quindi in attività ci sono impianti, alcuni vecchi di anni, ancora in funzione e destinati ad essere operativi per non si sa ancora quando. In questi contesti si possono trovare software che sono stati sviluppati con ogni tipo di tecnologia che si è affacciata nell’ambito dello sviluppo della automazione industriale. Perciò si possono trovare ambienti che non sono più idonei alla manutenzione o per mancanza di expertise o anche di indisponibilità di tecnologie ormai desuete, usate nelle fasi di sviluppo.
Sistemi desueti: un problema per la cyber security industriale
Tra i sistemi “Cross” (qualcuno si ricorda delle programmazioni delle EEPROM?) e gli IIoT (Industrial IoT) c’è in mezzo tutto lo spettro dell’evoluzione tecnologica, sia hardware che software con cui sono stati realizzati o basati i programmi di automazione.
Alcuni sono anche equipaggiati con i runtime environment del sistema operativo in uso al momento dell’implementazione, quando il protocollo TCP/IP già esisteva ma internet non ancora. E, conseguentemente, il cyber crime nell’accezione attuale (intendendo in questa sede tutti coloro che creano dei danni indipendentemente dalla motivazione, che sia hacking adolescenziale o sabotaggio per motivi politici) non era nemmeno nello spettro delle possibilità.
In questo scenario, nel proseguimento dell’incontro, si citava a titolo di esempio il fatto che, nel suo ambito, si trovano ancora oggi, per rimanere nel campo Microsoft Windows, implementazioni che spaziano da Windows 95 a Windows NT, fino alle versioni odierne.
Quindi, non solo sistemi che sono pieni di vulnerabilità, all’epoca non note, e che non sono più, anche se relativamente recenti, in manutenzione. Con l’aggravante che non possono essere nemmeno essere aggiornati a nuove versioni, se non a scapito di un grosso lavoro di verifica sulle capacità prestazionali dell’hardware disponibile.
È necessario accertarsi che questo possa essere in grado di supportare le nuove versioni: i processi di automazione sono time bound, le nuove funzionalità che un upgrade si porta dietro provocano un rallentamento delle prestazioni, se non opportunamente controbilanciate da un upgrade dell’hardware. Insomma, questo mio interlocutore concluse il ragionamento con l’affermazione: “Io non so la dimensione della polveriera sulla quale sono seduto e quando esploderà”.
Lo scopo di tutti questi “mal di pancia” da eliminare doveva portare due tipi di azioni:
- il primo, di censimento delle varie “polveriere” e la pianificazione delle attività di rientro almeno per tappare più criticità possibili.
- Il secondo, di definire le politiche, le regole e le procedure per ridurre questa ipotesi di rischio nel futuro. Realisticamente, ci si aspettava di organizzare il processo da seguire in tutte le fasi del ciclo di vita per ridurre l’esposizione ai rischi, di certo non la previsione e prevenzione di vulnerabilità non ancora note. Definire quindi le best practice operative e comportamentali da seguire per avere una ragionevole certezza di avere eliminato delle potenziali vulnerabilità.
Per il momento, ad un anno di distanza, sfogliando i giornali non ho avuto informazioni relative ad incidenti che hanno coinvolto l’impresa in oggetto, i cui impianti fortunatamente non sono annoverabili tra quelli la cui compromissione potrebbe mettere a rischio l’incolumità delle persone o dell’ambiente; né tantomeno sono venuto a conoscenza di informazioni relative a conseguenze di rilevanza finanziaria o di reputazione a causa di incidenti in cui la società sarebbe stata coinvolta.
Questo aneddoto mi ha sollecitato alcune riflessioni, mutuandole anche con altre informazioni raccolte in convegni sulla sicurezza IT, sulla sicurezza nell’automazione industriale e in colloqui con imprenditori di cui faccio un piccolo sunto.
L’evoluzione delle tecnologie nella cyber security industriale
Le tecnologie in uso negli impianti, si è visto, hanno un ampio spettro temporale di utilizzo (non hanno e ci si aspetta che non abbiano la stessa rapidità di obsolescenza come un PC). Anche se queste sono le migliori disponibili al momento in cui sono implementate, sono soggette, per quanto riguarda la sicurezza, alla conoscenza dello stato dell’arte dei rischi e delle vulnerabilità note, le cui assunzioni sono destinate a scadere ed essere sorpassate da scoperte di vulnerabilità ulteriori.
Nei vari momenti, man mano, l’hardware è stato equipaggiato con dispositivi (ad esempio: le porte di rete o connettori per dispositivi esterni) che erano stati resi disponibili per evoluzioni future, e successivamente sono state utilizzate, e corrono il rischio di essere utilizzate, al di fuori di considerazioni di sicurezza.
Ad esempio la tecnologia USB (Universal Serial Bus): nessuno avrebbe pensato che potesse essere veicolo di malware per esempio tramite pendrive (anche oggi in ambito IT si pensa che una pendrive USB, anche se te la regalano con della documentazione, o la trovi per caso per terra in un parcheggio, possa essere innocua) e non è pensato e disponibile possa essere utilizzato anche per ricaricare la batteria di uno smartphone.
Una linea di produzione industriale potrebbe essere costituita con apparati e sotto processi provenienti da fornitori diversi che espongono, ognuno per la sua parte, un loro livello di vulnerabilità. E tutto questo è da valutare e governare.
Fino a che tutto rimane rigidamente limitato al mondo delle OT, escludendo i comportamenti impropri, tutto può essere ben confinato con un accettabile livello di sicurezza. I problemi iniziano a comparire quando, se non opportunamente segregate, si comincia a fare uno scambio di informazioni dalla produzione (OT) al controllo (Scada) ed alla programmazione (IT) e poi nel percorso contrario dalla programmazione (IT) alla produzione: l’Industria 4.0.
Di fronte alla possibilità di rinnovo degli impianti a fronte degli sgravi fiscali ed agevolazioni, si corre il rischio che si verifichi il fenomeno della corsa all’acquisizione di nuovi impianti ed apparecchiature, cosa di per sé valevole per lo sviluppo industriale, senza un’accurata valutazione sul potenziale rischio tecnologico cui questa operazione potrebbe esporre, soprattutto nel caso di integrazione in impianti esistenti, sulla tenuta della sicurezza.
I problemi da affrontare
La disponibilità di controlli automatici a mezzo di sistemi programmabili ormai è dappertutto. Fortunatamente i sistemi di safety e sicurezza a garanzia delle persone e dell’ambiente sono già rigidamente attuati, a seconda del campo di operazione (chimico, elettrico ecc.), con certificazioni, norme e controlli efficaci. In mezzo c’è un limbo che, per quanto ben descritto dal modello di Purdue (ANSI ISA95), corre il rischio di essere implementato in modo fragile e aperto a minacce.
Devono essere affrontati due ordini di problemi:
- l’evoluzione data dallo sviluppo delle necessità di produzione che ha due sotto filoni:
- Industria 4.0, con la continuazione dell’adozione del modello di Purdue;
- l’avvento del IIoT (Industrial IoT) e del futuro 5G (che prospetta il collassamento del modello Purdue portando i dispositivi IIoT a comunicare direttamente in rete Internet, verso applicazioni, magari in cloud, senza filtri e controlli soprattutto se i flussi vanno dal cloud direttamente ad agire sugli apparati IoT sul campo);
- l’altro, della gestione della legacy data da apparati e impianti di produzione tuttora ben funzionanti, destinati ad essere operativi ancora per un po’ di tempo, e che non sono stati concepiti per essere parte di un mondo più articolato.
Ci si sta affacciando in questa palude con diverse abilità che devono per forza essere complementari e non in contrasto: la sicurezza nel mondo IT e quella del mondo OT. Si deve tenere conto che hanno diverse gerarchie di priorità per quanto riguarda i temi di sicurezza e tali abilità devono essere reciprocamente comprese e omogeneizzate per essere efficaci. Non credo che ci possa essere un solo modello o approccio che garantisca che “one size fits all”, anche perché ogni tipologia di produzione ha le proprie caratteristiche ed esigenze specifiche: una catena di produzione metalmeccanica non ha la stessa particolarità di un processo farmaceutico.
I consigli dell’esperto
Alcuni capisaldi devono però essere di guida:
- prima di tutto un assessment, fare il punto di quale è la postura di sicurezza attuale e le eventuali vulnerabilità note;
- valutare i rischi;
- finire le regole da seguire per la gestione corrente della sicurezza;
- mettere in preventivo le attività di revisione periodiche delle regole a fronte di modifiche evolutive degli impianti o conseguenti alla reazione causata da eventi sopravvenuti.
Per l’assessment mi piace adottare questa similitudine politico/militare: conoscere il territorio ed i suoi confini; conoscere la popolazione che vive nel territorio e come si muove; tenere presente che il territorio si evolve nel tempo, frane, alluvioni ed attività antropiche ne modellano la forma. La popolazione se da una parte modifica il territorio, dall’altra modifica il comportamento in base alla nuova forma del territorio. L’assessment è un’attività continua.
Rischi: conoscere i nemici che si affacciano sul territorio e porre in atto le difese più adeguate. A questo riguardo nelle statistiche delle motivazioni di attacco redatte dall’ultimo rapporto Clusit del 2019 viene messo in evidenza che vi è un significativo aumento delle seguenti motivazioni: spionaggio industriale e Hacktivism, che sono due lati della stessa medaglia della concorrenza sleale che può, e inizia ad usare, anche la vulnerabilità delle infrastrutture informatiche come leva di azione.
Di fatto, credere che non si possa essere oggetti di una qualche forma di attacco non è una posizione ormai sostenibile. In alcuni contesti non è più nemmeno necessario dover essere degli hacker eccezionalmente esperti: nel Dark Web si possono trovare software o servizi, già quasi pronti per attuare un attacco. Rimane solo da attuare una strategia: buona parte delle armi sono già pronte.
Si devono definire e seguire regole comportamentali da seguire: per ridurre i punti di accesso ed eliminare leggerezze (come collegare uno smartphone ad una porta USB per ricaricarlo) ed organizzare gli ambienti per mantenere fisicamente separate le necessità. E quindi limitare le funzionalità disponibili nei vari ambienti a solo quelle necessarie nelle specifiche fasi di lavoro e togliere ciò che non serve (quello che non c’è non si rompe e non crea danno).
Questo significa dover attuare dell’hardening e organizzare gli ambiti di sviluppo, test, collaudo, e produzione in modo tale da ridurre le contaminazioni e trasferire solo il necessario con regole certe. Deve essere anche specificata la segregazione dei ruoli: chi sviluppa non deve essere in grado di accedere agli ambienti di test o produzione (se non investito di un ruolo specifico: nelle piccole imprese dove non è pensabile avere soggetti diversi, deve essere segregata la funzionalità di chi accede con un ruolo specifico in ogni ambiente e solo in quello).
Importante anche la revisione periodica. Una pianificazione di una modifica dell’impianto, sia per necessità operative, sia in seguito ad esperienze maturate in seguito ad incidenti, deve essere oggetto di una revisione dell’impianto di sicurezza che riparta dalla definizione del nuovo territorio, dei rischi, delle regole da rivedere e dei problemi riscontrati.
Poiché ogni ambito IT od OT e le corrispondenti expertise di sicurezza si portano dentro un bias (punto di vista) particolare, è necessario che queste esperienze siano entrambe presenti e collaborative e facciano capo ad un’idea che metta in primo piano la continuità del business: ovvero mettere in grado, nel miglior modo possibile, l’organizzazione di poter continuare ad operare e ridurre i rischi e le dimensioni delle possibili (la sicurezza non potrà mai essere assoluta) esplosioni delle “polveriere”.
