Posted on by Andrea Monti

Cosa insegna il contagio ransomware della SIAE

Come sempre, la colpa degli attacchi informatici è degli “hacker” o degli “utenti sprovveduti”. Ma che ruolo ha l’industria del software nel rendere possibili questi eventi? di Andrea Monti – Originariamente pubblicato su PC Professionale n. 369

Dopo il caso estivo di Regione Lazio, lo scorso ottobre  è stata la volta della Società Italiana Autori ed Editori (SIAE) ad essere attaccata da un ransomware che è riuscito —a quanto si legge— ad esfiltrare una sessantina di giga di materiali, da documenti di identità, indirizzi, dichiarazioni di paternità autoriale.

La vicenda ha suscitato reazioni che oramai sono diventate uno standard, pur con qualche variazione sul tema, fra chi subisce eventi del genere: “se hanno colpito noi, nessuno e al sicuro”, “abbiamo segnalato l’evento alla polizia postale e al garante dei dati personali”, “la security è al lavoro per limitare i danni”. Puntuali sono arrivati anche i commenti scandalizzati sull’assenza di una “cultura della privacy” e sulla sottovalutazione degli obblighi di adozione di misure di sicurezza imposti dalla normativa sulla protezione dei dati personali, e quelli degli “esperti del giorno dopo” che hanno la soluzione per ogni problema, dopo che si è verificato. Insomma, come nel dopopartita o nel dopoelezioni, non c’è bisogno di approfondire o farsi qualche domanda in più: basta ricorrere ai consolidati luoghi comuni e aspettare la prossima occasione.

Nel dibattito pubblico seguito all’incidente e durato lo il tempo di qualche tweet sono rimaste sullo sfondo alcune questioni che affliggono da sempre il mondo IT e che continueranno ad essere ignorate innanzi tutto dal legislatore e poi da tutto il resto della filiera: le scelte produttive delle multinazionali del software, i modelli per la commercializzazione dei servizi di sicurezza, l’assenza di responsabilità legale di chi mette in commercio prodotti difettosi o mal progettati, norme burocratiche e generatrici di inerzia come il regolamento sulla protezione dei dati personali che, da un lato, impone di proteggere dati e informazioni e, dall’altro, ostacola l’adozione di strumenti di monitoraggio e prevenzione degli attacchi.

È vero, non esistono software privi di difetti. Se poi consideriamo  l’inte(g)razione fra sistemi operativi, software, piattaforme, protocolli e via discorrendo è abbastanza intuitivo capire che non esiste un unico punto di vulnerabilità e che la somma dei problemi di ciascun componente di un servizio è ben superiore a quella delle singole parti.

Ad esempio: una vulnerabilità applicativa consente di prendere il controllo di una macchina. Ma se, errando, il server in questione è stato posizionato in una parte della rete dalla quale è possibile attaccare lateralmente macchine critiche vulnerabili per altre ragioni, l’effetto dell’errore amplifica quello delle singole vulnerabilità. Questo non significa, tuttavia, che sia lecito immettere sul mercato codice mal progettato e mal scritto perché tanto… È chiaro, in altri termini, che la prima difesa dovrebbe essere software ben fatto e che chi vende programmi difettosi dovrebbe pagare i danni, né più né meno come accade nel caso dei prodotti fisici.

Tradizionalmente le software house nicchiano ogni volta che viene posto in discussione questo tema e si nascondono dietro licenze d’uso, contratti e proprietà intellettuale. Ricordo vecchie (ma nemmeno tanto) licenze che addirittura vietavano di collaudare il software e di rendere pubblici i risultati. In pratica, poi, proprio per l’oscurità delle pratiche commerciali che ruotano attorno al software è molto difficile promuovere un’azione legale contro chi ha licenziato un “prodotto” buggato.

Anche il modo in cui vengono commercializzati i servizi di sicurezza ha un ruolo nella costruzione del colosso dai piedi d’argilla che è l’infrastruttura ICT nazionale. È fuori di dubbio che l’esternalizzazione della sicurezza, per esempio tramite i managed cloud security service, sia più “comoda” per il fornitore. Tuttavia, il suo effetto è quello di deresponsabilizzare l’utente che perde la percezione dell’importanza di tenere sotto controllo la propria infrastruttura e i propri utenti. È inutile contestare questa considerazione dicendo che l’utente dovrebbe in ogni caso mantenere un elevato livello di consapevolezza sulle necessità di protezione dei sistemi, ecc. ecc. ecc. La realtà è che non accade e i casi di cui stiamo parlando lo dimostrano al di là di ogni ragionevole dubbio.

Infine, anche la legge contribuisce ad aumentare confusione e inefficacia delle scelte di gestione della sicurezza di reti e sistemi. Il famigerato “GDPR” è nato vecchio, con la testa rivolta verso gli inizi del 2000, e interpretato avendo in mente infrastrutture che non esistono più. Un solo esempio dimostra la correttezza di questa affermazione: secondo la normativa, un software che tratta dati personali dovrebbe essere progettato per garantire “di default” sicurezza e integrità dei dati che consente di maneggiare. Mi domando quanti “audit” del genere siano stati condotti sui software prodotti dalle multinazionali e utilizzati a qualsiasi livello e mi chiedo se chi ha scritto quella norma si è posto il problema della quantità di linee di codice che si dovrebbero esaminare per ottenere dei risultati seri. Siamo pratici: Windows 10 ha circa cinquanta milioni di linee di codice e un “vecchio” kernel di Linux, circa quindici milioni. E stiamo parlando solo di sistemi operativi. Certo, analisi del genere non si fanno a mano, tuttavia rimane la mostruosità del dover anche solo pensare di doverle eseguire. E allora che senso ha imporre “per legge” qualcosa che non ha senso o non è realisticamente praticabile?

Sotto un altro profilo: gli attacchi ransomware hanno dimostrato che la forma più efficace per limitare i danni è la possibilità di accorgersi il prima possibile di quello che sta accadendo. I sistemi per farlo ci sono, ma —ancora una volta— un’interpretazione burocratica del GDPR e dello Statuto dei lavoratori rende estremamente difficile, se non impossibile, adottare sistemi di questo genere. In nome del “divieto di controllo a distanza”, una norma pensata negli anni 70 del secolo scorso, aziende e istituzioni sono costrette a rinunciare a metodi che potrebbero mitigare fortemente le conseguenze di un’azione illecita.

Con uno scenario del genere i criminali possono dormire sonni tranquilli perché avranno sempre a disposizione sistemi adeguatamente non protetti, e non tutti saranno così sfortunati come il gruppo REvil, oggetto di un contrattacco sferrato dal FBI  e da “Paesi amici” che lo ha ridotto all’impotenza.

Ma questa, è un’altra storia.

Possibly Related Posts: