Regione Lazio, RansomEXX e opinioni. Facciamo chiarezza.

Redazione RHC : 8 Agosto 2021 23:00

Autore: Agostino Pellegrino

Data Pubblicazione: 9/08/2021

In un mondo di opinioni, quello che realmente fa la differenza sono i fatti. In questi giorni domina le prime pagine (finalmente, direi, per tipologia di argomento ed amore rispetto allo stesso) la vicenda relativa all’attacco subìto dalle infrastrutture IT della Regione Lazio.

Il “disquisitore italiano”, ovviamente, è passato da virologo a climatologo ad esperto di sicurezza informatica in un tempo incredibilmente breve, mostrando ancora flessibilità e spunti tecnici tali che il MIT, domani mattina, potrebbe anche chiudere.

La linea temporale degli eventi

Ciò che interessa noi, però, è proprio mantenerci distanti dalle opinioni e cercare di ricostruire tecnicamente i passaggi che conducono ad un disastro, perché tale è da intendersi nel 2021 un evento di queste proporzioni.

Ricostruiamo una timeline degli eventi principali che hanno caratterizzato sino ad ora la “Breach Regione Lazio”:

1. 01 Agosto 2021: comunicato ufficiale dell’attacco subito dalla Regione Lazio (viene immediatamente diffusa l’ipotesi Ransomware dalle maggiori testate)
2. 02 Agosto 2021: ulteriori voci indicano come eventuale punto di accesso un client VPN di un dipendente di un’azienda esterna ed un’infezione avente come vettore un Remote Access Trojan, si ipotizzava Emotet, e come payload, il ransomware vero e proprio, Lockbit 2.0.
3. 03 – 04 Agosto 2021: dichiarazioni ovviamente confusionarie dal mondo politico. Zingaretti: “La situazione è seria e molto grave”…”Stiamo difendendo la nostra comunità da questi attacchi di stampo terroristico.” Attribuzione attacco ad organizzazione straniera che utilizza RansomEXX (Sprite Spider). Accantonata ipotesi Lockbit 2.0.
4. 05 Agosto 2021: Zingaretti comunica recupero backup su sistemi protetti via hardware di recente installazione (sembra che tutto vada per il verso giusto, appaiono però anomali i tempi di “ricerca” del backup; quasi sei giorni sembrano veramente troppi).
5. 06 Agosto 2021: 795 record di account di accesso ai sistemi della Regione Lazio in vendita su Dark Web (sembra si avvii una manovra di seconda estorsione: ma i dati non sono stati recuperati?).
6. 07 Agosto 2021: nuova lettera di ricatto da parte di “organizzazione terroristica” che chiede contatti diretti col “CEO” o con un legale rappresentante (ma il backup non era al sicuro?).

Inquadrata la linea temporale degli eventi ed i punti di incertezza nella gestione delle fasi di “Incident Response”, analizziamo quella che avrebbe dovuto essere stata la catena di azioni da intraprendere con un approccio rigoroso, magari ispirato alla Cyber Forensics, fusione della Cyber Security con l’Informatica Forense classica, che importa le tecniche di indagine da White Hat, il “pirata buono” gestendole con rigore forense, al fine di garantire ripetibilità e solidità all’indagine stessa, nonché di conferire valore legale ai dati raccolti.

Il malware

Il primo step avrebbe dovuto essere un’immediata analisi di tutti i dati “volatili” presenti sui sistemi centrali al momento dell’attacco: questo avrebbe consentito di identificare immediatamente il tipo di Ransomware, specie nel caso di RansomEXX, in quanto residente in memoria come payload di secondo livello rispetto ad un ransom più semplice che si affida ad un “vettore” classico residente su disco.

Questa strategia consente ai più moderni malware di non essere facilmente rilevati dai software antivirus, tenendo comunque presente che, nel caso di attacchi di tale consistenza, i codici dei Ransomware vengono modificati ad hoc, al fine di alterare l’impronta dei dati che l’euristica (la capacità di un software di rilevare codice “sospetto”) di un eventuale antivirus riuscirebbe ad intercettare. Dai tempi di risposta (dal 30 luglio al 4 Agosto) del team che si è occupato dell’analisi non sembra si sia praticato questo check.

Si passa quindi alla fase di analisi dei dati non volatili, alla verifica di tutto ciò che è “salvato” sui supporti di archiviazione. Il backup, già a quest’epoca, doveva essere stato individuato e ripristinato insieme ad eventuali strutture fisiche e/o logiche di disaster recovery, cioè tutti i mezzi utili a ripristinare l’operatività dei sistemi e riprendere a fornire “servizio” all’utenza (nelle realtà aziendali ci si preoccupa normalmente della Business Continuity, nella PA durante un evento pandemico molto meno direi…).

In concomitanza con quanto descritto, l’eventuale Incident Response Team si preoccupa di analizzare approfonditamente tutti i log sia a livello network che a livello server, al fine di individuare anomalie, specie sugli accessi (dovrebbero essere in uso sistemi Autorizzazione, Autenticazione ed Accounting) ai servizi in rete e ad eventuali tentativi di connessione da indirizzi IP (gli indirizzi che identificano le nostre macchine in rete) non autorizzati e di mantenere sotto controllo il traffico di rete, strutturando magari dei sistemi Honeypot controllati al fine di attirare l’attenzione di un eventuale malintenzionato e riuscire a prelevare importanti informazioni sulla provenienza di un eventuale attacco (cosa difficilissima e spiegheremo successivamente il perché) e sulle metodologie di controllo (è possibile capire, dai comandi impartiti ai “servizi malevoli” in ascolto sui sistemi hackerati, di quali payload si tratti con basso margine d’errore).

Il GDPR

Tutto questo, oggi, dovrebbe avere come fine dell’indagine l’intercettazione di un’eventuale esfiltrazione dei dati sensibili dei quali la Regione Lazio è direttamente responsabile, dovendo provvedere, secondo GDPR, a garantire con ogni mezzo la protezione degli stessi.

Nel caso di questo Data Breach anomalo, del quale non ci è dato conoscere dettagli certi, l’intervento del Garante della Privacy avrebbe dovuto essere pressoché immediato in concomitanza con la notifica dell’evento agli interessati poiché la non disponibilità dei dati ha comportato ritardi nelle vaccinazioni anti Covid-19 ed in altri trattamenti sanitari.

In questa fase è facile pensare che la Regione Lazio debba iniziare a preoccuparsi di fornire dati sufficienti a dimostrare che, nonostante il Data Breach, siano state introdotte tutte le possibili azioni di mitigazione del rischio di attacco previste dal GDPR stesso.

Nello specifico, per un attacco ransomware, il decalogo che ho sintetizzato riassume i punti principali in:

1. Individuazione del personale addetto al trattamento dei dati e riduzione delle possibilità di accesso e modifica, anche involontaria, dei sistemi;
2. Definizione dei perimetri interni del network al fine di limitare i danni da intrusione alle sole aree interessate dalla breccia;
3. Definizione e potenziamento del perimetro esterno del network;
4. Formazione dei dipendenti, sensibilizzazione alle tematiche relative alla Cyber Security, analisi delle conoscenze e generazione di modelli di compliance relativi alla privacy ed alla sicurezza informatica.
5. Definizione di Penetration Test a cadenza regolare, auditing per garantire la compliance dei sistemi e del personale e di un piano di governance delle policy rigoroso.
6. Definizione di un Incident Response Plan e di un Disaster Recovery Plan collaudati.
7. Definizione di un Business (service) Continuity Plan collaudato
8. Definizione di una procedura CHIARA e di IMMEDIATA ESECUTIVITÀ relativa ai sistemi di backup dei dati (in site ed off site), alla protezione (segmentazione del network e separazione rispetto ai server esposti) ed al ripristino degli stessi al fine di garantire continuità di servizio all’utenza.
9. Utilizzo di tecniche crittografiche forti e di sistemi AAA che forniscano autenticazione a due o tre fattori per gli accessi più critici.
10. Gestione centralizzata dei log

È la mancanza di tutto questo che ci ha condotti, ci conduce e ci condurrà al peggio.

Concludo questa disquisizione sintetica, semplificativa e puramente tecnica fornendo un ulteriore spunto di riflessione rivolto agli esperti dell’ultimo minuto: oggi, nel 2021, chiunque volesse attaccare o simulare un attacco, avrebbe la possibilità di sfruttare interi network per rendersi anonimo.

La Onion Network TOR fornisce un sistema stratificato (a cipolla) di protezione che consentirebbe ad un utente malintenzionato di essere fisicamente a casa propria davanti al suo pc e logicamente “uscire” da uno dei 1395 Exit Nodes (https://www.bigdatacloud.com/insights/tor-exit-nodes) sparpagliati in giro per il mondo, Russia compresa, senza la possibilità di poterlo individuare se non grazie a disattenzioni proprio del malintenzionato in questione (magari in un altro articolo approfondiremo anche questo argomento).

Ricordate al giornalista “mercante di click”, al politico “conspiracy lover”, all’amico al bar che, talvolta, ove non si abbiano competenze sufficienti, non è necessario esprimere un’opinione su qualcosa; non si è obbligati a farlo e si fa solo del bene a tacere. O a studiare.

Redazione
La redazione di Red Hot Cyber è composta da un insieme di persone fisiche e fonti anonime che collaborano attivamente fornendo informazioni in anteprima e news sulla sicurezza informatica e sull'informatica in generale.