La notizia più importante sulla sicurezza informatica della scorsa settimana è quella relativa all’attacco contro Lastpass, il popolare (e consigliato da quasi tutti gli esperti del settore) password manager remoto.

Non entro qui nella questione se usare o meno un password manager, ci sono tante analisi e confronti disponibili molto più validi di quelli che possono fare io. Mi limiterò a dire che sì, ritengo sia necessario (se non indispensabile) usarne uno.

Cosa è successo?

Quello che è successo a LastPass non è ancora del tutto chiaro, in sintesi hanno reso noto che verificando alcune anomalie sui loro sistemi, hanno potuto riscontare un accesso non autorizzato ai dati degli utenti che usano il servizio (comprensivi di indirizzo email usato come username) e all’hash della master password che apre il vault di ogni utente, dove sono conservate tutte le password.

In pratica, hanno rubato l’hash della famosa lastpass che da il nome al servizio stesso.

Non è un gran danno, a meno che non si usi ovviamente una password banale, perché l’architettura di LastPass gestisce la master password non solo con un banale hash (che è teoricamente reversibile tramite un attacco brute force), ma implementando una procedura di salting e iterazioni successive per rendere più difficile risalire alla password originaria.

Non entro nel tecnicismo perché non è lo scopo di questo articolo, ma il blog Naked Security di Sophos lo fa in modo eccellente

Considerate solo che loro consigliavano 10.000 iterazioni successive per l’hash della password, mentre LastPass ne fa 100.000.

Come è facile immaginare un servizio online come LastPass, che contiene milioni (se non miliardi) di password di utenti di tutto il mondo è uno dei bersagli più interessanti che possano stare in circolazione.

Lo sanno i cyber criminali, ma lo sanno benissimo anche quelli di LastPass. Infatti quello dei giorni scorsi non è stato il primo incidente di sicurezza che ha coinvolto il servizio.

Già nel 2011 c’era stato un presunto attacco alle infrastrutture di LastPass, (loro correttamente si riferiscono ad una prima analisi dei log come ad anomalie) e già allora la risposta era stata eccellente, sia dal punto di vista comunicativo sia da quello della risposta all’incidente e, appunto, dell’identificare e applicare le lesson learned.

La lezione da imparare bene

Partiamo da un concetto base della sicurezza informatica, noto a tutti ma tristemente spesso dimenticato da molti: non esiste la sicurezza al 100% e gli incidenti avverranno sempre.

Per questo, che si abbia un negozio online che vende soia in scatola o che gestisca milioni di password, la sicurezza va sempre affrontata dall’inizio, by design e sempre tenendo in mente che si può essere un bersaglio di possibili attaccanti. E lo si sarà prima o poi, quindi non essere pronti vuol dire potenzialmente mettere a rischio la propria attività online. Perché quando vengono rubati i dati dei propri clienti, la perdita di fiducia è tale che si rischia davvero di chiudere tutto…

LastPass è un chiaro esempio di come si possa essere consapevoli

• del fatto che si sarà sempre bucati (prima o poi succederà);
• che questo comporta scelte architetturali orientate a coprire il più possibile il perimetro di attacco (ne avevo parlato, a chi attacca basta un punto debole sul perimetro);
• che questo comporta anche un controllo costante ed una gestione dell’incidente ottimale.

Il controllo costante

Quello che sicuramente colpisce di più degli incidenti occorsi a LastPass  è che nascono tutti da una analisi dei loro log e del funzionamento dei loro apparati.

Questo è il primo passo per garantire la sicurezza nell’erogazione dei propri servizi. E bisogna considerare il fatto che non è solo una scelta organizzativa, di allocazione di risorse e tempo per analizzare i log.

È sopratutto una scelta architetturale, perché non basta generare milioni di log e farli leggere a qualcuno, bisogna che i log sia pensati per essere analizzati e che l’infrastruttura che li analizza lo faccia evidenziando solo le reali anomalie.

Chiunque abbia lavorato su sistemi SIEM o analizzatori di log su grande scala lo sa bene.

La gestione dell’incidente

Qui passiamo da un lato tecnico ad uno più prettamente organizzativo, infatti la gestione dell’incidente è un processo che prescinde dalla tecnologia o dall’azienda. È più una procedura (conosciuta, validata e collaudata da tutti) su come l’azienda esce allo scoperto e discute dell’incidente con i propri clienti, azionisti e stakeholder in generale.

Anche qui LastPass dimostra di aver capito bene la situazione e sia nella comunicazione del 2011 sia in quella di questi giorni pubblica dettagli, fornisce aggiornamenti e descrive tutte le azioni intraprese e, molto importante, gli errori commessi.

Ci sono state polemiche ad esempio sul fatto che molti utenti di LastPass hanno saputo dell’incidente prima dalla stampa di settore (notabilmente Lifehacker) e poi da una comunicazione via mail agli utenti

Why did I hear about this in the media first?
Emails have been sent to all users regarding the security incident. Notifying millions of users via email takes time. Quindi, we also announced the security alert to our blog and our social accounts in real-time, and the media quickly picked up the story.

Questo ovviamente ci può stare, anzi ritengo che abbiano fatto bene a rendere pubblica la situazione con il massimo eco mediatico possibile. E per quello serve un post su un blog.

Considerato quanto tempo gli utenti passino su Facebook o Twitter rispetto alla propria mail, è stata una scelta azzeccata.

Certo, qualche utente arrabbiato ci sarà sempre, come molti si sono arrabbiati per il fatto che alla pubblicazione della notizia il servizio di cambio della master password era andato in overload, non permettendo il cambio (ecco, subito pronta un’altra lesson learned).

Ma questo ci sta. Del resto l’azienda ha appena detto di aver subito il più grande incidente di sicurezza della propria storia, quindi è ovvio che comunque vada perderà una parte dei propri clienti o utenti.

Consapevolezza

Come detto, sia ragionare in termini di “sono un bersaglio, mi bucheranno” aiuta a progettare un’architettura di sicurezza che sia in grado di minimizzare il danno. Sia imparare da quello che è successo in precedenza, le lesson learned, serve a modificare la propria infrastruttura ed adattarla alle nuove e più gravi minacce.

Ad esempio, oltre a tutti gli strumenti passivi di protezione della master password e del vault, che già mitigano enormemente il furto avvenuto, LastPass mette a disposizione altri strumenti attivi

• il supporto all’autenticazione a due fattori
• il supporto alla geo-localizzazione del login e conseguente blocco
• il supporto per ulteriori iterazioni dell’hash dal lato client (default: 5.000)

Ora questi fattori vanno ovviamente abilitati dall’utente, ma forniscono comunque un quadro complessivo di come si sia strutturato un servizio veramente secure by design.

Offrendo non solo una base di sicurezza già superiore agli standard consigliati, ma anche strumenti ulteriori (che non posso fare a meno di indicare come necessari e indispensabili da usare ovunque, particolarmente l’autenticazione a due fattori) che rendono un evento gravissimo come il furto di un hash di una password, quasi ignorabile.

Security by design

Prendere questo attacco a LastPass come case study è sicuramente molto interessante, ma diventa ancora più importante farlo in un mondo come il nostro, dove ancora troppo spesso ci si trova di fronte a servizi che non solo non fanno un hash delle password, ma le mettono in chiaro sul database.

Avete presente quando vi registrate in un servizio web e vi mandano la mail di riepilogo con il vostro username E la password? Ecco, vuol dire che è in chiaro sul db.

Naturalmente non vuol dire che tutti debbano implementare le tecnologie e le procedure descritte qui sopra.

Security by design significa pensare in termini di sicurezza quando si sta progettando qualcosa. E quando si progetta qualcosa lo si fa sempre rapportandosi a quello che si sta progettando.

Non ha senso sparare col cannone alle mosche come non ha senso usare un Mainframe IBM per le ricette della nonna.

Ha senso però impostare il ragionamento sulla consapevolezza di quello che si rischia, implementare le opportune (e legate al budget) contromisure. Eventualmente cercando sempre di alzarne un po’ il livello oltre lo standard.

Ma che almeno si faccia lo standard. Perché se è vero che “beati monoculi in terra caecorum“, allora è sempre meglio fare un po’ di più degli altri e porsi in una situazione di privilegio per le contromisure adottate.

Perché se è vero che prima o poi saremo bucati, è meglio poi.

E, in ogni caso, è sempre meglio essere pronti a gestirlo.