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. Vediamo di che si tratta.
(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. 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?
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.
(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).
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.
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 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.
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.
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. 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.
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.
(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).
(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. Quanti ci vuole per (a) ripulire i sistemi dal malware (b) ripristinare i backup dei dati? Che nel mondo reale ci sia un periodo che può passare da qualche ora a qualche giorno di down mi sembra ragionevole.
(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.
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?
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.
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. 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. 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.
