Incident response: come gestire un attacco informatico

di Giovanni Finetto & Paola Finetto

“Quattro italiani su dieci hanno pagato il riscatto per ripristinare l’accesso ai propri dati dopo essere stati vittima di un ransomware, solo uno su dieci è stato in grado di recuperare i documenti. Una minaccia informatica che è cresciuta sempre di più, soprattutto nell’anno della pandemia e dello smart working, e fa riflettere sull’importanza della protezione e della sicurezza dei dati”¹.
Il servizio di Incident Response è volto alla gestione degli incidenti informatici, i quali possono comportare anche violazioni di dati personali – o data breach – rilevanti ai sensi degli artt. 33 e 34 del GDPR.
Prima di affrontare la questione che maggiormente qui interessa, qual è la gestione di un data breach, può essere utile approfondire alcuni aspetti terminologici. Talora, infatti, si adoperano indifferentemente i termini violazione dei dati, incidente informatico e incidente di sicurezza come fossero sinonimi. In realtà, questi vocaboli fanno riferimento a situazioni che tra loro differiscono, per svariati aspetti.
Un incidente informatico è, in generale, un evento che comporta malfunzionamenti degli apparati hardware e software e, dunque, può compromettere la funzionalità di una struttura ICT.
Un incidente di sicurezza delle informazioni è, più precisamente, un incidente informatico che determina una compromissione effettiva o una minaccia imminente dei sistemi informatici e telematici di una organizzazione.
A titolo meramente esemplificativo, un incidente di sicurezza può aversi nei seguenti casi:

• criptazione delle informazioni contenute nella struttura ICT o parte di essa;
• accesso non autorizzato alla struttura ICT;
• esfiltrazione e diffusione non autorizzata di dati presenti nella struttura ICT;
• compromissione delle credenziali personali di autenticazione;
• perdita o modifica delle configurazioni di sistema;
• interruzione di servizi ICT;
• furto o perdita dei dispositivi;
• impossibilità di accedere ai dati per cause accidentali o per attacchi esterni, virus, malware, ecc.; 
• perdita o distruzione di dati a causa di incidenti, eventi avversi, incendi o altre calamità.

Questi eventi, idonei a compromettere la sicurezza sia delle informazioni custodite nella struttura ICT, che della struttura ICT stessa, possono dipendere da azioni intenzionali o da fattori accidentali. A loro volta, le azioni e/o i fattori, che generano l’incidente di sicurezza, possono provenire dall’interno dell’organizzazione, piuttosto che dall’esterno di essa.
Un’azione intenzionale interna presuppone un evidente intento malevolo: è il caso del c.d. collaboratore infedele, che accede al sistema informatico al fine di sottrarre dati e informazioni, per portarli all’esterno dell’organizzazione e farne un uso contrario agli obblighi di riservatezza. Un fattore accidentale proveniente pur sempre dall’interno dell’organizzazione, idoneo a generare un incidente di sicurezza, è solitamente riconducibile a una negligenza, talora ad una mera svista di un operatore: si pensi al caso dell’utente, che apre un file inviato tramite posta elettronica o posta elettronica certificata, proveniente da un account sconosciuto, che in realtà contiene un codice malevolo; si pensi ancora all’ipotesi del collaboratore che utilizza nel computer aziendale una pen-drive personale, che è stata in precedenza inconsapevolmente infettata.
Un’azione intenzionale proveniente dall’esterno dell’organizzazione coinvolge terzi soggetti, il cui obiettivo è unicamente quello di danneggiare una struttura ICT, al fine di penetrarla e/o di carpire le informazioni e i dati in essa contenuti. In questi casi, molto spesso, la rete dell’organizzazione viene attaccata per finalità ulteriori. È il caso tipico della rete “zombie”: infettata per essere in futuro “risvegliata” e usata dai criminali nell’ambito di una botnet, per sferrare attacchi ulteriori. Peraltro, i dati carpiti dai criminali informatici possono essere a loro volta sfruttati: immessi nel dark web, per farne un commercio illegale. Molto più raro, invece, è il caso dell’incidente informatico causato da un fattore accidentale esterno.
Ebbene, un incidente di sicurezza, quale che ne sia la causa scatenante, ha sempre un impatto negativo nella struttura dell’organizzazione: il suo verificarsi evidenzia la vulnerabilità di determinati sistemi o apparati, così come dei protocolli interni di sicurezza, e può avere anche un impatto negativo sul business dell’organizzazione. Non è raro che incidenti di sicurezza comportino l’esfiltrazione e la pubblicazione nel dark web di dati riservati (know-how dell’organizzazione o di soggetti terzi con i quali la prima collabora), piuttosto che di dati c.d. particolari (o sensibili) relativi a dipendenti, collaboratori, clienti dell’organizzazione stessa. Simili accadimenti compromettono inevitabilmente l’immagine e la reputazione dell’organizzazione e ne minano seriamente il business.
Gli incidenti di sicurezza sono solitamente distinti in tre categorie, tenendo conto sia degli eventi che li hanno determinati, che delle conseguenze che hanno comportato:

• eventi a basso impatto (detti anche non significativi): si tratta di eventi gestiti dal sistema di sicurezza dell’organizzazione in maniera silente, tali da non richiedere ulteriori interventi di ripristino specifici; è il caso, ad esempio, del virus intercettato da un sistema di monitoraggio della rete e messo in quarantena, così da non inficiare la funzionalità del device attaccato;
• eventi significativi: tali sono gli allarmi di sicurezza e, comunque, gli eventi rilevati nell’ambito dei sistemi e delle infrastrutture ICT, che devono essere presi in carico e analizzati dal personale incaricato delle attività di monitoraggio (quali ad esempio, il rilevamento in tempo reale delle segnalazioni provenienti dai dispositivi di sicurezza, l’analisi dei log prodotti da tali dispositivi, la raccolta e la valutazione di comunicazioni su comportamenti anomali o eventi sospetti);
• eventi critici: sono sussumili in questa categoria tutti gli eventi significativi che, a seguito delle analisi effettuate, sono ritenuti idonei a comportare, direttamente o indirettamente, una compromissione della struttura ICT dell’organizzazione e, comunque, una violazione delle politiche di sicurezza della medesima.

Il data breach (o violazione di dati) è, a sua volta, una particolare tipologia di incidente di sicurezza delle informazioni, che coinvolge i dati personali. Una tale violazione può essere determinata da un fattore accidentale oppure da un’azione intenzionale, al pari di ogni altro incidente di sicurezza. A questo riguardo giova ricordare che l’art. 4, comma 1, n. 12, del GDPR definisce la violazione dei dati personali come la “violazione di sicurezza che comporta accidentalmente o in modo illecito la distruzione, la perdita, la modifica, la divulgazione non autorizzata o l’accesso ai dati personali trasmessi, conservati o comunque trattati”. Il Considerando 85 del GDPR precisa, peraltro, che “Una violazione dei dati personali può, se non affrontata in modo adeguato e tempestivo, provocare danni fisici, materiali o immateriali alle persone fisiche, ad esempio perdita del controllo dei dati personali che li riguardano o limitazione dei loro diritti, discriminazione, furto o usurpazione d’identità, perdite finanziarie, decifratura non autorizzata della pseudonimizzazione, pregiudizio alla reputazione, perdita di riservatezza dei dati personali protetti da segreto professionale o qualsiasi altro danno economico o sociale significativo alla persona fisica interessata”. Si comprende, dunque, come sia necessario non solo non sottovalutare una violazione di dati personali, ma, ancor più, gestirla correttamente.
Un data breach può compromettere la riservatezza, l’integrità o la disponibilità dei dati personali coinvolti.
La riservatezza dei dati, riconducibile al diritto alla segretezza e alla non divulgazione dei dati medesimi, può essere compromessa nel caso di furto di informazioni. Così, ad esempio, nella ipotesi di perdita o furto di uno smartphone o di un computer portatile, ma si pensi anche al caso, tutt’altro che raro, di utilizzo di device aziendali per fini privati (navigazione in siti pericolosi, uso di chiavetta USB non aziendale e infetta). Anche l’installazione di programmi gratuiti scaricati dal web potrebbe compromettere la riservatezza dei dati e avere ripercussioni sulla sicurezza della struttura informatica dell’organizzazione.
L’integrità dei dati, per tale intendendosi la legittima aspettativa che le informazioni non vengano modificate, cancellate o distrutte in modo non autorizzato o improprio, può parimenti essere compromessa da un incidente informatico che riguarda i dati stessi (gli esempi possono essere i medesimi già richiamati per il caso di incidenti afferenti alla riservatezza dei dati), ma pure il sistema informatico (del quale non sia più possibile garantire il funzionamento; tipico è il caso dell’attacco phishing sferrato con successo, con l’invio di virus malevoli contenuti in allegato ad un messaggio di posta elettronica, aperto dall’utente, con conseguente criptazione dei dati e blocco del sistema).
La disponibilità dei dati, la quale si riferisce al diritto degli utenti autorizzati di poter disporre sempre di determinate risorse, può essere compromessa da incidenti di sicurezza che impattano su informazioni, applicazioni, servizi, sistemi, reti. Tipico esempio di evento che pregiudica la disponibilità delle risorse sono gli attacchi DoS (Denial of Service) e DDoS (Distributed Denial of Service).
Ebbene, in caso di data breach sono compromesse proprio la riservatezza, la integrità e la disponibilità dei dati, naturalmente con intensità e modalità differenti, che variano nei singoli casi. Ogni incidente di sicurezza che pregiudica in qualche modo i dati personali dev’essere valutato con attenzione, con riferimento anche agli obblighi di comunicazione specificamente previsti dal GDPR. L’articolo 33 del GDPR stabilisce l’obbligo di comunicare, all’autorità di controllo competente, l’avvenuta violazione di dati personali entro un termine di 72 ore dalla sua scoperta, qualora si sia concretizzato un danno o una minaccia alle libertà o ai diritti delle persone titolari dei dati. L’articolo 34 stabilisce, inoltre, l’obbligo di comunicazione agli interessati, dando notizia del data breach che si è concretizzato, solamente nel caso in cui esista un rischio elevato per i diritti e le libertà degli interessati.
L’incremento dei crimini informatici, la (ahimè) notevole fantasia dei criminali informatici, che sviluppano minacce sempre nuove e diverse, la consapevolezza che nessuna struttura ICT può mai considerarsi assolutamente resistente ai rischi cyber, deve indurre le organizzazioni ad affrontare con professionalità e competenza adeguate gli incidenti informatici, tanto più se essi comportano una violazione di dati personali. Ciò rende necessario saper gestire ogni incidente di sicurezza correttamente e con efficacia.
L’Incident Management e l’Incident Response sono i servizi – e relative competenze e attività – a disposizione delle organizzazioni che subiscano un incidente di sicurezza o un data breach.
L’Incident Management identifica la capacità di gestire l’evento in modo efficace, così da minimizzarne le conseguenze avverse, assicurare la business continuity e, al contempo, gestire i rapporti con terze autorità di Pubblica Sicurezza e con le autorità di controllo. Un servizio concretamente efficace di Incident Management deve poter offrire all’organizzazione tutte le risorse – umane e materiali – necessarie, per garantire una gestione lineare dell’incidente di sicurezza, dunque senza stravolgimenti nella operatività quotidiana dell’organizzazione, i quali, altrimenti, appesantirebbero le già presenti – e non indifferenti – conseguenze dell’evento occorso. Obiettivo primario dell’Incident Management è quello di definire una corretta strategia di gestione dell’incidente verificatosi, tenendo conto anche delle procedure di sicurezza e dei protocolli di gestione del rischio adottati dall’organizzazione. Quest’ultima può essere realmente e concretamente supportata, laddove il servizio di Incident Management sia idoneo a:

• definire e, ove necessario, attuare le misure necessarie per ridurre l’impatto dell’incidente di sicurezza sulla operatività quotidiana;
• identificare le ulteriori iniziative da assumere, in un arco temporale ben definito, al fine di ripristinare e garantire la business continuity;
• segnalare ai responsabili dell’organizzazione la necessità od opportunità di denunziare l’occorso alle autorità di Pubblica Sicurezza o di portarlo a conoscenza di una autorità di controllo e, eventualmente, di darne notizia ai terzi i cui dati siano stati compromessi;
• definire e, ove richiesto, mettere in atto misure tecnico-organizzative ulteriori, rispetto a quelle di cui l’organizzazione già dispone, per assicurare o implementare una migliore e più efficace difesa contro gli attacchi;
• effettuare, ove necessario od ove richiesto, un’attività specifica di analisi e investigazione, per ricostruire l’occorso e individuare le vulnerabilità dei sistemi e le ulteriori misure di mitigazione del rischio;
• analizzare, ove necessario o su sollecitazione dell’organizzazione, i protocolli interni di gestione del rischio, per eventualmente individuare misure e protocolli da aggiornare o da introdurre ex novo.

L’Incident Management riguarda, conclusivamente, tutte le azioni intraprese prima, durante e dopo il verificarsi di un incidente di sicurezza delle informazioni.
Una parte importante, anzi determinante, di questo processo è l’Incident Response.
L’Incident Response è, dunque, una fase o, meglio, una componente del più ampio e articolato processo di Incident Management e identifica le attività e le risorse necessarie per ripristinare la continuità operativa dell’organizzazione il più velocemente possibile, minimizzando gli impatti negativi dell’incidente di sicurezza e, al contempo, identificando le ulteriori iniziative da adottare a fronte dell’evento occorso.
Se virtuosa, l’organizzazione potrebbe avere già adottato una propria procedura di gestione dell’Incident Response, la quale dovrebbe includere:

• la costruzione di un protocollo interno Incident Response, che definisca step by step le azioni da intraprendere nel caso in cui si verifichi un incidente di sicurezza;
• lo sviluppo di procedure interne per garantire il tracciamento di ogni incidente di sicurezza e un adeguato flusso di informazioni da e verso gli organi amministrativi e di controllo dell’organizzazione;
• l’approntamento di linee guida per definire le comunicazioni dirette ad enti o autorità esterne all’organizzazione, relative sempre ad un incidente di sicurezza (ad esempio, polizia postale o Garante per la protezione dei dati personali);
• la creazione di un team interno, con competenze sia tecnico-informatiche che giuridiche, in grado di gestire un incidente di sicurezza (Incident Response Team), con previsione di sessioni formative ricorrenti e specifiche per coloro che ne fanno parte.

In molti casi, tuttavia, l’organizzazione sceglie di affidarsi ad un Incident Response Team esterno.
Invero, un gestore esterno dispone solitamente di maggiori competenze e risorse, umane e strumentali, ed è pertanto in grado di offrire un servizio eccellente e completo di gestione dell’incidente di sicurezza.  Per molti motivi, non da ultimo per ragioni di maggiore economicità, le organizzazioni colpite da un incidente informatico richiedono il “pronto intervento” di un Incident Response Team esterno. Gli attacchi informatici compromettono sempre più frequentemente i dati personali e il business: ciò rende ormai imprescindibile saper rispondere velocemente ed efficacemente agli incidenti di sicurezza e, ancor più, a quelli che comportano un data breach.  La capacità di gestire l’attività di Incident Response è diventata un fattore critico: le organizzazioni hanno bisogno del supporto di un team che sia in grado di:

• affrontare gli incidenti di sicurezza con sistematicità ed efficacia;
• supportare l’organizzazione nel prendere tempestivamente le decisioni appropriate al caso concreto;
• ripristinare e garantire la continuità operativa;
• fornire ogni suggerimento utile per permettere all’organizzazione di migliorarsi e di trarre, anche da un evento dannoso, qual è un incidente di sicurezza, utili spunti per implementare la resilienza della sua struttura di fronte ad attacchi informatici sempre nuovi e diversificati.

Un Incident Response Team effettivamente efficace dovrà, quindi, saper offrire all’organizzazione un insieme di procedure, sistemi e risorse (non solo informatiche ma anche legali), necessari e utili per reagire all’incidente informatico.
Nonostante il GDPR non prescriva espressamente di creare un CSIRT (Computer Security Incident Response Team), è evidente che, per garantire la conformità all’articolo 33 del GDPR,  una organizzazione non può farne a meno: ogni ente, secondo quanto previsto dal GDPR, deve dotarsi di un piano di gestione degli incidenti informatici, che permetta di attivare, automaticamente, alcuni meccanismi tecnologici e precise procedure tecnico-legali finalizzate alla minimizzazione del danno e alla continuità operativa. Questa gestione si articola essenzialmente nelle seguenti fasi:

• risposta iniziale all’incidente;
• investigazione;
• ripristino dei sistemi compromessi, laddove possibile, e comunque ripristino della continuità operativa;
• supporto all’organizzazione per le comunicazioni da effettuare nei confronti di autorità di Pubblica Sicurezza o di controllo.

Nella prima fase di risposta iniziale, il team che interviene determina il tipo di incidente e il suo potenziale impatto, interloquendo con chi ha rilevato l’incidente, revisionando i relativi log di rete o di sistema, mantenendo copia documentale di tutte le informazioni raccolte. È, questa, una fase delicata: si approccia, infatti, un’organizzazione che ha subito un incidente informatico e i cui dati sono stati in qualche modo violati, compromessi. Il titolare dell’organizzazione ha, in questo momento, una duplice esigenza: da un lato promuovere ogni iniziativa utile e necessaria per verificare l’occorso; dall’altro ripristinare quanto prima la business continuity.
Nella fase successiva, quella investigativa, una volta cristallizzata la “scena del crimine informatico” si accerta quanto presente nei sistemi e nelle reti, al fine di ricostruire le cause e la dinamica dell’incidente occorso. In questa fase si applicano le metodologie che fanno capo alla digital forensics, l’analisi forense dei campioni rappresentativi rispetto all’incidente informatico verificatosi con una metodologia ben nota, denominata “copia bit a bit”. In questa fase è molto importante – anzi, determinante – procedere con attenzione e competenza in ogni singolo step dell’iter di verifica e accertamento, in quanto gli esiti di queste indagini potrebbero essere utili per il titolare del trattamento per individuare responsabilità (o, come più frequentemente accade, corresponsabilità) nella generazione dell’incidente occorso.
La terza fase è diretta al ripristino della operatività: essa si concentra sul ripristino dei dati e della rete, possibilmente riportandoli al momento precedente all’attacco informatico, solo dopo avere “bonificato” e “disinfettato” i device da ogni codice malevolo presente all’interno.
Da ultimo, l’Incident Response Team dovrà fornire all’organizzazione ogni utile supporto per la gestione della comunicazione verso l’esterno. Si tratta, in questo caso, di affiancare l’ente nella valutazione, prima, e nella esecuzione, poi, di una eventuale denunzia alle autorità di polizia, piuttosto che di una comunicazione al Garante per la protezione dei dati personali (inevitabile nel caso previsto dall’art. 33 GDPR) o, ancora, di una comunicazione dell’evento occorso nei confronti di terzi soggetti, i cui dati siano stati violati con un conseguente grave rischio per i loro diritti o le loro libertà (è, questo, il caso cui si riferisce l’art. 34 GDPR).
Come si è già evidenziato, l’approccio del team di Incident Response sarà necessariamente multidisciplinare e organico: le competenze che il team deve possedere sono, infatti, sia tecniche, che giuridiche, dovendosi verificare, tra l’altro, se l’organizzazione abbia approntato ed efficacemente attuato procedure interne per la corretta gestione della protezione dei dati personali, e dovendo il team altresì interloquire anche il Responsabile della Protezione dei Dati (RPD – DPO), se nominato ai sensi dell’art. 37 e seguenti del GDPR. Il team per lo svolgimento delle attività di Incident Response è normalmente composto, in relazione alle necessità e in considerazione della concreta organizzazione e operatività della struttura attaccata, anche da una o più figure di ​Senior Security Consultant​. In ogni caso, tutte le risorse dell’Incident Response Team devono possedere le necessarie competenze per definire con i vertici dell’ente l’approccio metodologico più efficace e adeguato ad affrontare e risolvere le problematiche emerse.

Esempio di funzionamento di un SOC

***

Tutto quanto sopra esposto contiene un inquadramento generale e, per così dire, dottrinale dell’argomento.
Ora intendiamo raccontarvi un’esperienza reale, una storia di sopravvivenza aziendale vissuta da una classica PMI del Nord Italia che ha dovuto affrontare e combattere il “mostro” sopra citato, il ransomware.
I ransomware sono virus malevoli che consentono ai criminali informatici di appropriarsi della rete di un’azienda, di criptarne i dati e poi di chiedere alla vittima una somma in denaro (normalmente in cryptovaluta) per restituire i file. Secondo il Clusit², l’Associazione Italiana per la Sicurezza Informatica, i ransomware sono stati usati nel 42% degli attacchi mondiali gravi, in quasi un terzo di questi c’è stata la richiesta di denaro. Secondo una ricerca di Kaspersky condotta su 15.000 persone in tutto il mondo, il 33% degli italiani che ha subito un attacco ransomware ha dichiarato di aver perso quasi tutti i suoi dati. Indipendentemente dal fatto che abbia pagato o meno, solo l’11% delle vittime è stato in grado di ripristinare tutti i file criptati o bloccati dopo l’attacco. Il 17%, invece, ne ha persi solo alcuni mentre il 22% non è riuscito a recuperarne una quantità significativa³.
La vicenda che di seguito raccontiamo, seguendo la cronologia degli eventi ma rendendo opportunamente non riconoscibile la realtà di cui parleremo, ha rappresentato per il nostro Incident Response Team, un modello di gestione, virtuosa, di un incidente informatico, applicando tutte le discipline necessarie alla sua gestione: da quelle tecniche a quelle legali, alla comunicazione interna ed esterna.
Agli inizi di settembre 2020 un dirigente dell’ente, vittima dell’attacco informatico, si accorgeva, mentre si trovava sul posto di lavoro, che i files salvati sul server usuale risultavano non leggibili. Allertava dunque il responsabile dei sistemi informatici, che confermava trattarsi di files infetti da un crypto-locker. Lo stesso informava il dirigente di avere anche ricevuto un messaggio, tramite una chat online (le cui indicazioni aveva trovato in un file non criptato) da parte di sconosciuti, che presumibilmente erano i protagonisti dell’attacco informatico. Il riscatto richiesto era di circa 700.000,00 euro, pena la pubblicazione online della totalità dei dati carpiti.
In realtà, gli aggressori avevano già pubblicato su un sito del deep web, il 5% dei dati carpiti in modo tale da dimostrare l’efficacia delle loro azioni.
A quel punto, il responsabile IT dell’ente, sentendo su di sé il peso di una soluzione e, in parte, la responsabilità dell’accaduto, cominciava a cercare affannosamente in rete una possibile soluzione alla situazione critica che si stava delineando e le cui conseguenze non poteva nemmeno immaginare. Cominciava dunque a contattare online diverse aziende, che propongono la decrittazione dei file cifrati da ransomware.
Attenzione, questa attività per una vittima di attacco ransomware può essere sia un’opportunità che un ulteriore problema:

• per alcune famiglie di ransomware, soprattutto dei più datati, è possibile effettivamente procedere ad una decrittazione, poiché esistono online delle organizzazioni che hanno creato un database di chiavi di decrittazione, oppure perché anche istituzioni pubbliche (FBI, etc.) mettono a disposizione le informazioni a seguito di arresti perpetrati nei confronti dei criminali con conseguente sequestro dei server e dei pc utilizzati per l’attacco;
• alcune aziende invece, con altri intenti, di certo non benevoli e legali, semplicemente si propongono come intermediari tra le vittime e gli attaccanti e trattano il riscatto al posto delle vittime (consapevolmente o inconsapevolmente).

In sintesi, per i nuovi ransomware è molto difficile, se non impossibile, poter decifrare i dati. Tuttavia, conviene sempre tenere una copia dei dati cifrati in modo tale da poterli decifrare in un secondo momento in caso di arresto dei malfattori.
Ad ogni buon conto, il responsabile IT dell’ente vittima dell’attacco informatico, contattava anche, tra le altre, l’organizzazione, con la quale gli scriventi operano o comunque collaborano. Immediatamente allertato, tale Incident Response Team esterno, composto da un esperto legale, un esperto tecnico ed un incident commander, prendeva contatti con l’ente vittima e, contestualizzato l’evento in un primo veloce briefing, esponeva i passi necessari per gestire la situazione emergenziale e migliorare la resilienza aziendale:

• effettuazione della copia dell’ultimo back-up in un altro storage anche locale;
• effettuazione della copia dei server criptati per eventuali possibilità di decrittazione future in un altro storage anche locale;
• bonifica della copia dell’ultimo back-up per verificare la presenza di file infetti all’interno;
• effettuazione dell’analisi tecnica dell’incidente (digital forensic) prima di ripristinare il back-up;
• bonifica delle macchine/server infetti;
• ripristino del back-up;
• effettuazione della dichiarazione di violazione al Garante della Privacy entro 72 ore (eventualmente posticipando l’invio della digital forensic e/o vari approfondimenti);
• comunicazione a clienti e fornitori del data breach e delle misure attuate (sito web, social, comunicato stampa/brand reputation);
• riprogettazione ed implementazione di un nuovo sistema di back-up con controlli di efficacia e prove di ripristino;
• effettuazione di vulnerability assessment della rete al fine di verificare ulteriori vulnerabilità;
• implementazione delle misure di sicurezza cyber al fine di monitorare la rete in tempo reale per prevenire ulteriori minacce;
• valutazione di un’assicurazione cyber risk e di un servizio in abbonamento di SOS cyber/Incident Response.

Nel caso di specie, dall’analisi della richiesta pervenuta dalla vittima, contenente alcuni dettagli dell’incidente, e dal know how in possesso della organizzazione capofila dell’Incident Response Team esterno sulle moderne tecniche di attacco hacker, si è riusciti a identificare i seguenti, quali principali e più probabili vettori sfruttati per sferrare l’attacco tramite ransomware:

• e-mail di phishing;
• vulnerabilità dei sistemi esposti su Internet;
• errate configurazioni degli apparati di rete.

Infatti, tra i ransomware recenti e in quel periodo (fine 2020) più diffusi, i più noti e temuti erano Ryuk, Ekans e Maze. Pur essendo tra loro diversi, questi ransomware erano accomunati dalla metodologia (kill-chain) con cui attaccavano un’organizzazione o impresa.
La kill-chain è normalmente costituita dalle seguenti fasi:

1. Accesso alla rete aziendale: avviene tipicamente attraverso una campagna di e-mail di phishing attraverso la quale si installa il software malevolo (malware) sul pc della vittima.
2. Infezione: l’esecuzione di questo malware permette all’attaccante di carpire le credenziali e diffondere l’infezione all’interno dell’organizzazione.
3. Acquisizione di privilegi elevati: il malware, aggirando facilmente i meccanismi di difesa presenti sul dispositivo colpito, riesce ad impersonare utenti con maggiori privilegi di accesso ai sistemi (e.g. Amministratori di sistema, IT Manager).
4. Movimento laterale: gli attaccanti, in modo silente, si muovono liberamente all’interno dell’infrastruttura aziendale. In questo caso è necessario analizzare l’intera infrastruttura telematica, assumendo che proprio l’intera infrastruttura informatica (pc client, server, apparti di rete e dispositivi connessi) sia stata compromessa.
5. Cifratura dei dati: a questo punto viene scaricato il ransomware che si occupa della codifica di tutti i file aziendali, del blocco dei sistemi e della richiesta di riscatto. I gruppi hacker che utilizzano il ransomware Maze pubblicano i dati trafugati su Internet finché il riscatto non viene pagato. Oltre al danno di immagine che ne consegue, se i dati pubblicati sono dei dati personali, si rende necessaria la notifica all’Autorità Garante della Privacy.

Tornando dunque al caso in esame, una volta reso edotto il Board di quanto sopra, e a seguito di una prima riunione del Crisis Action Team aziendale, nel contesto della quale emergeva che la consistenza numerica dei server in servizio e potenzialmente infettati era di almeno n. 30 con ulteriori 200 macchine, l’Incident Response Team esterno veniva investito della gestione dell’attività di Incident Response, affiancando con pieni poteri di coordinamento le società e i professionisti informatici (amministratori di rete/sistema – responsabili esterni del trattamento dei dati), ai quali l’ente vittima si era fino a quel momento affidato, e procedendo ad elaborare un piano di gestione comprendente quanto di seguito riportato.

1) Mappatura fisica dell’infrastruttura tecnologica

• definizione del perimetro di analisi
• mappatura degli spazi fisici
• verifica degli aspetti di continuità elettrica
• verifica degli aspetti di collegamento ad internet
• raccolta delle credenziali di accesso

2) Analisi della rete interna

• rilevazione delle configurazioni di rete
• creazione anagrafica dei dispositivi collegati con catalogazione della tipologia, porte aperte, servizi attivi, condivisioni di rete ed eventuali vulnerabilità
• rilevazione dei punti di accesso fisico alla rete LAN
• rilevazione delle reti wifi e delle politiche di accesso

3) Analisi della rete esterna

• rilevazione degli indirizzi IP pubblici
• creazione anagrafica punti di accesso ed eventuali vulnerabilità tecnologiche

4) Analisi PC CLIENT e SERVER

• rilevazione dei software installati
• catalogazione degli account utente
• raccolta delle configurazione di rete
• raccolta delle policy di configurazione del sistema
• verifica delle configurazioni di backup
• verifica delle connessioni attive
• verifica dello stato del firewall di sistema
• verifica della risoluzione forzata dei nomi a dominio
• raccolta delle informazioni sui processi attivi
• verifica delle impostazioni e dello stato dei servizi
• verifica dello stato aggiornamento del sistema operativo
• catalogazione contenuto della cartella dei programmi
• mappatura delle unità di rete connesse
• raccolta dell’elenco dei file recenti
• raccolta dell’elenco file modificati di recente
• mappatura delle credenziali di accesso memorizzate
• rilevazione delle politiche di gestione delle periferiche USB

5) Analisi APPARATI DI RETE (switch, router, firewall, access point)

• rilevazione della tipologia di dispositivo
• verifica delle credenziali di accesso
• analisi della configurazione
• raccolta dei file di log

6) Analisi DEVICE GENERICI (telecamere, stampanti multifunzione, tecnologie proprietarie)

• rilevazione della tipologia di dispositivo
• verifica delle credenziali di accesso
• analisi della configurazione
• raccolta dei file di log

7) Analisi forense dell’attacco informatico

• rilevazione dei punti di accesso
• verifica del vettore di attacco
• identificazione, se possibile, del virus e delle tecniche utilizzate
• replica del funzionamento in ambiente protetto al fine di raccogliere ulteriori informazioni
• definizione del perimetro di accessibilità dell’attaccante
• verifica della possibilità di movimento laterale nella rete
• rilevazione delle modalità di accesso ai dati
• verifica dell’attuazione di tecniche di persistenza dell’attaccante

8) Configurazione del monitoraggio continuativo del traffico di rete su base temporale

• salvataggio degli eventi di rete con analisi del traffico
• ricerca di eventuali comportamenti sospetti
• rilevazione dei dispositivi a rischio
• elaborazione della mitigazione del rischio attraverso procedure e configurazioni software

9) Elaborazione dei dati raccolti

• acquisizione dei dati di input
• normalizzazione dei file strutturati
• archiviazione e armonizzazione degli indicatori di rischio
• valutazione coordinata del team di Cyber Analysis con attribuzione degli indicatori di impatto in base alle linee guida
• elaborazione delle eventuali misure correttive

10) Documentazione e proposta di mitigazione del rischio

• evidenziazione delle criticità fisiche
• rappresentazione grafica della topologia di rete
• elaborazione dei fattori di rischio informatico e tecnologico
• proposta di soluzioni per il miglioramento del livello di rischio
• redazione del report per la notifica al Garante della Privacy in caso di data breach

Al termine della fase di analisi si constatava che:

• la violazione era databile almeno al novembre dell’anno precedente al conclamarsi dell’attacco informatico;
• la tipologia di attacco era di tipo Advanced Persistent Threat, ovvero si trattava di attacco sferrato mediante l’utilizzo di più tecniche di attacco combinate con esfiltrazione di circa n. 86 GB di dati;
• la causa della violazione era riconducibile ad una combinazione dello sfruttamento di diverse vulnerabilità da parte delle Botnet attive; in sintesi, gli hacker avrebbero potuto sfruttare diversi canali di ingresso vulnerabili;
• era stato compromesso circa il 65% della rete.

Contestualmente, l’esperto legale facente parte dell’Incident Response Team esterno provvedeva ad affiancare il Board aziendale e il RPD/DPO per la Comunicazione del data breach al Garante della Privacy, suggerendo di predisporre e tempestivamente inviare una prima notifica c.d. preliminare e, a distanza di qualche settimana, la notifica c.d. integrativa, ove rendere conto dell’occorso nel dettaglio e sulla base delle informazioni raccolte medio tempore dal Team, altresì interloquendo con il Garante per dirimere ogni dubbio circa la correttezza della condotta aziendale.
Nel febbraio di quest’anno giungeva la notizia, diffusa dalla stampa internazionale, dell’arresto in Ucraina di affiliati e operatori del ransomware Egregor, individuati – sembra – seguendo il denaro, dunque rintracciando i pagamenti dei riscatti.

***

Conclusivamente, si comprende quanto sia cruciale disporre delle risorse, interne o esterne all’organizzazione, per saper gestire bene l’attività di Incident Response. Non ci si improvvisa esperti nella gestione degli incidenti di sicurezza: al contrario, si tratta di un servizio che richiede competenze qualificate e trasversali, capaci di dialogare tra loro al solo fine di affrontare, con immediatezza ed efficacia, una situazione critica e, così, saper restituire all’ente vittima di un attacco informatico la serenità e la forza necessarie per garantire la continuità operativa.

1. 1° aprile 2021 ANSA -https://www.ansa.it/sito/notizie/tecnologia/software_app/2021/03/31/world-backup-day4-italiani-su-10-pagano-riscatti-ransomware_98332894-dbb5-4553-8a7f-ef5fd03f5a98.html#:~:text=Il%2031%20marzo%20giornata%20sensibilizzazione%20sulla%20sicurezza%20dei%20dati&text=Quattro%20italiani%20su%20dieci%20hanno,grado%20di%20recuperare%20i%20documenti. ↩︎
2. Rapporto Clusit 2021 sulla sicurezza ICT in Italia https://clusit.it/rapporto-clusit/ ↩︎
3. 1° aprile 2021 ANSA -https://www.ansa.it/sito/notizie/tecnologia/software_app/2021/03/31/world-backup-day4-italiani-su-10-pagano-riscatti-ransomware_98332894-dbb5-4553-8a7f-ef5fd03f5a98.html#:~:text=Il%2031%20marzo%20giornata%20sensibilizzazione%20sulla%20sicurezza%20dei%20dati&text=Quattro%20italiani%20su%20dieci%20hanno,grado%20di%20recuperare%20i%20documenti. ↩︎