Gestione delle vulnerabilità basata sul rischio: come i finding diventano le giuste priorità
Nelle moderne operazioni IT, stabilire le priorità delle vulnerabilità basandosi esclusivamente sui punteggi CVSS non è più sufficiente. La gestione delle vulnerabilità basata sul rischio combina la gravità tecnica con la threat intelligence, il contesto degli endpoint e la rilevanza per il business. Questo trasforma lunghi elenchi di CVE in azioni concrete di remediation.
Gestione delle vulnerabilità basata sul rischio – In sintesi
- Un punteggio CVSS elevato descrive la gravità tecnica, ma non il rischio effettivo per la propria organizzazione.
- Il contesto del software e degli endpoint interessati modifica la priorità di una vulnerabilità.
- La prioritizzazione porta ad azioni concrete come aggiornamenti, installazioni e disinstallazioni.
- Il Proactive Hub combina le informazioni sulle vulnerabilità con lo stato del proprio ambiente IT.
Una dashboard non protegge. L’azione sì. Con queste parole iniziava il precedente articolo sull’Auto Remediation. Ma prima che un reparto IT possa agire, deve decidere da dove iniziare.
Nella gestione delle vulnerabilità, questo è spesso più complesso del previsto. Gli scanner e i database di sicurezza forniscono continuamente nuove segnalazioni di vulnerabilità. Anche una singola applicazione obsoleta può comportare numerose voci CVE. L’elenco cresce, ma il tempo disponibile no.
E cresce anche la pressione. Il Mandiant M-Trends 2026 Report stima ora a meno sette giorni il tempo mediano che intercorre fino allo sfruttamento di una vulnerabilità. Questo significa che le vulnerabilità vengono regolarmente sfruttate prima ancora che sia disponibile una patch.
Perché la gestione classica del rischio delle vulnerabilità raggiunge i suoi limiti
La maggior parte dei sistemi di gestione delle vulnerabilità segue un principio semplice: in cima vengono elencate le vulnerabilità critiche, seguite da quelle con valutazione alta, media e bassa. Questo crea un ordine iniziale, ma non è un triage sufficiente per le operazioni quotidiane.
Infatti, una vulnerabilità con un punteggio CVSS elevato (Common Vulnerability Scoring System) potrebbe interessare un’applicazione installata soltanto su tre dispositivi di test isolati. Un’altra vulnerabilità, invece, può avere una valutazione tecnica inferiore, ma trovarsi in un browser presente su quasi tutti gli endpoint. Potrebbe persino esistere un exploit noto, oppure i dispositivi interessati potrebbero essere utilizzati da dipendenti con ampi privilegi.
Per stabilire una priorità affidabile, l’IT ha quindi bisogno di ulteriori informazioni:
- Quali versioni del software sono effettivamente installate?
- Quanti endpoint sono interessati e quali?
- Vi sono indicazioni di uno sfruttamento in corso?
- Quali dispositivi o gruppi di utenti sono particolarmente esposti?
- Quanto sarebbe complessa e rischiosa la remediation?
A seconda delle risposte, l’ordine in cui devono essere eliminate può cambiare significativamente.
Dalle singole CVE alla remediation delle vulnerabilità di sicurezza
Le voci CVE descrivono singole vulnerabilità note. Tuttavia, gli amministratori raramente lavorano a questo livello. Distribuiscono un aggiornamento software, modificano una configurazione oppure installano/disinstallano un’applicazione.
Una vecchia versione del software può contenere dieci o venti CVE. In un elenco classico, ciò produce dieci o venti finding. Per la remediation, tuttavia, può essere sufficiente un singolo aggiornamento.
Per questo ha senso spostare l’attenzione dalla singola CVE all’applicazione interessata e all’azione possibile. In questo modo, più finding possono essere consolidati in un unico ordine di lavoro concreto.
Questo non riduce artificialmente il numero di voci. Il loro significato diventa più chiaro. Un amministratore individua quale applicazione causa il rischio, dove è presente e quante vulnerabilità possono essere eliminate con una sola azione.
Che cos’è la gestione delle vulnerabilità basata sul rischio (RBVM)
La gestione delle vulnerabilità basata sul rischio (Risk-based Vulnerability Management, RBVM) non si limita a valutare le vulnerabilità esclusivamente in base alla loro gravità tecnica. Invece di considerare ogni vulnerabilità isolatamente, nella prioritizzazione confluiscono insieme panorama delle minacce, sistemi interessati e contesto aziendale.
Un approccio sensato consiste nel confrontare innanzitutto le applicazioni e le versioni rilevate con i livelli di versione effettivamente interessati da una CVE. Successivamente, le vulnerabilità rilevanti vengono arricchite con threat intelligence aggiornata.
Ne fanno parte
- la gravità tecnica,
- gli exploit noti,
- una previsione della probabilità di sfruttamento futuro,
- e il contesto del rispettivo ambiente IT (ad es. sistema di test o sistema critico per il business).
Ne risulta una valutazione più accurata di quella basata sul solo punteggio CVSS.
Questo approccio diventa ancora più significativo quando la valutazione viene poi collegata ai dati degli endpoint interessati. L’amministratore vede quindi quale
applicazione e quale versione sono interessate, su quali dispositivi sono presenti e quanto sia elevata la necessità di intervento nel proprio ambiente.
Prioritizzare le vulnerabilità – e poi? Come trasformare le informazioni sulla sicurezza in un IT stabile
Una priorità chiara è il primo passo. Ma solo l’azione corretta fa la differenza. Nella nostra Best Practice Guide “DEX & UEM – Conoscenze IT pratiche dall’IT per l’IT”, mostriamo come trasformare gli stati software vulnerabili in endpoint sicuri e più performanti.
Non tutti i rischi richiedono la stessa remediation
Anche una priorità elevata non risponde ancora alla domanda su come debba essere corretta una vulnerabilità.
Un browser o un lettore PDF può generalmente essere aggiornato in modo rapido e su larga scala. Per il software critico per il business, tuttavia, possono essere coinvolte interfacce, estensioni o altre dipendenze. Un rollout immediato su tutti gli endpoint potrebbe in questo caso causare nuove interruzioni e “digital friction”.
Per il software standard può essere indicato un aggiornamento in gran parte automatizzato. Le applicazioni critiche vengono aggiornate dapprima su dispositivi selezionati. Solo se non si verificano nuove anomalie segue un ulteriore gruppo di endpoint.
In questo modo, anche una misura di sicurezza urgente rimane controllabile. La valutazione tecnica mostra con quale rapidità l’IT dovrebbe reagire. Il contesto dell’endpoint e dell’applicazione aiuta a scegliere l’approccio.
“Perché le vulnerabilità non dovrebbero essere considerate soltanto dal punto di vista della sicurezza?”
Robert Klinger (Product Manager): “Perché spesso questo si manifesta nella stessa applicazione. Un software obsoleto è in esecuzione su numerosi endpoint, viene utilizzato raramente, ma genera carico sulla CPU e presenta vulnerabilità note. Chi guarda soltanto alla sicurezza aggiornerebbe semplicemente ovunque. Con il contesto dell’endpoint, l’azione diventa più mirata: i dispositivi attivi ricevono la versione sicura, le installazioni inutilizzate vengono rimosse. Security e Digital Employee Experience considerano qui la stessa applicazione da prospettive diverse. Il baramundi Proactive Hub riunisce queste informazioni in un unico punto."
Conclusione: dalla priorità alla remediation delle vulnerabilità di sicurezza
Un lungo elenco di CVE aperte, dunque, non indica ancora da dove dovrebbe iniziare un team IT. Solo quando le vulnerabilità vengono collegate allo stato effettivo del proprio ambiente IT, un generico finding di sicurezza diventa un’azione concreta e significativa.
Dopo ogni remediation segue la verifica: la versione vulnerabile è stata effettivamente sostituita? Ci sono ancora dispositivi interessati? L’aggiornamento ha causato nuovi problemi?
Il baramundi Proactive Hub supporta i team IT proprio in questo: le vulnerabilità vengono confrontate con gli endpoint esistenti, valutate in base alla rilevanza e consolidate in azioni concrete di remediation.
