Le squadre blue conoscono bene lo stress del difensore: “troppi eventi in troppo poco tempo”.
Il tempo di reazione è una chiave interpretativa della qualità di un servizio di difesa; ma perché possa essere valutato il tempo di reazione, il tempo di azione della minaccia deve essere sufficientemente dilatato da consentire il tempo di intercettazione, comprensione, ed infine di reazione.
Dal punto di vista della prevenzione, invece, il tempo può essere considerato in relazione alla conoscenza dell’esistenza di una vulnerabilità e alla costatazione della sua presenza nel perimetro (Vulnerability Identification), al fine di misurare poi il tempo necessario a che la vulnerabilità sia sanata (Remediation), ammesso che sia già noto un metodo. L’urgenza dell’intervento correttivo è un ulteriore parametro in gioco (nel momento che esistano soluzioni) nella realizzazione di un “Remediation Plan”, in quanto il tempo a disposizione per risolvere è comune a tutte le problematiche, pertanto per avvicinare il momento che sani la vulnerabilità più insidiosa occorre fare delle scelte. Queste scelte ricadono nel concetto di priorità delle vulnerabilità (vulnerability prioritization), ed è un parametro complesso da valutare perché legato non solo alla gravità tecnica della vulnerabilità, ma anche al rischio (che è spesso legato al business aziendale, ma anche a fattori oggettivi quali la presenza di un PoC, la visibilità in natura degli attacchi a tale vulnerabilità).
Tutto ruota dunque intorno a due fondamentali: la definizione di una vulnerabilità (CVE) e l’attribuzione di una sua gravità (CVSS).
Il problema è che spesso ci troviamo di fronte a situazioni in cui il tempo disponibile si riduce in maniera incredibile. Questo anno abbiamo avuto, come nei precedenti, molteplici identificazioni di vulnerabilità 0-Day e tra queste alcune di tipo 0-click e addirittura già protagoniste di attacchi in natura.
Ricordiamone qualcuna: CVE-2022-1096 (Google JavaScript V8 Chrome engine), CVE-2022-0847 (Dirty Pipe su Kernel Linux 5.8), CVE-2022-26809 (0-click RCE su RPC di Microsoft), ecc.
In queste circostanze il rilevamento di 0-day porta l’urgenza di una soluzione a livelli altissimi, che aumentano quando queste minacce siano già state viste sfruttate in natura o anche solo in quanto esistano delle implementazioni o PoC per il loro sfruttamento. In questo caso contro la difesa vengono poste anche altre due questioni “temporali”: dal punto di vista analitico, non sempre sono disponibili dettagli tecnici dell’attacco, del suo procedere e delle eventuali soluzioni (i vendor sono ancora all’opera per realizzare i correttivi), e nel frattempo anche la quantificazione della gravità potrebbe tardare ad arrivare o essere del tutto inutile.
È ciò che vediamo quando ricerchiamo dettagli su certe vulnerabilità, quando i dettagli scarseggiano o addirittura non sia stato assegnato un CVE e un CVSS. Ma in questo ultimo caso abbiamo anche il paradosso per cui, pur avendone una definizione, spesso ci troviamo di fronte a molte vulnerabilità tutte “tecnicamente” gravissime, cosa che annulla ogni possibile differenza per sviluppare un piano di intervento guidato dalla priorità.
In questo buio di informazioni è naturale avere difficoltà nel produrre una priorità di interventi difensivi, anche fossero solo degli espedienti per sopportare un eventuale attacco senza incorrere nello sfruttamento della vulnerabilità ancora non sanata.
Identificare l’esistenza di una vulnerabilità è dunque solo l’inizio di un intervento a tutela del perimetro: in questo caso è opportuno arrivare prima possibile, pertanto può risultare strategicamente fondamentale ottenere dai propri strumenti diagnostici una autonomia “predittiva” sul rischio di certe vulnerabilità, indipendentemente da quanto possa essere divulgato da fonti aperte come l’NVD del NIST, così da ottenere parametri oggettivi per consentire di costruire una priorità di intervento che, al dunque, sanando o mitigando le vulnerabilità più rischiose, porti ad una più evoluta sicurezza dell’infrastruttura.