Definizione di scenari di attacco ai sistemi SCADA e Infrastruttura di Laboratorio

Transcript

1 Definizione di scenari di attacco ai sistemi SCADA e Infrastruttura di Laboratorio G. Dondossola, F. Garrone, J. Szanto Febbraio 2010 Area: Governo, Gestione e Sviluppo del Sistema Elettrico Nazionale

2 Rapporto SSE Sviluppo dei Sistemi Elettrici Pag. 1/70 Contratto Accordo di programma con il Ministero dello Sviluppo Economico per le attività di ricerca e sviluppo di interesse generale per il sistema elettrico nazionale. Piano Annuale di realizzazione Oggetto Definizione di scenari di attacco ai sistemi SCADA e Infrastruttura di Laboratorio Progetto Linea di Ricerca Deliverable Note Studi sullo sviluppo del sistema elettrico e della rete elettrica nazionale Sicurezza delle infrastrutture del sistema elettrico 18 PUBBLICATO (PAD ) La parziale riproduzione di questo documento è permessa solo con l'autorizzazione scritta di ERSE. N. pagine 70 N. pagine fuori testo 0 Mod. RPRDS v. 04 Data 28/02/2010 Elaborato Elaborato Verificato Verificato SSE G. Dondossola, F. Garrone Consulente Dondossola esterna Giovanna J. (SSE), Szanto Garrone Fabrizio (SSE) AUT AUT SSE Consulente D. Cirio esterna - J. Szanto Cirio Diego (SSE) VER Approvato SSE Cherbaucich M. Gallanti Claudio (TTD), Gallanti Massimo (SSE) APP APP TTD C. Cherbaucich ENEA Ricerca sul Sistema Elettrico S.p.A. via R. Rubattino, Milano - Italia Tel Fax Capitale sociale Euro i.v. R.I. di Milano, C.F. e P.IVA , N. R.E.A ISO 9001 CH-32919

3 Rapporto SSE Sviluppo dei Sistemi Elettrici Pag. 2/70 Indice SOMMARIO... 5 Acronimi INTRODUZIONE ARCHITETTURA TESTBED Funzioni di comunicazione Simulazione di un attacco DoS FRAMEWORK DI VALUTAZIONE Misure puntuali sulla singola prova e relativi grafici Misure medie sulla singola prova Valutazione sperimentale ricerca e sviluppo COMUNICAZIONI IEC TRAMITE VPN IPSEC IPsec Cisco IPsec StrongSwan Prove IEC con IPSEC Conclusioni COMUNICAZIONI RIDONDATE Hot Standby Router Protocol Conclusioni ATTACCHI DOS Taratura del tool di attacco Prove DoS Cisco Prove DoS Linux Conclusioni CONTROMISURE DOS CISCO Hot Standby Router Protocol Intrusion Prevention System Vulnerabilità di Cisco IPS Conclusioni INTRUSIONI Processo di intrusione Intrusioni e modellazione UCD Conclusioni CONCLUSIONI BIBLIOGRAFIA Copyright 2010 by ERSE. All rights reserved - Activity code

4 Rapporto SSE Sviluppo dei Sistemi Elettrici Pag. 3/70 Indice delle Figure Figura 1: Laboratorio per l analisi degli attacchi informatici Figura 2: Ciclo di Gestione del Rischio e Valutazione Sperimentale Figura 3: Infrastrutture ICT del Sistema Elettrico Figura 4: Architettura Testbed per l analisi degli attacchi informatici Figura 5: Struttura indirizzo Nodo Figura 6: Flusso comunicazioni Centro Stazioni Figura 7: Implementazione comunicazioni Centro-Stazioni nel Testbed Figura 8: IEC Utilizzo del timer t3 test ok (fonte [3]) Figura 9: IEC Utilizzo del timer t3 test not-ok (fonte [3]) Figura 10: Schema semplificato di un processo di attacco DoS distribuito Figura 11: Interfaccia ATTACK Manager Figura 12: Interfaccia ATTACK Client Figura 13: Schema attacco DoS distribuito Figura 14: Configurazione dell ATTACK Manager Figura 15: File di log attività modulo P104Client Figura 16: File di log attività modulo P104Server Figura 17: Interfaccia Tool CS_Assess_Centre Figura 18: Grafico Misure Temporali condizione normale (sx) - condizione attacco DoS (dx) Figura 19. Grafico Misure adimensionali condizione normale (sx) condizione attacco DoS (dx) Figura 20: Grafico Riassuntivo Misure condizione normale (sx) condizione attacco DoS (dx) Figura 21: Grafico Misure Medie Figura 22: modello SWN per l analisi della procedura di emergenza fonte [13] Figura 23: Inizializzazione IEC in chiaro Figura 24: Configurazione Cisco IPsec Policies via SDM Figura 25: Configurazione Cisco IPsec IKE via SDM Figura 26: Configurazione Cisco IPsec ACL via SDM Figura 27: Traffico IPsec - sessione iniziale Figura 28: Traffico IPsec - sessione di rigenerazione chiavi Figura 29: Gateway Linux - IPtables Figura 30: Gateway Linux - File configurazione ipsec.conf Figura 31: Grafico misure IMT Stazione 1 in situazione di funzionamento normale Figura 32: Grafico misure IMT Stazione 2 in situazione di funzionamento normale Figura 33: Dettaglio configurazione collegamento ridondato Centro-Stazione Figura 34: Grafico IMT durante test HSRP (t3 = 20 sec) Figura 35: Grafico riassuntivo misure durante test HSRP (t3 = 20 sec) Figura 36: Grafico misure durante test2 HSRP (t3 = 20 sec) Figura 37: Grafico IMT durante test HSRP (t3 = 30 sec) Figura 38: Grafico misure durante test HSRP (t3 = 30 sec) Figura 39: Consumo di Banda vs. Frequenza Attacco Figura 40: Configurazione router primario di Centro Figura 41: Configurazione Accessi Interfaccia di Manutenzione Figura 42: Log segnalazioni eventi durante attacco all interfaccia di manutenzione di un router Figura 43: DoS Router Cisco - 3 Attaccanti: Number of Lost Messages Figura 44: DoS Router Cisco - 3 Attaccanti: Inter Message Time Figura 45: DoS Router Cisco - 3 Attaccanti T3 = 20 sec: Percentage of Lost Messages Figura 46: DoS Router Cisco - 3 Attaccanti- T3 = 30 sec: Percentage of Lost Messages Figura 47: DoS Router Cisco Attaccanti T3 = 20 sec: Percentage of Lost Messages Figura 48: DoS Router Cisco Attaccanti T3 = 30 sec: Percentage of Lost Messages Figura 49: Round Trip Time in presenza di attacco DoS Figura 50: DoS Gateway-1 Linux 3 attaccanti: Misure riassuntive Figura 51: DoS Gateway Linux-2 3 attaccanti: Misure riassuntive

5 Rapporto SSE Sviluppo dei Sistemi Elettrici Pag. 4/70 Figura 52: DoS Router Cisco seguito da indisponibilità fisica: Misure riassuntive Figura 53: Elaborazione dei pacchetti che fluiscono dall esterno all interno della rete (fonte [15]) Figura 54: Configurazione router secondario di Centro Figura 55: Configurazione IPS Figura 56: Log segnalazioni eventi durante attacco interfaccia di manutenzione di un router con IPS Figura 57: DoS Router Cisco IPS produce-alert: Misure riassuntive Figura 58: Configurazione Firma Figura 59: DoS Router Cisco IPS drop-packet: Misure riassuntive Figura 60: Log segnalazioni eventi IPS Firma Figura 61: Effetto flooding https Figura 62: Scenario di Intrusione Indice delle Tabelle Tabella 1: Relazioni tra i parametri dei due Framework Tabella 2: Configurazione Protocollo Tabella 3: Comunicazioni HSRP in presenza di anomalia fisica del link di comunicazione Tabella 4: Elenco test prova HSRP Tabella 5: Test per taratura tool attacco Pulsed Tabella 6: Test DoS Comunicazioni IEC

6 Rapporto SSE Sviluppo dei Sistemi Elettrici Pag. 5/70 STORIA DELLE REVISIONI Numero Data Protocollo Lista delle modifiche e/o dei paragrafi modificati revisione 00 28/02/ Prima emissione SOMMARIO Il presente Rapporto è parte integrante della documentazione delle attività di Ricerca di Sistema previste dal Piano Annuale di Realizzazione 2009 nell ambito del progetto STUDI SULLO SVILUPPO DEL SISTEMA ELETTRICO E DELLA RETE ELETTRICA NAZIONALE (Area Governo, gestione e sviluppo del sistema elettrico nazionale ) e ne costituisce il Deliverable 18. La sicurezza delle reti informatiche impiegate nel controllo di processo costituisce, allo stato tecnologico attuale, un interessante argomento di studio e ricerca tecnico-scientifica. L attività AdP sulla sicurezza informatica nel controllo elettrico si pone come obiettivo la valutazione sperimentale degli effetti dei processi di attacco sui sistemi di automazione e controllo delle reti elettriche. L attività di valutazione sperimentale, inserita nel Ciclo complessivo di Gestione del Rischio, si articola in diverse fasi quali la pianificazione, la predisposizione ed esecuzione di esperimenti, seguita dalla archiviazione ed elaborazione dei dati sperimentali. Per l esecuzione degli esperimenti il Laboratorio PCS-ResTest mette a disposizione un architettura di controllo della rete elettrica di distribuzione, peculiare nella sua capacità di riprodurre sistemi SCADA scalabili in funzione di Centri, Stazioni e IED di Automazione. L architettura del Laboratorio si propone come piattaforma di prova, estendibile e configurabile, su cui effettuare esperimenti controllati per la raccolta di dati relativi ad attacchi informatici ai sistemi di controllo. L attività sperimentale si concentra sulle caratteristiche e i requisiti delle comunicazioni tipiche dei sistemi SCADA impiegati nei diversi livelli di regolazione e controllo elettrico, quali disponibilità continua, brevi tempi di risposta, limitati ritardi di trasmissione, correttezza dei flussi di dati, assenza di dati spuri e di perdite di dati. L elaborazione dei dati raccolti dagli esperimenti del Laboratorio si avvale di un apposito framework metodologico caratterizzato da un insieme di misure relative alle comunicazioni standard. Secondo quanto previsto dal ciclo di sviluppo degli esperimenti, l attività PAR 2009 ha prodotto un Testbed e un Framework di valutazione di supporto per l esecuzione e la valutazione di un insieme pianificato di esperimenti. Il Testbed 2009 costituisce un evoluzione fisica, funzionale e logica del testbed pre-esistente, al quale sono stati aggiunti i seguenti moduli: nuova versione del protocollo standard IEC , con funzionalità di test della connessione; connessione Centro-Stazione tramite router Cisco ridondati e dotati di funzionalità di sicurezza quali IPsec e IPS; Centro di Manutenzione ICT; strumenti per la ripetibilità degli attacchi. Il Framework di valutazione 2009 è dotato di strumenti funzionali alla elaborazione e visualizzazione di un insieme di misure puntuali e medie relative ai tempi delle ricezioni, delle riconnessioni, alle congestioni e alle perdite di messaggi applicativi. Gli sviluppi software dell attività PAR 2009, inclusi nel Testbed e nel Framework di Valutazione, hanno consentito di effettuare e valutare le seguenti campagne di prove: a. Prove di valutazione funzionale delle comunicazioni standard IEC messe in sicurezza dai protocolli IPsec;

7 Rapporto SSE Sviluppo dei Sistemi Elettrici Pag. 6/70 b. Prove di valutazione della gestione automatica delle anomalie fisiche tramite protocollo HSRP; c. Prove di valutazione degli attacchi DoS verso router Cisco e Gateway Linux; d. Prove di valutazione delle contromisure di difesa dagli attacchi DoS; e. Prove di intrusione. L analisi dei risultati delle prove tramite il Framework di Valutazione ha permesso di quantificare l effetto delle anomalie delle comunicazioni sul Testbed, e di ricavare utili considerazioni e raccomandazioni di carattere più generale, riportate nel documento. I dati e la documentazione delle prove effettuate sono disponibili negli archivi del Laboratorio ERSE. Infine si ricorda che nel periodo di riferimento sono state finalizzate le attività del progetto Europeo CRUTIAL, dedicato all analisi, valutazione e sperimentazione delle dipendenze dei sistemi di controllo elettrico dalle infrastrutture ICT. I risultati del progetto, coordinato da ERSE, sono raggruppabili in i) scenari di sistemi di controllo, ii) Framework di Modellazione, iii) Macrogrid Control Testbed e Microgrid Control Testbed, iv) Architettura ICT, v) Framework di Valutazione. Le attività di ERSE, presentate nei documenti RdS , hanno riguardato l identificazione degli scenari di controllo e lo sviluppo del Macrogrid Control Testbed. Nel corso del PAR 2009 sono stati prodotti i deliverable tecnici finali del progetto (consultabili sul sito e le pubblicazioni per le Conferenze IEEE-PSCE 2009, CRIS 2009, CIRED 2009, DSN E stata organizzata presso ERSE la revisione finale del progetto, svoltasi il 2-3/4/2009, nel corso della quale i risultati del progetto sono stati presentati e dimostrati all Officer della EC, ai revisori e al Consorzio, ottenendo una valutazione eccellente sia negli aspetti tecnici che nel management. I risultati del PAR 2009 sono stati oggetto di divulgazione sulla stampa di settore e di presentazione alle iniziative Europee ESTEC ed ERN-CIP, al WG Cigré D2.22, al Politecnico di Torino, ad ENEL ed ENEA.

8 Rapporto SSE Sviluppo dei Sistemi Elettrici Pag. 7/70 Acronimi ACC ACL AH Area Control Centre Access Control Lists Authentication Header APCI Application protocol Control Information header IEC APDU Application Protocol Data Unit pacchetto IEC completo, include APCI e ASDU ASDU Application Service Data Unit payload IEC ATS AVR CERT DG DoS DSO EHV-AAT EI EMS EPS ESP FACTS FTP GENCO HMI HSRP HTTPS HV-AT ICT ICMP IEC IED IOS IKE IP IPS IPsec LAN Area Telecontrol System Automatic Voltage Regulator Computer Emergency Response Team Distributed Generation Denial of Service Distribution System Operator Extra High Voltage - Altissima Tensione Electrical Infrastructure Energy Management System Electrical Power System Encapsulation Security Payload Flexible Alternating Current Transmission Systems File Transfer Protocol GENeration COompany Human-Machine Interface Hot Standby Router Protocol Hypertext Transfer Protocol over Secure Socket Layer High Voltage - Alta Tensione Information Communication Technology Internet Control Message Protocol International Electrotechnical Commission Intelligent Electronic Device Internetwork Operating System Internet Key Exchange Internet Protocol Intrusion Protection System IP security standard protocol Local Area Network

9 Rapporto SSE Sviluppo dei Sistemi Elettrici Pag. 8/70 LV-BT MCD-TU MV-MT NSM NTS NVR OLTC OPF OSI PC PCS PFR PMU PQR PS PSS PVC RCC RTS RTT RVR SAN SAS SCADA SDM SFR SME SPI SSH SWN TCP TSO TSP UCTE UDP UML Low Voltage - Bassa Tensione Monitoring Control and Defence Terminal Unit Medium Voltage - Media Tensione Network System Management National Telecontrol System National Voltage Regulator On-Load Tap Changer Optimal Power Flow Open System Interconnection Personal Computer Process Control System Primary Frequency Regulator Phasor Measurement Unit Reactive Power (Q) Regulator Power Station Power System Stabiliser Permanent Virtual Circuit Regional Control Centre Regional Telecontrol System Round Trip Time Regional Voltage Regulator Stochastic Activity Network Substation Automation System Supervisory Control and Data Acquisition Security Device Manager Secondary Frequency Regulator Signature Micro Engine Security Parameter Index Secure Shell Stochastic Well formed Net Transmission Control Protocol Transmission System Operator Telecommunication Service Provider Union for Co-ordination of Transmission of Electricity User Datagram Protocol Unified Modelling Language

10 Rapporto SSE Sviluppo dei Sistemi Elettrici Pag. 9/70 VPN WAMS WAN WAP Virtual Private Network Wide Area Measurement Systems Wide Area Network Wide Area Protection

11 Rapporto SSE Sviluppo dei Sistemi Elettrici Pag. 10/70 1 INTRODUZIONE Tradizionalmente i sistemi SCADA preposti allo svolgimento delle funzioni di monitoraggio e controllo del sistema elettrico in esercizio prevedono una disponibilità continua della rete di comunicazione per la trasmissione di flussi di dati periodici (stati) o asincroni (comandi ed eventi). Ai flussi di dati di processo si aggiungono flussi di dati per la gestione dei componenti di comunicazione e controllo e della loro sicurezza. Le diverse criticità delle condizioni operative del sistema elettrico impongono vincoli più o meno stringenti sui tempi di risposta delle azioni remote di automazione e controllo che, nei casi più critici (leggasi in emergenza), possono scendere fino all ordine di 10 2 msec. Ai requisiti di disponibilità e temporali sopra esposti, si aggiunge un requisito di autenticità nell invio e nella ricezione di flussi di dati. In qualunque condizione operativa le procedure di esercizio richiedono l esecuzione indisturbata di sequenze ordinate di acquisizioni e attuazioni basate su flussi ordinati di dati di monitoraggio e controllo. In tale contesto applicativo, l esistenza di processi di attacco informatico basati su consumo di banda, riferiti con il termine attacchi DoS, provocano congestioni di rete che alterano o addirittura paralizzano i flussi delle sequenze operative, con conseguenze rilevanti sul processo controllato in presenza di condizioni operative altamente critiche. Qualunque azione di recupero automatico delle anomalie sulle comunicazioni deve essere valutata in relazione alle tempistiche richieste. Al fine di rispettare i vincoli nelle situazioni più critiche (o nei casi peggiori) un primo obiettivo delle contromisure di sicurezza delle comunicazioni per il controllo elettrico è quello di annullare le perdite di dati e limitare i ritardi di trasmissione. Disponendo di una conoscenza di maggior dettaglio sulle comunicazioni coinvolte negli schemi del controllo elettrico, possono d altro canto insorgere processi di intrusione in grado di infrangere il requisito di autenticità dei flussi di dati già accennato. In questo caso le misure di sicurezza assumono un ruolo preventivo evitando la possibilità di forgiare il colloquio in atto. Pertanto un secondo obiettivo delle contromisure di sicurezza delle comunicazioni per il controllo elettrico è quello di eliminare l intromissione di dati spuri. Considerati i requisiti delle comunicazioni dei sistemi di controllo elettrico, l analisi del rischio informatico deve coprire le seguenti tipologie di minacce: i) anomalie fisiche che generano indisponibilità dei canali di comunicazione; ii) attacchi logici basati su flussi consistenti di traffico malizioso che possono comportare ritardi inaccettabili o perdite di dati applicativi, con particolare riferimento ai comandi di telecontrollo iii) intrusioni in grado di intromettersi nella comunicazione inserendo dati/comandi spuri nel traffico applicativo. Lo studio degli effetti di tali tipologie di malfunzionamento consente di valutare, rispettivamente, i seguenti indici di Dependability e Security introdotti nella bozza dello standard IEC [1] relativamente alle teleprotezioni i) Dependability D = 1 P mc dove P mc Probability for missing commands ii) Security S = 1 P uc dove P uc Probability for unwanted commands Secondo le indicazioni riportate nello standard, gli schemi di protezioni inter-tripping richiedono P uc < 10-8 e P mc < 10-4, dove i missing commands sono caratterizzati da un tempo di latenza t > 10 msec. L architettura di controllo elettrico realizzata nel Laboratorio ERSE (Figura 1), peculiare nella sua capacità di riprodurre sistemi SCADA scalabili in funzione di Centri, Stazioni e IED di Automazione, si

12 Rapporto SSE Sviluppo dei Sistemi Elettrici Pag. 11/70 propone come piattaforma di prova su cui effettuare esperimenti controllati per la raccolta di dati relativi ad attacchi informatici ai sistemi di controllo. Figura 1: Laboratorio per l analisi degli attacchi informatici. L attività di ricerca associata al Laboratorio deve essere concepita in funzione della valutazione sperimentale dell effetto degli attacchi sui sistemi di controllo, la quale si avvale di un apposito framework per l elaborazione di un insieme di misure relative alle comunicazioni standard. Tale attività di valutazione sperimentale, inserita nel Ciclo complessivo di Gestione del Rischio come illustrato in Figura 2, si articola in diverse fasi quali la pianificazione, la predisposizione ed esecuzione di esperimenti, seguita dalla archiviazione ed elaborazione dei dati sperimentali. Gli esperimenti controllati via via pianificati sono caratterizzati in base al tipo di attacco: ogni tipo di attacco identifica un insieme di parametri propri del tipo di esperimento e da un insieme di misure di valutazione.

13 Rapporto SSE Sviluppo dei Sistemi Elettrici Pag. 12/70 Figura 2: Ciclo di Gestione del Rischio e Valutazione Sperimentale. In continuità con la precedente attività di Ricerca di Sistema , l attività del PAR 2009 riportata del documento ha riguardato lo sviluppo dei diversi aspetti coinvolti nella sperimentazione, elencati nel seguito. i) Estensioni del Testbed pre-esistente, relative alle funzioni del software di comunicazione a livello Centro e a livello Stazione e agli strumenti per la simulazione degli attacchi ii) iii) iv) Definizione del framework di valutazione delle comunicazioni e sua applicazione alle prove funzionali, di anomalie fisiche e di attacco logico Prova e valutazione delle comunicazioni IEC messe in sicurezza tramite IPsec Prova e valutazione della gestione automatica delle anomalie fisiche tramite comunicazioni ridondate v) Prova e valutazione degli attacchi DoS vi) vii) Configurazione, prova e valutazione di contromisure di difesa dagli attacchi DoS Sviluppo di prove di intrusione. Nel Testbed le comunicazioni IEC vengono utilizzate per l implementazione dei flussi informativi che afferiscono ai sistemi di Telecontrollo della rete di distribuzione e trasmissione, comprendenti le comunicazioni Centro-Stazioni, inter-centro e inter-stazioni (NTS, ATS, Station Computer in Figura 3). Tuttavia le prove effettuate e i risultati ottenuti sono estendibili anche ad altri flussi informativi basati sullo stesso protocollo IEC presenti nelle infrastrutture reali [18], come quelli afferenti ai sistemi di Regolazione Secondaria della Tensione localizzati nei Centri Regionali del gestore e presso gli impianti delle compagnie di generazione (rispettivamente RVR e PQR in Figura 3) [19].

14 Rapporto SSE Sviluppo dei Sistemi Elettrici Pag. 13/70 Figura 3: Infrastrutture ICT del Sistema Elettrico. Le contromisure di sicurezza inserite nella sperimentazione, mirate a soddisfare i requisiti di Dependability e Security, si collocano sia a livello della rete IP (VPN IPsec, canali ridondati, IPS), sia a livello del protocollo applicativo di telecontrollo, rappresentato nello specifico dallo standard IEC [3]. Dopo avere presentato e analizzato metodi e risultati delle prove effettuate sul Testbed di Laboratorio, si riuscirà a comprendere come la scelta di una contromisura di sicurezza e della sua modalità di utilizzo - preventiva (esecuzione incondizionata) o correttiva (esecuzione condizionata alla rilevazione di anomalia) dipenda dalla valutazione delle prestazioni delle comunicazioni in relazione agli obiettivi posti in precedenza.

15 Rapporto SSE Sviluppo dei Sistemi Elettrici Pag. 14/70 2 ARCHITETTURA TESTBED L architettura del Testbed utilizzata per le sperimentazioni costituisce un evoluzione dell architettura sviluppata nell attività RdS Pertanto nel seguito verranno riassunte le estensioni implementate nell anno 2009, rimandando al precedente rapporto [2] per la descrizione esaustiva dei suoi componenti. Al fine di effettuare sperimentazioni rilevanti per il telecontrollo IP degli apparati di automazione di Stazione, l architettura del Testbed del Laboratorio rappresentata in Figura 4 prevede il Telecontrollo di due Stazioni AT/MT di un DSO, identiche dal punto di vista funzionale, ma diversificate rispetto alla tecnologia utilizzata per la connettività Centro di Supervisione-Stazione. La Stazione 1 viene connessa al Centro utilizzando dei Router commerciali Cisco in ambiente operativo Cisco IOS, soluzione già utilizzata nell infrastruttura reale di Telecontrollo delle Stazioni AT/MT di ENEL. Per una simulazione più fedele delle comunicazioni, che nell infrastruttura reale avvengono tramite canali PVC su interfaccia Frame Relay forniti da TSP terza parte, nel Testbed le comunicazioni Centro-Stazione1 sono implementate tramite link seriali. Come nell infrastruttura reale, anche nel Testbed a livello di Centro è prevista una ridondanza hardware della connettività, tramite l impiego di un router di back-up, gestita mediante protocollo HSRP disponibile in ambiente IOS. Per quanto riguarda la sicurezza, l ambiente Cisco IOS offre un insieme integrato di funzionalità quali firewall, VPN e IPS. In ambiente operativo IOS le comunicazioni Centro- Stazione1 vengono protette tramite VPN IPsec Site-to-Site su interfaccia seriale. La Stazione2 viene connessa al Centro utilizzando dei Gateway basati su PC Dell in ambiente Linux. La ridondanza di Centro viene in questo caso realizzata mediante l impiego di un interfaccia di rete di back-up sullo stesso gateway. In ambiente operativo Linux le comunicazioni Centro- Stazione2 vengono protette tramite VPN basata su protocollo IPsec implementato mediante la soluzione Open-Source StrongSwan Site-to-Site su interfaccia Ethernet. L eterogeneità tecnologica del Testbed consente di confrontare diverse configurazioni e le prestazioni delle comunicazioni nelle due infrastrutture. La connettività IP dei Centri e delle Stazioni, oltre a supportare l attività di telecontrollo e le comunicazioni dei sistemi SCADA, viene sfruttata nel Testbed per la remotizzazione delle funzioni di gestione e manutenzione dei sistemi di comunicazione e di controllo degli stessi. La convivenza di comunicazioni diverse su uno stesso sistema richiede di estendere l analisi delle vulnerabilità del sistema a tutte le sue funzioni, includendo l analisi delle vulnerabilità indotte dalle attività di gestione dell infrastruttura ICT. Come visibile in Figura 4, l architettura del Testbed 2009 include: sistemi di Telecontrollo a livello di Centro e di Stazione, le cui comunicazioni sono basate sui protocolli IEC , TCP/IP e IPsec. Quest ultima suite di protocolli [11] comprende protocolli che forniscono la cifratura del flusso di dati (es.: AH ed ESP) e protocolli che implementano lo scambio delle chiavi per realizzare il flusso crittografato (es.: IKE basato su UDP/IP); sistemi (ICT Control Centre) per la gestione remota dei dispositivi di comunicazione, controllo e automazione, le cui comunicazioni sono basate, per ragioni di sicurezza, sui protocolli standard https e ssh, entrambi basati su TCP/IP; sistemi (Attacker) per la simulazione degli attacchi, le cui comunicazioni sono basate sul protocollo UDP/IP; sistemi (Sniffer) basati su PC collegati alle singole sottoreti che registrano tutto il traffico in transito nelle sottoreti.

16 Rapporto SSE Sviluppo dei Sistemi Elettrici Pag. 15/70 Figura 4: Architettura Testbed per l analisi degli attacchi informatici. Per una maggiore realisticità degli scenari, tutte le sottoreti sono implementate impiegando dei dispositivi di tipo switch, evitando l impiego di tecniche basate su macchine virtuali o reti simulate. In particolare sfruttando le caratteristiche di ridirezione del traffico, proprie dei dispositivi switch, si è potuto collegare alla sottoreti dispositivi per realizzare lo sniffing, ovvero la cattura del traffico, una funzionalità indispensabile alla comprensione dei protocolli e del corretto flusso dei pacchetti impiegati nelle comunicazioni. Nelle sezioni che seguono vengono descritte le modifiche e le estensioni apportate alle funzioni di comunicazione e ai tool per la simulazione degli attacchi DoS utilizzati negli esperimenti. 2.1 Funzioni di comunicazione Nel Testbed 2009 le funzioni dei programmi di gestione delle comunicazioni tra Centro DSO e stazioni controllate, e delle comunicazioni intercentro tra Centri DSO e TSO, sono state suddivise in due tipi di moduli software, logicamente distinti: i moduli del protocollo IEC [3] ( Transmission protocols- Network access for IEC using standard transport profiles - nel seguito protocollo 104); i moduli Dispatcher di Centro e di Stazione con funzioni SCADA. All interno dei Centri e delle Stazioni tutte le comunicazioni sono in formato proprietario ed utilizzano il protocollo UDP/IP; le comunicazioni tra Centro e Stazioni, tra Centri ed, in generale, tra Centro/Stazione e mondo esterno sono invece in formato compatibile con il protocollo IEC e sono basate su TCP/IP. Ogni scambio di messaggi tra centro e stazioni, o tra Centri, richiede quindi una conversione da formato proprietario a formato 104 e vice versa. A lato centro queste conversioni vengono effettuate dal modulo Dispatcher di Centro denominato DsoDispatcher o TSODispatcher, mentre a lato stazione le conversioni sono effettuate dal modulo Dispatcher di Stazione denominato StationDispatcher. Nelle funzionalità SCADA dei Dispatcher, per ogni Centro e per ogni Stazione è stato introdotto un proprio identificatore univoco. Per maggior precisione parleremo nel seguito di identificatore di nodo

17 Rapporto SSE Sviluppo dei Sistemi Elettrici Pag. 16/70 invece che di identificatore di impianto. L identificatore di nodo ha il formato dei COMMON ADDRESS (Figura 5) specificati nel documento GRTN DRRPX02039 Rev2. [4], nel senso che ogni identificatore comprende una coppia di byte: l identificatore della regione o area di appartenenza (area_id) e l identificatore del nodo all interno dell area (node_id). La coppia (node_id, area_id) identifica univocamente ogni centro e stazione del Testbed. L ASDU COMMON ADDRESS occupa i primi due byte della sezione ASDU del frame 104. Figura 5: Struttura indirizzo Nodo. Lo scambio informativo secondo il protocollo 104 viene gestito dall applicazione P104 di tipo clientserver, quindi di tipo asimmetrico: l applicazione server P104Server (lato stazione controllata) e l applicazione client P104Client (lato stazione controllante), aventi un comportamento diverso. L applicazione P104 rappresenta un implementazione semplificata dello standard che si propone di riprodurre fedelmente le funzioni indispensabili per supportare il particolare tipo di flusso informativo che ha luogo tra i nodi dell architettura di laboratorio, prescindendo dal contenuto della parte applicativa. Il modulo P104Server è stato esteso per accettare comunicazioni UDP in formato 104 relative alla gestione delle situazioni di emergenza. Lo schema generale del flusso della comunicazione è riportato in Figura 6, mentre lo schema dell implementazione del flusso della comunicazione nel Testbed è riportato in Figura 7, la quale evidenzia le diverse tecnologie impiegate per i collegamenti fisici tra Centro e Stazioni. Figura 6: Flusso comunicazioni Centro Stazioni.