Predire in modo accurato gli attacchi contro un sistema
Si possono definire due approcci, quello predittivo e quello reattivo, per la difesa di un sistema rispetto ad attaccanti intelligenti e con obiettivi predefiniti.
Parliamo di un approccio reattivo quando la sicurezza è basata sulla capacità del sistema di scoprire qualsiasi attacco contro il sistema per fermare gli attaccanti prima che essi raggiungano il loro obiettivo. Un approccio predittivo analizza il sistema da proteggere per scoprire e fermare quelli che permettono agli attaccanti di raggiungere i loro obiettivi. E’ possibile fermare gli attaccanti perché essi utilizzano una privilege escalation mediante una catene di attacchi, o chained exploit. Per fermare una catena basta bloccare uno qualsiasi degli attacchi che la compongono.
Tipicamente una strategia reattiva cerca di bloccare le catene introducendo nel sistema da difendere alcuni strumenti per la rilevazione d’intrusioni che monitorano il sistema e, scoperta un’intrusione, modificano le regole di filtraggio di uno o più firewall per impedire all’attaccante di interagire con il sistema prima che possa completare la sua catena.
La definizione di una strategia predittiva richiede la disponibilità di uno storico sugli attacchi che sono stati tentati contro sistemi simili a quello da difendere. I dati nello storico vengono utilizzati per stabilire le “firme” dei possibili attacchi che potrebbero essere tentati contro il sistema da difendere. Il monitoraggio deve scoprire le firme degli attacchi nei flussi d’informazioni del sistema.
Ovvio vantaggio di un approccio reattivo è la possibilità di aggiungere la sicurezza a posteriori, solo se e quando essa è ritenuta necessaria. L’altrettanto ovvio svantaggio è che la sua efficacia dipende dall’accuratezza del monitoraggio e dalla conoscenza di tutti gli attacchi che possono essere eseguiti. Il livello di sicurezza che un approccio reattivo garantisce può ad esempio diminuire ogni volta che aumentano prestazioni della struttura di interconnessione del sistema poiché aumenta la probabilità che il sistema di monitoraggio non riesca a raccogliere ed analizzare una parte di un flusso di informazioni. La mancanza d’informazioni sugli attacchi e sulle catene che permettono agli attaccanti di raggiungere i loro obiettivi non permette di focalizzare il monitoraggio sugli attacchi d’interesse e costringe a sovradimensionare le risorse da utilizzare.
Consideriamo due attaccanti che tentano di violare il sistema mostrato in Fig.1 dove ogni cerchio rappresenta un passo di un attacco. La catena implementata dal primo attaccante, rappresentata dalla freccia rossa, inizia con l’inserimento di una chiavetta USB contenente un malware in un client VPN, utilizzato per connettersi in remoto all’infrastruttura. L’attacco iniziale della seconda catena, rappresentata dalla freccia gialla, sfrutta una vulnerabilità del firewall esposto su Internet. I due attaccanti hanno due obiettivi diversi: il primo vuole compromettere l’intero sistema di smart metering, il secondo vuole prendere il controllo del nodo che invia comandi ai PLC situati nella rete di controllo. In questo caso, una strategia reattiva deve monitorare tutte le sottoreti perché non dispone di informazioni sugli attacchi e sulle catene degli attaccanti. La disponibilità di queste informazioni riduce fortemente le risorse richieste dal monitoraggio perché le due catene possono essere bloccate conoscendo le firme di un attacco per ogni catena. Ad esempio, è sufficiente monitorare le comunicazioni tra il VPN ed il firewall, per scoprire un attacco della prima catena. Monitorando il flusso tra il firewall e la stazione di controllo si scopre invece un attacco della seconda catena. Le vulnerabilità 0-day sono estremamente critiche per un approccio reattivo. Infatti, il sistema è totalmente indifeso contro gli attacchi che non sono noti perché non è in grado di scoprirli e fermarli.
L’approccio predittivo è basato su un’analisi preliminare di un sistema, auspicabilmente in fase di progetto, per scoprire tutte le informazioni utili per difenderlo. Tipicamente, queste informazioni comprendono le vulnerabilità, gli attacchi che esse abilitano ed i danni causati. Scoperti i possibili attacchi, un approccio predittivo stabilisce, se possibile, un insieme di modifiche al sistema, o contromisure, in modo da eliminare i difetti che permettono i passi in una catena di attacco. Solo se alcuni difetti non possono essere eliminati, s’introduce un monitoraggio del sistema per scoprire gli attacchi nelle catene che gli attaccanti utilizzano e per intervenire in modo reattivo. Ovviamente, il monitoraggio è focalizzato sulle catene abilitate dalle vulnerabilità del sistema ed utili per gli attaccanti. Il principale vantaggio di un approccio predittivo è la capacità di sfruttare le informazioni sul sistema per scegliere la contromisura più efficace e conveniente in un insieme che comprende, ad esempio, il patch di una vulnerabilità, la modifica della configurazione o della politica di sicurezza o anche una diversa allocazione dei vari moduli software sui nodi del sistema. L’eliminazione di alcune vulnerabilità riduce fortemente il numero di attacchi e quindi delle catene che il monitoraggio deve considerare ed aumenta in modo rilevante la robustezza del sistema.
Un approccio predittivo è meno sensibile ad una vulnerabilità 0- day, perché l’analisi può ipotizzare in alcuni componenti la presenza di vulnerabilità non ancora note in grado di permettere, se sfruttate da un attaccante, di controllare questi componenti. Tali vulnerabilità possono essere gestite bloccando le catene che contengono gli attacchi, abilitati da queste vulnerabilità, prima che possano essere sfruttate.
Un punto critico per un approccio predittivo è la capacità di scoprire tutti i possibili difetti e tutti gli attacchi che possono comparire nelle catene degli attaccanti. Per approfondire questo punto consideriamo che, come abbiamo discusso nei nostri precedenti articoli, molte catene siano tra loro equivalenti, ovvero sono catene alternative che un attaccante ha a disposizione per ottenere uno stesso insieme di diritti. Consideriamo, ad esempio, un attaccante che voglia controllare un certo database per leggerne o alterarne i dati. Un primo attacco della catena corrispondente potrebbe essere abilitato da alcune vulnerabilità del sistema operativo.
In questo caso, l’attaccante implementa una catena che gli permetta di diventare amministratore del nodo che ospita il database. Raggiungendo quest’obiettivo, l’attaccante controlla tutte le risorse del nodo ed, in particolare, il database. Un attacco completamente diverso è quello che ha come obiettivo un’interfaccia web che permette ad utenti remoti di accedere al database. In questo caso, il primo attacco di una catena sfrutta una vulnerabilità web, tipicamente una SQL injection, per ottenere il diritto di leggere e/o modificare il database.
È quindi fondamentale per un sistema predittivo la capacità di analizzare vulnerabilità a diversi livelli d’implementazione e di scoprire catene che sfruttino vulnerabilità a livelli diversi. Questo vincolo è semplice da soddisfare per componenti off-the-shelf a larga diffusione, perché esistono numerosi database che elencano le vulnerabilità pubbliche delle varie applicazioni software e dei vari sistemi operativi. Nell’esempio precedente, non è quindi difficile scoprire se nel sistema operativo considerato esistono uno o più vulnerabilità che permettano di costruire una catena di attacchi per diventare amministratore. Il problema diventa più complesso per la vulnerabilità che permette la SQL injection perché non esiste un database standard al quale far riferimento per scoprirne le firme. Di conseguenza, è necessario utilizzare degli scanner web che ricerchino le vulnerabilità tramite alcuni tentativi eseguiti sull’interfaccia web. IBM Security AppScan ed Owasp Zap sono noti scanner che possiamo utilizzare per questo scopo. Se abbiamo a disposizione anche il codice sorgente dell’applicazione web, possiamo eseguire un’analisi più completa che integri il risultato dello scanning precedente con un’analisi statica che scopra eventuali difetti del codice ed ulteriori vulnerabilità. Esistono numerosi strumenti che sono in grado di eseguire quest’analisi.
La complessità dell’analisi e la preferenza data all’approccio reattivo non hanno incoraggiato la produzione di strumenti open-source e quindi gli strumenti più accurati sono proprietari e non economici. Il ritorno sull’investimento richiesto resta comunque elevato visto il forte risparmio sugli strumenti di monitoraggio in tempo reale. Inoltre, il controllo a priori su eventuali vulnerabilità riduce il tempo di debugging e fornisce una valutazione affidabile della qualità del codice sviluppato.
Il passo successivo all’analisi delle vulnerabilità nei vari componenti e degli attacchi che esse abilitano deve individuare tutti diritti che ogni attacco concede. Quest’analisi è fondamentale per la scoperta delle catene e deve considerare le relazioni tra i vari componenti. Abbiamo una relazione strutturale da un componente C1, la sorgente, ad un componente C2, la destinazione, quando l’implementazione delle funzionalità di C2 utilizza le funzioni definite da C1. Tipica dipendenza strutturale è quella tra il sistema operativo ed un’applicazione o tra un hypervisor e le macchine virtuali che esso gestisce. Le relazioni strutturali tra componenti possono essere dedotte a partire dalla loro allocazione. Ad esempio, è relativa mente semplice scoprire la relazione strutturale tra un sistema operativo ed un servizio che esso espone sfruttando gli indirizzi di rete e le porte logiche utilizzate. Le dipendenze strutturali sono importanti perché controllare il componente di più basso livello, C1, equivale a controllare anche ogni componente in relazione strutturale con C2. La relazione strutturale è tipicamente antisimmetrica vista la gerarchia funzionale esistente in un sistema. Tra una sorgente C1 ed una destinazione C2 esiste, invece, una relazione funzionale ogni volta che C1 interagisce esplicitamente con C2. Tipica relazione funzionale è quella tra un client ed un server, oppure tra due componenti in una relazione alla pari. Se esiste una relazione funzionale da C1 a C2 allora controllando C1 è possibile sfruttare le operazioni invocate su C2. Nel nostro esempio precedente, controllando l’interfaccia web è possibile accedere in scrittura e lettura al database purché si inviino le opportune richieste al gestore del database. L’esistenza di una relazione funzionale da C1 a C2 può coesistere con una diversa relazione funzionale da C2 a C1. Questa situazione è tipica ad esempio di sistemi paralleli o peer-to-peer. Le relazioni funzionali possono essere dedotte da informazioni sul flusso dei dati tra i componenti.
L’analisi delle relazioni strutturali e funzionali deve essere integrata perché vale la transitività, e quindi, ottenuto il controllo di un componente C grazie ad una certa relazione, si ottiene anche quello dei componenti che sono destinazione delle relazioni che hanno C come sorgente. La chiusura transitiva di tutte le relazioni permette di scoprire tutti i diritti che possono essere ottenuti da un attacco, in particolare da quegli attacchi che permettono il controllo di un componente. Ciò aumenta l’accuratezza dell’analisi del sistema che è alla base di ogni metodo predittivo. Per valutare in modo più esatto l’aumento di accuratezza, abbiamo esteso la suite Haruspex2 per tener conto delle relazioni strutturali e funzionali nella descrizione dei diritti che un attacco concede a chi lo esegue con successo. Il modello risultante del sistema da analizzare è molto flessibile perché in grado di associare ad ogni relazione strutturale o funzionale coppie di diritti, uno sul componente sorgente ed uno su quello destinazione. Il possesso del diritto sul componente sorgente garantisce automaticamente quello sul componente destinazione. Questa flessibilità è necessaria per tener conto di livelli multipli di autorizzazione. Ad esempio, il controllo di un’interfaccia web potrebbe garantire l’accesso ad un certo database, ma questo database potrebbe essere criptato, oppure l’accesso in scrittura potrebbe richiedere ulteriori autorizzazioni.
Determinati i diritti che ogni attacco concede, la suite scopre le varie catene degli attaccanti e le loro probabilità di successo come già discusso, applicando il metodo Monte Carlo.
Per valutare l’aumento di accuratezza permesso da un analisi che consideri anche le relazioni, abbiamo applicato la nuova versione della suite per valutare il rischio ICT di un sistema di smart metering. In particolare, abbiamo incluso nel perimetro del sistema da analizzare un sistema web che permette agli utenti di accedere ad un database che contiene, tra le altre, informazioni sul loro consumo e sulla fatturazione dei relativi costi. La suite Haruspex applica il metodo Monte Carlo ad uno scenario con due attaccanti: un utente che desidera “ritoccare” la propria fattura ed un competitor che cerca di ottenere informazioni sull’infrastruttura complessiva e sulla gestione degli smart meter. Il numero delle diverse catene che ognuno dei due attaccanti può scegliere per controllare le componenti di suo interesse aumenta di circa il 20% quando si considerano anche le vulnerabilità web e di circa il 50% quando si considerano anche le relazioni strutturali e funzionali.
La variazione è quindi estremamente significativa e dimostra come l’aumento di complessità dell’analisi e del modello del sistema che si costruisce, sia ampiamente compensato dalla migliore accuratezza dei risultati ottenuti. Quest’accuratezza è critica per un approccio predittivo perché l’analisi che sta alla base del metodo non può trascurare nessuno degli attacchi e nemmeno modellare in modo non accurato i loro effetti. Come già detto, la conoscenza delle informazioni su attacchi e catene permette di scegliere al meglio le contromisure da applicare e riduce i rischi dovuti ad un approccio reattivo.
Per valutare l’aumento di accuratezza ottenuto tramite un’analisi che considera anche le relazioni, abbiamo applicato la nuova versione della suite per valutare il rischio ICT di un sistema di smart metering. In particolare, abbiamo incluso nel perimetro del sistema da analizzare un sistema web che permette agli utenti di accedere ad un database che contiene, tra le altre, informazioni sul loro consumo e sulla fatturazione dei relativi costi.
La suite Haruspex applica il metodo Monte Carlo ad uno scenario con due attaccanti: un utente che desidera “ritoccare” la propria fattura od un competitor che cerca di ottenere informazioni sull’infrastruttura complessiva e sulla gestione degli smart meter. Il numero delle diverse catene che ognuno dei due attaccanti può scegliere per controllare le componenti di suo interesse aumenta di circa il 20% quando si considerano anche le vulnerabilità web e di circa il 50% quando si considerano anche le relazioni strutturali e funzionali. La variazione è quindi estremamente significativa e dimostra come l’aumento di complessità dell’analisi e del modello del sistema che si costruisce, sia ampiamente compensato dalla migliore accuratezza dei risultati ottenuti.
Quest’accuratezza è critica per un approccio predittivo perché l’analisi che sta alla base del metodo non può trascurare nessuno degli attacchi o modellare in modo non accurato i loro effetti. Come già detto, la conoscenza delle informazioni su attacchi e catene permette di scegliere al meglio le contromisure da applicare e riduce i rischi dovuti ad un approccio reattivo.
A cura di: Fabrizio Baiardi, Lorenzo Isoni, Federico Tonelli, Dipartimento di Informatica, Università di Pisa, Italia
Articolo pubblicato sulla rivista ICT Security – Novembre/Dicembre 2015
Full Professor, Università di Pisa
E' attualmente è professore ordinario di Informatica presso l'Università di Pisa dove coordina il gruppo di ricerca su ICT risk assessment and management. La sua attività di ricerca è focalizzata su strumenti e metodi formali l'automazione dell'analisi e la gestione del rischio.
F.Tonelli ha ricevuto il dottorato in Informatica nell’Aprile del 2017 dall'Università di Pisa.
In precedenza, ha ottenuto una laurea in Informatica ed una magistrale con lode in Sicurezza Informatica dalla stessa università. Successivamente, ha vinto una borsa di studio finanziata da Enel Ingegneria e Servizi sulla ricerca di vulnerabilità in sistemi SCADA.
