Per svaligiare una banca si può provare a forzare la porta oppure si può fare qualcosa di più elegante: aprirla per cinque minuti, richiuderla e aspettare che arrivi l’ispettore che troverà tutto in ordine. Il problema: i ladri sono già passati.
Qualcosa di molto simile è successo nel mondo del software. Google Threat Intelligence Group e Mandiant hanno ricostruito una campagna che, tra aprile e luglio, ha colpito l’infrastruttura di aggiornamento di AOMEI, azienda specializzata in software di backup, clonazione e disaster recovery, cioè strumenti che dovrebbero aiutarci a recuperare dati e sistemi quando qualcosa va storto. Gli attaccanti non avevano bisogno di mantenere stabilmente alterati i server. Li modificavano per intervalli brevissimi, sufficienti a distribuire istruzioni malevole, per poi riportarli alla condizione precedente. Google ha documentato finestre di dieci minuti il 28 maggio, sei minuti il 16 luglio e appena cinque minuti il 20 luglio.
Il meccanismo è piuttosto semplice. La sua realizzazione, evidentemente, molto meno. Un computer contatta il server del produttore per verificare la disponibilità di aggiornamenti. Se lo fa nel momento giusto riceve quanto previsto. Se capita nei cinque minuti sbagliati rischia di ricevere qualcosa di molto diverso. Poco dopo il server torna alla normalità, ma il software malevolo potrebbe avere già raggiunto il suo obiettivo. In questa vicenda c’è un primo elemento che dovrebbe farci riflettere: gli aggiornamenti sono una delle principali misure di sicurezza che consigliamo di adottare. In questo caso proprio il meccanismo attraverso il quale cerchiamo di proteggerci è diventato il veicolo dell’aggressione. Diciamo che scoprire un difetto di galleggiamento nel salvagente non è esattamente una buona notizia.
Tuttavia, personalmente ritengo che l’aspetto più interessante sia un altro e riguardi una nostra abitudine piuttosto consolidata: pensare alla sicurezza come a una fotografia. Controlliamo un file, un server, una configurazione e, se in quel preciso momento tutto appare corretto, tendiamo a concludere che il sistema sia sicuro. Il problema è che una fotografia documenta una condizione, non una storia. Nulla ci dice su quanto è accaduto prima dello scatto e, soprattutto, su quanto potrebbe accadere dopo.
Nel caso AOMEI gli attaccanti sembrano avere sfruttato proprio questa debolezza. La brevità delle modifiche riduceva le possibilità che venissero individuate attraverso controlli sullo stato dei sistemi. Non significa che un’indagine informatica accurata non possa ricostruire quanto accaduto, visto che poi è accaduto. Esistono registrazioni degli eventi, sistemi di monitoraggio e strumenti di analisi che consentono di risalire anche ad alterazioni ormai scomparse. Naturalmente a una condizione: che quelle informazioni siano state raccolte e conservate. Diversamente, controllare un server dopo che l’aggressore ha rimesso tutto in ordine può essere rassicurante, ma non particolarmente utile.
Il punto è meno tecnico di quanto possa sembrare. Da anni investiamo risorse per impedire che qualcuno modifichi abusivamente i nostri sistemi, ma dovremmo preoccuparci altrettanto di essere in grado di dimostrare che quelle modifiche non siano avvenute. Le due cose non sono equivalenti. Nel primo caso cerchiamo di prevenire un evento, nel secondo dobbiamo poterlo ricostruire. E mentre la prevenzione può fallire, la mancanza di informazioni su ciò che è successo rischia di trasformare un incidente in un mistero. Una situazione che, per chi deve gestire la sicurezza di un’organizzazione, non rappresenta esattamente il massimo delle aspirazioni professionali.
C’è poi un secondo aspetto che merita attenzione. Quando un computer scarica un aggiornamento dal produttore del software, compie un atto di fiducia. Presume che quella fonte sia attendibile e che quanto riceverà servirà a migliorare il funzionamento o la sicurezza del programma. Gli attaccanti hanno sfruttato proprio questa relazione. Non hanno dovuto convincere l’utente a cliccare su un messaggio sospetto o a installare un programma di provenienza incerta. Hanno cercato di utilizzare un canale che, per definizione, dovrebbe essere affidabile. È una differenza sostanziale, perché ci ricorda che la sicurezza di un sistema dipende anche da quella di soggetti sui quali non esercitiamo alcun controllo diretto. In altre parole, possiamo essere prudentissimi e finire nei guai per colpa di qualcuno che non conosciamo e che probabilmente non conosceremo mai.
Per anni abbiamo affrontato la sicurezza informatica soprattutto in termini di spazio: dove si trova il malware, quale server è compromesso, quale file è stato modificato. Vicende come questa ci ricordano che esiste un’altra coordinata, altrettanto importante: il tempo. Non basta sapere che un sistema è integro quando lo controlliamo. Dovremmo poter stabilire se lo sia stato anche quando non stavamo guardando. Significa progettare controlli capaci non soltanto di rilevare una condizione anomala, ma anche di conservarne le tracce. E significa accettare che la sicurezza non sia una proprietà acquisita una volta per tutte, bensì una condizione che dobbiamo essere in grado di verificare nel tempo. Cinque minuti, in fondo, sono pochissimi, tranne quando sono quelli “giusti”.