Una coda di patch ordinata soltanto per punteggio tecnico può assegnare male le risorse. La priorità dipende anche da ciò che è installato, dall’esposizione, dai percorsi di attacco e dalle conseguenze operative. Servono criteri comprensibili e dati datati, non una moltiplicazione di numeri eterogenei.
Obiettivo, pubblico e prerequisiti: costruire una priorità motivata combinando applicabilità, esposizione, KEV, EPSS e CVSS. È rivolto a vulnerability manager e responsabili tecnici con inventario datato, advisory del vendor e contesto degli asset.
Uso etico e autorizzato: verifica versioni ed esposizione soltanto sugli asset del tuo perimetro. Non usare la prioritizzazione come autorizzazione a scansionare terzi e non trattare score o presenza in KEV come prova di compromissione.
Tre strumenti, tre domande
Il catalogo KEV di CISA identifica vulnerabilità per cui è noto lo sfruttamento in natura. È un ingresso nel processo di prioritizzazione; l’assenza dal catalogo non è una prova di sicurezza. Una presenza non dimostra che un proprio sistema sia già compromesso.
EPSS di FIRST stima la probabilità che una CVE pubblicata venga sfruttata in natura nei successivi 30 giorni. Score e percentile non sono intercambiabili: il percentile esprime il posizionamento relativo. Lo score non è la probabilità di compromissione del proprio asset.
CVSS v4.0 descrive caratteristiche e severità di una vulnerabilità con gruppi di metriche. Un Base score, da solo, non rappresenta l’intero rischio aziendale. Conservare vettore e versione per evitare confronti opachi tra valutazioni differenti.
Verificare l’applicabilità
Prima della graduatoria, confermare prodotto, versione e componente effettivamente usato. Una libreria nel repository non prova che sia nel processo in esecuzione; una versione apparentemente vecchia può includere backport del vendor. Confrontare inventario e advisory del produttore, riportando la fonte della verifica.
Descrivere inoltre prerequisiti, interfaccia esposta e privilegi richiesti nel contesto reale. Un controllo compensativo può ridurre l’esposizione, ma va collaudato sul percorso pertinente. Non convertirlo in un’esclusione definitiva senza un responsabile e una scadenza.
Un criterio editoriale di ordinamento
La tabella è una proposta di governance, non un algoritmo ufficiale FIRST o CISA:
| Condizione | Azione da valutare |
|---|---|
| Sfruttamento noto, applicabilità confermata, esposizione critica | Trattamento urgente con proprietario e verifica di compromissione |
| Applicabile, asset critico, probabilità stimata elevata | Accelerare il piano e verificare i controlli temporanei |
| Applicabilità incerta | Risoluzione dell’incertezza con tempi assegnati |
| Non applicabile documentato | Chiudere conservando evidenza e condizione di revisione |
Definire localmente cosa significhino urgente ed elevata: capacità di intervento, obblighi e rischio tollerato cambiano tra organizzazioni. Non adottare soglie universali solo perché sono facili da implementare.
Uno scenario senza punteggi inventati
Considerare due sistemi sintetici: un’appliance esposta con una vulnerabilità applicabile e sfruttamento noto, e un servizio isolato con un problema tecnicamente severo ma un percorso non raggiungibile dai segmenti ordinari. La prima può richiedere trattamento prioritario; la seconda resta nel piano e l’isolamento deve essere dimostrato. Non serve inventare CVE o numeri per spiegare il criterio.
Se il sistema esposto presenta segnali di abuso, patching e risposta all’incidente sono attività differenti. Aggiornare il software non elimina automaticamente credenziali rubate o persistenza. Collegare il ticket di remediation all’indagine senza confondere le evidenze.
Mitigazioni, limiti e verifica finale
Registrare data di KEV/EPSS, advisory, asset, decisione e approvazione delle eccezioni. Dopo l’intervento verificare la versione effettiva, l’esposizione e i servizi dipendenti. La rivalutazione deve avvenire quando cambiano gli input, non soltanto alla scadenza di un report mensile.
Fonti essenziali
Riferimenti primari consultati il 3 ottobre 2026. Le procedure di analisi e gli scenari di laboratorio sono proposte editoriali: vanno adattati alla telemetria e alle versioni installate.
AUTORE
Redazione ThreatHunting.it
Da piu' di 30 anni sono appassionato di computers e tecnologia. il mio primo programma lo sviluppai in Basic nel 1989, non era un gran che :).. ma quella voglia di scrivere codici non mi ha piu' lasciato …
COMMUNITY
Non ci sono ancora commenti. Puoi iniziare tu la conversazione.