L’intrusion detection nel Cloud Computing

Gli attacchi ai sistemi e ai dati sono una realtà con cui bisogna confrontarsi pressoché quotidianamente. Rilevare e rispondere a questi attacchi è ormai una norma, ed è considerata una due diligence quando si parla di sicurezza.

È un dato di fatto che la maggior parte degli standard e delle regolamentazioni applicate in ambito informatico, hanno esplicite istruzioni in merito alla necessità di monitoraggio e di allarme, istruzioni che solitamente sono chiamate intrusion detection.

In questo articolo, analizzeremo alcuni degli aspetti di intrusion detection (ID) che dovrebbero essere applicati in un ambiente Cloud. Vedremo dove l’ID può essere applicato e da chi, ma vedremo anche alcuni percorsi che sta intraprendendo l’ID e che dovrebbero essere considerati non appena saranno disponibili.

Intrusion detection e il modello di Cloud Computing

La capacità di effettuare l’ID nel Cloud dipende fortemente dal modello di Cloud Computing che si sta utilizzando:

• • Software as a Service (SaaS). Gli utenti SaaS devono contare quasi esclusivamente sul loro provider per eseguire l’ID. Si può avere la possibilità di ottenere alcuni log e di implementare un monitoraggio e alert personalizzati su tali informazioni, ma la maggior parte dell’ID sarà effettuata dal provider.

• • Platform as a Service (PaaS). Come nel SaaS, la maggior parte dell’ID per questo livello di servizio sarà effettuata dal provider. Dato che i sistemi di intrusion detection (IDS) sono in genere al di fuori dell’applicazione, è necessario contare sul provider per implementarli in un PaaS. È possibile, tuttavia, configurare le applicazioni e le piattaforme di accesso da una posizione centrale attraverso la quale impostare il monitoraggio e l’alerting (e quindi eseguire l’ID).

• Infrastructure as a Service (IaaS). Questo è il modello più flessibile per il deployment dell’ID. A differenza dei due precedenti, l’IaaS vi dà più opzioni. Ed è proprio all’IaaS che dedicheremo la maggior parte di questo articolo.

Intrusion detection per l’IaaS: dove dovrebbe essere eseguita?

E’ necessario individuare i punti di snodo che dovrebbero essere considerati quando si parla di ID nel Cloud IaaS. In questo senso vediamo quattro principali “punti”:

• Nella stessa macchina virtuale (VM). Il deployment dell’ID nella VM consente di monitorare l’attività del sistema e rilevare e segnalare problemi che potrebbero sorgere.

• Nell’hypervisor o nel sistema host. Il deployment dell’ID nell’hypervisor permette di monitorare non solo l’hypervisor stesso, ma qualsiasi cosa viaggi tra le macchine virtuali su tale hypervisor. Si tratta di una posizione più centralizzata per l’ ID, ma ci possono essere problemi nel mantenere sempre il medesimo livello di prestazioni o si possono perdono alcune informazioni se la quantità di dati è elevata. Inoltre, come vedremo, questo ambito è ancora piuttosto immaturo.

• Nella rete virtuale. Il deployment dell’ID per monitorare la rete virtuale (cioè, la rete istituita all’interno dello stesso host) consente di tenere sotto controllo il traffico di rete tra le macchine virtuali sull’host, ma anche il traffico tra le macchine virtuali e l’host. Questo traffico “di rete” non riguarda la rete tradizionale.

• Nella rete tradizionale. Il deployment dell’ID consente di monitorare, rilevare e alert sul traffico che passa nell’infrastruttura di rete tradizionale.

Chi è responsabile dell’ intrusion detection nel Cloud?

Un aspetto da chiarire immediatamente è chi e in che modo sarà responsabile per l’ID nel Cloud. Dal nostro punto di vista ci sono le seguenti regole di base:

• I provider utilizzeranno l’ID in certe location che si trovano all’interno del loro (e non del vostro) IDS.

• Dovete avere un Service-Level Agreement (SLA) che imponga ai provider di notificarvi se siete oggetto di un attacco indiretto (cioè verso le vostre macchine virtuali) oppure diretto (cioè verso un hypervisor che sta facendo girare le VM).

• Se e quando si distribuisce l’ID, dovrebbe essere integrato (in qualche modo) nell’infrastruttura di monitoraggio e di alerting esistente.

• E’ probabile che in futuro ci saranno soluzioni di terzi che forniranno l’IDS per il Cloud, e che questo sarà solo un costo aggiuntivo per coloro che non desiderano gestire l’ID nelle proprie istanze Cloud.

Esecuzione dell’intrusion detection nel Cloud

Quindi, ora che sappiamo dove dobbiamo/possiamo eseguire l’ID nel Cloud, ci possiamo chiedere, “Come possiamo farlo?”

• • Un tradizionale sistema di intrusion detection host
    La prima opzione è il tradizionale sistema host intrusion detection (HIDS). È possibile utilizzare un HIDS sulla macchina virtuale così come sull’host/hypervisor. L’HIDS sulla VM dovrebbe essere implementato, gestito e monitorato da voi, mentre l’HIDS sull’hypervisor sarebbe responsabilità del provider. Se si desidera includere una qualsiasi delle informazioni di ID relative all’hypervisor nel proprio IDS, allora ci si deve coordinare con il proprio fornitore.
    In realtà, molto probabilmente non sarà possibile ottenere tali informazioni, per cui il contratto con il fornitore dovrà garantire che stia eseguendo un monitoraggio e un alert adeguati. L’implementazione e la gestione di un HIDS sulla VM sarà responsabilità del cliente, mentre l’HIDS sull’hypervisor ricadrebbe sotto la responsabilità del provider.

• • Un tradizionale sistema di intrusion detection di rete
    Una seconda opzione è un tradizionale sistema di rete di intrusion detection (NIDS). Questo tipo di implementazione è utile per individuare alcuni attacchi contro la VM e l’hypervisor ma ha diverse limitazioni.
    La prima è che non può essere di aiuto quando si tratta di attacchi in una rete virtuale che si trova interamente all’interno dell’hypervisor. In secondo luogo, ha una visibilità molto limitata all’interno dello stesso host.
    Infine, se il traffico di rete è crittografato, non c’è nessun modo efficace per l’NIDS di decifrare tale traffico al fine di analizzarlo. Nel Cloud, l’implementazione e la gestione dell’NIDS sono completamente appannaggio del provider.

• Un sistema di intrusion detection hypervisor-based
  La terza opzione potrebbe essere l’uso di un sistema di intrusion detection che gira a livello di hypervisor, ma non è strettamente un HIDS per l’hypervisor. Una delle tecnologie più promettenti in questo settore è l’uso della VM introspection.
  Questo tipo di IDS consente di monitorare e analizzare le comunicazioni tra macchine virtuali, tra hypervisor e VM e all’interno di una rete virtuale hypervisor-based.
  Il vantaggio dell’ hypervisor-based ID è la disponibilità di informazioni, che permettono di vedere praticamente tutto. Lo svantaggio è che la tecnologia è nuova e si ha bisogno di sapere quello che si stastate cercando. Come nel caso dell’NIDS, questo rientra completamente nel campo di applicazione del provider per l’implementazione e la gestione.

In conclusione

In fin dei conti, l’intrusion detection nel Cloud viene eseguito meglio dai provider, avendo loro una perfetta conoscenza dei punti di snodo. L’ID basato sulla VM introspection è probabilmente la tecnologia più promettente, in termini di sistema di intrusion detection per il Cloud.

Arriveremmo a dire che è il futuro del Cloud IDS, e ciò significa che dovrete avere un buon SLA con il vostro provider per garantirvi le timeline e le informazioni di cui avete bisogno.

Se il vostro provider non offre l’ID come parte del suo servizio, incoraggiatelo a iniziare o trovate un altro fornitore che lo faccia. Quando si tratta di effettuare valutazioni sul lungo termine, gli standard, il rispetto e le best practices richiedono di avere un efficace IDS. Non è un’opzione e qualsiasi provider Cloud che si preoccupa della sicurezza offrirà questo servizio.