La diffusione dei dispositivi elettronici a basso costo per connettività (soprattutto Wi-Fi) e la sempre crescente offerta di banda per lo scambio dati vede, in questi anni, una convergenza fra il mondo industriale, permeato dalle architetture SCADA, e la galassia dei dispositivi IoT (Internet of Things), che in un primo tempo si identificava con i dispositivi consumer, in particolare domotica e personal care.
In questo scenario è significativo, nel febbraio di quest’anno, il rilascio ufficiale della norma IEC 62443-4-2. Quest’ultima appartiene alla famiglia di standard IEC 62443, per la sicurezza informatica dei sistemi IACS (Industrial Automation Control Systems), e in particolare regola la conformità tecnica agli standard di sicurezza informatica dei singoli endpoint quali PLC (Programmable Logic Controller), sensori, attuatori e via dicendo.
Tutti i dispositivi certificati IEC 62443-4-2 avranno un motivo in più per essere inseriti negli impianti industriali.
Indice degli argomenti
Lo standard IEC 62443-4-2 per la safety dell’impianto
Obiettivo della norma è garantire la “safety” dell’impianto, insieme alla confidenzialità, disponibilità ed integrità dei dati che vengono utilizzati nello stesso.
Il documento descrive quattro livelli di sicurezza, di complessità crescente:
- Security Level 1 (SL1): protezione contro la violazione occasionale o casuale.
- Security Level 2 (SL2): protezione contro la violazione intenzionale con mezzi scarsi, con risorse scarse, competenze generiche del sistema e motivazione scarsa.
- Security Level 3 (SL3) Protezione contro la violazione intenzionale con mezzi sofisticati, con risorse moderate, competenze specifiche del sistema e motivazione moderata.
- Security Level 4 (SL4) Protezione contro la violazione intenzionale con mezzi sofisticati con risorse ingenti, competenze specifiche del sistema e forte motivazione.
I requisiti di sicurezza per ogni installazione variano a seconda della criticità dell’impianto e adempiono agli eventuali cogenti di legge.
La componente Internet of Things (IoT) dei sistemi industriali sta espandendosi in modo decisamente marcato; a questo si affianca una (in verità meno rapida) affermazione del paradigma “Industry 4.0”. Conseguenza sulla cyber security delle installazioni: la superficie di attacco degli impianti industriali sta aumentando sensibilmente.
Quindi diventa vitale proteggere le singole apparecchiature da manipolazioni di terzi malevoli senza però compromettere le funzionalità proprie dei devices e degli impianti.
Quest’ultimo passaggio viene esplicitato in una serie di indicazioni che sono presenti da decenni nell’informatica, ma solo recentemente hanno preso piede nella progettazione e nell’esercizio di impianti industriali.
Standard IEC 62443-4-2: l’accento sul controllo accessi
La norma sottolinea il principio del privilegio minimo, secondo cui ogni parte attiva del sistema (umana e non) deve fruire dei privilegi di accesso strettamente necessari all’espletamento delle sole funzioni previste dal proprio ruolo.
Da questo consegue uno schema di controllo accessi granulare (a differenza, per esempio, di molte vecchie installazioni, che prevedono il solo accesso come amministratore) e di attribuzione puntuale dei comandi ad ogni utente e/o ruolo previsto (segregazione dei compiti).
In questo modo, come prescritto da un’altra norma della stessa famiglia, la 62443-3-3, si richiama la necessità dell’identificazione e dell’autenticazione dell’utente (nel caso più banale, userid/password) per consentire l’accesso a sistemi o apparati.
A parte il caso semplice di password, l’accesso può essere protetto mediante token fisici, certificati crittografici (a chiave simmetrica o a doppia chiave protette a livello hardware), biometria (nel caso di utente umano), anche in combinazione tra di loro e con una durata temporale finita. Inoltre ogni dispositivo deve essere predisposto per l’integrazione in un sistema di gestione delle identità di stabilimento.
È compito dei produttori predisporre una lista di ruoli con accessi diversificati su cui verranno mappati i singoli utenti in fase di configurazione, siano questi umani, processi software, oppure altre apparecchiature che devono interagire con il componente certificato.
Per motivi di sicurezza deve essere previsto una procedura di override manuale in casi di emergenza e, in specifiche attività particolarmente importanti o critiche, un sistema a doppia approvazione.
Quando il componente prevede un’interfaccia di accesso (ovvero la quasi toatalità dei dispositivi moderni), questa deve prevedere il blocco automatico in caso di inattività e un numero limitato di sessioni contemporanee per evitare il problema del blocco delle risorse a seguito di troppe richieste.
Standard IEC 62443-4-2: l’importanza dei log
Ogni dispositivo deve poter generare log e tenere traccia di una serie di eventi di sicurezza: accessi riusciti e falliti, modifiche di configurazioni, eventi del sistema di protezione, lettura dei log, etc con marcature temporali certe (time stamping), identificazione univoca dell’oggetto, dell’utente e del risultato dell’azione.
La norma prevede espressamente che l’apparecchiatura debba poter trasmettere i log ad un repository remoto (per evitare compromissioni on-site), nonché un meccanismo per impedire la saturazione della capacità locale di immagazzinamento.
Il componente deve anche implementare un sistema di non ripudiabilità dei log, in modo da poter ricostruire un’attribuzione certa e inoppugnabile di ogni singolo evento tracciato.
L’integrità dei sistemi come fattore critico
I comandi che circolano nelle reti industriali possono essere critici, quindi i vari componenti certificati devono prevedere un sistema di verifica dell’integrità degli stessi, per prevenire modifiche non autorizzate. Un tale obiettivo si raggiunge innanzitutto attraverso controlli preventivi dell’apparato (test locali e remotizzati).
A questi si aggiunge la validazione puntuale dei comandi con sistemi crittografici di firma del messaggio (per l’integrità del messaggio) o anche di cifratura integrale del messaggio complessivo. Naturalmente deve essere presente un sistema di validazione degli input.
Le segnalazioni di ogni non conformità devono avvenire in modo automatico non appena l’apparecchiatura la rileva. La gestione degli errori però non deve poter fornire informazioni ad eventuali attaccanti (viene fatto esplicito riferimento alle linee guida OWASP).
Viene infine richiesto un sistema di validazione delle sessioni di comunicazione per evitare che un attaccante malevolo si inserisca in una sessione corretta e possa inviare comandi non autorizzati.
Standard IEC 62443-4-2: la segmentazione delle reti
La norma impone che i singoli oggetti possano operare in un ambiente segmentato.
Un tipico schema di segmentazione prevede zone specifiche da cui i flussi di dati non possano fuoruscire, attraverso l’utilizzo dei tradizionali sistemi di protezione perimetrale (firewall) ed eventuali VPN per connessioni remote.
L’esigenza di una reazione tempestiva
Una buona capacità di risposta agli attacchi richiede tempi di reazione spesso molto corti: i sistemi certificati devono rilevare autonomamente eventuali tentativi di manomissione in un tempo ragionevole e segnalarli, rimanendo attivi anche in caso di un attacco di tipo Denial Of Service.
Inoltre, nel caso pessimo, devono portarsi in uno stato di protezione in modo predicibile ed automatico.
Backup, backup, backup
Il tallone di Achille della maggioranza dei sistemi industriali consiste in procedure di backup inesistenti, implementate in modo inefficace o non protette adeguatamente contro letture non autorizzate e/o manomissioni.
I sistemi che si adeguano alla norma IEC 62443-4-2 dovranno implementare stringenti policy di backup con capacità crittografiche per proteggere le informazioni, al fine di assicurare la capacità di recupero della funzionalità a seguito di un incidente.
Principio della minima funzionalità attiva
Tutte le funzionalità non necessarie al funzionamento normale del dispositivo devono essere per default disabilitate.
I dispositivi devono essere in grado di dialogare con un sistema di catalogazione, specificando quali funzioni siano attive e in quale modalità.
Il pericolo del “mobile code”
Lo standard IEC 62443-4-2 riserva particolare attenzione ai linguaggi che utilizzano il mobile code, per esempio Java, Javascript, Flash, ActiveX e via dicendo.
Ogni applicativo software di questo tipo deve essere preventivamente verificato prima di essere eseguito; si deve tener traccia di chi può inviare (upload) frammenti di codice e validare l’identità del mittente.
Questa forma di protezione è estesa alle interfacce di test/diagnostica (per esempio i protocolli JTAG).
Gestione degli aggiornamenti, protezione fisica e dell’avvio
I device certificati devono poter essere aggiornabili in modo sicuro (di solito, con protezione degli update mediante certificati crittografici).
Aspetto critico riguarda il presidio dell’accesso fisico agli stessi (per esempio, con sigilli) che deve essere tracciato nel sistema di gestione centrale. Al bootstrap, i dispositivi devono validare il firmware e gli applicativi software utilizzando anche la hardware root of trust (HWRoT).
Un esempio recentissimo di questi problemi è stato trovato nella cattiva implementazione da parte di alcuni integratori del secure boot su hardware Xilinx.
Conclusioni
L’impatto della norma IEC 62443-4-2, e in generale di tutte quelle della famiglia 62443, può apparire in un aumento della complessità degli impianti industriali e del relativo costo di esercizio.
Non va sottovalutato, tuttavia, il grande vantaggio di mitigare i rischi legati a manomissioni e danni anche accidentali.
Sebbene il contrasto a cyber attacchi fornisca all’attaccante il vantaggio dell’iniziativa, la compliance a norme di questo tipo garantisce al responsabile della sicurezza industriale un’indispensabile protezione supplementare.
