I bug dei signori del silicio che pagheremo noi

Qualys, 4 previsioni di sicurezza per il 2022

Focus sulla sicurezza by design e progettazione delle CPU. L’affaire Meltdown/Spectre scuote sin dalle fondamenta un certo modo di intendere la sicurezza IT. Allo stesso tempo illustra perfettamente l’importanza di far luce sulle implicazioni di questa falla strutturale con costi extra in vista per le aziende

Gli incidenti di sicurezza, che si sono succeduti negli ultimi due anni senza soluzione di continuità, hanno delineato lo scenario cyber dei prossimi anni. C’è stato WannaCry e la piaga del ransomware. Ci sono stati Petya e Mirai. La vicenda Yahoo! e la voragine Equifax. Il colpo da 81 milioni di dollari alla Banca Centrale del Bangladesh, sfruttando una vulnerabilità del sistema Swift; il leak al Comitato Elettorale del Partito Democratico USA; l’attacco a DYN, uno dei più importanti provider DNS della costa orientale USA. E ancora prima, i 20mila clienti della britannica Tesco Bank, derubati del loro denaro da una banda di cybercriminali. Senza dimenticare, l’attacco alla Farnesina, la vicenda Hacking Team oppure l’attacco alla rete elettrica ucraina. Attacchi informatici su scala globale che hanno messo a nudo i rischi di sicurezza per cittadini e aziende. E per il paese in rete. Oggi, è la volta di Meltdown e Spectre. Vulnerabilità interne ai microprocessori. Portate alla luce dai ricercatori del team Google Project Zero in collaborazione con altri gruppi indipendenti di ricerca. Rivelazioni che hanno messo alle corde i principali produttori del settore, costringendoli ad ammettere che la stragrande maggioranza di quelli sfornati negli ultimi dieci anni, utilizzati su PC e tablet, server, router e smartphone sono vulnerabili. Bug interni ai processori. Classificati in due varianti, Meltdown, due vulnerabilità, le più datate e Spectre, una vulnerabilità, la più recente e anche la più grave. Falle connesse alla cosiddetta “esecuzione speculativa”, una funzionalità con cui i processori, per velocizzare le operazioni, scommettono su una strada che giudicano come la più probabile tra le due possibili, e sulla base di questa scelta iniziano a eseguire i calcoli ancor prima di ricevere le istruzioni.

TI PIACE QUESTO ARTICOLO?

Iscriviti alla nostra newsletter per essere sempre aggiornato.

«In altre parole, in quel meccanismo con cui le CPU moderne cercano di “predire” cosa dovranno fare nei prossimi cicli, accelerando l’esecuzione dei programmi» – come ci spiega Mauro Cicognini, membro del comitato direttivo di CLUSIT, l’associazione Italiana per la Sicurezza Informatica. Vulnerabilità che sfruttano un difetto di progettazione. «Uno schema progettuale vecchio almeno di vent’anni, utilizzato per aumentare la prestazione dei chip» – mette subito in chiaro Michele Colajanni, direttore del Centro di Ricerca Interdipartimentale sulla Sicurezza e Prevenzione dei Rischi (CRIS) e del corso in Cyber security dell’Università di Modena e Reggio Emilia. Difficile stabilire con precisione a quando risalga la scoperta. Secondo alcuni, si tratta di una falla nota sin da quando questa intuizione progettuale è stata adottata nel disegno dei processori. È quello che per esempio ha dichiarato Amazon – non esattamente il meno informato degli operatori del settore – in una nota ai suoi clienti dei servizi cloud. Altri tendono a spostare la scoperta più in là nel tempo. «La vulnerabilità esiste da molti anni, ma non penso fosse nota da altrettanto tempo» – afferma Colajanni. «Di certo, non è una falla degli ultimi giorni o mesi. Diciamo che in certi ambienti se ne parla dal 2017». Difficile datare con precisione il momento in cui è stata individuata la vulnerabilità. Sappiamo che questo “buco” nella sicurezza consente di accedere alla memoria dei dispositivi – tutti i dispositivi che montano un processore costruito negli ultimi dieci anni indipendentemente dal sistema operativo installato – e sottrarre i dati presenti. Senza lasciare tracce. Immediatamente dopo le prime rivelazioni, anche IDC ha confermato la gravità della minaccia. Ma nel quadro generale, limitata, perché sono pochi coloro che sono veramente in grado di sfruttarla.

UN DANNO PER INTEL MA NON SOLO

Secondo alcuni, questa vicenda ha tutto il potenziale per mandare in frantumi l’immagine di uno dei giganti dell’industria così come la conosciamo. Che non è solo quella dell’azienda che detiene con l’80 per cento del mercato nel campo dei microprocessori per PC e server. Ma molto, molto altro. Un concetto ribadito dal CEO Brian Krzanich, al recente CES di Las Vegas. Uno speech in cui il boss del gigante di Santa Clara dopo aver liquidato in meno di due minuti le osservazioni su Meltdown e Spectre ha illustrato per gli altri 38 tutte le attività in corso – dalla collaborazione con la scuderia Ferrari, che utilizzerà le tecnologie Intel per sfruttare i dati delle corse a vantaggio di piloti e tifosi, all’auto a guida autonoma, passando per l’intelligenza artificiale al servizio delle imprese – senza più quasi nemmeno nominare, e anche questo è a suo modo un esercizio di equilibrismo interessante, il termine “processore”. Che poi è il “cuore”, o meglio la “mente” di ogni computer, e soprattutto, quello che ha permesso a Intel di macinare fatturati e utili miliardari per quasi cinquant’anni. Una grande storia di successo narrata in tanti libri di economia. Puntellata tuttavia anche da cause legali e sanzioni milionarie. Culminate nel maggio del 2009 con la multa da 1,06 miliardi di euro, comminata dall’Antitrust europeo per abuso di posizione dominante e sei mesi più tardi con l’accordo extragiudiziale da 1,25 miliardi di dollari con la rivale storica AMD. Un passato di cui, c’è da scommettere, si riparlerà ancora molto. Principalmente dopo le recenti indiscrezioni sulla vendita di azioni Intel per oltre 39 milioni di dollari da parte dell’attuale CEO. Una vendita effettuata con largo anticipo rispetto alle rivelazioni su Meltdown e Spectre, ma ugualmente sospetta. Tanto da risvegliare l’interesse della SEC, la Consob statunitense, al lavoro da mesi per fare chiarezza sull’operazione. Improbabile che queste vulnerabilità possano impattare sui dati di vendita di Intel, spostando gli equilibri in termini di quote di mercato. «Non credo ci sarà alcun impatto percepibile sulle vendite di Intel, anche perché come possono i suoi concorrenti dimostrare di essere più sicuri? Esiste forse un qualche standard, o almeno una metrica, che possa misurare questa maggiore sicurezza, in un modo logicamente robusto, e accettabile dal mercato?» – osserva Mauro Cicognini di CLUSIT. Rischioso però escludere a priori che altre vicende interne, come la variazione delle regole contro i pericoli dell’insider trading, non possano riservare altri colpi di scena. Il mercato, in qualche occasione, ha dimostrato di non perdonare. Nel frattempo, è ormai storia la notizia del sorpasso di Samsung tra i produttori di chip. Un evento che sancisce la fine del dominio Intel su questo mercato che risale ai primi anni 70.

Leggi anche:  Il supporto degli MSP ai rischi digitali per le aziende della Generazione Z

UNA GESTIONE DELLA CRISI DA MANUALE

I problemi per il gigante di Santa Clara potrebbero essere appena iniziati. Tuttavia – guai di Intel a parte – la vicenda Meltdown e Spectre offre molti altri spunti interessanti di riflessione. Mantenere un segreto il più delle volte è un’impresa quasi disperata. In questa occasione, chi ha pilotato tutta la vicenda ha dato prova di grande maestria. «Google si è comportata in modo esemplare: appena scoperta la vulnerabilità e verificata la possibilità di sfruttarla, ha informato in modo riservato Intel, AMD e ARM, i responsabili della comunità Linux e Microsoft» – afferma Colajanni del CRIS, sottolineando altresì l’assenza di speculazioni come in altre occasioni. «Le vicende Equifax e Sony sono state gestite molto peggio. La tempestività degli aggiornamenti sarebbe un indizio sul tempo che le imprese coinvolte hanno avuto per prepararsi a gestire la crisi. Le patch uscite in questi giorni sono talmente invasive che non è possibile credere siano state messe a punto in una settimana. Sono il frutto di mesi di lavoro. Appena si è avuta notizia delle vulnerabilità, in un paio di giorni c’erano già le patch». Attività che secondo Colajanni rivelano un alto grado di coordinamento e di preparazione. E anche, se vogliamo, di segretezza. «Solo scalfita da qualche “spiffero”, come la dimostrazione effettuata da un gruppo di ricercatori di Londra nel mese di novembre».

TESTARE HARDWARE E SOFTWARE

Dalla vicenda, emerge l’importanza di testare adeguatamente hardware e software commercializzati. «Il testing dei prodotti è un problema. Budget e tempi dedicati a questa attività sono sempre più compressi» conferma Colajanni. «Prendiamo il software. Si stima che l’ultima versione del sistema operativo di Microsoft contenga qualcosa come cinquanta milioni di righe di codice. Data la complessità degli applicativi, un errore di programmazione durante la scrittura del codice è molto probabile. Nel caso dell’hardware, la fase di testing richiede ancora più impegno. I microprocessori sono tra i dispositivi più complessi in circolazione. Miliardi di transistor la cui progettazione è diventata impossibile senza l’ausilio di computer in grado di semplificare la complessità. Per i costruttori si tratta di un processo che richiede più tempo rispetto ai produttori di software. «Testare i processori è un processo lento e difficoltoso. E che comunque non mette al riparo da errori» – conferma Colajanni. Come dimostrano i listati di “errata”, correzioni, che i costruttori forniscono insieme alle specifiche dei loro prodotti. In alcuni casi, si tratta solo di seccature. In altri, ed è questo il caso, possono mettere in serio pericolo la sicurezza. Testare l’hardware secondo alcuni esperti presenta più difficoltà rispetto al software. E gli errori, i bug dell’hardware possono avere conseguenze più gravi. Principalmente per via del ruolo svolto dall’hardware nel funzionamento di un computer. Mentre il software in estrema sintesi è una lista di istruzioni, il compito del microprocessore è quello di eseguirle correttamente. Complessità che induce a ritenere che i dispositivi fisici siano anche più difficili da patchare da remoto rispetto al software. E che, in qualche caso, sia addirittura impossibile farlo.

Leggi anche:  Il paradigma SASE rivoluziona la protezione dei dati

SOSTITUIRE PARTE DELL’HARDWARE

«Queste vulnerabilità sono un effetto “collaterale” dell’obiettivo di velocizzare l’esecuzione dei processi. Purtroppo, causano la possibilità di accedere a spazi di memoria arbitrari con le conseguenze che tutti possono immaginare. Detto questo separerei i problemi dalle soluzioni» – riprende Colajanni del CRIS, stemperando i toni. «Sono certo che nel progetto dei nuovi processori si terrà conto di queste vulnerabilità, provvedendo by design». In effetti, sembra che i rischi di sicurezza associati a Meltdown possano essere risolti con le patch già a disposizione sui principali sistemi operativi. Un rimedio temporaneo e non una soluzione definitiva? Staremo a vedere. Per quanto riguarda Spectre, il problema è più grave. Plotoni di sviluppatori sono al lavoro per trovare un cerotto per mitigare il problema. Ma sono in molti a temere che l’unico rimedio efficace sia quello di riprogettare i processori vulnerabili e procedere con la loro sostituzione. Con un esborso di miliardi di euro e tempi non prevedibili.

COSTI EXTRA IN VISTA PER LE AZIENDE

Patching dei sistemi. La falla è grave. Ora tocca correre ai ripari. Per parare il colpo si renderà necessario patchare in fretta tutti i sistemi a rischio. «Un’attività extra da pianificare, stilando una lista delle priorità, e che inciderà in modo significativo sull’operatività dell’azienda. Allocate le risorse, bisognerà testare e poi procedere con la distribuzione delle patch sui sistemi» – afferma Cicognini di CLUSIT. Il suggerimento è di procedere con gli aggiornamenti in modo ragionato. Sottolineando la necessità di vagliare l’opportunità di un patching massivo. Il consiglio di vendor ed esperti è di partire con l’update manuale dei sistemi non critici. In modo da assicurarsi la compatibilità del software con applicazioni e sistemi non bloccanti per l’azienda. L’altro aspetto molto dibattuto è l’impatto degli aggiornamenti sulle performance dei processori. Le prime stime degli analisti di IDC ipotizzavano un degrado delle prestazioni oscillante tra il 5 e il 30 per cento. Previsioni in seguito confermate dai dati provenienti dagli stessi vendor e dalle prove sul campo. «Molto dipende dalle applicazioni» – ci dice Colajanni del CRIS. «Ci sono applicazioni più “computationally intensive” – che comportano cioè un uso intensivo delle risorse del sistema – per le quali il rallentamento sarà più sensibile. Altre, per le quali l’input/output è il collo di bottiglia prevalente, per cui non si noterà alcun degrado di prestazioni. Per certo, le prime subiranno un calo, ma tenendo conto dell’evoluzione dei processori, sarà ben compensato». In ogni caso, rimediare a queste vulnerabilità inciderà sui costi di aziende e organizzazioni. In una misura variabile a seconda del mix di asset di ognuna. Chi dispone prevalentemente di pc on-premise subirà un certo tipo di impatto. «Le grandi aziende che hanno già attivato processi e sistemi di patch management non ne risentiranno più di tanto» – sottolinea Colajanni. «Per le altre invece, è bene che usino questo caso per attivarne uno, in quanto per loro sarà molto più costoso, soprattutto in termini di gestione e di impatto sulla continuità operativa». Chi invece si affida anche a macchine virtualizzate, infrastrutture in cloud e risorse condivise, processori compresi, dovrà agire diversamente. «In questo caso si tratterà di verificare la diligenza del fornitore di servizi cloud nell’aggiornare i sistemi» – spiega Cicognini.

Leggi anche:  Le attività illecite del personale comportano rischi per la sicurezza informatica delle aziende

DIFFICOLTÀ DI AGGIORNAMENTO

Per tutti, l’aggiornamento dei sistemi sarà un costo. Anche per via della valanga di aggiornamenti arrivati in queste settimane dai vendor. «Il vero problema – osserva Colajanni – sarà per quei casi in cui le patch sono difficili se non impossibili da applicare. Per questi scenari non c’è una vera soluzione». La buona notizia è che Meltdown sembra sia patchabile. Non così Spectre. Mitigabile, pare, solo con aggiornamenti al microcode. La risoluzione del problema alla radice – però – è demandata alla sostituzione dei processori affetti dal problema. Si stima che un nuovo processore progettato oggi arriverà sul mercato non prima di 36/60 mesi. Perciò la scelta di aggiornare il microcode – fermo restando la complessità di distribuire questo tipo di patch da parte dei costruttori – è probabilmente al momento la miglior opzione disponibile. Nel frattempo, le aziende dovranno correre ai ripari per ovviare al problema con metodologie note. «I rischi si possono attenuare con i soliti metodi: multipli livelli di protezione, accesso limitato e controllato, sistemi di detection più sofisticati» – suggerisce Colajanni.

UN ECOSISTEMA DI TESTING

L’importanza di un ecosistema di testing più affidabile è al centro del dibattito alimentato da esperti e sviluppatori. Ribadito che testare rappresenta un costo non trascurabile per i produttori, anche in vista dei nuovi piani di sostituzione dei microprocessori da parte dei produttori di chip che subiranno una decisa accelerazione con costi non prevedibili – come rileva IDC – questa ennesima vulnerabilità prova che quando in questa fase qualcosa va storto, i costi dell’insicurezza vengono scaricati dall’industria su aziende e organizzazioni. È chiaro che se la quasi totalità dell’installato in circolazione ha un difetto, la sostituzione di tutti i componenti inciderà – e molto – sulla struttura dei costi degli utilizzatori finali. Detto questo, bisognerà convivere con l’idea di essere esposti al pericolo di attacchi. Verosimilmente, l’hardware installato invecchierà con questa tara, che finirà per allinearsi ai ritmi consolidati di sostituzione dell’hardware. La buona notizia? Il probabile consolidamento del cosiddetto approccio “zero trust”. L’orientamento cioè di chi suggerisce di pensare al software, all’hardware e ai prodotti di sicurezza, come a qualcosa di intrinsecamente non sicuro. E agire di conseguenza.