CVSS in fabbrica: perché il punteggio non basta

Un praticioner OT propone un framework a 5 passi per valutare l'exploitabilità reale delle vulnerabilità in ambienti manifatturieri, dove il patching immediato non è

Scopri anche

CVSS in fabbrica: perché il punteggio non basta

Un praticioner di sicurezza OT ha pubblicato il 4 giugno 2026 su Help Net Security un framework operativo per gestire le vulnerabilità in ambienti manifatturieri, sostenendo che il punteggio CVSS da solo genera allarmi ingiustificati e allocazioni di risorse distorte. La proposta nasce da un'esigenza concreta: nei sistemi industriali la disponibilità operativa prevale sulla confidenzialità e l'integrità, e il patching non può seguire i ritmi dell'IT enterprise.

Punti chiave

Un framework a cinque passaggi — inventario, verifica funzione vulnerabile, mitigazioni esistenti, percorso di exploitation, remediation — è proposto per valutare l'exploitabilità effettiva in ambienti OT.
Gli scanner di vulnerabilità si affidano spesso alla versione software self-reported, generando falsi positivi che non riflettono la reale esposizione del sistema.
La segmentazione di rete (DMZ, firewall ACL, jump server) riduce l'exploitabilità anche di vulnerabilità con CVSS elevato, ma questa attenuazione non compare nei report automatici.
L'acceptance del rischio in OT richiede processo formale documentato, con controlli compensativi e data fissa di rivalutazione, in alternativa al patching immediato.

Perché il CVSS 10 non è sempre un CVSS 10

Il punteggio CVSS misura la severità intrinseca di una vulnerabilità, non il rischio per una specifica organizzazione. In un ambiente IT standard, un CVSS 10 sulla WAN spinge al patching d'urgenza. In fabbrica, la stessa vulnerabilità può trovarsi su un PLC dietro tre livelli di segmentazione, senza route di rete verso l'esterno, con accesso fisico controllato. La differenza è strutturale, non nominale.

La fonte cita CVE-2025-27495, con CVSS 9.8, come contro-esempio emblematico: porta 8000 aperta di default, exploitation possibile da internet senza autenticazione. In quel caso specifico, il percorso di attacco è semplice e il punteggio rispecchia il rischio operativo. Ma la stessa severità nominale su un diverso asset, con topologia segmentata e ACL attive, descrive uno scenario radicalmente diverso. Il problema, secondo il praticioner, è che gli strumenti di scanning non distinguono i due contesti: entrambi generano ticket con la stessa priorità.

I cinque passaggi del framework proposto

Il framework articola una sequenza decisionale che precede qualsiasi azione di remediation. Il primo passaggio è l'inventario accurato: non solo elencare gli asset, ma verificarne la funzione operativa, il ruolo nel processo produttivo, la criticità per la continuità. Il secondo passaggio verifica se la funzione vulnerabile è effettivamente attiva nel sistema target: una libreria presente ma non invocata, un servizio disabilitato, una feature non implementata rendono la vulnerabilità tecnicamente irrilevante.

Il terzo passaggio mappa le mitigazioni esistenti: NAT, VLAN segmentate, firewall con regole stateful, DMZ per i servizi esposti, jump server per l'accesso amministrativo. Il quarto traccia il percorso di exploitation completo, dal punto di ingresso potenziale all'asset target, verificando se ogni hop è attraversabile in pratica. Il quinto affronta la remediation, che in OT significa spesso controlli compensativi e risk acceptance formale piuttosto di patching.

"In a normal IT environment, you patch it then close the ticket and call it a day. If, however, you're in OT or dealing with ICS in a live manufacturing facility, it's rarely that simple."

Il problema dei falsi positivi da versione software

Una delle cause più frequenti di distorsione nei report di vulnerabilità OT è la dipendenza dalla versione self-reported. Gli scanner identificano il numero di versione dichiarato da un'applicazione e lo confrontano con database di CVE noti, senza verificare se il codice vulnerabile è effettivamente presente o se la build installata include già un backport della patch. Il praticioner riporta un caso con sette versioni diverse di Adobe, tutte segnalate come vulnerabili, con overhead di verifica manuale che non si traduceva in esposizione reale.

La citazione diretta dalla fonte descrive il meccanismo: "We have not tested for these issues but instead relied only on the application's self-reported version number". Questa limitazione metodologica, nota anche in ambienti IT, diventa critica in OT dove ogni alert richiede coordinamento con ingegneria di processo, pianificazione di fermi produttivi, e spesso contratti di manutenzione con vendor che devono validare la compatibilità del firmware. Un falso positivo non è inefficienza: è rischio operativo, perché consuma finestre di manutenzione limitate su problemi inesistenti.

La documentazione del risk acceptance come controllo

Quando il patching è impraticabile — per vincoli di produzione continua, per assenza di patch vendor, per rischio di regressione funzionale — il framework propone l'acceptance del rischio come percorso strutturato, non come deroga informale. La fonte specifica i requisiti: record scritto del rischio accettato, controlli compensativi in funzione, data rigida di rivalutazione. Questa formalizzazione serve duplice funzione: operativa, mantenendo tracciabilità delle decisioni; e giuridica, fornendo al management documentazione difensiva in caso di audit o incidente.

Il praticioner sottolinea il valore del linguaggio tecnico per la comunicazione con la direzione: la capacità di tradurre "CVSS 10" in "exploitabilità condizionata da X controlli, con impatto mitigato a Y, richiede investimento Z per remediation programmata" è ciò che distingue una funzione di sicurezza reattiva da una funzione di risk management. La citazione conclusiva della fonte sintetizza il principio: "A CVSS 10 buried three networks deep being two firewalls with proper ACLs in place is completely different than a CVSS 10 on a flat network accessible by anyone on the internet and a default password".

Perché è importante

Il dossier non specifica l'identità istituzionale dell'autore né fornisce dati quantitativi sulla prevalenza del problema — percentuali di falsi positivi, tempi medi di remediation OT, tassi di adozione del framework. Non emerge se il metodo sia originale o derivato da standard esistenti come NIST SP 800-82 o IEC 62443. La validazione empirica è assente: nessun caso d'uso documentato, nessuna revisione peer, nessuna misurazione dell'efficacia rispetto a processi tradizionali di prioritizzazione.

La fonte non indica inoltre lo stato attuale di CVE-2025-27495: se patchata, se ampiamente diffusa in ambienti industriali, se effettivamente rilevante nel contesto del 2026. Il riferimento è illustrativo, non analitico. Le fonti Unit 42, presenti nel dossier come contesto settoriale, non corroborano il framework proposto: coprono vulnerabilità Linux, malware macOS, superficie di attacco della Coppa del Mondo 2026, e strumenti cloud identity, nessuno dei quali interseca direttamente il vulnerability management OT in manufacturing.

Il valore del contributo risiede nel linguaggio operativo proposto per un problema riconosciuto: il divario tra metriche di sicurezza progettate per l'IT e le esigenze di ambienti dove la fermata di una linea produttiva ha costi misurabili in milioni di euro l'ora. Per CISO e responsabili della sicurezza in manufacturing, il framework fornisce struttura per conversazioni interne che altrimenti si risolvono in pressione irrazionale per il patching immediato, o in immobilismo pericoloso.

Le informazioni sono basate sulla fonte citata e aggiornate al momento della pubblicazione.

Fonti

Fonti e riferimenti