Sopravvivere a un (cyber)attacco ransomware – Le prime 72 ore

Dopo anni a studiare il fenomeno del ransomware, purtroppo mi sono trovato a doverlo fronteggiare in prima persona (“non chiederti se, chiediti quando” cit.). Se la conoscenza del fenomeno mi ha sicuramente aiutato a comprendere quanto stava accadendo e intervenire più rapidamente, l’esperienza diretta conseguente all’attacco mi ha permesso di toccare con mano alcuni aspetti che, forse, prima sottovalutavo.

Come saprete, lavoro in ambito universitario: un contesto particolarmente complesso, vasto e variegato, dove le esigenze della didattica e della ricerca talvolta rendono complicato implementare le necessarie difese.

Senza dover entrare troppo nei dettagli tecnici di quanto accaduto, per i quali ci saranno altre occasioni, in queste righe vorrei descrivere tutti quegli aspetti meno tecnologici e più umano-procedurali con i quali ho avuto a che fare in queste ultime settimane, nella viva speranza di poter essere di aiuto ai colleghi e a chiunque opera nell’ambiente.

Il primo aspetto di cui voglio parlare è la comprensione del fenomeno ransomware da parte dei non tecnici ICT. Anche se i dettagli più tecnici sono inevitabili, e difficili da comprendere per chi non è del settore, sicuramente la corretta percezione di quanto avvenuto, delle conseguenze e degli effetti, sia nel breve che nel medio e lungo periodo, sono essenziali per poter intraprendere percorsi virtuosi di mitigation e remediation.

Tra le azioni da predisporre in caso di un attacco ransomware c’è indubbiamente il tavolo permanente dell’Incident Response Team, o IRT.

Il tavolo dovrebbe essere composto dalle figure apicali e da esperti nei 3 principali ambiti coinvolti, comunicazione, legal, tecnico-informatico, con l’obiettivo di concertare e coordinare le azioni di risposta in ambito comunicativo, normativo e tecnologico.

Un attacco ransomware tocca tutti e tre gli ambiti della “famosa” triade CIA: disponibilità, riservatezza, integrità del dato. È forse uno degli eventi potenzialmente più devastanti che una realtà aziendale/istituzionale si può trovare ad affrontare, soprattutto senza le necessarie competenze.

Attenzione: non parlo solo del recupero dell’operatività, in gergo MTTR, o del tempo necessario a individuare gli attaccanti e “buttarli fuori” dai sistemi. Argomenti triti e ritriti, affrontati ampiamente. Parlo soprattutto di ciò che avviene tutto intorno, tra gli utenti che fremono per poter tornare a usare i servizi impattati, l‘opinione pubblica che chiede spiegazioni, le autorità che –come da normative vigenti– deve essere coinvolta nell’incidente e con cui, necessariamente, devono aprirsi canali di comunicazione. Non commettete l’errore di sottovalutare questi aspetti: nella società dell’informazione, una corretta comunicazione fa la differenza su come si gestisce un incidente (se non avete le competenze in-house, valutate se affidarvi a professionisti del settore).

Le prime 72 ore dalla scoperta dell’attacco, generalmente in modo assai doloroso, sono forse le più complesse. Farsi trovare preparati aiuta, moltissimo, ad affrontare e gestire il caos che inevitabilmente travolgerà il contesto colpito a vari livelli. In cui, lo sottolineo, la comunicazione rappresenta un elemento cardine per ridurre l’impatto dell’incidente sotto l’aspetto reputazionale, mitigare le conseguenze per gli interessati, ridurre l’esposizione a sanzioni da parte dell’Autorità Garante dei Dati Personali.

Le 72 ore sono anche quelle entro le quali, “senza ingiustificato ritardo“, deve essere fatta la comunicazione al Garante dei Dati Personali attraverso la procedura prevista dalla normativa in merito alla segnalazione di data breach, che richiede una necessaria prima analisi dell’incidente e delle conseguenze per gli interessati.

Nella notifica vanno indicati diversi aspetti dell’attacco, tra cui l’impatto della violazione (basso, medio, alto, molto alto) secondo i criteri previsti dal GDPR, ovvero valutando gli effetti sui diritti e le libertà degli interessati:

Come si può notare, il livello di rischio è valutato secondo le potenziali conseguenze per gli interessati e non secondo la natura del dato. Anche se, è sempre bene ricordarlo, alcuni dati sono più suscettibili di altri (ad esempio tutta la categoria dei dati ex-sensibili, o particolari) di rappresentare un rischio importante.

La notifica di data-breach deve essere predisposta dal team dell’IRT, poi sottoscritta da Titolare, con la consapevolezza che si tratta di un documento ufficiale le cui affermazioni devono essere precise, corrette e coerenti. Rappresenta, questa notifica e le eventuali successive integrazioni, una specie di memoria difensiva con cui il Titolare dimostra la sua capacità di affrontare una violazione dei dati personali degli interessati, nell’ottica di limitare le conseguenze ai loro diritti e libertà. Inutile sottolineare come tutte le eventuali successive comunicazioni devono essere coerenti con quanto scritto nella notifica.

Oltre alla notifica di data-breach al Garante deve essere fatta anche la segnalazione ad ACN –Agenzia Cybersicurezza Nazionale– attraverso la pagina “Notifica incidente“. Nel nostro caso, ACN ci ha ricontattato immediatamente ed è stata avviata una stretta collaborazione con i loro tecnici per affrontare le prime fasi dell’incidente.

Nel mentre, il reparto ICT dovrà isolare i sistemi colpiti per evitare che la compromissione si propaghi e tagliare fuori gli attaccanti che, molto probabilmente, staranno comunque operando o avranno implementato delle backdoor per accedere ai sistemi e controllare lo stato del loro attacco. Lavoro non facile, da portare avanti cercando di raccogliere e preservare le evidenze necessarie a individuare eventuali payload malevoli, la richiesta di riscatto (generalmente un file !!!README!!!.txt sul desktop) e tutte le altre informazioni da fornire, poi, alle autorità.

Non è escluso che, come avvenuto nel nostro caso, si renda necessario “staccare Internet” per le prime misure di contenimento dell’attacco. In ecosistemi complessi, infatti, individuare con precisione i sistemi compromessi può essere un lavoro difficile che richiede tempo. Tempo che, nel caso di un attacco in corso, rappresenta un elemento critico. In certi casi, quindi, interrompere qualsiasi comunicazione dati può quantomeno evitare che gli attaccanti, nel caso siano ancora presenti dentro i sistemi compromessi, possano mettere in atto misure evasive o espandere la compromissione ad altri sistemi.

Lo so, è una scelta molto difficile decidere di interrompere totalmente la connettività a Internet. Ma in situazioni critiche potrebbe essere la scelta migliore, quantomeno per aiutare nel contenimento.

In tutto questo, i preposti alla Comunicazione dovranno predisporre il comunicato da pubblicare sul sito web, da inviare anche agli organi di stampa, e le eventuali notifiche agli interessati: anche questo un atto necessario sia nel rispetto della normativa che per limitare il rischio di conseguenze indesiderate. Il tempo, in quest’ultima azione, rappresenta un elemento critico: la comunicazione deve essere quanto più possibile completa, esaustiva e contenere tutte istruzioni utili agli interessati per tutelare i propri diritti.

Mi sento di suggerire vivamente di evitare termini come “hackeraggio“ o “attacco hacker“, privilegiando invece termini come “compromissione“, “attacco informatico“. Non usate il termine “hackers” ma “cybercriminali“.

L’IRT ha, in questo caso, il difficile compito di far circolare le informazioni tra i vari team e garantire che tutti siano allineati, senza fughe in avanti o iniziative personali non concordate: in queste ore basta un tweet sbagliato dalla profilo sbagliato per causare un grosso problema all’Istituzione/Azienda.

In queste prime ore è fondamentale anche comunicare correttamente con tutta l’utenza interna, evitando che vengano prese iniziative personali che possano danneggiare l’organizzazione. In attesa delle comunicazioni ufficiali, infatti, sarebbe meglio invitare tutti a un cauto silenzio, limitandosi –se proprio necessario– a confermare l’esistenza di un incidente informatico ma senza spendersi in troppi dettagli: le analisi tecniche in corso serviranno anche a confermare, o smentire, i dettagli dell’attacco, come la natura, i sistemi coinvolti, i potenziali rischi per gli interessati.

Nella foto di copertina: il M. Cerino e il M. Toso in una dimostrazione di katori.