La natura sempre più dinamica dei sistemi e la continua scoperta di nuove vulnerabilità di cyber security non può essere affrontata con assessment periodici con bassa o bassissima frequenza. La soluzione può venire dal continuous assessment: approfondiamo questa nozione e vediamo la sua possibile implementazione mediante un metodo basato sulla scoperta ed interruzione dei percorsi di attacco.
L’assessment su percorsi d’attacco
Un risk assessment che scopra i percorsi di attacco contro un sistema presenta diversi vantaggi. Un percorso di attacco è una sequenza di attacchi, movimenti laterali secondo altre terminologie, che permette ad un attaccante di ampliare i suoi diritti fino a raggiungere i suoi obiettivi. La simulazione ripetuta del comportamento degli attaccanti e del sistema permette di scoprire tutti i percorsi d’attacco che gli attaccanti possono usare contro il sistema. Partendo dalla conoscenza dei percorsi, si può implementare una strategia che calcola un patch scheduling selezionando il più piccolo insieme di patch che elimini almeno una vulnerabilità per ogni percorso. Questo insieme di patch elimina almeno un attacco per ogni percorso e, di conseguenza, blocca tutti i percorsi. Il principale vantaggio della strategia proposta è quello di minimizzare il tempo per rimediare alle varie vulnerabilità e bloccare gli attaccanti. Adottando le strategie di patching correnti il tempo è tale da mettere a rischio la sicurezza di un sistema.
Questo articolo introduce ed illustra altre potenzialità di un assessment basato su modello e su percorsi di attacco, in particolare la capacità di eseguire un assessment continuo e calcolare un patch scheduling senza disturbare il sistema target. Nel seguito illustreremo sia i benefici di un assessment continuo che i vantaggi offerti da un assessment continuo basato su modello.
Un modello è descrizione finita e formale che rappresenta un sottoinsieme stretto delle informazioni di un sistema. Poiché rappresenta un sottoinsieme stretto delle informazioni su un sistema, ogni modello astrae sempre, e quindi trascura, alcune informazioni. Questa è la ragione per cui ogni modello è sbagliato e utile per risolvere solo alcuni problemi, quelli che usano le informazioni che il modello rappresenta. Se ogni modello è parziale, esistono alcune analisi che possono essere compiute solo sul modello e non sul sistema reale. Quindi la scelta tra l’uso del modello o il lavoro sul sistema reale non è libera ma è strettamente dipendente dal problema di interesse. In particolare, sistemi i cui risultati dipendono da distribuzioni di probabilità sconosciute possono solo essere analizzati lavorando sul sistema e non sul modello. Questo è sostanzialmente il caso di ogni sistema informatico che abbia una complessità non banale..
Fig. 1 Tempo medio di applicazione di un patch dopo la scoperta di una vulnerabilità
Continuous assessment mediante un modello
La valutazione e la gestione del rischio di un sistema ICT deve individuare le vulnerabilità di un sistema e calcolare un insieme di contromisure o controlli compensativi da applicare per impedire, o minimizzare la probabilità che, un insieme di attaccanti, umani o malware, raggiunga alcuni obiettivi. Nel seguito assumeremo che questo assessment utilizzi il metodo di individuare dei percorsi d’attacco e blocchi almeno un attacco per ogni percorso. Vi sono diversi motivi per ripetere questo assessment, che discutiamo nel seguito insieme ai meccanismi che rilevano la necessità di un assessment.
I motivi per ripetere un assessment possono essere classificati in endogeni o esogeni. Il principale motivo endogeno per ripetere un assessment è un cambiamento del sistema quale, ad esempio, una variazione del numero di nodi di elaborazione o routing o nelle applicazioni che ogni nodo esegue. Il cambiamento esogeno è invece dovuto alla scoperta di nuove vulnerabilità nei moduli, hardware o software del sistema oppure dalla modifica ai modelli degli attaccanti dovuti al presentarsi di nuovi malware o ransomware.
Cambiamenti endogeni
L’introduzione di nuovi nodi di elaborazione e routing o l’introduzione di nuovi moduli software provoca un aumento del numero di vulnerabilità nel sistema e, di conseguenza può portare alla creazione di nuovi percorsi di attacco. Notiamo che un cambiamento nella topologia logica di un sistema può essere dovuto a nuove regole per il routing del traffico di rete o a nuove configurazione dei firewall già esistenti. Cambiamenti endogeni possono essere legali oppure violare la politica di sicurezza del sistema. Dopo ogni cambiamento endogeno, il calcolo dei percorsi d’attacco deve essere ripetuto dopo aver aggiornato il modello del sistema. In questo caso, per raccogliere le informazioni necessarie per aggiornare il modello è necessario eseguire uno scanning che rilevi la configurazione dei nuovi nodi aggiunti al sistema e quella delle configurazioni. L’esecuzione di uno scanning può anche scoprire se nodi sono stati disconnessi dal sistema.
Il metodo più semplice per fondere la rilevazione di cambiamenti del sistema e la raccolta delle informazioni necessarie per aggiornare il modello è quello di utilizzare uno scanning passivo. Sostanzialmente uno scanner passivo è un nodo che sniffa i pacchetti che transitano nella rete e li matcha con una o più signature per dedurre informazioni sula configurazione dei due nodi coinvolti nella comunicazione. Tipicamente, questo tipo di scanning restituisce informazioni accurate solo esaminando un grande numero di pacchetti ma raccogliere questi pacchetti non è un problema visto che questa attività non disturba in alcun modo il sistema stesso. Inoltre, in questo caso la perdita di un pacchetto è totalmente accettabile a differenza della rilevazione di intrusioni. Più complessa è la raccolta di informazioni sulla topologia. Esistono algoritmi distribuiti per raccogliere informazioni sulla topologia a partire dallo scambio di messaggi predefiniti tra un insieme di sensori opportunamente allocati. Il carico complessivo che questi algoritmi impongono al traffico di rete è non nullo ma comunque molto limitato rispetto al traffico reale. La loro esecuzione periodica è quindi del tutto accettabile per quanto riguarda le prestazioni della struttura di interconnessione del sistema.
Il problema della ricostruzione dei nuovi nodi di elaborazione e routing e della nuova topologia è molto semplificato se già esiste un inventario del sistema. Infatti, in questo caso è sufficiente accedervi e costruire una diff list da utilizzare poi per aggiornare il modello. Purtroppo, l’esistenza di questo inventario non è molto comune. Il numero di contromisure da applicare per reagire a modifiche endogene può essere molto grande. Infatti l’aggiunta anche di un solo nodo può permettere di collegare reti che prima erano separate e quindi permettere di collegare parti di percorsi d’attacco che erano prima separate. Non è quindi facile stimare a priori il numero di percorsi che si vanno a creare e che dovranno essere interrotti. Un effetto collaterale interessante della scoperta dei nuovi percorsi è proprio una valutazione delle possibili ripercussioni delle modifiche al sistema sulla sicurezza del sistema stesso. Ovviamente, è possibile sfruttare le capacità predittive e valutare le ripercussioni sulla sicurezza di una modifica aggiornando il modello e studiando i percorsi d’attacco prima di applicare la modifica.
Cambiamenti esogeni
I cambiamenti esogeni dovuti alla scoperta di nuove vulnerabilità o di nuovi attaccanti sono scorrelati dalla politica di sicurezza di un sistema perché non sono dovuti alle attività dei vari utenti o degli ammistratori del sistema stesso. La gestione di un cambiamento esogeno dovuto alla scoperta di nuove vulnerabilità è molto più semplice di quello endogeno. Infatti è sufficiente estendere le vulnerabilità di ogni modulo con quelle scoperte e quindi simulare nuovamente il comportamento degli attaccanti per individuare ed interrompere ogni nuovo percorso d’attacco. Notiamo come le contromisure da introdurre non devono necessariamente coinvolgere le nuove vulnerabilità scoperte. Infatti, il metodo basato sui percorsi d’attacco e sulle vulnerabilità condivise tra i percorsi può selezionare contromisure per vulnerabilità già presenti nel sistema e che non erano state interrotte in precedenza. Ovviamente l’obiettivo resta sempre quello di minimizzare il numero di contromisure da applicare.
La probabilità che un cambiamento esogeno generi nuovi percorsi è bassa. Infatti il numero di vulnerabilità che vengono scoperte è percentualmente basso rispetto a quello delle vulnerabilità complessive e quindi bassa è la probabilità che una delle nuove vulnerabilità possa sostituire nei percorsi una delle vulnerabilità già eliminate. La probabilità aumenta con il numero di vulnerabilità e che si vanno ad aggiungere a quelle già analizzate. Mentre l’analisi delle nuove vulnerabilità scoperte avviene fondamentalmente in momenti prefissati, come patch Tuesday, vi sono casi come la scoperta di una vulnerabilità estremamente critica che richiedono una analisi immediata per individuare eventuali contromisure da applicare. Nel caso di una vulnerabilità critica viene simulato il comportamento degli stessi attaccanti utilizzando il modello del sistema in cui è stata introdotta la nuova vulnerabilità.
Anche la comparsa di un nuovo attaccante, di una nuova tecnica di attacco o l’apparizione di un worm che sfrutta un particolare sottoinsieme di vulnerabilità richiedono una analisi immediata per verificare se esistono percorsi che questi nuovi attaccanti possono utilizzare. La simulazione utilizza i modelli dei nuovi attaccanti e lo stesso modello del sistema. Nel caso di cambiamenti esogeni, la modifica del modello con le nuove vulnerabilità e/o dei nuovi attaccanti e le simulazioni per scoprire i percorsi e le contromisure da adottare può essere eseguita in parallelo al normale funzionamento del sistema target utilizzando risorse hardware e software diverse da quelle del sistema stesso. Ciò permette di introdurre un servizio di assessment veramente continuo che opera in modo del tutto parallelo e scorrelato dal sistema target per fornire, periodicamente o immediamente, l’insieme delle patch da applicare per bloccare i nuovi percorsi d’attacco. Se il servizio deve coprire cambiamenti esogeni ed endogeni, il sistema dedicato all’assessment continuo deve ricevere le informazioni dei sensori per la rilevazione dei cambiamenti endogeni per attivare immediamente il calcolo dei percorsi e di eventuali patch da applicare.
Patch Scheduling senza patch
Un ultimo caso da considerare nel caso di cambiamenti endogeni è quello delle vulnerabilità per Molte delle vulnerabilità dei moduli possono non essere rimediabili perchè non esistono controlli compensativi o patch. Ad esempio, secondo Risk Based Security, il numero delle nuove vulnerabilità del software identificate nella prima metà del 2019 mostra una numerosità comparabile a quella del 2018. La società descrive nel report 2019 Mid-Year QuickView Vulnerability Report, alcuni trend importanti, ad esempio che il 34% delle vulnerabilità individuate, più di 10.000, non ha una soluzione, quindi non può essere “patchata. Il metodo dei percorsi di attacchi permette di risolvere anche il problema della mancanza di patch applicando quelle, esistenti, per vulnerabilità che nel percorso sono sfruttate prima o dopo della vulnerabilità per cui non esistono patch. L’assenza di rimedi per una vulnerabilità può aumentare il costo nel momento in cui essa è lunica condivisa tra molti percorsi di attacco ed occorre agire su più vulnerabilità in percorsi diversi.
Altre soluzioni per un continuous assessment
Attualmente, la più popolare soluzione per un assessment continuo è quella che utilizza strumenti di breach and attack simulation. Questi strumenti vanno installati su uno più nodi ed eseguono le azioni di un vero attaccante ovvero analizzano i nodi di elaborazione per scoprire eventuali vulnerabilità e le sfruttano per implementare un attacco e per diffondersi su altri nodi. Il principale vantaggio di questi strumenti è che essi permettono di ottenere informazioni molto accurate sulle vulnerabilità dei vari moduli. Questo indubbio vantaggio è fortemente mitigato da due problemi non banali. Il primo è il rumore che gli strumenti generano. Poiché gli attacchi avvengono realmente, sono possibili impatti sui nodi coinvolti e, se gli strumenti non sono opportunamente configurati, questi impatti sono assolutamente non banali. Quindi è fondamentale una accurata configurazione degli algoritmi di decisione che guidano questi strumenti per evitare di perdere il controllo di un strumenti che si muovono liberamente nel sistema che dovrebbero proteggere. Questo è un problema da considerare attentamente nel caso di un sistema di controllo industriale dove gli strumenti possono provocare problemi di sicurezza e di safety non banali a cose o persone. Gli stessi fornitori di questi strumenti parlano, correttamente, di rischio limitato o inferiore a quello di un attacco reale ma nessuno si azzarda a definire nullo il rischio associato all’adozione degli strumenti.
Il secondo problema è che comunque gli strumenti non sono in grado di restituire un ranking delle varie vulnerabilità e non garantiscono la scoperta di tutti i percorsi di attacco. Infatti, stiamo comunque parlando di un penetration test automatizzato che però non può essere ripetuto un numero di volte sufficiente per garantire la scoperta di tutti i percorsi d’attacco. L’unico vantaggio sicuramente offerto da questi sistemi è quindi la mancanza di falsi positivi, ovvero la garanzia che le vulnerabilità segnalate esistono effettivamente. La capacità del metodo basato su attacchi di operare su percorsi e di sfruttare vulnerabilità condivise permette comunque di ridurre fortemente il costo di un falso positivo e di ridurlo ad un livello molto inferiore a quello dei potenziali danni generati da uno strumento di breach and attack simulation non correttamente configurato.
