Approccio pragmatico alla sicurezza

Questa è la presentazione che ho usato nel mio intervento al Security Summit di Milano.

 

Il Security Summit, organizzato dal Clusit, è il più importante evento di sicurezza in Italia. Il mio intervento era sulla protezione dalla minacce ancora non note che arrivano via mail e metteva l’accento sul rapporto tra pragmatismo e sicurezza.

In questo post ripercorro gli argomenti di questa presentazione.

Complessità 

I problemi di sicurezza che oggi abbiamo sono principalmente dovuti alla grande complessità  dei sistemi che usiamo, questa complessità  crea una superficie d’attacco molto grande. Associamo questa grande superficie d’attacco ad una grande motivazione a violare i nostri sistemi, principalmente legata al business del ransomware e del phishing, e capiamo perché oggi le nuove minacce, ancora non note, sono all’ordine del giorno. Abbiamo visto 30mila nuove varianti di ransomware nel corso del 2016, cioè decine di nuove minacce al giorno e i sistemi di sicurezza per essere efficaci devono riuscire ad intercettarle pur non conoscendole.

I sistemi di sicurezza, in informatica come nel mondo fisico, devono essere mantenuti più semplici possibile perché la complessità  è nemica della sicurezza. Riduce l’affidabilità  e aumenta la superficie d’attacco.

Alcune soluzioni proposte da molti vendor sono più orientate ad esigenze di marketing che ad esigenze di sicurezza. Le sandbox basate su virtual machine, ad esempio, sono sistemi ancora più complessi di quelli che vogliono difendere: un sistema windows virtualizzato in un ambiente instrumentato con software aggiuntivo che cerca di osservare il malware senza a sua volta essere osservato. Tutto questo deve essere fatto con tempi di analisi brevi, tipicamente entro i due minuti, per non gravare eccessivamente sui workflow aziendali.

Il malware, i cui autori hanno a disposizione le stesse identiche sandbox che usiamo noi e sulle quali il malware può essere testato prima di essere rilasciato, hanno imparato velocemente ad ingannare le sandbox. Se la sandbox ha solo un paio di minuti per dare un responso, il malware una volta infettato il pc ha tutto il tempo che vuole per manifestarsi, quindi gli basta aspettare un po’ per non essere identificato dalla sanbox. Le sandbox hanno iniziato a far credere al malware che sia trascorso più tempo di quello che è realmente trascorso, cosa molto più facile a dirsi che a farsi, e il malware ha imparato ad usare proprio questa caratteristica per accorgersi di essere in una sandbox. Questo esempio semplificato per dire che l’eterna contesa tra attaccante e difensore si è semplicemente spostata in un diverso ambiente senza cambiarne le dinamiche di fondo. In questo nuovo ambiente però è chi difende a giocare in svantaggio.

Eppure la sandbox è un forte argomento di marketing perché la complessità  è un argomento che vende di più del pragmatismo.

Pur essendo uno strumento eccezionale per l’analisi e lo studio del malware, quando la sandbox basata su virtual machine è usata come filtro mostra diverse debolezze ed offre una superficie di attacco discreta. Proprio qualche giorno fa al Pwn2Own, una competizione di sicurezza informatica, un team è riuscito, attraverso un click su un link fatto su una macchina windows virtualizzata in vmware, ad uscire dalla vm e compromettere l’host. Il tutto con un semplice click su un link. Immagina un malware che compromette la sandbox per infettare tutti i file che vengono analizzati …

Quindi: usiamo la complessità  dove serve e con prudenza, sapendo che ogni aumento di complessità  riduce la sicurezza, quindi ha un costo.

 

Proteggersi da file malevoli

Per quanto riguarda l’analisi dei file, nel mio intervento ho ripercorso il ragionamento dalla casella numero zero. Analizziamo il problema ricominciando dal punto di partenza e aggiungiamo complessità  fino a che serve.

Partiamo dall’approccio “firewall”. Vi ricordate quando sul firewall si chiudevano selettivamente le porte? Tutte aperte tranne quelle che decidevamo di chiudere. Poi abbiamo invertito la logica: tutto chiuso e si apre solo quello che serve. Solo questo semplice cambio di paradigma ha migliorato drasticamente la sicurezza.

Facciamo lo stesso ragionamento. Abbiamo bisogno di eseguibili allegati alle mail? Di .exe, di .js, eccetera? No, non ne abbiamo bisogno, l’esperienza di oltre un miliardo di mail al mese ci dice che questi file non servono, toglierli non impatta sui workflow aziendali, quindi blocchiamoli senza neanche stare ad analizzarli.
Il tuo tecnico del reparto IT ha bisogno di riceve file jar? Ok, mettiamo una eccezione per lui. Approccio firewall. Tutto bloccato e si sblocca selettivamente.

Soluzione estremamente semplice, banale, per togliere la maggior parte dei vettori di attacco. Restano però i documenti. Documenti office, file pdf, ormai questi formati sono così complessi da poter contenere codice in grado di fare di tutto. Come ci comportiamo? Di sicuro non possiamo bloccarli.

Ok, è il momento di salire un gradino di complessità . Un passo in direzione di una maggiore complessità  giustificato da un’esigenza reale. Facciamolo.

Andiamo ad analizzare il documento. Contiene codice o no? Se no, passa. Approccio firewall.
E se lo contiene? Mica possiamo bloccare tutti gli spreadsheet con una macro! Giusto.

Altro gradino di complessità  giustificato, quindi facciamolo.
Ora che sappiamo che c’è del codice, rimbocchiamoci le maniche e andiamo a vedere cosa fa. Fa calcoli in uno spreadsheet, automazioni di altro tipo ma normali in un documento? Ok, definiamo un set di automazioni sicure e lasciamole passare. Approccio firewall. Questa analisi può essere fatta in modo rapido e sicuro, facciamola.

Ottimo, abbiamo fatto passare i documenti con macro innocue. Gli altri però mica possiamo bloccarli tutti, rischiamo di creare qualche disservizio.

Ok, altro gradino di complessità . Questi file che abbiamo classificato come “sospetti” allora li “puliamo”. Siamo in grado di rimuovere il contenuto “attivo”, la macro, l’oggetto ocx embedded, il codice javascript in un pdf. Togliamo questo codice e consegnamo un documento inerte. Utilizzabile come documento ma senza codice.

Ci siamo. Non ci restano che le ultime rifiniture: prevedere cosa fare con i documenti criptati che non possiamo analizzare (facile, li blocchiamo perché oggi sono il veicolo principale di ransomware), e cosa fare nel malaugurato caso in cui un malware riesca a mandare in crash la mia sandbox per cercare di non essere scoperto: in questo caso lo categorizziamo come “indeterminato” e di default rimuoviamo tutto il contenuto attivo. Semplice buona pratica di programmazione prevedere anche il caso in cui qualcuno riesca a sabotare la tua sandbox (eppure vediamo in circolazione sandbox che in queste condizioni lasciano passare il malware che è riuscito a metterle in crisi).

Infine, rendiamo configurabili dall’amministratore i comportamenti in caso di contenuto sospetto, sicuro, criptato e indeterminato, così che possa decidere lui stesso cosa far passare, cosa bloccare e cosa “pulire”. Facciamo anche in modo che ogni volta che modifichiamo un file ne conserviamo la copia originale così che se dovesse mai servire possa essere recuperata.

A questo punto l’obiettivo è raggiunto, abbiamo protetto dagli attacchi via file anche non noti e lo abbiamo fatto con una soluzione più semplice possibile. Un’analisi e una pulizia selettiva veloci, che si fanno mentre la mail viene analizzata dai sistemi antispam, e che non richiedono di caricare i propri file su una sandbox di terze parti in cloud, con problemi di compliance e privacy, con ritardi che impattano sui workflow. Risultato raggiunto con complessità  e superficie d’attacco minima.

 

Proteggersi dai link malevoli

Quindi? Bisogna evitare assolutamente e in qualunque caso qualunque complessità ? No. Semplicemente usare la complessità  ove serve, senza avere alcun timore a farlo ma considerandolo un costo che deve essere giustificato.

Ad esempio, la complessità  è più che giustificata per proteggersi dalle url malevole.

L’attacco più frequente oggi è una mail proveniente da un mittente legittimo (il suo account è usato abusivamente), con un testo breve e estremamente generico, che contiene un link ad un sito legittimo (infettato 5 minuti fa) su cui è stato depositato un malware che si installa semplicemente visitando quella pagina. Fai un click e hai il ransomware.

Questo tipo di attacco è un bel problema perché una mail fatta in questo modo potrebbe anche non essere identificata come malevola. Quindi nel momento in cui la mail transita, noi riscriviamo la url così che invece di puntare a quella pagina punti alla nostra sandbox, vedremo che qui una sandbox complessa è giustificata. Prendiamoci tempo perché il tempo è dalla nostra, più tempo passa e più è facile che riuciremo ad identificare come malevolo quel sito legittimo appena infettato, quindi riscriviamo la url e basta, l’analisi la positicipiamo all’ultimo istante possibile: al momento del click.

Quando il click arriva, il browser dell’utente atterra sulla sandbox che, solo in questo momento, visita la pagina e la analizza. Segue i redirect, la visita da più località  per evidenziare tecniche di evasione, valuta come si presenta ai motori di ricerca, cerca segni di infezione, tentativi di phishing, eccetera.

Non lesiniamo complessità  perchè qui è utile e paga. Soprattutto qui è la sandbox a giocare in vantaggio: il malware non può aspettare a manifestarsi, qui l’infezione la deve fare subito al caricamento della pagina. Inoltre per nascondersi alle sandbox le tecniche disponibili sono poche e noi, visitando la pagina in più modalità  e da più posti, siamo in grado di scoprirle. Questo è un enorme vantaggio: il solo mettere in atto una tecnica di evasione rivela la presenza del malware, anche di quello più sofisticato e ancora ignoto, rendendolo estremamente vulnerabile alla nostra analisi.

Qui si che la complessità  è giustificata.

 

Per chi vuole approfondire, qui c’è la spiegazione di come funziona l’analisi dei file e qui quella delle url.