Cyber Security dei Sistemi di Controllo dei Processi nelle Infrastrutture Critiche
Igor Nai Fovino, Research Programme Manager, GCSEC
L
e infrastrutture e sistemi critici industriali (impianti e reti elettriche, oleodotti, gasdotti ecc.) sono oggi esposti non solo alle problematiche tradizionali di safety, stabilità e disponibilità di servizio, ma anche a nuove tipologie di minacce legate al grande numero di vulnerabilità architetturali ed operative introdotte dall’ado-­
zione pervasiva dell’ICT in sistemi così complessi.
Il trend architetturale attuale di queste particolari nfrastrutture critiche è quello di integrare sempre più le reti di controllo dei sistemi industriali con sistemi ICT di più ampio utilizzo, inclusa la rete aziendale, al ¿QHGLRWWLPL]]DUHVHPSUHGLSLODJHVWLRQHGHOO¶LQWHUD
infrastruttura. Per portare un esempio, spesso ora, grazie a questa massiccia operazione d’integrazione, i servizi di manutenzione sui dispositivi di controllo di processo sono eseguiti da remoto.
1HJOLXOWLPLDQQLVLqYHUL¿FDWDXQDQHFHVVLWjFUHVFHQWH
di mettere in sicurezza tali apparati da attività di tipo terroristico o comunque eseguite da gruppi criminali organizzati o estremisti. Da una parte, i requisiti di sicurezza sono cambiati drasticamente dopo l’11 Settembre 2001; dall’altra, l’uso intensivo dell’ICT ha aperto nuove strade per attaccare queste strutture. Il paradosso è che più i sistemi ICT tradizionali sono introdotti e utilizzati, al ¿QHGLPLJOLRUDUHOHSHUIRUPDQFHVHLVHUYL]L
di queste infrastrutture, più opportunità ci VRQRSHULOYHUL¿FDUVLGLLQWUXVLRQLGDOO¶HVWHUQR
e dall’interno; la violazione dell’integrità, GLVSRQLELOLWjRDQFKHGHOODFRQ¿GHQ]LDOLWjGHL
GDWLD]LHQGDOLSXzSURGXUUHGDQQLVLJQL¿FDWLYL
agli asset della compagnia ed essere parte di un attacco più ampio mirato a colpire ¿VLFDPHQWHOHVWUXWWXUHFULWLFKH
Questi scenari non possono essere ignorati poiché le conseguenze di incidenti simili possono essere gravi: ad esempio, il costo del blocco di un impianto energetico è grande ed il rilascio di agenti inquinanti a causa di XQDWWDFFRDQGDWRDEXRQ¿QHSXzSURYRFDUH
ingenti danni a livello ambientale.
La parte centrale delle infrastrutture critiche industriali è costituita dai sistemi di Supervisory Control and Data Acquisition, più propriamente noti come SCADA. La sicurezza ICT dei sistemi di controllo, campo di ricerca aperto e in evoluzione, è affetta da due macro tipologie di minacce: attacchi ICT classici, cioè attacchi che sfruttano vulnerabilità tipiche dei sistemi ICT Information Security -­ N.6 -­ set/ott 2011
19 general purpose. Questi attacchi possono essere generalmente arginati mediante DGR]LRQHGLFRQWURPLVXUHFRPH¿UHZDOO
antivirus ed adottando rigorose procedure di gestione delle patch;
DWWDFFKLVSHFL¿FLVXSLDWWDIRUPDLQGXVWULDOH
attacchi che sfruttano vulnerabilità VSHFL¿FKHGHLVLVWHPLLQGXVWULDOLDGHVHPSLR
l’assenza di meccanismi di autenticazione e controllo dell’integrità in molti dei più usati protocolli di comunicazione industriali utilizzati in questo ambito.
,OUHFHQWHFDVR6WX[QHWSULPRPDOZDUH
sviluppato esclusivamente per attaccare sistemi di controllo, ha portato l’attenzione degli organi governativi sull’esposizione degli impianti elettrici a minacce di attacchi informatici.
A causa delle peculiarità dei sistemi industriali, le tradizionali contromisure ICT non possono VHPSUHHVVHUHLPSLHJDWHHI¿FDFHPHQWHR
peggio possono essere del tutto inadeguate, come nel caso di alcuni attacchi della seconda classe descritta sopra. Inoltre, anche 20 20 nell’eventualità in cui le contromisure siano impiegate con successo, il rischio di esposizione ad attacchi ancora sconosciuti, per i quali i tradizionali metodi di protezione VRQRLQHI¿FDFLqVHPSUHSUHVHQWH&RQVLGHUDWRLOUXROR
che tali infrastrutture critiche giocano nella vita dei cittadini, questo rischio è ovviamente inaccettabile.
Essendo i sistemi SCADA il cuore degli impianti industriali, può valere la pena fare un breve excursus sulle differenti tipologie di vulnerabilità da cui sono affetti.
VULNERABILITÀ A LIVELLO ARCHITETTURALE
Le moderne architetture SCADA non sono così differenti da quelle adottate negli anni ’80 e ’90. I motivi di questa lentezza evolutiva sono abbastanza ovvi: queste architetture sono state testate per anni e sono FRQVLGHUDWHVWDELOLHDI¿GDELOL
il costo di deployment di un’architettura completamente nuova in un impianto funzionante non è affatto trascurabile;
esiste tuttora una differenza di percezione e valutazione sul ROI prodotto da un investimento simile da parte dei process engineers e del board of management.
Information Security -­ N.6 -­ set/ott 2011
Se da una parte, l’architettura di base è rimasta la stessa, si è assistito tuttavia ad una massiccia migrazione da un ambiente isolato e chiuso verso uno aperto, passando dalla comunicazione seriale al TCP/IP. In questo nuovo contesto le tradizionali architetture SCADA hanno iniziato a mostrare i loro limiti di sicurezza; gli ingegneri di processo hanno dunque tentato di risolvere i problemi di security adottando un approccio simile a quello utilizzato per mitigare i rischi di sicurezza ICT, spesso senza tenere in accurato conto i vincoli di safety e sicurezza per i sistemi SCADA sono molto più serrati.
Esempi di vulnerabilità architetturali nei sistemi SCADA possono essere:
una separazione debole tra la rete di processo e la rete di campo; quest’ultima, che rappresenta la componente più interna dell’intera architettura, non qJHQHUDOPHQWHVHSDUDWDLQPDQLHUDHI¿FDFHGDOOD
rete di processo poiché, si ritiene erroneamente improbabile che un attaccante riesca a raggiungere quest’area; in realtà, il caso Stuxnet ha smentito questa assunzione;
la mancanza di autenticazione tra le componenti del sistema SCADA (e.g. Server SCADA, Remote Terminal Units (RTU), SCADA Data Exchange Server). Ciò è dovuto al fatto che la rete di campo è sempre stata un ambiente chiuso e non sussisteva la necessità di integrazione con meccanismi di autenticazione tra le componenti di rete;
VLQJOHSRLQWRIIDLOXUHUDSSUHVHQWDWRGDO¿UHZDOOGL
processo e da dispositivi di accesso remoto (e.g. server di autenticazione);
poca attenzione verso load-­balancing di rete e ridondanza.
VULNERABILITÀ A LIVELLO DI POLICY DI SICUREZZA
Un sistema architetturalmente ben progettato può essere vulnerabile se mal utilizzato o gestito. Per essere robusto e sicuro, un sistema SCADA deve essere protetto sia a livello tecnico sia a livello di policy.
6HGDXQODWROHSROLF\GLVLFXUH]]DSHUO¶DFFHVVR¿VLFR
ai sistemi SCADA sono ben recepite e implementate nei sistemi industriali, le policy di sicurezza ICT sono generalmente deboli o mal implementate.
Generalmente il set di policy esistente è derivato da quelle tradizionali ICT adottate nelle reti aziendali. Sfortunatamente, spesso tali policy mal si sposano con l’ambiente e le peculiarità delle reti di processo industriale.
Ad esempio, vulnerabilità nel sistema possono essere causate da:
assenza di una patching policy aziendale: aggiornare il sistema con patch di sicurezza è abbastanza frequente, ma nei sistemi SCADA non è raro trovare VRIWZDUHVYLOXSSDWLDGKRFSHUFXLLOSURFHVVRGL
patch management può interferire pesantemente sull’operatività e stabilità del sistema. Inoltre, talvolta alcune patch richiedono il riavvio di sistema, ed il reboot del server di controllo di un sistema SCADA può interferire con l’intero sistema di produzione;
assenza di policy per aggiornamento antivirus; anche gli antivirus possono interferire con il sistema SCADA poiché, per eseguire correttamente gli aggiornamenti, è necessario garantire l’accesso a Internet direttamente al sistema SCADA oppure prevedere all’interno dell’architettura di rete un server FKHGLVWULEXLVFDLOQXRYRGDWDEDVHGL¿UPHFLzSXz
avvenire raramente poiché si preferisce mantenere la rete di processo il più possibile isolata da quella esterna;
SROLF\GLDFFHVVRQRQHI¿FDFLOHSROLF\GLDFFHVVRVRQR
generalmente ben prodotte ma male implementate (può sembrare strano ma capita che ancora sia usato il classico post-­it sul display di server di processo con su scritte le credenziali di login);
assenza di documentazione di sistema rigorosa e XQL¿FDWDFRQWHQHQWHLOWUDFFLDPHQWRGHOO¶HYROX]LRQH
del sistema e i risultati delle analisi di sicurezza Information Security -­ N.6 -­ set/ott 2011
21 eseguite iterativamente: le reti di processo e di campo sono generalmente in continua evoluzione ma ciò non è adeguatamente documentato (e.g. informazioni su nuovi servizi e dispositivi che sono vitali per attività di system vulnerability assessment). In più, le attività di security assessment di sistema sono generalmente percepite come processi una tantum, il che rappresenta un errore poiché dovrebbero essere integrate a livello di processo di gestione del ciclo di vita del sistema SCADA.
VULNERABILITÀ A LIVELLO DI SOFTWARE
,VLVWHPL6&$'$VRQRJHVWLWLGDVRIWZDUH
ed è chiaramente impossibile assumere che del codice sia del tutto esente da bug; le YXOQHUDELOLWjVRIWZDUHVRQRHVWUHPDPHQWH
pericolose, poiché possono consentire ad un attaccante di prendere pieno controllo di un sistema.
,OVRIWZDUHXWLOL]]DWRQHLVLVWHPL6&$'$SXz
presentare queste classiche vulnerabilità: EXIIHURYHUÀRZ64/LQMHFWLRQ)RUPDW6WULQJH
DOWUHYXOQHUDELOLWjWLSLFKHGHOOHZHEDSSOLFDWLRQ
22 22 A queste si aggiunge un set di vulnerabilità tipiche dei sistemi SCADA: i bug logici contenuti nei blocchi di codice eseguiti sui PLC/RTU, che costituiscono il livello SLEDVVRGHLVLVWHPL6&$'$XQHUURUHVRIWZDUHD
questo livello (ad esempio nella gestione delle eccezioni) può compromettere la funzionalità di un’intera porzione del sistema di controllo.
VULNERABILITÀ A LIVELLO DI PROTOCOLLI DI COMUNICAZIONE
La maggior parte dei protocolli SCADA, come il Modbus e DNP, è stata progettata molti anni fa, per reti di controllo basate su connessioni seriali; con la diffusione delle connessioni Ethernet, i protocolli SCADA sono stati poi implementati su protocolli basati su IP, tipicamente TCP. Tuttavia, tali implementazioni non sono integrate con meccanismi di protezione come autenticazione, autorizzazione e cifratura, mancando di protezione GHOODFRQ¿GHQ]LDOLWjHGLQWHJULWjGHLGDWLLQWUDQVLWRH
della disponibilità del sistema o di sue componenti. 0HQWUHSHUTXDQWRULJXDUGDOD³FRQ¿GHQ]LDOLWj´VLSXz
tranquillamente assumere che tutto sommato non sia un requisito necessario in una comunicazione industriale, di ben altra rilevanza sono la mancanza di autenticazione ed integrità.
Tipici esempi di attacchi sui protocolli di comunicazione Information Security -­ N.6 -­ set/ott 2011
possono comportare l’esecuzione di comandi non autorizzati sui dispositivi di campo, Denial-­of-­Service sui PLC, Man-­in-­the-­Middle tra dispositivi di campo e server di controllo, con conseguenze rilevanti sul corretto funzionamento dell’intero sistema di controllo.
Quali possono essere alcune misure basilari per proteggersi da queste vulnerabilità?
/¶XVRGL9LUWXDO3ULYDWH1HWZRUN931IDVuFKH
mediante l’uso di un canale di comunicazione GLUHWHFLIUDWRVLDSURWHWWDODFRQ¿GHQ]LDOLWjH
l’integrità dei dati in transito. Un utilizzo di VPN nella gestione del controllo remoto delle reti di processo costituisce sicuramente una prima barriera contro intrusioni informatiche. Presenta ovviamente alcune controindicazioni: ad esempio, è necessario assumere che il livello di sicurezza garantito ai due estremi della connessione (i.e. nelle due reti, quella del manutentore e quella dell’impianto) sia egualmente alto. Inoltre OH931SRVVRQRHVVHUHGLI¿FLOPHQWHXWLOL]]DWHSHU
proteggere la comunicazione tra Server SCADA e strumenti di campo, proprio a causa della scarsa capacità computazionale di questi ultimi.
La segregazione di rete e servizi può essere utilizzata per un controllo più granulare, unita ad una politica GL¿OWUDJJLRHPRQLWRULQJSHUOLPLWDUHOHFRQQHVVLRQL
esterne ed isolare il più possibile i sistemi di controllo;
L’uso di meccanismi di autenticazione e integrity FKHFNHWLPHVWDPSLQJGHLGDWLLQWUDQVLWRFRVuFRPH
integrato ad esempio negli ultimi aggiornamenti del protocollo DNP3) garantisce la protezione degli accessi, integrità dei dati e ne evita il riuso come nei casi di attacchi di tipo replay.
A livello globale, la protezione delle infrastrutture critiche dovrebbe passare per le seguenti fasi:
studio e comprensione approfondita delle interdipendenze tra le infrastrutture critiche (e.g. energetico-­telecomunicazioni-­trasporti) e necessità di adottare un approccio sistematico nell’analisi dei ‘sistemi di sistemi’;
analisi delle vulnerabilità e testing intensivo: ciò implica la progettazione e sviluppo di ambienti protetti in cui riprodurre test su campo in grado di raccogliere più informazioni possibili sugli effetti di nuovi attacchi;
progettazione di nuove contromisure ad hoc per proteggere i sistemi SCADA, come ad esempio schemi FULWWRJUD¿FLOHJJHULSHUSURWRFROOLGLFRPXQLFD]LRQH
SCADA e meccanismi di intrusion detection in grado di interpretare i protocolli industriali e di comprendere se il sistema sotto controllo stia virando verso rischiosi stati critici.
Se da una parte lo scenario appena descritto non è certamente dei più rassicuranti, è necessario sottolineare come in realtà attacchi informatici che mirino a danneggiare questi sistemi, richiedano una quantità di conoscenze ed una disponibilità di risorse non comuni.
Lo stesso caso Stuxnet, pur avendo evidenziato i limiti di sicurezza dei sistemi SCADA e avendo sollevato domande serie sull’evoluzione futura degli scenari di minacce informatiche verso le infrastrutture critiche, ha anche messo in luce come certi tipi di attacchi possano essere realizzati solamente da organizzazioni criminali con risorse non indifferenti. Ad ogni modo, gli effetti e i danni potenzialmente causati da un cyber attacco a questo tipo di infrastrutture, sono tali da rendere quello della sicurezza informatica delle infrastrutture critiche un tema su cui a livello nazionale urge quanto mai un rapido ed incisivo sforzo collettivo. Information Security -­ N.6 -­ set/ott 2011
23 Il futuro della cyber security ed il paradigma del cloud computing
Igor Nai Fovino, Research Programme Manager, GCSEC
Gli ultimi due anni entreranno nella storia della sicurezza informatica per una serie di eventi che hanno evidenziato come questa possa avere un impatto rilevante sulla vita dei cittadini e non riguardi semplicemente la PHVVDLQVLFXUH]]DGLVHUYHUVRIWZDUHHGDWL
aziendali.
Il 2010 sarà ricordato come l'anno di Stuxnet, LOSULPRPDOZDUHFDSDFHGLSUHQGHUHLO
controllo di dispositivi industriali di basso OLYHOORHFRQFHSLWRVSHFL¿FDWDPHQWHSHUXQ
particolare dispositivo delle centrali nucleari. In pochi giorni il mondo ha compreso come infrastrutture critiche quali reti elettriche, reti idriche, di gas e oleodotti, sistemi di controllo aereo, reti ospedaliere siano vulnerabili ad attacchi informatici.
La prima metà del 2011 ha visto una lunga lista di attacchi informatici di massa contro aziende internazionali. Tali attacchi, effettuati nella maggior parte dei casi con semplici attacchi Distributed Denial of Service, 24 non erano, almeno dal punto di vista tecnico, nulla di eccezionale. Ciò che, in questo contesto, è stato degno di QRWDqO¶HI¿FDFLDFRQFXLOHRUJDQL]]D]LRQLGLKDFNHUVRQR
ULXVFLWHDUDFFRJOLHUHFRQVHQVRHUHFOXWDUH³PDQRYDODQ]D´
per tali attacchi, sfruttando tradizionali canali di comunicazione quali chat, IRC e Forum.
7XWWDYLDO
HYHQWRSLVLJQL¿FDWLYRGHOqTXHOOR
che potremmo visionariamente chiamare l’attacco al ³9LGHRJDPH:RUOG´
In meno di un mese, tre delle società più importanti del mondo dei videogames, Sony, Sega ed Epic Games, sono state attaccate con successo raggiungendo un numero GL³YLWWLPH´JOLXWHQWLGHOOHORURSLDWWDIRUPHVXSHULRUHD
cento milioni, quasi il doppio della popolazione italiana, un terzo della popolazione europea, qualcosa di meno della metà della popolazione statunitense. Le vittime sono state oggetto di furto di dati sensibili, quali ad esempio numeri di carte di credito, dati personali, login XWHQWHHSDVVZRUG
Il caso di PSN Sony ha suscitato molto scalpore poiché l'attacco è stato lanciato sfruttando il Cloud di Amazon S3. In un’ottica futuristica, tale evento apre le porte a Information Security -­ N.6 -­ set/ott 2011
scenari foschi in cui gli attacchi informatici del futuro verranno scatenati sfruttando l’enorme potenza di calcolo dei Cloud.
Alla luce dei trend attuali, già si può affermare che tale visione non sia molto lontana dalla realtà, considerando che molto probabilmente, il Cloud sarà il paradigma dell’IT del prossimo futuro. Ovviamente, in tale ottica, risulta quindi necessario iniziare a valutare attentamente come la sicurezza informatica si evolverà per far fronte a tale nuovo paradigma di calcolo.
Il concetto alla base del Cloud Computing è l'idea di SDVVDUHGDXQDSSURFFLR³,7FRPH$UFKLWHWWXUD´DXQ
DSSURFFLR³,7FRPHVHUYL]LR´
Uno dei vantaggi del Cloud è, infatti, la possibilità di innalzare il livello e la qualità della piattaforma IT di una società garantendo al tempo stesso una migliore gestione dei costi (riduzione dei costi di gestione dell’infrastruttura interna, del personale IT, del personale di sicurezza, ecc).
Uno degli effetti del Cloud è inoltre il disaccoppiamento tra le necessità di un servizio IT e l’infrastruttura sottostante. Pur se tale separazione può rappresentare un vantaggio per l’organizzazione, focalizzando l'attenzione sui processi di business e sugli obiettivi che un servizio IT dovrebbe facilitare, d’altra parte il Cloud è a uno stadio ancora troppo embrionale per essere già accolto nei processi, nelle norme e nelle procedure di 8QDFRPXQHFODVVL¿FD]LRQHLGHQWL¿FDWUHGLYHUVHDSSURFFL governance.
logici al Cloud:
6RQRQXPHURVHOHV¿GHGHOODVLFXUH]]D,&7QHO&ORXG'D
infrastructure-­as-­a-­Service (IaaS)
XQSXQWRGLYLVWDWHFQLFROHV¿GHSULQFLSDOLVRQROHJDWH
platform-­as-­a-­Service (PaaS)
alla sua natura completamente distribuita:
VRIWZDUHDVD6HUYLFH6DD6
Sicurezza perimetrale: con la completa Il Cloud, a prima vista potrebbe essere confuso con decentralizzazione di servizi, processi, e dati non è il semplice "hosting tradizionale". In realtà, almeno più possibile separare chiaramente il mondo interno (inteso come interno al perimetro aziendale) dal mondo esterno. Come può quindi essere garantito lo stesso livello di sicurezza di un perimetro tradizionale di sicurezza?
/¶HYHQWRSLVLJQL¿FDWLYRGHOq
Host Security: gli host sono raramente sotto il quello che potremmo visionariamen-­
controllo dell’organizzazione che usufruisce del servizio te chiamare l’attacco al “Videogame Cloud. Come può quindi essere garantita l’host security?
:RUOG´
Sicurezza degli ambienti virtualizzati: il Cloud fa largo uso dei sistemi virtualizzati. Come possa essere garantita la sicurezza di questi sistemi virtualizzati, è attualmente materia di ricerca, specialmente tre caratteristiche lo differenziano nettamente da considerando le possibili interazioni tra diversi sistemi quest’ultimo: YLUWXDOL]]DWLSUHVHQWLVXOODVWHVVDPDFFKLQD¿VLFD
un servizio Cloud viene venduto on demand, in genere Sicurezza computazionale: quando utilizziamo il al minuto o all’ora
&ORXGSHUHVHJXLUHGHLSURFHVVLLQSUDWLFDFL¿GLDPR
un servizio Cloud è dinamico ed elastico nel senso che della correttezza di calcoli eseguiti in chissà quale l’utente può ottenere poche o molte risorse in base parte del mondo, su chissà quale macchina, senza DOO¶RFFRUUHQ]DGHOORVSHFL¿FRPRPHQWR
avere alcuna effettiva garanzia dell’integrità di calcoli e il servizio è completamente gestito dal provider (sia ULVXOWDWLÊGXQTXHQHFHVVDULRGH¿QLUHGHLPHFFDQLVPL
HVVR³LQWHUQR´QHOFDVRGLSULYDWHFORXGVLDHVVR
in grado di assicurare l’integrità dei processi eseguiti ³HVWHUQR´QHOFDVRGLSXEOLFFORXG
all’interno del Cloud;
8QLPSXOVRVLJQL¿FDWLYRDOODGLIIXVLRQHGHO&ORXGqVWDWR
Disponibilità della rete: il paradigma del Cloud dato dall'evoluzione delle tecnologie di virtualizzazione, si basa sulla disponibilità della rete, quindi senza dal crescente numero di connessioni Internet a banda connessione a Internet il Cloud non può fornire i suoi larga, ma anche dalla crisi economica degli ultimi anni.
servizi. Sfortunatamente non è facile garantire il 100% Information Security -­ N.6 -­ set/ott 2011
25 della disponibilità della rete. Gli attacchi DDOS degli ultimi mesi hanno messo ancora di più in evidenza la vulnerabilità del Cloud in questa prospettiva. Tale problematica è sicuramente una delle più critiche che la FRPXQLWjWHFQLFRVFLHQWL¿FDGRYUjDIIURQWDUH
nei tempi a venire.
1RQRVWDQWHTXHOODOXQJDOLVWDGLV¿GHH
problemi che sarà necessario risolvere nel futuro immediato per rendere il Cloud un ambiente effettivamente sicuro, è doveroso precisare però che il Cloud è più un modello IT che una rivoluzione tecnica. In realtà le tecnologie utilizzate per implementare i moderni Cloud sono ben note, in gran parte testate ed è dunque ragionevole pensare che le problematiche di sicurezza sopra sollevate saranno rapidamente risolte.
*OLDVSHWWLSLLPSRUWDQWLHIRUVHSLGLI¿FROWRVL
da affrontare sono invece relativi alla GH¿QL]LRQHGLXQDVSHFL¿FDJRYHUQDQFHGHOO¶,7
Security mappata sulle peculiarità del Cloud Computing.
In particolare, in quest’area vi è una necessità di:
maggiore trasparenza
maggiori garanzie in termini di robustezza 26 dei Cloud provider
/HV¿GHPDJJLRULVRQRGRYXWHDOIDWWRFKHO¶XWHQWHGHO
&ORXGQHOODGH¿QL]LRQHGHOOHVXHSROLWLFKHGLVLFXUH]]D
e governance, non può non tenere conto di quelle del provider dei servizi Cloud che utilizza. In altre parole, le politiche di governance dell’azienda dovranno integrarsi sempre di più con quelle del Cloud provider. Tra i punti chiave lato governance che necessitano di essere approfonditi e sviscerati troviamo i seguenti:
Come selezionare un Cloud provider: è QHFHVVDULRGH¿QLUHSDUDPHWULFKHFRQVHQWDQRGL
LGHQWL¿FDUHFKLDUDPHQWHLO&ORXGSURYLGHUFKHSLVL
adatta alle esigenze dell'utente Cloud. Una possibile fonte di valutazione sono la reputazione, la storia e la sostenibilità del provider. Diventerà sicuramente sempre più necessario introdurre parametri di valutazione degli standard di sicurezza adottati, della qualità del servizio offerto, del supporto garantito (ad esempio in caso di trasferimento di dati e servizi ad altro provider);
Information Handling: gli aspetti di riservatezza, disponibilità e integrità delle informazioni devono essere presi in considerazione da un punto di vista della governance. È fondamentale garantire tali proprietà anche in caso di situazioni particolari come, ad esempio, nel caso in cui una società è oggetto d’indagini delle autorità. In tal caso, come può il Information Security -­ N.6 -­ set/ott 2011
provider garantire che solo i dati di tale società siano comunicati alle autorità e non i dati di altre aziende ospitate dalla stessa infrastruttura?
Compliance normativaLO&ORXGqSHUGH¿QL]LRQH
XQVLVWHPDGLVWULEXLWR4XHVWRVLJQL¿FDFKHLGDWLH
i processi possono essere ospitati potenzialmente ovunque nel mondo. Luoghi diversi implicano leggi diverse ed è fondamentale riuscire a rispettarle; Business continuity: la continuità di business di un'azienda è una questione rilevante nella governance della sicurezza ed è necessaria una rigorosa GH¿QL]LRQHGHLSURFHVVLGDHVHJXLUHDVHJXLWRGLXQ
GLVDVWURRPDOIXQ]LRQDPHQWLGRYXWLDHUURULFDWDVWUR¿
naturali o attacchi informatici). Il caso Sony ha posto DQFKHXQIRUWHDFFHQWRVXOODQHFHVVLWjGLGH¿QLUH
policy che garantiscano che l’utente sia avvisato il prima possibile in caso di disservizio, attacco, malfunzionamento. Ancora una volta la governance GHOODVLFXUH]]DULFKLHGHXQDFKLDUDGH¿QL]LRQHGHOOH
modalità attraverso le quali garantire il tempestivo scambio di informazioni tra Cloud provider ed utenti;
Trasparenza: i provider devono essere in grado di garantire ai propri clienti che le informazioni ed i processi siano adeguatamente protetti da accessi non DXWRUL]]DWLGDPRGL¿FKHHGLVWUX]LRQHÊQHFHVVDULR
GXQTXHGH¿QLUHO
HVLVWHQ]DGLFRQWUROOLGLVLFXUH]]D
HI¿FDFLHUREXVWL
&HUWL¿FD]LRQH: i provider di servizi informatici in Cloud dovranno fornire ai loro clienti certezza che essi stiano eseguendo le operazioni richieste in modo FRUUHWWR8QDYHUL¿FDLQGLSHQGHQWHGLDXGLWGLWHU]H
parti dovrebbe essere una parte vitale di qualsiasi programma di governance.
Tutti questi aspetti dovrebbero essere chiariti, standardizzati e inclusi nelle procedure di governance delle imprese. Il Cloud è un opportunità, ma un’opportunità che deve essere gestita nel modo FRUUHWWRFRQODGH¿QL]LRQHGLFKLDULRELHWWLYLGLEXVLQHVV
da raggiungere e del livello di sicurezza da garantire. In questo senso il Cloud, probabilmente in maniera più profonda di altri modelli, richiede una stretta collaborazione tra la gestione del core business e la gestione della sicurezza IT. Forse proprio quest’ultima è ODSLJUDQGHV¿GDSRVWDGDO&ORXG&RPSXWLQJ Il Cloud è più un modello IT che una rivoluzione tecnica
Information Security -­ N.6 -­ set/ott 2011
27 Eventi segnalati da GCSEC
DNS EASY 2011 Workshop
Sede: Roma
Data: 18-­20 Ottobre 2011
Organizzazione: GCSEC in collaborazione con ICANN e DNS-­OARC
,OZRUNVKRSqFRVWLWXLWRGDOOD,,,HGL]LRQHGHOVLP-­
posio annuale mondiale sulla sicurezza, stabilità e resilienza del DNS (gli eventi precedenti sono stati organizzati ad Atalanta, Giorgia Tech University, USA e Kyoto, Kyoto University, Giappone) e dalla I HGL]LRQHGHOZRUNVKRSVX³VDOXWHHVLFXUH]]D´GHO
DNS. DNS EASY 2011 si propone di riunire ricercatori e 28 professionisti provenienti dall’ambito accademico e dall’industria ed i maggiori rappresentanti dei JUXSSLGLVWDNHKROGHUVXO'16SHUGLVFXWHUQHOR
VWDWRGL³VDOXWHHVLFXUH]]D´HGLOVXRLPSDWWRVXOOD
società odierna.
Per maggiori informazioni visitare il sito KWWSZZZJFVHFRUJGQVHDV\
Information Security -­ N.6 -­ set/ott 2011
