Il ventre molle dell’IT italiana: la sicurezza

Sicurezza IT, o meglio la sua quasi totale mancanza

Ultimamente sono stato coinvolto in alcuni casi di attacchi ransomware nei confronti di aziende italiane, e la cosa mi ha preoccupato abbastanza, non tanto per la pericolosità in se dell’attacco ma per la imbarazzante mancanza di implementazione di processi di sicurezza all’interno delle varie realtà aziendali.

Una mancanza di sicurezza che copre non solo gli aspetti meramente tecnici, ma anche quelli procedurali e persino legali.

Una infezione di tipo cryptoloker, kryptowall o simili, infatti, è una buona occasione per testare i meccanismi implementati di difesa, o, purtroppo, la loro totale mancanza.

Generalmente la copertura di sicurezza nelle strutture italiane è demandata a firewall perimetrale ed antivirus. La totale assenza di procedure di sicurezza è testimoniata dalla assenza, di solito, di un manuale operativo sulle procedure di sicurezza informatica, questo persino dove la legge ne faccia esplicita richiesta.

Allora analizziamo cosa succede con un attacco di un “normale” ransomware:

1) una o piu macchine vengono infettate da una qualche versione di malware.

Le ragioni che stanno dietro alla infezione sono molteplici, anche la presenza di un antivirus non garantisce una protezione assoluta, una variante nuova potrebbe essere non rilevabile con le firme virali correnti.

2) dopo essersi installato in una qualche macchina della rete il ransomware si attiva a seguito di un evento

l’evento potrebbe essere un log-in di un utente con sufficienti diritti amministrativi, un comando esterno proveniente da una struttura tipo command and control e via dicendo.

3) il malware inizia a criptare risorse

File, documenti, cartelle e strutture possono essere oggetto della azine, dipende dalla variante. Anche risorse di rete possono essere attaccate tramite, ad esempio, l’accesso a shares o cartelle condivise.

più o meno a questo punto si realizza che è in corso un attacco, e si cerca di porvi rimedio

4) il malware informa l’attaccato che condizione per togliere la cifratura alle risorse attaccate è il pagare una certa cifra con modalità variabili, da un semplice bonifico ad un pagamento tramite metavalute tipo bitcoin.

Questa modalità di funzionamento è nota da tempo, i ransomware sono presenti sul mercato da una decina di anni nelle diverse forme.

A questo punto dal punto di vista dell’attaccato occorrerebbe agire immediatamente cercando di isolare la infezione, limitare i danni, riportare l’operatività della rete alla norma.

ed è qui che si notano le lacune più grosse nelle nostre infrastrutture.

Isolare l’infezione:

Un attacco di questo tipo richiede che venga isolato nel modo più rapido possibile la fonte di infezione. Dal momento che un ransomware può forzare la cifratura di risorse sia locali che di rete, l’individuazione della macchina infetta non è sempre elementare.

La presenza di un IPSIDS, un SIEM o almeno un log collector e di procedure di analisi dei log di sistema sono gli strumenti principe. (assimilabili ai log ci sono anche gli eventi visibili nell’event viewer di microsoft).

Le tracce da cercare sono ovviamente le attività di accesso ai file criptati in termini di chi, dove e quando. cosi vedere chi ha avuto accesso e modifica ad un file criptato può dare indicazione di quale sia la sorgente dell’attacco, ammesso e non concesso che questa sia riferiile ad una sola macchina.

Una volta identificata la macchina occorre isolarla dalla rete, se appartenente ad un dominio Active Directory è anche consigliabile toglierla da tale dominio (questo per distruggere il sid univoco di riconoscimento associato alla macchina che potrebbe essere utilizzato da un eventuale secondo device infetto).

Limitare i danni:

Sul lato della mitigazione dei danni occorre procedere a diverse attività:

1) informare il proprio vendor antivirus dell’avvenuto attacco per chiedere che venga emessa una patch opportuna ed eventualmente un tool di rimozione

2)effettuare denuncia alla polizia postale, in quanto si è stati vittima di un reato informatico specifico previsto dal nostro codice penale e civile.

in funzione delle risposte ai primi 2 punti la parte operativa potrebbe essere diversa da caso a caso. ad esempio sia il vendor che la polizia postale potrebbero richiedere un minimo di attività di tipo forensic per individuare il tipo di infezione, la sorgente dell’attacco e, eventualmente, il responsabile.

3)procedere a procedure di analisi antivirusantimalware su tutta la struttura informatica a seguito della emissione della patch da parte del fornitore di antivirusantimalware.

Questo passaggio è fondamentale, in quanto il rischio di re-infezione o di attivazione di un secondo nodo infetto è elevata. Come detto in precedenza molti Ransomware sono attivati in seguito ad eventi, e quindi potrebbero esserci macchine infette in cui il codice malevolo è semplicemente silente.

4)procedere al restore delle risorse compromesse

questo è un punto abbastanza critico che richiede ancora una volta una certa attenzione, in quanto le stesse risorse provenienti da un restore potrebbero essere infette o portatrici del malware. il restore va fatto quindi inizialmente in un ambiente isolato e sottoposto a verifica da parte della soluzione antivirus aggiornata, e possibilmente anche sottoposto ad un secondo test con un secondo brand antivirus.

Riportare alla operatività le risorse:

Questo dovrebbe essere l’ultimo passo, solo dopo avere eseguito gli step citati in precedenza infatti ha senso ripristinare l’operatività completa, altrimenti si corre il rischio di postporre il problema.

Riportarsi alla oeperatività significa anche ridefinire le procedure operative a seguito dell’analisi dell’incidente per ridurre il rischio che si ripeta

 Cosa si rischia:

Come al solito l’approccio reattivo e non proattivo alla sicurezza informatica porta anche a una non chiara visione dei rischi cui si va in contro in caso di simili outbreak.

vi sono almeno 2 fattori da considerare:

1) il danno immediato, legato come minimo alla perdita di operatività e al ripristino dei dati

I costi associati ad un problema di sicurezza sono associati a diverse componenti quali la perdita di dati, i vincoli legislativi, i costi di ripristino, i costi per mancata operatività, i costi di immagine … tutte componenti che dovrebbero far parte delle considerazioni implementative quando si disegna un sistema di sicurezza e quindi portare alla definizione del budget da dedicare alla sicurezza stessa. Considerazioni spesso disattese, ammesso e non concesso che siano state effettuate valutazioni in tal senso in fase di definizione e stesura dei budget.

2) gli eventuali strascichi legali nel caso si sia veicolo di infezione verso terzi.

sopratutto per quello che concerne il secondo punto vige in italia un certo livello di allegra incoscienza, dimenticato che vigendo il concetto di responsabilità oggettiva noi siamo, nei fatti, responsabili di qualsiasi nocumento produciamo con le nostre strutture informatiche a terzi. Il problema è sia penale che civile, e per altro vale la pena di ricordare che i vari regolamenti tecnici specifici che fanno riferimento alla nostra legislazione informatica forniscono un insieme di vincoli MINIMI da rispettare.

Non rispettare tali vincoli minimi ci espone al rischio di procedimenti penali e civili, ma anche quando si rispettino questi parametri minimi il legislatore ha chiaramente espresso il concetto che ancorchè protetti da eventuali procedimenti penali, siamo ancora perseguibili in via civile per danni provocati a terzi dalle nostre strutture informatiche.

L’introduzione dei concetti di idoneità e attualizzazione nella nostra legislazione di settore, infatti, ci obbligano a superare i livelli minimi di protezione indicati.

In altri termini:

                                 la mancanza di un efficiente sistema a protezione di email e web browsing, veicoli principale di infezione e diffusione di codice malevolo, ci espone al rischio di essere considerati, nei fatti, corresponsabili nel caso di procurata infezione a terzi anche se tali soluzioni non sono esplicitamente indicate nei riferimenti tecnici del legislatore, ma considerate nei fatti strumenti consolidati di protezione delle strutture informatiche.

Per quanto queste considerazioni possano sembrare ovvie e banali, la realtà è che spesso le nostre strutture IT si trovano impreparate ed inefficienti persino di fronte a questo tipo di problematiche elementari.

 

To the official site of Related Posts via Taxonomies.


Discover more from The Puchi Herald Magazine

Subscribe to get the latest posts sent to your email.

CC BY-NC-SA 4.0 Il ventre molle dell’IT italiana: la sicurezza by The Puchi Herald Magazine is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.