Serve una svolta nella cybersecurity. Finora ha dettato legge la “mistica” del white hacker e del bug bounty: una logica basata sull’assioma che la sicurezza e la robustezza informatica sono e saranno ottenute grazie a coloro che attaccano un sistema, trovano delle vulnerabilità e le comunicano pubblicamente. Ma così non è. E le conseguenze sono sotto gli occhi di tutti.
Citando Grace Murray Hopper, “The Most Dangerous Phrase In Business: We’ve Always Done It This Way”: nella cybersecurity vince purtroppo questa logica. La conseguenza della mistica è la convinzione che le metodologie e gli strumenti per attaccare un sistema possano anche essere poi usate per capire come difenderlo. Quindi ogni investimento sull’attacco è anche visto come uno sulla difesa. Visto che da decenni ormai i sistemi sono attaccati con successo, forse è venuto il momento di verificare la validità di questa mistica e di cercarne una più efficace su cui basare la nostra sicurezza.
Cybersecurity, anche la Nsa ci ripensa
Un bell’articolo che racconta in dettaglio l’attacco lanciato da U.S. Cyber Command e da National Security Agency contro l’ISIS termina con una frase molto interessante del comandante dell’attacco “Penso che dovrebbe esserci molta più attenzione a come difendere i sistemi che a come attaccarli”. Contemporaneamente, la stessa NSA sta lanciando una nuova divisione focalizzata esclusivamente sulla difesa dei sistemi e delle infrastrutture informatiche.
Dunque, il messaggio che ci arriva da un ente sicuramente di punta nel campo della sicurezza informatica è che la difesa e gli attacchi informatici, defensive e offensive security se preferite, sono due campi diversi che richiedono competenze diverse.
Questo attualmente non è un concetto molto popolare ed infatti stanno fiorendo le competizioni, i corsi, ahimè anche universitari, che insegnano a comportarsi come dei veri white hacker ovvero insegnano come attaccare i sistemi, a penetrarli, a rubare le informazioni e via dicendo. Già questo è sufficientemente preoccupante poiché autorevoli osservatori ritengono che le abilità richieste per queste azioni non siano certo quelle necessarie per difendere i sistemi, fermare gli attacchi e tutto quanto ne consegue.
Comunque, il problema è ancora più preoccupante perché molto spesso si insegna solo come attaccare i sistemi e non anche come costruirli in modo che la sicurezza sia ottenuta come un risultato del progetto.
Sicurezza informatica, quali sistemi in campo
Una soluzione possibile è quella che, ad esempio, scopre e neutralizza le vulnerabilità prima che il sistema venga costruito in modo da renderlo più resiliente. In questo campo, risultati e metodologie innovative vengono trascurate accontentandosi spesso di illustrare metodi e strumenti per scoprire errori dei programmi che risalgono almeno a venti anni fa e non hanno mai influenzato la progettazione di sistemi reali. E di conseguenza non sono molto attraenti. Ma questo non è importante, gli abbiamo dato la mentalità dell’hacker, che importa di tutto il resto?
Quali sono le ragioni per intestardirsi in una strategia per la sicurezza informatica basata sull’attacco, senza curarsi dei continui fallimenti a cui ha portato? Mi stavo imbarcando in una complessa ed oscura spiegazione quando, fortunatamente per chi mi legge, ho trovato un prezioso report prodotto da ConsumerWatchdog, un’associazione di consumatori americani.
Questo report analizza la cybersicurezza delle nostre auto, ed in particolare i vari attacchi permessi dalla tecnologia che prevede di connettere ogni auto ad Internet. La connessione ad Internet permette risparmi significativi per le case automobilistiche poiché abilita aggiornamenti on-the-air del software che governa il funzionamento dei vari sistemi di un’automobile. In altri termini, il software che governa il veicolo può essere aggiornato in modo del tutto automatico e senza necessità di recarsi in una officina meccanica.
Automotive, le tecniche di difesa (e di attacco)
È bene ricordare che attualmente un’auto è un caso di sistema informatico per il controllo di impianti estremamente interessante e significativo il cui software ha un numero di istruzioni circa doppio del software che controlla un Boeing 787. Per apprezzare la complessità dei sistemi di controllo di una autovettura ed il loro ruolo significativo nel panorama informatico, riporto in fig. 1, informazioni dal sito Electronic Design sul numero di milioni di istruzioni per il controllo di un’auto e quello di altri sistemi di controllo e di popolari sistemi operativi.
Fig. 1 Milioni di istruzioni di alcuni sistemi
In un’auto, le istruzioni del sistema di controllo determinano molti parametri critici quali accensione e spegnimento del motore o lo spazio di frenata. Ad esempio, aggiornando il software di controllo è possibile variare lo spazio di frenata di un’auto. Il report di ConsumerWatchdog è del luglio 2019 ed ha un titolo almeno allarmante: Kill Switch: Why Connected Car can be Killing Machines and How to Turn them Off. Premettendo che quanto detto per la cybersicurezza delle auto si può replicare per un qualsiasi sistema complesso che comprenda un sottosistema informatico, cito un brano del report:
“White hackers develop sophisticated techniques for finding vulnerabilities with the goal of helping software developers make their products more resilient. While white hat hackers generally have good intentions, their efforts are often counterproductive to improving security in safety-critical systems. The biggest flaw in the “white hat” model is that it encourages automakers to repeatedly patch a system that was never fundamentally secure. History has shown that, while this can make incremental improvements, the process never ends, so it does not result in a secure product. Internet-connected cars were unsafe a decade ago and are still unsafe today”.
Cybersecurity, i danni della mistica White Hat
Quindi la giustificazione della mistica del white hacker non solo è falsa, e basta vedere come applicazioni e sistemi siano tutt’ora attaccati, ma è uno dei principali ostacoli alla produzione di sistemi sicuri. L’ostacolo nasce perché la mistica sposta a dopo il rilascio del software il tempo in cui preoccuparsi delle vulnerabilità.
I white hacker hanno quindi un ruolo fondamentale in un ecosistema che produce prodotti con difetti, le vulnerabilità: scopre questi difetti solo dopo la produzione di un sistema e li elimina tentando di rendere il sistema più sicuro. Purtroppo, questo tentativo non è efficace perché nonostante la dedizione, il disinteresse e le notevoli competenze tecnologiche dei white hacker, non è semplice trovare tutte le vulnerabilità. Se non si trovano tutte le vulnerabilità, eliminarne qualcuna non fornisce nessuna garanzia di rendere il sistema più resiliente agli attacchi, anzi può diminuire la resilienza, e quindi la sicurezza, del sistema.
Come sottolineato da ConsumerWatchdog, la principale ragione a favore della mistica del white hacker è economica:
“Despite the ineffectiveness of white hat hackers’ efforts at producing a secure car, their work is extremely valuable to automakers. The continuous churn of finding and fixing bugs presents the illusion that automakers are “working hard” to create a safe product. Paying bug bounties to white hat hackers is generally much less expensive than hiring employees to do the same work, in that automakers need only pay for positive results. Further, the “hacker mystique” contributes to the positive publicity created when a white hat reveals a new vulnerability”.
Così il White Hacker fa risparmiare l’azienda
Il vantaggio della mistica del white hacker, e soprattutto del bug bounty, per le aziende è quello di persone che vengono pagate se e quando trovano una vulnerabilità. Se la ricerca viene affidata a dei dipendenti, i costi sono molto maggiori perché occorre attrezzare dei laboratori e poi pagare i dipendenti indipendentemente da quante vulnerabilità trovano.
Brevemente, la mistica del white hacker esternalizza molti costi legati alla sicurezza, in particolare quelli per la ricerca di vulnerabilità. Considerazioni simili valgono per corsi universitari che trovano nell’aggiunta di corsi su hacking una semplice ed economica soluzione per evitare una rivisitazione dei programmi per rispondere alle richieste di competenze su sicurezza informatica.
L’approccio basato su white hacker trascura i metodi che da tempo esistono per analizzare, in modo statico o dinamico, il codice e scoprirne le vulnerabilità. Alcuni di questi metodi possono essere applicati ai singoli moduli per la scoperta di singole vulnerabilità, altri ad interi sistemi per la scoperta e l’eliminazione dei percorsi d’attacco che permettono ad un attaccante di raggiungere i gioielli della corona a partire dalla superficie d’attacco.
Il range di metodi applicabili va da interpreti su domini particolari, ad esecutori simbolici, a tecniche di fuzzing o di reverse engineering fino ad approcci basati su modelli per una analisi sistemica. Ovviamente, una soluzione basata su queste metodologie e strumenti richiede non solo il lavoro di tecnici esperti, ma anche l’adozione di strumenti di analisi e di progetto ed anche la formazione dei tecnici sugli strumenti. La mistica del white hacker pur essendo meno efficace è senz’altro più poetica e richiede investimenti minori sia alle aziende che alle università.
La strategia dell’offensive security
Il problema vero nasce quando la mistica del white hacker genera quella dell’offensive security, un campo su cui si stanno concentrando investimenti significativi. L’offensive security è focalizzata sulla ricerca di vulnerabilità che permettono di eseguire una catena di attacchi per ottenere diritti sul sistema target e sulla esecuzione di tali attacchi.
Un possibile esempio è quello di una catena che parta dal web server di un’azienda ed arrivi a controllare un database con informazioni critiche per l’azienda. La cyber killchain definita dalla Lockeed descrive le varie azioni necessarie per scoprire le informazioni sul sistema, sulle vulnerabilità da utilizzare e sugli attacchi da eseguire. La Mitre Att&ck Matrix descrive decine di tecniche che gli attaccanti possono sfruttare per realizzare ognuno degli attacchi in una catena nascondendoli ai difensori. Strumenti come Metasploit permettono di automatizzare buona parte degli attacchi. Gli ultimi sviluppi dell’offensive security cercano di fondere tutti questi risultati in piattaforme in grado di attaccare in modo stealth ed automatico per massimizzare la probabilità di successo.
La definizione di una piattaforma software che automatizzi l’attacco è un miglioramento importante rispetto alle attività di un white hacker perché permette, ad esempio, di raffinare le nostre analisi sugli attaccanti e di conoscere in profondità le loro strategie. Non comporta necessariamente la scoperta di un numero maggiore di vulnerabilità, che è possibile con tecniche meno invasive. Comunque, la ricerca su offensive security è fondamentale per la sicurezza informatica ma può però diventare dannosa se concepita ed utilizzata in modo separato, ed alternativo alla defensive security.
Offensive security, solo interventi spot
La separazione avviene quando si adottano tecnologie o soluzioni euristiche non aggiornate per la difesa. La sintesi tra soluzioni non aggiornate per la difesa e l’offensive security produce una strategia che prevede unicamente interventi spot e scorrelati dal sistema considerato e non a strumenti e piattaforme per un’analisi ed improvement continuo a livello di sistema.
Un esempio significativo dei problemi posti dalla separazione tra offensive e defensive security è la creazione di cyber range civili ovvero di laboratori di testing dove gli sviluppatori di software potranno portare i loro prodotti e qualcuno li attaccherà a fondo. La separazione tra offensive e defensive non ha ancora permesso di chiarire cosa succederà quando qualcuno segnalerà allo sviluppatore quello che già possiamo dirgli ora, gratis, ovvero che nel suo prodotto ci sono parecchie vulnerabilità.
L’obiettivo della security by design
Chi eliminerà le vulnerabilità trovate? Che feedback riceve il produttore di software per migliorare il suo processo produttivo e le sue metodologie di progetto? Cosa succede se le vulnerabilità in un prodotto dipendono da librerie fornite da terzi?
Ed ancora: come si valuta se il feedback al produttore, qualunque esso sia, migliora la sicurezza e la robustezza del modulo? Sicuramente la sicurezza e la robustezza non migliorano semplicemente eliminando qualcuna delle vulnerabilità. Anzi, conviene ripetere che, con buona pace dei penetration test, spesso eliminare delle vulnerabilità in un modulo senza curarsi del sistema cui il modulo appartiene può essere dannoso e portare ad una perdita di sicurezza del sistema.
Questo è ormai un risultato consolidato al punto da essere portato come esempio anche dai produttori più affidabili nel materiale illustrativo dei più avanzati strumenti di breach and simulation che attaccano un sistema perché poi sia migliorato. È paradossale pensare di investire in prodotti per creare un laboratorio per poi trascurare le indicazioni dei produttori degli strumenti che il laboratorio deve utilizzare. Un cyber range deve quindi necessariamente offrire non solo strumenti per individuare vulnerabilità ma anche strumenti per scegliere e validare modifiche al sistema che individuino quali vulnerabilità eliminare e garantiscano, a priori, che il sistema risultante sia più robusto.
Quali politiche per sistemi protetti
Quindi conviene riflettere attentamente su quali investimenti sono necessari e perché. Sicuramente la formazione, ed anche quella superiore, deve prevedere corsi su strumenti e tecniche per scoprire le vulnerabilità, ma deve contemporaneamente offrire anche quelli che insegnano come costruire sistemi non vulnerabili operando sul sistema complessivo anche quando si utilizzano componenti con vulnerabilità.
Una politica di supporto alle aziende interessate ad aumentare la sicurezza dei loro prodotti dovrebbe essere orientata alla formazione dei dipendenti su tecnologie ormai assodate ed all’acquisizione di strumenti di verifica e validazione in grado di lavorare sul progetto ed a priori. Sicuramente, questi investimenti sarebbero più produttivi di quelli focalizzati sulla sola offensive security e ci permetterebbero di raggiungere la security by design che la legislazione invoca sempre più ma senza indicare come essa possa essere realizzata e senza supportare le aziende interessate a garantirla ai loro clienti. In un mercato che privilegia le soluzioni quick and dirty, un supporto a chi è interessato fornire prodotti sicuri e robusti può essere indispensabile.
In tutto il dibattito non dobbiamo mai dimenticare l’urgenza di trovare delle soluzioni applicabili ora. Infatti, attualmente, le infrastrutture informatiche hanno un ruolo vitale non solo negli impianti di controllo industriale e per la sicurezza di aerei ed auto ma anche in tutti gli aspetti della vita civile, sociale e politica.
Basta pensare che le infrastrutture informatiche connettono e permettono di accedere a centinaia di database che contengono informazioni su di noi, i nostri gusti, le nostre preferenze, le nostre malattie. Manipolare questi database può avere effetti dirompenti su tutte le nostre istituzioni. Immaginiamo l’effetto della manipolazione di un database con i nostri dati clinici e che ci attribuisca malattie che non abbiamo.
La sicurezza informatica deve garantire la confidenzialità e l’integrità di tutte queste infrastrutture e dei database a cui esse permettono di accedere. Dal successo dei meccanismi di sicurezza informatica dipende l’integrità e la disponibilità delle informazioni che guidano le nostre scelte sociali e politiche e che determinano, in ultima analisi, la nostra libertà. E per sottolineare l’urgenza di questo problema e la necessità di scoprire e rendere inoffensive le vulnerabilità prima, e non dopo aver creato una infrastruttura informatica, mi permetto un’ultima citazione dal report:
With our safety at stake, we cannot wait another decade hoping that this process will eventually find the last remaining security vulnerability.
Il rapporto si limita ad evidenziare i rischi per la nostra safety, ma nella società civile a rischio c’è molto altro.
