Numerose organizzazioni hanno adottato una gestione delle vulnerabilità basata sul rischio come componente fondamentale del proprio programma di sicurezza informatica, andando oltre la semplice valutazione basata esclusivamente sul CVSS per sviluppare modelli di definizione delle priorità e investire in fonti di intelligence sulle minacce informatiche, scanner e flussi di lavoro per la correzione delle vulnerabilità . Tuttavia, le code di correzione spesso rimangono inattuabili, i punteggi di rischio faticano a ottenere credibilità presso il reparto IT e i team continuano ad avere difficoltà a dimostrare alla dirigenza una riduzione misurabile del rischio.
Questo articolo illustra come colmare ogni lacuna, dall’infrastruttura di copertura ai modelli di valutazione, passando per l’allineamento tra i team e gli indicatori chiave di prestazione (KPI) che dimostrano che il vostro programma sta riducendo il rischio, affinché il vostro team possa stare al passo con le minacce che la vostra organizzazione deve affrontare oggi.
Perché la maggior parte dei programmi RBVM si arena prima di poter essere estesi su larga scala
Le organizzazioni che stanno passando da approcci tradizionali alla gestione delle vulnerabilità spesso mantengono le stesse debolezze che RBVM è stato progettato per superare: visibilità incompleta delle risorse, risultati non convalidati degli scanner e passaggi di consegne poco chiari tra il reparto sicurezza e quello operativo IT. Eppure, la maggior parte dei team ritiene che comprendere i principi della definizione delle priorità basata sul rischio sia la parte più semplice. È proprio nell’applicarle in modo coerente in tutti gli ambienti aziendali che emergono ulteriori sfide.
Il concetto è semplice. È proprio durante l'esecuzione che i programmi presentano dei problemi.
Tre lacune infrastrutturali spiegano la maggior parte dei fallimenti dell’RBVM:
- Visibilità incompleta delle risorse : I punteggi Risk calcolati sulla base di dati parziali relativi alle vulnerabilità garantiscono una protezione parziale. Se gli endpoint non sono gestiti, non vengono sottoposti a scansione o restituiscono dati non aggiornati, la coda dei rischi presenta un punto cieco che nessun modello di prioritizzazione è in grado di colmare.
- Risultati dello scanner non convalidati: I risultati dello scanner non equivalgono a un’esposizione confermata. In contesti caratterizzati da dati di scansione obsoleti o da una scarsa gestione delle risorse, i tassi di falsi positivi possono raggiungere livelli tali da indurre il personale IT a perdere fiducia nella coda delle segnalazioni, con conseguente rallentamento generale dei tempi di risposta.
- Assenza di un modello di trasferimento controllato: Security provvede all’identificazione e alla definizione delle priorità. Il reparto operativo IT provvede alla risoluzione dei problemi. In assenza di una chiara attribuzione delle responsabilità, di SLA basati sul livello di rischio e di una gestione delle eccezioni, i risultati si accumulano in un limbo.
Il requisito di copertura
L'accuratezza dei punteggi relativi ai rischi informatici dipende interamente dall'accuratezza dell'inventario delle risorse e dei dati sullo stato di sicurezza endpoint su cui vengono calcolati. La copertura non si misura solo in base al numero di attività. Dipende dal fatto che la loro configurazione più recente, lo stato delle patch e il livello di esposizione siano costantemente noti. In assenza di ciò, i modelli di definizione delle priorità operano sulla base di una rappresentazione incompleta del rischio.
Laddove si verificano lacune nella copertura
Gli ambienti aziendali generano lacune nella copertura in punti prevedibili. I dispositivi non gestiti, i computer portatili degli appaltatori, i dispositivi mobili, i container, le risorse OT e ICS, i dispositivi IoT, lo “shadow IT” e gli endpoint dotati di agenti obsoleti o che non inviano report non rientrano tutti nella scansione standard.
Le risorse OT e ICS richiedono una strategia di copertura diversa. Molti non sono in grado di supportare gli agenti tradizionali, la scansione aggressiva comporta il rischio di interruzioni operative ed è frequente che si riscontri software obsoleto per il quale non sono disponibili patch. Per tali risorse, i controlli compensativi diventano la principale leva di riduzione del rischio, non le misure correttive, e la pianificazione della copertura dovrebbe tenerne conto sin dall’inizio.
Gli ambienti di sviluppo presentano un punto cieco analogo: le vulnerabilità introdotte tramite le pipeline CI/CD di DevOps spesso non vengono individuate fino a quando non raggiungono l’ambiente di produzione, dove la loro risoluzione comporta un impatto molto più significativo.
Una vulnerabilità rilevata su 200 endpoint gestiti potrebbe essere presente anche su 50 dispositivi non gestiti che non vengono mai inseriti nella coda dei rischi. L'immagine sembra completa, ma l'esposizione effettiva è più ampia di quanto sia visibile.
Perché il ritardo di scansione compromette il punteggio
Le scansioni periodiche generano risultati di valutazione che riflettono una situazione passata, non l’attuale superficie di attacco. In contesti dinamici in cui i cicli di applicazione delle patch, le implementazioni e le modifiche alla configurazione avvengono continuamente, anche un breve ritardo nella scansione può comportare che il punteggio di rischio non rifletta più l’esposizione effettiva.
La visibilità in tempo reale su endpoint riduce il ritardo causato dalle scansioni periodiche, fornendo una base più accurata per il calcolo dei punteggi di rischio. Le piattaforme progettate per il monitoraggio continuo forniscono dati telemetrici endpoint aggiornati frequentemente, in modo che le decisioni relative alle priorità riflettano le condizioni effettive anziché un’istantanea risalente a giorni prima.
Asset La visibilità non è un progetto una tantum. È una disciplina che richiede impegno costante. Senza di esso, anche il modello di valutazione più sofisticato produce classifiche che non tengono conto delle reali condizioni di rischio.
Una volta garantita la visibilità in tempo reale, la domanda successiva è: come si definisce un punteggio di rischio di cui i team possano fidarsi?
Come vengono effettivamente calcolati i punteggi di rischio
Un punteggio di rischio di cui nessuno si fida è peggio che non avere alcun punteggio. Una valutazione efficace dei rischi parte da una metodologia chiara e trasparente, in cui i fattori di input, i pesi e la logica di attribuzione dei punteggi siano compresi sia dal team di sicurezza che da quello delle operazioni IT. Per instaurare un clima di fiducia è necessario che sia chiaro in che modo tali dati e pesi si combinino per determinare un punteggio.
Altrettanto importante è che i team abbiano la certezza che i dati sottostanti riflettano lo stato effettivo del sistema in tempo reale, anziché istantanee obsolete, affinché le decisioni relative alle priorità siano effettivamente attuabili.
Quali sono i quattro dati principali utilizzati per il calcolo dei punteggi di rischio RBVM?
I punteggi di rischio RBVM combinano la gravità di base CVSS (gravità della vulnerabilità tecnica), la probabilità di sfruttamento EPSS (probabilità di sfruttamento nel mondo reale), lo stato KEV della CISA (conferma dello sfruttamento attivo) e la criticità delle risorse (funzione aziendale e sensibilità dei dati) per stabilire le priorità dei rischi nel mondo reale.
| Dati di input | Cosa misura | Why it matters |
|---|---|---|
| Gravità di base secondo il CVSS | Gravità tecnica della vulnerabilità | Fornisce un valore di riferimento per la gravità, ma il punteggio di base non tiene conto del contesto reale né della vulnerabilità* |
| Probabilità di sfruttamento dell’EPSS | Probabilità di sfruttamento in natura | Segnale dinamico che riflette il comportamento attuale degli autori delle minacce e si evolve man mano che vengono rilevate nuove attività di exploit |
| Stato CISA KEV | Se la vulnerabilità sia oggetto di sfruttamento attivo | Indicatore binario dell’utilizzo effettivo delle armi |
| Asset criticità | Funzione aziendale, sensibilità dei dati, esposizione | Determina il raggio d'azione dell'esplosione qualora l'elemento fosse compromesso |
* Il CVSS v3.x include modificatori di punteggio temporali e ambientali volti ad aggiungere contesto, ma questi vengono raramente applicati su larga scala nei programmi aziendali.
Questi dati risultano più efficaci quando vengono costantemente aggiornati con informazioni aggiornate sulle vulnerabilità, compresi i dati relativi agli exploit recentemente resi noti, alle tecniche di attacco emergenti e ai punteggi aggiornati relativi alla probabilità di sfruttamento. Il contesto delle minacce, compresi i settori attualmente presi di mira e i kit di exploit attualmente in circolazione, può consentire di definire con maggiore precisione le ponderazioni dei punteggi per il Suo ambiente specifico.
Anche il potenziale di diffusione laterale, ovvero la posizione nella rete e le vie di esposizione dell’asset interessato, funge da ulteriore fattore di modifica del rischio. Una vulnerabilità presente su un server di test isolato comporta un rischio diverso rispetto alla stessa vulnerabilità presente su un controller di dominio o su un server applicativo situato lungo un percorso di rete che conduce a dati sensibili dei clienti.
Qual è un esempio di approccio basato sul rischio?
Si considerino queste due vulnerabilità:
Vulnerabilità A: CVSS 9,8 (critica), EPSS 0,02 (bassa probabilità di sfruttamento), non presente nel KEV della CISA; interessa un server di test isolato privo di percorsi di movimento laterale.
Vulnerabilità B: CVSS 7,5 (alto), EPSS 0,85 (elevata probabilità di sfruttamento), presente nell’elenco KEV della CISA, interessa un server di elaborazione dei pagamenti in produzione con accesso laterale al database dei clienti.
Il CVSS, da solo, attribuirebbe una priorità maggiore a A rispetto a B. Tuttavia, un modello basato sul rischio assegna correttamente una priorità maggiore a B, poiché un server di pagamento in produzione con percorsi di movimento laterale verso dati sensibili rappresenta proprio quel tipo di obiettivo di alto valore e facilmente raggiungibile che le campagne di ransomware e di estorsione sono note per perseguire sistematicamente.
Tale inversione di prospettiva costituisce il fulcro della definizione delle priorità relative alle vulnerabilità in un programma basato sul rischio.
Tuttavia, la sola definizione delle priorità non riduce il rischio, a meno che non porti all’adozione di misure correttive che vengano portate a termine e verificate.
I rapporti ponderali specifici variano a seconda dell’organizzazione e della tolleranza al rischio, ma il principio generale rimane valido: i segnali dinamici relativi alle minacce e il contesto aziendale possono e devono prevalere sulla gravità statica.
Il punteggio svolge un ruolo anche nel regolare l’esecuzione delle azioni correttive, non solo nella definizione delle priorità. Man mano che i programmi evolvono verso l’automazione, la valutazione del livello di affidabilità può aiutare a determinare quali azioni possano essere implementate in modo sicuro su larga scala senza la revisione umana e quali richiedano invece un’implementazione graduale o un’approvazione manuale.
Una vulnerabilità con un punteggio di rischio elevato, ma per la quale sussistono incertezze riguardo alla stabilità della patch su una specifica versione del sistema operativo, potrebbe giustificare un’implementazione graduale anziché un’applicazione immediata. L'allineamento delle soglie di affidabilità ai flussi di lavoro di correzione consente alle organizzazioni di potenziare l'automazione senza aumentare il rischio operativo.
Tuttavia, anche un punteggio ben strutturato è utile solo se il dato su cui si basa è reale. È qui che entra in gioco la convalida.
Verificare le esposizioni prima di agire
Un risultato dello scanner non equivale a un’esposizione confermata. Agire sulla base di risultati non verificati comporta uno spreco di risorse destinate alla bonifica e mina la fiducia reciproca tra i team, su cui si basano i programmi RBVM. La convalida rappresenta il modo in cui i team colmano tale divario prima che si aggravi.
Cosa si intende per “convalida”
Un’esposizione confermata è un riscontro la cui presenza è stata verificata nell’ endpoint e e che non è stato ancora mitigato da controlli compensativi, sulla base dei dati attuali relativi allo stato e alla configurazione dell’ endpoint e. La convalida risponde a tre domande:
- Il software vulnerabile , versione , è effettivamente presente e in esecuzione?
- Un controllo compensativo mitiga già il rischio? La segmentazione della rete, le regole WAF e il rafforzamento della configurazione possono tutti contribuire a ridurre la vulnerabilità agli attacchi.
- La risorsa è ancora attiva e raggiungibile?
Grazie a questo livello di affidabilità, le organizzazioni possono tranquillamente automatizzare le procedure di correzione senza introdurre nuovi rischi nel processo.
Perché i falsi positivi minano la fiducia
Negli ambienti aziendali, i tassi di falsi positivi variano notevolmente a seconda della configurazione dello scanner, dello stato di integrità delle risorse e dell’attualità della scansione. A prescindere dal dato esatto, anche un tasso di falsi positivi modesto, se applicato su larga scala, può sovraccaricare la capacità operativa dell’IT qualora i risultati non vengano convalidati prima di entrare nella coda delle azioni correttive. A ciò contribuiscono le analisi delle vulnerabilità non aggiornate, i controlli compensativi non presi in considerazione e le risorse già dismesse.
Ogni falso positivo che giunge al reparto operativo IT comporta una perdita di tempo che avrebbe potuto essere impiegato per risolvere il rischio. Con il passare del tempo, i team IT iniziano a guardare alla coda con scetticismo. La risposta rallenta e la coda perde credibilità.
La gestione delle eccezioni è ciò che distingue una coda pulita da una caotica. I flussi di lavoro formali che escludono i rischi accettati, le esposizioni compensate e i risultati relativi alle attività dismesse garantiscono che la coda attiva rifletta esclusivamente le esposizioni effettive e non risolte. Senza questo meccanismo, anche le code con priorità ben definite accumulano rumore che, nel tempo, mina la fiducia delle operazioni IT.
Per ricostruire la fiducia, le organizzazioni hanno bisogno di qualcosa di più che semplici modelli di classificazione più efficaci. Devono avere la certezza che i problemi individuati rispecchino la situazione attuale e che le misure correttive adottate siano efficaci.
Ciò significa verificare se le azioni correttive comportino modifiche accertate allo stato del sistema, e non solo la chiusura di un ticket o un aggiornamento dello stato.
In che modo “ Tanium ” supporta la gestione delle vulnerabilità basata sul rischio
La maggior parte delle organizzazioni sa già quali sono le vulnerabilità più rilevanti. La sfida più ardua consiste nel mettere in pratica tali conoscenze in modo rapido, coerente e su larga scala. Tanium , soluzione per la gestione dell’esposizione, colma le lacune operative che causano il rallentamento dei programmi di gestione delle vulnerabilità basati sul rischio, integrando in un’unica piattaforma visibilità in tempo reale, definizione delle priorità, correzione e convalida.
Visibilità in tempo reale delle risorse
Tanium monitora costantemente gli endpoint, i dispositivi non gestiti, i registri dei container e i carichi di lavoro Kubernetes alla ricerca di vulnerabilità e lacune di conformità. Tanium Cloud Workloads estende tale copertura agli ambienti containerizzati grazie alla visibilità del registro delle immagini e all’analisi delle vulnerabilità, all’analisi dei container in fase di esecuzione e all’applicazione delle politiche di Kubernetes. Le lacune nella copertura si riducono poiché la piattaforma individua elementi che altri strumenti non rilevano.
Risk valutazione basata sulla situazione attuale
I punteggi di rischio a livello di endpoint e a livello organizzativo combinano la gravità delle vulnerabilità, la criticità delle risorse, le non conformità e il rischio di movimento laterale — fattori che i punteggi CVSS statici non tengono in considerazione — insieme a un’analisi comparativa con i valori di riferimento del settore. I punteggi riflettono lo stato attuale dell’ endpoint , piuttosto che istantanee periodiche relative a un determinato momento. Tanium , strumento di benchmarking, consente ai responsabili della sicurezza di confrontare il proprio profilo di rischio con quello dei colleghi del settore, traducendo i dati relativi alle vulnerabilità in metriche orientate ai risultati, di cui hanno bisogno i vertici aziendali e i team addetti alla conformità.
Bonifica integrata
I team passano dalla valutazione all'azione sulla stessa piattaforma. È possibile applicare patch, modifiche alla configurazione e altre misure di controllo su larga scala senza dover passare da uno strumento all’altro. Tanium Comply supporta la valutazione delle vulnerabilità e i controlli di conformità relativi a sistemi operativi, applicazioni, catena di fornitura del software e configurazioni di sicurezza, avvalendosi di contenuti OVAL e dell’ SCAP , oltre che della libreria di contenuti propria di Tanium', che viene aggiornata quotidianamente.
Automazione controllata
Tanium , grazie alle funzionalità di automazione, consente ai team di creare procedure operative (playbook) senza codice o con codice ridotto che automatizzano le attività di correzione ripetitive. I playbook possono richiedere l’autorizzazione di un operatore prima dell’esecuzione, garantendo così la tracciabilità su larga scala.
Convalida a ciclo chiuso
Una volta applicata una correzione, l’esecuzione della valutazione “ Comply ” conferma se la vulnerabilità è stata risolta e aggiorna di conseguenza il punteggio di rischio. Tanium È possibile eseguire questa valutazione su richiesta, anziché dover attendere il completamento di un ciclo di scansione programmato.
Ambiente di lavoro unificato per l'IT e la sicurezza
Entrambe le squadre operano sulla base degli stessi punteggi di rischio, degli stessi dati relativi alle priorità e dello stesso stato di risoluzione, il tutto all’interno di un’unica piattaforma unificata. Questo modello operativo condiviso contribuisce a ridurre gli oneri di coordinamento che rallentano le operazioni di risoluzione dei problemi quando le operazioni di sicurezza e quelle IT si avvalgono di strumenti e fonti di dati distinti.
Tanium Guardian
Tanium Guardian mette in luce le minacce emergenti grazie alle linee guida elaborate da esperti del Vulnerability Emergency Response Team (VERT) dell’ Tanium , aiutando i team a rispondere con sicurezza alle vulnerabilità zero-day e ai rischi che richiedono un intervento tempestivo. I team possono eseguire azioni correttive direttamente all’interno della piattaforma IT autonoma Tanium .
Queste funzionalità operano in sinergia per ridurre i tempi che intercorrono tra l’individuazione del problema e la risoluzione verificata. Ring Power Corp. ha utilizzato Tanium per valutare la propria esposizione a Log4j vulnerabilità su tutti gli endpoint in circa 30 minuti, un’operazione che, secondo le stime del team, avrebbe richiesto mesi con gli strumenti precedenti.
Quando l’individuazione, la definizione delle priorità e la correzione si avvalgono di un’unica piattaforma, i programmi di gestione delle vulnerabilità basati sul rischio possono evolversi alla velocità richiesta dal panorama delle minacce.
Domande frequenti sulla gestione delle vulnerabilità basata sul rischio
Anche i modelli ben noti sollevano questioni pratiche relative alla loro implementazione, e l’RBVM non fa eccezione. Le risposte che seguono affrontano alcuni dei punti di confusione più comuni che i team incontrano durante l’implementazione dell’RBVM.
In che modo l’RBVM si differenzia dalla gestione tradizionale delle vulnerabilità?
La gestione tradizionale delle vulnerabilità stabilisce le priorità basandosi esclusivamente sui punteggi di gravità CVSS, mentre l’RBVM tiene conto sia della probabilità di sfruttamento che della criticità delle risorse, per concentrarsi sulle vulnerabilità che comportano un rischio effettivo per l’azienda. Ad esempio, una vulnerabilità con punteggio CVSS 7,5 su un server di pagamento con elevata sfruttabilità potrebbe avere una priorità maggiore rispetto a una vulnerabilità con punteggio CVSS 9,8 su un sistema di test isolato.
In che modo la gestione delle vulnerabilità basata sul rischio migliora le difese in materia di sicurezza informatica?
RBVM migliora le difese indirizzando le risorse destinate alla correzione delle vulnerabilità verso quelle che gli aggressori stanno attivamente sfruttando o che sono più suscettibili di essere utilizzate a fini malevoli. Ciò contribuisce a ridurre il tempo medio necessario per risolvere i problemi relativi alle esposizioni più critiche e consente alle operazioni IT di concentrarsi sui risultati che comportano un rischio effettivo.
Quali sono gli strumenti più indicati per l’implementazione di una gestione delle vulnerabilità basata sul rischio?
I programmi RBVM efficaci richiedono in genere funzionalità che abbracciano diverse categorie: individuazione e inventario continui delle risorse, scansione e arricchimento delle vulnerabilità (compresi i punteggi EPSS e lo stato KEV della CISA), integrazione dei flussi di lavoro con gli strumenti ITSM per l’assegnazione delle misure correttive e verifica che le correzioni implementate abbiano risolto il problema individuato.
Alcune organizzazioni integrano tali funzionalità attingendo a diversi strumenti specifici. Altre aziende integrano la visibilità delle risorse, la valutazione del rischio e le misure correttive in un’unica piattaforma di flussi di lavoro. L'approccio corretto dipende dalla suite di strumenti esistente, dalla struttura del team e dal fatto che la visibilità sull' endpoint e sia già stata risolta.
La piattaforma IT autonoma “ Tanium ” integra le informazioni in tempo reale relative all’ endpoint , ai flussi di lavoro integrati e alle misure correttive, per consentire ai team di sicurezza e IT di operare sulla base di un quadro condiviso e accurato dei rischi.
I team possono agire più rapidamente, ridurre i ritardi nei passaggi di consegne e verificare i risultati delle azioni correttive in tutto l’ambiente senza dover ricorrere a controlli manuali o a dati non aggiornati.
Capire quali siano le vulnerabilità più rilevanti rappresenta solo metà del quadro. È proprio nella risoluzione rapida, coerente e su larga scala di tali problemi che la maggior parte dei programmi si arena.
Prenoti oggi stesso una demo gratuita e personalizzata all’indirizzo per scoprire come Tanium integri visibilità in tempo reale, definizione delle priorità e risoluzione dei problemi in un’unica piattaforma.
