CVE e EPSS negli ambienti OT: quali vulnerabilità correggere quando non puoi patchare tutto

Il problema della prioritizzazione nell'OT

In un ambiente OT manifatturiero, il numero di vulnerabilità note che insistono sui sistemi in produzione può essere considerevole. PLC, HMI, switch industriali, server SCADA, sistemi storici: ognuno accumula CVE nel tempo. Non è raro che un inventario OT di media dimensione mostri centinaia di vulnerabilità aperte, alcune con anni di anzianità.

Il problema non è trovare le vulnerabilità: è decidere cosa fare prima, sapendo che non si può fare tutto. E nell'OT questa limitazione è strutturale, non una questione di risorse insufficienti.

Patchare un PLC o un sistema SCADA richiede tipicamente un fermo impianto pianificato, test di regressione del processo, coordinamento con il vendor, finestre di manutenzione che si apriranno tra settimane o mesi. In alcuni casi (sistemi fuori supporto, contratti che vietano modifiche software, hardware che non supporta versioni aggiornate del firmware) la patch non esiste o non è applicabile. Occorre quindi una logica di prioritizzazione che sia pratica, non solo teorica.

CVSS: utile ma insufficiente

Il Common Vulnerability Scoring System (CVSS) è lo standard de facto per quantificare la severità di una vulnerabilità. Un punteggio CVSS va da 0 a 10, dove 9-10 è critico, 7-8.9 è alto, 4-6.9 è medio. La formula considera fattori come il vettore di attacco (remoto o locale), la complessità, i privilegi necessari, l'impatto su confidenzialità, integrità e disponibilità.

CVSS è utile perché standardizza la severità e permette di confrontare vulnerabilità diverse su una scala comune. Ma ha un limite fondamentale: misura la gravità teorica di una vulnerabilità, non la probabilità che venga sfruttata in pratica.

Una vulnerabilità con CVSS 9.8 è teoricamente gravissima. Ma se è su un protocollo di nicchia usato in pochissime installazioni al mondo, se non esiste exploit pubblico, se nessun gruppo di attacco la sta usando attivamente, nella pratica il rischio reale può essere molto più basso di una vulnerabilità con CVSS 7.2 che ha un exploit maturo disponibile su GitHub e che i gruppi ransomware stanno già usando nelle loro campagne.

Gestire la prioritizzazione basandosi solo sul CVSS porta a un errore sistematico: si tende a sovra-priorizzare vulnerabilità teoricamente gravi ma raramente sfruttate, e a sotto-priorizzare vulnerabilità moderate ma con alta probabilità di exploit attivo.

EPSS: cosa misura e come funziona

L'Exploit Prediction Scoring System (EPSS) è un modello sviluppato da FIRST (Forum of Incident Response and Security Teams) per stimare la probabilità che una vulnerabilità venga sfruttata in the wild entro i 30 giorni successivi alla valutazione.

Il modello si basa su dati osservati: segnalazioni di exploit in fonti OSINT, attività nei feed di threat intelligence, pubblicazioni di proof-of-concept, discussioni in forum underground, attività dei motori di ricerca di dispositivi esposti. Il risultato è una probabilità espressa tra 0 e 1 (o in percentuale).

I dati empirici mostrano una distribuzione molto sbilanciata: la grande maggioranza delle CVE pubblicate non viene mai sfruttata attivamente in campagne osservate. Una percentuale relativamente piccola concentra quasi tutta l'attività di exploit reale. EPSS permette di identificare in quale parte di questa distribuzione si trova una vulnerabilità specifica.

È importante capire cosa EPSS non è: non è una misura di impatto se la vulnerabilità viene sfruttata, non considera il contesto specifico dell'organizzazione, e può cambiare significativamente nel tempo se nuove informazioni (un exploit pubblicato, una campagna osservata) modificano la stima. Va usato come input in un processo di triage, non come oracolo.

Come combinare CVSS e EPSS nell'OT

La logica di prioritizzazione più efficace nell'OT combina le due dimensioni in una matrice a quattro quadranti:

CVSS alto + EPSS alto: massima priorità. La vulnerabilità è grave e viene attivamente sfruttata. Richiede compensating controls immediati se la patch non è applicabile.

CVSS alto + EPSS basso: priorità media. La vulnerabilità è teoricamente grave ma non è attivamente sfruttata. Va pianificata nella prossima finestra di manutenzione disponibile, ma non giustifica misure di emergenza.

CVSS basso + EPSS alto: priorità media-alta, spesso sottovalutata. Questo è il quadrante pericoloso: la vulnerabilità sembra moderata guardando solo il CVSS, ma c'è attività di exploit concreta. Nell'OT questo profilo richiede attenzione perché i compensating controls possono essere meno intuitivi.

CVSS basso + EPSS basso: priorità bassa. Da gestire nel normale ciclo di patch management quando le opportunità si presentano.

Esempi concreti nel contesto OT

Caso 1: CVE con CVSS 9.8, EPSS 0.8%

Immaginiamo una vulnerabilità critica in un protocollo di comunicazione industriale legacy, con un vettore di attacco remoto senza autenticazione. Il CVSS è altissimo. Ma il protocollo in questione è usato solo in installazioni molto specifiche, l'exploit richiede conoscenza dettagliata dell'implementazione e non c'è evidenza di uso in campagne osservate. EPSS è sotto l'1%.

In un ambiente OT dove la patch richiede un fermo di tre giorni, questo profilo non giustifica necessariamente un intervento d'emergenza. La segmentazione di rete esistente e l'assenza di esposizione diretta possono già mitigare il rischio in modo accettabile. Va pianificata, non gestita come crisi.

Caso 2: CVE con CVSS 7.2, EPSS 45%

Una vulnerabilità di severità alta in un componente software ampiamente distribuito nei sistemi SCADA. Non è critica in senso assoluto, ma un exploit funzionante è disponibile pubblicamente da settimane, è di semplice utilizzo e i feed di threat intelligence registrano attività di scansione attiva verso installazioni esposte. EPSS è al 45%.

Questo profilo nell'OT richiede azione immediata, anche se patchare è difficile. I compensating controls (isolare il sistema a livello di rete, bloccare il vettore di attacco specifico a livello firewall, aumentare il monitoraggio) vanno implementati prima della prossima finestra di manutenzione disponibile.

Logica di triage per ambienti OT

Una volta definite le priorità, occorre un framework decisionale per ogni vulnerabilità identificata. Le domande da porsi in sequenza:

1. Questo sistema è raggiungibile dall'esterno o da reti non fidate? La segmentazione riduce drasticamente la probabilità di sfruttamento. Un sistema completamente isolato con una CVE EPSS alta ha un rischio reale molto inferiore a un sistema esposto con la stessa CVE.

2. Il vettore di attacco specifico è praticabile nel mio contesto? Una vulnerabilità che richiede autenticazione previa su un sistema con autenticazione forte è meno critica di una che non richiede credenziali.

3. Esiste una patch applicabile oggi? Se sì: pianificarla nella prima finestra disponibile, con priorità proporzionale alla combinazione CVSS/EPSS. Se no: passare ai compensating controls.

4. Quali compensating controls sono disponibili? Le opzioni tipiche nell'OT includono: isolamento di rete aggiuntivo, blocco del protocollo vulnerabile a livello firewall, monitoraggio aumentato del traffico verso il sistema, disabilitazione di funzionalità non necessarie, notifica agli operatori.

5. Il rischio residuo dopo i compensating controls è accettabile? Questa valutazione richiede il contesto operativo: qual è la criticità del processo che il sistema governa? Quali sarebbero le conseguenze di un incidente?

Limiti e precauzioni nell'uso di EPSS

EPSS è un ottimo strumento, ma applicarlo meccanicamente senza contesto porta a errori. Alcune precauzioni specifiche per il contesto OT:

EPSS riflette l'attività osservata nel mondo IT: le campagne di exploit monitorate riguardano prevalentemente sistemi IT. Una vulnerabilità OT-specifica può avere un EPSS basso semplicemente perché l'ecosistema di threat intelligence OT è meno maturo, non perché il rischio sia basso.

I feed specializzati ICS-CERT e CISA KEV sono complementari: il Known Exploited Vulnerabilities Catalog di CISA elenca vulnerabilità con evidenza confermata di sfruttamento attivo, incluse alcune OT-specifiche. Va consultato in parallelo a EPSS, non in alternativa.

Il punteggio cambia nel tempo: una CVE con EPSS basso oggi può diventare ad alto EPSS domani se viene pubblicato un exploit o se inizia una campagna. Il triage non è un'operazione una tantum: richiede rivalutazione periodica, almeno mensile per i sistemi critici.

La prioritizzazione delle vulnerabilità OT non è un problema risolvibile con formule automatiche. CVSS e EPSS insieme forniscono una base razionale per le decisioni, ma il contesto operativo (la criticità del processo, la segmentazione esistente, la facilità di applicazione dei compensating controls) deve sempre entrare nella valutazione finale.

L'angolo MON5

La matrice CVSS/EPSS descritta in questo articolo è il cuore della fase ANALYZE di MON5: la piattaforma correla le vulnerabilità rilevate sugli asset con lo score EPSS e, soprattutto, con l'esposizione reale di ogni dispositivo. Un PLC vulnerabile ma segregato in una zona IEC 62443 ben definita riceve una priorità diversa dallo stesso PLC raggiungibile dalla rete IT.

Il prerequisito è un inventario accurato con le versioni firmware effettivamente in produzione, che MON5 costruisce passivamente nella fase DISCOVER. Se il tuo elenco di CVE aperte è diventato ingestibile, un assessment OT lo riduce a una lista di priorità su cui agire.