Wannacry, le sciocchezze degli esperti (ma anche no)

Introduzione

Quella che segue è una critica (e in parte una trollata) all’articolo del prof. Alberto Berretti, dell’Università degli Studi di Roma “Tor Vergata”, pubblicato su Agenda Digitale il 16/05/2017.

Il suo pezzo solleva una serie di critiche agli “esperti” (enfasi sua), colpevoli di “[ricercare] spiegazioni troppo semplici“, con un atteggiamento “che sconfina troppo spesso nella faciloneria“.

Tra le tendenze naturali dell’uomo vi è quella a trovare una spiegazione semplice per ciò che accade: e questo è sicuramente, nel lungo periodo, un fatto positivo, perché è la spinta che indirizza la mente umana verso quella comprensione razionale del reale che chiamiamo “scienza”. Il problema nasce quando cerchiamo spiegazioni troppo semplici, o quando tentiamo di assegnare con facilità – che sconfina troppo spesso nella faciloneria – responsabilità e colpe.

Questo principio appare in tutta la sua evidenza leggendo i commenti e le discussioni – sì, anche fra esperti – sulla vicenda del ransomware che ha colpito negli ultimi giorni una quantità di organizzazioni, tra cui, pesantemente, il servizio sanitario nazionale inglese.

Dato che il professore si è prodotto in questo che definirei più che altro un divertissement, io farò lo stesso: cogliete quindi le mie note al suo lavoro, che cito senza manipolazioni, con il giusto spirito, con il presupposto cioè che il mio è solo un voler far polemica. Ciò nonostante, cercherò di seguire il più fedelmente possibile le idee di Berretti: se la sua è una critica, la mia sarà una meta-critica 🙂

such meta!

L’NSA, le cyberarmi e Snowden

(1) “È colpa dell’NSA che sviluppa cyberarmi”. Questo è un discorso molto frequente, ed incolpare gli amerikani cattivi è sicuramente un selling point molto efficace giornalisticamente. Il malware in questione utilizza in effetti delle vulnerabilità che fanno parte dell’arsenale dell’NSA trafugato e diffuso da un gruppo di hacker che si sono fatti chiamare “Shadowbrokers”, gruppo che con una certa probabilità potrebbe far capo all’intelligence russa.

Ci si dimentica il dettaglio che l’NSA è un’organizzazione di intelligence, e che l’intelligence nel XXI secolo si fa in parte – in una parte significativa – con tecniche digitali. L’NSA starebbe sprecando i soldi del contribuente americano se non avesse dei tool del genere.

L’idea che l’NSA, come agenzia di sicurezza finanziata dal pubblico, farebbe male il suo lavoro se non accumulasse exploit non è solo estremamente controversa, è anzi invisa a molti esperti (ne cito uno a caso) ed è tutt’altro che di importanza secondaria. Utilizzare fondi pubblici per consentire alle agenzie di intelligence di costruire grandi repository di 0day non è solo di dubbia eticità, è semplicemente controproducente: nessuno può garantire che qualcun altro, che magari lavora per una potenza ostile, non abbia fatto le stesse scoperte e le stia utilizzando per colpire i cittadini che quella agenzia hanno finanziato. I soldi dei contribuenti sarebbero infinitamente meglio spesi se i bug venissero segnalati e corretti, in modo da incrementare la sicurezza di tutti. Questo approccio consentirebbe, tra l’altro, di “sottrarre l’arma al nemico”, o per lo meno di renderla assai meno affilata. Il vantaggio strategico dato da uno 0day nelle mani di un’agenzia è controbilanciato dal rischio che lo stesso bug venga sfruttato in massa contro tutti indiscriminatamente.

Una volta avvenuta la pubblicazione di questi tool, Microsoft ha rilasciato delle patch in tempi piuttosto celeri per correggere le falle che tali tool sfruttavano: la patch che correggeva la vulnerabilità sfruttata dal malware “WannaCrypt”, la MS17-010, è del 14 marzo scorso. Semmai è Shadowbrokers che ha rilasciato le vulnerabilità in modo irresponsabile: ma cos’altro ci si aspetta da un’organizzazione criminale?

Qui le cose si fanno un pochino più complicate rispetto ad una semplice divergenza di opinioni. Innanzitutto non c’è stato nessun “rilascio irresponsabile”: si dibatte infatti se addirittura si possa parlare di “rilascio orchestrato”, in quanto ciascuna delle vulnerabilità per Windows presenti nel dump degli ShadowBrokers aveva già pronta la sua bella patch. Le ultime in ordine temporale sono state rilasciate da Microsoft all’inizio di marzo e, coincidenza che di certo ha fatto sorridere qualcuno, almeno una patch è di padre ignoto (ovvero il bollettino non riporta chi ha segnalato il problema) [dump 14/4/2017, patch MS17-010 14/3/2017].

Io invece definirei “irresponsabile” l’uso che dell’exploit è stato probabilmente fatto dalle agenzie: EternalBlue, ad esempio, è capace, con qualche ritocchino, di exploitare Windows dalla versione XP fino alla 10, ovvero un range di tecnologie che variano dal 2001 al 2017. Da quanto tempo questa vulnerabilità era custodita nei cassetti della NSA? Quante volte e su chi è stata utilizzata? L’exploit è stato identificato da qualcuno dei colpiti e, magari, reingegnerizzato a partire da un PCAP? Non è dato saperlo.

Gli exploit hanno proprio questa particolarità: esattamente come successe con il famigerato MS08-067, una volta impiegati e divenuti noti, possono essere studiati, riciclati e trasformarsi da strumenti di precisione a disposizione delle agenzie a tre lettere (Stuxnet) a dispositivi per la pesca a strascico (Conficker). Suona familiare?

Piuttosto, si può accusare l’NSA di leggerezza nella custodia di questi strumenti. Questo è un discorso molto complesso e delicato, e non credo che tutti quelli che commentano in materia siano esperti di intelligence. È molto probabile che la compromissione sia avvenuta tramite l’utilizzo di contractors, di esterni; e sicuramente un problema serio di sicurezza interna l’NSA ce l’ha (leggere alla voce “Snowden”…). Ma chi accusa l’NSA per il worm non ha certo in mente di migliorare la sicurezza di tale agenzia, che probabilmente vede come il fumo negli occhi.

Io, come dice il professore, non sono un esperto di intelligence, tuttavia mi permetto di fare un paio di osservazioni anche qui: innanzitutto, come mai un’agenzia con dei compiti così delicati come l’NSA ha dei problemi così seri con i contractors? Tralasciando il caso Manning, che contractor non era, c’è sì Edward Snowden, ma anche Thomas Martin, e, non ultimo, il “potenziale contractor infedele” supposto da Berretti. Una risposta a questa domanda potrebbe arrivare, ad esempio, dai requisiti per entrare nell’NSA, sia come analista, sia come sistemista: «Applicants are required to complete a functional fitness test consisting of a 1.5-mile run, 300-meter sprint, pushups and situps.»

Non esattamente il metro di giudizio con cui valutare un informatico esperto, mi pare.

Molti altri vengono scartati per peccati di gioventù, o per aver fatto uso di sostanza “ricreative”. La soluzione? Ricorrere agli esterni, spesso gli inidonei di cui sopra, anche per compiti di manutenzione ordinaria dei sistemi (ovvero il compito originale di Snowden, che, come impiegato di Booz-Allen, ricopriva il ruolo di sysadmin).

A questo andrebbe aggiunto che, almeno per i file sottratti da Snowden, siamo a conoscenza del come è avvenuta l’esfiltrazione: e qui il problema diventa relativo alla sicurezza e alla segregazione di reti e sistemi, e non “all’intelligence”. Si ripropone quindi l’aspetto della raccolta delle professionalità di chi è assegnato alla progettazione, manutenzione e gestione di quelle reti e quei sistemi.

Io credo che il punto qui non sia il fumo, quanto piuttosto le spesse fette di prosciutto, più precisamente disposte sugli occhi di chi non vuol vedere il grande problema di policy che abbiamo davanti.

Chiuso questo aspetto, ci sarebbe da affrontare quello sociologico: mettendo sui piatti di una bilancia i “problemi seri” provocati dalle rivelazioni di Snowden da un lato e l’impatto sulla sicurezza e consapevolezza di tutti che dai suoi dossier sono derivati, in particolare riguardo al grado di penetrazione dell’NSA nei sistemi di tutte quelle multinazionali di cui tutti ci serviamo quotidianamente, da che parte penderebbe l’ago? Davvero consideriamo Snowden solo un “problema”?

Di stalle e di patch

(2) “Se le patch erano disponibibili fin da marzo, è colpa dei sistemisti delle organizzazioni colpite, che non hanno applicato tempestivamente tutte le patch”. In realtà è anche peggio: molti computer colpiti dal malware avevano Windows XP, che è fuori manutenzione da tre anni e che quindi non ha più (in realtà post factum Microsoft ha rilasciato una patch per MS17-010 anche per Windows XP, ma i buoi sono già scappati dalla stalla).

Cominciamo col mettere qualche punto fermo: secondo Kaspersky la percentuale di macchine infette con a bordo Windows XP è inferiore allo 0.02% (“statisticamente insignificante”).

Windows Versions Impact
Questo dato è dovuto semplicemente al fatto che l’implementazione dell’exploit non funziona a dovere sulle macchine con Windows XP. In realtà dai test sembra che l’exploit semplicemente riconosca le macchine XP SP3 come non vulnerabili, mentre riesca a generare un crash su quelle con SP2. In entrambi i casi, l’infezione non va a buon fine.

Microsoft ha, sua grazia, rilasciato una patch correttiva “out of bound”, dato che la vulnerabilità su XP è presente, ma il modulo di spreading di Wannacry non è in grado di approfittarne. Detto ciò, XP ha raggiunto la fine del periodo di supporto l’8 aprile 2014: se i buoi davvero sono scappati, vagano liberi ormai da almeno tre anni.

Può sembrare facile applicare le patch, far girare cioè “Windows Update”, una cosa da cinque minuti. Bene, a parte che nemmeno nel proprio computer di casa è una cosa da cinque minuti nella maggioranza dei casi (chi scrive ha tentato di aggiornare la propria macchina virtuale con Windows 7 ieri sera e dopo tre ore ancora tutte le patch non erano state installate), un conto è il contesto domestico, o quello di una piccola azienda, un conto è l’ambito corporate dove entrano in gioco tutta un’altra serie di questioni.

Anche qui, un minimo di chiarezza. Aggiornare Windows è difficile solo se si vuole che lo sia. Per quella che è la mia esperienza, sia come amministratore di reti sia come utente domestico, gli aggiornamenti di Windows, fatti con regolarità ogni mese, non portano via più di una manciata di minuti (fino ad un massimo di una mezz’ora sull’hardware più datato). Un’eccezione a questa regola sono i service pack, che però vengono rilasciati a lunghissimo tempo l’uno dall’altro (XP ne ha visti tre in 13 anni, Vista 2, Windows 7 uno solo).

Il discorso cambia se gli aggiornamenti vengono eseguiti sporadicamente: una macchina virtuale usata solo quattro/cinque volte l’anno e lasciata spenta per settimane può accumulare un ritardo notevole. Dato l’esempio aneddotico del professore, vi propongo i miei, da prendere con lo stesso grado di affidabilità: il portatile (un laptop HP di 4 anni fa con CPU Intel i5,  4GB di RAM e un disco SSD consumer) della mia compagna (non esattamente una sysadmin con esperienza decennale) ha impiegato 13 minuti per installare gli aggiornamenti del mese di maggio 2017 di Windows 7 (download di 224MB: 5′, installazione: 6′, reboot: 2′): non esattamente una tragedia. La mia virtual machine, dotata sempre di Windows 7 ma abbandonata per diverse settimane, ha impiegato circa 30 minuti per installare l’equivalente di tre mesi e mezzo di patch: anche qui, non mi sembra la fine del mondo. Come giustificare le oltre 3 ore sperimentate da Berretti? Semplice: la sua VM non vedeva un aggiornamento da almeno un anno, forse più, o magari mancava del SP1, rilasciato a metà 2010; in ogni caso non la si può considerare una condizione “media”, piuttosto come la situazione in cui ci si ritrova una tantum quando il S.O. è appena stato installato.

In ambito corporate è ovvio “cambia tutto“: lì è possibile pianificare gli update (ad esempio per eseguirli nottetempo), e poi sono a disposizione script di amministrazione, group policy, server WSUS… tutti strumenti che possono rendere la gestione degli aggiornamenti il meno invasiva possibile ed evitare situazioni spiacevoli (ad esempio sistemi che mancano delle patch rilasciate negli ultimi otto mesi e che poi impiegano tre ore a tornare disponibili).

Innanzitutto, sebbene tutti gli aggiornamenti di Windows siano testati e controllati da Microsoft prima di rilasciarli, come è ovvio, ci sono una quantità di problemi che possono manifestarsi in fase di installazione degli aggiornamenti, problemi che non si sono realizzati nella fase di testing presso Microsoft: non tutte le configurazioni possono essere testate, non tutte le condizioni d’uso. Provate a fare una ricerca su Google di “Windows Update breaks”: avrete una quantità di pagine web in cui si riporta come un aggiornamento ha compromesso la funzionalità di qualche applicazione, o anche dell’intero sistema. Chi utilizza Windows in apparecchiature mission-critical dunque ci pensa due volte prima di fare aggiornamenti e li controlla ancora nel suo contesto di lavoro specifico prima di farli. Esistono tonnellate di applicazioni, stand-alone o web based, utilizzate in ambito corporate che possono rompersi semplicemente aggiornando il browser web: e la colpa non è in questo caso di Microsoft, né dell’utente, ma di chi ha scritto l’applicazione.

Il problema degli aggiornamenti di Windows che “rompono” un applicativo è un problema molto sentito, ma spesso sopravvalutato o, peggio, utilizzato come scusante. Nelle realtà dove davvero questo problema esiste (che sono una minoranza, si badi bene), è necessario che siano messi in piedi dei processi specifici per testare le singole patch e quindi decidere, volta per volta, quali adottare e quali no. L’approccio per il quale non si installa nulla a prescindere è estremamente miope, dato che sacrifica la sicurezza delle postazioni di lavoro e dei server sull’altare di un problema che probabilmente non si manifesterà mai.

Restare indietro per qualche settimana rispetto ai rilasci mensili è comprensibile, abbandonare del tutto gli aggiornamenti no. Se poi prendiamo in esame il caso specifico, chi non ha installato l’aggiornamento MS17-010 ha sicuramente rischiato di essere infettato da Wannacry (o magari lo è stato, e i danni sono stati evidenti), mentre non ci sono prove che la fix a SMBv1 abbia causato disservizi.

La questione della fragilità di certo software applicativo è sicuramente una ferita aperta, ma non può essere risolta a scapito della sicurezza: piuttosto, si investa in professionalità in modo da creare software più moderno e premiare chi produce applicazioni più robuste (nel tempo e con gradualità, è chiaro, ma senza lassismi).

Il lavoro di ricontrollare ogni patch per verificare che non dia problemi nel contesto specifico non costa poco: non solo le ore di lavoro impegnate, ma anche la necessità di avere hardware “sacrificabile”, dei “muletti” sostanzialmente. Il problema diventa valutare se l’investimento in prevenzione del rischio informatico (che include procedure biecamente manageriali tipo appunto la gestione degli aggiornamenti) paghi: secondo chi scrive sì, eccome, ma mi pare chiaro che l’opinione degli esperti di informatica in generale e di sicurezza informatica in particolare sia un po’ biased, e comunque non bisogna convincere me ma il top management delle aziende.

E’ ovvio che la sicurezza costa, e non solo per i muletti: i bravi sistemisti sono merce rara, così come tante altre figure dell’IT che lavorano dietro le quinte. La questione dei costi della sicurezza è però un ostacolo (“non c’è budget!”) di origine squisitamente culturale. Una chiarissima esemplificazione di questo concetto l’ha fornita Andrea Zapparoli Manzoni su Radio24 qualche giorno fa: un terzo del prezzo di un’automobile nuova è dovuto alle dotazioni di sicurezza: ci siamo solo abituati all’idea che sia giusto e normale. Una volta accettata questa idea, le conseguenze che ne derivano sono quasi automatiche: nel privato come nel pubblico la sicurezza andrebbe regolamentata almeno in parte per legge, così come si fa ad esempio nei cantieri. La cosa si fa ancora più evidente nel caso dell’NHS: chi dovrebbe implementare e verificare le dotazioni di sicurezza di un servizio essenziale pagato dai cittadini se non l’amministrazione pubblica?

Ma è ancora peggio: le patch potrebbero non essere applicabili, o il sistema operativo, non più supportato come Windows XP oramai da anni, potrebbe non essere aggiornabile ad uno supportato.

La triste verità è che il 97% delle macchine colpite da Wannacry erano patchabili, e senza troppi patemi d’animo. XP come abbiamo visto non c’entra un fico secco.

Non abbiamo elementi certi, e l’applicazione del dubbio sistematico a qualunque informazione ci arrivi dalla stampa non aiuta a ricostruire la vicenda. Non sappiamo se le interruzioni di servizio clamorose (i cartelli nelle stazioni ferroviarie, i servizi ospedalieri, la fabbrica Dacia in Romania che si ferma: insomma non solo qualche desktop su una scrivania, facilmente aggiornabile con un minimo di perdita di tempo da parte dell’impiegato) siano dovuti esattamente e con precisione a cosa, a quale rete erano connessi, come e per quale ragione. Tutti elementi senza i quali una valutazione di dove stanno le responsabilità è impossibile.

Questo dubbio rispetto a cosa attribuire le  interruzioni di servizio, a mio parere, è assolutamente irrilevante: un incidente informatico che interessa un servizio pubblico o una infrastruttura critica resta comunque tale, Wannacry o non Wannacry. Le cause, i meccanismi e le possibili soluzioni restano, nella stragrande maggioranza dei casi, gli stessi: poche patch, applicate tardi e male, su una rete non partizionata a dovere; il tutto a causa di un budget per la sicurezza troppo corto o semplice mala gestio. Inoltre è un dato incontestabile che Wannacry abbia colpito indifferentemente tutto l’Occidente, Italia compresa, e in alcuni casi ci sono persino i report tecnici dettagliati dei diretti interessati (ad esempio quello di Telefonica). Buttarla in caciara sostenendo che è impossibile risalire alle responsabilità è inaccettabile.

wannacry infection heatmap

Possiamo però, per fare un esperimento mentale, immaginare qualche scenario.

Immaginiamo il caso di un macchinario per utilizzi medici in un ospedale (che so, una macchina per la risonanza magnetica: non ho idea di come funzionino, è solo un’ipotesi). Macchine che possono costare migliaia o decine di migliaia di euro. Immaginiamo che questa macchina abbia un sistema embedded basato su Windows XP, sistema che contiene ovviamente dei device driver custom scritti ad hoc per l’hardware in questione. La macchina potrebbe avere facilmente cinque, sei, sette anni: non è il genere di cose che si cambia così come un cellulare. La ditta che l’ha sviluppata potrebbe non esistere più, ad es. potrebbe essere stata assorbita da un’altra ditta che sviluppa una linea di macchine distinta e che non mantiene più la vecchia linea della società che ha acquisito – sto ovviamente inventando, ma lo scenario è plausibile. Cosa fa l’ospedale, butta via un macchinario perfettamente funzionante e ne compra un’altro nuovo di zecca perché il software on board ha una vulnerabilità che qualche criminale potrebbe divertirsi a sfruttare? Provatelo a spiegare al manager dell’ospedale e ne riparliamo. Questo scenario, en passant, rende anche nullo il discorso “facciamo girare XP in una macchina virtuale”: l’XP del sistema embedded ovviamente deve girare sul bare metal, come si suol dire.

Esperimento mentale inappuntabile (a parte il solito XP). Il problema dell’aggiornamento dei macchinari e dei device mission-critical dotati di S.O. embedded però, ha una soluzione: il fornitore deve essere obbligato, per legge, e specialmente per i dispositivi medici o essenziali, a manutenere il prodotto per tutto il suo ciclo di vita. D’altronde non ci si aspetta che invece, per quanto riguarda la meccanica degli stessi macchinari, “finiscano i ricambi” (tranne in casi limite, è ovvio). Questo tipo di supporto è già prassi nel privato in molti ambienti e per sistemi molto meno delicati: è ora che il pubblico si tuteli, almeno nei casi delle apparecchiature mediche o critiche.

Ovviamente quello descritto è uno scenario limite. Ma perfettamente plausibile, dettaglio più, dettaglio meno. Il supermercato dove faccio la spesa ha le casse che girano con Windows Embedded POS Edition 2009, basato su Windows XP, e la fotocopiatrice che ho in Dipartimento ha Windows Embedded come OS (non so che versione) ed è ovviamente collegata in rete.

Un ospedale non è un supermercato: i rischi andrebbero sempre valutati in base al contesto, in modo da stimare correttamente l’impatto di un eventuale attacco, altrimenti si rischia, pardon, di semplificare troppo.

Concedetemi infine una piccola nota polemica per tranquillizzare le cassiere del supermercato dove il professore fa la spesa: Windows Embedded POSReady 2009 è ancora sotto supporto e lo sarà fino ad aprile 2019.

Airgap all the things

(3) “Ma i manager dell’infrastruttura informatica avrebbero dovuto mettere tutti i sistemi vulnerabili in una rete separata, controllata, air gapped…”. Sì, probabilmente sarebbe stata una buona idea. Peccato che dal punto di vista pratico questo vuol dire modificare una infrastruttura di rete locale anche dal punto di vista fisico (o solo logico se utilizziamo VLAN e ci fidiamo). Non è gratis (né come costi di personale né come costi di materiale), non è necessariamente facile da fare, e non risolverebbe necessariamente il problema, come sanno gli iraniani dell’impianto di arricchimento dell’uranio di Natanz (sto alludendo alla vicenda del worm Stuxnet).

No, come abbiamo già visto, la sicurezza delle reti non è gratis, così come non sono gratuiti i test di staticità delle scuole. Le VLAN piuttosto, spesso vituperate, sono invece considerate ragionevolmente sicure da molti esperti, a patto, ovvio, di essere configurate con cognizione di causa e sono, in ogni caso, meglio di niente.

airgap meme

Per quanto riguarda l’utilizzo del cosiddetto air-gapping, preferisco pensare che il parallelismo che il professore propone con ciò che è successo a Natanz sia una battuta di spirito (una semplificazione, perfino): se il personale medico infila chiavette USB trovate in giro nelle apparecchiature mediche, allora il problema è molto più grande di quello che una architettura di rete possa risolvere.

Un ragionevole downtime

(4) “Ma questi non capiscono nulla, dovevano fare i backup!”. Ovviamente. Ma chi ci dice che i backup non esistono? Pensate ad un attacco di ransomware che mette fuori uso qualche centinaio di computer.

Facciamo un passo indietro: come si è detto, il 97% dei sistemi colpiti era patchabile, quindi si sarebbe dovuto partire da li. Una volta caduti nella trappola, però, il ripristino da backup pare effettivamente un’opzione adeguata. Pur sorvolando su tutti i luoghi comuni che ci sono sull’argomento (ma i backup vengono verificati? come? sono salvati su supporti differenti? c’è una seconda copia anche offline?), che diamo per scontato avere risposta positiva (!?), possiamo davvero affermare che i backup esistono? I 300 e passa riscatti pagati farebbero pensare il contrario, ma transeat; speriamo che gli spartani siano tutti utenti domestici.

Quanto ci vuole per (a) ripulire i sistemi dal malware (b) ripristinare i backup dei dati?

Effettivamente, ripristinare da un backup porta ad un certo downtime, che varia a seconda delle dimensioni dei dati da recuperare, dalle due memorie coinvolte e dal mezzo che le collega. E’ impossibile fare una stima senza dei riferimenti specifici, ma diamo per buona la previsione di Berretti:

Che nel mondo reale ci sia un periodo che può passare da qualche ora a qualche giorno di down mi sembra ragionevole.

Ma è davvero ragionevole un downtime (da qualche ora a qualche giorno) di un ospedale? E di una centrale elettrica? E di una diga? E di un sistema di controllo del traffico aereo? E’ ragionevole che accada per le ragioni che abbiamo visto, ovvero perché la coperta è corta e gli aggiornamenti “sono lenti da installare”?

uptime meme

Più pinguino per tutti

(5) “Basta con Windows! Passiamo tutti a Linux!”. Bene, chi scrive utilizza praticamente solo Linux ed è un fervente sostenitore dell’open source, quindi questo discorso, perlomeno con me, sfonda una porta aperta. Il problema è che non la deve sfondare con me ma con i responsabili IT di una quantità di aziende medio-grandi che hanno svariate buone ragioni per non seguire questo consiglio – purtroppo, aggiungo io.

Innanzitutto, vi sfido a (a) implementare tutto quello che si può fare su una rete Microsoft fatta bene (Active Directory etc.) utilizzando Linux (b) avere su tutta la baracca manutenzione, assistenza, e così via. Quando ci sarà una soluzione di questo tipo efficace, economica e mantenuta ne riparliamo. Ovviamente auspico questa soluzione, ed è possibile che questi eventi spingano in questa direzione: semplicemente ancora non ci siamo. Sono anche convinto che “più embedded Linux e meno embedded Windows” sia una cosa molto positiva – e che ha maggiori probabilità di realizzarsi: Linux ha molto successo nei sistemi embedded. Staremo a vedere.

non c'avevo pensato

Anche qui, tutto vero e sacrosanto. Eccetto che… ma è vero che l’uso di sistemi open source non ci espone almeno ad una parte degli stessi rischi? Si, un S.O. embedded basato su Linux ha più speranze di essere aggiornato, ma non per questo ne abbiamo la certezza. Quante IPcam linux based vulnerabili ci sono in giro? E i router? E i DVR? Quanti dispositivi simil-IoT come questi sono stati abbandonati dai loro produttori? Mirai, anyone? (Non voglio neanche entrare in quel vespaio che sono gli aggiornamenti nell’ecosistema Android, per carità).

Anche sui sistemi Linux-based sarebbe necessario emanare leggi che costringano i produttori a integrare la sicurezza direttamente a livello progettuale e a garantire gli aggiornamenti per un periodo di tempo congruo. C’è addirittura chi propone (i soliti semplicisti) di far pagare sanzioni ai produttori i cui dispositivi, poiché insicuri, siano usati per causare danni a terzi.

Inoltre, bisogna tenere conto della situazione di partenza: una migrazione da Windows a Linux a fronte di risparmi ha anche dei costi (come minimo di training degli utenti). Li vogliamo mettere in conto?

E un minimo di training sulla sicurezza invece? Ah già, non c’è budget.

Infine, per quanto io possa preferire software open anche dal punto di vista della sicurezza, chi ci dice che dal momento in cui Linux non diventa un target di alto profilo in termini di utilizzo non si manifestino vulnerabilità altrettanto gravi di quelle che troviamo in Windows? Anche Linux – kernel, sistema operativo ed applicazioni, l’intero ecosistema – è software scritto da umani che commettono errori esattamente come quelli che scrivono software per Windows.

Non sa quanto ha ragione, professore. Anzi, non è nemmeno necessario aspettare l’ascesa di Linux su desktop. Infatti, a una settimana dal suo pezzo, ecco comparire quella che qualcuno ha definito la “versione Linux” (mi perdonerà la semplificazione) di EternalBlue, praticamente il cacio sui maccheroni.

Soluzioni dal basso

Chiudo questo già lunghissimo e tediosissimo articolo con le conclusioni, mie e del professor Berretti.

Ci troviamo quindi in una situazione complessa. Non sto ovviamente sostenendo che non esistano soluzioni, ma che le soluzioni saranno sicuramente parziali e incrementali, e soprattutto verranno “dal basso”, diverse in contesti e settori diversi. Certamente occorre attenzione a scrivere applicazioni (sia stand-alone che web-app) che siano robuste rispetto agli aggiornamenti dell’OS.

Le soluzioni dal basso le abbiamo attese per quasi dieci anni e non si sono palesate. In un mondo che evolve ad una velocità ingestibile e dove i prodotti acquistati un anno fa sono già “fuori supporto”, il mercato ha fallito nell’obiettivo di rendere la sicurezza una killer-feature. I produttori non vogliono sostenere i costi derivanti dalla progettazione sicura e dalla manutenzione, i consumatori vogliono prodotti economici (“che tanto se si impalla lo ricompro”) e app gratuite. E’ una forma di inquinamento, un lento avvelenamento collettivo, che ha mostrato i suoi effetti, per l’ennesima volta, assumendo i connotati di Wannacry ed EternalBlue.

Certamente è necessario che le grandi organizzazioni diano alla sicurezza informatica il ruolo che giustamente gli compete anche in termini di budget. Certamente chi sviluppa sistemi embedded deve progettarli pensando alla loro aggiornabilità come elemento essenziale e chi li acquista deve prevedere e pianificare i loro aggiornamenti.

I contratti di fornitura di servizi software o device embedded vanno dotati per legge di clausole che prevedano la sicurezza sin dal design, la manutenzione e il supporto; mentre sanzioni vanno previste per chi non soddisfa tali specifiche.

La questione del budget, in materia di sicurezza, deve sparire dalla cartine geografiche: solo in Italia, nel 2016 si stima una spesa di 66 miliardi di euro per l’acquisto di beni e servizi legati all’IT, mentre solo 950 milioni sono stati spesi in security (per proteggere i 66 miliardi di cui sopra), ovvero l’1,5% [rapporto CLUSIT 2017, pagina 12]. Se si pensa quanta parte del PIL è abilitata da quei 66 miliardi, chi dice che la coperta per la security è corta “perché non c’è budget” dovrebbe semplicemente evaporare per l’imbarazzo.

Certamente occorre riconoscere la complessità come il maggiore nemico della sicurezza nello sviluppo del software e regolarsi di conseguenza. Ma non sono cose che si risolvono in pochi giorni. Nel frattempo, non resta che aggiornare i sistemi Windows e bloccare sul firewall le porte 139 e 445.

Il professore non me ne vorrà se faccio notare che questa mi sembra una soluzione semplicistica ad un problema complesso, ma spero che, arrivati sin qui, sia chiaro che non è con Berretti che cerco la polemica.

Magari però, se si iniziassero a diffondere determinate idee, spiegandole al pubblico, invece che additare “le sciocchezze degli esperti”, forse, piano piano, evolveremo abbastanza da superare questa empasse culturale e inizieremo a considerare la security come un requisito minimo e non come un fastidio di cui liberarsi il più velocemente possibile. Oppure possiamo arrenderci all’idea che i nostri ospedali siano alla mercé della Corea del Nord (o dei ragazzini con la felpa, va bene uguale).

Kim Jong-Un Troll