IL PROBLEMA DELLA SICUREZZA NEL CLOUD COMPUTING

ALMA MATER STUDIORUMUNIVERSITA DI BOLOGNA

Seconda Facolta di IngegneriaCorso di Laurea in Ingegneria Informatica

IL PROBLEMA DELLA SICUREZZA NEL CLOUD

COMPUTING

Elaborata nel corso di: Sistemi Operativi

Tesi di Laurea di:ALESSANDRO BATTELLI

Relatore:Prof. ALESSANDRO RICCI

ANNO ACCADEMICO 2011–2012SESSIONE II

PAROLE CHIAVE

Cloud Computing

Security

Risk assessment

Framework

Indice

Introduzione ix

1 Il Cloud Computing 1

1.1 Storia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Caratteristiche del Cloud Computing . . . . . . . . . . . . . 2

1.3 Architettura Cloud . . . . . . . . . . . . . . . . . . . . . . . 3

1.4 Modelli di servizio . . . . . . . . . . . . . . . . . . . . . . . 5

1.5 Modelli di deployment del servizio Cloud . . . . . . . . . . . 6

1.5.1 Public cloud . . . . . . . . . . . . . . . . . . . . . . . 7

1.5.2 Private cloud . . . . . . . . . . . . . . . . . . . . . . 7

1.5.3 Community cloud . . . . . . . . . . . . . . . . . . . . 8

1.5.4 Hybrid cloud . . . . . . . . . . . . . . . . . . . . . . 8

1.6 Problemi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2 La sicurezza nel cloud computing 11

2.1 Il problema della sicurezza nel cloud computing . . . . . . . 12

2.2 Classificazione delle vulnerabilita . . . . . . . . . . . . . . . 16

2.3 Analisi di rischio in ambiente Cloud . . . . . . . . . . . . . . 21

2.3.1 Rischi organizzativi e di policy . . . . . . . . . . . . . 22

2.3.1.1 Lock-in . . . . . . . . . . . . . . . . . . . . 22

2.3.1.2 Perdita di controllo . . . . . . . . . . . . . . 23

2.3.1.3 Problemi di conformita . . . . . . . . . . . . 24

2.3.1.4 Perdita di reputazione a causa delle attivitadi co-tenant . . . . . . . . . . . . . . . . . . 24

2.3.1.5 Supply chain failure . . . . . . . . . . . . . 25

2.3.2 Rischi che riguardano aspetti tecnologici e architetturali 26

v

2.3.2.1 Esaurimento delle risorse (sotto o sovra ap-provigionamento) . . . . . . . . . . . . . . . 26

2.3.2.2 Isolation failure . . . . . . . . . . . . . . . . 272.3.2.3 Malicious insider - abuso di ruoli privilegiati 282.3.2.4 Compromissione di interfacce di gestione . . 292.3.2.5 Intercettazione dati in transito . . . . . . . 292.3.2.6 Cancellazione dei dati insicura o inefficace . 302.3.2.7 Distributed denial of service . . . . . . . . . 312.3.2.8 Economic denial of service . . . . . . . . . . 312.3.2.9 Perdita di chiavi di criptazione . . . . . . . 322.3.2.10 Scan e probe malevoli . . . . . . . . . . . . 332.3.2.11 Compromissione del service engine . . . . . 332.3.2.12 Conflitti tra procedure di hardening del clien-

te ed environment cloud . . . . . . . . . . . 342.3.3 Rischi legali . . . . . . . . . . . . . . . . . . . . . . . 35

2.3.3.1 Sub poena . . . . . . . . . . . . . . . . . . . 352.3.3.2 Rischi derivanti dai cambi giurisdizionali . . 362.3.3.3 Rischi di protezione dati . . . . . . . . . . . 362.3.3.4 Rischi riguardanti le licenze . . . . . . . . . 37

2.3.4 Rischi non specifici al cloud . . . . . . . . . . . . . . 382.3.4.1 Rottura della rete . . . . . . . . . . . . . . 382.3.4.2 Gestione di rete (congestione di rete / errori

di configurazione / uso non ottimale) . . . . 382.3.4.3 Privilege escalation . . . . . . . . . . . . . . 392.3.4.4 Attacchi di social engineering . . . . . . . . 392.3.4.5 Accesso non autorizzato agli edifici aziendali

(incluso accesso fisico alle macchine) . . . . 40

3 Cloud Network Security Framework 413.1 Background teorico . . . . . . . . . . . . . . . . . . . . . . . 42

3.1.1 Snort . . . . . . . . . . . . . . . . . . . . . . . . . . . 423.1.2 Decision Tree Classifier . . . . . . . . . . . . . . . . . 42

3.2 NIDS framework per il cloud . . . . . . . . . . . . . . . . . . 443.2.1 Obiettivi di design . . . . . . . . . . . . . . . . . . . 443.2.2 Integrazione del NIDS nel cloud . . . . . . . . . . . . 443.2.3 Architettura del modulo NIDS . . . . . . . . . . . . . 45

3.3 Valutazione del NIDS nel cloud . . . . . . . . . . . . . . . . 49

vi

3.3.1 Setup . . . . . . . . . . . . . . . . . . . . . . . . . . 493.3.2 Risultati e discussione . . . . . . . . . . . . . . . . . 50

4 Conclusioni 53

vii

Introduzione

Il termine cloud ha origine dal mondo delle telecomunicazioni quando i pro-vider iniziarono ad utilizzare servizi basati su reti virtuali private (VPN)per la comunicazione dei dati. Il cloud computing ha a che fare con lacomputazione, il software, l’accesso ai dati e servizi di memorizzazione inmodo tale che l’utente finale non abbia idea della posizione fisica dei datie la configurazione del sistema in cui risiedono. Il cloud computing e unrecente trend nel mondo IT che muove la computazione e i dati lontano daidesktop e dai pc portatili portandoli in larghi data centers. La definizionedi cloud computing data dal NIST dice che il cloud computing e un modelloche permette accesso di rete on-demand a un pool condiviso di risorse com-putazionali che puo essere rapidamente utilizzato e rilasciato con sforzo digestione ed interazione con il provider del servizio minimi. Con la prolifera-zione a larga scala di Internet nel mondo, le applicazioni ora possono esseredistribuite come servizi tramite Internet; come risultato, i costi complessividi questi servizi vengono abbattuti.

L’obbiettivo principale del cloud computing e utilizzare meglio risorse di-stribuite, combinarle assieme per raggiungere un throughput piu elevato erisolvere problemi di computazione su larga scala. Le aziende che si appog-giano ai servizi cloud risparmiano su costi di infrastruttura e mantenimentodi risorse computazionali poiche trasferiscono questo aspetto al provider; inquesto modo le aziende si possono occupare esclusivamente del business diloro interesse.

Mano a mano che il cloud computing diventa piu popolare, vengono espostepreoccupazioni riguardo i problemi di sicurezza introdotti con l’utilizzo diquesto nuovo modello. Le caratteristiche di questo nuovo modello di deploy-ment differiscono ampiamente da quelle delle architetture tradizionali, e i

ix

meccanismi di sicurezza tradizionali risultano inefficienti o inutili. Il cloudcomputing offre molti benefici ma e anche piu vulnerabile a minacce. Cisono molte sfide e rischi nel cloud computing che aumentano la minacciadella compromissione dei dati. Queste preoccupazioni rendono le aziende re-stie dall’adoperare soluzioni di cloud computing, rallentandone la diffusione.

Negli anni recenti molti sforzi sono andati nella ricerca sulla sicurezza degliambienti cloud, sulla classificazione delle minacce e sull’analisi di rischio;purtroppo i problemi del cloud sono di vario livello e non esiste una solu-zione univoca.

Dopo aver presentato una breve introduzione sul cloud computing in ge-nerale, l’obiettivo di questo elaborato e quello di fornire una panoramicasulle vulnerabilita principali del modello cloud in base alle sue caratteristi-che, per poi effettuare una analisi di rischio dal punto di vista del clienteriguardo l’utilizzo del cloud. In questo modo valutando i rischi e le op-portunita un cliente deve decidere se adottare una soluzione di tipo cloud.Alla fine verra presentato un framework che mira a risolvere un particolareproblema, quello del traffico malevolo sulla rete cloud.

L’elaborato e strutturato nel modo seguente: nel primo capitolo verradata una panoramica del cloud computing, evidenziandone caratteristiche,architettura, modelli di servizio, modelli di deployment ed eventuali proble-mi riguardo il cloud. Nel secondo capitolo verra data una introduzione allasicurezza in ambito informatico per poi passare nello specifico alla sicurezzanel modello di cloud computing. Verranno considerate le vulnerabilita deri-vanti dalle tecnologie e dalle caratteristiche che enucleano il cloud, per poipassare ad una analisi dei rischi. I rischi sono di diversa natura, da quelliprettamente tecnologici a quelli derivanti da questioni legali o amministra-tive, fino a quelli non specifici al cloud ma che lo riguardano comunque.Per ogni rischio verranno elencati i beni afflitti in caso di attacco e verraespresso un livello di rischio che va dal basso fino al molto alto. Ogni rischiodovra essere messo in conto con le opportunita che l’aspetto da cui quelrischio nasce offre. Nell’ultimo capitolo verra illustrato un framework per laprotezione della rete interna del cloud, installando un Intrusion DetectionSystem con pattern recognition e anomaly detection.

x

Capitolo 1

Il Cloud Computing

1.1 Storia

L’origine del termine cloud computing e sconosciuto, ma sembra proveniredalla pratica di utilizzare un disegno a forma di nuvola per rappresentareuna rete negli schemi di telefonia e, negli anni dopo, per rappresentare In-ternet nei diagrammi di reti di computer.

Il concetto alla base del cloud computing risale agli anni ’50, quando imainframe divennero disponibili al mondo accademico e alle aziende. Com-prare un mainframe era molto costoso, e per ricavare il miglior ritorno sugliinvestimenti era opportuno trovare il modo di permettere a piu utenti diaccedere allo stesso hardware e di condividere il CPU time.Negli anni ’60 John McCarthy disse che “un giorno la computazione potraessere organizzata come servizio pubblico”.

La grande disponibilita di reti ad alta capacita, la presenza di computera basso costo e l’utilizzo sempre piu diffuso di hardware virtualization, ar-chitetture service-oriented, autonomic ed utility computing ha permesso unagrande crescita nell’utilizzo del cloud computing.Amazon, nel tentativo di modernizzare i propri data centres, che utilizzava-no fino al 10% della loro capacita la maggior parte del tempo soltanto perlasciar spazio ad aumenti temporanei nell’utilizzo, svolse un ruolo chiavenello sviluppo del cloud computing. Amazon rilascio Amazon Web Services(AWS) come utility computing nel 2006.

1

2 CAPITOLO 1. IL CLOUD COMPUTING

Negli anni successivi vennero rilasciati diversi software open source per ildeploy di cloud private ed ibride, e altre grandi aziende del settore, qualiIBM, Google e Microsoft, svilupparono software per il cloud computing.[14]

1.2 Caratteristiche del Cloud Computing

• Nel cloud computing gli utenti accedono ai dati, alle applicazioni ealtri servizi utilizzando un browser indipendentemente dal dispositi-vo utilizzato e dalla posizione dell’utente. L’infrastruttura del cloudviene acceduta grazie ad Internet. La spesa per una azienda e con-siderevolmente abbattuta in quanto le infrastrutture sono offerte daterze parti e non devono essere acquistate per computing occasionale.

• Meno abilita nel campo IT sono necessarie per l’implementazione.

• L’affidabilita del servizio e ottenuta utilizzando diversi siti mirror,sistema adatto per la continuita di business e per il disaster recovery.

• La condivisione delle risorse e dei costi tra un grande insieme di utentipermette un utilizzo piu efficiente dell’infrastruttura.

• La manutenzione di applicazioni cloud e semplificata in quanto nondevono essere installate nel computer di ogni utilizzatore.

• Utilizzo del modello pay-per-use, grazie al quale l’utilizzo delle risorsepuo essere misurato e utilizzato come metro di fatturazione.

• La performance puo essere monitorata ed e quindi possibile regolarlatramite la scalabilita delle risorse. Al cliente cloud la quantita dirisorse utilizzabili spesso appare infinita in quanto puo farne richiestain ogni momento in qualunque quantita.

• La multitenancy (singolo software serve piu clienti contemporanea-mente, chiamati “tenant) permette la condivisione delle risorse e deicosti su piu utenti, permettendo la centralizzazione delle infrastrutturee l’utilizzo efficiente delle risorse. Le risorse vengono assegnate dina-micamente ai vari utenti secondo le richieste che ne fanno. Tuttaviai clienti non sanno dove vengono fisicamente memorizzati i loro datipoiche c’e location independence; questo potrebbe essere un problema

2

CAPITOLO 1. IL CLOUD COMPUTING 3

nel caso in cui l’informazione sulla posizione dei dati sia necessaria alcontesto del servizio erogato dal cliente.

• Servizio self-service on-demand permette agli utenti di ottenere, con-figurare ed effettuare il deploy di servizi cloud utilizzando cataloghi diservizi cloud, senza necessita di assistenza da parte dell’azienda pro-vider. Questo requisito porta i provider cloud a stilare template perservizi che loro offrono, da inserire in un catalogo di servizi. Ogni tem-plate contiene le configurazioni predefinite necessarie per impostare unservizio cloud pronto all’uso.

• Tecnologie di virtualizzazione permettono la condivisione di server edispositivi di memoria, facilitano inoltre la migrazione di applicazionifra piu server fisici.[17]

1.3 Architettura Cloud

L’architettura di un sistema cloud puo essere suddivisa in due macro parti:il front-end ed il back-end. Il front-end e cio che l’utente vede e con cuiinteragisce, e eseguito nel computer del cliente e consiste nell’applicazionenecessaria ad accedere al cloud, mentre il back-end e il nucleo del sistema,dove tutte le risorse e le unita di computazione che servono per far funzionareil sistema giacciono.

Guardando figura 1.1, il layer di cloud software infrastructure provve-de le risorse base che sono offerte come servizi ai layer sovrastanti: risorsecomputazionali (in genere environment di macchine virtuali), memoria ecomunicazione su rete. Questi servizi possono essere utilizzati individual-mente, come succede tipicamente con i servizi di memorizzazione, ma sonospesso offerti in “bundle”. Questi servizi offerti assieme sono spesso riferiticome Infrastructure as a Service (IaaS).

Il layer di cloud software environment fornisce servizi al livello di piat-taforma di applicazione:

• un ambiente di sviluppo ed esecuzione per servizi e applicazioni scrittiin uno dei linguaggi supportati;

• dispositivi di memoria;

3


Figura 1.1: Architettura cloud.

• infrastruttura di comunicazione;

Questo layer corrisponde al Platform as a Service (PaaS).

Le applicazioni sovrastanti, segnate come Cloud applications in figura1.1, rappresentano il Software as a Service (SaaS) e sono le applicazioni (ingenere implementate come Web Service) accessibili ai clienti del cloud.

Una delle tecnologie su cui si basa il cloud computing e la virtualizzazione.Una macchina virtuale e il contenitore logico di un sistema operativo ospitee delle applicazioni che esso esegue. E’ memorizzata come una immagine didisco e quindi puo essere trasferita da un server ad un altro. L’hypervisor

4


e cio che gestisce le macchine virtuali eseguite sullo stesso server fisico, epresenta ai sistemi operativi ospite delle viste virtualizzate dell’hardwarefisico e delle risorse. Si occupa inoltre del set-up, dello spegnimento e dellamigrazione delle macchine virtuali di cui e responsabile.

1.4 Modelli di servizio

Il cloud computing offre servizi secondo tre modelli fondamentali: Infra-structure as a service (IaaS), Platform as a service (PaaS), e Software asa service (SaaS), in cui la IaaS rappresenta il livello base e ogni modellosuperiore astrae dai dettagli del modello inferiore.

Figura 1.2: Layer cloud

I cloud client consistono in hardware o software che fanno affidamentosul cloud computing per la distribuzione di applicazioni. Sono i clienti delprovider cloud.

Una cloud application offre SaaS su Internet, eliminando la necessita diinstallare ed eseguire l’applicazione sul sistema dell’utente finale. Nel mo-dello SaaS il cloud provider installa l’applicazione software nel cloud e gli

5


utenti utilizzano i cloud client per accedervi. Caratteristiche importanti diquesto tipo di offerta e l’accesso e la gestione di software remotamente tra-mite Internet e la scalabilita delle applicazioni cloud. Le task in un cloudpossono essere clonate a tempo di esecuzione su diverse macchine virtuali persoddisfare i requisiti di risorse. Dei load balancers si occupano di distribuireil lavoro su diversi insiemi di macchine virtuali, tutto in modo trasparenteall’utente cloud. Le cloud application possono essere multitenant, cioe ognimacchina serve piu di un utente cloud, questo per utilizzare efficientementele risorse messe a disposizione, poiche se venissero utilizzate da un singoloutente per volta rischierebbero di rimanere per la maggior parte inutilizzate.

I servizi Platform (PaaS) offrono una piattaforma di computing utilizzandol’infrastruttura cloud. L’ambiente offerto tipicamente ha gia tutte le appli-cazioni necessarie al cliente. In questo modo il cliente non deve occuparsi dicomprare, installare e configurare diversi hardware e software per eseguirei suoi programmi. Tramite questo servizio gli sviluppatori possono ottene-re tutti gli ambienti di sistema necessari per il ciclo di vita dei loro software.

I servizi di Infrastructure (IaaS) offrono l’infrastruttura necessaria comeservizio, cioe computer, sia fisici che virtualizzati e altre risorse. Le macchi-ne virtuali sono eseguite dall’hypervisor e diversi hypervisor dentro lo stessocloud possono ridimensionare i servizi a seconda dei requisiti del cliente. Al-tre risorse offerte come Infrastructure sono firewall, load balancer, range diindirizzi IP e virtual local area networks.

Il cliente non deve comprare i vari server, centri di dati o risorse di rete dicui puo necessitare, ma deve occuparsi di installare, patchare e manutenerele immagini di macchine virtuali e gli applicativi di cui puo necessitare.

Un altro vantaggio chiave e che il cliente deve pagare solo per la duratadel tempo in cui utilizza il servizio. Come risultato il cliente ottiene unservizio molto velocemente a costo basso.

1.5 Modelli di deployment del servizio Cloud

Quando si offre una soluzione di cloud computing, e indispensabile deciderequale modello deve essere implementato. Ci sono quattro tipi di cloudcomputing: public cloud, private cloud, community cloud e hybrid cloud.

6


1.5.1 Public cloud

Il public cloud permette agli utenti di accedere al cloud tramite web bro-wser. Gli utenti pagano solo per il tempo di utilizzo del servizio, tuttaviai cloud pubblici sono meno sicuri rispetto agli altri modelli poiche il mezzoutilizzato, Internet, e intrinsecamente insicuro. La maggior parte dei pro-blemi di sicurezza avviene in questo tipo di cloud anche perche il cliente sirivolge a terze parti per la gestione dei propri dati, perdendone il controllofisico. Standard di sicurezza, accordi, licenze e suddivisione precisa di ruolie responsabilita deve avvenire tra cliente e provider per preservare i dati.

Figura 1.3: Tipi di cloud computing

1.5.2 Private cloud

Una soluzione del tipo private cloud prevede il deploy di un cloud all’inter-no dei confini di una azienda. Il vantaggio principale e la facilita con cui sigestisce la sicurezza, la manutenzione e gli aggiornamenti, e provvede inol-tre piu controllo sul deployment e sull’utilizo. I cloud privati possono esserecomparati alle intranet. Rispetto ai cloud pubblici, dove tutte le risorse e leapplicazioni sono gestite dal service provider e sono condivise dagli utentidel cloud, nei cloud privati questi servizi sono messi a disposizione degliutenti a livello aziendale e le risorse sono gestite dall’organizzazione stessa.

7


La sicurezza e piu alta in quanto solo gli utenti dell’organizzazione hannoaccesso al cloud privato. A questo tipo di soluzione manca uno dei vantaggiprincipali del cloud computing per il cliente, cioe l’essere indipendenti dal-la costruzione e manutenzione di una nuova infrastruttura di computing.Una azienda che decide di adottare un cloud privato dovra infatti spendereconsiderevoli risorse per implementarlo.

1.5.3 Community cloud

Nel community cloud le infrastrutture sono condivise tra diverse organiz-zazioni di una specifica comunita con interessi comuni, puo essere gestitainternamente o da terze parti, ospitata internamente o esternamente. I costisono divisi tra meno utenti rispetto ad un cloud pubblico, percio il costoper ogni utente sara maggiore e viene perso questo vantaggio caratteristicodei cloud pubblici.

1.5.4 Hybrid cloud

L’ultimo tipo di cloud, lo hybrid cloud, e composto da due o piu cloud,privati, community o pubblici, che rimangono entita uniche ma sono lega-te assieme, permettendo di offrire i benefici di un modello di deploymentmultiplo. Utilizzando il modello hybrid cloud le aziende e le persone sonoin grado di ottenere diversi gradi di fault tolerance combinati con l’usabi-lita immediata delle risorse ospitate in locale, percio senza la dipendenzadella connettivita alla rete esterna. Le architetture hybrid cloud necessita-no sia di risorse ospitate in locale che di una infrastruttura cloud off-site.In genere una cloud privata si appoggia ad una cloud pubblica; permetteall’organizzazione di soddisfare le proprie necessita utilizzando la cloud pri-vata e di utilizzare quella pubblica in caso di picchi di necessita di risorsecomputazionali.

1.6 Problemi

Il cloud computing offre innumerevoli vantaggi ma ci sono aspetti che neimpediscono la diffusione ad ampia scala.

Privacy

8


Il modello cloud e stato criticato per la facilita con cui le compagnie provi-der dei servizi cloud controllano e quindi monitorano a piacere, legalmenteo illegalmente, le comunicazioni e i dati memorizzati dei propri utenti. Laprivacy dei dati non e sicura poiche, visto che il provider utilizza tecnologiecome la virtualizzazione, i dati possono non rimanere nello stesso sistema,nello stesso centro di dati o addirittura nello stesso cloud nel caso in cui ilprovider si appoggi a sua volta ad un servizio cloud. Questo puo portare acomplicazioni legali riguardo la giurisdizione. Devono essere applicate misu-re di protezione dei dati, quali criptazione, per mantenere sicura la privacy.

Compliance

Visto che i servizi erogati da un cloud possono essere sfruttati da tuttoil mondo esistono problemi di conformita. Ad esempio clienti nell’UnioneEuropea che firmano un contratto con un cloud provider proveniente dal difuori dell’Unione Europea devono aderire ai regolamenti dell’UE riguardol’esportazione di dati personali.

Le agenzie federali americane utilizzano un processo chiamato FedRAMP(Federal Risk and Authorization Management Program) per valutare e au-torizzare prodotti e servizi cloud. Il FedRAMP consiste in un sottoinsiemedi controlli di sicurezza presenti nel NIST Special Publication 800-53 sceltispecificatamente per provvedere protezione in ambienti cloud.

Legalita

Assieme al cloud computing sono sorti anche problemi di tipo legale, qualiviolazione di trademark, problemi di sicurezza e condivisione di dati perso-nali.

Caso eclatante e la confisca di Megaupload, durante la quale il governoamericano ha considerato i dati confiscati non piu di proprieta dei clienti,accedendo ai dati personali di un utente che non aveva nulla a che fare conil motivo di confisca di Megaupload.[6]

Un problema importante riguarda la proprieta dei dati. Se una azienda

9


cloud e la proprietaria dei dati, la azienda ha certi diritti. Se una aziendacloud e invece semplicemente un “custode” dei dati, diversi diritti si appli-cano. Molti Termini di Utilizzo non parlano di questa importante questione.

Open standards

Molti cloud provider offrono API che sono ben documentate ma che so-no uniche alla loro implementazione e quindi non interoperabili. Esistonoun numero di standard aperti che mirano a portare interoperabilita e porta-bilita ma tutt’ora la migrazione da un provider ad un altro e molto difficilese non impossibile.

Sicurezza

I meccanismi di protezione tradizionali non si rivelano efficaci con questonuovo modello computazionale. La preoccupazione da parte delle azienderiguardo la sicurezza del cloud computing e fra le cose che sta ritardandol’adozione diffusa di soluzioni cloud. Questo aspetto verra discusso piu afondo durante questo elaborato.

Abuso

I clienti possono comprare servizi cloud per utilizzi ragguardevoli. I provi-der non possono tenere conto delle attivita di tutti i loro utenti per rispettodella privacy, percio e possibile che una infrastruttura venga noleggiata peressere utilizzata come base da cui lanciare attacchi.

10

Capitolo 2

La sicurezza nel cloudcomputing

“Con il termine sicurezza informatica si intende quel ramo dell’informati-ca che si occupa dell’analisi delle vulnerabilita, del rischio, delle minacce edella successiva protezione dell’integrita logico-funzionale (software) di unsistema informatico e dei dati in esso contenuti o scambiati in una comuni-cazione con un utente.”[16]

I termini information security e computer security sono spesso usati inter-cambiabilmente poiche condividono gli scopi comuni di mantenere alcuneproprieta dell’informazione, quali confidentiality, integrity e availability.

La confidentiality consiste nel prevenire la rivelazione delle informazionia individui o sistemi non autorizzati. La confidentiality e necesasria permantenere la privacy delle persone che posseggono le informazioni.

La integrity significa che i dati non possono essere modificati senza chequesto sia noto.

La availability mira a rendere i dati disponibili in qualunque momentosiano necessari.

Per ottenere un sistema sicuro si procede in diverse direzioni. Dal pun-to di vista organizzativo, si progettano ruoli e si assegnano responsabilitaben precise per ogni utilizzatore del sistema. In questo modo l’area di at-tacco di un ipotetico malfattore e piu ristretta e definita, e allo stesso tempoin corrispondenza di un attacco si ha idea da quale direzione l’attacco arrivi

11

12 CAPITOLO 2. LA SICUREZZA NEL CLOUD COMPUTING

(un attacco puo arrivare anche da un membro stesso della societa, chiamatoinsider). Dal punto di vista tecnologico si utilizzano diversi sistemi di pro-tezione adatti al contesto che si vuole proteggere.

Per poter applicare soluzioni di sicurezza ai problemi del sistema, primae bene definire quali siano i problemi, e per far questo si effettua una ana-lisi di rischio. Il National Institute of Standards and Technology (NIST)definisce rischio come “a function of the likelihood of a given threat-sourceexercising a particular potential vulnerability, and the resulting impact ofthat adverse event on the organization”. Il rischio e quindi definito in fun-zione della probabilita che una minaccia sfrutti una vulnerabilita e delleconseguenze (impact) di questo evento sulla organizzazione.Una vulnerabilita invece e definita come “a flaw or weakness in system se-curity procedures, design, implementation, or internal controls that couldbe exercised (accidentally triggered or intentionally exploited) and result ina security breach or a violation of the system’s security policy”.[15]Nelle sezioni successive verra effettuata una analisi di rischio e verranno evi-denziate alcune vulnerabilita per quanto riguarda il cloud computing. Perogni rischio verranno evidenziate le vulnerabilita che lo riguardano, la pro-babilita che una minaccia sfrutti con successo una vulnerabilita, i beni chevengono impattati dallo sfruttamento della vulnerabilita e infine un livellodi rischio dipendente dalle caratteristiche precedenti.

2.1 Il problema della sicurezza nel cloud com-

puting

Come visto, il cloud computing ha molti pregi. Offre flessibilita, deploy diservizi veloce e permette alle aziende di risparmiare trasferendo dati, in-formazioni e infrastrutture ad un provider di terze parti. In questo modol’azienda non si deve preoccupare piu di gestire le infrastrutture ma puoconcentrarsi sullo svolgere attivita di sua competenza.

Cosa succede pero ai dati quando sono trasferiti offsite, fuori dal controllofisico o logico? Visto che i cloud provider non rivelano la posizione dei datie quasi impossibile dire dove sono immagazzinati, percio l’azienda perde ilcontrollo sulla sicurezza fisica dei dati. Inoltre in un cloud pubblico tutti

12

CAPITOLO 2. LA SICUREZZA NEL CLOUD COMPUTING 13

condividono le risorse in uno spazio comune, ad esempio un pool condiviso,fuori dalla portata dell’organizzazione; e al caso limite possibile che i datidi una certa organizzazione siano immagazzinati assieme ai dati di un’orga-nizzazione concorrente. Se le informazioni sono criptate, chi e in controllodelle chiavi di criptazione/decrittazione, il provider del cloud o il cliente?Questo e molti altri problemi necessitano di risposte, e questo e uno deimotivi piu importanti per cui il cloud computing non si e ancora diffuso inmaniera estesa. Le aziende sono riluttanti ad adoperare una soluzione chesi basa sul cloud computing perche non esiste uno standard a cui i provideraderiscono che assicura un certo livello di sicurezza, e lo standard non esisteperche i problemi che affliggono il cloud computing sono molteplici e non disemplice soluzione. A questo riguardo e nato nel 2009 un gruppo chiamatoCloud Security Alliance, che puo contare tra i fondatori eBay e ING, che sioccupa di effettuare rilevazioni, educare i provider cloud e provvedere cer-tificazioni per quanto riguarda la cloud security.[9]

L’adozione del cloud computing non ci permette di trattare i soliti pro-

13


blemi di sicurezza allo stesso modo in cui si faceva con altre tecnologie. Percapire quale sia il delta che il cloud computing apporta rispetto ai proble-mi di sicurezza dobbiamo analizzare come il cloud computing influenza iproblemi di sicurezza conosciuti. [4] Come vengono influenzati i fattori dirischio (probabilita, impatto) dal cloud computing? Dal punto di vista diun utente le conseguenze non sono influenzate dall’utilizzo del cloud: il co-sto ultimo di, ad esempio, una breccia nella riservatezza delle informazioni,e esattamente lo stesso indipendentemente se la breccia e avvenuta in unambiente cloud o in una infrastruttura IT convenzionale. Per un providercloud le cose sono differenti in quanto se prima i sistemi di computazioneerano separati, ora un evento di perdita potrebbe avere un impatto moltopiu largo.Cio che l’adozione del cloud computing influenza maggiormente e la proba-bilita di un evento dannoso. Il cloud computing cambia fortemente il fattore

14


di vulnerabilita, variando il livello di accesso e le modalita di attacco dispo-nibili per un malintenzionato.

Esistono vulnerabilita specifiche al cloud percio devono esistere fattori insitialla natura del cloud computing che rendono una vulnerabilita specifica alcloud.

Verrano elencate ora le tecnologie e gli aspetti che interessano il cloudcomputing dal punto di vista della sicurezza.

Il cloud computing si basa su funzionalita provvedute da diverse tecno-logie base:

Servizi e applicazioni web. Il SaaS e il PaaS sono impensabili senza ap-plicazioni web e servizi web, in quanto le offerte SaaS sono tipicamenteimplementate come applicazioni web mentre le offerte PaaS provvedonoambienti di esecuzione e sviluppo per applicazioni web. Per quanto riguar-da le offerte IaaS, le API e i servizi utilizzati per accedervi sono tipicamenteimplementati come applicazioni/servizi web.Virtualizzazione. Queste tecnologie si basano pesantemente sulla virtualiz-zazione e visto che PaaS e SaaS si basano su una struttura IaaS di supporto,l’importanza della virtualizzazione si estende anche a questi modelli di ser-vizio.Crittografia. Molti requisiti per la sicurezza nel cloud computing possonoessere risolti soltanto usanto tecniche crittografiche.

Nella descrizione delle carattersitiche cloud, il NIST delinea gli attributiche permettono al cloud computing di offrire servizi from the conveyor beltutilizzando economia di scala:

Self-service on-demand. Gli utenti possono ordinare e gestire servizi senzainterazioni umane direttamente dal portale del provider, sfruttando inter-facce di gestione. Il commissionamento e il decommissionamento avvieneautomaticamente da parte del provider.Accesso semplice. I servizi cloud sono acceduti tramite la rete utlizzandoprotocolli standard.Pooling delle risorse. Le risorse di computazione utilizzate per erogare iservizi sono realizzate utilizzando un’infrastruttura omogenea condivisa tratutti gli utenti.

15


Elasticita rapida. Le risorse provvedute ad un servizio possono essere ridi-mensionate rapidamente.Servizio misurato. L’utilizzo delle risorse e costantemente monitorato e ri-portato per soddisfare il modello di business pay-as-you-go.

Le tecnologie che enucleano il cloud computing - applicazioni web e ser-vizi, virtualizzazione e criptografia - e le caratteristiche descritte da NIST- Self-service on-demand, accesso semplice, pooling delle risorse, elasticitarapida, servizio misurato - portano con se vulnerabilita insite alla caratte-ristica o alla tecnologia, che verranno quindi inevitabilmente trasferite alcloud. Oltre a queste vulnerabilita ne esistono di nuove, nate proprio con ilcloud computing (esempio EDoS), di cui si dovra tenere conto.

2.2 Classificazione delle vulnerabilita

Vulnerabilita dell’hypervisor

Gli attacchi al layer hypervisor sono molto attraenti per un attaccante:l’hypervisor di fatto controlla completamente le risorse fisiche e le macchinevirtuali eseguite su di esse, percio ogni vulnerabilita a questo livello sonoestremamente critiche. Sfruttare l’hypervisor significa sfruttare potenzial-mente ogni macchina virtuale. Il primo proof of concept di un attaccocontro l’hypervisor e stato fatto da King et al nel paper [18], dove gli au-tori introducono il concetto di rootkit virutal machine-based. Al tempo dipubblicazione alcune vulnerabilita furono identificate negli hypervisor piupopolari [1] che potevano essere sfruttate senza diritti amministrativi.

Uno scenario tipico raggiunto sfruttando una vulnerabilita dell’hypervisore quello del ’guest to host escape’, ad esempio ’Cloudburst’, una vulnerabi-lita di VMware documentata in [10]. Un altro scenario e il ’VM hopping’:un attaccante hackera una macchina virtuale utilizzando metodi standarde poi - utilzzando vulnerabilita dell’hypervisor - prende il controllo di altremacchine virtuali in esecuzione sullo stesso hypervisor.

Mancanza di isolamento delle risorse

16


L’utilizzo di risorse da parte di un cliente puo avere effetti sulle risorsedi una altro cliente.

Le infrastrutture di cloud computing IaaS fanno affidamento soprattuttosu design di architettura dove le risorse fisiche sono condivise da multiplemacchine virtuali e quindi clienti multipli.

Vulnerabilita nell’hypervisor possono portare ad un accesso non auto-rizzato a queste risorse condivise. Per esempio, le macchine virtuali delCliente 1 e del Cliente 2 hanno i loro hard drive virtuali salvati sullo stessoLUN (Logical Unit Number) condiviso dentro una Storage Area Network. IlCliente 2 puo essere in grado di mappare l’hard drive virtuale del Cliente 1alla sua macchina virtuale e quindi vedere ed utilizzare i dati ivi contenuti.

La mancanza di strumenti per applicare dei Termini di Utilizzo o un piuspecifico Service Level Agreement (SLA), come Quality of Service o prodottidi distributed resource scheduling (DRS), possono permettere ad un clientedi monopolizzare l’utilizzo delle risorse, causando denial of service o scarsaperformance agli altri utenti del servizio.

Mancanza di isolamento di reputazione

Si ha quando le attivita di un utente impattano la reputazione di un al-tro utente. Questo puo avvenire in un contesto di mancanza di isolamentodelle risorse, percio un attaccante riesce a manipolare a suo piacimento lerisorse di altri utenti del cloud. Tuttavia difficilmente una minaccia riescead attaccare un bersaglio specifico in quanto i dati ai quali ha accesso ingenere non sono la totalita ma solo quelli presenti in quel momento nel di-spositivo di storage fisico di cui ha il controllo.

Possibilita che la rete interna venga spiata

Questo avviene quando i clienti cloud possono effettuare port scan e al-tri test su altri clienti sulla stessa rete interna.

Vulnerabilita di autenticazione e autorizzazione

Uno scarso sistema di autenticazione e autorizzazione puo facilitare l’ac-cesso non autorizzato a risorse, il privilege escalation, l’impossibilita di te-nere sotto controllo l’uso improprio di risorse e incidenti di sicurezza, etc,

17


attraverso:

• Immagazzinamento non sicuro delle credenziali di accesso cloud daparte del cliente;

• Ruoli disponibili insufficienti;

• Credenziali immagazzinate su una macchina transitoria;

Inoltre il cloud rende gli attacchi a sistemi di autenticazione basati su pas-sword molto piu impattanti in quanto le applicazioni delle aziende ora sonoesposte su Internet. Quindi l’autenticazione basata su password diventerainsufficiente e sara necessario un sistema di autenticazione piu forte (adesempio a due fattori).

Impossibilita di processare dati in forma criptata

Homomorphic encryption: una forma di criptazione che permette di svolge-re tipi specifici di computazioni direttamente sul testo cifrato, e di ottenereun risultato criptato che corrisponde al testo cifrato del risultato dell’ope-razione effettuata sul testo in chiaro.Criptare i dati staticamente non e difficile, ma nonostante i recenti pro-gressi nella homomorphic encryption, c’e poca prospettiva che un sistemacommerciale riesca a mantenere questo tipo di criptazione durante l’ela-borazione. In un articolo, Bruce Schneier stima che effettuare una ricercaweb utilizzando keyword criptate aumenterebbe il tempo di computazionedi circa mille miliardi di volte[12]. Questo significa che per molto tempo avenire, i clienti cloud che fanno qualcosa di diverso dall’immagazzinare datidovranno fidarsi del cloud provider.

Accesso remoto alle interfacce di gestione

Le interfacce di gestione possono essere accedute da Internet per cui tutte levulnerabilita del canale sono da tenere in considerazione, come ad esempioattacchi del tipo man-in-the-middle, replay, spoofing della rete.

Vulnerabilita di criptazione della comunicazione

Queste vulnerabilita riguardano la possibilita di lettura dei dati in transito

18


tramite, ad esempio, attacchi MITM, autenticazione scarsa, accettazione dicertificati auto firmati, etc. In questo senso e bene che i dati in transitosiano sempre criptati.

Possibilita di controllo dei co-residenti

Attacchi di tipo side-channel che sfruttano mancanza di isolamento dellerisorse permettono ad un attaccante di determinare quali risorse sono con-divise da quale cliente.

Sanitization dei media sensibili

La condivisione del dispositivo fisico di memoria tra vari utenti implicache dati sensibili possono trapelare in quanto le procedure di distruzioneapplicabili al termine del servizio possono essere impossibili da implemen-tare perche, ad esempio, il media non puo essere fisicamente distrutto aconseguenza del fatto che un disco e ancora in uso da un altro utente.

Vulnerabilita nel provisioning dell’utente

• Il cliente non puo controllare il processo di approvigionamento

• L’identita del cliente non e adeguatamente verificata in fase di regi-strazione

• Avvengono ritardi nella sincronizzazione tra componenti di un sistemacloud

• Vengono create copie multiple e non sincronizzate dei dati di identita

• Le credenziali sono vulnerabili ad intercettazione e replay

Nessuna regola riguardo il massimo utilizzo di risorse

Se non c’e una maniera flessibile e configurabile per il cliente o il provider perpoter impostare il limite sull’utilizzo delle risorse, puo essere problematicoquando l’uso di una risorsa e impredicibile. In questo caso il cliente e vulne-rabile ad attacchi del tipo economic denial of service, mentre il provider (etutti i clienti che si appoggiano al provider) e vulnerabile a denial of service.

19


Procedure di gestione delle chiavi inadeguate

Le infrastrutture di cloud computing necessitano di gestione e memoriz-zazione di molti differenti tipi di chiavi; esempi includono chiavi di sessioneper proteggere dati in transito (chiavi SSL), chiavi di criptazione file, cop-pia di chiavi che identificano il provider, coppia di chiavi che identificano ilcliente e token di autorizzazione. Visto che le virtual machine non hannouna infrastruttura hardware fissa e il contenuto di un cloud tende ad esseregeograficamente distribuito, e piu difficile applicare controlli standard, co-me memorizzazione in hardware security module (HSM), alle chiavi in unainfrastruttura cloud.[13]

Gli HSM sono per necessita fortemente protetti fisicamente. Questorende molto difficile distribuirli nelle multiple posizioni usate nelle architet-ture cloud. Inoltre le interfacce di gestione delle chiavi che sono accessibilitramite Internet pubblico sono piu vulnerabili, visto che la sicurezza e di-minuita dal canale di comunicazione tra l’utente e lo storage di chiave cloud.

Generazione delle chiavi: entropia bassa per la generazione dinumeri casuali

La combinazione di immagini di sistema standard, tecnologie di virtua-lizzazione e mancanza di device di input porta il sistema ad avere entropiamolto piu bassa rispetto ai generatori di numeri random hardware. Questosignifica che un attaccante su una macchina virtuale puo essere in grado diindovinare le chiavi di criptazione generate su altre macchine virtuali perchele sorgenti di entropia sono simili. Non e un problema difficile da risolveredi per se, ma se non e considerato a tempo di design puo avere importanticonseguenze.

Immagazzinamento di dati in multiple giurisdizioni e mancanzadi trasparenza a riguardo

La memorizzazione dei dati ridondante senza disponibilita per il clientedi informazioni in tempo reale riguardo la posizione dei dati introduce unlivello di vulnerabilita. Le compagnie potrebbero inavvertitamente violareregolamenti, specialmente se non sono disponibili informazioni chiare ri-

20


guardo la giurisdizione dello storage.

Mancanza di informazioni riguardo giurisdizioni

I dati potrebbero essere immagazzinati e/o processati in giurisdizioni adalto rischio dove sono vulnerabili a confisca tramite effrazione. Se questainformazione non e disponibile al cliente, esso non puo prendere le precau-zioni necessarie per evitare il danno.

Ruoli e responsabilita non chiariPrincipio Need-to-know non applicatoApplicazione inadeguata delle definizioni dei ruoli

Queste vulnerabilita riguardano la suddivisione in ruoli e la definizione diresponsabilita di tali ruoli. Se a un ruolo vengono dati meno privilegi diquanti ne siano necessari allo svolgimento delle funzioni di tale ruolo esisteun problema. Se, in modo complementare, vengono dati troppi privilegi aun ruolo si possono creare grosse falle nell’organizzazione del provider.[2]

Mancanza di security awareness

I clienti cloud possono non essere consapevoli dei rischi che corrono migran-do al cloud, in particolare i rischi generati da minacce specifiche del cloud,quali perdita di controllo, lock-in del venditore, risorse del cloud provideresaurite, etc. Questa mancanza di consapevolezza puo anche influenzare ilcloud provider, che puo non essere al corrente delle azioni da intraprendereper mitigare questi rischi.

2.3 Analisi di rischio in ambiente Cloud

Notare i seguenti punti in relazione alle sezioni successive:

• I rischi devono essere sempre considerati in relazione all’opportunitadi business complessiva - a volte un rischio e compensato da unaopportunita.

• Il livello di rischio in molti casi varia significativamente a seconda deltipo di architettura cloud considerata.

21


• Puo capitare che il cliente cloud trasferisca il rischio al provider cloude il rischio deve essere considerato rispetto ai benefici economici rice-vuti dal provvedere questi servizi. Tuttavia non tutti i rischi possonoessere trasferiti: se un rischio porta al fallimento di un business, danniseri alla reputazione o implicazioni legali, e difficile o impossibile farcompensare questo danno a terzi.

• L’analisi di rischio e espressa dal punto di vista del cliente cloud.

2.3.1 Rischi organizzativi e di policy

2.3.1.1 Lock-in

Probabilita ALTAImpatto MEDIOVulnerabilita Mancanza di tecnologie e soluzioni standard

Poca scelta di providerMancanza di completezza e trasparenza neitermini di utilizzo

Beni afflitti Reputazione dell’aziendaDati personali sensibiliService delivery

Rischio ALTO

Il vendor lock-in consiste nel rendere il cliente dipendente ad un partico-lare venditore in quanto a prodotti e servizi, inabile nel poter cambiarevenditore senza costi di migrazione sostanziali.Correntemente l’offerta di strumenti, procedure, formati di dato standardo interfacce di servizio che possono garantire portabilita di dati e servizie praticamente nulla. Questo rende la migrazione da un provider ad unaltro estremamente difficile; in piu, i provider possono essere incentivati adimpedire la portabilita dei servizi e dei dati dei propri clienti.Questa potenziale dipendenza ad un particolare provider, a seconda degliimpegni del provider, possono portare a disastri di business catastrofici seil provider dovesse andare in bancarotta e il costo per la migrazione delservizio e dei dati dovesse essere troppo alto.L’acquisizione del cloud provider da parte di altre aziende puo avere un effet-to simile, visto che questo aumenta la probabilita di cambiamenti improvvisinelle politiche del provider o nei termini di utilizzo.[7]

22


2.3.1.2 Perdita di controllo

Probabilita MOLTO ALTAImpatto IaaS MOLTO ALTO

SaaS BASSOVulnerabilita Ruoli e responsabilita non chiari

Applicazione inadeguata delle definizioni di ruoliClausole nel SLA con promesse in conflitto perdiversi portatori di interesseRevisioni e certificazioni non disponibili ai clientiMancanza di tecnologie e soluzioni standardMancanza di informazioni riguardo giurisdizioniMancanza di completezza e trasparenza neitermini di utilizzoProprieta dei beni incerta

Beni afflitti Reputazione dell’aziendaAffidabilita verso i clientiDati personali sensibiliService delivery

Rischio ALTO

Utilizzando infrastrutture cloud, il cliente cede necessariamente il controlloal provider cloud riguardo un numero di questioni che possono influenzare lasicurezza. Per esempio i termini di utilizzo possono proibire scan delle por-te, valutazione delle vulnerabilita e penetration testing. Inoltre ci possonoessere conflitti tra le procedure di hardening del cliente e l’ambiente cloud.Il Service Level Agreement puo non offrire impegno da parte del provider aprovvedere questi servizi, lasciando un gap nelle difese.[11]

In piu il provider stesso puo dare servizi in outsourcing a compagnieterze che non offrono le stesse garanzie del provider.

23


2.3.1.3 Problemi di conformita

Probabilita MOLTO ALTAImpatto ALTOVulnerabilita Revisioni e certificazioni non disponibili ai clienti

Mancanza di tecnologie e soluzioni standardMancanza di completezza e trasparenza neitermini di utilizzo

Beni afflitti CertificazioneRischio ALTO

Certe organizzazioni migrando al cloud hanno investito considerevolmen-te nell’ottenere certificazioni per soddisfare lo standard dell’industria o perrequisiti di regolamento. Questo investimento puo essere messo a rischiomigrando al cloud in quanto:

• Il cloud provider puo non fornire prova riguardo la sua conformita alrequisito rilevante

• il cloud provider puo non permettere verifiche da parte del cliente

In alcuni casi, questo significa che utilizzare una infrastruttura cloud pub-blica implica che certi tipi di conformita non possono essere ottenute equindi i servizi ospitati nel cloud non possono essere utilizzati per serviziche necessitano tali conformita.

2.3.1.4 Perdita di reputazione a causa delle attivita di co-tenant

Probabilita BASSAImpatto ALTOVulnerabilita Mancanza di isolamento delle risorse

Mancanza di isolamento di reputazioneVulnerabilita dell’hypervisor

Beni afflitti Reputazione dell’aziendaDati personali sensibiliService delivery

Rischio MEDIO

La condivisione di risorse fa si che attivita dolose da parte di un tenant

24


possano influenzare la reputazione di un altro tenant. Per esempio, spam-ming, port scanning o servire contenuto malevolo dalla infrastruttura puoportare a:

• un range di indirizzi IP bloccati, inclusi quello dell’attaccante e di altritennat innocenti

• confisca delle risorse a causa di attivita di altri tenant

L’impatto puo essere discontinuita nel service delivery, perdite di dati eproblemi alla reputazione dell’azienda.

2.3.1.5 Supply chain failure

Probabilita BASSOImpatto MEDIOVulnerabilita Mancanza di completezza e trasparenza nei

termini di utilizzoDipendenze nascoste create da applicazioni cross-cloudPoca scelta di provider

Beni afflitti Reputazione dell’aziendaAffidabilita verso il clienteDati personali sensibiliService delivery

Rischio MEDIO

Un provider cloud puo dare in outsource alcuni compiti specializzati nel-la sua catena di produzione. In questa situazione il livello di sicurezza delcloud provider dipende dal livello di sicurezza di ogni azienda su cui fa ou-tsource. Qualunque interruzione o corruzione della catena o mancanza dicoordinazione delle responsabilita tra tutti i membri coinvolti puo portarea: interruzione del servizio, perdita di dati, confidenzialita, integrita e avai-lability, perdite econimiche e di reputazione, violazione di SLA etc.

In generale, la mancanza di trasparenza nel contratto puo essere un pro-blema per tutto il sistema. Se il provider non dichiara quali servizi coresono in outsourcing il cliente non e in grado di valutare opportunamente irischi che corre.

25


2.3.2 Rischi che riguardano aspetti tecnologici e ar-chitetturali

2.3.2.1 Esaurimento delle risorse (sotto o sovra approvigiona-mento)

Probabilita Inabilita a fornire capacita addizionale all’utente:MEDIAInabilita a fornire capacita correntemente accorda-ta: BASSA

Impatto Inabilita a fornire capacita addizionale all’utente:BASSOInabilita a fornire capacita correntemente accorda-ta: ALTO

Vulnerabilita Modellazione inaccurata dell’utilizzo delle risorseInadeguato approvvigionamento delle risorse edinvestimento in infrastruttureNessuna regola riguardo il massimo utilizzo dirisorse

Beni afflitti Reputazione dell’aziendaAffidabilita verso i clientiService delivery

Rischio MEDIO

I servizi cloud sono servizi on-demand. Per questo c’e un livello di rischiocalcolato nell’allocare tutte le risorse di un servizio cloud, perche le risorsesono allocate secondo delle proiezioni statistiche.[3] Modellazione inaccura-ta dell’utilizzo delle risorse o approvvigionamento inadeguato e investimentinelle infrastrutture inadeguati possono portare, dal punto di vista del cloudprovider, a:

• Service unavailability: fallimenti in certi scenari applicativi moltospecifici, in cui una risorsa viene utilizzata molto intensamente;

• Perdite economiche e reputazionali: a causa del fallimento nel soddi-sfare le richieste del cliente

• Sovradimensione dell’infrastruttura: approvvigionamento eccessivo puoportare a perdite economiche e di redditivita

26


2.3.2.2 Isolation failure

Probabilita BASSA (Cloud privata)MEDIA ( Cloud pubblica)

Impatto MOLTO ALTOVulnerabilita Vulnerabilita dell’hypervisor

Mancanza di isolamento delle risorseMancanza di isolamento di reputazionePossibilita che la rete interna venga spiata

Beni afflitti Reputazione dell’aziendaAffidabilita verso i clientiDati personali, anche sensibiliService delivery

Rischio ALTO

Il multi-tenancy e le risorse condivise sono due delle caratteristiche chedefiniscono l’ambiente cloud. Capacita di computazione, memorizzazione erete sono condivise tra diversi utenti. Questa classe di rischi include il falli-mento di meccanismi che si occupano di separare i dati, la memoria e anchela reputazione tra diversi utenti dell’infrastruttura condivisa (esempio conattacchi guest-hopping, sql injection su una tabella contenente dati di piuclienti, attacchi side-channel).

La probabilita di questo scenario dipende dal modello di cloud conside-rato; sara basso in un cloud privato e piu alto in cloud pubblico.

L’impatto puo essere perdita di dati sensibili, perdita di reputazione einterruzione di servizio sia per i provider che per i clienti.

27


2.3.2.3 Malicious insider - abuso di ruoli privilegiati

Probabilita MEDIAImpatto MOLTO ALTOVulnerabilita Ruoli e responsabilita non chiari

Applicazione inadeguata delle definizioni dei ruoliPrincipio Need-to-know non applicatoVulnerabilita di autenticazione e autorizzazioneVulnerabilita di sistemaProcedure di sicurezza fisica inadeguateImpossiblita di processare dati in forma criptataVulnerabilita di applicazione / patch managementinadeguato

Beni afflitti Reputazione dell’aziendaAffidabilita verso i clientiProprieta intellettuale del clienteDati sensibiliService delivery

Rischio ALTO

Un insider e un individuo all’interno dell’azienda spesso con ruoli di accessoprivilegiati che va contro gli interessi dell’azienda, ad esempio rubando datio manomettendo il sistema. Le attivita di un insider possono potenzial-mente avere impatto su: confidenzialita, integrita e disponibilita di tutti itipi di dato, proprieta intellettuale, reputazione dell’azienda e affidabilitadell’azienda rispetto ai clienti. Man mano che il cloud viene sempre piuutilizzato, gli impiegati di cloud provider diventano bersaglio di atti crimi-nali (come e stato testimoniato nell’industria dei servizi finanziari con gliimpiegati di call centre [5]).

28


2.3.2.4 Compromissione di interfacce di gestione

Probabilita MEDIAImpatto MOLTO ALTOVulnerabilita Vulnerabilita di autenticazione e autorizzazione

Accesso remoto alle interfacce di gestioneVulnerabilita di sistemaVulnerabilita di applicazione / patch managementinadeguato

Beni afflitti Reputazione dell’aziendaAffidabilita verso i clientiDati sensibiliService deliveryInterfacce di gestione del servizio

Rischio MEDIO

Le interfacce di gestione del servizio cloud per il cliente sono accessibilivia Internet e mediano l’accesso ad un insieme di risorse piu grande rispet-to ai tradizionali servizi di hosting, quindi pongono un rischio aumentato,specialmente se combinato con vulnerabilita di accesso remoto e del webbrowser. Questo include interfacce di clienti che controllano un numero al-to di virtual machine, ma soprattutto le interfacce del cloud provider checontrollano l’intero sistema cloud.

2.3.2.5 Intercettazione dati in transito

Probabilita MEDIAImpatto ALTOVulnerabilita Vulnerabilita di autenticazione e autorizzazione

Vulnerabilita di criptazione della comunicazionePossibilita che la rete interna venga spiataPossibilita di controllo dei co-residenti

Beni afflitti Reputazione dell’aziendaAffidabilita verso i clientiProprieta intellettualeDati sensibili

Rischio MEDIO

Il cloud computing, in quanto architettura distribuita, implica piu dati in

29


transito rispetto alle normali infrastrutture. Per esempio vengono trasferitidati per sincronizzare piu immagini distribuite, tra infrastrutture cloud eclient remoti, etc. In piu, molti dei servizi di hosting di dati sono imple-mentati utilizzando un ambiente vpn-like sicuro, una pratica non sempreseguita in contesto cloud.

Sniffing, spoofing, attacchi man-in-the-middle e attacchi replay sono daconsiderare possibili fonti di minaccia.

Inoltre in alcuni casi il cloud provider non offre confidenzialita o condi-zioni di non-disclosure o queste condizioni non sono sufficienti a garantirerispetto per la protezione delle informazioni segrete del cliente.[8]

2.3.2.6 Cancellazione dei dati insicura o inefficace

Probabilita MEDIOImpatto MOLTO ALTOVulnerabilita Sanitization dei media sensibiliBeni afflitti Dai personali

Dati sensibiliCredenziali

Rischio MEDIO

Quando un cliente termina la richiesta di servizio, le risorse sono ridimen-sionate, l’hardware viene riallocato, etc, e i dati possono essere disponibilioltre il tempo specificato nel contratto di sicurezza. Puo essere impossibileapplicare le procedure di eliminazione specificate nel contratto di sicurezza,visto che la cancellazione totale dei dati e possibile soltanto distruggendo ildisco che contiene anche i dati di altri clienti. Quando viene effettuata unarichiesta di cancellazione di una risorsa cloud, questo potrebbe non risultarenella cancellazione vera dei dati. Quando e necessaria la vera eliminazio-ne dei dati devono essere seguite procedure speciali e questo potrebbe nonessere supportato dalle API standard (o potrebbe non essere supportatoaffatto).

Se viene utilizzata criptazione si puo considerare piu basso il livello dirischio.

30


2.3.2.7 Distributed denial of service

Probabilita Cliente: MEDIAProvider: BASSA

Impatto Cliente: MEDIOProvider: MOLTO ALTO

Vulnerabilita Errori di configurazioneVulnerabilita di sistemaRisorse di filtraggio inadeguate o configurateerroneamente

Beni afflitti Reputazione dell’aziendaAffidabilita verso i clientiService deliveryInterfacce di gestione del servizioRete (connessioni etc)

Rischio MEDIO

2.3.2.8 Economic denial of service

Probabilita BASSAImpatto ALTOVulnerabilita Vulnerabilita di autenticazione e autorizzazione

Vulnerabilita nel provisioning dell’utenteVulnerabilita nel de-provisioning dell’utenteAccesso remoto a interfacce di gestioneNessuna regola riguardo il massimo utilizzo dirisorse

Beni afflitti Reputazione dell’aziendaAffidabilita verso i clientiService deliveryRisorse monetarie del cliente

Rischio MEDIO

L’economic denial of service e un rischio nato con il cloud computing, inparticolare per la sua natura pay-per-use. In un attacco EDoS lo scopoe di rendere il modello di fatturazione cloud insostenibile e quindi impe-dire che una compagnia riesca a utilizzare o pagare l’infrastruttura cloud.Consiste nello sfruttare vulnerabilita nel sistema di fatturazione per far sem-

31


brare legittimo l’utilizzo malevolo del servizio mentre alza i costi a livelloingestibile.

Ci sono differenti scenari in cui le risorse del cliente possono essere usateper aver un impatto economico:

• Furto d’identita: un attaccante sfrutta un account per utilizzare le ri-sorse del cliente (la vittima) per il proprio vantaggio o per danneggiareeconomicamente la vittima

• Il cliente cloud non ha impostato limiti all’utilizzo delle risorse per cuipaga e sperimenta carichi inaspettati su queste risorse tramite nessunaazione dolosa

• Un attaccante usa un canale pubblico per utilizzare le risorse per cui ilcliente paga - ad esempio, se un cliente paga per ogni richiesta HTTPricevuta, un attacco DDoS puo avere anche l’effetto di EDoS

Gli attacchi EDoS distruggono le risorse economiche; il worst case scenariosarebbe la bancarotta del cliente o un impatto economico serio.

2.3.2.9 Perdita di chiavi di criptazione

Probabilita BASSAImpatto ALTOVulnerabilita Procedure di gestione delle chiavi inadeguate

Generazione delle chiavi: entropia bassa per lagenerazione di numeri casuali

Beni afflitti Proprieta intellettualeDati personali sensibiliCredenziali

Rischio MEDIO

Include la divulgazione di chiavi segrete (SSL, chiavi di criptazione file,chiavi private del cliente, etc), la perdita o corruzione di dette chiavi, o illoro uso non autorizzato per l’autenticazione o la non-ripudiazione (firmadigitale).

32


2.3.2.10 Scan e probe malevoli

Probabilita MEDIAImpatto MEDIOVulnerabilita Possibilita che la rete interna venga spiata

Possibilita di controllo dei co-residentiBeni afflitti Reputazione dell’azienda

Affidabilita verso i clientiService delivery

Rischio MEDIO

Scan e probe malevoli, cosı come il mapping della rete, sono minacce indiret-te ai beni considerati. Possono essere utilizzati per raccogliere informazioninel contesto di un tentativo di hack. Un possibile impatto puo essere perditadi confidenzialita, integrita e disponibilita di servizi e dati.

2.3.2.11 Compromissione del service engine

Probabilita BASSAImpatto MOLTO ALTOVulnerabilita Vulnerabilita dell’hypervisor

Mancanza di isolamento delle risorseBeni afflitti Dati personali sensibili

Service deliveryRischio MEDIO

Ogni architettura cloud si basa su una piattaforma altamente specializza-ta, il service engine, che giace sopra le risorse fisiche hardware e gestisce lerisorse del cliente a diversi livelli di astrazione. Per esempio, nei cloud IaaSquesto componente puo essere l’hypervisor. Il service engine e sviluppato esupportato dai venditori di piattaforme cloud e in alcuni casi dalla commu-nity open source. Puo essere ulteriormente personalizzato dai provider dicloud computing.

Come ogni altro layer software, il codice del service engine puo avere vulne-rabilita ed e soggetto ad attacchi o failure inaspettati. Un attaccante puocompromettere il service engine manomettendolo da dentro una macchi-na virtuale (cloud IaaS), dall’ambiente di runtime (PaaS), dall’applicazione(SaaS), o tramite le sue API.

33


Manomettere il service engine puo essere utile per uscire dall’isolamento de-gli environment di diversi clienti o per acquisire l’accesso a dati ivi contenuti,per monitorarne e modificarne le informazioni contenute in maniera traspa-rente (senza interazione diretta con l’applicazione dentro l’environment delcliente), o per ridurre le risorse assegnate ad un cliente, causandone denialof service.

2.3.2.12 Conflitti tra procedure di hardening del cliente ed envi-ronment cloud

Probabilita BASSAImpatto MEDIOVulnerabilita Mancanza di completezza e trasparenza nei

termini di utilizzoClausole nel SLA con promesse in conflitto perdiversi portatori di interesseRuoli e responsabilita non chiari

Beni afflitti Proprieta intellettualeDati personali sensibili

Rischio MEDIO

I cloud provider devono impostare chiaramente una segregazione delle re-sponsabilita che articola le azioni minime che un cliente deve intraprendere.Il fallimento da parte del cliente di rendere sicuro il proprio environmentpuo costituire una vulnerabilita alla piattaforma cloud se il cloud providernon ha isolato accuratamente il sistema. I cloud provider dovrebbero arti-colare ulteriormente i loro meccanismi di isolamento e provvedere delle lineeguida per assistere i loro clienti a rendere sicure le loro risorse.

I clienti devono assumersi le loro responsabilita in quanto se non lo fan-no porrebbero i loro dati e le loro risorse ad un ulteriore rischio. In alcunicasi i clienti cloud hanno inappropriatamente dato per scontato che il cloudprovider fosse responsabile per tutte le attivita necessarie a rendere sicuri ipropri dati. Questa assunzione da parte del cliente, e/o mancanza da partedel provider di una chiara articolazione, mette sotto rischio i dati del cliente.E’ imperativo che il cliente cloud identifichi le proprie responsabilita e chele soddisfi.

34


I cloud provider, per loro natura, devono provvedere un ambiente multi-tenant; la co-locazione di molti clienti causa inevitabilmente conflitti per ilcloud provider in quanto i requisiti di sicurezza per la comunicazione di ognicliente cloud probabilmente differiscono da utente ad utente. Si prenda, adesempio, il caso di due clienti su una infrastruttura tradizionale di rete con-divisa. Se un cliente vuole che il firewall di rete blocchi tutto il trafficoeccetto SSH, mentre un altro cliente sta eseguendo un web server e neces-sita il passaggio di HTTP e HTTPS, chi vince? Lo stesso tipo di problemasi verifica per clienti che hanno requisiti conflittuali. Questo tipo di sfidapeggiora mano a mano che i clienti e la disparita dei loro requisiti aumenta.Percio i cloud provider devono essere in una posizione che permette loro ditrattare queste sfide tramite tecnologia, policy e trasparenza.

2.3.3 Rischi legali

2.3.3.1 Sub poena

Probabilita ALTAImpatto MEDIOVulnerabilita Mancanza di isolamento delle risorse

Immagazzinamento di dati in multiple giurisdizio-ni e mancanza di trasparenza a riguardoMancanza di informazioni riguardo giurisdizioni


Rischio ALTO

Sub poena e una espressione di origine latina per designare il diritto di unorganismo statuale (in genere un giudice) di costringere la testimonianza diun teste o la produzione di elementi di prova con l’avviso che il mancatorispetto comporta una sanzione.Nell’evento di confisca di hardware fisico come risultato di sub poena, lacentralizzazione della memoria assieme alla tenancy condivisa dell’hardwarefisico pone molti clienti a rischio di divulgazione dei propri dati a terzi.

35


Contemporaneamente, puo essere impossibile per una agenzia di una singolanazione confiscare un cloud dati i progressi riguardo la migrazione a lungadistanza di macchine virtuali da parte di un hypervisor.

2.3.3.2 Rischi derivanti dai cambi giurisdizionali

Probabilita MOLTO ALTAImpatto ALTOVulnerabilita Mancanza di informazioni riguardo giurisdizioni

Immagazzinamento di dati in multiple giurisdizio-ni e mancanza di trasparenza a riguardo


Rischio ALTO

I dati dei clienti potrebbero residuare in multiple giurisdizioni, alcune dellequali potrebbero essere un rischio. Se i centri dei dati sono localizzati inpaesi ad alto rischio, esempio quelli la cui struttura legislativa risulta im-prevedibile, stati di polizia autocratici, stati che non rispettano gli accordiinternazionali etc, i dati possono essere divulgati o confiscati dalle autoritalocali.

2.3.3.3 Rischi di protezione dati

Probabilita ALTAImpatto ALTOVulnerabilita Mancanza di informazioni riguardo giurisdizioni

Immagazzinamento di dati in multiple giurisdizio-ni e mancanza di trasparenza a riguardo


Rischio ALTO

Il cloud computing pone diversi rischi per la protezione dei dati per i clientcloud e per i provider.

36


• Puo essere difficile per il cliente tenere sotto controllo l’elaborazionedei dati da parte del provider, e quindi essere sicuro che i dati sia-no gestiti in maniera legale. Deve essere chiaro che il cliente cloudsara il principale responsabile per l’elaborazione dei dati personali,anche quando questa elaborazione viene effettuata da parte del pro-vider cloud. Fallimenti nel rispettare le leggi di protezione dei datipuo portare a sanzioni di tipo amministrativo, civile o addirittura pe-nale. D’altra parte alcuni cloud provider forniscono informazioni intal senso, provvedendo riassunti riguardo le elaborazioni dei dati chehanno effettuato, le loro attivita di security sui dati e i controlli chepraticano.

• Ci possono essere brecce di sicurezza che non sono notificate al con-trollore (il cliente) da parte del provider.

• Il cliente potrebbe perdere il controllo dei dati elaborati dal provi-der. Il problema e aumentato in caso di multipli trasferimenti di dati(esempio tra cloud provider fedarati).

• Il cloud provider puo ricevere dati che non sono stati ottenuti legal-mente da parte del cliente.

2.3.3.4 Rischi riguardanti le licenze

Probabilita MEDIAImpatto MEDIOVulnerabilita Mancanza di completezza e trasparenza nei

termini di utilizzoBeni afflitti Reputazione dell’azienda

Service deliveryCertificazione

Rischio MEDIO

Condizioni di licenza, come agreement per-seat e controlli di licenza on-line possono diventare inapplicabili in un ambiente cloud. Per esempio, seil software e addebitato per ogni istanza ogni volta che una nuova macchinae istanziata allora i costi di licenza dell’utente cloud puo aumentare espo-nenzialmente anche se usa lo stesso numero di istanze di macchine per lastessa durata.

37


2.3.4 Rischi non specifici al cloud

In questa sezione verra elencata una serie di minacce non specifiche al cloudma che vanno comunque considerate attentamente quando si valutano irischi di un tipico sistema cloud.

2.3.4.1 Rottura della rete

Probabilita BASSAImpatto MOLTO ALTOVulnerabilita Errori di configurazione

Vulnerabilita del sistema o dell’OSMancanza di isolamento delle risorseMancanza o inadeguatezza di un disaster recoveryplan

Beni afflitti Service deliveryRischio MEDIO

Uno dei rischi piu grandi. Potenzialmente migliaia di utenti ne sono in-fluenzati contemporaneamente.

2.3.4.2 Gestione di rete (congestione di rete / errori di configu-razione / uso non ottimale)

Probabilita MEDIAImpatto MOLTO ALTOVulnerabilita Errori di configurazione

Vulnerabilita del sistema o dell’OSMancanza di isolamento delle risorseMancanza o inadeguatezza di un disaster recoveryplan

Beni afflitti Reputazione dell’aziendaAffidabilita verso i clientiService deliveryRete (connessioni, etc)

Rischio ALTO

38


2.3.4.3 Privilege escalation

Probabilita BASSAImpatto ALTOVulnerabilita Vulnerabilita di autenticazione e autorizzazione

Vulnerabilita nel provisioning dell’utenteVulnerabilita nel de-provisioning dell’utenteVulnerabilita dell’hypervisorRuoli e responsabilita non chiariApplicazione inadeguata delle definizioni dei ruoliErrori di configurazione

Beni afflitti Dati personali sensibiliControllo di accessoDirectory utente (dati)

Rischio MEDIO

2.3.4.4 Attacchi di social engineering

Probabilita MEDIAImpatto ALTAVulnerabilita Mancanza di security awareness

Vulnerabilita nel provisioning dell’utenteMancanza di isolamento delle risorseVulnerabilita di criptazione della comunicazioneProcedure di sicurezza fisica inadeguate

Beni afflitti Reputazione dell’aziendaAffidabilita verso il clienteProprieta intellettualeDati personali sensibiliControllo di accessoCredenziali

Rischio MEDIO

39


2.3.4.5 Accesso non autorizzato agli edifici aziendali (incluso ac-cesso fisico alle macchine)

Probabilita MOTLO BASSAImpatto ALTOVulnerabilita Procedure di sicurezza fisica inadeguateBeni afflitti Reputazione dell’azienda

Affidabilita verso il clienteDati personali sensibiliBackup o dati archiviati

Rischio MEDIO

Visto che i cloud provider concentrano le risorse in diversi data centre,anche se i controlli del perimetro fisico sono probabilmente piu forti delnormale, l’impatto di una breccia in quei controlli e piu alta in quanto lasicurezza dei dati di tutti i clienti le cui risorse sono memorizzate in quelcentro di dati e compromessa.

40

Capitolo 3

Cloud Network SecurityFramework

Il cloud computing porta con se una gamma talmente ampia di rischi checonsiderare una soluzione integrata e impossibile. Cio che si puo fare e la-vorare su singoli o gruppi molto legati di fattori di rischio (vulnerabilita)cercando di risolvere problemi con aspetti condivisi.Di seguito verra discusso un framework per il cloud security che si occupadi risolvere il problema di intrusione nella rete cloud.

In questo framework, proposto da Modi, Patel, Borisanya, Patel e Rajarajanal 5th International Conference on Security of Information and Networks,viene proposto di integrare un network intrusion detection system (NIDS)nella infrastruttura cloud. Viene utilizzato snort e un decision tree classifierper rilevare gli attacchi nella rete, mentre viene mantenuta la performancee la qualita del servizio.

L’obiettivo del framework e quello di rilevare intrusi in reti tradizionalie virtuali nel cloud, e di ridurre i falsi allarmi con costo computazionaleabbordabile.

41

42 CAPITOLO 3. CLOUD NETWORK SECURITY FRAMEWORK

3.1 Background teorico

3.1.1 Snort

Per il rilevamento basato su signature viene utilizzato Snort, un packet snif-fer e NIDS molto conosciuto ed open source. E’ configurabile, gratuito, puoessere eseguito su diversi tipi di piattaforme ed e costantemente mantenutoaggiornato. Snort cattura i pacchetti di dati nella rete e controlla il lorocontenuto confrontandoli con pattern predefiniti alla ricerca di correlazioni.Il detection engine di Snort permette di registrare, allertare e risponderead ogni attacco conosciuto. L’unico problema e che Snort non puo rilevareattacchi sconosciuti. Per questo viene utilizzato un decision tree classifier,un approccio proprio del machine learning.

3.1.2 Decision Tree Classifier

Per il rilevamento di anomalie, viene utilizzata una tecnica di DT Classi-fier, che costruisce una struttura ad albero dalla cima alla base. Nell’alberogenerato ogni nodo rappresenta il nome della caratteristica del pacchetto,ogni foglia indica la classe e ogni ramo rappresenta un risultato (o valore)del nodo associato. Dopo aver generato l’albero, vengono definite regoletracciando ogni percorso dalla radice alle foglie. I DT possono classificaregrandi quantita di dati con velocita di apprendimento piu alta rispetto adaltre tecniche di classificazione e ha una precisione di rilevamento piu alta.In questo approccio viene utilizzato l’algoritmo ID3, costruendo l’albero de-cisionale in questo modo:Input: Training set di pacchetti D.Output: Albero decisionale T.Step 1:

• Se tutti i pacchetti nel dataset D sono normali, crea un nodo “Normal”e si ferma.

• Se tutti i pacchetti nel dataset D sono intrusioni, crea un nodo “In-trusion” e si ferma.

42

CAPITOLO 3. CLOUD NETWORK SECURITY FRAMEWORK 43

• Altrimenti sceglie una caratteristica F con valori f1, f2,... fn, e crea unnodo decisionale.

Step 2:Partiziona i training packets in D in sottoinsiemi D1, D2,...,Dn a secondadei valori di F.Step 3:Applica l’algoritmo ricorsivamente per ogni insieme Di.

Per scegliere le caratteristiche su cui fare split nell’albero decisionale, vie-ne calcolato il guadagno informativo per ogni caratteristica. Quindi vie-ne scelta la caratteristica con maggior guadagno informativo. Il guadagnoinformativo per ogni attributo e derivato dalle equazioni 3.1, 3.2 e 3.3.

Info(D) = −m∑i=1

Pi × log2(Pi) (3.1)

Dove m e il numero di classi, Pi la probabilita che un pacchetto in Dappartenga alla classe Ci, calcolato da |Ci, D|/|D|.

Info F (D) = −v∑

j=1

(|Dj|/|D|)× Info(Dj). (3.2)

Gain(F ) = Info(D)− Info F (D). (3.3)

L’equazione 3.2 indica l’informazione necessaria dopo aver utilizzato F perdividere D in v parti, mentre l’equazione 3.3 rappresenta l’informazione gua-dagnata effettuando branching sulla caratteristica F.Dopo aver costruito l’albero T, vengono generate delle regole nella formaIF THEN ELSE tracciando ogni percorso dalla radice alle foglie. Per esem-pio, un percorso ha nodi (F1, F2, F3, F4) e foglia Ci allora la regola derivatae: IF F1.value=f1 AND F2.value=f2 AND F3.value=f3 AND F4.value=f4THEN Ci. Percio vengono generate regole per ogni percorso nell’albero,che sono poi utilizzate per classificare le class label di pacchetti di testsconosciuti.

43


3.2 NIDS framework per il cloud

3.2.1 Obiettivi di design

• Rilevamento di intrusioni in una rete cloud

• Basso numero di falsi positivi e falsi negativi

• Alta precisione

• Costo computazionale basso e velocita di rilevamento alta

• Scalabilita

• Compatibilita

3.2.2 Integrazione del NIDS nel cloud

I servizi cloud computing, in quanto web service, possono essere visti comecomposti da due parti: il front-end (lato user) e il back-end (lato server).Gli utenti cloud sono in grado di comunicare con il cloud tramite front-end, accedendo cosı indirettamente alla rete interna. La rete interna e

Figura 3.1: Possibli integrazioni del NIDS nel cloud.

44


progettata per l’interconnettivita tra macchine virtuali. Nel cloud Amazon,ad esempio, le macchine virtuali hanno due IP, uno pubblico e uno privato.Le MV possono comunicare direttamente utilizzando la rete privata, mentreil NAT mappa l’ip pubblico della MV a quello privato.Ci sono diversi livelli a cui il NIDS puo lavorare nel cloud: sul front-end, sulback-end e su ogni singola macchina virtuale. Ci sono pro e contro riguardoad ogni scelta:

• Integrare il NIDS nel front-end aiuta a rilevare intrusioni dalla reteesterna, ma non si e in grado di rilevare attacchi dalla rete interna.

• Posizionare il NIDS a livello di back-end aiuta il rilevamento di intrusinella rete interna del cloud rilevando allo stesso tempo anche quellinella rete esterna.

• Integrare il modulo NIDS su ogni macchina virtuale aiuta l’uten-te a rilevare l’intrusione sulla sua macchina virtuale. Tale configu-razione necessita di multiple istanze del NIDS, rendendo la gestio-ne dei NIDS complessa poiche le macchine virtuali possono migraredinamicamente.

3.2.3 Architettura del modulo NIDS

Il modulo NIDS consiste in quattro parti principali: packet preprocessing,intrusion detection (composto da signature based detection e anomaly de-tecion), memoria (knowledge base, behavior base e central log) e sistema diallarme.

Il modulo di packet preprocessing si occupa di rimuovere informazioniridondanti che non hanno alcuna relazione con il rilevamento.

Il modulo di intrusion detection consiste in Snort e nel Decision TreeClassifier. Snort e utilizzato per rilevare attacchi conosciuti correlando ipacchetti catturati con regole presenti nella knowledge base. Il DT Classifiercostruisce un albero decisionale utilizzando la behavior base e stabilisce leclass label dei pacchetti.

La memoria consiste in tre database. Il knowledge base immagazzina lesignature di attacco conosciute, mentre il behavior base contiene i compor-tamenti considerati dannosi e quelli normali. Il central log e utilizzato perregistrare eventi considerati dannosi da Snort o dal DT classifier. I moduli

45


Figura 3.2: Architettura del modulo NIDS

NIDS impiegati su altri server possono aggiornare la loro knowledge base ebehavior base in corrispondenza di un aggiornamento del central log.

L’alert system e utilizzato per generare un allarme in caso di anomalierilevate da Snort o dal DT Classifier.

Nell’approccio considerato il NIDS osserva pacchetti sia dalla rete in-terna che dalla rete esterna. Snort confronta i pacchetti catturati con leregole presenti nel knowledge base. Se viene trovata una correlazione, vienegenerato un allarme che viene inviato al central log, dopodiche il pacchettoviene scartato. I pacchetti normali vengono applicati al DT classifier chedetermina le class label per tali pacchetti. Se il DT classifier trova intru-sioni verra generato un allarme che verra inviato al central log, altrimenti ipacchetti vengono considerati eventi normali.

La combinazione di rilevamento signature based e behavior based au-menta la precisione di rilevamento del sistema; inoltre il metodo signa-ture based e applicato prima di quello behavior based, riducendo i costicomputazionali.

46


I NIDS installati su tutti i server che si basano sullo stesso central logaggiornano la loro behavior e knowledge base ogni volta che un allarme vienememorizzato nel central log: in questo modo un attacco svolto su piu servercontemporaneamente potra essere velocemente rilevato su tutti i server daSnort.

Di seguito un esempio che dimostra il funzionamento del DT Classifierutilizzando un dataset esemplificativo.

Tabella 3.1: Dataset campione

ID Protocol Type Service Flag Land Class1 TCP HTTP S1 0 Normale2 TCP HTTP S1 1 Normale3 UDP HTTP S1 0 Intrusione4 ICMP SMTP S1 0 Intrusione5 ICMP FTP S0 0 Intrusione6 ICMP FTP S0 1 Normale7 UDP FTP S0 1 Intrusione8 TCP SMTP S1 0 Normale9 TCP FTP S0 0 Intrusione10 ICMP SMTP S0 1 Intrusione11 TCP SMTP S0 1 Intrusione12 UDP SMTP S0 1 Intrusione13 UDP HTTP S0 0 Intrusione14 ICMP SMTP S1 1 Normale

L’algoritmo del DT trova per primo la caratteristica migliore (quella coninformation gain piu alto) utilizzando le equazioni 3.1, 3.2 e 3.3. La sele-zione della caratteristica procede in questo modo:Prima viene calcolato Info(D):

Info(D) = −(9/14)× log2(9/14)− (5/14)× log2(5/14) = 0.940 (3.4)

Dove (9/14) e la probabilita di intrusione mentre (5/14) e la probabilita diattivita normale.Dopodiche viene calcolato il guadagno informativo per ogni caratteristica.

47


Ad esempio, a seconda del Protocol Type:

InfoProtocolType(D) = (5/14)×I(2, 3)+(4/14)×I(4, 0)+(5/14)×I(3, 2) = 0.694(3.5)

Dove (5/14)×I(2,3) significa che per il protocollo TCP ci sono 5 istanze su14 con 2 Intrusioni e 3 pacchetti Normali; (4/14)×I(4,0) significa che peril protocollo UDP ci sono 4 istanze su 14 con 4 Intrusioni e 0 pacchettiNormali e cosı via per il protocollo ICMP. Infine

Gain(Protocol Type) = Info(D) - InfoProtocolType(D) = 0.246

Allo stesso modo, Gain(Service) = 0.029, Gain(Flag) = 0.151 e Gain(Land)= 0.048. In questo caso Gain(Protocol Type) e piu alto delle altre carat-teristiche percio il DT Classifier sceglie per primo Protocol Type. Questaprocedura e applicata ricorsivamente per costruire l’albero decisionale T,mostrato in figura 3.3.

Figura 3.3: Albero decisionale

Dopo aver costruito l’albero decisionale T, vengono generate delle regoleper ogni percorso dalla radice a ogni foglia di T.

Avendo un pacchetto sconosciuto X = (Protocol Type = TCP, Service= SMTP, Flag = S0, Land = 0) applicandolo al DT Classifier scopriamotramite la regola 2 che il pacchetto e una intrusione; in questo modo il DTClassifier stabilisce le classi di pacchetti sconosciuti nel cloud.

48


Tabella 3.2: Regole derivate

No. Rule Risultato1 If Protocol Type = TCP AND Flag = S1 Then Normal2 If Protocol Type = TCP AND Flag = S0 Then Intrusion3 If Protocol Type = UDP Then Intrusion4 If Protocol Type = ICMP AND Land = 1, Then Normal5 If Protocol Type = ICMP AND Land = 0, Then Intrusion

3.3 Valutazione del NIDS nel cloud

3.3.1 Setup

Per testare il modulo NIDS e stato utilizzato un cloud open source chiama-to Eucalyptus installato su sistema operativo Ubuntu. Il modulo NIDS einstallato sul back-end; viene utilizzato Scapy per inviare pacchetti perso-nalizzati sulla rete; sia su front-end che su back-end e eseguito Wiresharkper monitorare il traffico; per il logging delle intrusioni viene utilizzato undatabase MySql.Per il training del DT Classifier sono stati utilizzati due dataset, il NSL-KDD e il KDD. Il KDD e uno dei pochi dataset pubblici per il machinelearning mentre il NSL-KDD e un miglioramento del KDD mirato a soppe-rire ad alcuni difetti nel KDD.Le class labels dei training set erano 25 ma sono state convertite in solodue: Normal ed Intrusion. Le caratteristiche in questi dataset erano 41 mane sono state utilizzate 17 in quanto la classificazione di 41 caratteristichedel dataset KDD diminuisce la precisione di rilevamento. Le caratteristichecon valori continui (src bytes, dst bytes, count e srv count) sono state nor-malizzate in 100 blocchi di dimensione 500.E’ stata calcolata la percentuale di veri positivi (TPR), falsi positivi (FPR),veri negativi (TNR), falsi negativi (FNR), fitness, F score, accuracy e costocomputazionale per valutare l’adeguatezza del modulo NIDS all’utilizzo nelCloud.

49


3.3.2 Risultati e discussione

I risultati sono riportati in tabella 3.3. Viene mostrato che il NIDS haprecisione alta (maggiore di 95%) in entrambi i dataset. La percentuale diveri positivi e piu alta nel KDD e mostra che il 96.25% delle intrusioni vienericonosciuto come Intrusione. In entrambi i dataset il TNR e piu alto delTPR, cio significa che il NIDS predilige il non generare allarmi inutili.

Tabella 3.3: Performance results

Dataset Precision TPR TNR FPR FNRNSL-KDD 95.45 76.80 95.15 4.85 23.20KDD 99.32 96.25 98.08 1.92 3.75

Indicati in tabella 3.4 sono fitness, accuracy e F score. Il valore di fitnessvaluta quanto il modulo riesca a rilevare bene le intrusioni in presenza dipredizioni sbagliate, mentre l’accuracy indica la percentuale di predizioniveritiere. Lo F score e la media armonica tra TPR e precision dove laprecision indica la percentuale di intrusioni avvenute che sono state rilevatedal NIDS.

Tabella 3.4: Performance results

Dataset Fitness Accuracy F scoreNSL-KDD 72.00 84.31 85.11KDD 94.33 96.71 97.76

Come mostrato nelle figure 3.4 e 3.5, servono meno di 2 secondi al NIDSper testare le 311,029 istanze di dato del KDD, mostrando un costo compu-tazionale basso. Il sistema e facilmente scalabile in quanto possono essereaggiunte nuove regole a Snort senza modificare quelle preesistenti; inoltre,i moduli NIDS possono essere aggiunti e rimossi dal Node Controller senzamodificare quelli esistenti, visto che ogni modulo NIDS agisce indipendente-mente. Il NIDS proposto e compatibile con ogni protocollo di comunicazionee piattaforma come Windows e Linux.

50


Figura 3.4: Tempo di training necessario al NIDS

Figura 3.5: Tempo di testing necessario al NIDS

51


52

Capitolo 4

Conclusioni

Il cloud computing e in perenne sviluppo; mano a mano che il campo progre-disce, emergeranno di sicuro ulteriori vulnerabilita mentre altre diverrannomeno rilevanti. Il problema della privacy dei dati diventa piu prominenterispetto alle reti tradizionali in quanto il cliente perde il controllo fisico suidati, e si deve fidare del provider. Le aziende spesso non si fidano a cedereil controllo dei propri dati, evitando quindi di migrare verso una soluzionecloud. Un’altra complicazione e la difficolta con cui avviene il cambio diprovider.

Il grosso problema comune a queste questioni e la mancanza di standarde certificazioni a cui il provider puo essere conforme che danno sicurezzaal cliente. La presenza di standard in quanto ad API e interfacce di ge-stione faciliterebbe la migrazione da un provider ad un altro evitando illock-in, mentre clausole specifiche nei Termini di Utilizzo e nel Service Le-vel Agreement dovrebbero mettere in chiaro aspetti che risultano importantiper quanto riguarda la fiducia trasmessa al cliente. Ad esempio, i cloud pro-vider dovrebbero rilasciare ai clienti i propri rapporti riguardo lo stato dellasicurezza dell’infrastruttura e la valutazione dei rischi. La difficolta dei ser-vizi cloud ad essere conformi a certi tipi di standard li esclude totalmenteda certi utilizzi: ad esempio le organizzazioni che gestiscono le informazionidelle carte di credito dei clienti devono per forza essere conformi allo stan-dard PCI DSS (Payment Card Industry Data Security Standard), tuttavial’implementazione dei controlli requisiti da questo standard in ambientecloud risulta esageratamente complicata, percio non ci sono servizi cloudche offrono questa funzionalita.

53

54 CAPITOLO 4. CONCLUSIONI

Non tutti i problemi riguardano il provider ma anche il cliente cloud eresponsabile della sicurezza dell’ambiente cloud, criptando i dati memoriz-zati nel cloud per maggiore sicurezza ed evitando di aggiungere contenutopericoloso alla sua parte di cloud. Sia i clienti che i provider cloud vannoeducati ai rischi e alle buone pratiche di sicurezza per l’utilizzo del cloud. Inquesto senso la Cloud Security Alliance offre training di diverso livello persensibilizzare gli utilizzatori del cloud sulla sicurezza del cloud computing,oltre a diverse certificazioni per le aziende.

In conclusione, la direzione giusta per un utilizzo piu sicuro del cloud eper trasmettere sicurezza ai potenziali clienti e quella di educare i provideralle buone pratiche per la sicurezza del cloud e all’utilizzo di software sicuro,poi stabilire standard potenti ai quali le aziende provider devono aderire,che comprendono un certo livello di sicurezza interna al cloud e feedback surichiesta verso l’utente, come ad esempio lo stato di sicurezza del cloud e lalocazione fisica dei propri dati.

54

Ringraziamenti

Ringrazio la mia famiglia e miei amici, che mi sono stati vicino e mi hannodato supporto durante questo percorso di studi.

55

56 CAPITOLO 4. CONCLUSIONI

56

Bibliografia

[1] Secunia advisories. http://secunia.com/advisories/37081/,http://secunia.com/advisories/36389/.

[2] C. S. Alliance. Top threats to cloud computing v1.0, 2010.

[3] A. Behl. Emerging security challenges in cloud computing: An in-sight to cloud security challenges and their mitigation. In World Con-gress on Information and Communication Technologies (WICT), 2011,Mumbai, 2011.

[4] E. S. Bernd Grobauer, Tobias Walloschek. Understanding cloudcomputing vulnerabilities, 2011. www.computer.org/security.

[5] R. Buchanan. Call centres infiltrated by gangs.http://news.bbc.co.uk/2/hi/uk news/scotland/glasgow and west/6089736.stm.

[6] J. S. Cindy Cohn. Megaupload and the government’s attack on cloudcomputing. https://www.eff.org/deeplinks/2012/10/governments-attack-cloud-computing.

[7] G. H. Daniele Catteddu. Cloud computing, benefits, risks andrecommendations for information security, 2009.

[8] S. H. Farhan Bashir Shaikh. Security threats in cloud computing.In 6th International Conference on Internet Technology and SecuredTransactions, Abu Dhabi, 2011.

[9] S. Farzad. Cloud computing security threats and responses. In Interna-tional Conference on Communication Software and Networks (ICCSN),2011 IEEE 3rd, Xi’an, 2011.

57

58 BIBLIOGRAFIA

[10] K. Kortchinsky. Secunia advisories.http://www.immunityinc.com/documentation/cloudburst-vista.html.

[11] W. Liu. Research on cloud computing security problem and strategy.In Consumer Electronics, Communications and Networks (CECNet),2012 2nd International Conference, Yichang, 2012.

[12] B. Schneier. Homomorphic encryption breakthrough.http://www.schneier.com/blog/archives/2009/07/homomorphic enc.html.

[13] M. R. P. Srinivasanm Sarukesi, Rodrigues. State-of-the-art cloud com-puting security taxonomies: A classification of security challenges inthe present cloud computing environment. In ICACCI ’12, Chennai,India, 2012.

[14] Wikipedia. Cloud computing. http://en.wikipedia.org/wiki/Cloud computing.

[15] Wikipedia. Information security. http://en.wikipedia.org/wiki/Information security.

[16] Wikipedia. Sicurezza informatica.http://it.wikipedia.org/wiki/Sicurezza informatica.

[17] K. M. Yashpalsinh Jadeja. Cloud computing - concepts, architectu-re and challenges. In 2012 International Conference on Computing,Electronics and Electrical Technologies [ICCEET], Kumaracoil, 2012.

[18] Yi-Min Wang, Samuel T King et Al. Subvirt: Implementing malwarewith virtual machines. 2006.

58

IL PROBLEMA DELLA SICUREZZA NEL CLOUD COMPUTING

Documents

Transcript of IL PROBLEMA DELLA SICUREZZA NEL CLOUD COMPUTING