WannaCry? No, grazie…
La notizia è fresca ma non più attuale, tende a scomparire dai notiziari e lascia la maggior parte degli interessati con il desiderio impellente di saperne di più, di capire cosa si nasconda realmente dietro al sedicente “attacco al cuore di Internet”. E magari desidera apprendere in che modo evitare che simili avvenimenti accadano di nuovo.
Perché è accaduto? Chi è suscettibile di infezione? Di chi è la colpa? Chi o cosa si nasconde dietro questo “attacco”? E’ possibile prevedere simili azioni in futuro? A chi giova un simile stato di cose? Queste (e molte altre) le domande che serpeggiano tuttora irrisolte tra gli utenti di computer, domande alle quali nessuno ancora ha saputo dare una risposta univoca.
Conscio di una simile colpevole negligenza negli organi di pubblica informazione, mi accingo umilmente a condividere i miei dati e le mie conoscenze al riguardo, sperando di fare cosa gradita.
Ransomware: un nome, un programma
Ransomware è un neologismo (un tecnicismo, ad essere pignoli) composto dai termini inglesi ransom, riscatto, e ware, merce, e per estensione suffisso utilizzato per indicare qualcosa che abbia a che fare con un computer (software, hardware, firmware e così via).
Nel caso specifico, ci troviamo davanti ad un programma che attua le azioni seguenti: blocco del computer, cifratura dei file, richiesta di un riscatto per riottenere l’usabilità dei file.
Programmi simili sono stati già isolati ed analizzati in passato.
Popolare inizialmente in Russia, l’utilizzo di ransomware è in seguito cresciuto a livello internazionale: già nel giugno 2013 la software house McAfee ha reso pubblici i dati i cui veniva mostrato come nel primo quarto del 2013 ne fossero stati isolati 250.000 diversi esemplari, più del doppio del primo quarto dell’anno precedente. L’utilizzo di programmi trojan (programmi che forniscono accesso indiretto ad un computer, come un cavallo di troia) consentirono attacchi di larga diffusione con ransomware basati su cifratura come Cryptolocker, che ha provocato perdite stimate in 3 milioni di dollari prima di essere bloccato dalle autorità, e CryptoWall, che secondo l’FBI è costato 18 milioni di dollari in danni sino a giugno 2015.
Breve storia di WannaCry(pt)
Di seguito la trascrizione delle tappe fondamentali dello sviluppo del ransomware in oggetto, così come sono state descritte nello splendido articolo “WannaCry about Business Models” di Ben Thompson, presentato al link https://stratechery.com/2017/wannacry-and-the-power-of-business-models/ .
Il Presidente della Microsoft e capo degli affari legali Brad Smith non sminuisce il problema sul The Microsoft Blog (“WannaCrypt” è un nome alternativo per WannaCry”):
“Starting first in the United Kingdom and Spain, the malicious “WannaCrypt” software quickly spread globally, blocking customers from their data unless they paid a ransom using Bitcoin. The WannaCrypt exploits used in the attack were drawn from the exploits stolen from the National Security Agency, or NSA, in the United States. That theft was publicly reported earlier this year. A month prior, on March 14, Microsoft had released a security update to patch this vulnerability and protect our customers. While this protected newer Windows systems and computers that had enabled Windows Update to apply this latest update, many computers remained unpatched globally. As a result, hospitals, businesses, governments, and computers at homes were affected.”
In breve, Thompson riassume in questo modo le date che caratterizzano lo sviluppo della situazione critica:
- 2001: Il bug in questione viene introdotto involontariamente in Windows XP, e da esso si diffonde in tutte le release successive
- 2001–2015: Ad un dato momento NSA (probabilmente l’ Equation Group, presumibilmente una sezione di NSA) ha scoperto il bug ed ha predisposto un exploit (programma che ne consente l’utilizzo malevolo) chiamato EternalBlue, che potrebbe o potrebbe non aver utilizzato
- 2012–2015: Un contraente NSA ruba presumibilmente più del 75% della libreria NSA’s di strumenti di hacking
- Agosto 2016: Un gruppo chiamato “ShadowBrokers” pubblica strumenti di hacking che dichiarano essere di provenienza NSA; gli strumenti sembrano giungere dall’Equation Group
- Ottobre 2016: Il contraente NSA di cui sopra viene accusato di aver rubato dati di proprietà NSA
- Gennaio 2017: ShadowBrokers mettono in vendita un buon numero di strumenti per l’attacco a sistemi Windows, tra questi un exploit zero-day SMB simile ad “EternalBlue” utilizzato in WannaCry per 250 BTC (intorno ai $225.000 di allora)
- Marzo 2017: Microsoft, senza fanfara, corregge una serie di bugs evitando di specificare chi li abbia scoperti; tra questi l’exploit EternalBlue; sembra alquanto probabile che la stessa NSA li abbia avvertiti
- Aprile 2017: ShadowBrokers rilasciano una nuova serie di exploits, compreso EternalBlue, probabilmente perché la Microsoft li aveva già corretti, riducendo in tal modo drasticamente il valore degli zero-day exploits in particolare
- Maggio 2017: WannaCry, basato sull’exploit EternalBlue, viene rilasciato e si diffonde su circa 200.000 computer prima che il suo kill-switch (un sistema per “spegnerlo” online) venga inavvertitamente attivato da un ricercatore ventiduenne; nuove versioni di WannaCry, prive del kill-switch sono già state segnalate
Under the hood: il funzionamento
Il ransomware sfrutta un buco nella sicurezza di Windows, connesso con il sottosistema SMB.
La nostra fida Wikipedia ci spiega che “Nelle reti di computer, Server Message Block (SMB), una versione del quale è nota come Common Internet File System (CIFS, /ˈsɪfs/), opera come un protocollo di rete di livello applicativo utilizzato soprattutto per condividere l’accesso a file, stampanti, porte seriali ed altre comunicazioni generiche tra i nodi di una rete.”
In parole più “umane”, è un programma che consente di “vedere” file e periferiche posti su di un altro computer in rete. Ovviamente tale protocollo non è unico (Unix ne utilizza spesso uno differente, e per tale ragione risulta praticamente immune a WannaCry). Sfruttando un errore di implementazione del protocollo, è possibile inserire sul computer in rete un programma in grado di agire come una spia (trojan) e rilasciare un carico (payload) nocivo che cifra i file contenuti nella macchina e chiede un riscatto. Decifrare il file risulta praticamente impossibile (e comunque in genere più dispendioso, in funzione di tempo macchina e risorse richieste, del pagamento del riscatto).
Un attacco in piena regola?
Si è parlato ovunque di “attacco massiccio sferrato nei confronti del sistema ospedaliero inglese”, di “sistema di comunicazione spagnolo messo in ginocchio” e via discorrendo. Dimenticando un paio di nozioni fondamentali di tattica: ogni attacco viene contraddistinto da un target nemico e da una mission da compiere.
Nel nostro caso (ma lo stesso può dirsi del fenomeno scatenato da mirai, il malware diffusosi nella Internet of Things sulla costa occidentale degli USA qualche mese fa) non abbiamo nessuna delle due caratteristiche: non c’è un target specifico (vengono attaccati tutti i computer con sistema operativo Microsoft Windows privi della specifica patch correttiva distribuita da Microsoft nello scorso Marzo) né una mission specifica (del tipo: mettere fuori uso le centrali di controllo elettrico, disabilitare il sistema di riconsocimento aereo). Quindi, strategicamente, non si è trattato di un attacco.
Alcune voci si sono immediatamente levate ad indicare la somiglianza del codice decompilato con altre “firme” note: si è detto che era stata riconosciuta la traccia della Corea del Nord, della Russia, della Siria, si è persino affermato che si si trattato di una mossa di tattica politica con la quale la NSA abbia tentato di sensibilizzare le agenzie di sicurezza nazionale a metodologie maggiormente cotnrollate ed a protocolli di sicurezza più stringenti. Ho potuto analizzare superficialmente il sorgente in oggetto, e da quel che ho visto non sussiste alcuna prova che possa avvalorare simili affermazioni; di certo partedel codice appare “clonata” da altri ransomware, ed è ovvio, dal momento che si tratta di programmi che agiscono allo stesso modo sui medesimi target.
Cui prodest?
I laboratori NSA (National Security Agency) hanno come mission la protezione della Sicurezza Nazionale, ad ogni costo: per tale ragione in molti (perlopiù complottisti) si sono scagliati contro l’Agenzia-che-non-esiste incolpandola del problema. In realtà la mission dell’agenzia consiste (tra le altre cose) nell’analisi del software alla ricerca di possibili falle nella sicurezza, e nella creazione di exploits, programmi che ne sfruttano le debolezze, per giocare digitalmente d’anticipo nei confronti di hacker in tutto il mondo. L’unica vera colpa di NSA è stata quella di non aver saputo impedire il furto di materiale sensibile.
Microsoft gestisce un codice elefantiaco, sviluppando moduli diversi in uffici diversi, ed evitare la creazione involontaria di falle nel sistema risulta praticamente impossibile. Non appena venuto a conoscenza della debolezza, il gigante di Redmond ha prontamente rilasciato un software correttivo, quasi due mesi prima dello scatenarsi dell’infezione digitale.
Gli avversari di Microsoft non sembrano coivolti nell’attacco a Windows: Apple ha avuto i suoi problemi con FBI per l’utilizzo di un sistema di cifratura inattaccabile, è maggiormente interessata allo sviluppo di apparati mobile ed utilizza un protocollo di condivisione delle risorse quasi proprietario; Linux (in qualsiasi distribuzione lo si voglia utilizzare) offre un sistema operativo gratuito ed auto-aggiornantesi, il software è visibile a chiunque e viene costantemente patchato da specialisti. Offrendo a pagamento eventualmente solo un service di configurazione, non ha nulla su cui competere con Microsoft, e nulla da guadagnare da una sua debacle.
Gli ShadowBrokers, che hanno rilasciato il ransomware, hanno guadagnato intorno ai 30.000 dollari in tutto dai “riscatti” (dati acquisiti tenendo sotto controllo i movimenti in bitcoins), praticamente nulla in confronto al mercato virtualmente accessibile.
Ma allora, chi è stato a trarre giovamento da questo sedicente “attacco”?
Apparentemente nessuno, e questa considerazione distrugge definitivamente il concetto di “attacco informatico”, trasformandolo in “pasticcio informatico”. Vediamo per quale ragione.
Il duro lavoro del Security Manager
Come abbiamo visto, non appena l’agenzia nazionale per la sicurezza ha realizzato di aver perso il codice faticosamente estrapolato in anni di studi, e con esso una notevole dose di capacità di controllo e previsione degli attacchi informatici, ha verosimilmente avvertito Microsoft del rischio connesso a tale perdita.
Microsoft, dal canto suo, ha immediatamente provveduto a riconsocere e correggere quei bachi del proprio sistema così esposti ad un exploit esterno: nel mese di Marzo 2017 rilascia la Windows patch MS17–010, un service pack di sicurezza indicato come indispensabile nella lista degli aggiornamenti consigliati. Con tale manutenzione correttiva vengono affrontati e risolti diversi problemi legati alla sicurezza e all’instabilità del sistema.
Cosa significa questo, per un’azienda che lavora nel ramo dell’Information Technology? E’ molto semplice: quando appare una segnalazione del genere da parte di Microsoft, il responsabile della sicurezza informatica ha l’obbligo di porre al primo posto nelle azioni da intraprendere sul sistema un backup completo dei dati e l’installazione del nuovo software, “scalando” a priorità inferiori tutti gli altri interventi programmati (ciò significa che aggiornamenti hardware, software applicativo, aggiornamento di licenze, allineamento di versione-release, audit del parco installato, manutenzione applicativa dei server, estensione del parco installato e qualsiasi altra attività prevista deve essere posticipata).
Immediatamente ha qui il significato di “appena possibile”, un tempo compreso tra poche ore e (al massimo) un paio di giorni, pena un possibile attacco informatico: quando un aggiornamento di sicurezza viene rilasciato, infatti, vengono indicate su di una lista pubblica tutte le falle ed i bachi di sicurezza che tale aggiornamento corregge; chiunque abbia le capacità tecniche e la malizia necessaria per interpretare le correzioni sarà quindi in grado di creare un codice malevolo in grado di sfruttare le falle a proprio vantaggio prima che esse vengano chiuse. Di qui l’urgenza estrema nell’applicare le security patches.
Tale urgenza non è però stata ravvisata negli oltre 100.000 casi di infezione verificatisi nel mondo. Vediamo perché.
L’insostenibile leggerezza dell’essere
Le ragioni del disastro sono da imputarsi alla mancata manutenzione correttiva dei server. Come abbiamo visto, l’attacco ha sfruttato una debolezza del protocollo di condivisione delle risorse, oggettivamente al centro di ogni sistema di controllo di rete, sia essa locale, estesa o metropolitana. Ma per quale motivo gli amministratori di rete dei sistemi colpiti non hanno ravvisato, in due mesi, la necessità di installare l’aggiornamento di sicurezza?
Gli aggiornamenti sono lenti e penosi
Installare una patch di sicurezza su un computer, o a maggior ragione su un server o un cluster, è una questione delicata, occorre eseguire una serie di operazioni sia prima che dopo l’installazione: backup del sistema, sostituzione del server con una macchina temporanea, messa offline (fuori rete) della macchina da aggiornare, pulizia dei file obsoleti e deframmentazione (quando ciò non sia stato predisposto automaticamente da un sysadmin scrupoloso), installazione della patch (può richiedere ore a seconda del sistema), controllo della correttezza dell’operazione, eventuale rollback in caso di completamento errato della procedura, controllo (e correzione!) delle ragioni per le quali l’installazione non è andata a buon fine, reinstallazione della patch, nuovo controllo sulle funzionalità aggiunte. A questo punto il manager scrupoloso controlla che i bachi corretti dall’aggiornamento siano effettivamente stati chiusi, lanciando una serie di attacchi software da una propria rete di test isolata, quindi controlla la macchina su di una rete di correzione per verificare che il computer funzioni ancora come prima, e che gli aggiornamenti non abbiano avuto una cattiva influenza sul software applicativo preinstallato: se tutto fiunziona per il meglio, si riaggiunge il computer alla rete, si ricontrollano gli indirizzi IP, i permessi, il profilo nel Directory Server, l’audit sugli aggiornamenti installati, gli instradamenti dei router, la configurazione del firewall, il passaggio attraverso IDS/IPS (sistemi anti-intrusione, se presenti), la raggiungibilità esterna, la funzionalità delle applicazioni, e infine si prepara una relazione scritta sulle attività svolte, relazione che avrà il significato di “missione compiuta” fornendo l’autorizzazione all’uso del computer con la nuova patch di sicurezza.
Microsoft ce l’ha su con me…
Come è facile intendere, la gestione di un aggiornamento per la sicurezza non è una classica passeggiata di salute. A tutto questo si aggiunga che la manutenzione degli aggiornamenti Microsoft non è lineare: i nomi delle patches sono criptici, la descrizione degli aggiornamenti in esse contenuti è spesso oscura, è necessario mantenere una lista di (in)compatibilità software (vedremo più avanti cosa ciò significhi), sovente per installare un dato aggiornamento è necessario avere già installato altri aggiornamenti in precedenza ai quali quest’ultimo fa riferimento nel codice. Inoltre quando per una qualsiasi ragione un aggiornamento finisce in modo errato, l’unica possibilità di decodifica dell’errore appare in una finestra di dialogo, e risulta essere un codice alfanumerico ed una stringa descrittiva generica che spesso rimanda alla “Knowledge Base”, una sorta di enciclopedia dei sistemi operativi Microsoft ove è spiegato tutto in dermini dettagliatissimi e spesso incomprensibili. Altrimenti è necessario contattare il centro di assistenza Microsoft.
Il centro di assistenza Microsoft (ma tutte le multinazionali del Software si comportano allo stesso modo) merita un paragrafo a parte. Una volta superata la barriera telefonica, l’addetto chiede il numero di licenza del sistema operativo relativo al computer su cui intervenire; già a questo punto iniziano i problemi, dal momento che in realtà industriali medio-grandi si possono trovare centinaia di computer: in tali casi spesso si ricorre ad un numero di licenza globale per l’Azienda, che copre 100, 500, 1000 macchine. Tale numero viene in genere conservato nella cassaforte dell’Economo Capo, che invariabilmente il giorno in cui vi occorre il numero di licenza si trova in ferie. In seconda battuta si ricorre al Responsabile del Magazzino, che vi fornirà il numero agognato: ovviamente errato, con conseguente diniego di servizio del Centro Microsoft. Ottenuto infine il numero corretto, dopo aver richiesto, minacciato, pregato, ricattato di volta in volta, il vostro superiore, il responsabile del laboratorio di test, il vostro compagno di corso all’Università, che ora lavora in Microsoft, l’operatore di sala macchine o contact center che procede alle installazioni e via discorrendo, vi sedete davanti ad un caffè doppio, con la tastiera ed il telefono a portata di mano, e vi accingete a richiamare Microsoft. Che dopo (almeno) un paio d’ore trascorse in amorevole scambio di opinioni (“Cosa c’entra Oracle con la patch?”, “Si, la KB372934–0987.21 è già installata!”, “No, non è un computer stand-alone, la patch devo installare per proteggere l’azienda!”, “No, non conosco Giorgio Rossi!” “Sì, è con me che dovete parlare!”) vi offrirà una soluzione quasi perfetta per risolvere il vostro problema.
Controllo del sistema operativo
Come tutti i prodotti da banco, anche i sistemi operativi hanno una loro scadenza. La scadenza di un sistema operativo dipende da diversi fattori: l’obsolescenza del sistema, il livello di supporto della casa madre, il numero di matricola o codice operativo.
Obsolescenza. Un sistema operativo diviene obsolescente quando non risponde più ai requisiti minimi richiesti dall’ambiente di sviluppo o applicativo; ad esempio, un sistema privo di protocollo TCP/IP come Windows 3.1 è inutilizzabile oggi. Allo stesso modo un sistema sviluppato per operare in modalità monotask reale a 16 bit (senza quindi la possibilità di utilizzare threads, multitasking, programmazione parallela, distribuita o concorrente) non è utilizzabile in ambienti attuali (tranne che rari casi di utilizzo nei sistemi embedded di cui, però, non ci occupiamo in questa sede).
Livello di supporto. Può capitare che un’azienda di sviluppo del software produca diverse versioni di sistema operativo: le diverse versioni vengono offerte per ambienti diversi (32 e 64 bit), diverse famiglie di processori (Intel, AMD, Atom, ARM), diversi tagli (Home, Pro, Server, Enterprise), creando una serie quasi infinita di flavours. A ciò si aggiunga che, per questioni di marketing, spesso a scadenze fisse viene offerto un sistema con una nuova veste grafica e nuovi gadgets, ovviamente con un nome diverso.
Oltre che per invogliare nuovi acquirenti, le nuove versioni sono distribuite per garantire che l’utente medio abbia un sistema il più possibile aggiornato: abbiamo visto in precedenza che gli aggiornamenti di sistema producono spesso emicranie ai possessori di computer, e vengono per tal motivo talvolta “evitati”; installando un sistema nuovo, l’utente pigro installa in tal modo anche tutti gli aggiornamenti della versione precedente in un colpo solo.
Quando però aggiornamenti, versioni, releases, flavours diventano troppi da gestire e mantenere, la Software House decide di cessare il supporto di alcuni, e di ritirare i più vecchi. Cessare il supporto significa smettere di distribuire aggiornamenti correttivi e di sicurezza, sconsigliandone quindi l’utlizzo, mentre ritirare indica che il prodotto non dovrebbe più essere utilizzato a prescindere.
Scadenza del codice operativo. Ogni sistema operativo ha un numero di licenza per l’utilizzo; tale codice viene inserito nel proprio computer per “sbloccare” una serie di garanzie tra le quali l’utilizzo dell’help desk Microsoft, del servizio di aggiornamento gratuito e così via.
Purtroppo è sovente accaduto che utenti smaliziati e poco etici abbiano distribuito su Internet liste interminabili di numeri di licenza, in parte trafugati dai posti di lavoro, in parte “ricreati” clonando l’algoritmo utilizzato da Microsoft. Dal momento che ciascun computer durante l’attivazione “telefona a casa”, contattando il sito Microsoft, talvolta si verifica l’increscioso incidente di vedersi rifiutare il servizio a causa di un numero di matricola errato, in quanto già assegnato ad altro PC. Il codice operativo in tal caso risulta scaduto.
Qualcosa di simile accade con le licenze aziendali. Si acquistano 100 licenze, si installano 70 computer, si “spengono” 50 dei computer installati, si installano altri 70 computer, per un ttale di 140 computer per 100 licenze. Ovviamente tale sistema non funziona, e non appena il 101mo computer viene rimesso in rete, scatta il messaggio di errore. Ma senza voler necessariamente agire in modo non etico, può sicuramente capitare a chi gestisce un parco di 1000 computer, di fare confusione con le licenze, ed assegnarne qualcuna in più “per dimenticanza”. Purtroppo (o per fortuna), quando questi casi diventano troppo numerosi, specie per le licenze più vecchie, i codici vengono annullati, e la Software House propone una offerta di upgrade che l’Azienda “non può rifiutare”.
Dio (o il produttore del SW applicativo) lo vuole!
Il software applicativo dovrebbe essere indifferente al sistema sul quale si trova a funzionare: un programma di gestione per paghe e contributi dovrebbe funzionare all stesso modo su Unix, MAC, Windows XP o Windows 8.1. Purtroppo però la realtà è diversa.
La ragione di questa diversità è duplice: SW applicativo legato al sistema operativo e sistema operativo incompatibile con le versioni precedenti.
SW applicativo legato al sistema operativo. Scrivere software è semplicissimo. Scrivere software che funzioni è difficile. Scrivere software che funzioni bene è dannatamente arduo. In un periodo legato mani e piedi alla programmazione ad oggetti, il concetto di astrazione è sovente il più trascurato: è semplice scrivere un programma utilizzando funzioni di libreria precompilate, senza rendersi conto se e quanto tali funzioni dipendono da chiamate al sistema operativo inferiore. Quando il sistema operativo cambia, e alcune funzioni vengono modificate o abbandonate, il programma applicativo semplicemente cessa di funzionare. In questi casi il responsabile IT ha tre possibili strade da percorrere: a) Richiamare il progettista del software applicativo e facendo leva sulla corretta lettura delle specifiche di progettto obbligarlo a fornire una nuova versione funzionante, invocando una manutenzione correttiva, pena lo scatto delle clausole penali del contratto; b) Richiamare il progettista del software applicativo e pregarlo di eseguire una manutenzione evolutiva dietro pagamento di lauto compenso, per consentire all’azienda di continuare a lavorare; c) Tornare al vecchio sistema operativo e fingere che non sia successo nulla.
E’ evidente che la soluzione c) è quella che ha favorito l’attacco informatico.
Sistema operativo incompatibile con le versioni precedenti. Talvolta l’aggiornamento di un sistema operativo richiede risorse hardware non indifferenti a causa delle aggiunte e dei nuovi controlli effettuati con la modifica, in misura tale da obbligare all’acquisto di una macchina più nuova e performante, pena il deterioramento delle performances e in ultima analisi delle prestazioni lavorative. E’ altresì possibile che l’aggiornamento modifichi completamente alcune sezioni del core (il nucleo più interno del sistema), rendendolo incompatibile con le versioni precedenti e obbligando quindi al’update di tutte le macchine in contatto con la nuova in seguito all’aggiornamento.
Risultato netto: in tutti i casi esaminati in precedenza, ci si trova di fronte al dilemma se l’aggiornamento sia più o meno dannoso del mantenimento dello stato attuale. L’ovvia risposta, in mancanza di attacco informatico, è “Ma sì, tanto cosa vuoi che accada? E poi, su milioni di server installati, deve capitare qualcosa proprio a noi?”.
Occorre a questo punto spezzare una lancia a favore di Microsoft. Nonostante, infatti, Windows XP non fosse più supportato da Microsoft, la software house di Redmond ha predisposto e distribuito su Internet un aggiornamento correttivo anche per Windows XP. Sono ora evidenti le ragioni per le quali ancora tanti computer avessero XP installato nonostante la mancanza di supporto della casa madre, ed è giusto comunque riconoscere che il comportamento di Microsoft abbia impedito che il risultato dell’attacco informatico fosse ben più pesante.
E’ possibile prevedere simili azioni in futuro?
No. Un sistema operativo è un software eccezionalmente complesso, sviluppato in team da diversi programmatori, e nonostante i test di regressione effettuati, è sempre possibile che un baco s’intrufoli nel codice.
E’ tuttavia possibile (e necessario, aggiungerei) gestire la sicurezza informatica aziendale in modo meno “artigianale”, seguendo politiche, procedure e processi di sicurezza stabiliti e inderogabili. Come abbiamo visto, attività apparentemente innocue come la scelta di un software applicativo, di un contraente, di un sistema operativo o di sviluppo, dei tempi di aggiornamento, del team di controllo possono avere pesantissime ricadute sulla sicurezza aziendale: lavorare con la testa sulle spalle significa anche saper prevedere brecce nella politica e nel comportamento aziendale, ed avere la forza di opporvicisi.
Vorrei qui aggiungere e far notare come non sia un caso che gli ultimi episodi di aggressione informatica internazionale siano tutti dovuti a malcostume nella gestione della sicurezza personale e aziendale. Molti utenti hanno forse imparato a non cliccare su tutto ciò che si muove o arriva nella propria casella postale, alcuni stanno imparando ad utilizzare password più robuste o passphrases semplici da ricordare (“laAmaiuscola!1” è una password piuttosto forte e semplice da ricordare e da cambiare senza modificarne la struttura, ad esempio, si veda http://www.passwordmeter.com/ ). Ora è il caso che i dirigenti d’azienda smettano di richiedere “specialisti della sicurezza” alle cooperative, o di pescarli tra i neolaureati senza esperienza e i programmatori web.
WannaCry? No, grazie, preferisco sorridere. Posso permettermelo. E voi?
