Nella serata del primo gennaio 2022 l’attacco all’azienda sanitaria ULSS 6 di Padova, avvenuto ai primi di dicembre, ha subito un aggiornamento: è arrivata la rivendicazione da parte del gruppo ransomware Lockbit 2.0. Sul sito ufficiale (sotto rete Tor) della gang criminale è infatti comparso l’annuncio con il quale si minaccia, a seguito di richiesta di riscatto economico, la diffusione online di 9.246 file esfiltrati durante l’attacco.
Aggiornamento del 5 gennaio 2022. Come riferisce il presidente della Regione Zaia alla stampa nazionale, i dati rubati preoccupano per la loro importanza: “Penso abbiano cartelle o dati sensibili in mano: non cediamo al ricatto” e fa trapelare che il riscatto richiesto dal gruppo criminale ammonterebbe a 800.000 euro.
Intanto, il gruppo criminale (che è entrato in possesso dei file) ha fissato anche un timeout per l’accordo tra le parti nella giornata del 15 gennaio prossimo. Non rimane, dunque, che attendere il termine del countdown per fare un’analisi dettagliata del data leak e comprendere così la reale portata dell’incidente di sicurezza.
Indice degli argomenti
Attacco alla Ulss 6 di Padova: si torna alla normalità
La situazione che si è creata all’Ulss Euganea di Padova in seguito all’attacco ransomware che nelle scorse settimane ha colpito il sistema informatico è emblematica dei tempi che stiamo vivendo ed è la conferma di come la Sanità sia una vittima perfetta e delle gravi conseguenze che attacchi del genere possono avere su tutti noi.
Adesso sembra che il sistema informatico dell’Ulss 6 Euganea stia muovendo i primi passi per il ripristino delle diverse funzionalità. Come segnalato da alcune fonti giornalistiche, nella mattina del 10 dicembre è stato ripristinato il servizio informatico di prescrizione farmaceutica e specialistica, che a seguito dell’attacco risultava bloccato.
I medici e i farmacisti, infatti, fino al giorno prima si sono adattati con “carta e penna”, tornando alla tradizionale compilazione delle ricette rosse: un vero e proprio downgrade della metodologia con cui l’Informatica applicata alla Medicina aveva comodamente abituato medici e pazienti negli ultimi anni.
Si segnalano ancora disagi nelle sedi della Guardia medica, in particolare a Padova, dove sembrerebbero non funzionare i telefoni VoIP. Da ilGazzettino.it, inoltre, veniamo messi al corrente che l’Ulss Euganea ha (giustamente) rifiutato il pagamento del riscatto in Bitcoin, a seguito dell’attacco ransomware subito.
Se un ransomware può uccidere un neonato: un caso che deve farci riflettere
Quanto “costano” questi incidenti informatici
Così come è già accaduto per l’attacco all’Ospedale San Giovanni Addolorata di Roma, i giornali (quando lo fanno, giacché pensare che le strutture pubbliche compromesse siano solo quelle di cui leggiamo saltuariamente articoli sulla stampa è un modo di pensare decisamente ingenuo) ci mettono al corrente di un’altra struttura pubblica compromessa da ransomware (o “pizzo informatico”), uno dei tanti armamenti a disposizione del cyber crime.
Quanto costano agli italiani questi incidenti informatici? Se si trattasse di un’azienda privata, verosimilmente le responsabilità e i costi potrebbero ricadere esclusivamente nelle tasche dei soci o dei proprietari di quella o di un’altra azienda colpita, ma in questi casi si tratta di aziende pubbliche, aziende che percepiscono (spesso ingenti) fondi pubblici.
A prescindere se in futuro si dovesse scoprire che l’Ulss abbia poi effettivamente pagato o meno il riscatto in Bitcoin, c’è un danno in termini di ore-uomo, in termini di pazienti e cittadini che si vedono negati un servizio, o che fruiscono di un servizio rallentato.
A prescindere, un attacco del genere andato a buon fine causa disservizi che, direttamente o indirettamente, qualcuno pagherà e, come nel caso dell’Ulss, sta già pagando in termini di immagine, in termini appunto di impossibilità di fruizione del tal o tal altro servizio sanitario.
La mancata adozione di best practice di cyber security
In un’Italia sempre più connessa, in un’Europa che sta investendo fortemente in sistemi e tecnologie IoT (anche in campo sanitario), è possibile che i dirigenti dei sistemi informativi delle PA continuino a non imporre l’adozione di sistemi SIEM nei relativi datacenter, verosimilmente né sistemi PAM/IAM, tantomeno a far attuare operativamente le misure minime di sicurezza informatica (best practice, e per intenderci, anche quelle volte alla prevenzione e al contrasto di attacchi ransomware) per una buona segregazione sia del traffico di rete che delle operazioni in scrittura autorizzate per utenti, su fileserver e share condivise?
Già solo la stampa ci dimostra che è tristemente possibile, anzi, possibilissimo. E con questi bei risultati. Risultati e costi di gestione che, se ci riflettiamo bene, in fin dei conti – a prescindere se verrà o meno pagato un riscatto, e a prescindere dalla data in cui tutto – auspichiamo – tornerà operativo come prima dell’attacco – andranno indirettamente a gravare nelle tasche degli italiani.
La lezione dell’attacco ransomware all’Ulss 6 di Padova
A questo punto è lecito chiedersi quale sarà la prossima infrastruttura critica ad essere colpita (e affondata).
Eppure da molto tempo ormai, enti, ricercatori e comitati tecnici che si occupano di cyber security, mettono in guardia le aziende e gli addetti ai lavori nel mondo dell’informatica sui rischi di una connettività pervasiva e, soprattutto, di una “cattiva progettazione”.
Basta consultare le linee guida del NIST relative alla prevenzione di attacchi ransomware (che indubbiamente rimandano ad articoli e approfondimenti aggiuntivi) per accorgersi – ammesso che il lettore sia operativo nel mercato InfoSec – che strutturare un’architettura di rete a prova di ransomware è un progetto a sé.
Chiariamoci, non si tratta di pianificare un viaggio interstellare alla Christopher Nolan, ma certamente oggi più di ieri non si può più sentire in giro, né riscontrare sul campo, che qualcuno tenga in piedi una rete – e soprattutto una rete di un’infrastruttura pubblica – con quattro firewall e switch, un load balancer, un dominio Active Directory, un paio di NAS e qualche policy.
Ma, ahinoi, accade purtroppo ancora (e per quanto accadrà ancora?) questo, in barba appunto alle già citate best practice.
Queste best practice e le direttive pubblicate da autorevoli enti come il NIST (ma non solo, spendiamo un po’ di tempo anche sulle linee guida rilasciate da IEEE, giusto per citarne un altro) ci raccontano appunto che per proteggere una rete e/o un sistema informatico vanno adottati degli approcci scientifici, alla pari delle leggi dell’architettura: ad esempio, chi non utilizza protocolli di autenticazione (come l’802.1X) in un reparto dove sono operative infrastrutture critiche, evidentemente o sottovaluta la problematica, o ancor peggio non ha mai riflettuto sulla possibilità che qualcuno possa accedere abusivamente a quella o quell’altra sottorete dell’azienda o di quell’ospedale. E causare immensi danni.
Altro esempio: quanti sono i sistemisti, gli amministratori di sistema e i dirigenti che, parlando di traffico DNS, conoscono e attuano le tecniche di protezione illustrate in questo volume di IEEE? Eppure, dovrebbero padroneggiarle poiché il traffico DNS è sfruttato dai server C&C, di cui i ransomware fanno ampiamente utilizzo.
Quante strutture statali oggi, alle soglie del 2022, sono effettivamente seguite da un SOC? Quanti sono i sistemi informatici e informativi sottoposti a costante monitoraggio cibernetico? Ma ancor di più, le reti informatiche e le architetture dei sistemi (in cloud piuttosto che on-premises) di un ospedale, o di un qualsivoglia altro ente pubblico, rispettano effettivamente le linee guida della modellizzazione Zero Trust Security?
O forse c’è qualcuno che continua a pensare (eccome se c’è: anzi, eccome se ci sono) che sia sufficiente applicare gli aggiornamenti periodici di Windows ed effettuare dei penetration test per assicurare l’effettiva sicurezza informatica di quella Rete o di quel sistema informatico?
In conclusione
Se acronimi come “Stride”, “Dread”, “Trike” o ancor di più come le parole “Threat Model” (contenuta nella RFC 3552) risultano termini astrusi o sconosciuti al fornitore ICT o Cyber Defence con cui ti stai interfacciando, evidentemente il tuo interlocutore desidera solo “venderti un prodotto”, una (apparente) soluzione ingegnerizzata per un cliente tipo o per un determinato problema.
Ma la realtà è un’altra, o meglio, è diversificata, e richiede analisi, riscontri e adattamenti verosimilmente per la maggior parte dei contesti, dei clienti e delle loro infrastrutture.
Poiché le problematiche nel mondo della cyber security sono tante, e spesso richiedono analisi e valutazioni effettuate a più mani (ossia a più teste), prediligendo consulenti e fornitori di cyber security esterni all’infrastruttura stessa (quanto potrà essere veramente imparziale un vulnerabilty assessment effettuato dalla medesima società che gestisce anche la rete del cliente in esame?)
Ecco perché il leitmotiv “La sicurezza informatica non è un prodotto ma un processo” è vero oggi ancor più di quanto lo fosse ieri, lo è ancor di più oggi proprio perché aziende, apparati, dispositivi, processi e dati di enti pubblici e privati, dati e sistemi di comuni cittadini e consumatori sono sempre più connessi non solo ad Internet, ma anche tra di loro.
Ergo, tutti noi siamo sempre più collegati: dunque chi lavora nelle aule dirigenziali ha il diritto-dovere di ragionare ingegneristicamente sempre di più in primis in termini di Architetture informatiche sicure e di Threat modelling, ancora prima di qual sia la migliore o peggiore piattaforma EDR, o il miglior SOAR presente sul mercato.
Articolo pubblicato lo scorso 13 dicembre 2021 e aggiornato in seguito alla rivendicazione del gruppo ransomware Lockbit 2.0
