Costruire sistemi senza vulnerabilità è un’impresa troppo costosa e complessa che fino ad ora non ha avuto successo. Utile dunque un modello alternativo, una soluzione di cyber security meno costosa e più efficace che accetta la presenza di vulnerabilità ed elimina quelle critiche applicando delle patch o introducendo dei controlli compensativi: il modello basato sui percorsi d’attacco.
Una vulnerabilità è critica se abilita un percorso di attacco, cioè una sequenza di attacchi a moduli del sistema, che permette ad un attaccante di muoversi nel sistema ed aumentare i propri privilegi fino ad impadronirsi degli asset di una organizzazione. Il metodo basato su percorsi permette di valutare in maniera consistente il rischio associato ad una vulnerabilità ed individua le contromisure più appropriate minimizzando le contromisure ed i controlli compensativi da applicare. Di conseguenza, aumenta significativamente il ritorno dell’investimento in sicurezza.
La ricerca di un modello alternativo
Un lavoro molto influente di Saltzer e Schroder elenca i dieci principi per la sicurezza, cioè gli step da seguire fedelmente per evitare di costruire sistemi e componenti con vulnerabilità:
- Economia di progetto
- Fail-safe defaults
- Open design
- Separation of duties
- Mediazione Completa
- Privilegio minimo
- Insieme minimo di meccanismi
- Accettabilità psicologica
- Lavoro proporzionale dell’attaccante
- Ricordare le violazioni
A partire questo lavoro, il progetto di sistemi sicuri si è focalizzato sulla costruzione di moduli senza vulnerabilità come elementi base per costruire sistemi senza vulnerabilità. Già Saltzer e Schroder erano coscienti della estrema complessità di applicare fedelmente i loro principi, al punto di ammettere che comunque un sistema può essere attaccato. Infatti, gli ultimi due principi ammettono implicitamente che attacchi con successo sono possibili. Infatti, questi due principi richiedono, rispettivamente, di aumentare il lavoro richiesto da un attacco con successo e di ricordare gli attacchi che hanno avuto successo.
In un approccio realistico, i dieci principi possono essere usati per definire un sistema ideale o asintotico con cui confrontare le varie alternative di progetto per scegliere quella meno insicura. A parziale conferma, lavori successivi anche degli stessi autori adottano un approccio iterativo che migliorano il sistema considerato dopo ogni attacco con successo. Questo lavoro illustra un approccio alternativo che accetta la presenza di vulnerabilità nei vari moduli ed individua quelle da eliminare mediante patch o controlli compensativi per difendere gli asset di una organizzazione.
Vulnerabilità, Riuso e Patch Scheduling
In un mondo in cui i vincoli sui sistemi e sulle strategie di progetto sono anche, e sopratutto, economici, il riuso di moduli già esistenti è una strategia importante, ma riusare un modulo vuol dire anche introdurre nel sistema le sue vulnerabilità. Molto spesso, vincoli economiche e di tempo non permettono di adottare una strategia patch all che elimina tutte le vulnerabilità di ogni modulo, mediante patches o controlli compensativi, prima di installare il sistema finale. Occorre quindi definire una metodologia per individuare quanti e quali vulnerabilità dei vari moduli devono essere eliminate prima della installazione del sistema. A parità di prestazioni, in particolare a parità di robustezza rispetto agli attacchi esterni, minore è il numero di vulnerabilità su cui intervenire, migliore la metodologia.
Ovviamente, vista la complessità dei sistemi di cui stiamo parlando, la metodologia deve necessariamente essere automatizzata e la sua implementazione mediante una piattaforma, i.e. una suite di strumenti, garantisce proprietà fondamentali quali la ripetitività dell’analisi e la sua completezza. È bene evidenziare che la scelta delle vulnerabilità su cui intervenire è un problema che si presenta non solo prima dell’installazione ma periodicamente durante tutta la vita di un qualsiasi sistema ICT complesso che utilizzi moduli standard. In particolare, il problema, noto come patch scheduling si ripresenta quando diventano pubbliche vulnerabilità nei moduli che il sistema utilizza e può essere cosi riassunto: scegliere le vulnerabilità su cui intervenire tra quelle scoperte ed in quale ordine.
Il problema di calcolare un patch scheduling che riduca il numero di vulnerabilità su cui intervenireè di fondamentale importanza. Infatti, spesso anche organizzazioni complesse e ben coscienti dell’importanza della sicurezza informatica non riescono ad applicare tutte le patch rilasciate per i moduli del loro sistema in modo da fronteggiare eventuali attacchi. È ben noto che il rischio per un sistema in cui è present una vulnerabilità V aumenta dal momento in cui si rilascia una patch per V perché questo è anche il momento in cui gli attaccanti acquisiscono tutte le informazioni necessarie per attaccare chi non applica la patch per V. Visto che, come evidenziato in fig. 1, il tempo medio necessario per applicare una patch è di 100 giorni, è chiaro che in questi cento giorni il sistema rimane indifeso rispetto alla vulnerabilità considerata. Il tempo è ancora più preoccupante perché in media entro 15 giorni viene pubblicato un exploit per una vulnerabilità, anche quando nessun epxloit era noto inizialmente. Questo spiega il grande successo, nell’ottica dei loro sviluppatori, di ransomware come WannaCry e NotPetya che hanno avuto effetti devastanti pur sfruttando vulnerabilità note da tempo.
Fig. 1. Tempo medio per intervento su una vulnerabilità
Il recente attacco alla NASA partito da un dispositivo Raspberry Pi connesso illegalmente alla rete ha potuto trafugare 500Mb di informazioni sul trasferimento di tecnologie critiche grazie anche alla mancata applicazione di alcune patch. Un altro caso di successo dovuto ad un missed patch è stato l’attacco alla Equifax del Maggio 2017 dove sono stati rubati i dati di circa 150 milioni di persone. Esiste un sostanziale consenso sul fatto che, in molti sistemi, gli impatti dovuti ai missed patch sono più gravi di quelli dovuti ad attaccanti che sfruttino 0-day attack. In effetti, il numero di attaccanti che possono sfruttare un missed patch è senz’altro superiore a quelli che dispongono di uno 0-day attack. Inoltre, nessuno è disposto a sprecare una 0-day quando ci sono altre soluzioni più economiche.
Numerosi metodi per il patch scheduling molto diffusi si sono dimostrati inefficaci perchè non considerano le peculiarità del singolo sistema. Ad esempio, molti vulnerability scanning valutano il rischio mediante una lista delle vulnerabilità del sistema. In alcuni casi, ad ognuna delle vulnerabilità è associato uno score, un punteggio, che ne valuta il rischio. Purtroppo, gli attaccanti non lavorano considerando le singole vulnerabilità in modo isolato ma considerano se, e come, l’insieme complessivo delle vulnerabilità permettano di attaccare un sistema. Due vulnerabilità che singolarmente presentano un rischio ridotto possono essere presenti in uno stesso sistema e, se sfruttate da uno stesso attaccante, permettere il controllo del sistema.
Quindi metodi di scoring che, come il Common Vulnerability Scoring System, considerano unicamente gli attributi della vulnerabilità non forniscono informazioni specifiche sul possibile uso di una vulnerabilità per attaccare il sistema di interesse. Le due vulnerabilità utili per il nostro attaccante avrebbero sicuramente un CVSS score molto basso e, in base a quanto indicato dalla curva in fig. 1, sicuramente sarebbero ancora aperte dopo un anno dalla loro scoperta. La discussione precedente ci permette immediatamente di dedurre una prima caratteristica desiderabile in ogni metodo per calcolare un patch scheduling, la dipendenza dello scheduling dallo specifico sistema considerato.
Modello di un sistema e capacità predittiva
Nel seguito vedremo come il metodo proposto lavora non sul sistema reale ma su un modello del sistema. L’uso di un modello evita di produrre rumore che disturbi il sistema. Questa sezione descrive brevemente alcune caratteristiche del modello di un sistema di nostro interesse. Il modello di un sistema raccoglie ed organizza informazioni sul sistema utili per la soluzione di specifici problemi. Esistono quindi più modelli dello stesso sistema in base al problema che interessa risolvere ed al livello di dettaglio della descrizione. Il problema di nostro interesse è legato alla sicurezza del sistema ed in particolare a come gli attacchi permessi dalle vulnerabilità dei moduli permettano ad un attaccante di controllare gli asset di una organizzazione.
Di conseguenza, il modello contiene tutte le informazioni sulle vulnerabilità dei vari moduli del sistema e sugli attacchi che ogni vulnerabilità abilita. Il modello associa ad ogni attacco i diritti necessari per la sua esecuzione e quelli ottenuti quando l’attacco ha successo. Queste informazioni permettono di scoprire come l’attaccante può comporre i vari attacchi nei suoi movimenti laterali verso gli asset. Una ulteriore proprietà fondamentale di un attacco è la sua probabilità di successo. Questa probabilità dipende dalla complessità delle azioni da eseguire e dal verificarsi di particolari condizioni al di fuori del controllo dell’attaccante. La probabilità di successo dei vari attacchi che un attaccante utilizza determina la probabilità di successo del movimento laterale verso gli asset.
Ulteriori informazioni del modello descrivono le varie connessioni logiche tra i moduli. Queste connessioni sono fondamentali per descrivere gli attacchi remoti. Una vulnerabilità V abilita un attacco remoto se chi controlla un modulo può eseguire questo attacco contro uno dei moduli connessi a quello controllato e che è affetto da V. Gli attacchi remoti sono estremamente pericolosi perchè vengono lanciati da altri moduli, indipendemente dal comportamento del modulo target che non ha difese contro questo attacco. Le informazioni sulle connessioni logiche sono dedotte a partire dalle regole di routing e di filtraggio ai vari livelli dei protocollli di comunicazione. Una ulteriore informazione utile per costruire il modello è quella delle relazioni gerarchiche tra moduli. Ad esempio il controllo di un hypervisor permette quello delle macchine virtuali che esso supporta. In altri casi, il controllo di un web server permette quello dei database che esso interfaccia.
Ogni approccio basato su un modello deve porsi il problema della accuratezza del modello stesso e della sua capacità di predire ed anticipare il comportamento del sistema descritto. Nel problema di interesse, la scoperta dei percorsi di attacco, la capacità predittiva di un modello è legata al numero di falsi positivi e di falsi negativi di una analisi che lo utilizzi per scoprire i percorsi. Ad esempio, nel problema considerato falsi positivi e negativi possono riguardare le vulnerabilità presenti nei moduli. Ovviamente, entrambi gli errori devono essere minimizzati ma notiamo che in problemi di sicurezza i falsi positivi riducono l’efficienza dei risultati prodotti perché alcuni problemi segnalati possono non esistere. Falsi negativi possono essere più pericolosi, perché nascondono dei problemi esistenti e che possono semplificare gli attacchi contro il sistema.
Il metodo basato sui percorsi d’attacco
Il metodo basato sui percorsi d’attacco, metodo bpa, calcola un patch scheduling a partire dai percorsi che permettono ad un attaccante un movimento laterale che lo porti a controllare gli asset di un sistema. Un percorso d’attacco è una sequenza di attacchi elementari, i.e. ai singoli moduli di un sistema, che permette all’attaccante di aumentare i propri privilegi e di muoversi lateralmente nel sistema fino ad ottenere i privilegi che gli permettono di controllare uno o più asset di una organizzazione. Ad esempio, un attaccante può sfruttare l’accesso al sito web di una organizzazione per acquisire, tramite alcuni attacchi il diritto di amministratore sul nodo che ospita il sito.
Quindi può muoversi lateralmente e controllare altri nodi, acquisendo in questo modo un numero sempre maggiore di diritti su risorse interne. Gli attacchi continuano fino ad ottenere, ad esempio, i diritti di pilotare la rete di controllo di impianti di produzione o di leggere le informazioni in database interni con la IP dell’organizzazione. La scoperta di un percorso d’attacco indica che un attaccante può comporre gli attacchi abilitati dalle singole vulnerabilità nei moduli del sistema per raggiungere gli asset dell’organizzazione. Il metodo bpa evidenzia che il rischio per l’organizzazione non nasce dalle singole vulnerabilità ma dai percorsi che esse permettono di costruire e che raggiungono gli asset dell’ organizzazione. Questo conferma ulteriormente come non sia possibile associare un rischio ad una vulnerabilità in astratto, ma che occorra contestualizzare la vulnerabilità in uno specifico sistema e con riferimento a specifici asset.
Il metodo bpa generalizza altre metodologie, quali Consequence-driven Cyber-informed Engineering, che calcolano un patch scheduling in base agli impatti di un attacco che sfrutti la vulnerabilità presenti. Il metodo bpa può essere decomposto nei seguenti passi:
- scoperta dei percorsi d’attacco,
- individuazione delle vulnerabilità critiche,
- calcolo dei patch e dello schedulingscheduling.
La scoperta dei percorsi d’attacco avviene in modo automatico con un approccio model based, che raccoglie informazioni sul sistema e costruisce un database con il modello del sistema. Come già detto, il modello descrive i moduli del sistema, la topologia delle loro connessioni e le loro vulnerabilità. Un secondo database comprende le informazioni sugli attaccanti, le strategie che usano per scegliere e comporre gli attacchi e le loro priorità e preferenze. Le informazioni nei due database permettono sia simulare gli attacchi elementari contro i singoli componenti che le strategie che gli attaccanti usano per costruire i loro percorsi d’attacco contro il sistema di interesse.
Simulando per centinaia di migliaia di volte il comportamento di ogni attaccante, un approccio model based può scoprire come aspetti stocastici, e.g. il successo o il fallimento di un singolo attacco influenzano il percorso ed analizzare tutto lo spazio dei possibili percorsi o, se si preferisce, delle possibili privilege escalation e dei movimenti laterali. In questo caso, un falso positivo è dato da un percorso di attacco che non esiste mentre un falso negativo corrisponde alla mancata scoperta di un percorso di attacco. I falsi positivi sono dovuti ad informazioni non accurate sulle vulnerabilità dei moduli mentre il metodo bpa genera un falso negativo se non scopre un percorso d’attacco esistente. Come detto in precedenza, falsi positivi riducono la efficacia dell’approccio mentre i falsi negativi impediscono di eliminare dei percorsi di attacco. Fortunatamente, la probabilità di un falso negativo può essere resa piccola a piacere simulando più volte del comportamento degli attaccanti.
I percorsi che un attaccante può scoprire ed utilizzare dipendono non solo dal sistema ma anche dalla adattività dell’attaccante stesso. Un attaccante adattivo cambia le sue strategie e preferenze in base al tipo di sistema che sta attaccando. Ad esempio, un ransomware non è adattivo perché sfrutta un insieme prefissato di vulnerabilità, che non dipendono in nessun modo dal sistema che sta attaccando. In breve, se il sistema non comprende le vulnerabilità che il ransomware sfrutta l’attacco fallisce. Invece, un attaccante adattivo sceglie le vulnerabilità da sfruttare tra quelle che il sistema offre. L’attaccante ha delle priorità e delle preferenze ma continua il suo cammino verso gli asset anche se nessuna delle vulnerabilità è tra le sue preferite.
Simulato l’attaccante e scoperti eventuali percorsi d’attacco, il metodo bpa calcola le vulnerabilità critiche ovvero quelle che abilitano attacchi su uno qualsiasi dei percorsi scoperti. Ad ogni vulnerabilità critica, il metodo bpa associa una molteplicità ovvero il numero di percorsi che la sfruttano. Note le vulnerabilità critiche e la loro molteplicità, il metodo calcola una prima approssimazione del patch scheduling costruendo una copertura ovvero un insieme che comprende una vulnerabilità per ogni percorso. L’eliminazione di una sola vulnerabilità interrompe un percorso ed impedisce all’attaccante di utilizzarlo. Per ridurre la dimensione della copertura, conviene scegliere coperture con vulnerabilità con molteplicità elevata perchè questo riduce il numero di vulnerabilità critiche su cui intervenire. In altre parole, interrompendo le parti condivise tra più percorsi si bloccano ad un costo ridotto tutti i percorsi che condividono la parte bloccata.
Se gli attaccanti considerati non sono adattivi, la prima copertura calcolata definisce il patch scheduling. Altrimenti, si suppone di aver eliminato dal sistema le vulnerabilità precedenti e si scoprono eventuali altri percorsi simulando il comportamento degli attaccanti contro il sistema cosi modificato. Questa nuova simulazione tiene conto dell’adattività dell’attaccante che può comunque scegliere altri percorsi nel sistema quando scopre che quelli che preferisce sono stati bloccati. Se la nuova simulazione non scopre altri percorsi, il calcolo del patch scheduling termina. Viceversa si uniscono tutti i percorsi scoperti in precedenza e quelli scoperti ora e si calcola una nuova copertura complessiva. Al prezzo di non utilizzare le coperture già calcolate, il calcolo di una nuova copertura minimizza la dimensione della copertura perché sfrutta vulnerabilità critiche comuni a percorsi scoperti in momenti diversi. I tre passi di eliminazione vulnerabilità, scoperta di nuovi percorsi e calcolo di una nuova copertura vengono ripetuti fino a quando si scoprono nuovi percorsi. Ciò garantisce di fermare sicuramente l’attaccante adattivo, indipendentemente dalle sue preferenze.
Esperienze su un grande numero di sistemi reali, compresi sistemi di controllo industriale ed architetture cloud, dimostrano come la dimensione della copertura calcolata al termine delle iterazioni sia di alcuni ordini di grandezza inferiore al numero delle vulnerabilità presenti. In un caso, indubbiamente estremo ma ciononostante significativo, si è dovuti intervenire su 16 delle 9000 vulnerabilità presenti in un impianto di controllo industriale. In alcuni esercizi di cyberwar, le vulnerabilità sono state individuate e gestite nelle due ore a disposizione prima degli attacchi del red team.
Vita del sistema ed applicazione del metodo
Il metodo bpa richiede unicamente la descrizione del sistema e degli attaccanti memorizzata nei due database, quindi può essere applicato in un qualsiasi momento della vita del sistema. Sono due i momenti di particolare interesse:
- durante il progetto del sistema
- alla scoperta di nuove vulnerabilità dopo l’installazione del sistema.
Il metodo bpa può essere applicato durante il progetto del sistema perché, a differenza del penetration test o dei breach and simulation tools, opera su una descrizione astratta del sistema stesso. Ciò permette di ripetere a piacere le simulazioni d’attacco per raccogliere informazioni accurate e consistenti. Si evitano cosi le soluzioni parziali e spesso contraddittorie prodotte dai penetration test e sopratutto non si disturba il sistema nel suo normale funzionamento. L’ultima proprietà è fondamentale per sistemi ad elevata affidabilità che operino in tempo reale quali sistemi per medicina a distanza.
Un ulteriore vantaggio di adottare il metodo bpa a partire dalla fase di progetto è la grande varietà di contromisure e controlli compensativi disponibili durante il progetto di un sistema. Inoltre, il costo dell’adozione di una contromisura o di un controllo in fase di progetto è drammaticamente più basso di quello di un intervento su un sistema già esistente. E’ possibile immaginare una strategia di progetto in cui il metodo proposto viene applicato periodicamente durante le varie fasi di un progetto per anticipare la scelta e l’inserimento di contromisure o di controlli compensativi.
Dopo l’installazione del sistema, alla scoperta di nuove vulnerabilità, il metodo bpa permette innanzitutto di individuare nel sistema già installato e funzionante nuovi percorsi permessi dalle nuove vulnerabilità. Il tutto avviene senza disturbare il sistema perchè il metodo utilizza solo le informazioni nei due database aggiornati con le vulnerabilità appena scoperte. In questo caso, il metodo fornisce anche un insieme di controlli o patch da applicare.
E’ bene sottolineare che, visto il focus sui percorsi, i controlli ed i patch che il metodo bpa inserisce in un proprio scheduling non riguardano necessariamente le nuove vulnerabilita. Ad esempio, il metodo può suggerire di applicare delle patch che interrompono i movimenti laterali di un ‘attaccante prima che esso possa interagire con il componente affetto dalla nuova vulnerabilità. Quindi, il metodo bpa può rimediare una nuova vulnerabilità annullando il rischio da essa generato anche se il fornitore non ha ancora reso disponibile una contromisura o una patch per la vulnerabilità. Questo permette di chiudere i percorsi che le nuove vulnerabilita abilitano nel più breve tempo possibile, un vantaggio che nessuno dei metodi alternativi al bpa offre.
Altro vantaggio significativo del metodo proposto è la capacità di supportare a strategie di progetto o di gestione di tipo what-if. Queste strategie ipotizzano l’occorrenza di alcuni eventi per valutare e scegliere in anticipo le possibili reazioni agli eventi stessi. Ad esempio, è possibile individuare la reazione ottima ad una nuova vulnerabilità individuando e valutando le possibili contromisure prima che la vulnerabilità venga effettivamente scoperta.
Conclusioni
La possibilità di scoprire in fase di progetto ed in tutta la vita del sistema i percorsi di attacco abilitati da un insieme di vulnerabilità permette una valutazione del rischio specifica per il sistema e di calcolare un patch scheduling che minimizza il rischio ICT per il sistema. Il metodo permette di superare valutazioni parziali e spesso non consistenti come quelle che utilizzano penetration test o uno scoring delle vulnerabilità basato su attributi ed indipendenti dal sistema. Minimizzando il numero di vulnerabilità su cui intervenire, il metodo bpa garantisce un aumento sostanziale del ritorno dell’investimento in sicurezza di una organizzazione. Sono ovviamente possibili ulteriori ottimizzazioni del metodo bpa ma i suoi vantaggi sono evidenti anche nella nostra analisi preliminare.
