A. Coletta, I. Nai Fovino, A. Carcano, M. Guglielmi
Global Cyber Security Center (GSEC)
UN’ANALISI MULTIDIMENSIONALE DI STATI CRITICI PER RILEVARE INTRUSIONI
NEI SISTEMI SCADA
(STATe evoLUTIoN ANALySIS foR DeTeCTINg ATTACkS IN SCADA SySTeMS)
Sommario
Una tendenza relativamente nuova nelle Infrastrutture
Critiche (es., centrali elettriche, centrali nucleari, rete di distribuzione, ecc.) è la migrazione di massa dal classico modello di
sistemi isolati, ad un modello di sistema-di-sistemi in cui le
infrastrutture stanno intensificando le interconnessioni basate
su tecnologie ICT. Il cuore ICT di questi impianti industriali è conosciuto come Supervisory Control And Data
Acquisition Systems (SCADA). Le contromisure di sicurezza ICT tradizionali (es., firewall classici, anti-virus e IDS)
non riescono a fornire una protezione completa per questi sistemi, in quanto le loro esigenze sono diverse da quelle dei sistemi ICT tradizionali. Questo articolo presenta un approccio
innovativo per il rilevamento delle intrusioni di rete in sistemi
SCADA basato sul concetto di analisi di stati critici e di
prossimità da questi stati. Il framework teorico presentato è
supportato da test effettuati con un prototipo di Intrusion
Detection System (IDS) che implementa l’approccio proposto.
1. Introduzione
Negli ultimi anni l’uso di Information and
Communication Technology (di seguito ICT) nei sistemi
industriali è aumentato enormemente, con un impatto drammatico sulla loro sicurezza. In questo lavoro
l’attenzione è rivolta alla sicurezza dei sistemi
SCADA (Supervisory Control and Data Acquisition). I
sistemi SCADA sono ampiamente usati negli
impianti industriali per il controllo e manutenzione
dei sensori e degli attuatori. I componenti di base che
caratterizzano un sistema SCADA sono: (a) Master
Terminal Units (MTU) che presentano i dati agli operatori, raccolgono i dati dalla rete di campo e trasmettono i segnali di controllo; (b) Remote Terminal
Unit (RTU), che inviano segnali di controllo ai dispositivi elettronici, acquisiscono dati da questi diSpeciale Sicurezza ICT
A bstract
Modern industrial systems (e.g., power plants, water
plants, chemical installations, etc.) make increasing use of
ICT technologies. In the last years, those systems started to use
public networks (i.e., the Internet) for system-to-system interconnections. The core of these industrial installations is traditionally a SCADA (SystemControl And Data Acquisition)
system. The characteristics of SCADA communication protocols and architectures are quite different from classical ICT
devices, protocols and systems. For this reason, at the moment,
traditional ICT security technologies are not able to effectively
protect industrial systems in an adequate way against ad-hoc
SCADA-tailored attacks. In this work we propose a novel
approach to Intrusion Detection for SCADA systems based
on the idea of Critical State Analysis. The presented theoretical framework is supported by tests made using an Intrusion
Detection System (IDS) prototype implementing the proposed
approach.
spositivi, ricevono i comandi dagli MTU e trasmettono i dati alle MTU. La maggior parte delle vulnerabilità SCADA è legata ai protocolli di comunicazione
utilizzate per lo scambio di comandi e dati tra i dispositivi master e slave.
Le tecnologie di sicurezza ICT tradizionali non
sono in grado (come dimostrato in [1]) di proteggere in modo efficace i sistemi industriali da attacchi
ideati su misura dei sistemi SCADA. In questo lavoro viene presentato un nuovo approccio per rilevare
attacchi ICT ai sistemi SCADA basato sul concetto
di Analisi di Stati Critici. Le seguenti osservazioni
sono alla base di questo approccio:
1) date le conseguenze di possibili incidenti, i
sistemi industriali sono soggetti a processi di
analisi della sicurezza, e quindi i possibili stati
critici sono ben documentati. Inoltre, gli stati
13
A. Coletta, I. Nai Fovino, A. Carcano, M. Guglielmi
critici possono essere considerati, per minimi
sottosistemi, di numero finito e conosciuti a
priori;
2) un attaccante che vuole danneggiare un sistema industriale deve interferire con lo stato dell’installazione, ad esempio forzando una transizione del sistema da uno stato sicuro ad uno
stato critico;
3) monitorando l’evoluzione degli stati di una
centrale, e tracciando se il processo industriale
sta entrando in un sistema critico, è possibile
rilevare tutte quelle tipologie di attacco (conosciuti o sconosciuti) che tentano di portare il
sistema in uno stato critico usando una catena
di comandi leciti;
4) nelle architetture SCADA, il principale vettore
di attacchi informatici è il flusso di comandi di
rete.
Dal momento che il sistema IDS proposto tiene
traccia della sequenza di pacchetti che porta il sistema in uno stato critico, salvando i dettagli dei pacchetti su un database remoto e usando la metrica di
distanza per far partire il log della tale sequenza, è
possibile discriminare tra gli stati critici dovuti ad
attacchi informatici e quelli dovuti a malfunzionamenti o attacchi fisici. Questo approccio è stato
introdotto per sopperire all’incapacità delle tecniche
IDS tradizionali di rilevare le particolari tipologie di
attacchi su SCADA basati su catene di comandi legittimi.
2. Lavori correlati
Quello dell’Intrusion Detection è un campo di ricerca ben definito. Nel caso dei sistemi SCADA, tuttavia, solo di recente sono stati rilasciati una serie di
regole ad hoc e di moduli di pre-processing [2] in
grado di rilevare alcuni tipi di attacchi ai protocolli
SCADA. Con queste regole un sistema di Network
Intrusion Detection (NIDS) è in grado di identificare
solo gli attacchi basati su un singolo pacchetto di
rete; tuttavia gli attacchi SCADA raramente sfruttano
un singolo pacchetto ([1], [7], [8], [9]); di conseguenza è necessario un meccanismo di correlazione dell’attacco. gross et al. [3] hanno proposto un meccanismo “collaborativo” di intrusion detection (“selecticast”) che utilizza un server centralizzato per l'invio
di informazioni proveniente da sensori ID riguardanti attività provenienti da indirizzi IP sospetti.
Questo approccio è utile per fornire un quadro più
14
ampio degli eventi sospetti che accadono nel sistema
monitorato. Tuttavia, non fornisce alcun tipo di tecnica specifica per identificare azioni malevoli complesse e di alto livello. Ning et al. [6] hanno proposto un modello volto a individuare le relazioni di
causa fra gli alert sulla base dei pre-requisiti e le conseguenze. L’approccio proposto da Cuppens e Miege
in [5] adotta pre- e post-condizioni; purtroppo, questa tecnica può generare regole di correlazione spurie, aumentando il rumore del sistema IDS di alerting. Per quanto riguarda le soluzioni di sicurezza per
ambienti industriali e sistemi SCADA, Nai et al.
hanno presentato un primo IDS embrionale per protocolli SCADA [10] in cui è stato introdotto il concetto di state-based analysis. Il presente lavoro estende
quest’ultimo concetto, presentando un framework
teorico e applicativo completo, introducendo il concetto di previsione del livello di criticità degli stati del
sistema. L’idea di individuare gli attacchi analizzando
se il sistema sta entrando in uno stato critico ha alcune analogie con quanto è stato fatto nel campo di
ricerca di Fault-Detection and Diagnosis. Più in dettaglio,
l’approccio più simile è la model-based fault detection, che
si avvale delle cosiddette limit-value based supervisory
functions, per monitorare le variabili misurabili in cerca
di valori non validi o, nel caso di funzioni di protezione automatica, per l’attivazione di opportune azioni di risposta per proteggere il processo (per i dettagli si veda [12], [13], [14]). Questi approcci non possono essere adottati per discriminare tra cyber-attacchi e guasti accidentali, e non forniscono una metrica di prossimità dagli stati critici che sia facilmente
calcolabile, che è il principale contributo di questo
lavoro. La situational awareness è un altro campo di
ricerca che ha una certa somiglianza con il nostro
approccio. La situational awareness è un componente chiave in ambienti critici ed è trattata da un gran
numero di lavori accademici. Per una bibliografia su
questo argomento si rimanda a [15]. generalmente
l’inconveniente principale degli approcci di situational awareness risiede nella quantità enorme di dati da
elaborare e nella mancanza di tecniche efficaci per la
successiva valutazione di eventi che potrebbero essere fonte di minaccia. Un lavoro significativo in questo settore è [16].
3. Analisi degli stati
L’approccio proposto in questo lavoro si basa sul
monitoraggio dell’evoluzione degli stati del sistema.
Speciale Sicurezza ICT
UN’ANALISI MULTIDIMeNSIoNALe DI STATI CRITICI PeR RILevARe INTRUSIoNI NeI SISTeMI SCADA
(STATe evoLUTIoN ANALySIS foR DeTeCTINg ATTACkS IN SCADA SySTeMS)
Da un punto di vista operativo, gli elementi seguenti
sono necessari per monitorare e analizzare l’evoluzione di un sistema:
• Un linguaggio di rappresentazione per descrivere
in modo formale il sistema in esame.
• Un linguaggio degli stati del sistema, per descrivere in modo formale gli stati critici associate al
sistema in esame.
• Un monitor dell’evoluzione degli stati, per seguire
l'evoluzione del sistema.
• Un rilevatore di stati critici, per verificare se lo
stato del sistema evolve verso uno stato definito critico.
• Una metrica di distanza da stati critici per calcolare quanto uno stato del sistema sia vicino agli
stati critici.
3.1 Descrizione del sistema e rappresentazione degli stati critici
Per la rappresentazione formale degli stati del
sistema industriale abbiamo specificamente definito
un nuovo linguaggio formale chiamato Industrial State
Modeling Language (ISML). Questo linguaggio supporta i sistemi SCADA che utilizzano il protocollo
MoDBUS, ma può essere facilmente esteso ad altri
protocolli industriali.
In ISML una regola ha la forma condition → action.
Condition è una formula booleana composta dalla
congiunzione di predicati che descrivono quali valori possono essere assunti dai diversi componenti critici connessi ai Programmable Logic Controllers (PLC).
Più in dettaglio, ISML è definito in notazione
standard BNf come segue:
⟨comp⟩ rappresenta un register; in MoDBUS:
DI=Discrete Input (1-bit Ro register), Co=Coil(1bit RW register), IR=Input Register(16-bit Ro register) e HR=Holding Register (16-bit RW register).
Lo stato del sistema viene definito dai valori dei
Speciale Sicurezza ICT
componenti del sistema. Il linguaggio ISML viene
utilizzato (a) per fornire una descrizione dettagliata
del sistema da monitorare, la quale verrà utilizzata
per generare il sistema “virtuale” utilizzato dall’IDS,
e (b) per descrivere una classe particolare di stati del
sistema chiamato stati critici che corrispondono a
situazioni pericolose o indesiderate. Per ogni stato
critico è possibile specificare il livello di rischio. Il
valore 1 corrisponde a uno stato basso rischio critico
(ad esempio il sistema è in esecuzione ma non in
modo ottimale). Il valore 5 corrisponde a un stato
critico pericoloso per il sistema.
Esempio 1: Si consideri un sistema composto da
una turbina e da un sensore di temperatura, entrambi connessi a due PLC. I PLC sono identificati dal
loro indirizzo IP e dalla porta. PLC[10.0.0.10:502] è
connesso ad una turbina con un holding register che
permette di regolare la velocità di rotazione, mentre
PLC[10.0.0.22:502] è connesso ad un sensore di temperatura e il suo valore è memorizzato in un input
register. Il sistema è in uno stato critico (con livello
di rischio 4) se la temperatura è maggiore di 99˚C e
la turbina gira a meno di 1000 giri al minuto. Questo
stato critico può essere formalizzato in ISML come
segue:
L’IDS lancia un avvertimento se la formula critica è soddisfatta.
3.2 Monitoring dell’evoluzione del sistema
Uno State Evolution Monitor (SeM) è un componente software che tiene traccia dell’evoluzione dello
stato del sistema. Nell’approccio presentato, la
descrizione formale del sistema, definita tramite il
linguaggio ISML, viene usata per creare un’immagine software virtuale del sottosistema monitorato.
ogni elemento è rappresentato in memoria. In questo modo viene creata una mappa in memoria dei
PLC e dei Master. L’immagine virtuale contenuta in
SeM è popolata ed aggiornata usando il traffico di
controllo scambiato tra i dispositivi master e slave.
In altre parole, assumendo che il traffico che va dal
master allo slave contiene una compatta rappresentazione dell’evoluzione del sistema, usando lo sniffing
del traffico è possibile mantenere nella memoria di
SeM una riproduzione dello stato del sistema reale.
Inoltre, per garantire una stretta sincronizzazione tra
15
A. Coletta, I. Nai Fovino, A. Carcano, M. Guglielmi
il sistema virtuale e quello reale, SeM contiene un
emulatore di master per eseguire direttamente query
sui PLC del sistema; per limitare la sua interferenza
con il sistema, è possibile definire un “tempo di
invecchiamento” per ogni register e coil presenti nel
sistema virtuale, oltre il quale l’emulatore master può
eseguire una query diretta al PLC. L’accesso alla
memoria per aggiornare il sistema virtuale potrebbe
essere potenzialmente costoso. Nel prototipo realizzato tutti i componenti virtuali sono indicizzati utilizzando una tabella di hash per fornire accesso diretto a ogni elemento.
importante notare che gli allarmi sono sollevati dall’occorrenza di uno stato critico, e non da un particolare schema di attacco. La descrizione di uno stato
critico agisce come un “aggregatore di schemi di
attacchi”, raggruppando nella descrizione di un singolo stato critico tutti quei tipi di attacchi (conosciuti o sconosciuti) che possono condurre il sistema in
quel particolare stato critico. Usando questo approccio è possibile rilevare gli attacchi cosiddetti zero-day
(cioè non ancora scoperti) che portano il sistema in
stati critici conosciuti.
ogni possibile stato del sistema è descritto dai
valori che i componenti del sistema possono assumere. Un certo stato di un sistema di n componenti
può essere rappresentato da un vettore s ∈ ℝn.
L’esempio 1 può essere rappresentato con uno stato
s ∈ ℝ2, dove il valore della velocità della turbina è
mappato su s1, mentre il valore del sensore di temperatura su s2. L’insieme di stati critici CS ⊆ ℝn è l’insieme degli stati che soddisfano le condizioni critiche
descritte nella Sezione 3.1. Sia s(t) lo stato del sistema
al tempo t. Possiamo dire che il sistema in esame è in
uno stato critico se s(t) ∈ CS.
Stabilire se un certo stato s è critico significa verificare se s verifica una qualche formula critica in CS.
Dato uno stato s e una formula critica φ, verificare se
s soddisfa φ corrisponde a valutare la formula φ usando i valori rappresentati da s. La complessità
computazionale per valutare φ è lineare rispetto al
numero dei predicati che compaiono nella formula.
Anche se la valutazione di una formula può essere
effettuata facilmente con una semplice visita del suo
albero di sintassi, abbiamo usato una rappresentazione in memoria della formula basata su vincoli di intervallo, come descritto nella Sezione 4. La valutazione
delle formule critiche usando questa rappresentazione ha la stessa complessità della visita dell’albero di
sintassi, ma tale rappresentazione presenta dei vantaggi per calcolare la misura di prossimità dagli stati
critici.
Dal punto di vista operazionale, il Critical State
Analyzer controlla se lo stato contenuto in SeM corrisponde ad almeno uno degli stati critici specificati.
In tal caso solleva un allarme, memorizzando i dettagli sui pacchetti che hanno causato il sistema critico.
In questo modo è possibile discriminare tra gli attacchi informatici e i fallimenti o attacchi fisici. È
In questa sezione presentiamo un modo di predire
se il sistema sta andando verso uno stato critico. Il
metodo si basa sulla nozione di distanza dagli stati critici. Tracciando i cambiamenti della distanza del sistema corrente dagli stati critici è possibile predirne la
criticalità. Il sistema virtuale descritto nella sezione
precedente è usato per tracciare lo stato corrente del
sistema, e la distanza dagli stati critici è calcolata
usando i valori del sistema virtuale.
3.3 Rilevamento degli stati critici
16
4. Metrica multidimensionale per Stati Critici
4.1 Distanza stato-stato
La nozione di distanza è parametrica rispetto alla
metrica sullo spazio degli stati di sistema. Sia
d: ℝn × ℝn → ℝ+ una qualunque metrica su ℝn. In altre
parole, sia d una qualunque nozione di distanza tra
due stati del sistema. In questo lavoro due distanze
sono particolarmente interessanti:
La distanza d1 è anche detta in letteratura distanza di Manhattan. La distanza dv conta il numero dei
componenti di sistema che hanno valore diverso nei
due stati.
Nell’esempio 1, d1 calcola quanto l’attuale velocità della turbina e temperatura sono vicine ai valori
critici. Sia s = (999, 100) uno stato critico (cioè lo stato
in cui la velocità della turbina è di 999 giri al minuto
e la temperatura è 100˚C). Siano u = (999, 30) e
v = (999, 50) due stati. I valori della distanza
d1(u, s) = 70 e d1(v, s) = 50 indicano che lo stato v è più
vicino allo stato critico s di quanto lo sia lo stato u,
cioè secondo la distanza d1 lo stato u è più sicuro di
v. D’altra parte, i valori dv(u, s) = 1 e dv(v, s) = 1 indicaSpeciale Sicurezza ICT
UN’ANALISI MULTIDIMeNSIoNALe DI STATI CRITICI PeR RILevARe INTRUSIoNI NeI SISTeMI SCADA
(STATe evoLUTIoN ANALySIS foR DeTeCTINg ATTACkS IN SCADA SySTeMS)
no che u e v distano dallo stato critico s allo stesso
modo. Infatti, sia nello stato u che in v solo un componente di sistema (il sensore di temperatura) ha un
valore differente dallo stato s. La scelta effettiva della
distanza d1 o dv dipende dalla nozione di criticalità
che si vuole catturare. Quando si è interessati soltanto al numero di componenti che si avvicinano ai valori critici, allora la distanza dv è più appropriata.
Quando invece si è interessati proprio ai valori che si
avvicinano a quelli critici, allora la distanza d1 è più
appropriata.
4.2 Distanza stato-stati critici
Data una qualsiasi distanza su ℝn (ad esempio le
distanze d1 e dv definite in precedenza), la nozione di
distanza tra uno stato e un insieme di stati può essere definita come:
Come definito in letteratura standard, dato un
insieme di numeri reali A ⊆ ℝ, l’espressione inf A
denota il massimo dei minoranti (greatest lower bound)
di A, cioè inf A = max{x ∈ ℝ ∣ ∀y ∈ A. x ≤ y}. Inoltre,
inft ∈ S d(s, t) = inf {d(s, t) ∣ t ∈ s} per ogni s.
La definizione di d(s, S) ricalca il senso comune di
distanza tra un punto ed un insieme di punti. La
nozione di distanza tra uno stato del sistema e l’insieme degli stati critici sarà indicata con d(s, CS). È
fondamentale sottolineare che questa distanza è
completamente parametrica rispetto alla metrica
scelta su ℝn.
4.3 Valutazione della distanza
Il calcolo della distanza d(s, CS) definita in precedenza non segue direttamente dalla sua definizione.
Per un’implementazione efficiente è necessario usare
la forma matematica dell’insieme di stati critici. Il linguaggio delle condizioni critiche implica che, per
ogni formula delle regole, i valori critici di ogni componente appartengono ad intervalli (limitati o illimitati) di numeri reali. Questa informazione è usata per
calcolare la distanza in modo efficiente.
Un vincolo C = I1, …, In è una sequenza di n
intervalli su ℝ, dove n è il numero di componenti del
sistema. Un vincolo indica gli intervalli di valori critici per ogni componente di sistema.
Uno stato s è critico rispetto ad un vincolo C se
Speciale Sicurezza ICT
per ogni i = 1, …, n, il valore dell’i-esimo componente
si ∈ Ii. ogni formula critica φ può essere rappresentata da uno o più vincoli. Un insieme di vincoli
{C1, …, Ck} è equivalente ad una formula φ se per
ogni stato s che soddisfa φ esiste almeno un vincolo
Cj tale che s è critico rispetto a Cj. Considerando
l’esempio 1, sia φ = PLC[10. 0. 0. 10: 502]. HR[1] ≠ 50
una formula critica. Non è possibile trovare un
vincolo equivalente a φ. Tuttavia, siano C1 = [-∞, 49],
[-∞, +∞] e C2 = [51, +∞], [-∞, +∞] due vincoli.
L’insieme di vincoli {C1, C2} è equivalente a φ, infatti
ogni stato che soddisfa φ soddisfa anche {C1, C2}, e
viceversa.
La nozione di insieme di vincoli equivalenti è la
base per implementare un’opportuna rappresentazione di memoria delle formule critiche. Nella fase
di inizializzazione dell’IDS ogni formula viene convertita nel suo insieme di vincoli equivalenti.
Considerando l’esempio 1, sia:
una formula critica. Tramite il parsing della
formula φ è possibile creare gli intervalli critici di
ogni componente di sistema che compare nella formula. In questo caso, l’insieme di vincoli equivalenti
a φ è costituito da un solo vincolo C = [3, 50],
[30, +∞].
Sia {C1, …, Ck} l’insieme di vincoli equivalenti ad
una formula φ. valgono le seguenti uguaglianze:
La distanza d(s, CS) = minφ d(s, φ) può essere calcolata usando le equazioni (1) e (2), implementate
con due cicli annidati, uno sui vincoli creati nella fase
di inizializzazione, l’altro sugli intervalli che compaiono in ogni vincolo. La complessità è lineare nel
numero di predicati che compaiono nelle formule
critiche.
L’equazione (2) è parametrica rispetto all’effettiva distanza usata. Precisamente, la funzione d(si, Ii)
nella parte destra dell’equazione può essere sostituita
sia con di che con dv. Le definizioni seguenti permettono di implementare facilmente l’algoritmo di
calcolo delle distanze:
17
A. Coletta, I. Nai Fovino, A. Carcano, M. Guglielmi
lo Modbus su TCP e PLC della famiglia ABB
AC800. La figura 1 mostra uno schema del dispositivo elettromeccanico fisico utilizzato per le simulazioni, mentre una descrizione dettagliata dell’ambiente sperimentale può essere trovata in [8].
dove inf I e sup I sono rispettivamente l’estremo
inferiore e superiore dell’intervallo I.
Riassumendo, per calcolare la distanza d(s, CS) tra
uno stato del sistema e l’insieme di stati critici, usando la distanza di Manhattan d1 e la distanza discreta
dv, è sufficiente calcolare l’insieme di vincoli equivalenti di ciascuna formula durante la fase di inizializzazione. Durante l’evoluzione del sistema, la criticalità dello stato corrente e la prossimità dagli stati critici possono essere calcolati implementando le
equazioni (1) e (2). La scelta effettiva delle due
metriche d1 e dv dipende dalla nozione di distanza
scelta.
5. Esperimenti e risultati
In questa sezione sono descritti alcuni test su un
nostro prototipo che implementa l’approccio che
abbiamo descritto. I test sono stati effettuati nel
laboratorio Testbed for Industrial Networking Security del
Joint Research Centre.
Questo laboratorio è stato creato grazie ad una
attività di ricerca di collaborazione tra il
Dipartimento di Ricerca di enel SpA e il Joint
Research Centre della Commissione europea. Il
laboratorio contiene un ambiente protetto in cui un
complesso dispositivo elettromeccanico costituito da
tubi, valvole, sensori, pompe, ecc. viene utilizzato per
emulare fisicamente i diversi stati di una centrale elettrica reale. Nei nostri test abbiamo usato il protocol-
Figura 1: Schema dell'ambiente di simulazione nel nostro laboratorio.
18
5.1 Scenario Boiling Water Reactor
Lo scenario del Boiling Water Reactor (BWR) in
figura 2 mostra un reattore nucleare usato per generare energia elettrica. Il BWR in figura è volutamente semplificato. Il serbatoio a pressione del reattore
contiene gli elementi di combustibile e le barre di
controllo assorbiti in acqua leggera. gli elementi di
combustibile riscaldano l’acqua per produrre vapore.
Il vapore raggiunge la turbina principale attraverso la
linea di vapore e lo fa ruotare. Il vapore utilizzato è
pilotato verso il condensatore dove viene condensato in acqua. L’acqua risultante viene pompata nuovamente nel serbatoio del reattore. I PLC sono programmati con la seguente logica:
PLC1: controlla il sensore di temperatura dell’acqua nel serbatoio e la velocità di Pump 2. Questi valori vengono memorizzati nei registri IR1 e HR1. PLC1
aumenta la velocità della Pump 2, se la temperatura è
troppo elevata, al fine di aumentare il flusso di acqua
fredda e per ridurre la temperatura del serbatoio.
PLC2: controlla il sensore di pressione collegato
alla IR2 e la valvola di controllo VOUT collegata a
HR2, che contiene un valore che rappresenta l’apertura della valvola (0 chiusa - 100 aperto). Quando la
pressione è troppo elevata, PLC2 apre la valvola
VOUT per espellere il vapore e per ridurre la pressio-
Figura 2: Schema del Boiling Water Reactor.
Speciale Sicurezza ICT
UN’ANALISI MULTIDIMeNSIoNALe DI STATI CRITICI PeR RILevARe INTRUSIoNI NeI SISTeMI SCADA
(STATe evoLUTIoN ANALySIS foR DeTeCTINg ATTACkS IN SCADA SySTeMS)
ne interna.
PLC3: controlla il sensore di temperatura del condensatore collegato al IR3 e la velocità di Pump 1 collegata a HR3. Come PLC1, quando la temperatura del
condensatore è troppo alta, PLC3 aumenta la velocità della pompa in modo da aumentare il flusso di
acqua fredda e per condensare il vapore.
La descrizione formale del sistema tramite ISML
è un insieme di predicati che specificano lo stato del
sistema, ad esempio:
dove i valori nella parte destra degli assegnamenti sono i valori iniziali del sistema, e che sono automaticamente sincronizzati con il sistema reale grazie
all’emulatore master.
Di seguito è mostrato un insieme di regole critiche di esempio che rappresentato possibili stati critici per lo scenario BWR.
Il significato delle regole è il seguente:
(R1) Se la temperatura è maggiore di 120˚C e la
velocità di Pump 2 è minore di 40 rpm, allora il sistema è in uno stato critico perché la temperatura dell’acqua è alta ma la velocità della pompa non è sufficiente a ridurre la temperatura del serbatoio.
(R2) Se la pressione è maggiore di 80 bar e la valvolare è aperta meno del 50%, allora il sistema è in
uno stato critico perché la pressione è alta, ma la valvola non è sufficientemente aperta per espellere il
vapore e ridurre la pressione interna.
(R3) Se la temperatura è maggiore di 100˚C e
Pump 1 è minore di 60 rpm, allora il sistema è in uno
stato critico perché la temperatura del vapore è alta,
ma la velocità della pompa non è sufficiente a ridurre la temperatura del condensatore.
esempio di distanza: Si consideri la regola (R1) e
si assuma che PLC[1].IR[1] sia mappato su s1 e
PLC[1].HR[1] su s2.
L’insieme di vincoli equivalenti alla formula critica contenuta nella regola (R1) è l’insieme
{C1 =[120,+∞],[-∞,40]}. Sia s1 =(100,45) lo stato
corrente. La distanza tra s e la formula (R1) è calcolata nel modo seguente:
Speciale Sicurezza ICT
In questo esempio l’insieme di vincoli equivalenti a (R1) contiene un solo vincolo. Se l’insieme è più
di un vincolo, lo stesso calcolo deve essere ripetuto
per ciascun vincolo e il valore finale della distanza è
il minimo tra i valori calcolati.
5.2 Analisi dell’accuratezza
Uno dei parametri più importanti da prendere in
considerazione quando si valuta un IDS è l’accuratezza, cioè in quale misura sia in grado di identificare correttamente una condizione (nel nostro caso la
presenza di uno stato critico). Nella letteratura scientifica di Intrusion Detection, l’accuratezza viene
comunemente misurata in termini di
falsi positivi e falsi negativi, cioè si considera rispettivamente il numero di falsi
allarmi sollevati e il numero di attacchi
che non vengono identificati. Per misurare l’accuratezza degli IDS, abbiamo messo a punto
il seguente esperimento: un data set è stato creato
attraverso la raccolta di traffico di rete nel nostro
laboratorio ICS per quindici giorni. Il data set è costituito da traffico SCADA standard che riflette le tipiche attività industriali, più del traffico random generato simulando attacchi che mirano a stati critici.
L’approccio proposto è inteso come una funzione
aggiuntiva da aggiungere a IDS esistenti, per fare in
modo di individuare una particolare classe di attacchi
contro i sistemi SCADA. Per questo motivo, abbiamo valutato la sua accuratezza rispetto alla tipologia
di attacchi composti da sequenze di comandi
SCADA leciti. vale la pena notare che la congestione del traffico di rete influisce sulla precisione delle
IDS. Come sottolineato in precedenza, in caso di
un’alta congestione della rete l’immagine del sistema
virtuale potrebbe essere leggermente diversa dal
sistema attuale, a causa della perdita di pacchetti.
Quando ciò accade, le regole di stati critici vengono
valutate usando valori di stato che non sono pienamente coerenti con quelli dello stato reale, con conseguenti falsi positivi o falsi negativi. Per catturare
questo aspetto abbiamo immesso nel traffico di rete,
19
A. Coletta, I. Nai Fovino, A. Carcano, M. Guglielmi
Figura 3: Risultati falsi positivi e negativi.
Tabella 1: Risultati di accuratezza per falsi positivi e negativi.
in modo casuale, dei pacchetti con alti tassi di banda.
La Tabella 1 fornisce un quadro del numero di
allarmi, veri e falsi, generati al giorno. L’esempio
mostra chiaramente che il numero di allarmi veri è
molto superiore a quello di falsi allarmi.
Approssimativamente il 99% degli allarmi generati
sono “true positive”, mentre meno dell’1% del totale sono “false positive”. facciamo notare che l’accuratezza in questo contesto si riferisce alla specifica
classe di attacchi per i quali il nostro approccio è
stato studiato, e cioè quegli attacchi costituiti da
sequenze di comandi SCADA legittimi ma che portano il sistema in uno stato critico.
Monitorando il sistema con l’approccio proposto,
un falso positivo o un falso negativo potrebbero
occorrere nel caso di de-sincronizzazione del sistema
virtuale da quello reale. Un ruolo importante è svolto dall’emulatore Master che si trova all’interno
dell’IDS: più il tempo di richieste di sincronizzazioni
è veloce, minore è il rischio di de-sincronizzazione
del sistema virtuale. Da questo punto di vista i test
precedenti possono essere anche considerati come
20
misura della robustezza contro
falsi positivi e negativi causati da
de-sincronizzazione.
D’altra
parte, una sincronizzazione
eccessivamente veloce e ripetuta
potrebbe interferire molto con il
sistema monitorato. Il compromesso tra la frequenza di richieste di sincronizzazione e l’interferenza con il sistema dipende
fortemente dal sistema. I parametri che devono essere considerati per definire la frequenza di
query appropriata sono: (a) l’architettura di sistema (ad es., se il
sistema è composto da connessioni di rete ridondanti, allora le
connessioni di backup potrebbero essere usate per le query di
sincronizzazione); (b) l’hardware
del sistema (ed es., la potenza
computazionale e di rete dei
PLC); (c) i requisiti di real-time
del sistema. La stima della corretta frequenza di query può
essere considerata parte dell’usuale fase di messa a punto, tipica di ogni IDS. Il giusto compromesso tra il tempo di sincronizzazione e l’interferenza con il sistema può essere
determinato sulla base di test ed esperimenti ad-hoc.
5.3 Test di performance
Questa sezione descrive i test effettuati con una
configurazione che abbiamo chiamato “four subsystem scenario” (fSS). Questo scenario è stato
implementato per misurare i tempi di latenza e di
ritardo dell’IDS. L’fSS è composto da quattro master
connessi a 16 PLC configurati con almeno 100 porte
di input analogiche e digitali.
5.3.1 Test sull’uso della memoria
L’evoluzione delle performance di uso di memoria è mostrato nel seguito. Ci sono due strutture dati
che di dimensione considerevole nel nostro IDS: l’immagine virtuale del sistema e la rappresentazione in memoria
delle regole. La struttura per il sistema virtuale consiste
in una hash table che identifica ogni PLC con una
chiave unica. La quantità di memoria richiesta per
Speciale Sicurezza ICT
UN’ANALISI MULTIDIMeNSIoNALe DI STATI CRITICI PeR RILevARe INTRUSIoNI NeI SISTeMI SCADA
(STATe evoLUTIoN ANALySIS foR DeTeCTINg ATTACkS IN SCADA SySTeMS)
Tabella 2: Memoria per PLC.
Tabella 4: Memoria per regola singola.
Tabella 3: Memoria per VS.
Tabella 5: Memoria per insieme di regole.
ogni oggetto PLC cresce in modo lineare con il
numero di registri del PLC. La memoria richiesta per
l’intero sistema virtuale cresce linearmente con il
numero di PLC del sistema da monitorare. La
Tabella 2 mostra l’uso di memoria per ogni PLC, e la
Tabella 3 mostra l’uso di memoria per il sistema virtuale contenente PLC di 65535 registri (che è il massimo numero permesso dalle specifiche Modbus [4]).
L’altra importante struttura dati è usata per rappresentare le regole di stati critici. Questa struttura
dati è una lista di liste, dove ogni sotto-lista rappresenta una regola. La memoria richiesta per ogni regola cresce in modo lineare con il numero di condizioni presente nella regola, e la memoria necessaria per
l’intero insieme di regole cresce linearmente con il
numero di regole. La Tabella 4 mostra l’uso di
memoria per ogni regola e la Tabella 5 mostra l’uso
di memoria per ogni intero insieme di regole (da 1 a
2000 regole, ciascuna composta da 4 condizioni).
5.3.2 Test per Packet Capturing
Le performance di cattura dei pacchetti del
nostro prototipo è stata testata mandando un alto
numero di pacchetti con un bit rate molto alto. I
Tabella 6: Test per cattura di pacchetti e allarmi sollevati.
Speciale Sicurezza ICT
risultati sono mostrati in Tabella 6.
In questo scenario l’IDS è sottoposto a burst di
400000 pacchetti consecutivi (con bit rate crescente).
Nei nostri test, il comportamento dell’IDS risulta
affidabile, dal momento che nel caso peggiore (traffico di 2,77 Mbit/sec) solo lo 0.0079% dei pacchetti
e lo 0.0158% degli alert sono andati persi (in Tabella
6 sono mostrati solo gli alert che sono stati persi a
causa della perdita di pacchetti). Come prevedibile, il
numero di pacchetti persi e di alert persi cresce
all’aumentare del traffico, come mostrato in figura 4.
Quando il rate di traffico è al di sotto di 1,215
Mbit/sec non c’è alcun pacchetto perso, e anche
quando il traffico diventa alto (oltre 2 Mbit/sec) la
percentuale di pacchetti persi rimane sotto lo
0,008%.
5.3.3 Test dell’aggiornamento del sistema virtuale
L’IDS, ogni volta che cattura un pacchetto di rete
che rappresenta un comando o un messaggio
SCADA, aggiorna l’immagine del sistema virtuale
(System Virtual Image, SvI) in due passi: trova il PLC
relativo al comando, e aggiorna i valori dell’oggetto
che rappresenta quel PLC. Il primo passo non è rilevante per quanto riguarda le performance dell’IDS in quanto la lista di
PLC è implementata da una hash table,
quindi il tempo impiegato per trovare
un PLC (circa 0,0042 ms secondo le
nostre misure) è praticamente identico
per tutte le tabelle che contengono da
1 a 1000 PLC.
Per misurare il tempo impiegato
per aggiornare le informazioni dei
21
A. Coletta, I. Nai Fovino, A. Carcano, M. Guglielmi
Tabella 7: Performance dell'analizzatore di regole di stati critici (Tempo
in ms).
5.3.4 Test dell’analizzatore delle regole di stati critici
Figura 4: Test sulla cattura di pacchetti e allarmi sollevati.
Figura 5: Performance degli aggiornamenti del sistema virtuale.
PLC è stato impiegato il test seguente: la Master
Station manda 1000 richieste con il comando “Read
n coils”, e la Slave Station risponde con dei messaggi
che contengono gli n valori richiesti. L’IDS cattura le
transazioni richiesta/risposta e aggiorna gli n valori
nell’immagine virtuale del PLC.
I risultati dimostrano la validità dell’approccio.
Infatti, anche nel peggior caso, cioè 2000 coil da
aggiornare (che è il valore massimo consentito dalle
specifiche Modbus [4]), la performance dell’IDS
rimane sotto 1 ms. Inoltre, il tempo impiegato cresce con il numero di coil da aggiornare in modo
lineare, come mostrato nel grafico di figura 5.
22
La performance dell’analizzatore delle regole di
stati critici dipende da due fattori: la dimensione di
ogni regola e la quantità di regole. L’impatto della
dimensione delle regole è stata misurata come segue:
la Master Station manda 1000 richieste generiche e la
Slave Station risponde con il messaggio appropriato,
l’IDS cattura le transazioni richiesta/risposta e controlla se il sistema virtuale sta entrando in uno degli
stati critici definiti da un file di regole che contiene
solo una regola con n condizioni (in questo caso, 2
condizioni). L’impatto del numero di regole sulla
performance dell’IDS è stato testato aumentando il
numero di regole e tenendo fissa la dimensione di
ogni regola. I risultati
sono mostrati in Tabella 7.
È importante notare
che il tempo impiegato
per un numero di condizioni fino a 2048 rimane
inferiore ad 1 ms. Questo
risultato è soddisfacente,
dal momento che è altamente improbabile avere
delle regole con 2048 condizioni. Inoltre, questi test
mostrano che il collo di bottiglia per le performance
IDS è l’analizzatore delle regole di stati critici, specialmente quando il numero di regole è alto. In ogni
caso, il tempo impiegato è inferiore 1 ms con un
numero di regole che arriva fino a 2000.
5.4 Test di performance della distanza
Alla luce dell’implementazione descritta, abbiamo
effettuato i test seguenti:
1. Test sui predicati: l’insieme di regole è composto da soltanto una formula critica che ha
un numero variabile di predicati (fino a 2000)
Speciale Sicurezza ICT
UN’ANALISI MULTIDIMeNSIoNALe DI STATI CRITICI PeR RILevARe INTRUSIoNI NeI SISTeMI SCADA
(STATe evoLUTIoN ANALySIS foR DeTeCTINg ATTACkS IN SCADA SySTeMS)
8.A
8.B
Tabella 8: Test sulla performance del calcolo della distanza
relativi allo stesso componente di sistema.
2. Test sui componenti di sistema: l’insieme
di regole è composto da soltanto una formula
critica che ha un numero variabile di predicati
(fino a 2000) relativi a differenti componenti
di sistema.
3. Test sulle regole: l’insieme di regole è composto da un numero variabile di regole (fino a
2000).
I risultati dei test sono mostrati nella Tabella 8.
Ciascun test conferma che il tempo richiesto per calcolare la distanza è lineare con il numero dei predicati. Nel test 1, il tempo impiegato per calcolare la
distanza (Tabella 8.A) è trascurabile, soprattutto considerando che una lista di 2000 predicati per un singolo componente è improbabile. Nel test 2, il tempo
speso per calcolare la distanza (Tabella 8.B) è inferiore a 6 ms, che è un buon risultato. Nel test 3, il
tempo speso per calcolare la distanza (Tabella 8.C) è
considerevolmente più alto, ma comunque la crescita è lineare e il tempo massimo è inferiore a 60 ms
fino a 2000 regole che è un tempo più che accettabile per sollevare degli alert.
6 Conclusioni
Questo articolo presenta un nuovo approccio per
il rilevamento di una particolare classe di attacchi
informatici nei confronti delle installazioni indu-
8.C
striali. gli aspetti chiave di questa tecnica solo il concetto di stato critico e l’assunzione che un attaccante
che vuole danneggiare un’installazione industriale
(come una centrale elettrica) dovrà modificare, per
raggiungere il suo risultato, lo stato del sistema e portarlo da uno stato sicuro ad uno stato critico.
L’identificazione degli stati critici, che è difficilmente
applicabile ai sistemi ICT tradizionali, trova invece la
sua naturale applicazione nel campo dei controlli
industriali, dove gli stati critici sono in generale ben
conosciuti e di numero limitato. Dal momento che il
rilevamento è basato sull’analisi dell’evoluzione del
sistema e non sull’analisi dell’evoluzione dell’attacco,
l’IDS è anche in grado di rilevare, per gli stati critici
conosciuti, i cosiddetti attacchi “zero-day” (cioè sconosciuti).
L’articolo introduce una metrica multidimensionale che fornisce una misura della distanza tra un
certo stato e l’insieme di stati critici. La metrica è
parametrica rispetto a due possibili concetti di
distanza tra stati, a seconda se è più importante il
numero dei componenti di sistema che si stanno
avvicinando a valori critici, oppure sono i valori stessi di tali componenti ad essere importanti. Questa
metrica può essere usata per tracciare l’evoluzione
del sistema, indicando la sua prossimità dall’insieme
di stati critici predefiniti. I risultati dei test condotti
su un nostro prototipo che implementa l’approccio
descritto dimostrano l’effettiva fattibilità e validità
del metodo proposto.
BIBLIOGRAFIA
[1]
[2]
[3]
[4]
I. Nai fovino, A. Carcano, M. Masera, A. Trombetta, “An experimental investigation of malware attacks
on SCADA systems”, International Journal of Critical Infrastructure Protection, 2(4): 2009.
http://www.digitalbond.com/index.php/research/ids-signatures/modbus-tcp-ids-signatures/, last
access 30/04/2010.
P. gross, J. Parekh and g. kaiser, “Secure Selecticast for collaborative Intrusion Detection systems”, in
Proc. of the Int. Workshop on DeBS, 2004.
Modbus-IDA, Modbus Application Protocol Specification v1.1b, http://www.modbus.org, December
28, 2006.
Speciale Sicurezza ICT
23
A. Coletta, I. Nai Fovino, A. Carcano, M. Guglielmi
[5]
[6]
[7]
[8]
[9]
[10]
[11]
[12]
[13]
[14]
[15]
[16]
24
f. Cuppens and A. Miège, “Alert correlation in a cooperative intrusion detection framework”, In SP ’02:
Proceedings of the 2002 Ieee Symposium on Security and Privacy, page 202, Washington, DC, USA,
2002. Ieee Computer Society.
P. Ning, y. Cui, and D.S. Reeves, “Constructing Attack Scenarios through Correlation of Intrusion
Alerts”, in Proc. of the ACM Conf. on Computer and Communications Security, pages 245-254,
Washington, D.C., November 2002.
J. Slay and M. Miller, ”Lessons Learned from the Maroochy Water Breach”, IfIP International
federation for Information Processing, volume 253, Critical Infrastructure Protection, eds. e. goetz
and S. Shenoi; (Boston: Springer), pp. 73-82, 2008.
I. Nai fovino, M. Masera, L. guidi and g. Carpi, “An experimental Platform for Assessing SCADA
vulnerabilities and Countermeasures in Power Plants”, in Proceedings of the Ieee 3rd International
Conference on Human System Interaction, May 13-15, 2010, Rzeszow, Poland.
S. east, J. Butts, M. Papa and S. Shenoi, “A Taxonomy of Attacks on the DNP3 Protocol”, IfIP
Advances in Information and Communication Technology, Springer Boston ISSN 1868-4238, v.
311/2009, Pages 67- 81.
I. Nai fovino, A. Carcano, M. Masera, A. Trombetta, T. Delacheze-Murel, “Modbus/DNP3 State-based
Intrusion Detection System”, in Proceedings of the 24th International Conference on Advanced
Information Networking and Applications, Perth, Australia, 20-23 April 2010.
g. Clarke, D. Reynders, “Modern SCADA Protocols”, elsevier, 2004, ISBN 0750657995.
R. Isermann, “Supervision, fault-detection and fault-diagnosis methods. An Introduction”, Control
engineering Practice, vol.5, n.5, pp.639-652, 1997.
R. Isermann, “Process fault detection based on modelling and estimation methods - a survey”,
Automatica, vol. 20, n. 4, pp. 1287-1298, 1984.
P. M. frank, “Advanced fault detection and isolation schemes using non linear and robust observers”,
10th IfAC Congress, Munich, vol. 3, pp. 63-68, 1987.
C. Dominguez, M. vidulich, e. vogel, g. McMillan, “Situation awareness: Papers and annotated bibliography”, Armstrong Laboratory, Human System Center, ref. AL/Cf-TR-1994-0085, 1994.
R. Roman, C. Alcaraz and J. Lopez, “The role of Wireless Sensor Networks in the area of Critical
Information Infrastructure Protection”, in Inf. Secur. Tech. Rep., vol. 12, No. 1, pp. 24-31, 2007.
Speciale Sicurezza ICT