Rilevazione di intrusioni in sistemi di...
153
UNIVERSITÀ DI PISA TESI DI LAUREA IN SICUREZZA INFORMATICA: INFRASTRUTTURE ED APPLICAZIONI SECURING SCADA SYSTEMS Relatori: Baiardi Fabrizio Guidi Luca Controrelatore: Montangero Carlo Tesisti: Stillavato Francesco Trotta Giuseppe ICS & SCADA RILEVAZIONE DI INTRUSIONI IN SISTEMI DI CONTROLLO
Transcript of Rilevazione di intrusioni in sistemi di...
UNIVERSITÀ DI PISA
TESI DI LAUREA IN SICUREZZA INFORMATICA: INFRASTRUTTURE ED
APPLICAZIONI
SECURING SCADA SYSTEMS
Relatori: Baiardi Fabrizio Guidi Luca
Controrelatore: Montangero Carlo
Tesisti:
Stillavato Francesco Trotta Giuseppe
ICS &
SCADA RILEVAZIONE DI INTRUSIONI IN SISTEMI DI
CONTROLLO
Prefazione
Nonostante la crescente consapevolezza di minacce contro le infrastrutture critiche (CI), la
sicurezza nei sistemi di supervisione e controllo rimane ancora incompleta. Diversi studi
sono stati condotti per migliorare i protocolli di comunicazioni, le attrezzature e le
politiche di sicurezza. Gli strumenti di sicurezza solitamente utilizzati, sono hardware e
software pensati per sistemi IT. L’utilizzo di questi strumenti non offre lo stesso grado di
protezione offerto nei sistemi IT, in quanto non essendo pensati e sviluppati per la
sicurezza delle infrastrutture critiche, non interpretano correttamente o non conoscono
protocolli, politiche e operazioni presenti nei sistemi ICS.
Il presente lavoro di tesi dimostra come sia possibile definire e sviluppare uno
strumento per rilevare attacchi a sistemi ICS basato sulla correlazione di comportamenti.
Lo strumento analizza la descrizione dei comportamenti attesi dei componenti ed il flusso
delle comunicazioni tra i componenti.
Autori: Stillavato Francesco [email protected] Trotta Giuseppe [email protected] Relatori: Baiardi Fabrizio [email protected] Guidi Luca [email protected] Controrelatore: Montangero Carlo [email protected]
INTRODUZIONE........................................................................................................................... 9
Organizzazione della tesi ..................................................................................................................................................................... 11
1 SISTEMI DI CONTROLLO INDUSTRIALE ............................................................................ 13
1.1 SCADA ........................................................................................................................................................................................ 13 1.1 DCS.............................................................................................................................................................................................. 14 1.2 PLC .............................................................................................................................................................................................. 14 1.3 Operazioni................................................................................................................................................................................ 15 1.4 Componenti chiave ............................................................................................................................................................... 17
Componenti di controllo .................................................................................................... 17
Componenti di rete ........................................................................................................... 18
2 SCADA ............................................................................................................................ 21
2.1 Supervisione ........................................................................................................................................................................... 21 2.2 Controllo ................................................................................................................................................................................... 21 2.3 Acquisizione dati ................................................................................................................................................................... 22 2.4 Confronto tra SCADA e DCS ............................................................................................................................................... 22 2.5 Applicazioni di sistemi SCADA ......................................................................................................................................... 24
Gestione del traffico ferroviario (5) .................................................................................... 24
Produzione di energia elettrica (8) ..................................................................................... 27
3 IMPLEMENTAZIONI E ARCHITETTURE ............................................................................. 31
3.1 SCADA ........................................................................................................................................................................................ 31 3.2 DCS.............................................................................................................................................................................................. 35 3.3 PLC .............................................................................................................................................................................................. 37
4 SICUREZZA IN SCADA ...................................................................................................... 39
4.1 Convergenza dei sistemi SCADA e IT ............................................................................................................................. 40 4.2 Sicurezza nell’IT e relativi problemi in SCADA ........................................................................................................... 40 4.3 Sicurezza protocolli SCADA ............................................................................................................................................... 42
Firewall ............................................................................................................................. 42
Zona Demilitarizzata (DMZ)............................................................................................... 44
Regole generali dei firewall ............................................................................................... 47
5 PROTOCOLLI ICS.............................................................................................................. 49
5.1. Evoluzione dei protocolli SCADA ..................................................................................................................................... 49 5.2. Tecnologie di base dei sistemi SCADA ........................................................................................................................... 50
Il modello OSI .................................................................................................................... 50
Il modello TCP/IP ............................................................................................................... 53 5.3. Protocolli SCADA ................................................................................................................................................................... 54
MODBUS........................................................................................................................... 54
DNP3 ................................................................................................................................ 55
PROFIBUS ......................................................................................................................... 57
6 INTRUSION DETECTION SYSTEM ..................................................................................... 59
Indice
6
Indice
7 CORRELAZIONE ............................................................................................................... 61
7.1. IDS e correlazione nei sistemi ICS ................................................................................................................................... 61 7.2. Proprietà del correlatore.................................................................................................................................................... 66
Consapevolezza del dominio ............................................................................................. 66
Auto apprendimento e conoscenza esterna ....................................................................... 66
Real-time e Dati memorizzati ............................................................................................ 67
Stateless e stateful ............................................................................................................ 67
Centralizzati e distribuiti ................................................................................................... 67
Perdita d’informazioni....................................................................................................... 69
8 IMPLEMENTAZIONE DEL SISTEMA DI CORRELAZIONE ..................................................... 71
8.1 Classificazione degli eventi ................................................................................................................................................ 71 Eventi alert ....................................................................................................................... 72
Eventi da correlare ............................................................................................................ 73 8.2 Automi a stati finiti ............................................................................................................................................................... 75 8.3 Descrizione di automi per la correlazione ................................................................................................................... 76 8.4 Esempi di correlazione........................................................................................................................................................ 79 8.5 Comunicazioni e problemi di sincronismo .................................................................................................................. 88
9 STRUMENTI SVILUPPATI ................................................................................................. 91
9.1 FSMGen ..................................................................................................................................................................................... 91 Considerazioni finali sullo strumento ................................................................................. 97
9.2 SEC .............................................................................................................................................................................................. 97 Generazione eventi ........................................................................................................... 98
Funzionamento ................................................................................................................. 99
Caratteristiche tecniche .................................................................................................... 99
10 PROVE .......................................................................................................................... 101
Configurazione dell’ambiente di test............................................................................................................................................. 102 Utilizzo degli strumenti per i test ................................................................................................................................................... 102 Test #1: Comunicazioni singola rete (rete 1 - 192.168.3.0/24) .......................................................................................... 104
Scopo del test ................................................................................................................. 104
Dispositivi ....................................................................................................................... 104
Automi ........................................................................................................................... 104
Comunicazioni ................................................................................................................ 105
Risultati .......................................................................................................................... 107 Test #2: Comunicazioni singola rete (rete 2 - 192.168.4.0/24) .......................................................................................... 108
Scopo del test ................................................................................................................. 108
Dispositivi ....................................................................................................................... 108
Automi ........................................................................................................................... 109
Comunicazioni ................................................................................................................ 110
Risultati .......................................................................................................................... 111 Test #3: Lettura valore slave............................................................................................................................................................ 112
Scopo del test ................................................................................................................. 112
Dispositivi ....................................................................................................................... 112
Automi ........................................................................................................................... 112
Comunicazioni ................................................................................................................ 115
Risultati .......................................................................................................................... 115 Test #4: Richieste asincrone ............................................................................................................................................................ 116
Scopo del test ................................................................................................................. 116
Indice 7
Dispositivi ....................................................................................................................... 116
Automi ............................................................................................................................ 116
Comunicazioni ................................................................................................................ 119
Risultati .......................................................................................................................... 120 Considerazioni finali............................................................................................................................................................................ 121
APPENDICE ............................................................................................................................. 123
A.1 Test#1 – Correlatore rete 1 ............................................................................................................................................. 123 A.2 Test#2 – Correlatore rete 2 ............................................................................................................................................. 126 A.3 Test#3 – Richieste sincrone ............................................................................................................................................ 128 A.4 Test#4 – Richieste asincrone .......................................................................................................................................... 133 A.5 Creazione e configurazione dell’ambiente di test .................................................................................................... 138
Avvio dei tool per la fase di test ....................................................................................... 139
Configurazione IDS – Debian 6.0.5 ................................................................................... 143
Configurazione regole per Modbus .................................................................................. 148
BIBLIOGRAFIA ......................................................................................................................... 149
INDICE DELLE FIGURE .............................................................................................................. 151
INDICE DELLE TABELLE ............................................................................................................ 153
I sistemi di supervisione, controllo e acquisizione dati (Supervisory Control and Data
Acquisition – SCADA) si sono evoluti nel corso degli ultimi quaranta anni, passando da
sistemi indipendenti ad architetture di rete che comunicano anche a grandi distanze.
Inoltre, le loro implementazioni sono cambiate da hardware e software personalizzati a
infrastrutture standard. Questo cambiamento ha consentito di ridurre i costi di sviluppo e
manutenzione, ed anche di fornire informazioni in tempo reale per le operazioni di
gestione e pianificazione dei sistemi. Tuttavia, questi benefici hanno un costo. Diversi studi
(1) (2) (3) hanno dimostrato come le moderne infrastrutture industriali sono mediamente
soggette a tradizionali attacchi e minacce ICT, e quello che prima era un sistema di
controllo completamente isolato con hardware e software personalizzato, è ora
vulnerabile a minacce e attacchi provenienti da reti esterne, come Internet. La causa di
queste minacce è strettamente legata al grande numero di vulnerabilità introdotte
dall’utilizzo di tecnologie e reti standard ICT, come ad esempio sistemi operativi, protocolli
di comunicazione e applicazioni.
Il problema ha però un impatto più grave se si considera che questi sistemi sono
utilizzati in tutto il mondo per il controllo di infrastrutture critiche come impianti nucleari,
impianti di produzione di energia elettrica, gasdotti, oleodotti, impianti chimici ed altro.
Inoltre, i recenti virus informatici come Stuxnet 1e Duqu2, hanno evidenziato quanto questi
sistemi siano vulnerabili, a volte totalmente privi di sicurezza, e come un attaccante possa
causare danni catastrofici non solo al sistema in se, ma ad intere aree geografiche estese.
Il presente lavoro di tesi si pone l’obiettivo di fornire una metodologia e degli
strumenti software utilizzabili in sistemi ICS con differenti configurazioni, per individuare
attacchi informatici siano essi, attacchi 0-day o conosciuti. Essendo i sistemi ICS molto
statici, l’idea alla base del nostro modello prevede una prima fase di configurazione e
descrizione dei comportamenti, delle comunicazioni di rete, delle operazioni e dei flussi
ammessi nel sistema da monitorare e in una seconda fase di analisi e correlazione in
tempo reale delle comunicazioni e degli eventi tra le componenti del sistema controllato.
La descrizione dei comportamenti del sistema utilizza gli automi a stati finiti. Ciò
permette di definire in maniera molto rigorosa tutti gli stati nei quali il sistema può
trovarsi partendo dallo stato attuale. Gli automi, gli stati e le transizioni sono descritti
utilizzando il linguaggio XML e sono creati attraverso un’interfaccia web che guida l’utente
1 Stuxnet: primo worm sviluppato per sistemi industriali, in grado di riprogrammare i
dispositivi. 2 Duqu: worm sviluppato per sistemi industriali, che fornisce servizi all’attaccante.
Introduzione
10
Introduzione
nella creazione e definizione dei comportamenti del sistema. Le informazioni inserite e
utilizzate per la creazione dei modelli XML comprendono indirizzi sorgente, indirizzi
destinatario, protocolli e dati contenuti nel payload dei messaggi.
Gli automi guidano il comportamento delle unità di correlazione che ricevono gli
eventi generati dagli IDS installati nel sistema, e controllano che dallo stato attuale degli
automi si possibile transitare nello stato successivo. Se le informazioni contenute
nell’evento, corrispondono a una delle transizioni possibili, lo stato dell’automa viene
aggiornato. Se invece non è possibile effettuare alcuna transizione di stato, l’evento viene
identificato come errore.
I due strumenti sviluppati, guidano l’utente fin dalle prime fasi di creazione degli
automi, fino all’utilizzo e alla configurazione del sistema di correlazione. Il primo
strumento, FSMGen, guida l’utente nella creazione degli automi, offrendo la possibilità di
caricare report di scansioni di rete eseguite con Nessus3, dalle quali sono automaticamente
estratte informazioni come dispositivi, protocolli e porte aperte. In base alle informazioni
rilevate, sono automaticamente creati degli automi di base che l’utente può modificare
secondo le esigenze. Il secondo strumento, SEC, carica i file XML generati, ed effettua le
operazioni di correlazione. Lo strumento è configurabile e può essere utilizzato con
differenti tipologie di rete. Inoltre, è stato sviluppato in maniera modulare, in modo da
poter modificare, eliminare o aggiungere in maniera immediata delle librerie che
descrivono i diversi protocolli di rete.
I test effettuati nell’ambiente SCADA simulato4, descritti nel Capitolo 10, mostrano
come il sistema di correlazione ed identificazione di attacchi abbia rilevato correttamente
tutti i comportamenti e le comunicazioni anomale generate nel sistema, senza aver
generato alcun falso positivo o falso negativo. I test mostrano inoltre come a seconda del
livello di astrazione a cui sono descritti gli automi, è possibile utilizzare lo strumento di
correlazione, su sistemi con implementazioni, protocolli e politiche di gestione diverse.
3 Vulnerability scanner che si occupa di analisi di vulnerabilità sia in ambiente di rete locale,
sia in ambiente remoto. 4 Per fare le prove del sistema sviluppato, è stato creato un ambiente di test nel quale più
entità comunicano utilizzando i più comuni protocolli SCADA, ed effettuano operazioni diverse nell’arco del tempo. L’ambiente di test è descritto nel dettaglio in appendice, nel capitolo A.5 Creazione e configurazione dell’ambiente di test.
Introduzione
11
Organizzazione della tesi
Il presente lavoro di tesi è suddiviso nei seguenti capitoli:
Il cap. 1 introduce i sistemi di controllo industriale, descrivendone le
implementazioni, le caratteristiche e le componenti principali. Il capitolo successivo
descrive le operazioni di supervisione, controllo e acquisizione dati, che caratterizzano i
sistemi SCADA. Inoltre si evidenziano le differenze tra SCADA, DCS e PLC. Il cap. 3 illustra
soluzioni alternative per le architetture di rete di sistemi SCADA, DCS e PLC. Dopo aver
descritto le possibili architetture, il capitolo 4 illustra i principali problemi di sicurezza e
meccanismi di sicurezza alternativi negli SCADA. Il cap. 5 presenta le caratteristiche dei
più diffusi protocolli di comunicazione utilizzati nei sistemi ICS. Il cap. 6 descrive le
differenti tipologie di IDS e come esse possono essere utilizzati e implementati nei sistemi
SCADA. Il cap. 7 introduce il meccanismo base utilizzato per la rilevazione di attacchi, la
correlazione e le caratteristiche principali che un sistema di correlazione deve offrire.
Dopo aver descritto in generale la correlazione, il cap. 8 presenta le caratteristiche della
metodologia di correlazione sviluppata nel presente lavoro di tesi. Il cap. 9 descrive le
caratteristiche e i funzionamenti dei due strumenti sviluppati: FSMGen e SEC. Infine, il cap.
10 presenta l’ambiente di simulazione creato e le prove effettuate. Per ogni prova il
capitolo descrive le comunicazioni simulate, le configurazioni utilizzate e i risultati
ottenuti.
Con il termine Industrial Control System (ICS) si definiscono diversi sistemi di controllo
usati nella produzione industriale, come i sistemi di Controllo di Supervisione e
Acquisizione Dati (Supervisory Control and Data Acquisition - SCADA), Sistemi di Controllo
Distribuito (Distributed Control Systems - DCS), e i più semplici Controllori Logici
Programmabili (Programmable Logic Controllers - PLC), spesso utilizzati nei settori
industriali e nelle infrastrutture critiche. Gli ICS sono usati dalle industrie che forniscono
servizi come elettricità, gas, acqua o anche da industrie chimiche, di trasporto,
farmaceutiche, manifatturiere e impianti nucleari. (4)
Analizziamo brevemente questa tipologia di sistemi e i loro comportamenti.
1.1 SCADA
Gli SCADA sono sistemi ampiamente distribuiti, usati per controllare risorse in un’area
geografica che può estendersi per migliaia di chilometri quadrati, dove il controllo e
l’acquisizione centralizzata dei dati sono operazioni critiche. Questi sistemi sono utilizzati
per gestire il trasporto ferroviario o la distribuzione di risorse quali acqua, gas, elettricità.
Un centro di controllo SCADA implementa su reti molto estese, operazioni centralizzate di
monitoraggio e controllo sia degli allarmi sia dello stato dei dati da elaborare. In base alle
informazioni ricevute da una stazione remota questi sistemi possono inviare specifici
comandi alle relative stazioni di controllo dei dispositivi. Queste ultime sono spesso
indicate anche con il termine di dispositivi di campo5 , field devices. Le operazioni definite
su dispositivi di campo possono essere di tipo diverso, come ad esempio apertura o
chiusura di valvole e attuatori, ricezione dati da sensori, o monitoraggio di parametri
dell’ambiente circostante. Un possibile esempio è quello dei sensori di rilevamento di
scosse sismiche.
5 Nei sistemi di automazione e controllo industriale il termine campo è un’espressione
generica che descrive l’insieme dei sistemi a basso livello, quali sensori, trasmettitori o attuatori.
1
Sistemi di controllo industriale
14
Capitolo 1
1.1 DCS
Un DCS è un sistema di controllo simile a uno SCADA ma caratterizzato da un elevato
livello di decentramento delle funzioni. Le operazioni sono solitamente implementate
utilizzando controlli ciclici che invocano operazioni per mantenere alcuni valori del
processo controllato nell’intervallo di uno specifico set-point6. Per garantire che questi
valori siano collocati, con tolleranza richiesta, all’interno di un intervallo, sul campo sono
utilizzati specifici PLC, configurati in modo tale da garantire la tolleranza desiderata.
Questo è utile nel caso in cui durante l’esecuzione di processo sia necessario correggere un
determinato valore per riportarlo all’interno dell’intervallo prestabilito (set-point).
Un esempio può essere quello di un PLC che invia dei comandi che permettono di
aprire o chiudere una valvola. Esiste inoltre un sensore di temperatura configurato in
modo tale che il suo set-point sia 40° e la sua tolleranza di ±20°, quindi il suo intervallo va
da un minimo di 20° a un massimo di 60°. Nel momento in cui il sensore rileva un valore
non appartenente all’intervallo di tolleranza, il PLC, in base alla sua configurazione, invierà
automaticamente il comando di chiusura o apertura della valvola.
1.2 PLC
Un PLC è un dispositivo industriale computer-based specializzato nella gestione e nel
controllo di processi e attrezzature industriali mediante l’elaborazione di segnali digitali
e/o analogici provenienti dalle strumentazioni di campo. I PLC possono essere usati come
parti di un sistema di controllo SCADA e DCS oppure, autonomamente, come piccoli
sistemi di controllo su processi come ad esempio catene di montaggio, inoltre, sono
ampiamente utilizzati nella maggior parte dei processi industriali.
L'insieme dei componenti hardware che costituiscono la struttura fisica di un PLC
dipende strettamente dalle operazioni da eseguire per l'automazione del processo. I
principali componenti di un controllore logico programmabile sono:
Alimentatore CPU Scheda d’ingressi digitali Scheda d’ingresso analogica Schede di uscita digitali Schede di uscita analogiche Schede speciali Schede di comunicazione
6 Nei sistemi di controllo industriale il valore di set-point è la misura di riferimento costante
per una variabile di processo a cui far tendere i valori. I sistemi operano in modo da correggere la variabile quando devia da questo valore standard.
Sistemi di controllo industriale
15
Figura 1: PLC Siemens.
1.3 Operazioni
Nel seguito descriviamo le operazioni base di un sistema ICS.
Controlli ciclici: queste operazioni coinvolgono controller hardware come sensori di misurazione, PLC, attuatori, valvole di controllo, interruttori, motori. Le variabili di controllo sono trasmesse ai controllori dai sensori che li raggiungono. I controllori interpretano i segnali e, basandosi sui set-point, modificano in modo opportuno le variabili. A volte, i controlli ciclici sono annidati o implementati a cascata e il set-point di un ciclo può essere basato sulla variabile di processo di un altro ciclo. A livello di supervisione e di campo, i cicli sono ripetuti per tutta la durata del processo con tempi che variano nell’ordine dei millisecondi fino ad arrivare ai minuti.
Un esempio di controllo ciclico è mostrato in Figura 2.
Figura 2: Controllo ciclico di un sistema SCADA.
16
Capitolo 1
Interfaccia uomo-macchina (Human-Machines Interface – HMI): è l’interfaccia utilizzata per configurare i set-point, controllare stabilendo e modificando i processi e parametri dei controllori. Le HMI mostrano anche informazioni sullo stato dei processi e il loro storico.
Un esempio di HMI è mostrato in Figura 3.
Figura 3: HMI
Diagnostica remota e strumenti di manutenzione: queste operazioni devono prevenire, identificare e recuperare il sistema da eventuali errori.
Un tipico ICS esegue un insieme di cicli di controllo e comprende numerose HMI,
diagnostica remota e strumenti di manutenzione costruiti utilizzando un ampio insieme di
protocolli di rete su architetture a più livelli. Questi cicli di controllo possono essere
annidati e/o in cascata, per cui il set-point di ciclo si basa sulla variabile di processo
determinata da un altro ciclo. I cicli a livello di supervisione e inferiore lavorano in modo
continuo per tutta la durata di un processo con tempi di ciclo che vanno nell'ordine dai
millisecondi a minuti.
La Figura 4 riassume graficamente le tre operazioni base appena descritte.
Sistemi di controllo industriale
17
Figura 4: Operazioni base di un sistema ICS.
1.4 Componenti chiave
In base all’utilizzo, si distinguono due tipologie di componenti di un sistema ICS: quelle di
controllo e quelle di rete o collegamento.
Componenti di controllo
Le parti di controllo possono essere distinti in:
Server di controllo: esegue i supervisori DCS e PLC, che comunicano con i dispositivi di basso livello. Il server ha l’accesso attraverso la rete ICS a moduli di controllo secondari.
SCADA Server o Master Terminal Unit (MTU): è il dispositivo che svolge le funzioni di master in un sistema SCADA. Gli RTU e i PLC, situati nelle locazioni remote agiscono solitamente come slave.
Remote Terminal Unit (RTU): sono unità si supporto alle stazioni remote SCADA, per raccogliere dati e controllare altre unità. Gli RTU sono dispositivi di campo solitamente equipaggiati con interfacce radio wireless, utilizzati in situazioni dove il cablaggio fisico per la comunicazione non è implementabile. A volte i PLC possono essere considerati come dispositivi di campo ed essere utilizzati come RTU.
18
Capitolo 1
Programmable Logic Controller (PLC): sono piccoli computer industriali originariamente progettati per svolgere funzioni logiche eseguite in precedenza da hardware elettrico (ripetitori, interruttori, timer e contatori meccanici). I PLC si sono ormai evoluti in controllori ed hanno capacità che permettono di controllare processi complessi, per questo sono molto utilizzati in sistemi SCADA e DCS. I sistemi SCADA utilizzano spesso i PLC come dispositivi di campo poiché sono economici, versatili, flessibili e molto configurabili.
Intelligent Electronic Device (IED): è un sensore/attuatore ‘intelligente’ in grado di acquisire dati, comunicare con altri dispositivi ed eseguire processi e controlli locali. Un IED comprende un sensore d’input/output analogico, capacità di controllo a basso livello, sistemi di comunicazione, e memoria programmabile. L’utilizzo di questi dispositivi nei sistemi SCADA e DCS permette di implementare controlli automatici a livello locale.
Human-Machine Interface (HMI): integra software e hardware che permette agli operatori di monitorare lo stato di un processo, modificare le impostazioni di controllo e sovrascrivere operazioni automatiche in casi di emergenza. Le HMI permettono inoltre agli operatori di configurare set-point, algoritmi e parametri di controllo. Inoltre, esse mostrano lo stato delle informazioni elaborate, uno storico dei dati (report), e altre informazioni utili a operatori, amministratori, manager. La loro posizione, piattaforma e interfaccia possono variare secondo le implementazioni. Ad esempio, un HMI può essere una piattaforma dedicata nel centro di controllo, un portatile in una WLAN, un browser o qualsiasi altro sistema connesso a internet.
Storico dei dati: è un database centralizzato che registra tutte le informazioni dei processi di un ICS. Queste informazioni possono essere utilizzate per produrre analisi o statistiche aziendali.
Input/Output Server: è il componente responsabile della raccolta dati. Permette l’accesso a informazioni di processo e ai componenti di controllo come PLC, RTU, IED. I server Input/Output sono utilizzati inoltre come interfaccia verso componenti di controllo di terze parti, come le HMI o i server di controllo.
Componenti di rete
Esistono diverse caratteristiche di rete per ogni strato della gerarchia in un sistema di
controllo. Le topologie di rete delle varie implementazioni dei sistemi ICS sono cambiate
molto grazie ai moderni sistemi internet-based7. Infatti, le moderne reti di controllo si sono
fuse con le reti aziendali permettendo agli operatori il monitoraggio e il controllo dei
sistemi anche dall’esterno.
7 internet based: rete che collega milioni di computer in tutto il mondo per lo scambio di dati
e informazioni
Sistemi di controllo industriale
19
I principali componenti di rete di un sistema ICS sono:
Bus di campo (Fieldbus): questo componente collega i dispositivi di campo (sensori, attuatori, ecc...) ai vari PLC o controller. Questa tecnologia elimina un insieme di collegamenti punto-punto tra il controller e ogni dispositivo. I dispositivi comunicano con il controller del bus di campo mediante protocolli diversi. I messaggi trasmessi tra i sensori e il controller, identificano univocamente ogni sensore.
Rete di controllo: collega il livello del supervisor con i moduli di controllo dei livelli più bassi.
Router: è il dispositivo di comunicazione che trasporta messaggi tra due reti. Sono comunemente utilizzati per collegare una rete locale (LAN) ad una WAN, oppure in reti a lunghe distanza MTU a RTU.
Firewall: protegge i dispositivi all’interno di una rete, monitorando e controllando i pacchetti di comunicazione secondo le politiche e i filtri predefiniti. I firewall permettono di implementare strategie di separazione in reti ICS.
Modem: permette la conversione da dati digitali ad analogici e viceversa, consentendo ai dispositivi di comunicare tra loro tramite linee telefoniche. I modem sono spesso utilizzati nei sistemi SCADA per comunicazioni a lunga distanza tra MTU e dispositivi di campo remoti. Sono inoltre utilizzati nei sistemi SCADA, nei DCS e nei PLC per consentire accessi remoti e per operazioni di manutenzione come ad esempio diagnosi, modifica dei parametri e dei comandi.
Come accennato all’inizio del capitolo precedente, l’acronimo SCADA indica i sistemi di
Controllo di Supervisione e Acquisizione Dati. Le sezioni successive descrivono le funzioni
svolte da un sistema SCADA e le differenze che possono essere individuate tra questo tipo
di sistemi e un affine: DCS (Distributed Control System). A conclusione del capitolo sono
descritti due esempi di sistemi SCADA nel mondo reale.
2.1 Supervisione
La supervisione è la funzione di un sistema SCADA che permette di osservare e controllare
l’evoluzione degli stati di un processo. Questo comprende tutte le funzionalità di
visualizzazione delle informazioni relative allo stato dei processi, di gestione delle
informazioni storiche, di trattamento degli stati che costituiscono eccezioni rispetto alla
normale evoluzione dei processi controllati. La funzione di supervisione è importante in
un sistema SCADA poiché, non può essere definito come SCADA un sistema che non
permette di accedere alle informazioni di stato corrente e/o storiche del processo
osservato o controllato (5).
2.2 Controllo
La funzione di controllo rappresenta la capacità di un sistema di prendere decisioni sul
cambiamento di stato del processo controllato in funzione dell’evoluzione del processo
stesso. Le regole con le quali le procedure di controllo sono realizzate, dipendono
fortemente dal tipo di processo. Le funzionalità di controllo sono quindi concentrate nel
sistema di elaborazione il quale, dopo gli opportuni controlli, utilizza i componenti che
fanno parte della catena di acquisizione dati, per modificare i parametri di stato del
processo controllato. (5)
2
SCADA
22
Capitolo 2
2.3 Acquisizione dati
L’acquisizione dati è una funzione che nella maggior parte dei casi ha un ruolo di supporto
alle funzioni di supervisione e controllo poiché mette in relazione il sistema con il
processo controllato. Ciò consente la conoscenza dello stato del processo e
l’implementazione del controllo che varia i parametri caratteristici del processo stesso. In
questo senso “acquisizione dati” significa in realtà scambio dati in entrambe le direzioni:
dal processo verso il sistema e viceversa. Nei sistemi SCADA l’acquisizione è la funzione
principale del sistema; questo è il caso in cui non ci sono procedure di controllo
implementate dal sistema e la fase di supervisione può essere realizzata sia
sporadicamente che come analisi a posteriori degli stati acquisiti dal processo. Un esempio
può essere un qualsiasi sistema di telerilevamento nel quale l’obiettivo principale è la
raccolta e l’organizzazione dei dati sui quali, in seguito, possono essere condotte analisi
non necessariamente predefinite.
L’acquisizione dati contribuisce a definire il sistema SCADA poiché non è possibile
eseguire funzioni di supervisione senza acquisire informazioni sullo stato del processo
osservato, così come non è possibile orientarne il comportamento, cioè controllarlo, senza
poterne influenzare lo stato modificando il valore di parametri che lo caratterizzano.
La funzione di acquisizione dati di un sistema SCADA è considerata generalmente un
semplice scambio d’informazioni tra la parte di sistema che realizza supervisione e
controllo e il processo controllato. In altri termini, essa non comprende un qualsiasi
processo decisionale delle strutture di supervisione e controllo sul processo controllato.
Se questa condizione non è soddisfatta, si deve parlare di sistemi a intelligenza distribuita
che operano in modo diverso da un sistema SCADA inteso in senso classico. Uno dei motivi
di questa distinzione è dovuto alla capacità di elaborazione, necessaria solo se il processo
controllato ha dimensioni geograficamente rilevanti, tali da ostacolare la realizzazione di
un sistema di elaborazione centralizzato e localizzato in prossimità del processo. (5)
2.4 Confronto tra SCADA e DCS
La distinzione tra SCADA e DCS è basata sul grado di distribuzione dell’intelligenza del
sistema. Il sistema SCADA è stato sempre considerato come sistema con funzioni di
controllo centralizzate nel sottosistema di elaborazione e fisicamente e tecnologicamente
distinte dalle funzioni di acquisizione. I sistemi DCS sono caratterizzati da strutture di
acquisizione dotate di elevata capacità di elaborazione.
Nel caso dei sistemi DCS non è possibile parlare, come per i sistemi scada, di
apparecchiature di acquisizione poiché esse sono veri e propri sistemi di elaborazione in
grado di interpretare i dati provenienti dall’osservazione del processo, valutarne le
caratteristiche e prendere decisioni sul controllo dello stato. In questo contesto, un centro
di supervisione di un sistema DCS acquisisce sia dati grezzi sullo stato del processo sia
informazioni aggregate relative allo stato di esercizio delle strutture di controllo.
SCADA
23
L’evoluzione delle tecnologie coinvolte nello sviluppo dei sistemi di controllo
richiede di distinguere i sistemi SCADA dai sistemi DCS: la distinzione è stata prodotta
dalle caratteristiche tecnologiche e dalle scelte realizzative divenute dominanti nell’ambito
dei singoli problemi di controllo. Con lo sviluppo delle tecnologie dei sistemi di
elaborazione e delle infrastrutture di comunicazione, la scelta tra un sistema a controllo
centralizzato e di acquisizione pura e un sistema a controllo distribuito e apparecchiature
di acquisizione complesse, diviene sempre dipendente da fattori quali la scalabilità, la
manutenibilità o altre caratteristiche di progetto diverse dalla realizzabilità del sistema di
supervisione e controllo. In questo senso, la distinzione tra DCS e SCADA sta diventando
poco rilevante per motivi sia tecnologici sia funzionali e si può prevedere che ben presto i
due tipi di sistemi saranno inclusi in un’unica categoria. (5)
È sempre più comune pensare di poter implementare le funzioni SCADA attraverso
sistemi DCS poiché le specifiche tra i due sistemi sono molto simili. Tuttavia, come
descritto in (6) e (7), gli obiettivi, il funzionamento e le caratteristiche dei due sistemi sono
differenti:
1. Lo scopo principale dei DCS è di controllare i processi dell’impianto, e
mostrare i risultati agli operatori. L’obiettivo dei sistemi SCADA è invece
quello di raccogliere le informazioni da mostrare al centro di controllo e agli
operatori. Tuttavia, questi sistemi possono anche eseguire operazioni
complesse sui processi controllati.
2. I sistemi SCADA sono utilizzati per controllare e monitorare vaste aree
geografiche e sono tipicamente utilizzati in sistemi di distribuzione
(elettricità, acqua, ecc.), di trasmissione (olio, gas, trasmissioni elettriche,
ecc.) che coprono larghe aree geografiche. I sistemi DCS sono invece
associati al controllo di singoli impianti, dove sono presenti molteplici
controllori, stazioni degli operatori, storico dei dati e altri strumenti di
analisi e configurazione.
3. Nei DCS, la stazione dell’operatore è direttamente collegata con i dispositivi
di campo. Quando un operatore vuole ottenere delle informazioni, esegue
una richiesta direttamente al dispositivo di campo. Inoltre, gli eventi
generati nel campo possono direttamente interrompere il sistema e avvisare
gli operatori. A differenza dei DCS, gli SCADA operano quando le
comunicazioni di campo falliscono. Infatti, questi sistemi permettono di
eseguire delle operazioni speciali per gestire i problemi di acquisizione dei
dati.
4. I sistemi SCADA devono ottenere dati e controllare il processo maniera
sicura, anche in situazioni dove le comunicazioni sono lente o inaffidabili, e
richiedono di mantenere un database con gli ultimi valori corretti da
mostrare agli operatori. Per questo è spesso necessario validare gli eventi
elaborati e la qualità dei dati ottenuti. I DCS invece sono sempre connessi
alla sorgente dei dati e quindi non richiedono un database contenente i
valori correnti. A differenza degli SCADA, la ridondanza è gestita con
apparecchiature parallele e non con la diffusione distribuita dei dati su più
risorse.
24
Capitolo 2
5. La complessità nei sistemi SCADA è dovuta alla gestione di database di
informazioni e alla raccolta dati. Nei sistemi DCS, la complessità è invece
dovuta alla gestione dei processi di controllo.
Nonostante le differenze descritte in precedenza, è comunque possibile utilizzare i
sistemi SCADA per gestire le funzionalità offerte dai DCS, così come è possibile utilizzare i
DCS per gestire le funzionalità degli SCADA.
2.5 Applicazioni di sistemi SCADA
I sistemi SCADA sono diffusi in tutto il mondo e permettono di monitorare e controllare
molteplici processi e operazioni all’interno d’infrastrutture critiche. Questa sezione
presenta applicazioni reali dei sistemi ICS.
Gestione del traffico ferroviario (5)
Uno scalo ferroviario può essere descritto, in generale, come un sistema di gestione del
flusso dei convogli dotato di un insieme di linee d’ingresso, un insieme di linee di uscita e
un terzo insieme di linee interne allo scalo. La gestione del traffico deve associare una
linea d’ingresso e una di uscita alla stessa linea interna in modo da generare continuità tra
ingresso e uscita. Ciò permette ad un convoglio proveniente dalla linea d’ingresso di
procedere, dopo aver effettuato la fermata per servizio viaggiatori, verso la meta
raggiungibile dalla linea d’uscita.
Per anni la gestione è stata condotta da operatori che, in base alle indicazioni dei
responsabili del traffico, provvedevano al corretto posizionamento degli scambi ferroviari,
cioè dei sistemi di deviazione che permettono l’associazione di una linea interna a una tra
le due linee d’ingresso o d’uscita adiacenti. Questa pratica ha posto le basi per il
movimento dei convogli, sulle quali è stato costruito un sistema di segnalazioni gestuali
per la trasmissione del comando di partenza e di fermata.
Una prima evoluzione di questo sistema è stata l’introduzione dei semafori di
segnalazione delle autorizzazioni riguardanti il movimento. Il responsabile del traffico ha
così potuto demandare al semaforo tutte le funzioni di segnalazione riguardante il
movimento. Allo stesso tempo, è stato necessario rendere disponibile al personale addetto
al traffico un sistema di gestione delle segnalazioni, un semplice quadro elettrico con gli
interruttori dei segnali luminosi.
Il secondo elemento di sviluppo degli scali ferroviari è stato l’introduzione dei
sistemi semiautomatici di gestione del traffico che possono essere considerati a pieno
titolo sistemi SCADA. L’evoluzione tecnologica ha consentito di realizzare scambi
ferroviari dotati di sistemi elettromeccanici che permettono il controllo della posizione
per mezzo di segnali elettrici impartiti a distanza. Il controllo della posizione comprende il
comando di assunzione di una tra le posizioni consentite e la segnalazione della posizione
SCADA
25
raggiunta al sistema che ha impartito il comando. Sfruttando questi apparati è stato
possibile pensare a un sistema che raccogliesse le informazioni riguardanti la posizione di
ogni scambio ferroviario nello scalo e allo stato di segnalazione di ogni semaforo.
I sistemi SCADA implementano tre funzionalità fondamentali:
Acquisizione dati. Acquisizione degli stati riguardanti gli scambi ferroviari
(posizioni) e al sistema di semafori (segnalazioni);
Supervisione. Visualizzazione dello stato di esercizio dello scalo sulla base dei dati
acquisiti.
Controllo. Gestione centralizzata della posizione degli scambi ferroviari e delle
segnalazioni del sistema di semafori.
Grazie a questi sistemi i responsabili del traffico ferroviario hanno una
rappresentazione schematica completa dello scalo che illustra i percorsi attivi praticabili e
lo stato d’uso. Gli stessi sistemi comprendono dispositivi che permettono di impartire
comandi agli apparati di deviazione e segnalazioni ai convogli.
La Figura 5 schematizza un sistema di controllo del traffico ferroviario. In
particolare rappresenta le due componenti fondamentali per l’interazione tra operatori e
sistema: il quadro sinottico e il banco di controllo. Il quadro sinottico contiene una
rappresentazione topologica dello scalo animata da un meccanismo di retroilluminazione
che consente di avere informazioni sulle posizioni degli scambi ferroviari e gli stati delle
segnalazioni luminose. Ciò fornisce una rappresentazione dello stato di esercizio dello
scalo. Il banco di controllo è dotato di pulsanti e leve che permettono di inviare segnali
elettrici ai sistemi di manovra e di segnalazione, ossia di comandare la variazione di
posizione agli scambi ferroviari e il cambiamento della segnalazione al sistema di
semafori.
26
Capitolo 2
Figura 5: Sistema di controllo del traffico ferroviario.
Il quadro sinottico e il banco di controllo realizzano le funzioni di supervisione e
controllo del sistema e svolgono tali funzioni sfruttando un’altra porzione di sistema
dedicata all’acquisizione dati quale l’intero sistema di scambio delle informazioni:
comandi diretti ai sistemi di segnalazione di manovra e informazioni di stato dirette al
sistema di controllo per la rappresentazione sul quadro sinottico.
Lo sviluppo tecnologico dei sistemi di calcolo ha consentito ai sistemi di gestione del
traffico ferroviario una seconda fase evolutiva. In particolare, è stato possibile introdurre
procedure di elaborazione delle informazioni di stato dello scalo per la verifica della
congruenza tra posizioni degli organi di manovra e segnalazioni luminose impartite ai
convogli, alla gestione di stati di esercizio anomali quali guasti e interruzioni del servizio
per manutenzione, alla verifica della presenza di convogli nei tronchi di linea gestiti dal
sistema.
Gli stadi di sviluppo dei sistemi di gestione del traffico ferroviario reali sono stati
caratterizzati dall’introduzione di meccanismi automatici per la gestione delle barriere dei
passaggi a livello adiacenti agli scali, la segnalazione agli scali adiacenti della posizione dei
convogli e dell’entità di eventuali ritardi, la configurazione automatica della topologia
attiva in funzione dell’orario di esercizio. La complessità degli attuali sistemi dipende
dall’insieme di funzioni che essi possono svolgere mentre la struttura che li caratterizza è
in gran parte simile a quella dei primi prototipi realizzati.
SCADA
27
Produzione di energia elettrica (8)
Un tradizionale impianto di generazione di potenza elettrica produce elettricità sfruttando
l'energia dell'acqua che cade oppure producendo calore attraverso la combustione di
combustibili fossili. Analizziamo in questo esempio un impianto di combustibile fossile.
Come nelle centrali nucleari, applicando del calore all'acqua, si genera del vapore, il
che è utilizzato per alimentare le turbine che generano energia elettrica. L'energia elettrica
è poi trasmessa e distribuita a differenti tensioni a sottostazioni elettriche. La Figura 6
mostra una panoramica geografica di un impianto elettrico a combustibile fossile e il
successivo percorso dell'energia elettrica prodotta per il consumatore finale.
In una centrale a carbone, il carbone è schiacciato, immagazzinato in silos,
polverizzato, e convogliato in una fornace. La combustione del carbone genera calore per
una caldaia che genera vapore utilizzato per manovrare turbine a vapore. Le turbine, a
loro volta, guidano generatori elettrici che forniscono energia per la trasmissione e la rete
di distribuzione. Il vapore viene condensato e fatto ricircolare nella caldaia per ripetere il
processo. Una camera di controllo locale che è parte di un sistema SCADA gestisce
l'impianto e suoi processi. La Figura 7 illustra questo processo e i relativi componenti.
Figura 6: Generazione di energia elettrica e distribuzione geografica.
28
Capitolo 2
Figura 7: Tipica centrale elettrica a combustione fossile.
SCADA
29
Per il corretto funzionamento dell’impianto i parametri e i dispositivi da controllare
sono numerosi ed essi comprendono anche i sistemi di emergenza. I principali componenti
SCADA sono nella sala di controllo e nelle sottostazioni. Le RTU8 si trovano in tutto
l’impianto in corrispondenza dei punti di controllo. I componenti di controllo coinvolti
sono:
Computer di gestione dell’energia PLC Master di supervisione e controllo PLC Master di backup a caldo9 PLC di controllo delle turbine PLC di controllo dei bruciatori PLC di controllo della qualità dell’aria PLC di controllo del trattamento acque PLC di controllo della caldaia PLC per il sistema di trasporto PLC per le sottostazioni di controllo
8 Un RTU (Remote Terminal Unit) è un dispositivo elettronico a microprocessore situato in un
punto remoto in cui è concentrata l'informazione di processo. Esso rileva l'informazione di processo che viene inviata al centro di controllo. Inoltre, realizza i controlli periferici come specificato dal centro di controllo. (10)
9 Le operazioni di backup a caldo (in inglese hot backup), detto anche backup dinamico, sono eseguite sui dati, anche se il programma che ne sta facendo uso è ancora attivo. Infatti, durante le operazioni di backup i dati sono attivamente accessibili dagli utenti. A differenza del tradizionale backup a freddo, questa tipologia di backup non richiede tempi d’inattività.
30
Capitolo 2
La Figura 8 illustra le stazioni di controllo e le rispettive interazioni.
Figura 8: Impianto di controllo dei componenti
Questo capitolo fornisce una visione d'insieme dei sistemi SCADA, DCS e PLC, descrivendo
le principali implementazioni e architetture comunemente utilizzate. Sono inoltre presenti
immagini che raffigurano le più comuni implementazioni di connessioni di rete e
componenti. Tenere presente che le figure presenti in questo capitolo non mostrano un
sistema ICS sicuro. Architetture e controlli di sicurezza saranno discussi nel capitolo
Sicurezza in SCADA.
3.1 SCADA
I sistemi SCADA sono utilizzati per acquisire dati e controllare risorse distribuite in vaste
aree geografiche, raccogliere informazioni di campo, trasferirle in un impianto centrale e
mostrarle all’operatore in maniera grafica o testuale. In questi sistemi, le HMI permettono
di centralizzare operazioni di monitoraggio e controllo per numerosi processi. In base alle
configurazioni dei sistemi, operazioni e processi possono essere automatizzati o eseguiti
dagli operatori grazie a specifici comandi.
Un sistema SCADA è costituito di parti hardware e software. L’hardware in genere
comprende un MTU posto in un centro di controllo, dispositivi di comunicazione (radio,
linee telefoniche, cavi o satelliti), e uno o più siti distribuiti geograficamente, che
comprendono RTU o un PLC il quale controlla attuatori e sensori. Gli MTU memorizzano
ed elaborano le informazioni ricevute dagli RTU, mentre gli RTU o i PLC controllano i
processi locali. Le connessioni hardware permettono il trasferimento d’informazioni e dati
(comunicazione bidirezionale) tra MTU e RTU o PLC. I componenti software determinano
cosa e quando monitorare, qual è l’intervallo accettabile per i parametri, e come reagire
quando i parametri sono al di fuori di questo intervallo. Invece, un IED può comunicare
direttamente con un server SCADA e fornire un’interfaccia diretta per controllare e
monitorare le strumentazioni e i sensori. La comunicazione dei dati e delle informazioni
da parte di questi dispositivi può avvenire anche tramite polling10.
10 Polling: verifica ciclica di tutte le unità o periferiche (slave) da parte del master
3
Implementazioni e architetture
32
Capitolo 3
In Figura 9 è illustrata una configurazione classica e le rispettive parti di un sistema
SCADA.
Figura 9: Configurazione classica di un sistema SCADA.
Il centro di controllo ospita un server SCADA MTU, e uno o più router. Altri elementi
di un centro di controllo sono le HMI, le postazioni degli operatori, e il database per lo
storico dei dati. Questi componenti sono connessi tramite una rete locale. Il centro di
controllo raccoglie e registra le informazioni ottenute dai vari siti e le mostra tramite le
HMI che possono anche eseguire operazioni in base agli eventi rilevati. Il centro di
controllo è anche responsabile degli allarmi centralizzati, dell’analisi e della reportistica
delle informazioni.
I siti possono eseguire operazioni di monitoraggio locale e di controllo di attuatori e
sensori. Esistono apparecchiature per accesso remoto, che permettono a operatori di
campo, di compiere diagnosi e riparazioni tramite una connessione al modem o alla WAN.
Lo scambio d’informazioni può utilizzare protocolli di comunicazione standard e
proprietari. La topologia delle connessioni tra MTU e RTU varia secondo le
implementazioni, quelle più utilizzate sono punto-punto, in serie, serie a stella e multi-
drop (bus) illustrate in Figura 10.
La topologia punto-punto è la più semplice, ma anche la più costosa poiché utilizza
un canale dedicato per ogni connessione. Invece, una configurazione a serie utilizza un
numero di canali inferiori con lo svantaggio di condividere il canale di comunicazione ed
influenzando in questo modo l’efficienza e la complessità delle operazioni SCADA. In modo
simile, le configurazioni serie a stella e multi-drop usano un canale per dispositivo,
diminuendo l’efficienza e aumentando la complessità.
Implementazioni e architetture
33
Figura 10: Topologie di una comunicazione SCADA.
Le architetture in Figura 10 possono essere ampliate utilizzando dispositivi di
comunicazione dedicati che gestiscono gli scambi instradando o bufferizzando i messaggi.
La Figura 11 mostra la topologia di un sistema SCADA molto esteso, che può contenere
centinaia di RTU e che utilizza sub-MTU per alleggerire il lavoro del MTU primario.
Figura 11: Topologia SCADA molto estesi.
34
Capitolo 3
Una possibile implementazione di un sistema SCADA per il controllo e monitoraggio
decentralizzato è illustrata in Figura 12. Questo sistema comprende un centro di controllo
primario che gestisce tre siti. Un secondo centro di controllo, di backup, fornisce
ridondanza nel caso di malfunzionamenti nel primo. In questo caso, sono utilizzate
connessioni punto-punto per le comunicazioni dal centro di controllo ai tre siti. Inoltre, il
terzo sito è situato nel centro di controllo ed è collegato a questo tramite WAN. Esiste
anche un centro di controllo regionale che fornisce un livello più alto di supervisione. La
rete aziendale, tramite la WAN, ha accesso a tutti i centri di controllo. Il centro di controllo
primario interroga a intervalli temporali prefissati i dispositivi di campo per ottenere dati
e può impostare nuovi set-point per ogni dispositivo.
Figura 12: Esempio di SCADA per monitoraggio e controllo decentralizzato.
Un altro esempio di architettura SCADA è mostrato in Figura 13. In questo caso
l’architettura del sistema è composta da un centro di controllo che ospita un sistema
SCADA e siti separati rappresentati da tre sezioni di binari. Il server di controllo SCADA
interroga le sezioni dei binari per acquisire informazioni su stato dei treni, segnali di
sistema o anche informazioni sui distributori automatici di biglietti. Queste informazioni
sono anche visibili dalla console operatore nella stazione HMI. Inoltre, il sistema SCADA
controlla gli input degli operatori del centro di controllo dei binari e le condizioni delle tre
sezioni. Il sistema può anche generare comandi in base alle condizioni del sistema; ad
Implementazioni e architetture
35
esempio può fermare un treno per evitare che entri in un’area che è stata inondata o
occupata da altri treni.
Figura 13: Esempio di SCADA per la gestione del traffico ferroviario.
3.2 DCS
I sistemi DCS sono utilizzati localmente alle aree geografiche dei sistemi di produzione.
Questi sistemi sono solo una parte dei sistemi di controllo. Un DCS utilizza dei cicli di
controllo centralizzati per collegare un gruppo di controllori locali che hanno come unico
compito quello di poter gestire dall’esterno un intero processo di produzione.
Decomponendo il sistema di produzione, un DCS riduce gli impatti di un singolo guasto
nell’intero sistema. Nei sistemi moderni, i DCS sono interfacciati con la rete aziendale per
fornire alle operazioni di business una vista della produzione.
La Figura 14 mostra un’implementazione generale di un sistema DCS e le relative
componenti. In questo esempio, il DCS racchiude un intero impianto, partendo dai processi
di produzione a livello più basso fino ad arrivare al livello di rete aziendale. Si può
osservare che il centro di controllo, supervisory controller, comunica con le altre
componenti tramite la rete di controllo. Il Supervisor invia i set-point e riceve i dati dai
36
Capitolo 3
controllori di campo distribuiti sul sito. I controllori gestiscono i processi degli attuatori in
base sia ai comandi del server sia alle risposte elaborate dai sensori.
In questo esempio abbiamo un controllore a basso livello in un sistema DCS. I
dispositivi di controllo di campo includono un PLC, un Controllore di Processo, uno a Ciclo
Unico e uno con una HMI collegata. Il Controllore a ciclo unico s’interfaccia con sensori e
attuatori attraverso un collegamento punto-punto, mentre gli altri tre dispositivi di campo
utilizzano un bus di campo per interfacciarsi con i sensori e gli attuatori. Il bus di campo
evita i collegamenti punto-punto tra un controllore e un singolo sensore o attuatore di
campo. Inoltre, permette controlli di diagnostica dei dispositivi e algoritmi di controllo
all’interno del bus evitando di trasmettere al PLC, per ogni controllo, i segnali di routing.
Esistono protocolli standard progettati per lavorare in reti di bus di campo, come Modbus,
Profibus e Fieldbus (9).
Figura 14: Implementazione di un sistema DCS.
Implementazioni e architetture
37
3.3 PLC
I PLC sono utilizzati sia nei sistemi SCADA che nei sistemi DCS come componenti di
controllo che permettono una gestione locale dei processi attraverso dei controlli sulle
informazioni e sui dati. Nel caso di sistemi SCADA, essi forniscono le stesse funzionalità
degli RTU. Se, invece, i PLC sono utilizzati in sistemi DCS, essi sono implementati come
controllori locali in un schema di controllo e supervisione. Nei sistemi di controllo di
dimensioni ridotte, i PLC costituiscono gli elementi primari. Hanno una memoria
programmabile utile per memorizzare istruzioni e che permette di implementare
specifiche funzioni come controlli di I/O, logici, contatori, PID (proportional integral
derivative), comunicazione, aritmetica ed elaborazione dati e file.
La Figura 15 mostra un processo eseguito da un PLC in una rete a bus. In questo caso
il PLC è accessibile tramite un’interfaccia programmabile presente in una stazione
ingegneristica, e i dati rilevati sono salvati nel DB.
Figura 15: Esempio d’imlementazione di un PLC.
Per motivi di efficienza e manutenzione, le piattaforme di acquisizione e controllo dati si
sono evolute da reti aziendali isolate con protocolli e attrezzature proprietarie, in sistemi
computer-based che utilizzano software e protocolli di rete standard che permettono
comunicazioni attraverso Internet. Il lato negativo di questa transizione è l’esposizione dei
sistemi SCADA alle stesse minacce e vulnerabilità che affliggono le reti ICT classiche.
Alcuni degli attacchi tipici che si possono eseguire ai danni di sistemi SCADA che
utilizzano hardware e software standard sono:
Esecuzione di codici malevoli (virus, trojan e worm); Divulgazione e modifica non autorizzata di informazioni; Denial of Service11(DoS); Accesso e modifica non autorizzata ai log di sistema.
La gran parte dei sistemi SCADA opera in ambienti real-time12. Questo tipo di sistemi
non ammette ritardi nelle comunicazioni o nell’esecuzione di operazioni critiche. L’utilizzo
di software che soddisfa a requisiti di sicurezza con conseguente aumento di complessità,
può interferire con i vincoli in tempo reale del sistema, mettendo a rischio la sicurezza
delle persone, la qualità dei prodotti e causando costi aggiuntivi. Inoltre, le componenti dei
sistemi SCADA non hanno capacità computazionali adeguate.
11 Il termine Denial of Service (DoS), letteralmente negazione del servizio, sta a indicare una
tipologia di attacco informatico il cui obiettivo è di portare il funzionamento di un sistema informatico che mette a disposizione un servizio, al limite delle prestazioni esaurendo quante più risorse possibili e rendendolo inutilizzabile al punto di non erogare più il servizio offerto, negando quindi le successive richieste di utilizzo.
12 I sistemi real-time sono sistemi in cui la correttezza non dipende solamente dai risultati
prodotti ma anche dal tempo necessario per produrli. Ciò comporta che tali sistemi devono rispondere ad eventi esterni entro tempi prestabiliti. Tuttavia un sistema real-time non deve necessariamente essere veloce poiché non è importante l’intervallo di tempo in cui il sistema deve reagire, ma che risponda entro un tempo predeterminato. In altre parole il sistema deve essere prevedibile.
4
Sicurezza in SCADA
40
Capitolo 4
4.1 Convergenza dei sistemi SCADA e IT
Molte organizzazioni cercano di integrare le componenti SCADA con quelle IT aziendali
per far coincidere e collegare le attività aziendali con quelle industriali. Questa tendenza è
motivata dal risparmio economico che si ottiene consolidando piattaforme differenti, reti,
software e strumenti di manutenzione. Per di più, integrare la raccolta dati SCADA con i
dati finanziari dell’azienda fornisce una gestione aziendale più efficiente.
Tuttavia, un’integrazione di questo tipo genera diversi problemi. Ad esempio, da un
punto di vista della sicurezza, è opportuno ricordare che i sistemi SCADA e IT hanno
diverse priorità e quindi la loro integrazione porta a usare modelli di sicurezza che
introducono compromessi. Problemi quali quelli causati da modem connessi su una rete
permettono di compromettere il sistema SCADA tramite le connessioni Internet della rete
aziendale. Altri problemi possono essere legai ai tempi di fermi nel sistema IT aziendale
quando, ad esempio, sono effettuate operazioni di aggiornamento software, backup e cosi
via. Queste situazioni di non possono essere tollerate nei sistemi SCADA.
4.2 Sicurezza nell’IT e relativi problemi in SCADA
Negli anni, esperti e gruppi di lavoro nella sicurezza informatica, hanno sviluppato e
pubblicato un gran numero di best practice13, per proteggere le reti e le infrastrutture
informatiche da attacchi. Queste best practice possono essere applicate direttamente ai
sistemi SCADA considerando solo le differenze dei requisiti tra i due sistemi.
Descriviamo ora alcuni esempi di best practice sviluppate per sistemi IT e le loro
applicazioni nei sistemi SCADA:
Audit e Monitoraggio. Le analisi effettuate dopo il verificarsi di un evento sono utili per determinare eventi passati. Il monitoraggio invece, implica la cattura di dati in tempo reale in sistemi che continuano a eseguire le loro operazioni. Sia l’audit che il monitoraggio sono tecniche completamente implementate nei sistemi IT. La loro applicazione nei sistemi SCADA porterebbe benefici simili a quelli derivanti dal loro utilizzo in sistemi IT. Purtroppo però, a causa delle componenti obsolete e sofisticate dei sistemi SCADA, potrebbe non essere sempre possibile realizzare audit e monitoraggi globali.
Sistemi biometrici. L’utilizzo di autenticazione biometrica tramite il riconoscimento di caratteristiche fisiche degli individui è da sempre affascinante, ma al momento non è completamente affidabile. Dipendentemente dalle caratteristiche da esaminare, possono esserci un numero elevato di autenticazioni errate fallite. Tuttavia la tecnologia è in fase di progresso e l’utilizzo di autenticazione biometrica potrebbe essere una valida alternativa agli attuali meccanismi di autenticazione.
13 Una best practice, letteralmente miglior pratica, è un metodo o una tecnica che ha risultati
superiori a quelli raggiunti con altri mezzi, e che viene impiegato come punto di riferimento per una misurazione (benchmark). Una best practice può evolvere e migliorare. Il termine best practice è considerato da alcuni come uno slogan commerciale, per descrivere un processo di sviluppo e in seguito una metodologia standard che possono adottare le aziende.
Sicurezza in SCADA
41
Firewall. I firewall permettono di generare allarmi riguardanti il traffico tra la rete aziendale e SCADA. In molte occasioni, un firewall potrebbe proteggere i sistemi SCADA da attacchi provenienti dal lato aziendale. Alcuni problemi da considerare nell’installazione di firewall all’interno di reti SCADA sono: il ritardo che s’introduce nella trasmissione di dati, le competenze e i costi necessari per la configurazione e la gestione degli apparati, e la mancanza di controlli specifici per protocolli SCADA.
Intrusion Detection System (IDS). Esistono due tipi di IDS: Network IDS (NIDS) e Host IDS (HIDS). Gli HIDS possono scoprire attacchi contro il nodo di rete cui sono collegati, mentre il NIDS controlla la rete, monitorandone il traffico per individuare azioni non permesse. Gli IDS possono essere utilizzati solo in modo limitato poiché tuttora non sono disponibili veri e propri IDS sviluppati per operare con protocolli SCADA o per monitorare i bus di campo. Inoltre, l’utilizzo di IDS potrebbe rallentare il normale funzionamento della rete.
Individuazione ed Eliminazione di Codice malevolo. Il costo computazionale per scoprire e rimuovere codice malevolo che potrebbe infettare sistemi SCADA, può violare i vincoli real-time. Processi come l’esecuzione di software antivirus, aggiornamento delle firme (signature), eliminazione e quarantena di codice malevolo richiedono tempi che potrebbero non essere ammissibili in sistemi SCADA. Inoltre, l’aggiornamento dei database attraverso Internet potrebbe esporre i sistemi a minacce provenienti dall’esterno.
Password. Negli ambienti SCADA può essere necessario l’utilizzo di password per ottenere accesso ai dispositivi. Se un operatore tenta più volte l’accesso al dispositivo utilizzando password errate, una tradizionale misura di sicurezza è quella di bloccare l’operatore. Questo meccanismo di sicurezza non è però applicabile in ambienti di controllo in tempo reale. Le password utilizzate nei dispositivi di controllo locali devono essere eliminate o rese molto semplici. A livello di supervisione invece, possono essere impiegate password più lunghe e complesse. Inoltre, in situazioni dove le password possono essere trasmesse in rete e quindi soggette a intercettazione, la crittografia può essere un buon compromesso.
Controllo degli accessi basato sui ruoli. Questo tipo di controllo è ampiamente utilizzato nel settore governativo e industriale, poiché si adatta ai cambiamenti del personale e dell’organizzazione. In questo tipo di controlli di sicurezza, l’accesso è basato sul ruolo di una persona nell’organizzazione, e può essere revocato quando non ce n’è più bisogno.
Crittografia a chiave pubblica. La crittografia a chiave pubblica o chiave asimmetrica, non richiede di scambiare chiavi segrete tra chi riceve e chi invia messaggi. Una chiave pubblica è disponibile a tutti quelli che vogliono comunicare con chi possiede la chiave privata. La chiave privata è protetta e la conosce solo la parte che riceve i messaggi. La caratteristica principale della crittografia a chiave pubblica è che è impossibile ricavare la chiave privata da quella pubblica. Inoltre, l’utilizzo di questo meccanismo permette di firmare digitalmente documenti e inviarli a tutti quelli che possono accedere alla chiave pubblica. La firma garantisce che il documento è stato inviato dal proprietario della chiave privata. L’utilizzo di sistemi di crittografia a chiave pubblica richiede lunghi tempi di elaborazione. Per questo motivo, nei sistemi SCADA che richiedono computazioni in tempo reale, questo meccanismo di sicurezza non è utilizzabile.
42
Capitolo 4
Crittografica a chiave simmetrica. La crittografia a chiave simmetrica forza il mittente e il destinatario a condividere una chiave segreta per cifrare e decifrare i messaggi. La chiave deve essere distribuita in maniera sicura tra tutti i mittenti e destinatari. Una soluzione molto comune è quella di utilizzare la crittografia a chiave pubblica per distribuire la chiave segreta, e poi utilizzare crittografia a chiave simmetrica per proteggere i messaggi. La crittografia a chiave simmetrica ha tempi computazionali inferiori a quelli della crittografia a chiave pubblica. Nonostante ciò, la crittografia a chiave privata non è ancora ampiamente utilizzata in sistemi SCADA.
Oltre ai controlli di sicurezza tecnici e amministrativi, diverse misure fisiche di
sicurezza possono essere applicate per proteggere i sistemi SCADA. Backup, duplicati,
centri di controllo separati geograficamente possono garantire ridondanza e quindi
protezione contro attacchi umani o disastri naturali. Ad esempio, un backup del sistema
SCADA, in particolare della parte di supervisione e controllo, permette di non
interrompere le operazioni se il sistema primario viene compromesso.
4.3 Sicurezza protocolli SCADA
È importante ricordare che in sistemi SCADA non sono tollerati ritardi nelle
comunicazioni. Per tal motivo, non sono applicabili meccanismi di sicurezza che
richiedono elevati tempi computazionali.
Di seguito descriviamo alcuni meccanismi di sicurezza.
Firewall
Un elemento chiave della sicurezza in ogni rete collegata ad altre reti con livelli di
sicurezza diversi, è il Firewall che ha lo scopo di filtrare il traffico per bloccare eventuali
attacchi o comunicazioni non permesse. Tuttavia, molti firewall utilizzati nei sistemi
SCADA non supportano e non gestiscono i protocolli SCADA. Una tipica configurazione di
rete che implementa un firewall tra rete locale e Internet è illustrata in Figura 16.
I tre tipi di firewall più comuni sono packet-filtering, stateful inspection e proxy.
Un packet-filtering firewall lavora a livello tre della pila ISO/OSI, e seleziona i
pacchetti che possono entrare in una rete esaminando indirizzo IP sorgente, indirizzo IP
destinatario, protocollo. Grazie ai controlli sui pacchetti in ingresso, in particolare
sull’indirizzo del mittente, un firewall può bloccare pacchetti provenienti da indirizzi IP
indesiderati, come host non fidati, spam, pubblicità e così via.
Sicurezza in SCADA
43
Figura 16: Applicazione tipica di un firewall.
Il filtraggio si basa su un database contenente una lista per il controllo degli accessi
(Access Control List - ACL), memorizzata all’interno del firewall. Un packet-filtering
firewall può evitare che sia inviato del traffico a uno specifico indirizzo IP. Questo
meccanismo può essere utile per evitare che siano inviate informazioni riservate a un host,
e quindi limita il numero di messaggi per quello specifico host.
Un altro tipo di filtraggio esamina il protocollo del pacchetto. Alcuni dei protocolli
comunemente analizzati sono Internet Protocol (IP), Address Resolution Protocol (ARP),
Reverse Address Resolution Protocol (RARP), Transmission Control Protocol (TCP), User
Datagram Protocol (UDP), e Internet Control Message Protocol (ICMP). Il firewall può
quindi bloccare pacchetti di un protocollo specifico.
Nel filtraggio stateful dei pacchetti (stateful inspection) il firewall ricorda in una
tabella lo stato e le relazioni tra i pacchetti che lo attraversano. La tabella memorizza le
informazioni sulla sorgente e sulla destinazione associate al pacchetto, e utilizza delle
regole per determinare se la comunicazione è consentita e può continuare alla fase
successiva oppure deve essere bloccata. Le informazioni utilizzate per questo tipo di
analisi sono: l’indirizzo sorgente, l’indirizzo destinatario e la porta di comunicazione
utilizzata. Poiché le prestazioni di questo tipo di firewall dipendono dal tempo impiegato
44
Capitolo 4
per completare un’analisi dettagliata dello stato del pacchetto e del numero di
connessioni, è possibile che esso ritardi le comunicazioni; quindi, l’implementazione di
questi meccanismi in un sistema SCADA può causare ritardi con conseguenti danni alle
operazioni.
Un proxy firewall lavora a livello di applicazione, livello sette, della pila ISO/OSI ed è
definito come una parte autorizzata a eseguire operazioni per conto di qualcun altro.
Ad esempio, un firewall proxy può essere inserito tra un utente e un server per
nascondere l’identità dell’utente. Il server vedrà solo il proxy e quindi non potrà
identificare l’utente. Questa situazione vale anche in senso inverso, dove l’utente
interagisce con un proxy situato prima di un server. In questo caso l’utente non può
identificare né il server, né la rete che c’è dietro. Un firewall proxy è molto efficacie nella
protezione di reti nelle comunicazioni con reti esterne, come ad esempio Internet.
Zona Demilitarizzata (DMZ)
I firewall possono essere utilizzati per implementare architetture sicure di reti in sistemi
SCADA. Queste architetture si basano sul concetto di zona demilitarizzata o DMZ, una
regione che separa tra una rete pubblica (esterna) e una privata (interna). Per supportare
una DMZ, un firewall deve avere più interfacce esterne e, dove necessario, corrispondenti
liste per il controllo degli accessi.
Diverse architetture utilizzano le DMZ ma negli ambienti di acquisizione e controllo
dati sono solo due quelle implementabili, nello specifico: DMZ a singolo firewall e DMZ a
doppio firewall. Entrambe permettono di separare la rete aziendale da quella di controllo,
fornendo comunque a entrambe le reti connessioni a reti pubbliche come Internet.
Una DMZ a firewall singolo utilizza un firewall per filtrare i pacchetti che viaggiano
dalla rete aziendale e dalle reti esterne, alla rete locale di controllo. La DMZ contiene solo
gli elementi che possono essere acceduti dai computer aziendali o dalle reti pubbliche. Un
esempio di quest’architettura è mostrato in Figura 17.
Sicurezza in SCADA
45
Figura 17: DMZ a singolo firewall.
È possibile aumentare il livello di sicurezza di una rete SCADA aggiungendo un
secondo firewall tra la rete di controllo e la DMZ, in questo modo si ottiene una
configurazione di DMZ a doppio firewall. Un esempio è mostrato in Figura 18.
46
Capitolo 4
Figura 18: DMZ a doppio firewall.
Sicurezza in SCADA
47
Regole generali dei firewall
Le regole per i firewall devono essere costruite considerando i vari protocolli e servizi di
rete da analizzare. L’Industrial Automation Open Networking Association (IAONA) ha
sviluppato in (10) delle linee guida sui servizi di rete implementati dai sistemi SCADA,
riassunte nella Tabella 1.
PROTOCOLLI REGOLE
File Transfer Protocol (FTP) Permettere solo comunicazioni verso l’esterno. Deve utilizzare autenticazione e tunnel VPN cifrato. Non devono essere consentite le comunicazioni verso l’interno.
Trivial File Transfer Protocol (TFTP)
Non dovrebbe essere permesso utilizzare questo protocollo.
Simple Mail Transfer Protocol Devono essere permesse le email verso l’esterno e bloccate verso l’interno.
Telnet Le comunicazioni in uscita devono utilizzare un tunnel VPN cifrato. Le comunicazioni in ingresso devono utilizzare tunnel VPN cifrati e autenticati.
HyperText Transfer Protocol (HTTP)
Le comunicazioni in entrata non dovrebbero essere permesse, sempre che non siano necessarie. Se richiesto, HTTP dovrebbe essere utilizzo insieme a SSL (Secure Sockets Layer). Dovrebbero inoltre essere bloccate, le comunicazioni che utilizzano script.
Simple Network Management Protocol (SNMP)
Le comunicazioni SNMP non dovrebbero essere permesse salvo che non si utilizzi un’implementazione sicura della rete.
SCADA e protocolli industriali Nello sviluppo di questi protocolli non è stata considerata la sicurezza. Le comunicazioni devono essere proibite dall’esterno, e dalla rete aziendale, mentre devono essere limitate alla rete di processo e solo per determinate informazioni di controllo.
Tabella 1: Linee guida IAONA sui servizi di rete SCADA.
Questo capitolo descrive i più comuni protocolli di comunicazione utilizzati nei
sistemi SCADA.
5.1. Evoluzione dei protocolli SCADA
La necessità di scambiare dati e informazioni di controllo sia localmente che su lunghe
distanze, ha reso i protocolli SCADA sempre più specializzati e complessi. Una delle
caratteristiche essenziali che hanno portato allo sviluppo di nuovi protocolli è stata la
necessità di avere comunicazioni deterministiche. In quest’ambiente il determinismo
riguarda l’abilità di predire la quantità di tempo necessaria per una transizione, quando
tutti i fattori rilevanti sono conosciuti a priori. Per garantire tempi deterministici nelle
comunicazioni sono stati sviluppati negli anni, da diversi costruttori, protocolli e strutture
di comunicazione specifiche. In Tabella 2 sono riassunti i principali protocolli utilizzati nei
sistemi SCADA.
COSTRUTTORI PROTOCOLLI
Allen Bradley (Rockwell) DeviceNet, ConrolNet, DF1, Data Highway, Data Highway
485
Siemens Profibus
Modicon MODBUS, MODBUS Plus,
Tabella 2: Protocolli SCADA.
Nel 1990, gruppi d’industrie ed enti di standardizzazione, cominciarono a sviluppare
dei protocolli per i sistemi di controllo che non fossero proprietari o esclusivi di
5
Protocolli ICS
50
Capitolo 5
determinati costruttori. Quando negli anni successivi Internet divenne molto più comune e
utilizzato, le società cominciarono a sfruttare a loro vantaggio i protocolli e gli strumenti
sviluppati per questa tecnologia, come ad esempio la suite di protocolli TCP/IP e i
browser. In aggiunta, i costruttori e le organizzazioni, modificarono la tecnologia Ethernet
LAN per poterla implementare nelle reti SCADA.
5.2. Tecnologie di base dei sistemi SCADA
Per definire dove i protocolli possono essere applicati e per suddividere le funzioni
necessarie a inviare e ricevere i dati in una comunicazione, è stato utilizzato un modello a
livelli. Due dei modelli più utilizzati sono il modello OSI (Open System Interconnection) e il
TCP/IP (Transmission Control Protocol/Internet Protocol).
Descriviamo brevemente i due modelli appena citati.
Il modello OSI
L’Open System Interconnection (OSI) è stato sviluppato all’inizio degli anni ’80
dall’International Standard Organization (ISO). Il modello ISO/OSI, concepito per reti di
telecomunicazioni a commutazione di pacchetto, è costituito da una pila, stack, di
protocolli utilizzati per semplificare l’implementazione di un sistema di comunicazione. In
particolare, ISO/OSI è costituito da strati, anche detti livelli o layer, ognuno dei quali
incapsula meccanismi fra loro correlati. I livelli sono sette e vanno dal livello fisico che
definisce le proprietà del cavo o delle onde radio, fino al livello delle applicazioni,
attraverso il quale si realizza la comunicazione di alto livello.
Figura 19: Livelli del modello ISO/OSI.
Protocolli ICS
51
Ogni livello individua un protocollo di comunicazione associato. ISO/OSI realizza
una comunicazione per livelli, cioè dati due nodi A e B, il livello n del nodo A può
scambiare informazioni col livello n del nodo B ma non con gli altri livelli. Ciò conferisce
modularità al sistema e semplicità d’implementazione. Inoltre, ogni livello implementa la
comunicazione con il livello corrispondente su altri nodi utilizzando il PoS (point of
service) del livello immediatamente sottostante. Il modello quindi incapsula i messaggi di
livello n in messaggi del livello n-1. Ad esempio, se A deve inviare una e-mail a B,
l'applicazione, a livello 7, di A propagherà il messaggio utilizzando il livello sottostante,
livello 6, che a sua volta userà il PoS del livello inferiore, fino ad arrivare alla vera e propria
comunicazione, ovvero trasmissione sul mezzo fisico, implementata a livello 1, per poi
risalire una volta raggiunto il destinatario.
I dati dal livello più alto sono incapsulati dai livelli inferiori che, a ogni passaggio,
aggiungono nuove informazioni (header), vedi Figura 20. In questo modo, si realizza una
comunicazione multilivello che consente di implementare algoritmi diversi per
l'instradamento di rete. Inoltre, conferisce maggiore semplicità di progettazione e gestione
della rete con la possibilità di migliorare, sviluppare, ed eventualmente sostituire, i
protocolli dei vari livelli.
Figura 20: ISO/OSI Incapsulamento.
Nella Tabella 3 sono descritte le funzioni principali dei sette livelli e i principali
protocolli utilizzati.
52
Capitolo 5
LIVELLO OBIETTIVO/FUNZIONI PROTOCOLLI
7 - Applicazione Interfacciare utente e macchina. Fornisce un insieme di
protocolli che operano a stretto contatto con le
applicazioni.
FTP (file transfer
protocol)
SMTP (simple mail
transport protocol)
SNMP (simple
network
management
protocol)
6 - Presentazione Trasformare i dati forniti dalle applicazioni in un
formato standardizzato e offrire servizi di
comunicazione, come crittografia, compressione del
testo.
HTTP, JPEG, MPEG
5 - Sessione Controllare la comunicazione tra applicazioni.
Instaurare, mantenere e chiudere connessioni
(sessioni) tra applicazioni. Si occupa anche della
sincronia d’invio/ricezione messaggi.
RPC (remote
procedure call)
NFS (network file
system)
4 - Trasporto Permettere un trasferimento di dati trasparente e
affidabile(implementando anche un controllo degli
errori e delle perdite) tra due host. È il primo livello
realmente end-to-end, cioè da host sorgente a
destinatario.
TCP (Transmission
Control Protocol)
UDP (User Datagram
Protocol)
3 – Rete Rende i livelli superiori indipendenti dai meccanismi e
dalle tecnologie di trasmissione usate per la
connessione. Si occupa di stabilire, mantenere e
terminare una connessione, garantendo il corretto e
ottimale funzionamento della sottorete di
comunicazione.
IP (Internet Protocol)
ICMP (Internet
Control Message
Protocol)
2 - Collegamento
dati
Permettere il trasferimento di dati attraverso il livello
fisico. Invia frame di dati con la necessaria
sincronizzazione ed effettua un controllo degli errori e
delle perdite di segnale. Consente di far apparire al
livello superiore, il mezzo fisico, come una linea di
trasmissione esente da errori di trasmissione.
ARP (Address
Resolution Protocol)
PPP (Point-to-Point
Protocol)
1 – Fisico Permette di trasmettere un flusso di dati attraverso un
collegamento fisico, occupandosi della forma e della
tensione del segnale. Ha a che fare con le procedure
meccaniche ed elettroniche necessarie a stabilire,
mantenere e disattivare un collegamento fisico.
EIA-422-B (RS-422)
EIA -232C (RS-232C)
Tabella 3 Descrizione dei sette livelli del modello ISO/OSI.
Protocolli ICS
53
Il modello TCP/IP
Il modello TCP/IP è stato sviluppato negli anni ’70 dalla Defense Advanced Research Project
Agency come insieme di protocolli di comunicazione per reti a commutazione di pacchetto.
I quattro livelli del TCP/IP sono mostrati nella Figura 21.
Figura 21: Livelli del modello TCP/IP.
La Tabella 4 descrive i livelli del modello TCP/IP e i principali protocolli utilizzati a
ogni livello della pila.
LIVELLO OBIETTIVO/FUNZIONI PROTOCOLLI
4 – Applicazione Rappresenta l'interfaccia con l'utente. DHCP, HTTP, HTTP
S, SMTP, POP3...
3 – Trasporto Assembla e fornisce i pacchetti di dati. TCP, UDP, SCTP, DC
CP ...
2 – Internet decide come trasferire il messaggio per
ogni singolo tratto del percorso.
IPv4, IPv6, ICMP, IC
MPv6, IGMP, IPsec,
OSPF ...
1 – Interfaccia di rete Trasmettere un flusso di dati non
strutturati attraverso un collegamento
fisico, occupandosi della forma e della
tensione del segnale..
Ethernet, WiFi, PPP,
WiMAX, HSDPA, MP
LS .
Tabella 4 Descrizione dei livelli TCP/IP.
54
Capitolo 5
5.3. Protocolli SCADA
I protocolli SCADA si sono evoluti da quelli che un tempo erano utilizzati da hardware e
software proprietari. Infatti, sono stati progettati e sviluppati nuovi protocolli per far
fronte alle necessità di mercato che prevedevano applicazioni specifiche per sistemi di
controllo in tempo reale. Sono stati creati protocolli SCADA per sfruttare le nuove
tecnologie di rete come ad esempio Internet e LAN. Questi cambiamenti hanno permesso
da un lato la creazione di standard per i sistemi SCADA, dall’altro hanno esposto questi
sistemi ai comuni attacchi tipici delle tecnologie informatiche più diffuse.
Nei paragrafi successivi, saranno descritti alcuni dei principali protocolli.
MODBUS
Nel 1979 Modicon ha sviluppato il protocollo MODBUS (11) (12) (13) che si colloca a
livello sette del modello OSI e supporta comunicazioni Client-Server attraverso Modicon
PLC e altri dispositivi di rete. Il protocollo MODBUS definisce i metodi di un PLC per
ottenere l’accesso a un altro PLC, per permettere a un PLC di rispondere ad altri
dispositivi, e per rilevare e comunicare eventuali errori. Inoltre, MODBUS supporta altri
protocolli per trasmissioni asincrone tra master e slave, come Modicon MODBUS Plus, ed
Ethernet.
Per sfruttare le tecnologie internet, è stato anche implementato MODBUS TCP/IP.
Anche questo si basa sul modello OSI, sebbene non utilizzi tutti i sette livelli definiti dallo
standard. La Figura 22 mostra i livelli di comunicazione implementati nel protocollo
MODBUS.
Un esempio di comunicazione tipica che si esegue attraverso il protocollo MODBUS è
sintetizzata come segue:
1. Il protocollo imposta il formato per l’inizio della comunicazione con il client; 2. Un codice nella sezione dati indica quale azione deve eseguire il server; 3. Un campo dati nel messaggio inviato, fornisce altre informazioni utilizzate
dal server per eseguire correttamente l’azione richiesta; a. Se non ci sono errori nello scambio di messaggi, il server completa la
richiesta inviando al client i dati elaborati;
b. Se ci sono errori, il server legge il codice dell’errore dall’unità dati del
messaggio ricevuto e determina l’azione da effettuare.
Protocolli ICS
55
Figura 22: Livelli di comunicazione MODBUS.
DNP3
DNP3 (14) è un protocollo SCADA open, usato dai dispositivi di controllo per
comunicazioni seriali e IP. È ampiamente utilizzato soprattutto per lo scambio di dati e
istruzioni di controllo tra le stazioni di controllo master e i computer o controllori remoti,
anche chiamati out-station (stazioni esterne).
Alcuni dei comandi tipici inviati dal master sono, ad esempio, “apri valvola”, “accendi
motore”, “fornisci dati a una particolare stazione di controllo”. Le stazioni esterne
forniscono quindi alle stazioni di controllo master, informazioni come pressione,
temperature, potenza e così via.
Il protocollo DNP3 permette anche l’utilizzo di TCP/IP per lo scambio di messaggi.
La Figura 23 mostra l’architettura a livelli DNP3 TCP/IP utilizzata per lo scambio di dati
tra le stazioni di controllo e le stazioni esterne.
56
Capitolo 5
Figura 23: Scambio dati DNP3 TCP/IP.
La Figura 24 mostra come è organizzato il frame DNP3 (header e sezione dati).
Figura 24: Struttura frame DNP3 (15).
L’header è composto di due byte di sincronizzazione che permettono al destinatario
di determinare dove comincia il frame; un byte lunghezza indica il numero di byte
rimanenti nel frame; un byte link control è utilizzato dalle due entità per sincronizzare le
attività; indirizzo destinazione e indirizzo sorgente; e due byte per il controllo d’integrità
Protocolli ICS
57
CRC (Cyclic Redundancy Check). La sezione dati (payload), contiene i dati che devono
essere passati tra i vari livelli della pila.
PROFIBUS
Profibus (Process Fieldbus) (16) (17) è uno standard open per reti di bus di campo, che
definisce caratteristiche meccaniche, elettriche e funzionali del bus. Lo standard è
utilizzato in applicazioni, dove l’acquisizione dati e il tempo di trasmissione e ricezione
sono fattori critici. (14)
Poiché il protocollo è open, può essere utilizzato e adattato su dispositivi di diversi
costruttori. Nel modello OSI, ha portato cambiamenti nei livelli applicazione, data link e
fisico. Due delle caratteristiche principali di questo protocollo sono il determinismo per
applicazioni di controllo real-time e le comunicazioni multi-master e master-slave.
Sono disponibili tre versioni di Profibus:
Profibus Process Automation (PA): collega acquisizione dati e dispositivi di
controllo su bus seriale e supporta implementazioni intrinsecamente sicure e
affidabili. Inoltre, fornisce energia ai dispositivi di campo, attraverso il bus.
Profibus Factory Automation (Decentralized Peripheral – DP): fornisce
comunicazioni ad alta velocità tra i sistemi di controllo e i dispositivi
decentralizzati. A differenza di Profibus PA, utilizza specifiche diverse a
livello fisico del modello OSI. Esiste anche un’estensione di questo standard,
Profibus-DPV1, che include diagnostica, messaggi d’allarme e
parametrizzazione.
Profibus Fieldbus Message Specification (FMS): sviluppato per supportare
un grande numero di applicazioni e interconnessioni ad alto livello per
applicazioni a medio raggio di trasmissione. Anche se offre più funzionalità, è
più complesso da implementare rispetto a Profibus DP e Profibus PA.
La Figura 25 mostra le architetture di comunicazione e le relazioni tra i sette livelli
del modello ISO/OSI per le versioni Profibus.
58
Capitolo 5
Figura 25: Livelli e protocolli Profibus FMS, DP e PA.
In questo capitolo descriviamo gli Intrusion Detection System (IDS), analizzando come
operano e quali tecniche utilizzano per rilevare possibili attacchi.
Gli IDS rilevano attacchi contro un dato insieme di asset14. Quest’analisi può
considerare il singolo PC oppure essere estesa all’intera rete aziendale. A differenza degli
IDS gli IPS (Intrusion Prevention System) oltre a rilevare, possono anche bloccare attività
non permesse. In entrambi i sistemi, gli attacchi sono rilevati controllando un insieme
predefinito di comportamenti (comunicazioni, payload, ecc.) che non dovrebbero essere
presenti durante il normale funzionamento del sistema. Gli IDS possono essere considerati
strumenti flessibili poiché permettono di aggiornare in qualsiasi momento, i criteri
utilizzati per rilevare possibili attacchi e minacce. Questo comportamento è simile a quello
degli antivirus, che permettono di aggiornare il loro database in modo da poter rilevare
nuove minacce, senza dover aggiornare il “cuore” del software, ossia l’engine che esegue le
scansioni.
Gli IDS possono essere divisi in due categorie: host-based (HIDS) e network-based
(NIDS). Nelle soluzioni host-based, l’IDS è installato direttamente nell’host da controllare,
mentre i network-based lavorano come sistemi indipendenti e controllano le
comunicazioni di rete, tipicamente nei punti d’ingresso e di uscita delle reti e in
congiunzione con i firewall.
Sia NIDS che HIDS, utilizzano due principali tecniche utilizzate per la rilevazione di
attacchi: signature detection (firme) e anomaly detection (anomalie).
Gli IDS basati su firme, lavorano analizzando i pacchetti e confrontano le attività
rilevate con pattern di attacchi conosciuti, memorizzati in un database. Poiché questo tipo
di IDS genera gli allarmi utilizzando pattern ben definiti, può fornire specifiche
informazioni sul tipo di attacco rilevato, producendo quindi, meno falsi positivi rispetto
agli IDS basati su anomalie. Questi IDS non sono in grado di rilevare nuovi tipi di attacchi,
perché non sono memorizzati nel database di riferimento. Il database deve quindi essere
costantemente aggiornato con i pattern dei nuovi attacchi. Inoltre, considerando i sistemi
14 Si definisce con il termine asset tutto ciò che ha valore per l’organizzazione e che pertanto
ha bisogno di protezione.
6
Intrusion detection system
60
Capitolo 6
SCADA, le firme degli attacchi hanno differenti caratteristiche rispetto alle firme più
comuni utilizzate nei sistemi IT. In particolare, le firme devono essere in grado di
analizzare protocolli SCADA come Foundation Fieldbus, Modbus, Profinet, ControlNet e
cosi via. Le caratteristiche principali delle firme sono indirizzi IP, parametri trasmessi e
protocolli.
Gli IDS basati su anomalie considerano un campione staticamente della rete, in
modo da costruire un profilo delle normali attività del sistema. Quando il comportamento
del sottosistema devia, è rilevato un possibile attacco. Le caratteristiche considerate da
queste tecniche includono ad esempio, la percentuale di utilizzo della CPU, il numero di
login falliti, la quantità di traffico nella rete. Questi IDS sono in grado di rilevare nuovi
attacchi ma possono essere facilmente elusi da attacchi che non cambiano in maniera
rilevante il comportamento del sistema e i parametri misurati.
Gli IDS basati su anomalie, possono facilmente generare falsi allarmi se attività
legittime causano cambiamenti dei parametri analizzati. Ovviamente, il fattore chiave di
queste tipologie di IDS è la qualità della linea base utilizzata per definire il comportamento
normale.
Gli IDS basati su firme, possono implementare differenti politiche:
Default Deny: sono definite tutte e solo le comunicazioni permesse. Se una comunicazione rilevata non rispetta le regole, è un possibile attacco.
Default Allow: sono definite tutte e solo le comunicazioni non permesse, tutto il resto è consentito. Se una comunicazione rilevata rispetta una regola, allora è una comunicazione non permessa.
Gli attuali IDS non hanno conoscenza e intelligenza per gestire applicazioni e
protocolli SCADA. Mentre gli attacchi contro i sistemi più comuni sono rilevati abbastanza
facilmente, attacchi contro applicazioni e protocolli SCADA, come ad esempio a un server
di controllo SCADA che usa protocollo Modbus, non sono neppure considerati. Per questo
motivo, l’utilizzo di IDS in sistemi SCADA prevede dei controlli che proteggano la rete
aziendale. Questo permette di proteggersi da attacchi provenienti da Internet, offrendo
quindi una certa protezione anche alla rete SCADA collegata.
7.1. IDS e correlazione nei sistemi ICS
L’adozione di Intrusion Detection System (IDS) in reti ICS (Industrial Control System) offre
un vantaggio rispetto ai classici ambienti corporate perché le reti ICS sono
prevalentemente statiche, sia per quanto riguarda la topologia, sia per i protocolli e i
processi. I sistemi che comprendono queste reti, come server SCADA, PLC, DCS, dispositivi
di campo sono raramente aggiornati dopo che l’intero processo di produzione è stato
avviato. Inoltre, tutte le parti lavorano per uno stesso scopo: eseguire le operazioni dettate
dal software ICS.
Data la particolare staticità di questa tipologia di sistemi, è semplice analizzare il
traffico per scoprire comportamenti anomali, poiché è possibile definire a priori i flussi di
comunicazioni autorizzati, il loro contenuto, le entità che possono comunicare, i protocolli
permessi e chi può iniziare una comunicazione.
In Figura 26 è riportato un esempio di rete SCADA. L’architettura comprende tre
sottoreti: una di controllo e due di processo. Tutti i dispositivi della stessa sottorete
possono comunicare, come mostrato nei collegamenti di colore nero. Sono invece
evidenziati in rosso i collegamenti vietati dalle politiche di sicurezza.
Un controllo sulle comunicazioni permette di definire il primo insieme di regole da
inserire nell’IDS che segnalerà un’anomalia nel momento in cui rileverà una
comunicazione non autorizzata. Il server di controllo può comunicare solo con lo storico
dati e la stazione HMI. La stazione HMI può comunicare con tutti tranne che con lo storico
dati.
La Tabella 5 sintetizza le regole di comunicazione che saranno definite nell’IDS. In
questo caso, il verso della comunicazione è da intendersi bidirezionale.
7
Correlazione
62
Capitolo 7
Figura 26: Architettura SCADA v1.
SORGENTE DESTINAZIONE AZIONE
HMI Server Controllo Allow
HMI Workstation Allow
Server di Controllo Storico dati Allow
Server di Controllo PLC1, PLC2 Allow
Workstation Stampante Allow
Any Any Deny
Tabella 5: Flusso delle comunicazioni descritte in Figura 26.
Un IDS basato sui flussi è in grado di riconoscere diversi comportamenti anomali,
come ad esempio tentativi di scansione della rete. Ciò è possibile, anche se si utilizzano
tecniche di evasione come offuscamento15 oppure slow scanning16. Infatti, uno scan di rete
cerca di enumerare tutti gli host e i servizi in esecuzione generando del traffico non
permesso dalle specifiche dei flussi. Quando l’IDS rileva comunicazioni di questo tipo,
genera degli alert.
15 Metodo di evasione con il quale si codifica il payload in modo da renderlo incomprensibile
all’IDS o impedendogli di effettuare string e pattern matching. 16 Metodo di evasione nel quale lo scan viene effettuato in un arco di tempo molto ampio,
come settimane o anche mesi.
Correlazione
63
Un altro esempio è mostrato in
Figura 27. In questo caso, la stazione HMI e le workstation sono connesse
direttamente ai PLC. Anche se i sistemi sono connessi sullo stesso segmento di rete, la
politica di sicurezza permette solo alla HMI di comunicare con i PLC. L’IDS dovrà quindi
controllare che le workstation e i PLC non comunichino.
Figura 27: Architettura SCADA v2.
Le regole dell’IDS possono essere create sia in maniera statica, analizzando gli host e
i servizi presenti, sia in maniera dinamica, monitorando il corretto funzionamento del
sistema per un determinato periodo e memorizzando le comunicazioni in una situazione
che è per ipotesi normale o a regime.
Queste metodologie di analisi, sono tipiche della categoria degli IDS basati su
anomalie, anche chiamati Anomaly-Based. Questa categoria di IDS utilizza una conoscenza
di base della rete e delle comunicazioni per determinare attività anomale.
Le strategie viste fino a questo punto cercano di identificare connessioni anomale,
attraverso l’analisi del flusso e dei pacchetti malformati (deep packet inspection). Tuttavia,
non sono in grado di identificare attacchi di tipo men-in-the-middle (MITM) causati da
entità compromesse, com’è avvenuto in sistemi attaccati da Stuxnet e Duqu.
Gli attuali IDS, non permettono di definire se un comando sintatticamente corretto
sia dannoso per lo stato del sistema. Considerando l’esempio in
Figura 27, se un attaccante riesce a compromettere il server di controllo, può inviare
comandi malevoli a RTU e PLC. Questi comandi possono essere sintatticamente corretti,
64
Capitolo 7
poiché le informazioni trasmesse sono valide e rispettano i protocolli e le politiche, ma
non sono corretti se si considera la semantica del comando nello stato in cui si trova il
sistema. Ad esempio, s’invia un comando di chiusura a una valvola, quando questa è già
chiusa. Fino a quando il comando è sintatticamente corretto e permesso
dall’implementazione, l’IDS non segnalerà alcuna anomalia, poiché non esiste nessuna
regola che vieta l’invio del comando. Tuttavia, l’IDS non valuterà se il comando è
semanticamente valido nello stato del sistema in cui è eseguito.
È possibile affrontare problemi di questo tipo, come gli attacchi MITM, correlando
informazioni provenienti da più sensori. Ogni sensore sarà sistemato in diversi segmenti
di rete per costruire in tempo reale, un database d’informazioni condivise, come ad
esempio set point, comandi, indirizzi e altro, per ogni flusso di dati effettuato nelle varie
reti. Correlando le informazioni provenienti dai diversi sensori, è possibile individuare le
inconsistenze logiche che un attacco crea quando ha successo.
Come accennato in precedenza, il traffico nei sistemi ICS ha una struttura statica. Le
informazioni trasmesse dalle comunicazioni di questi sistemi sono principalmente: set-
point, ossia valori di soglia dei dispositivi, dati provenienti da host remoti come i valori
inviati dalle stazioni ingegneristiche e HMI, e comandi e dati inviati da e per i controllori
(PLC/RTU).
Considerando l’architettura di rete in Figura 26, il flusso normale delle
comunicazioni può essere così descritto. I dati sono recuperati dai dispositivi di campo,
tramite i PLC che li convertono e ritrasmettono al server SCADA. A questo punto i dati
sono disponibili nella rete aziendale e sono quindi accessibili ai dispositivi client come lo
storico dati, console degli operatori (HMI) e altri dispositivi. Allo stesso modo, con un
processo inverso, sono elaborati i comandi degli operatori. Il comando parte dalla console
degli operatori, passa prima dal server SCADA il quale lo ritrasmette al PLC/RTU remoto,
che esegue il comando sul rispettivo dispositivo di campo. Inoltre, un server SCADA può
inviare comandi ai dispositivi remoti PLC e RTU in base alle configurazioni e alla logica
interna del server, evitando l’intervento dell’operatore mediante la console
corrispondente.
Una proprietà di queste architetture è che comandi e dati esistono in tempi
relativamente vicini in diverse parti del sistema. Nel caso più semplice, i dati viaggiano
dagli slave ai PLC/RTU, poi verso il server SCADA, e ancora verso le console degli
operatori o lo storico dati. È facile capire come più copie degli stessi dati esistono nel
sistema in un periodo breve. Ciò permette di implementare controlli di consistenza e
congruenza sui dati.
Analizzando il traffico nei vari segmenti di rete, memorizzando comandi e dati in un
database centralizzato, è possibile correlare le informazioni raccolte per individuare delle
inconsistenze causate da un possibile attacco. Allo stesso modo, è possibile controllare che
stazioni non autorizzate inviino comandi non permessi. Un possibile esempio di
quest’ultimo comportamento, si ha quando un dispositivo PLC o RTU può inviare comandi
di configurazione solo se ordinato dalla console dell’operatore. In questo caso, a causa del
flusso di dati inviati dalla console di gestione ai dispositivi di campo, si avranno più copie
Correlazione
65
del comando nel database d’informazioni condiviso. Se un attaccante riesce a
compromettere un PLC, può inviare comandi ai dispositivi di campo, ignorando i comandi
ricevuti dalle stazioni di controllo. Inoltre, può modificare le informazioni da restituire ai
server SCADA in modo da coprire le proprie tracce, rimanendo invisibile ai sistemi di
protezione.
La Figura 28 e la Figura 29 mostrano alcuni esempi di flussi non corretti dovuti ad
apparecchiature compromesse.
Nell’esempio in Figura 28, un server SCADA compromesso invia un comando al PLC1
per aprire la valvola1. Il PLC, fidandosi del server e dei comandi ricevuti, apre la valvola.
Compiuta l’operazione di apertura, il PLC, invia al server SCADA lo stato dell’operazione: la
valvola1 è stata aperta. A questo punto, l’attaccante può scartare o modificare il messaggio
ricevuto e inviare alla HMI un messaggio che indica lo stato della valvola1 come chiusa. La
comunicazione tra il PLC e la valvola1 è ‘corretta’ poiché i comandi sono eseguiti in modo
corretto sia dal PLC sia dalla valvola. Tuttavia, analizzando l’esempio, è possibile
individuare due inconsistenze. La prima riguarda il server SCADA che invia un comando al
PLC1 senza un corrispondente comando da parte della HMI. In questo caso si suppone che
il server SCADA possa inviare qualsiasi comando solo quando la HMI lo ordina. La seconda
inconsistenza sorge quando l’attaccante modifica la risposta del PLC, inviando falsi dati
alla HMI. Un IDS che utilizza un database d’informazioni in tempo reale, è in grado di
rilevare questo tipo d’inconsistenze e generare eventuali messaggi di allarme.
Nella Figura 28 le frecce blu indicano le comunicazioni corrette, mentre in rosso
quelle compromesse.
Figura 28: MITM es. 1.
Come nell’esempio precedente, un attaccante che controlla qualsiasi dispositivo
all’interno della rete, nell’esempio in Figura 29 è il caso di un server SCADA, potrebbe
filtrare i comandi in entrata e in uscita oppure scartare i comandi che possono interferire
con l’attacco che sta svolgendo. In questo esempio, un attaccante che ha il controllo del
server SCADA elimina il comando di apertura della valvola1 inviato dalla HMI e diretto al
PLC1. Poiché il PLC1 non riceve un comando, non modificherà lo stato della valvola che
rimarrà chiusa. A questo punto, per rendere l’attacco meno visibile, l’attaccante modifica il
messaggio di risposta alla stazione di controllo rispondendo che l’operazione è andata a
buon fine e che la valvola1 è stata aperta.
66
Capitolo 7
Figura 29: MITM es. 2.
Analizzando l’esempio in Figura 29, è possibile individuare due inconsistenze. La
prima riguarda il comportamento scorretto del server SCADA a seguito del comando
inviato dalla HMI. La seconda inconsistenza si verifica quando il PLC1 risponde indicando
lo stato della valvola1 come chiusa, e il server SCADA comunica che la valvola1 è aperta.
Queste due inconsistenze possono essere facilmente rilevate utilizzando un database
condiviso d’informazioni sui flussi di comunicazioni rilevati.
Individuare questa tipologia di attacchi non è sempre semplice. Nei casi visti in
precedenza, il server SCADA potrebbe essere un dispositivo intelligente che ha la
possibilità di inviare comandi in maniera del tutto indipendente. Inoltre, potrebbe essere
configurato in modo da non eseguire comandi che potrebbero portare il sistema in
condizioni non sicure. In alcuni casi, l’IDS dovrà rilevare inconsistenze sui valori (point-
data) e non sui comandi inviati.
7.2. Proprietà del correlatore
La correlazione consiste nello stabilire un rapporto tra due o più entità. Come discusso in
(18) e descritto nel seguito, esistono differenti proprietà che un correlatore deve offrire.
Consapevolezza del dominio
Un correlatore può essere costruito per un dominio specifico o generico. Nel primo caso il
correlatore conosce la tipologia d’informazioni da elaborare e ciò permette al correlatore
di fornire operazioni e strutture dati specifiche per il dominio di riferimento. Nel caso dei
sistemi ICS, il correlatore deve permettere di analizzare in maniera più efficiente le
informazioni degli strumenti di campo, come valori e set point, ma anche analizzare e
gestire comportamenti e flussi di comunicazione dovute alle differenti configurazioni degli
ambienti.
Auto apprendimento e conoscenza esterna
Per correlare gli eventi provenienti dall’esterno, un correlatore ha bisogno di conoscere la
struttura della rete, gli eventi rilevati, i servizi, le dipendenze tra flussi e cosi via.
Correlazione
67
Queste informazioni possono essere ottenute in modo automatico oppure possono
essere inserite manualmente. La seconda soluzione richiede un lavoro più complesso da
parte degli operatori. Tuttavia, questa soluzione è più economica se la maggior parte della
conoscenza da inserire è statica, come nel caso di sistemi ICS. Se, invece, il sistema è
dinamico, un correlatore che raccoglie informazioni automaticamente è più adeguato. In
alcuni casi, l’apprendimento automatico non solo è più complesso, ma può anche produrre
informazioni non corrette che possono portare a una correlazione completamente errata.
Un buon compromesso consiste nell’ottenere una prima parte d’informazioni
automaticamente e poi raffinare manualmente le informazioni rilevate.
Real-time e Dati memorizzati
La correlazione può essere implementata sia in tempo reale, analizzando gli eventi nel
momento stesso in cui sono rilevati, sia in modo offline, utilizzando dati memorizzati in
precedenza. Se la correlazione offline è più utile quando si vogliono eseguire operazioni su
grandi quantità di dati, quella real-time è utile in ambienti dove la criticità del sistema è
elevata e si vuole minimizzare il tempo di rilevazione delle anomalie.
Stateless e stateful
Un correlatore real-time che memorizza la storia degli eventi ricevuti è chiamato stateful,
mentre un correlatore che non memorizza nessun evento è chiamato stateless.
I correlatori completamente stateless sono molto limitati, poiché gli eventi rilevati
non possono essere relazionati con gli altri. Quello che si ottiene con correlatori di questo
tipo sono semplici operazioni di filtraggio secondo un insieme di regole predefinite. In
questo caso è anche discutibile che si possa parlare di correlazione. In base alla capacità di
memorizzazione ed alla quantità di eventi rilevati, i correlatori stateful permettono di
elaborare sia grandi sia piccole quantità di eventi.
Centralizzati e distribuiti
Gli eventi sono solitamente generati da risorse distribuite. Questo permette di eseguire le
operazioni di correlazione in maniera distribuita, come mostrato in Figura 30 dove, più
correlatori gestiscono gli eventi provenienti da differenti entità. I vantaggi di questa
implementazione sono: migliori prestazioni, maggiore scalabilità e facilità di accesso a
informazioni supplementari dalla risorsa.
68
Capitolo 7
Figura 30: Correlazione distribuita.
Tuttavia, si ha una correlazione più completa analizzando in modo centralizzato gli
eventi rilevati da ogni singola entità, come mostrato in Figura 31.
Figura 31: Correlazione centralizzata
Come mostrato in Figura 32, un compromesso tra le due implementazioni è quello di
un sistema, dove gli eventi sono inizialmente elaborati in prossimità della risorsa da
analizzare ed in seguito correlati in maniera centralizzata.
Figura 32: Correlazione ibrida.
Correlazione
69
Perdita d’informazioni
Un’operazione di correlazione è senza perdita d’informazioni (lossless), se il processo di
analisi non ignora nessun evento o informazione. Di conseguenza, un correlatore è lossless
se lo sono anche tutte le operazioni effettuate. Tuttavia può essere utile filtrare alcuni
eventi, e quindi rinunciare ad alcune informazioni.
Un buon compromesso si ottiene rendendo disponibili tutte le informazioni ed
eseguendo le operazioni di correlazione solo su una parte di queste. Informazioni
dettagliate dell’evento devono essere minimizzate durante le operazioni di correlazione,
ma devono essere sempre disponibili. In questo modo, è possibile eseguire analisi più
accurate nel momento in cui esse siano necessarie.
La staticità dei sistemi ICS permette di descrivere a priori i comportamenti del sistema da
controllare. Grazie a questa caratteristica è quindi possibile correlare gli eventi rilevati e
verificare che essi rispettino i comportamenti descritti. Il processo d’identificazione
d’intrusioni e di correlazione di eventi può essere decomposto in tre fasi:
Una prima fase descrive i comportamenti e le comunicazioni del sistema attraverso automi a stati finiti.
In seguito, s’identificano le comunicazioni del sistema. Quest’analisi permette di classificare le comunicazioni in eventi vietati ed eventi permessi.
La terza fase correla gli eventi permessi ed identifica le anomalie nel sistema. Questo richiede di correlare gli eventi confrontandoli con i comportamenti descritti nella prima fase.
Questo capitolo descrive la metodologia sviluppata che permetterà di eseguire le
operazioni di correlazioni.
8.1 Classificazione degli eventi
Oltre ai sensori IDS installati in ogni segmento di rete, è fondamentale la presenza di uno o
più dispositivi di correlazione, ai quali confluiranno tutti o parte degli eventi rilevati dagli
IDS. I correlatori devono quindi raccogliere questi eventi e verificare che essi non violino il
comportamento atteso.
8
Implementazione del sistema di
correlazione
72
Capitolo 8
Non tutti gli eventi dovranno essere elaborati dai correlatori. Il traffico rilevato dai
sensori dovrà essere quindi classificato a seconda se deve essere elaborato dal correlatore
o meno. Le due categorie di classificazione di eventi sono quindi:
Eventi Alert. Sono eventi rilevati a seguito di un comportamento anomalo, che non rispetta le specifiche del sistema (regole simili a quelle dei classici IDS).
o Es: due entità che comunicano nonostante le policy lo vietano.
Eventi da correlare. Sono eventi sui quali è necessario eseguire delle operazioni di correlazione.
Eventi alert
Questa categoria comprende tutti gli eventi rilevati da regole specifiche che vietano
determinati tipi di comunicazioni.
Consideriamo una rete con tre entità distinte e definiamo in maniera informale, le
regole della classe “Eventi Alert”:
- A <> B (l’entità A può comunicare con B e vice versa);
- B <> C (l’entità B può comunicare con C e vice versa);
- A <!> C (l’entità A non può comunicare con C e vice versa).
Figura 33: Comunicazioni rete locale.
In questo esempio, quando il sensore rileva del traffico tra A e C identifica la
comunicazione come “comunicazione non permessa” e genera un alert. Tutti gli alert in
questa categoria non saranno inviati al correlatore.
Implementazione del sistema di correlazione
73
Categoria Eventi Alert in SNORT
Di seguito è illustrato il codice utilizzato in Snort17, che permette di creare una nuova
categoria di nome Eventi Alert.
ruletype eventi_alert
{
type alert
output alert_fast: stdout
}
Codice 1: Classe eventi_alert
Aggiungendo questo codice nel file di configurazione di Snort, si definisce una classe
di nome eventi_alert. Quando l’IDS rileva del traffico che corrisponde a una delle regole
definite con classe eventi_alert, genera un alert direttamente a schermo.
### Scrittura 'Holding register' da indirizzo non autorizzato ###
eventi_alert tcp !192.168.2.1 any -> 192.168.2.61 502
(msg:"USER RULE - Modbus: Scrittura 'Holding register' da indirizzo
non autorizzato"; flow:established,to_server; content:"|06|";
depth:1; offset:7; classtype:protocol-command-decode; sid:1000107;
rev:1;)
Codice 2: Regola snort con classe eventi_alert
Il primo parametro della regola è il nome della classe. Tutto il traffico rilevato dalla
regola precedente, sarà elaborato in base alle specifiche della classe selezionata
(eventi_alert). In questo caso il messaggio sarà mostrato a video.
Eventi da correlare
Questa categoria comprende tutto il traffico permesso sul quale si vogliono eseguire delle
operazioni di correlazione. La Figura 34 mostra una possibile configurazione di rete:
17 Snort: Network Intrusion Prevention e Detection System (IPS/IDS) open source sviluppato
da Sourcefire.
74
Capitolo 8
Figura 34: Correlatore sistemi ICS.
Supponiamo di avere due reti separate fisicamente. La prima comprende tutti i
dispositivi della rete di controllo, la seconda corrisponde al campo18. Le reti sono collegate
da un dispositivo nella rete SCADA che comunica con il PLC, il quale a sua volta
comunicherà direttamente con il campo. L’analisi del traffico delle due sottoreti richiede
due sensori. Questi sono indicati in Figura 34 con Sensore1 per la rete SCADA, e Sensore2
per la rete CAMPO.
Dopo aver classificato un evento come “evento da correlare”, il sensore lo invia al
correlatore associato. Il correlatore riceve gli eventi e, in base alla propria configurazione,
controlla la correttezza delle informazioni trasmesse e i flussi delle comunicazioni. Lo
stesso evento può essere inviato gerarchicamente fino all’ultimo correlatore presente nel
sistema.
Supponiamo che nel Sensore1 esista una regola che individua il comando “Apri
Valvola” inviato da un dispositivo della rete SCADA al PLC, e allo stesso modo esista una
regola nel Sensore2, che individua il comando ritrasmesso dal PLC al dispositivo di campo.
Quando il Sensore1 rileverà il comando di apertura valvola, genererà l’evento
associato e lo invierà al Correlatore SCADA, il quale lo inoltrerà al Correlatore ICS e in
seguito inizierà le operazioni di correlazione. In questo modo, tutte le componenti
interessate allo specifico evento hanno le informazioni per eseguire le operazioni di
correlazione.
Allo stesso modo, quando il Sensore2 rileverà il comando inviato dal PLC al campo,
invierà l’evento al Correlatore Campo il quale lo invierà al Correlatore ICS. In questo caso,
mentre il Correlatore SCADA e il Correlatore Campo conoscono gli eventi della propria
sottorete, il Correlatore ICS conoscerà le comunicazioni di entrambe le sottoreti e potrà
procedere con la fase di correlazione, per verificare la correttezza del traffico.
Un’analisi degli eventi basata su questo tipo di approccio è in grado di rilevare
facilmente attacchi di tipo Man in the Middle (MitM).
18 Nei sistemi di automazione e controllo industriale il termine campo è un’espressione
generica che descrive l’insieme dei sistemi a basso livello, quali sensori, trasmettitori, attuatori ecc.
Implementazione del sistema di correlazione
75
A questo punto, siamo in grado di descrivere due tipologie di eventi: quelli sempre
vietati e quelli da correlare. Oltre a questi eventi, esiste una terza classe, quella degli eventi
sconosciuti. Data la criticità dei sistemi ICS, la polita adottata per gestire eventi di questo
tipo sarà di tipo default deny, e quindi, tutto il traffico non specificato nelle regole delle
classi Eventi Alert ed Eventi da correlare è identificato come non permesso.
8.2 Automi a stati finiti
Nel corso degli ultimi anni sono state sviluppate diverse implementazioni di IDS e
differenti modelli di correlazione basati sull’utilizzo di automi a stati finiti (Finite state
machine). La maggior parte di questi lavori ha però l’obiettivo di migliorare la qualità degli
IDS, riducendo i falsi positivi e i falsi negativi. Nel presente lavoro di tesi, la necessità di
descrivere i comportamenti del sistema da analizzare, ha portato allo sviluppo di modelli
basati su automi a stati finiti. Questi modelli hanno come obiettivo, quello di descrivere i
flussi di comunicazione che esistono tra le entità del sistema da analizzare.
Un automa a stati finiti è un sistema dinamico, invariante e discreto
nell'avanzamento e nelle interazioni, per il quale gli insiemi dei possibili valori di ingresso,
uscita e stato sono insiemi finiti. Dinamico significa che il sistema evolve nel tempo
passando da uno stato all'altro in funzione dei segnali d'ingresso e dello stato precedente,
invariante perché a parità di condizioni iniziali il comportamento del sistema è sempre lo
stesso, e discreto poiché le variabili d'ingresso, di stato, d'uscita, possono assumere solo
valori discreti.
L'automa a stati finiti è un modello di calcolo semplice rappresentabile come un
dispositivo che mediante una testina legge una stringa d’input su un nastro e la elabora,
facendo uso di un meccanismo molto semplice di calcolo e di una memoria limitata.
L'esame della stringa avviene un carattere alla volta attraverso precisi passi
computazionali che comportano l'avanzamento della testina. In sostanza un ASF è un caso
particolare di macchina di Turing, utilizzato per l'elaborazione di quei linguaggi che
nelle Grammatiche di Chomsky sono definiti di Tipo 3 o Regolari. Distinguiamo due tipi di
automi a stati finiti: quelli deterministici (ASFD) e quelli non deterministici (ASFND).
Un ASF deterministico si definisce come un sistema , dove
insieme finito dei possibili simboli in ingresso
insieme finito dei possibili simboli in uscita
insieme finito degli stati
funzione di transizione degli stati interni successivi, che collega lo
stato nell'istante successivo al valore attuale dell'ingresso e dello
stato,
76
Capitolo 8
funzione delle uscite, che collega l'uscita al valore attuale
dell'ingresso e dello stato, .
Il prossimo esempio illustra il comportamento di un automa che accetta tutte e sole
le stringhe che finiscono in 01.
Il diagramma di stato è cosi definito:
Figura 35: Diagramma di stati con stringhe che finiscono in 01.
La Figura 36 illustra come l’automa elabora l’input 00101.
Figura 36: Esempio di transizioni.
In Figura 36 si può notare come ogni qual volta l’automa è nello stato S1 e riceve in
input 0, termina in uno stato chiamato stuck. Lo stesso comportamento si ha quando da
uno stato S2 l’automa riceve l’input 0. Lo stato stuck indica che l’automa non può muoversi
in uno stato successivo.
Come vedremo nel seguito, la possibilità di utilizzare automi per descrivere i
comportamenti del sistema permette di rilevare anomalie e comportamenti errati.
8.3 Descrizione di automi per la correlazione
Grazie alle caratteristiche degli ASF è possibile descrivere i flussi (automa e stati) di eventi
(transizioni) che il correlatore deve ricevere al verificarsi di un determinato evento.
Secondo gli automi implementati e dello stato attuale del sistema, i correlatori conoscono
a priori tutti i possibili comportamenti del sistema. Gli eventi da correlare possono essere
Implementazione del sistema di correlazione
77
interpretati in maniera differente a seconda dello stato attuale del sistema. In particolare
possono essere divisi in:
Eventi iniziali: Come descritto nel paragrafo 8.2, ogni automa ha uno stato iniziale. Gli stati iniziali costituiscono l’insieme di eventi iniziali, i quali, quando ricevuti dal correlatore, causano l’avvio dell’automa associato.
Eventi transizione: questi eventi sono utilizzati per effettuare la transizione di stato in uno degli automi attivi nel correlatore.
Eventi finali: questi eventi causano la terminazione con successo dell’automa associato.
Supponiamo di avere il seguente scenario:
Figura 37: Comando apertura valvola.
Una componente del sistema SCADA (HMI) invia il comando Apri V1 al PLC 1.
Ricevuto il comando, il PLC esegue le dovute operazioni e invia il rispettivo comando nella
rete CAMPO, ordinando alla valvola 1 di aprirsi. Queste due operazioni possono avvenire
anche con protocolli differenti. La valvola 1, dopo aver terminato l’operazione di apertura,
invia il suo stato (V1 Aperta) al PLC, il quale a sua volta lo inoltra all’HMI. Al termine del
processo, l’HMI è a conoscenza dello stato della valvola: Aperta.
Le comunicazioni nell’esempio precedente sono tutte corrette, e il comando Apri V1
è eseguito con successo. I due sensori (sensore 1 e sensore 2) intercettano sia i comandi di
apertura, sia i risultati dell’operazione: un comando e una risposta per sensore. Le
comunicazioni sono intercettate e classificate come Eventi da correlare grazie ad un
insieme di regole presenti in ogni sensore. Ogni qual volta un pacchetto corrisponde ad
una di queste regole, un evento contenente le relative informazioni sulla comunicazione
viene generato ed inviato al rispettivo correlatore.
78
Capitolo 8
Un esempio di regola Snort che permette di intercettare il comando di apertura di un
dispositivo remoto, con protocollo MODBUS, è il seguente:
eventi_da_correlare tcp 192.168.2.1 any -> 192.168.2.61 502 (msg:"Write Register: Open "; sid:1000301; content:"|06|"; depth:1; offset:7; content:"|01|"; depth:1; offset:6; sid:1000103;)
Codice 3: Regola snort - apertura valvola
Quando la regola descritta in Codice 3 è attivata, il sensore genera ed invia un evento
al correlatore. Il correlatore, configurato con un insieme di automi che descrivono il
comportamento atteso della rete da monitorare, riceve l’evento e controlla se nello stato
attuale del sistema, l’evento ricevuto è corretto o meno. Questo avviene analizzando gli
stati attuali e le transizioni degli automi presenti nel correlatore. Le restanti tre
comunicazioni sono intercettate e inviate al correlatore in maniera simile al precedente.
Di seguito è descritta la configurazione dell’automa che permette la correlazione
degli eventi generati nell’esempio precedente (Figura 37). Per rendere più semplice la
lettura dell’automa e delle transizioni, ad ogni evento generato è associata una lettera. La
Tabella 6 mostra il valore (lettera) assegnato a ogni comando dell’esempio precedente:
Sensore Comando Input automa
Sensore 1 Apri V1 A
Sensore 2 Apri V1 B
Sensore 2 V1 Aperta C
Sensore 1 V1 Aperta D
Tabella 6: Lista eventi generati
Il flusso di eventi ricevuti dal correlatore è il seguente: A->B->C->D.
La descrizione dell’automa associato è:
∑ = {A,B,C,D} // insieme dei simboli
S = {s0,s1,s2,s3, s4} // insieme finito di stati
s0 ∈ S // stato iniziale
s4 ∈ F // stati finali
δ // funzione di transizione
Implementazione del sistema di correlazione
79
A B C D s0 {s1} - - - s1 - {s2} - - s2 - - { s3} - s3 - - - { s4} *s4 - - - -
Tabella 7: Tabella delle transizioni.
La Figura 38 mostra il diagramma di stato del precedente automa.
Figura 38: Diagramma di stato - Apertura valvola
All’avvio del correlatore, l’automa si trova in uno stato S0. L’automa potrà effettuare
una transizione nello stato S1, solo se il correlatore riceve l’evento A. Considerando la
sequenza di eventi ricevuti (A->B->C->D), l’automa si comporta in maniera corretta
arrivando al suo stato finale S4.
Qualunque sia lo stato attuale dell’automa, se il correlatore non riceve un evento che
permette all’automa di effettuare una transizione nello stato successivo, l’evento sarà
riconosciuto come comportamento anomalo. È utile ricordare che al correlatore arrivano
eventi filtrati (solo quelli della classe eventi_da_correlare) e che questi possono essere
utilizzati per attivare nuovi automi, effettuare transizioni di stato o terminare un automa.
Quando un automa raggiunge uno stato finale, l’operazione associata a quell’automa è
considerata terminata in maniera corretta.
Per ogni automa, è possibile definire un tempo di vita dell’automa stesso. Al termine
del tempo, l’automa viene eliminato dalla lista degli automi attivi, e viene generato un
alert. Questo tempo evita che ci siano automi che non terminano mai e permette di
riconoscere possibili anomalie o attacchi al sistema. Infatti, un automa che non termina
segnala che il sistema non si è comportato in maniera corretta.
8.4 Esempi di correlazione
Di seguito sono illustrati alcuni esempi che descrivono come il correlatore interpreta gli
eventi ricevuti ed effettua le dovute operazioni di correlazione. La Figura 39 e la Figura 40
80
Capitolo 8
mostrano due esempi di operazioni dovuti rispettivamente alle operazioni di apertura
valvola e lettura valvola.
Figura 39: Comando Apri valvola
Figura 40: Comando Leggi valore
Come nell’esempio precedente (Tabella 6), la Tabella 8 associa una lettera a ogni
comunicazione:
Sensore Comando Input automa
Apertura Valvola 1
Sensore 1 Apri V1 A
Sensore 2 Apri V1 B
Sensore 2 V1 Aperta C Sensore 1 V1 Aperta D
Lettura Valvola 2
Sensore 1 Leggi V2 E
Sensore 2 Leggi V2 F
Sensore 2 Valore V2 G
Sensore 1 Valore V2 H
Tabella 8: Lista degli eventi generati.
Il correlatore deve conoscere sia il corretto funzionamento dei due processi, sia gli
eventi iniziali che causano l’attivazione di nuovi automi. Definiamo quindi il flusso degli
eventi attraverso i diagrammi di stato e i relativi automi:
Implementazione del sistema di correlazione
81
Apertura valvola 1:
Figura 41: Diagramma di stato - Apri valvola
Lettura valvola 2:
Figura 42: Diagramma di stato - Lettura valvola
Gli eventi iniziali che permettono l’attivazione dei rispettivi automi sono A ed E.
Quando il correlatore riceve l’evento A, attiva l’automa Apertura Valvola (con stato iniziale
S0), mentre quando riceve l’evento E attiva l’automa Lettura valvola (con stato iniziale G0).
Tutti gli altri eventi, saranno quindi utilizzati per passare in uno degli stati successivi dei
rispettivi automi.
In base al flusso degli eventi ricevuti, il correlatore opera in modi diversi. Di seguito
è illustrato il comportamento del correlatore quando i due processi (Apertura V1 e Lettura
V2) sono eseguiti in maniera corretta e sequenzialmente. In questo caso sarà eseguito
prima tutto il processo 1 ed al termine, sarà eseguito il processo 2. Il correlatore riceverà
quindi la seguente sequenza di eventi:
Figura 43: Flusso eventi apertura e lettura valvola (sequenziale)
Quando il correlatore riceve la sequenza di eventi in Figura 43, esegue le seguenti
operazioni:
1. Riceve A: il correlatore controlla se questo è uno degli eventi iniziali e avvia
l’automa associato: Apertura Valvola (Figura 41).
2. Riceve B: non essendo un evento iniziale, controlla se esiste un automa attivo che
ha B come possibile transizione. L’ automa esiste in quanto è stato avviato nel
82
Capitolo 8
passo precedente. Lo stato attuale dell’automa permette inoltre di passare allo
stato successivo (S0->S1).
3. Riceve C: si comporta come al passo 2 e passa allo stato successivo (S1->S2).
4. Riceve D, e passa nello stato finale (S2->S3).
Raggiunto lo stato finale (Figura 41 – stato S3), l’automa è completo e può essere
disattivato. Un automa che raggiunge il suo stato finale e quindi termina correttamente,
implica che non sono stati rilevati errori o anomalie nel sistema. In maniera simile, il
correlatore continua la correlazione degli eventi E,F,G,H, attivando un nuovo automa e
effettuando le dovute transizioni di stato. Anche in questo caso non sono rilevate anomalie
nel sistema.
Di seguito è mostrato il comportamento del correlatore, quando i due processi
Apertura valvola e Lettura valvola, sono eseguiti in maniera asincrona. Per asincrona si
intende che il processo 2 (lettura della valvola) è avviato prima che il processo 1 (apertura
della valvola) sia completamente terminato. Supponiamo quindi che il correlatore riceva il
seguente flusso di eventi:
Figura 44: Flusso eventi apertura e lettura valvola (asincrono)
Come mostrato in Figura 44 , il correlatore riceve l’evento iniziale del processo 1
(evento A) e subito dopo quello del processo 2 (evento E). In seguito i due processi
continuano in maniera indipendente.
Utilizzando la sequenza di eventi mostrata in Figura 44 il correlatore eseguirà le
seguenti operazioni:
1. Riceve A: poiché questo è un evento iniziale crea l’automa associato (Automa 1 –
Apertura valvola);
2. Riceve E: poiché è un evento iniziale crea l’automa associato (Automa 2 – Lettura
valvola); Da questo momento esistono due automi attivi contemporaneamente.
3. Riceve B: questo non è un evento iniziale, e quindi si controlla se esistano uno o più
automi “vivi” che abbiano una transizione di stato associata a B. Una volta trovato,
il correlatore controlla che dallo stato attuale dell’automa associato sia possibile
passare ad uno stato successivo tramite l’evento B. In questo caso l’automa 1
passerà allo stato successivo.
4. Per gli eventi successivi, il correlatore si comporta come nel passo 3, fino a quando
gli automi non raggiungono il proprio stato finale.
Quando il correlatore riceve un evento, non compie una transizione di stato su tutti
gli automi attivi al suo interno, ma esegue delle operazioni di controllo per selezionare uno
o più automi per i quali quell’evento ha un senso. Se il correlatore non eseguisse queste
operazioni, l’intero processo di correlazione fallirebbe in quanto ad ogni evento ricevuto,
più automi potrebbero andare in stato di stuck. Questo è uno dei motivi che non permette
Implementazione del sistema di correlazione
83
di costruire un singolo automa che contenga tutte le transizioni di stato di tutti i
comportamenti del sistema. È invece necessario descrivere singolarmente gli automi per
ogni processo che si vuole correlare.
Finora si è visto come il correlatore reagisce quando riceve un flusso di eventi
corretto rispetto agli automi descritti al correlatore. L’esempio successivo mostra le
operazioni di correlazioni nel caso in cui uno dei componenti del sistema è compromesso,
ed invia dati falsi. In questo caso, l’entità corrotta è il PLC e le comunicazioni sulla rete
sono le seguenti:
Figura 45: Apertura valvola compromesso
Come si nota in Figura 45, una delle entità del sistema SCADA invia al PLC il
comando di apertura valvola. Il PLC compromesso, non esegue l’operazione di apertura
valvola, bensì invia il comando di chiusura. Inoltre, il PLC comunica alle componenti della
rete SCADA che l’operazione di apertura è stata eseguita con successo. Questo
comportamento anomalo è simile al comportamento di PLC compromessi da Stuxnet 19e
Duqu20.
Come nell’esempio precedente, il correlatore conosce il flusso corretto di eventi
quando il processo Apri valvola è eseguito:
Figura 46: Diagramma di stato - Apri valvola.
19 Stuxnet: primo worm sviluppato per sistemi industriali, in grado di riprogrammare i
dispositivi. http://www.symantec.com/content/en/us/enterprise/media/security_response/whitepapers/w32_stuxnet_dossier.pdf
20 Duqu: worm sviluppato per sistemi industriali, che fornisce servizi all’attaccante. http://www.crysys.hu/publications/files/bencsathPBF11duqu.pdf
84
Capitolo 8
In base alla configurazione del sensore 2, il correlatore può ricevere diversi flussi di
eventi. In particolare si possono avere i seguenti due casi:
1. Il sensore 2 non conosce le comunicazioni associate agli eventi X e Z (o non sono
classificati come “Eventi da correlare”), e non li invia al correlatore.
2. Il sensore 2 conosce gli eventi X e Z, e li invia al correlatore.
Di seguito è descritto come il sistema, ed in particolare il correlatore, si comporta in
entrambi gli scenari. Nel primo caso, il sensore 2 non invia gli eventi al correlatore. Il flusso
è il seguente:
Flusso 1
Nel secondo caso il flusso è :
Flusso 2
Le operazioni del correlatore nel caso del Flusso 1 sono le seguenti:
1. Riceve A: è un evento iniziale, e quindi crea l’automa associato
2. Riceve D:
a. non crea nessun automa poiché l’evento non è iniziale
b. Controlla che esista un automa attivo con una possibile transizione di stato
associata all’evento D.
c. L’automa esiste ma non può passare nello stato successivo poiché l’unica
transizione possibile si ha se l’automa riceve B.
3. Il correlatore segnala quindi l’errore dell’evento B.
4. L’automa è inoltre in stato di “stuck” poiché dallo stato S0 non è ammessa la
transizione associata all’evento D. In questo modo è possibile collegare l’alert
generato al punto 3, al fallimento di un automa.
Nell’esempio visto utilizzando il Flusso 1, si hanno due segnalazioni, una sul singolo
evento (B) e uno riguardante l’automa che non ha raggiunto con successo stato finale.
Implementazione del sistema di correlazione
85
Nel caso del Flusso 2 il correlatore effettua le seguenti operazioni:
1. Riceve A: questo è un evento iniziale e quindi crea l’automa associato;
2. Riceve X:
a. Non crea nessun automa poiché l’evento non è iniziale
b. Controlla che esista un automa attivo con una possibile transizione di stato
dovuta all’evento X;
c. Non trova nessuna transizione possibile e segnala l’evento X come
anomalo;
3. Riceve Z e si comporta come al passo 2;
4. Riceve D:
a. Non crea nessun automa poiché l’evento non è iniziale
b. Controlla che esista un automa ‘vivo’ con una possibile transizione di stato
con D;
c. Seleziona l’automa creato in precedenza. Questo automa non può passare
nello stato successivo, poiché nello stato S0, l’unica transizione possibile si
ha se si riceve l’evento B;
5. Il correlatore segnala quindi l’errore dovuto all’evento D.
6. L’automa è inoltre in stato di “stuck” poiché dallo stato S0 si è effettuata una
transizione non ammessa e l’automa non è potuto transire in nessuno stato valido.
In questo modo è possibile collegare l’alert del singolo evento al fallimento di un
automa.
Gli esempi precedenti descrivono le operazioni di correlazione nell’ipotesi in cui
esista un unico correlatore per tutto il sistema SCADA. Nel seguito sono descritti i
comportamenti del sistema di correlazione durante l’operazione di apertura valvola, nel
caso di più correlatori, ognuno con le proprie configurazioni.
Figura 47: Apertura valvola con più correlatori
86
Capitolo 8
Come mostrato in Figura 47, nel sistema sono presenti tre correlatori, uno per ogni
segmento di rete (SCADA e Campo) e uno per l’intero sistema ICS.
Le configurazioni dei correlatori sono le seguenti:
Correlatore SCADA: Correlatore Campo:
Figura 48: Automa correlatore SCADA
Figura 49: Automa correlatore Campo
Correlatore ICS:
Figura 50: automa correlatore ICS
Le operazioni eseguite dal sistema di correlazione sono:
1. Il Sensore 1 intercetta il comando “Apri V1”, lo classifica come Evento da correlare e
lo invia al Correlatore SCADA;
2. Il Correlatore SCADA:
a. Invia l’evento al padre (Correlatore ICS);
b. Controlla la sua configurazione e crea l’automa associato all’evento (Figura
48);
3. Il Correlatore ICS riceve l’evento e crea l’automa associato (Figura 50); è utile
specificare che se il correlatore ICS avesse avuto un padre, avrebbe trasmesso
l’evento prima di eseguire le operazioni di correlazione.
4. Il Sensore 2 intercetta il comando “Apri V1”, lo classifica come Evento da correlare
e lo invia al Correlatore Campo;
5. Il Correlatore Campo:
a. Invia l’evento al padre (Correlatore ICS);
b. Controlla la sua configurazione e crea l’automa associato all’evento (Figura
49);
6. Il Correlatore ICS riceve l’evento, e poiché esiste una transizione si muove nello
stato S1;
7. Il Sensore 2 intercetta il comando “V1 Aperta”, lo classifica come Evento da
correlare e lo invia al Correlatore Campo;
8. Il Correlatore Campo:
Implementazione del sistema di correlazione
87
a. Invia l’evento al padre;
b. Controlla che esista una transizione, la esegue e termina con successo
l’automa. In questo momento nel Correlatore Campo non esistono più
automi vivi a differenza degli altri correlatori;
9. Il Correlatore ICS riceve l’evento, ed effettua la transizione in S2
10. Il sensore 1 intercetta il comando “V1 Aperta”, lo classifica come Evento da
correlare e lo invia al Correlatore SCADA;
11. Il correlatore SCADA:
a. Invia l’evento al padre;
b. Controlla l’esistenza di una transizione e termina con successo l’automa.
12. Il Correlatore ICS riceve l’evento, e termina con successo l’automa.
Questo esempio illustra come ogni correlatore opera in maniera autonoma e
indipendente. Infatti, uno stesso evento può provocare il fallimento di un automa su un
correlatore, e genera invece una transizione di stato in un automa in un altro correlatore.
Questo caso è mostrato nella figura successiva, nel quale il PLC è corrotto e invia comandi
errati:
Figura 51: PLC corrotto
Le configurazioni dei correlatori sono le seguenti:
Correlatore SCADA:
Correlatore Campo:
88
Capitolo 8
Correlatore ICS:
Come evidenziato dalla descrizione degli automi, il correlatore CAMPO conosce e
implementa un automa per il comando di chiusura valvola. Di seguito sono descritte le
operazioni dei tre correlatori:
1. Il Correlatore SCADA riceve l’evento A e crea l’automa associato;
2. Il Correlatore ICS riceve l’evento A e crea l’automa associato;
3. Il Correlatore CAMPO riceve l’evento X e crea l’automa associato;
4. Il Correlatore ICS riceve l’evento X. Poiché non esiste una configurazione che
accetti quell’evento, lo ignora;
5. Il Correlatore CAMPO riceve Z e termina con successo l’automa;
a. Quindi il correlatore non rileva nessuna anomalia nel suo segmento di rete.
I comandi e i flussi ricevuti sono corretti;
6. Il Correlatore ICS riceve Z. Poiché non esiste una configurazione che accetti
quell’evento, lo ignora.
7. Il Correlatore SCADA riceve D e termina con successo l’automa.
8. Il Correlatore ICS riceve l’evento D. L’automa vivo nel correlatore accetta l’evento
D, ma lo stato attuale dell’automa non permette il passaggio di stato in s1. L’evento
è quindi rilevato come comportamento anomalo.
Questo esempio mostra la potenza del sistema di correlazione. Infatti, anche se
singole entità (Correlatore SCADA e CAMPO) terminano con successo i rispettivi automi, il
sistema rileva l’anomalia.
8.5 Comunicazioni e problemi di sincronismo
I correlatori devono essere in grado di ricevere correttamente gli eventi da analizzare e
devono quindi condividere un struttura di interconnessione che permetta la
comunicazione degli eventi.
La comunicazione degli eventi può essere implementata in più modi. È possibile
scrivere su un unico file condiviso tra tutti i sensori e i correlatori o condividere molteplici
file. In quest’ultimo caso, ogni componente del sistema, sensore o correlatore, condivide
un file con il correlatore padre, nel quale saranno scritti gli eventi. Una terza
implementazione è l’invio di eventi attraverso la rete. In questo caso il correlatore dovrà
implementare un servizio che resta in ascolto su una o più porte ed è in grado di ricevere
gli eventi dei vari figli.
Implementazione del sistema di correlazione
89
Tutte le possibili implementazioni devono considerare la sincronizzazione tra le
componenti, nonché i ritardi di comunicazione. In un sistema di correlazione real-time,
ritardi di comunicazione possono causare correlazioni errate, poiché gli eventi ricevuti dai
correlatori non sono nell’ordine corretto. Se il correlatore attende un determinato evento
ma, per un ritardo nelle comunicazioni, riceve l’evento successivo, le operazioni di
correlazione sarebbero compromesse.
Consideriamo il seguente esempio dove è presente un solo correlatore che riceve
eventi da quattro differenti sensori:
Figura 52: Correlatore ICS con più reti da monitorare
Supponiamo che il sistema funzioni in maniera corretta e che gli eventi inviati dai
sensori siano i seguenti:
Evento Sensore Messaggio Tempo
#1 Sensore 1 A t0
#2 Sensore 2 B t1
#3 Sensore 3 C t2
#4 Sensore 4 D t3
Tabella 9: Flusso eventi correlatore
(la colonna Tempo indica il momento in cui l’evento viene ricevuto dal correlatore)
In assenza di ritardi di comunicazione, il correlatore riceve gli eventi in maniera
corretta: prima l’evento 1, poi il 2, il 3 ed infine il 4. Supponendo che il correlatore conosca
la sequenza corretta di eventi per quella determinata operazione, il correlatore non rileva
nessuna anomalia nel sistema poiché gli eventi sono stati ricevuti nell’ordine corretto e le
90
Capitolo 8
operazioni di correlazione non rilevano nessuna anomalia nell’operazione effettuata. Nel
caso in cui ci fossero ritardi di comunicazione, il correlatore rileverebbe un’anomalia.
Infatti, supponendo che il sistema funzioni correttamente, ma la comunicazione con
il sensore 3 sia soggetta a ritardi, si avrebbe un flusso di eventi simile a quello illustrato
nella tabella successiva:
Evento Sensore Messaggio Tempo
#1 Sensore 1 A t0
#2 Sensore 2 B t1
#4 Sensore 4 D t2
#3 Sensore 3 C t3
Tabella 10: Flusso eventi correlatore con ritardi di comunicazione
In questo caso, l’evento #4 è ricevuto prima del #3 a causa dei ritardi del sensore3. Il
correlatore, che si aspetta per quell’operazione il flusso di eventi A -> B -> C -> D,
rileverebbe un comportamento anomalo del sistema.
Per eseguire le operazioni di correlazione, è necessario conoscere i comportamenti
corretti del sistema per poi confrontarli con gli eventi generati durante le operazioni del
sistema. Sono stati quindi sviluppati due strumenti: FSMGen (Finite State Machine
Generator) e SEC (SCADA Engine Correlation). Il primo permette di descrivere i flussi, i
comportamenti e le comunicazioni del sistema, mentre il secondo analizza gli eventi del
sistema e, in base ai comportamenti descritti con FSMGen, esegue le operazioni di
correlazione.
Questo capitolo presenta i due tool, e descrive come sono stati sviluppati, quali
funzionalità offrono, come operano e come utilizzarli.
9.1 FSMGen
FSMGen è uno strumento sviluppato utilizzando linguaggi web-oriented quali HTML21,
PHP22 e JavaScript23, e permette di creare automi che descrivono il comportamento del
sistema da analizzare. La scelta dei linguaggi web-oriented è dovuta alla portabilità degli
stessi. Infatti, per utilizzare lo strumento è necessario un browser web, presente ormai in
tutti i dispositivi.
L’idea alla base dello strumento è di guidare l’utente attraverso semplici passi che
consentono di descrivere le reti da analizzare, le componenti delle stesse e le
comunicazioni permesse tra i vari host. Definiti i comportamenti del sistema, lo strumento
consente di generare automaticamente gli automi che dovranno essere incorporati in SEC.
21 HTML (HyperText Markup Language): linguaggio di markup che descrive le modalità di
impaginazione 22 PHP: HyperText Processor. Linguaggio utilizzato per lo sviluppo di applicazioni web 23 JavaScript: Linguaggio di scripting orientato agli oggetti, comunemente usato nei siti web
9
Strumenti sviluppati
92
Capitolo 9
Le funzionalità che lo strumento offre sono le seguenti:
1. Import dei report di Nessus
2. Descrizione delle reti da analizzare
3. Definizione delle regole tra host e reti
4. Definizione dei ruoli degli host a seconda dei protocolli individuati nella rete
5. Creazione automatica di automi basata su modelli predefiniti (Modbus)
6. Creazione avanzata di automi
7. Visualizzazione grafica 24degli automi
8. Export degli automi in formato XML (da importare in SEC)
Come mostrato in Figura 53, dopo aver importato uno o più report di Nessus (uno
per rete), lo strumento estrae automaticamente le informazioni utili per la creazione degli
automi, quali:
Host esistenti nella rete
Indirizzi IP
Sistema Operativo
Indirizzo MAC
Nome dell’ host
Protocolli di comunicazione
Porte aperte
Figura 53: Informazioni estratte dal report.
L’utente può quindi decidere di modificare le informazioni estratte, aggiungere o
eliminare degli host e le relative informazioni.
24 La generazione dei diagrammi di stato è effettuata costruendo un file di configurazione,
utilizzando la descrizione dell’automa inserita dell’utente. Il file è viene successivamente interpretato da uno strumento chiamato Graphviz (http://www.graphviz.org/), il quale crea l’immagine finale.
Strumenti sviluppati
93
Dopo aver descritto le reti da analizzare, lo strumento permette di definire con
granularità differente le regole di comunicazione. Come mostrato in Figura 54, è possibile
indicare quali reti e quali host (identificati nelle fasi precedenti) non possono comunicare
tra loro.
Figura 54: Definizione regole di comunicazione.
La definizione di queste regole evita che nella fase successiva di configurazione delle
comunicazioni, si associno dispositivi per i quali le comunicazioni sono state vietate.
In base ai i protocolli rilevati durante l’analisi dei report, può essere necessario
definire ulteriori configurazioni. Queste informazioni permettono allo strumento di
apprendere le configurazioni dei protocolli esistenti e generare automaticamente un
insieme di automi che sono sempre validi per ogni protocollo. Come mostrato in Figura 55,
durante l’analisi del report sono stati rilevati dei dispositivi che supportano il protocollo
Modbus. In questa fase è quindi necessario istruire lo strumento, definendo quali
dispositivi agiscono come slave e quali come master.
94
Capitolo 9
Figura 55: Configurazione protocolli.
Dopo aver descritto i protocolli, lo strumento possiede tutte le informazioni per
generare automaticamente gli automi. Questa fase utilizza i modelli di default predefiniti
nello strumento. I modelli sono file XML che descrivono tutte le transizioni, gli stati e i
valori per ogni comunicazione, e possono essere modificati, aggiunti o eliminati secondo le
esigenze e delle configurazioni di rete del sistema.
Nel passo successivo, lo strumento visualizza gli automi generati, classificandoli per
rete e dispositivi. Come mostrato in Figura 56, FSMGen crea per ogni automa sia il
diagramma degli stati, sia il file XML che potrà essere caricato in SEC. L’utente può
visualizzare l’automa sia in maniera grafica che testuale, con la possibilità di modificare le
transizioni e le relative informazioni.
Strumenti sviluppati
95
Figura 56: Automi generati automaticamente.
Lo strumento permette inotltre di creare gli automi in maniera del tutto manuale.
Ciò permette di descrivere automi più specifici e dettagliati per il proprio sistema. Come
mostrato in Figura 57, per ogni transizione è possibile definire gli host che comunicano, i
protocolli utilizzati ed eventualmente le informazioni contenute in ogni comunicazione.
Per evitare errori durante la creazione, gli host e i protocolli sono caricati dalle descrizioni
di rete eseguite nei passi precedenti. Inoltre, in base al protocollo selezionato sono
mostrati specifici campi, che aiutano l’utente nella descrizione del protocollo selezionato.
Al termine della configurazione dell’automa, lo strumento esegue dei controlli sulla
correttezza sintattica degli stati e delle transizioni create. Se l’automa è corretto, è
mostrato il diagramma degli stati, le informazioni relative a ogni transizione e l’automa in
formato XML. Quest’ultimo può essere inoltre salvato su file e caricato in SEC.
96
Capitolo 9
Figura 57: Creazione manuale di automi
Figura 58: Visualizzazione dell'automa creato.
Strumenti sviluppati
97
Considerazioni finali sullo strumento
Data la molteplicità di protocolli di comunicazione, architetture di rete e dispositivi
utilizzati nei sistemi SCADA, FSMGen è stato progettato in maniera modulare. Questa
proprietà permette di aggiungere allo strumento la conoscenza di nuovi protocolli in
maniera semplice e veloce. È inoltre possibile creare e caricare nuovi modelli di automi da
utilizzare per la generazione automatica degli stessi.
9.2 SEC
Il secondo strumento sviluppato si chiama SEC, acronimo di SCADA Engine Correlation
ossia motore di correlazione di eventi per sistemi SCADA. Lo scopo di questo strumento è
di raccogliere eventi generati dagli IDS e correlarli seguendo comportamenti predefiniti. Il
funzionamento di SEC si basa su due elementi chiave: gli eventi passati dai sensori e i
comportamenti predefiniti, rappresentati sotto forma di automi a stati finiti, creati
attraverso FSMGen.
Di seguito indicheremo SEC e correlatore come due sinonimi.
Figura 59: Elementi chiave del processo di correlazione.
Il contesto applicativo di SEC prevede una o più reti, in ognuna delle quali è presente
un sensore IDS che analizza il traffico e memorizza gli eventi rilevati all’interno di un
database. Il database è poi acceduto da SEC che analizza i singoli eventi e li confronta con
gli automi forniti in input. Se il correlatore rileva un evento non permesso, e quindi non
previsto dal comportamento definito negli automi, genera un allarme. Una
rappresentazione grafica di una possibile situazione di applicazione di SEC è descritta in
Figura 60.
98
Capitolo 9
Una distinzione principale sugli utilizzi di SEC riguarda il campo di applicazione.
Esistono due tipologie di correlatore: locale e globale. Il correlatore locale analizza gli
eventi che riguardano solo la rete controllata e che non sono in alcun modo collegati ad
altre reti nel sistema. Il correlatore globale agisce a un livello superiore e ad esso si posso
associare due o più correlatori. Il suo obiettivo è di raccogliere gli eventi trasmessi dai
correlatori associati e analizzarli sulla base degli automi definiti. Questa distinzione tra
correlatori locali e globali consente di controllare un sistema in maniera gerarchica. Infatti,
un correlatore locale può diventare figlio di un correlatore globale e uno globale di un
altro globale.
Figura 60: Contesto applicativo di SEC .
Oltre ad essere un correlatore di eventi per sistemi SCADA, la particolarità di SEC è
dovuta alla capacità di analizzare i protocolli di rete impiegati in questi sistemi e correlarli
in conformità ai comportamenti noti a priori. A tal scopo è stato necessario implementare
SEC in modo più modulare possibile. Ogni protocollo è stato interpretato come una
libreria, questo permette di estendere l’applicazione aggiungendo nuovi protocolli. Allo
stato dell’arte, SEC è in grado di analizzare il protocollo ModBusTCP.
Generazione eventi
Il funzionamento di SEC è legato agli eventi generati dai sensori IDS associati. Ogni
correlatore ha associato uno o più sensori di rete. I correlatori locali prevedono un solo
sensore poiché agiscono localmente alla rete controllata. Da un punto di vista logico il
correlatore locale e il sensore sono due entità separate, ma da un punto di vista
Strumenti sviluppati
99
implementativo possono essere installati sulla stessa macchina fisica per questioni di
efficienza e sicurezza. Invece, il correlatore globale s’interfaccia con i correlatori locali
associati per identificare da quali sensori rilevare gli eventi.
Ogni sensore IDS memorizza gli eventi rilevati in un database dedicato. Il database
può essere acceduto dall’utente che identifica il sensore e dall’utente che identifica il
correlatore locale. Se sono installati anche dei correlatori globali, gli utenti associati a ogni
correlatore devono avere i relativi privilegi per accedere ai database necessari. Ogni
correlatore ha le credenziali di accesso ai database dei sensori associati in un file di
configurazione. Nel file sono presenti oltre alle credenziali anche gli indirizzi di rete, dove
sono memorizzati i database.
SEC è stato implementato per analizzare gli eventi generati da Snort25, un
applicativo open-source che implementa funzioni di network intrusion prevention system
(NIPS) e network intrusion detection system (NIDS). L’implementazione ha considerato
solo l’aspetto riguardante il NIDS, poiché non si conoscono le specifiche interne di ogni
componente, a differenza dei protocolli e delle comunicazioni inviate.
Funzionamento
All’avvio dell’applicazione del correlatore sono caricati in memoria gli automi. Ogni
automa è definito in un file XML memorizzato in una cartella contenente tutti gli automi
che dovranno essere caricati all’avvio del correlatore. In seguito, sono eseguiti i test di
connettività di rete per rilevare se tutti i dispositivi di rete da contattare sono attivi. I
dispositivi sono sistemi che eseguono gli altri correlatori e quelli che memorizzano
database utilizzati dai sensori per memorizzare gli eventi rilevati. Completata la fase di
caricamento e controllo iniziale, l’applicazione si connette ai database dei correlatori e
carica in memoria tutti gli eventi da analizzare.
Il correlatore verifica per ogni evento se esiste un automa in attesa di eseguire una
transazione oppure un automa inattivo in attesa di un evento iniziale. In caso positivo,
aggiorna lo stato degli automi in memoria, viceversa segnala un allarme poiché non è
previsto alcuno stato del sistema che possa accettare l’evento analizzato. Questo
comportamento identifica una politica di default-deny, si segnala come anomalia tutto ciò
che non è previsto come stato del sistema nel momento in cui si analizza l’evento.
Caratteristiche tecniche
SEC è stato sviluppato in C#, un linguaggio di programmazione orientato agli oggetti. La
scelta è dovuta ai molteplici vantaggi che questo linguaggio offre ed in particolare
all’ottimo supporto per l’interazione con XML e DBMS, parti essenziali per il
funzionamento dell’applicazione.
25 http://www.snort.org/
L’utilizzo crescente di protocolli TCP/IP in sistemi SCADA, ha permesso di creare un
ambiente di test nel quale simulare un piccolo sistema industriale. In particolare è stato
creato un ambiente composto di due reti, una di controllo (SCADA) e una di processo
(CAMPO), nel quale le comunicazioni e i comandi tra i dispositivi utilizzano il protocollo
Modbus TCP.
Questo capitolo descrive i test effettuati utilizzando la topologia di rete illustrata in
Figura 61. Per ogni prova effettuata saranno descritti i comandi26 inviati e ricevuti da ogni
entità della rete, gli automi ed i correlatori utilizzati nel test e come questi hanno
identificato le anomalie del sistema.
Figura 61: Topologia ambiente di test.
26 Comandi: comunicazioni con protocollo Modbus TCP effettuate tra master e slave.
10
Prove
102
Capitolo 10
I flussi e le comunicazioni nell’ambiente di test rispettano le implementazioni in
sistemi SCADA reali.
Configurazione dell’ambiente di test
L’ambiente di test è stato creato su una macchina con le seguenti caratteristiche:
Processore: Intel Core i5-2410M
Velocità Clock: 2.3 GHz
Memoria: 4 GB
Sistema Operativo: Windows 7 Home Edition
I dispositivi sono stati simulati creando macchine virtuali con l’ausilio del software
VMware Workstation27. La scelta delle macchine virtuali è stata necessaria per creare,
intercettare e analizzare del vero traffico tra due reti separate. In particolare il Modbus
Master è eseguito su una macchina virtuale con S.O. Ubuntu 10.04 LTS. Sulla stessa
macchina è stato inoltre installato e configurato l’IDS che intercetta le comunicazioni della
rete SCADA. Il Modbus Gateway, che agisce come PLC, è stato simulato su una macchina
virtuale con sistema operativo Debian 6.0.5. Sulla stessa macchina è presente l’IDS che
intercetta le comunicazioni della rete CAMPO e il database contenente lo storico degli
eventi rilevati. Il Modbus slave è stato invece simulato su una macchina virtuale con S.O.
Backtrack 5. Per evitare di sovraccaricare la macchina, i correlatori sono stati eseguiti
direttamente sull’host (Windows 7).
Informazioni dettagliate su come creare, installare e configurare ogni macchina,
sono descritte in Appendice: Creazione e configurazione dell’ambiente di test.
Utilizzo degli strumenti per i test
Le comunicazioni inviate dal Modbus Master sono state generate con lo strumento
tcpmaster.py28. Dopo aver inserito l’indirizzo IP dello slave al quale inviare il comando
(Gateway Modbus per la rete 1 e Modbus Slave per la rete 2) è possibile inviare comandi
con differenti function code e valori. In base al function code selezionato possono essere
richieste altre informazioni. Di default, il master trasmette la richiesta allo slave con i
seguenti parametri:
Porta: 502
Modbus Starting address: 100
Modbus Number of registers: 3
27 VMware Workstation è un software di virtualizzazione che permette di eseguire
contemporaneamente più sistemi operativi su un singolo computer. 28 tcpmaster.py è uno strumento che permette di simulare un master che comunica con
protocollo Modbus TCP.
Prove
103
Gli slave sono implementati tramite lo strumento tcpslave.py29. Quando lo slave si
attiva è necessario inserire l’indirizzo IP sul quale il servizio deve ascoltare le richieste
Modbus. Dopo aver inserito l’IP, è possibile configurare lo slave (starting address, number
of registers, valori dei registri etc.) o avviare lo slave in modo che rimanga in attesa di
richieste. Di default lo slave è configurato con i seguenti parametri:
Porta sulla quale ascoltare: 502
Starting address: 100
3 registri con valori [1,2,3]
Le impostazioni di default permettono di effettuare comunicazioni tra il master e lo
slave senza ulteriori configurazioni da parte dell’utente. Quando lo slave riceve una
richiesta, mostra a video il function code richiesto e rimane in attesa dell’input dell’utente.
L’utente può decidere se la risposta deve essere creata correttamente (stesso function
code e parametri) o se rispondere con un function code diverso. Questo permette di
simulare malfunzionamenti o manomissioni dello slave.
29 tcpslave.py è uno strumento che permette di simulare uno o più slave che comunicano con
protocollo Modbus TCP.
104
Capitolo 10
Test #1: Comunicazioni singola rete (rete 1 - 192.168.3.0/24)
In questo test sono simulate richieste e risposte Modbus nella rete 1.
Scopo del test
Verificare che il correlatore analizzi i comportamenti di una singola rete sia quando le
comunicazioni Modbus sono corrette, sia quando s’inviano o ricevono comunicazioni
errate. Ovvero, saranno testati i casi in cui:
1. Ad una richiesta da parte del master corrisponde una risposta corretta da parte dello slave (es: lo slave risponde con il function code corretto o con un exception code permesso)
2. Ad una richiesta da parte del master corrisponde una risposta inattesa da parte dello slave (es: lo slave risponde con un function code differente da quello richiesto)
3. Si eseguono delle richieste non definite dagli automi.
Dispositivi
Il correlatore globale e i dispositivi della seconda rete non sono utilizzati in questo
test.
Automi
Di seguito sono illustrati gli automi caricati in ogni correlatore.
Correlatore rete 1
Automa Read Multiple Registers:
Prove
105
Nome Transizione
Indirizzo Sorgente
Indirizzo Destinatario
Protocollo
Opzioni del protocollo
F.
code Starting address
Values
SE 192.168.3.130 192.168.3.129 Modbus TCP
3
0
ex1 192.168.3.129 192.168.3.130 Modbus TCP
83
1
ex2 192.168.3.129 192.168.3.130 Modbus TCP
83
2
ex3 192.168.3.129 192.168.3.130 Modbus TCP
83
3
ex4 192.168.3.129 192.168.3.130 Modbus TCP
83
4
F 192.168.3.129 192.168.3.130 Modbus TCP
3
Il file XML riguardante l’automa è descritto in appendice: Test#1 – Correlatore rete 1
Comunicazioni
Di seguito sono illustrate le comunicazioni inviate e ricevute da ogni entità.
#1 - Comunicazione corretta: Read multiple registers30
30 Read Multiple Registers: Permette di leggere i valori dei registri contenuti nello slave. Il
function code associato è 03.
106
Capitolo 10
#2 - Comunicazione corretta: Illegal Data Address31
#3 - Comunicazione errata: Risposta con function code differente (06 – Write
Single Register)
31 Illegal data address: lo slave non supporta l’intervallo di bit presente nella richiesta. L’
exception code ha valore 02.
Prove
107
#4 - Comunicazione errata: Richiesta con function code non permesso (01 –
Read Coils)
#5 Richieste asincrone
Risultati
Nei test descritti, il correlatore ha rilevato correttamente le anomalie. In particolare: per i
casi #1 e #2 ha rilevato che le comunicazioni sono state eseguite correttamente, mentre
nel caso #3 ha rilevato una risposta non prevista a seguito della richiesta effettuata. Nel
caso #4, poiché non esiste nessun automa che descrive la comunicazione inviata, si rileva
l’anomalia. Nell’ultimo test (#5), il correlatore crea molteplici automi, uno per ogni
richiesta, e li termina correttamente alle successive risposte senza rilevazioni di anomalie.
108
Capitolo 10
Test #2: Comunicazioni singola rete (rete 2 - 192.168.4.0/24)
In maniera simile ai precedenti test saranno generate richieste e risposte Modbus nella
rete 2.
Scopo del test
Verificare che il correlatore analizzi i comportamenti della singola rete sia quando le
comunicazioni Modbus sono corrette, sia quando s’inviano o ricevono comunicazioni
errate. Ovvero, saranno testati i casi in cui:
1. Ad una richiesta da parte del master corrisponde una risposta corretta da parte dello slave (es: lo slave risponde con il function code corretto o con un exception code permesso)
2. Ad una richiesta da parte del master corrisponde una risposta inattesa da parte dello slave (es: lo slave risponde con un function code differente da quello richiesto)
3. Si eseguono delle richieste non definite dagli automi.
Dispositivi
Il correlatore globale e i dispositivi della seconda rete non sono utilizzati in questo
test.
Prove
109
Automi
Di seguito sono illustrati gli automi caricati in ogni correlatore.
Correlatore rete 2
Automa Read Multiple Registers:
Nome Transizione
Indirizzo Sorgente
Indirizzo Destinatario
Protocollo
Opzioni del protocollo
F. code Starting address
Values
SE 192.168.4.130 192.168.4.131 Modbus
TCP
3
0
ex1 192.168.4.131 192.168.4.130 Modbus
TCP
83
1
ex2 192.168.4.131 192.168.4.130 Modbus
TCP
83
2
ex3 192.168.4.131 192.168.4.130 Modbus
TCP
83
3
ex4 192.168.4.131 192.168.4.130 Modbus
TCP
83
4
F 192.168.3.130 192.168.4.131 Modbus
TCP
3
Il file XML riguardante l’automa è mostrato in appendice: Test#2 – Correlatore rete
2.
110
Capitolo 10
Comunicazioni
Di seguito sono illustrate le comunicazioni inviate e ricevute da ogni entità.
#1 - Comunicazione corretta: Read multiple registers (Function Code 03)
#2 - Comunicazione corretta: Illegal Data Address (Exception n. 02)
#3 - Comunicazione errata: Risposta con function code differente (06 – Write
Single Register)
Prove
111
#4 - Comunicazione errata: Richiesta con function code non permesso (01 –
Read Coils)
#5 - Richieste asincrone
Risultati
Nei casi descritti, il correlatore ha rilevato correttamente le anomalie. In particolare: per i
casi #1 e #2 ha rilevato che le comunicazioni sono state eseguite correttamente, mentre
nel caso #3 ha rilevato una risposta non prevista a seguito della richiesta effettuata. Nel
caso #4, poiché non esiste un automa che descrive la comunicazione inviata, si rileva
l’anomalia. Nell’ultimo test (#5), il correlatore crea più automi, uno per ogni richiesta, e li
termina correttamente alle successive risposte senza rilevazioni di anomalie.
I test successivi analizzano le comunicazioni su entrambe le reti viste in precedenza.
In questo modo è possibile eseguire test di correlazioni che considerano operazioni
‘composte’ che hanno inizio in una rete e coinvolgono la successiva.
112
Capitolo 10
Test #3: Lettura valore slave
In questo test vengono generate delle richieste dal master della rete 1 verso slave della
rete 2. Le comunicazioni dovranno quindi passare dal Modbus Gateway che riceve il
comando dal Modbus Master, lo invia allo slave corretto e risponde con il valore letto.
Scopo del test
Verificare che i comandi di entrambe le reti siano effettuati correttamente e si rispettino i
flussi descritti.
Dispositivi
Automi
Di seguito sono illustrati gli automi caricati in ogni correlatore.
Correlatore rete 1
Automa Read Multiple Registers:
Prove
113
Correlatore rete 2
Automa Read Multiple Registers:
Correlatore globale
Automa Read Multiple Registers Sync:
114
Capitolo 10
Nome Transizione
Indirizzo Sorgente
Indirizzo Destinatario
Protocollo
Opzioni del protocollo
F. code Starting address
Values
ST 192.168.3.130 192.168.3.129 Modbus TCP 3
0
ex1 192.168.3.129 192.168.3.130 Modbus TCP
83
1
ex2 192.168.3.129 192.168.3.130 Modbus TCP
83
2
ex3 192.168.3.129 192.168.3.130 Modbus TCP
83
3
ex4 192.168.3.129 192.168.3.130 Modbus TCP
83
4
R 192.168.4.130 192.168.4.131 Modbus TCP
3
0
ex12 192.168.4.131 192.168.4.130 Modbus TCP
83
1
ex22 192.168.4.131 192.168.4.130 Modbus TCP
83
2
ex32 192.168.4.131 192.168.4.130 Modbus TCP
83
3
ex42 192.168.4.131 192.168.4.130 Modbus TCP
83
4
V 192.168.4.131 192.168.4.130 Modbus TCP 3
ex13 192.168.3.129 192.168.3.130 Modbus TCP
83
1
ex23 192.168.3.129 192.168.3.130 Modbus TCP
83
2
ex33 192.168.3.129 192.168.3.130 Modbus TCP
83
3
ex43 192.168.3.129 192.168.3.130 Modbus TCP
83
4
V2 192.168.3.129 192.168.3.130 Modbus TCP 3
Il file XML riguardante l’automa è mostrato in appendice: Test#3 – Richieste sincrone.
Prove
115
Comunicazioni
Di seguito sono illustrate le comunicazioni inviate e ricevute da e per ogni entità.
#1 - Comunicazione corretta: Read multiple registers
#2 - Comunicazione errata: Function code differente
Risultati
Nei casi descritti, i correlatori delle singole reti non hanno rilevato nessuna anomalia. Il
correlatore globale ha invece rilevato delle comunicazioni non permesse. In particolare:
per il caso #1 ha rilevato che le comunicazioni sono state eseguite correttamente, mentre
nel caso #2 ha rilevato le comunicazioni errate (Write Coils).
116
Capitolo 10
Test #4: Richieste asincrone
In questo test il master della rete 1 genera delle richieste per lo slave della rete 2. Le
comunicazioni dovranno quindi passare dal Modbus Gateway che riceve il comando dal
Modbus Master, lo invia allo slave corretto. Quest’ultima operazione può essere ripetuta
un numero arbitrario di volte ma deve essere seguita da una risposta al Modbus Master.
Scopo del test
Verificare che i comandi di entrambe le reti siano effettuati correttamente e si rispettino i
flussi asincroni descritti.
Dispositivi
Automi
Di seguito sono illustrati gli automi caricati in ogni correlatore.
Correlatore rete 1
Automa Read Multiple Registers:
Prove
117
Correlatore rete 2
Automa Read Multiple Registers:
Correlatore globale
Automa Read Multiple Registers Async:
118
Capitolo 10
Nome Transizione
Indirizzo Sorgente
Indirizzo Destinatario
Protocollo
Opzioni del protocollo
F. code Starting address
Values
ST 192.168.3.130 192.168.3.129 Modbus
TCP
3
0
ex1 192.168.3.129 192.168.3.130 Modbus
TCP
83
1
ex2 192.168.3.129 192.168.3.130 Modbus
TCP
83
2
ex3 192.168.3.129 192.168.3.130 Modbus
TCP
83
3
ex4 192.168.3.129 192.168.3.130 Modbus
TCP
83
4
R1 192.168.4.130 192.168.4.131 Modbus
TCP
3
0
ex12 192.168.4.131 192.168.4.130 Modbus
TCP
83
1
ex22 192.168.4.131 192.168.4.130 Modbus
TCP
83
2
ex32 192.168.4.131 192.168.4.130 Modbus
TCP
83
3
ex42 192.168.4.131 192.168.4.130 Modbus
TCP
83
4
R2 192.168.4.131 192.168.4.130 Modbus
TCP
3
ex13 192.168.3.129 192.168.3.130 Modbus
TCP
83
1
ex23 192.168.3.129 192.168.3.130 Modbus
TCP
83
2
ex33 192.168.3.129 192.168.3.130 Modbus
TCP
83
3
ex43 192.168.3.129 192.168.3.130 Modbus
TCP
83
4
R3 192.168.3.129 192.168.3.130 Modbus
TCP
3
Il file XML riguardante l’automa è mostrato in appendice: Test#4 – Richieste
asincrone.
Prove
119
Comunicazioni
Di seguito sono illustrate le comunicazioni inviate e ricevute da e per ogni entità.
#1 – Comunicazioni asincrone corrette: Read multiple registers
#2 – Comunicazioni asincrone non corrette
120
Capitolo 10
Risultati
Nei casi descritti, i correlatori delle singole reti non hanno rilevato nessuna anomalia. Il
correlatore globale ha invece rilevato delle comunicazioni non permesse nel secondo caso
di test. In particolare: per il caso #1 ha completato correttamente tutti gli automi, mentre
nel caso #2, alla ricezione del messaggio Write Coils, il correlatore ha rilevato la
comunicazione come non permessa.
Prove
121
Considerazioni finali
Se da una parte le proprietà degli automi a stati finiti permettono di descrivere in maniera
rigorosa i comportamenti del sistema, dall'altra ne conseguono alcune limitazioni. Negli
automi a stati finiti il numero di stati è fissato a priori, ciò non consente di trattare
problemi che richiedono operazioni senza limite fissato, non è quindi possibile gestire
situazioni di non determinismo.
Riportiamo di seguito due esempi: uno in cui il sistema fallisce ed un altro in cui non
è possibile descrivere il caso attraverso l’implementazione degli automi adottata.
Un caso in cui il sistema di correlazione può fallire e non rilevare un possibile
attacco è il seguente: considerando l'automa rappresentato in Figura 62, quando lo stato
attuale dell'automa è in S0, è possibile effettuare due transizioni: una in S1 ed una in S2.
Non è possibile conoscere a priori verso quale dei due stati l'automa effettuerà la
transizione. Un attaccante che ha compromesso l'entità che genera gli eventi A e B, può
evadere i controlli eseguiti dal correlatore forzando il sistema ad effettuare sempre una
transizione piuttosto che l'altra. Questo comportamento anomalo non sarà rilevato dal
correlatore in quanto date le specifiche dell'automa descritto, entrambe le transizioni sono
permesse.
Figura 62: Automa non deterministico.
Una limitazione dovuta all'utilizzo degli automi a stati finiti è descritta di seguito.
Durante la creazione degli automi, non è possibile definire iterazioni con condizione
d'uscita. Un esempio è quando una comunicazione denominata A può essere eseguita n
volte e la comunicazione B deve susseguirsi tante volte quante A. Se A e B sono eseguite in
maniera sequenziale, A1->B1->A2->B2...An->Bn, è possibile descrivere questo
comportamento attraverso l'automa mostrato in Figura 63. Nel caso in cui ad ogni A non
deve necessariamente susseguirsi una B, non è possibile creare un automa che descriva
questo comportamento.
Figura 63: Iterazione.
A.1 Test#1 – Correlatore rete 1
<automa>
<nome>ReadMultipleRegistersAsync</nome>
<expire_time>4</expire_time>
<stati>
<stato>
<tipo>INITIAL</tipo>
<id>0</id>
<nome>S(0)</nome>
<transizioni>
<transizione>
<name>SE</name>
<to>1</to>
<parties>
<source>192.168.3.130</source>
<destination>192.168.3.129</destination>
</parties>
<protocolEvent>
<protocol>Modbus TCP</protocol>
<functionCode>3</functionCode>
<registers></registers>
<starting_address>0</starting_address>
<value></value>
</protocolEvent>
</transizione>
</transizioni>
</stato>
<stato>
<tipo>MIDDLE</tipo>
<id>1</id>
<nome>S(1)</nome>
<transizioni>
<transizione>
<name>ex1</name>
<to>2</to>
<parties>
<source>192.168.3.129</source>
<destination>192.168.3.130</destination>
</parties>
<protocolEvent>
<protocol>Modbus TCP</protocol>
<functionCode>83</functionCode>
<registers></registers>
<starting_address></starting_address>
<value>=1</value>
Appendice
124
</protocolEvent>
</transizione>
<transizione>
<name>ex2</name>
<to>2</to>
<parties>
<source>192.168.3.129</source>
<destination>192.168.3.130</destination>
</parties>
<protocolEvent>
<protocol>Modbus TCP</protocol>
<functionCode>83</functionCode>
<registers></registers>
<starting_address></starting_address>
<value>=2</value>
</protocolEvent>
</transizione>
<transizione>
<name>ex3</name>
<to>2</to>
<parties>
<source>192.168.3.129</source>
<destination>192.168.3.130</destination>
</parties>
<protocolEvent>
<protocol>Modbus TCP</protocol>
<functionCode>83</functionCode>
<registers></registers>
<starting_address></starting_address>
<value>=3</value>
</protocolEvent>
</transizione>
<transizione>
<name>ex4</name>
<to>2</to>
<parties>
<source>192.168.3.129</source>
<destination>192.168.3.130</destination>
</parties>
<protocolEvent>
<protocol>Modbus TCP</protocol>
<functionCode>83</functionCode>
<registers></registers>
<starting_address></starting_address>
<value>=4</value>
</protocolEvent>
</transizione>
<transizione>
<name>F</name>
<to>3</to>
<parties>
<source>192.168.3.129</source>
<destination>192.168.3.130</destination>
</parties>
<protocolEvent>
<protocol>Modbus TCP</protocol>
<functionCode>3</functionCode>
<registers></registers>
<starting_address></starting_address>
<value></value>
</protocolEvent>
</transizione>
</transizioni>
</stato>
<stato>
Appendice
125
<tipo>FINAL</tipo>
<id>2</id>
<nome>S(2)</nome>
<transizioni/>
</stato>
<stato>
<tipo>FINAL</tipo>
<id>3</id>
<nome>S(3)</nome>
<transizioni/>
</stato>
</stati>
</automa>
126
A.2 Test#2 – Correlatore rete 2
<automa>
<nome>ReadMultipleRegisters</nome>
<expire_time>4</expire_time>
<stati>
<stato>
<tipo>INITIAL</tipo>
<id>0</id>
<nome>S(0)</nome>
<transizioni>
<transizione>
<name>SE</name>
<to>1</to>
<parties>
<source>192.168.4.130</source>
<destination>192.168.4.132</destination>
</parties>
<protocolEvent>
<protocol>Modbus TCP</protocol>
<functionCode>3</functionCode>
<registers></registers>
<starting_address>0</starting_address>
<value></value>
</protocolEvent>
</transizione>
</transizioni>
</stato>
<stato>
<tipo>MIDDLE</tipo>
<id>1</id>
<nome>S(1)</nome>
<transizioni>
<transizione>
<name>ex1</name>
<to>2</to>
<parties>
<source>192.168.4.131</source>
<destination>192.168.4.130</destination>
</parties>
<protocolEvent>
<protocol>Modbus TCP</protocol>
<functionCode>83</functionCode>
<registers></registers>
<starting_address></starting_address>
<value>=1</value>
</protocolEvent>
</transizione>
<transizione>
<name>ex2</name>
<to>2</to>
<parties>
<source>192.168.4.131</source>
<destination>192.168.4.130</destination>
</parties>
<protocolEvent>
<protocol>Modbus TCP</protocol>
<functionCode>83</functionCode>
<registers></registers>
<starting_address></starting_address>
<value>=2</value>
</protocolEvent>
</transizione>
<transizione>
Appendice
127
<name>ex3</name>
<to>2</to>
<parties>
<source>192.168.4.131</source>
<destination>192.168.4.130</destination>
</parties>
<protocolEvent>
<protocol>Modbus TCP</protocol>
<functionCode>83</functionCode>
<registers></registers>
<starting_address></starting_address>
<value>=3</value>
</protocolEvent>
</transizione>
<transizione>
<name>ex4</name>
<to>2</to>
<parties>
<source>192.168.4.131</source>
<destination>192.168.4.130</destination>
</parties>
<protocolEvent>
<protocol>Modbus TCP</protocol>
<functionCode>83</functionCode>
<registers></registers>
<starting_address></starting_address>
<value>=4</value>
</protocolEvent>
</transizione>
<transizione>
<name>F</name>
<to>3</to>
<parties>
<source>192.168.4.131</source>
<destination>192.168.4.130</destination>
</parties>
<protocolEvent>
<protocol>Modbus TCP</protocol>
<functionCode>3</functionCode>
<registers></registers>
<starting_address></starting_address>
<value></value>
</protocolEvent>
</transizione>
</transizioni>
</stato>
<stato>
<tipo>FINAL</tipo>
<id>2</id>
<nome>S(2)</nome>
<transizioni/>
</stato>
<stato>
<tipo>FINAL</tipo>
<id>3</id>
<nome>S(3)</nome>
<transizioni/>
</stato>
</stati>
</automa>
128
A.3 Test#3 – Richieste sincrone
<automa>
<nome>ReadMultipleRegistersSync</nome>
<expire_time/>
<stati>
<stato>
<tipo>INITIAL</tipo>
<id>0</id>
<nome>S(0)</nome>
<transizioni>
<transizione>
<name>ST</name>
<to>1</to>
<parties>
<source>192.168.3.130</source>
<destination>192.168.3.129</destination>
</parties>
<protocolEvent>
<protocol>Modbus TCP</protocol>
<functionCode>3</functionCode>
<registers/>
<starting_address>0</starting_address>
<value/>
</protocolEvent>
</transizione>
</transizioni>
</stato>
<stato>
<tipo>MIDDLE</tipo>
<id>1</id>
<nome>S(1)</nome>
<transizioni>
<transizione>
<name>ex1</name>
<to>2</to>
<parties>
<source>192.168.3.129</source>
<destination>192.168.3.130</destination>
</parties>
<protocolEvent>
<protocol>Modbus TCP</protocol>
<functionCode>83</functionCode>
<registers/>
<starting_address/>
<value>=1</value>
</protocolEvent>
</transizione>
<transizione>
<name>ex2</name>
<to>2</to>
<parties>
<source>192.168.3.129</source>
<destination>192.168.3.130</destination>
</parties>
<protocolEvent>
<protocol>Modbus TCP</protocol>
<functionCode>83</functionCode>
<registers/>
<starting_address/>
<value>=2</value>
</protocolEvent>
</transizione>
<transizione>
Appendice
129
<name>ex3</name>
<to>2</to>
<parties>
<source>192.168.3.129</source>
<destination>192.168.3.130</destination>
</parties>
<protocolEvent>
<protocol>Modbus TCP</protocol>
<functionCode>83</functionCode>
<registers/>
<starting_address/>
<value>=3</value>
</protocolEvent>
</transizione>
<transizione>
<name>ex4</name>
<to>2</to>
<parties>
<source>192.168.3.129</source>
<destination>192.168.3.130</destination>
</parties>
<protocolEvent>
<protocol>Modbus TCP</protocol>
<functionCode>83</functionCode>
<registers/>
<starting_address/>
<value>=4</value>
</protocolEvent>
</transizione>
<transizione>
<name>R</name>
<to>3</to>
<parties>
<source>192.168.4.130</source>
<destination>192.168.4.131</destination>
</parties>
<protocolEvent>
<protocol>Modbus TCP</protocol>
<functionCode>3</functionCode>
<registers/>
<starting_address>0</starting_address>
<value/>
</protocolEvent>
</transizione>
</transizioni>
</stato>
<stato>
<tipo>MIDDLE</tipo>
<id>2</id>
<nome>S(2)</nome>
<transizioni/>
</stato>
<stato>
<tipo>MIDDLE</tipo>
<id>3</id>
<nome>S(3)</nome>
<transizioni>
<transizione>
<name>ex12</name>
<to>4</to>
<parties>
<source>192.168.4.131</source>
<destination>192.168.4.130</destination>
</parties>
<protocolEvent>
130
<protocol>Modbus TCP</protocol>
<functionCode>83</functionCode>
<registers/>
<starting_address/>
<value>=1</value>
</protocolEvent>
</transizione>
<transizione>
<name>ex22</name>
<to>4</to>
<parties>
<source>192.168.4.131</source>
<destination>192.168.4.130</destination>
</parties>
<protocolEvent>
<protocol>Modbus TCP</protocol>
<functionCode>83</functionCode>
<registers/>
<starting_address/>
<value>=2</value>
</protocolEvent>
</transizione>
<transizione>
<name>ex32</name>
<to>4</to>
<parties>
<source>192.168.4.131</source>
<destination>192.168.4.130</destination>
</parties>
<protocolEvent>
<protocol>Modbus TCP</protocol>
<functionCode>83</functionCode>
<registers/>
<starting_address/>
<value>=3</value>
</protocolEvent>
</transizione>
<transizione>
<name>ex24</name>
<to>4</to>
<parties>
<source>192.168.4.131</source>
<destination>192.168.4.130</destination>
</parties>
<protocolEvent>
<protocol>Modbus TCP</protocol>
<functionCode>83</functionCode>
<registers/>
<starting_address/>
<value>=4</value>
</protocolEvent>
</transizione>
<transizione>
<name>V</name>
<to>4</to>
<parties>
<source>192.168.4.131</source>
<destination>192.168.4.130</destination>
</parties>
<protocolEvent>
<protocol>Modbus TCP</protocol>
<functionCode>3</functionCode>
<registers/>
<starting_address/>
<value/>
Appendice
131
</protocolEvent>
</transizione>
</transizioni>
</stato>
<stato>
<tipo>MIDDLE</tipo>
<id>4</id>
<nome>S(4)</nome>
<transizioni>
<transizione>
<name>ex13</name>
<to>5</to>
<parties>
<source>192.168.3.129</source>
<destination>192.168.3.130</destination>
</parties>
<protocolEvent>
<protocol>Modbus TCP</protocol>
<functionCode>83</functionCode>
<registers/>
<starting_address/>
<value>=1</value>
</protocolEvent>
</transizione>
<transizione>
<name>ex23</name>
<to>5</to>
<parties>
<source>192.168.3.129</source>
<destination>192.168.3.130</destination>
</parties>
<protocolEvent>
<protocol>Modbus TCP</protocol>
<functionCode>83</functionCode>
<registers/>
<starting_address/>
<value>=2</value>
</protocolEvent>
</transizione>
<transizione>
<name>ex33</name>
<to>5</to>
<parties>
<source>192.168.3.129</source>
<destination>192.168.3.130</destination>
</parties>
<protocolEvent>
<protocol>Modbus TCP</protocol>
<functionCode>83</functionCode>
<registers/>
<starting_address/>
<value>=3</value>
</protocolEvent>
</transizione>
<transizione>
<name>ex43</name>
<to>5</to>
<parties>
<source>192.168.3.129</source>
<destination>192.168.3.130</destination>
</parties>
<protocolEvent>
<protocol>Modbus TCP</protocol>
<functionCode>83</functionCode>
<registers/>
132
<starting_address/>
<value>=4</value>
</protocolEvent>
</transizione>
<transizione>
<name>V2</name>
<to>5</to>
<parties>
<source>192.168.3.129</source>
<destination>192.168.3.130</destination>
</parties>
<protocolEvent>
<protocol>Modbus TCP</protocol>
<functionCode>3</functionCode>
<registers/>
<starting_address>0</starting_address>
<value/>
</protocolEvent>
</transizione>
</transizioni>
</stato>
<stato>
<tipo>MIDDLE</tipo>
<id>5</id>
<nome>S(5)</nome>
<transizioni/>
</stato>
</stati>
</automa>
Appendice
133
A.4 Test#4 – Richieste asincrone
<automa>
<nome>ReadMultipleRegistersAsync</nome>
<expire_time>15</expire_time>
<stati>
<stato>
<tipo>INITIAL</tipo>
<id>0</id>
<nome>S(0)</nome>
<transizioni>
<transizione>
<name>ST</name>
<to>1</to>
<parties>
<source>192.168.3.130</source>
<destination>192.168.3.129</destination>
</parties>
<protocolEvent>
<protocol>Modbus TCP</protocol>
<functionCode>3</functionCode>
<registers/>
<starting_address/>
<value/>
</protocolEvent>
</transizione>
</transizioni>
</stato>
<stato>
<tipo>MIDDLE</tipo>
<id>1</id>
<nome>S(1)</nome>
<transizioni>
<transizione>
<name>Ex11</name>
<to>2</to>
<parties>
<source>192.168.3.129</source>
<destination>192.168.3.130</destination>
</parties>
<protocolEvent>
<protocol>Modbus TCP</protocol>
<functionCode>83</functionCode>
<registers/>
<starting_address/>
<value>=1</value>
</protocolEvent>
</transizione>
<transizione>
<name>Ex21</name>
<to>2</to>
<parties>
<source>192.168.3.129</source>
<destination>192.168.3.130</destination>
</parties>
<protocolEvent>
<protocol>Modbus TCP</protocol>
<functionCode>83</functionCode>
<registers/>
<starting_address/>
<value>=2</value>
</protocolEvent>
</transizione>
<transizione>
134
<name>Ex31</name>
<to>2</to>
<parties>
<source>192.168.3.129</source>
<destination>192.168.3.130</destination>
</parties>
<protocolEvent>
<protocol>Modbus TCP</protocol>
<functionCode>83</functionCode>
<registers/>
<starting_address/>
<value>=3</value>
</protocolEvent>
</transizione>
<transizione>
<name>Ex4</name>
<to>2</to>
<parties>
<source>192.168.3.129</source>
<destination>192.168.3.130</destination>
</parties>
<protocolEvent>
<protocol>Modbus TCP</protocol>
<functionCode>83</functionCode>
<registers/>
<starting_address/>
<value>=4</value>
</protocolEvent>
</transizione>
<transizione>
<name>R1</name>
<to>3</to>
<parties>
<source>192.168.4.130</source>
<destination>192.168.4.131</destination>
</parties>
<protocolEvent>
<protocol>Modbus TCP</protocol>
<functionCode>3</functionCode>
<registers/>
<starting_address/>
<value/>
</protocolEvent>
</transizione>
</transizioni>
</stato>
<stato>
<tipo>MIDDLE</tipo>
<id>2</id>
<nome>S(2)</nome>
<transizioni/>
</stato>
<stato>
<tipo>MIDDLE</tipo>
<id>3</id>
<nome>S(3)</nome>
<transizioni>
<transizione>
<name>Ex12</name>
<to>1</to>
<parties>
<source>192.168.4.131</source>
<destination>192.168.4.130</destination>
</parties>
<protocolEvent>
Appendice
135
<protocol>Modbus TCP</protocol>
<functionCode>83</functionCode>
<registers/>
<starting_address/>
<value>=1</value>
</protocolEvent>
</transizione>
<transizione>
<name>Ex22</name>
<to>1</to>
<parties>
<source>192.168.4.131</source>
<destination>192.168.4.130</destination>
</parties>
<protocolEvent>
<protocol>Modbus TCP</protocol>
<functionCode>83</functionCode>
<registers/>
<starting_address/>
<value>=2</value>
</protocolEvent>
</transizione>
<transizione>
<name>Ex32</name>
<to>1</to>
<parties>
<source>192.168.4.131</source>
<destination>192.168.4.130</destination>
</parties>
<protocolEvent>
<protocol>Modbus TCP</protocol>
<functionCode>83</functionCode>
<registers/>
<starting_address/>
<value>=3</value>
</protocolEvent>
</transizione>
<transizione>
<name>Ex42</name>
<to>1</to>
<parties>
<source>192.168.4.131</source>
<destination>192.168.4.130</destination>
</parties>
<protocolEvent>
<protocol>Modbus TCP</protocol>
<functionCode>83</functionCode>
<registers/>
<starting_address/>
<value>=4</value>
</protocolEvent>
</transizione>
<transizione>
<name>R2</name>
<to>1</to>
<parties>
<source>192.168.4.131</source>
<destination>192.168.4.130</destination>
</parties>
<protocolEvent>
<protocol>Modbus TCP</protocol>
<functionCode>3</functionCode>
<registers/>
<starting_address/>
<value/>
136
</protocolEvent>
</transizione>
<transizione>
<name>R3</name>
<to>4</to>
<parties>
<source>192.168.3.129</source>
<destination>192.168.3.130</destination>
</parties>
<protocolEvent>
<protocol>Modbus TCP</protocol>
<functionCode>3</functionCode>
<registers/>
<starting_address/>
<value/>
</protocolEvent>
</transizione>
<transizione>
<name>Ex13</name>
<to>4</to>
<parties>
<source>192.168.3.129</source>
<destination>192.168.3.130</destination>
</parties>
<protocolEvent>
<protocol>Modbus TCP</protocol>
<functionCode>83</functionCode>
<registers/>
<starting_address/>
<value>=1</value>
</protocolEvent>
</transizione>
<transizione>
<name>Ex23</name>
<to>4</to>
<parties>
<source>192.168.3.129</source>
<destination>192.168.3.130</destination>
</parties>
<protocolEvent>
<protocol>Modbus TCP</protocol>
<functionCode>83</functionCode>
<registers/>
<starting_address/>
<value>=2</value>
</protocolEvent>
</transizione>
<transizione>
<name>Ex33</name>
<to>4</to>
<parties>
<source>192.168.3.129</source>
<destination>192.168.3.130</destination>
</parties>
<protocolEvent>
<protocol>Modbus TCP</protocol>
<functionCode>83</functionCode>
<registers/>
<starting_address/>
<value>=3</value>
</protocolEvent>
</transizione>
<transizione>
<name>Ex43</name>
<to>4</to>
Appendice
137
<parties>
<source>192.168.3.129</source>
<destination>192.168.3.130</destination>
</parties>
<protocolEvent>
<protocol>Modbus TCP</protocol>
<functionCode>83</functionCode>
<registers/>
<starting_address/>
<value>=4</value>
</protocolEvent>
</transizione>
</transizioni>
</stato>
<stato>
<tipo>MIDDLE</tipo>
<id>4</id>
<nome>S(4)</nome>
<transizioni/>
</stato>
</stati>
</automa>
138
A.5 Creazione e configurazione dell’ambiente di test
Per effettuare le prove illustrate nel capitolo 10, è stato necessario simulare sia i
comportamenti delle componenti di un sistema ICS, sia le comunicazioni che avvengono
tra questi. Con l’ausilio del software VMware Workstation, l’ambiente di test è stato
simulato e configurato come segue:
1 IDS che monitora la rete di controllo 1 IDS che monitora la rete di processo 1 macchina virtuale (Modbus master) posta nella rete di controllo, che invia
comandi al Modbus Gateway. 1 macchina (Modbus Gateway) con doppia scheda di rete per comunicare
con i dispositivi di entrambe le reti. Riceve comandi dalla rete di controllo e li invia ai dispositivi presenti nella rete di processo (Modbus slave)
1 macchina nella rete di processo che simula un slave (Modbus Slave)
La configurazione dell’ambiente di test è mostrata in Figura 64:
Figura 64: Ambiente di test.
Il master invia i comandi al Modbus Gateway, il quale in base alla configurazione ed
ai parametri utente, effettua le dovute operazioni nella rete di processo prima di
rispondere al Master.
Per motivi di prestazioni, gli IDS sono installati rispettivamente sulle macchine
Modbus Master e Modbus Gateway. L’IDS1, presente sulla macchina Modbus Master,
monitora la rete di controllo (192.168.3.0/24), mentre l’IDS2 presente sulla macchina
Modbus Gateway, monitora la rete di processo (192.168.4.0/24). Quest’ultima macchina
virtuale è inoltre configurata per permettere l’accesso dall’esterno verso il database
MySQL al suo interno, dove sono memorizzati gli eventi rilevati.
Appendice
139
Di seguito sono descritti i sistemi operativi e i tool utilizzati per la simulazione
dell’intero ambiente:
- Modbus Master:
o OS: Ubuntu 10.04 LTS
o IDS1: Snort 2.9.2 + Barnyard32
o Python 2.6
o Modbus-tk-0. 4 33
- Modbus Gateway:
o OS: Debian 6
o IDS2: Snort 2.9.2 + Barnyard + MySQL 34server (l’installazione e la
configurazione sono descritte nel paragrafo Configurazione IDS – Debian
6.0.5)
o Python 2.6
o Modbus-tk-0. 4
- Modbus Slave
o OS: Backtrack 5
o Python 2.6
o Modbus-tk 0.4
Avvio dei tool per la fase di test
Di seguito sono descritti i comandi da eseguire per avviare i tool ed effettuare un primo
test dell’ambiente.
Nella prima fase dovranno essere avviati i due IDS. Per l’installazione dell’IDS fare
riferimento al paragrafo Configurazione IDS – Debian 6.0.5.
Avvio di Snort e Barnyard sulla macchina Modbus Master (Ubuntu):
snort@ubuntu:~$ sudo /usr/local/snort/bin/snort -u snort -g snort -c /usr/local/snort/etc/snort.conf -i eth1
Codice 4: Avvio Snort in Modbus Master.
32 Barnyard è uno strumento che permette di eliminare da Snort il carico di lavoro dovuto
alla gestione degli output, permettendo a Snort di occuparsi solo dell’analisi della rete. 33 Modbus-tk: strumento che permette di creare comunicazioni con protocollo Modbus TCP e
RTU 34 MySql: software per la gestione dei database relazionali
140
snort@ubuntu:~$ sudo /usr/local/bin/barnyard2 -c /usr/local/snort/etc/barnyard2.conf -G /usr/local/snort/etc/gen-msg.map -S /home/snort/Desktop/modbus_rules.map -d /var/log/snort -f snort.u2 -w /var/log/snort/barnyard2.waldo
Codice 5: Avvio Barnyard in Modbus Master.
Avvio di Snort e Barnyard sulla macchina Modbus Gateway (debian):
Avvio di Snort snort@snort:~$ sudo /usr/local/bin/snort -u snort -g snort -c /etc/snort/snort.conf -i eth1
Codice 6: Avvio Snort in Modbus Gateway.
Avvio di Baryard snort@snort:~$ sudo /usr/local/bin/barnyard2 -c /etc/snort/barnyard2.conf -d /var/log/snort -f snort.log -w /etc/snort/bylog.waldo -G /etc/snort/gen-msg.map -S /etc/snort/sid-msg.map -C /etc/snort/classification.config
Codice 7: Avvio Barnyard in Modbus Gateway.
Dopo aver avviato gli IDS sulle rispettive macchine, è necessario avviare i master e
gli slave Modbus:
Legenda
testo: input dell’utente testo: output del programma
Avvio dello slave sulla macchina Modbus Slave (Backtrack - 192.168.4.131):
root@bt:~/Desktop$ python tcpslave_exampl.py enter the IP address 192.168.4.131 running... commands: 'start' | start the slave 'quit' | stop the slave 'add_slave' | add a slave (es: add_slave 1) 'set_value' | set slave values (id name address values start listening...
Codice 8: Avvio slave – Backtrack.
Appendice
141
Avvio dello slave sulla macchina Modbus Gateway (192.168.3.129):
snort@snort:~/Scrivania$ python tcpslave_exampl.py enter the IP address 192.168.4.129 running... commands: 'start' | start the slave 'quit' | stop the slave 'add_slave' | add a slave (es: add_slave 1) 'set_value' | set slave values (id name address values start listening...
Codice 9: Avvio Slave – Debian.
Dopo aver avviato entrambi gli slave, è possibile avviare i master e iniziare le
comunicazioni Modbus.
Avvio del master sulla macchina Modbus Master (Ubuntu) e invio della
prima comunicazione:
root@ubuntu:/home/snort/Desktop# python tcpmaster_example.py Enter the slave IP address 192.168.3.129 2012-06-30 11:17:11,507 INFO tcpmaster_example.<module> MainThread connected Select the modbus request: 0) Read coils 1) Read discrete inputs 2) Read input registers 3) Read Holding registers 4) Write single coil 5) Write single register 6) Write multiple coils 7) Write multiple registers 3
Codice 10: Avvio master – Debian.
Dopo aver avviato il programma ed aver inserito l’indirizzo IP dello slave al quale
inviare la comunicazione (Modbus gateway) , lo slave e il master sono connessi. Lo slave
riceve la richiesta Modbus (Read Holding Registers di default) ed attende l’input da parte
dell’utente. L’utente può decidere se lo slave debba rispondere in maniera corretta o
meno.
142
Modbus Gateway – slave
Listening... ('192.168.3.130', 58608) is connected with socket 4... The slave asked for function code -> 3 Insert the mb function ->
Codice 11: Slave connesso e in attesa.
Nel seguito, prima di rispondere al master, invieremo la stessa richiesta nella
seconda rete. Questa operazione ci permette di simulare il comportamento di un PLC, il
quale alla ricezione di un comando, invia lo stesso allo slave corretto presente nella rete di
processo. A seconda della richiesta che verrà inviata allo slave, è possibile simulare sia un
PLC che invia comandi in maniera corretta, sia un PLC corrotto che invia comandi diversi.
Nel seguito sono illustrati i comandi che permettono di simulare un processo
completamente corretto. In questo caso invieremo allo slave della rete di processo lo
stesso comando ricevuto (Read Holding Registers). È quindi necessario avviare il lo
strumento tcpmaster_example.py sul Modbus gateway ed inviare il comando allo slave:
snort@snort:/home/snort/Scrivania# python tcpmaster_example.py Enter the slave IP address 192.168.3.129 2012-06-25 19:28:44,208 INFO tcpmaster_example.<module> MainThread connected Select the modbus request: 0) Read coils 1) Read discrete inputs 2) Read input registers 3) Read Holding registers 4) Write single coil 5) Write single register 6) Write multiple coils 7) Write multiple registers 3
Codice 12: Avvio master sul Gateway Modbus e invio comando.
Lo slave della rete di processo riceve la richiesta e attende l’input da parte
dell’utente per rispondere.
Appendice
143
Volendo simulare un processo corretto, inseriremo il function code corretto: 3
Listening... ('192.168.4.131', 45650) is connected with socket 4... The slave asked for function code -> 3 Insert the mb function 3 4 is disconnected
Codice 13: Risposta slave della rete di processo.
Dopo aver inserito il codice della funzione Modbus, il master riceve i valori e la
comunicazione viene chiusa. Per concludere il processo è necessario ripetere lo stesso
procedimento per il primo slave (Modbus Gateway):
Modbus Gateway (Master) – Risposta dello slave con valori (1,2,3) 2012-07-01 11:09:42,004 INFO tcpmaster_example.<module> MainThread (1, 2, 3)
Codice 14: Risposta slave della rete di controllo.
Una volta inviata la risposta al Modbus Master, l’intero processo è concluso. Con gli
esempio di codice descritti in precedenza, è stato simulato un processo nel quale una
stazione HMI (Modbus Master) invia al PLC (Modbus Gateway) una comunicazione
richiedendo lo stato dello slave presente nella rete di processo. Il PLC inoltra la richiesta
allo slave (Modbus Slave) e restituisce i valori all’HMI.
Configurazione IDS – Debian 6.0.5
Nel seguito sono illustrati i passaggi da eseguire per l’installazione e la configurazione
dell’IDS su macchina Debian.
Installazione dei software base
Aggiornamento dei package:
# gedit /etc/apt/sources.list
Aggiungere le seguenti righe al file:
# deb http://packages.dotdeb.org squeeze all # deb-src http://packages.dotdeb.org squeeze all
144
Installare i pacchetti con il seguente commando (nota: alcuni di questi richiedono
degli input. Ad esempio MySQL richiede di inserire username e password. Nella nostra
configurazione useremo username: root e password: snort)
# apt-get update # apt-get install apache2 apache2-doc autoconf automake bison ca-certificates ethtool flex g++ gcc gcc-4.4 libapache2-mod-php5 libcrypt-ssleay-perl libmysqlclient-dev libnet1 libnet1-dev libpcre3 libpcre3-dev libphp-adodb libssl-dev libtool libwww-perl make mysql-client mysql-common mysql-server ntp php5-cli php5-gd php5-mysql php-pear
Installazione prerequisiti per snort
1) Installazione libpcap:
# cd /usr/src && wget http://www.tcpdump.org/release/libpcap-1.2.1.tar.gz # tar -zxf libpcap-1.2.1.tar.gz && cd libpcap-1.2.1 # ./configure --prefix=/usr --enable-shared && make && make install
2) Installazione libdnet:
# cd /usr/src && wget http://libdnet.googlecode.com/files/libdnet-1.12.tgz # tar -zxf libdnet-1.12.tgz && cd libdnet-1.12 # ./configure --prefix=/usr --enable-shared && make && make install
3) installazione daq e update delle librerie condivise:
# cd /usr/src && wget http://www.snort.org/dl/snort-current/daq-0.6.2.tar.gz
# tar -zxf daq-0.6.2.tar.gz && cd daq-0.6.2 # ./configure && make && make install # echo >> /etc/ld.so.conf /usr/lib && ldconfig
Installazione, configurazione e test di Snort
# cd /usr/src && wget http://labs.snort.org/snort/2923/snort.conf # wget http://www.snort.org/dl/snort-current/snort-2.9.2.3.tar.gz -O snort-
2.9.2.3.tar.gz # tar -zxf snort-2.9.2.3.tar.gz && cd snort-2.9.2.3 # ./configure --enable-sourcefire && make && make install # mkdir /etc/snort /etc/snort/rules /var/log/snort /var/log/barnyard2
/usr/local/lib/snort_dynamicrules # touch /etc/snort/rules/white_list.rules /etc/snort/rules/black_list.rules # groupadd snort && useradd -g snort snort # chown snort:snort /var/log/snort /var/log/barnyard2 # cp /usr/src/snort-2.9.2.3/etc/*.conf* /etc/snort # cp /usr/src/snort-2.9.2.3/etc/*.map /etc/snort
# cp /usr/src/snort.conf /etc/snort
Appendice
145
Eseguire il commando
# gedit /etc/snort/snort.conf
e modificare il file come segue
1. ipvar HOME_NET 172.26.12.0/22 <-- rete permessa 2. var RULE_PATH ./rules 3. var WHITE_LIST_PATH ./rules <-- cambiare path 4. var BLACK_LIST_PATH ./rules <-- cambiare path 5. Aggiungere "max_gzip_mem 104857600" dopo la scritta “decompress_depth
65535” 6. Aggiungere alla fine del file "output unified2: filename snort.log, limit 128" 7. Cancellare o commentare le regole snort che non servono (“include
$RULE_PATH”) ad eccezione “local.rules”
Modificare il file delle regole di Snort
# gedit /etc/snort/rules/local.rules
inserire la seguente regola:
alert icmp any any -> $HOME_NET any (msg:"ICMP test"; sid:10000001;)
È ora possibile avviare Snort con il seguente comando:
# /usr/local/bin/snort -A console -q -u snort -g snort -c /etc/snort/snort.conf -i eth1
Per testare il corretto funzionamento dello strumento, avviare un ping verso la
macchina che ospita Snort. Alert simili a quello mostrati di seguito indicano che lo
strumento funziona correttamente:
02/09-11:29:43.450236 [**] [1:10000001:0] ICMP test [**] [Priority: 0] {ICMP} 172.26.12.1 -> 172.26.12.2
02/09-11:29:43.450251 [**] [1:10000001:0] ICMP test [**] [Priority: 0] {ICMP} 172.26.12.2 -> 172.26.12.1
Configurazione del database in MySQL
Eseguire i seguenti comandi (nota: sostituire id_sensore con un valore numerico per il
rispettivo IDS):
# mysql -u root -p # mysql> create database snort[id_sensore]; # mysql> GRANT ALL PRIVILEGES ON *.* TO root@IP_ADDRESS IDENTIFIED
BY 'password_di_root' WITH GRANT OPTION; # mysql> use snort[id_sensore]; # mysql> source /home/create_mysql (il file deve essere copiato dall'ids -
"/usr/src/snort-2.9.2.3/schemas/create_mysql")
146
Dopo aver creato il database è necessario modificare il tipo del campo timestamp
nella tabella event portandolo da TIMESTAMP a VARCHAR(50).
Il seguente commando serve per testare il funzionamento della connessione al
database:
# mysql -u root –h ip_server_mysql –p
Configurazione MySQL server
I seguenti comandi illustrano come configurare gli accessi dall’esterno verso il database.
Questa configurazione deve essere eseguita solo sulla macchina che ospita i database degli
eventi.
1) aprire e modificare il file di configurazione:
#gedit /etc/my.cnf
Modificare l’indirizzo ip della variabile bind-address e commentare la riga skip-networking. Il file deve essere simile al seguente:
[mysqld] user = mysql pid-file = /var/run/mysqld/mysqld.pid socket = /var/run/mysqld/mysqld.sock port = 3306 basedir = /usr datadir = /var/lib/mysql tmpdir = /tmp language = /usr/share/mysql/English bind-address = 65.55.55.2 #<-- ip address dove si intende ascoltare la
connessione # skip-networking
2) Riavviare il servizio
# /etc/init.d/mysql restart
3) Collegarsi al DB e configurare i privilegi per l’accesso dall’esterno
mysql>> GRANT ALL ON *.* TO root@'%' IDENTIFIED BY 'password_di_root'; mysql>> FLUSH PRIVILEGES;
4) Aprire le porte sulla macchina
# /sbin/iptables -A INPUT -i eth1 -s [IP_Sorgente] -p tcp --destination-port 3306 -j ACCEPT
Appendice
147
Cancellare il database
Nel caso si vogliano eliminare tutti gli eventi presenti nel database, eseguire le seguenti
query:
DELETE FROM data; DELETE FROM event; DELETE FROM icmphdr; DELETE FROM iphdr; DELETE FROM opt; DELETE FROM tcphdr; DELETE FROM udphdr; DELETE FROM signature; DELETE FROM sig_class; DELETE FROM sig_reference; DELETE FROM reference; DELETE FROM reference_system; DELETE FROM acid_event; DELETE FROM acid_ip_cache;
Installazione e configurazione di Barnyard
1) Eseguire i seguenti comandi:
# cd /usr/src && wget https://nodeload.github.com/firnsy/barnyard2/tarball/master -O firnsy-barnyard2-v2-1.10-beta2-6.tar.gz
# tar -zxf firnsy-barnyard2-v2-1.10-beta2-6.tar.gz && cd firnsy-barnyard2-c8e30b8
2) Modificare il file /usr/src/firnsy-barnyard- c8e30b8/src/output-
plugins/spo.database.c dalla riga 1298 alla riga 1301 con le seguenti:
if(timestamp_string!=NULL && strlen(timestamp_string)>20) { timestamp_string[19] = '.'; } if(timestamp_string!=NULL && strlen(timestamp_string)>24) { timestamp_string[23] = '\0'; }
4) eseguire i comandi seguenti per compilare Barnyard:
# autoreconf -fvi -I ./m4 && ./configure --with-mysql && make && make install # mv /usr/local/etc/barnyard2.conf /etc/snort
5) Modificare il file di configurazione:
# gedit /etc/snort/barnyard2.conf
148
6) Cambiare la riga 215 in:
output alert_fast
7) Aggiungere la seguente riga
output database: log, mysql, user=root password=snort dbname=snort[id_sensore] host=IP_MYSQL_SERVER
Avvio di Snort e Barnyard
Il comando per avviare Snort è il seguente
# /usr/local/bin/snort -u snort -g snort -c /etc/snort/snort.conf -i eth1
Il comando per avviare Barnyard è il seguente
# /usr/local/bin/barnyard2 -c /etc/snort/barnyard2.conf -d /var/log/snort -f snort.log -w /etc/snort/bylog.waldo -G /etc/snort/gen-msg.map -S /etc/snort/sid-msg.map -C /etc/snort/classification.config
Configurazione regole per Modbus
Per rilevare tutte le comunicazioni Modbus è necessario inserire una sola regola nel file
local.rules:
#gedit /etc/snort/rules/local.rules
Dipendentemente dai dispositivi che si vogliono monitorare bisogna modificare gli
indirizzi IP della regola seguente. Nel nostro ambiente di test vogliamo monitorare tutte le
comunicazioni tra il Modbus Gateway (192.168.4.130) e lo Slave associato
(192.168.4.131). La regola sarà così definita:
alert tcp 192.168.4.130 any <> 192.168.4.131 502 (content:"|0000|"; depth:2; offset:2;msg:”Modbus TCP Communication on Port 502″; sid:100001; gid:100001)
1. Andrea Carcano, Igor Nai Fovino e Marcelo Masera. Scada Malware, a Proof of
Concept. [Online] 2009.
2. Dondossola, Giovanna, et al., et al. Effects of intentional threats to power
substation control system. International Journal of Critical Infrastructure (IJCIS). 2008. Vol.
4, 1/2.
3. Nai Fovino, Igor, Masera, Marcelo e Leszczyna, Rafal. ICT Security Assessment
of a Power Plant, a Case Study. International Conference on Critical Infrastructure
Protection. George Manson University, Arlington, USA : s.n., 2008.
4. Stouffer, Keith, Falco, Joe e Scarfone, Karen . Guide to Industrial Control
Systems (ICS) Security. http://csrc.nist.gov. [Online] Giugno 2011. [Riportato: 21 Luglio
2012.] http://csrc.nist.gov/publications/nistpubs/800-82/SP800-82-final.pdf.
5. Bimbo, Stefano e Colaiacovo, Enrico. Sistemi SCADA. s.l. : Apogeo, 2006. 88-503-
1042-0.
6. Difference between DCS & SCADA. scadaperspective. [Online] 17 Febbraio 2008.
http://scadaperspective.com/pipermail/scada_scadaperspective.com/2008-
February/000061.html.
7. SCADA vs DCS. INET. [Online] Luglio 1997.
http://members.iinet.net.au/~ianw/archive/x4371.htm.
8. Krutz, Ronald L. Securing SCADA Systems. Indiana : Wiley Publishing, Inc., 2006.
0-7645-9787-6.
9. Berge, Jonas. Fieldbuses for Process Control: Engineering, Operation, and
Maintenance. 2002.
10. The IAONA Handbook for Network Security. www.IAONA.org. [Online] 2003.
www.IAONA.org.
11. Modbus-IDA. Modbus Application Protocol Specification. 28 Dicembre 2006.
12. —. Modbus Messaging on TCP/IP Implementation Guide. 26 Ottobre 2006.
13. —. Object Messaging Specification for the MODBUS TCP/IP Protocol. 08 Novembre
2004.
Bibliografia
150
14. Clarke, Gordon, et al., et al. Practical Modern SCADA Protocols:DNP3, 60870.5
and Related Systems. s.l. : Elsevier, 2004. ISBN 07506 7995.
15. www.acsac.org/2005/techblitz/majdalawieh.pdf. [Online] 19 12 2005.
[Riportato: 1 Agosto 2012.] www.acsac.org/2005/techblitz/majdalawieh.pdf.
16. Nutzerorganisation, PROFIBUS. Profibus System Description - Technology and
Application. Dicembre 2010.
17. —. System Description. Ottobre 2002.
18. Muller, Andreas. Event Correlation Engine. 2009. p. 29-31.
19. Glossario. http://www.infolandsys.com. [Online] [Riportato: 22 Luglio 2012.]
http://www.infolandsys.com/glossario.html.
Figura 1: PLC Siemens. ............................................................................................................................... 15
Figura 2: Controllo ciclico di un sistema SCADA........................................................................... 15
Figura 3: HMI ................................................................................................................................................... 16
Figura 4: Operazioni base di un sistema ICS. .................................................................................. 17
Figura 5: Sistema di controllo del traffico ferroviario. .............................................................. 26
Figura 6: Generazione di energia elettrica e distribuzione geografica. ............................ 27
Figura 7: Tipica centrale elettrica a combustione fossile......................................................... 28
Figura 8: Impianto di controllo dei componenti ........................................................................... 30
Figura 9: Configurazione classica di un sistema SCADA. .......................................................... 32
Figura 10: Topologie di una comunicazione SCADA. .................................................................. 33
Figura 11: Topologia SCADA molto estesi. ....................................................................................... 33
Figura 12: Esempio di SCADA per monitoraggio e controllo decentralizzato............... 34
Figura 13: Esempio di SCADA per la gestione del traffico ferroviario. ............................. 35
Figura 14: Implementazione di un sistema DCS. .......................................................................... 36
Figura 15: Esempio d’imlementazione di un PLC. ....................................................................... 37
Figura 16: Applicazione tipica di un firewall. ................................................................................. 43
Figura 17: DMZ a singolo firewall......................................................................................................... 45
Figura 18: DMZ a doppio firewall. ........................................................................................................ 46
Figura 19: Livelli del modello ISO/OSI. ............................................................................................. 50
Figura 20: ISO/OSI Incapsulamento.................................................................................................... 51
Figura 21: Livelli del modello TCP/IP. ............................................................................................... 53
Figura 22: Livelli di comunicazione MODBUS................................................................................ 55
Figura 23: Scambio dati DNP3 TCP/IP............................................................................................... 56
Figura 24: Struttura frame DNP3 (15). .............................................................................................. 56
Figura 25: Livelli e protocolli Profibus FMS, DP e PA................................................................. 58
Figura 26: Architettura SCADA v1........................................................................................................ 62
Figura 27: Architettura SCADA v2........................................................................................................ 63
Figura 28: MITM es. 1. ................................................................................................................................ 65
Figura 29: MITM es. 2. ................................................................................................................................ 66
Figura 30: Correlazione distribuita. .................................................................................................... 68
Figura 31: Correlazione centralizzata ................................................................................................ 68
Figura 32: Correlazione ibrida. .............................................................................................................. 68
Figura 33: Comunicazioni rete locale. ................................................................................................ 72
Figura 34: Correlatore sistemi ICS. ...................................................................................................... 74
Figura 35: Diagramma di stati con stringhe che finiscono in 01. ......................................... 76
Figura 36: Esempio di transizioni. ....................................................................................................... 76
Indice delle figure
152
Figura 37: Comando apertura valvola. ............................................................................................... 77
Figura 38: Diagramma di stato - Apertura valvola ...................................................................... 79
Figura 39: Comando Apri valvola ......................................................................................................... 80
Figura 40: Comando Leggi valore ......................................................................................................... 80
Figura 41: Diagramma di stato - Apri valvola................................................................................. 81
Figura 42: Diagramma di stato - Lettura valvola .......................................................................... 81
Figura 43: Flusso eventi apertura e lettura valvola (sequenziale) ...................................... 81
Figura 44: Flusso eventi apertura e lettura valvola (asincrono) .......................................... 82
Figura 45: Apertura valvola compromesso ..................................................................................... 83
Figura 46: Diagramma di stato - Apri valvola................................................................................. 83
Figura 47: Apertura valvola con più correlatori ........................................................................... 85
Figura 48: Automa correlatore SCADA .............................................................................................. 86
Figura 49: Automa correlatore Campo .............................................................................................. 86
Figura 50: automa correlatore ICS ....................................................................................................... 86
Figura 51: PLC corrotto .............................................................................................................................. 87
Figura 52: Correlatore ICS con più reti da monitorare .............................................................. 89
Figura 53: Informazioni estratte dal report. ................................................................................... 92
Figura 54: Definizione regole di comunicazione. ......................................................................... 93
Figura 55: Configurazione protocolli. ................................................................................................. 94
Figura 56: Automi generati automaticamente. .............................................................................. 95
Figura 57: Creazione manuale di automi .......................................................................................... 96
Figura 58: Visualizzazione dell'automa creato. ............................................................................. 96
Figura 59: Elementi chiave del processo di correlazione......................................................... 97
Figura 60: Contesto applicativo di SEC . ............................................................................................ 98
Figura 61: Topologia ambiente di test. ........................................................................................... 101
Figura 62: Automa non deterministico. .......................................................................................... 121
Figura 63: Iterazione. ............................................................................................................................... 121
Figura 64: Ambiente di test................................................................................................................... 138
Tabella 1: Linee guida IAONA sui servizi di rete SCADA. ......................................................... 47
Tabella 2: Protocolli SCADA. ................................................................................................................... 49
Tabella 3 Descrizione dei sette livelli del modello ISO/OSI. ................................................... 52
Tabella 4 Descrizione dei livelli TCP/IP. ........................................................................................... 53
Tabella 5: Flusso delle comunicazioni descritte in Figura 26. ............................................... 62
Tabella 6: Lista eventi generati .............................................................................................................. 78
Tabella 7: Tabella delle transizioni. ..................................................................................................... 79
Tabella 8: Lista degli eventi generati. ................................................................................................. 80
Tabella 9: Flusso eventi correlatore .................................................................................................... 89
Tabella 10: Flusso eventi correlatore con ritardi di comunicazione .................................. 90
Indice delle tabelle
