Potenziale di attacco: la metrica che rende “reale” una vulnerabilità

Il 19 ottobre 2025 il Museo del Louvre di Parigi ha subito il furto di otto gioielli della corona francese. Nonostante sistemi d’allarme, telecamere di sorveglianza e personale dedicato, un gruppo di malviventi travestiti da operai edili è riuscito ad avvicinarsi indisturbato e a bordo di un camion con piattaforma elevatrice hanno raggiunto una finestra del primo piano, l’hanno forzata e sono fuggiti in meno di sette minuti. Ed è proprio qui che emerge il nodo della vicenda: non la presenza delle difese, ma la loro capacità di aumentare il “costo complessivo” dell’attacco.

Lo stesso principio vale anche per i sistemi informatici. Quando parliamo di potenziale di attacco non misuriamo soltanto la presenza di vulnerabilità tecniche ma misuriamo lo sforzo complessivo che un avversario deve affrontare per sfruttarle.

Potenziale di attacco: origini e formalizzazione

Il concetto di potenziale di attacco non nasce nell’informatica, ma molto prima, in quanto le sue radici affondano nella valutazione del rischio militare e, soprattutto, nella crittoanalisi della Guerra Fredda. In quegli anni, gli analisti dell’intelligence svilupparono metodologie per stimare lo sforzo necessario a violare sistemi di comunicazione cifrati in quanto non bastava dimostrare che un cifrario fosse teoricamente attaccabile, bisognava capire se un avversario reale disponesse di tempo, risorse e competenze sufficienti per farlo.

Questa impostazione operativa, misurare non la possibilità teorica, ma la fattibilità concreta di un attacco, è poi migrata naturalmente nel mondo della sicurezza informatica.
Con la crescente complessità delle infrastrutture IT, diventò evidente che limitarsi a elencare vulnerabilità non permetteva più a descrivere il rischio ma ciò che conta davvero è quanto è difficile sfruttarle.

La formalizzazione del potenziale di attacco avviene negli anni ’90 con la definizione dei Common Criteria for Information Technology Security Evaluation (ISO/IEC 15408), lo standard internazionale che, ancora oggi, definisce come valutare la sicurezza dei prodotti IT certificati.

Le cinque dimensioni nei Common Criteria

All’interno dei Common Criteria (CC), l’attacco non è valutato in astratto ma attraverso una metrica composita che considera cinque dimensioni fondamentali:
• Tempo richiesto per eseguire l’attacco
• Competenze tecniche dell’avversario
• Conoscenza del sistema target
• Tipo di accesso al bersaglio ( alcuni attacchi possono essere tentati da remoto, altri richiedono di essere fisicamente vicino al dispositivo)
• Risorse hardware/software necessarie (quindi che strumenti servono davvero; può trattarsi di un normale computer, oppure di apparecchiature costose, laboratori dedicati, chip specializzati o infrastrutture complesse).

Combinando queste dimensioni, i CC definiscono quattro categorie di attaccanti, ordinate per crescente capacità e impegno: Basic → Enhanced-Basic → Moderate → High.
Queste non descrivono “quanto è brava la persona”, ma quanta fatica deve fare per arrivare a comprometterti. Un prodotto certificato deve dimostrare di resistere ad attacchi fino a un certo livello di potenziale ed è qui che emerge il principio chiave: la sicurezza non è assoluta, è sempre relativa all’avversario che puoi permetterti di fermare.

Un prodotto progettato per resistere ad attaccanti con potenziale “Moderate” può essere estremamente adeguato nel mondo civile, ma non sarà mai sufficiente contro un apparato di intelligence con potenziale “High”, risorse illimitate e capacità avanzate.

L’importanza dei Common Criteria è pertanto duplice:

• introducono un metodo rigoroso e ripetibile per stimare l’impegno dell’attaccante.
• creano una lingua comune che collega vulnerabilità, capacità dell’avversario e rischio reale.

2000 – 2010: diffusione nel Vulnerability Management (CVSS)

Nei primi anni Duemila, il potenziale di attacco varca la soglia dei laboratori di certificazione e inizia a confrontarsi con il caos degli ambienti di produzione. Non più soltanto un criterio per valutare prodotti secondo standard formali, ma una necessità pratica per chi ogni giorno deve rispondere a una domanda elementare: quale vulnerabilità correggere per prima?

Il problema principale è che si accumulavano vulnerabilità note più velocemente di quanto i team potessero correggerle. E non tutte le correzioni erano semplici: molte richiedevano patch complesse, test di regressione, riavvii di servizi critici, finestre di manutenzione negoziate con il business e trattare ogni vulnerabilità come emergenza equivalente significava paralizzare l’operatività o, più realisticamente, ignorare il problema fino al primo incidente. Serviva un criterio per distinguere ciò che richiede intervento immediato da ciò che può attendere, ciò che è concretamente sfruttabile da ciò che resta una possibilità teorica.

Fu in questo contesto che nacque e si diffuse il Common Vulnerability Scoring System (CVSS), sviluppato inizialmente dal NIST e poi standardizzato dal Forum of Incident Response and Security Teams (FIRST). Il CVSS rappresentò il primo tentativo sistematico di portare il potenziale di attacco fuori dai contesti accademici e dentro i Security operations Centre (SOC) e i processi di patch management.

L’idea di fondo era la stessa dei Common Criteria, ovvero non misurare soltanto l’esistenza di una vulnerabilità, ma lo sforzo necessario per sfruttarla. La differenza sostanziale stava nell’obiettivo: i CC valutavano e valutano i prodotti nel loro complesso, mentre il CVSS si applica a singole vulnerabilità scoperte nel mondo reale, fornendo nel contempo una metrica quantitativa, ripetibile e confrontabile. Il risultato era un punteggio numerico da 0 a 10, calcolato combinando diverse dimensioni che descrivono quanto è difficile, concretamente, portare a termine un attacco.

Come si costruisce un punteggio che catturi davvero il potenziale di attacco? Il CVSS, nella sua architettura teorica, lo fa combinando diverse caratteristiche della vulnerabilità raggruppate in tre categorie progressive: metriche base, metriche temporali e metriche ambientali. Queste sono pensate come tre livelli di zoom crescente: dal generale al particolare, dall’astratto al concreto, dalla vulnerabilità in sé alla sua manifestazione nel in un contesto operativo.

Metriche base del CVSS

Le metriche base del CVSS catturano le caratteristiche intrinseche della vulnerabilità, quelle che non cambiano, a prescindere da chi la valuta o quando viene valutata. Tra queste metriche, quattro ne descrivono direttamente il potenziale di attacco:

• Attack Vector indica la distanza dell’avversario: da Internet (massimo potenziale) fino al contatto fisico (minimo);
• Attack Complexity misura quante condizioni particolari servono per far funzionare l’exploit: se basta un pacchetto malformato il rischio è alto, se servono tempistiche o configurazioni rare si abbassa.
• I Privileges Required valutano quanto l’attaccante deve essere già dentro: una falla senza autenticazione amplia il bacino di minacce, una che richiede privilegi limita drasticamente chi può sfruttarla;
• User Interaction distingue tra exploit automatici e quelli che richiedono un clic: quando serve coinvolgere un utente, la frizione aumenta e il potenziale cala.

Combinando queste quattro dimensioni con le metriche di impatto su confidenzialità, integrità, disponibilità delle informazioni, il CVSS restituisce un punteggio base che non riflette la gravità astratta della vulnerabilità, ma la sua accessibilità concreta.

Questa distinzione ebbe un impatto immediato sui processi operativi. I team di sicurezza cominciarono a usare il CVSS per prioritizzare il patching: non tutto subito, ma prima le vulnerabilità con score elevato, ovvero quelle facilmente sfruttabili, quelle esposte a Internet e quelle che non richiedono autenticazione. I vendor iniziarono a includere il punteggio CVSS nei loro security advisory e i tool di vulnerability scanning lo adottarono come metrica standard.
Si creò un linguaggio comune che permetteva di confrontare vulnerabilità su piattaforme eterogenee, settori diversi e contesti operativi differenti.

Le metriche temporali e ambientali: il divario tra teoria e realtà

Qui emerge uno dei paradossi più significativi del CVSS. Il sistema, nella sua progettazione, prevedeva due ulteriori livelli di valutazione: metriche temporali e metriche ambientali. Sulla carta, avrebbero dovuto completare il quadro, trasformando il punteggio base astratto in una stima più accurata del rischio reale. Nella pratica, quasi nessuno le usa.

Le metriche temporali avrebbero dovuto catturare l’evoluzione del rischio nel tempo. Una vulnerabilità appena scoperta, senza exploit pubblici, con patch già disponibile, dovrebbe avere un punteggio temporale più basso del punteggio base. Una vulnerabilità per cui esistono exploit weaponizzati su Metasploit, senza patch disponibile, dovrebbe mantenere o aumentare il punteggio.

Le metriche ambientali avrebbero dovuto permettere a ogni organizzazione di personalizzare il punteggio considerando il proprio contesto specifico: quanto è critico quel sistema per il business? Esistono controlli compensativi che riducono l’esposizione? Quella vulnerabilità con Attack Vector Network è davvero raggiungibile da Internet o è isolata dietro firewall?

Il problema è che calcolare questi punteggi richiede lavoro manuale, valutazioni caso per caso, aggiornamenti continui. E nessuno lo fa. I vendor non pubblicano punteggi temporali perché cambiano troppo rapidamente. Le organizzazioni non calcolano punteggi ambientali perché richiederebbero di analizzare ogni vulnerabilità nel contesto di ogni sistema: un’operazione impossibile da scalare quando si gestiscono migliaia di asset e decine di migliaia di vulnerabilità. Il risultato pratico è che il CVSS, nella sua implementazione reale, si riduce quasi esclusivamente al punteggio base.

2010 – 2020: integrazione nei modelli probabilistici (FAIR)

Il CVSS misura sì la difficoltà tecnica di un attacco, ma ignora due dimensioni fondamentali del rischio: la probabilità che l’attacco si verifichi e l’impatto economico nel caso in cui si verificasse. Due vulnerabilità con lo stesso punteggio CVSS possono rappresentare rischi completamente diversi. Ad esempio, una su un sistema esposto a Internet con dati critici al suo interno e l’altra su un server di test isolato, raggiungibile solo da tre amministratori di sistema, contenente dati fittizi, hanno lo stesso score tecnico, ma un impatto completamente diverso.

In questo contesto il potenziale di attacco ha iniziato a tradursi da metrica tecnica a stima finanziaria, da punteggio statico a modello probabilistico. Ha trovato infatti la sua integrazione in un famoso framework di risk management conosciuto come FAIR (Factor Analysis of Information Risk), uno standard internazionale progettato per quantificare il rischio informatico in termini economici piuttosto che attraverso le tradizionali scale qualitative (alto-medio-basso, rosso-giallo-verde).

Quando i team di sicurezza producono report pieni di vulnerabilità classificate per severità tecnica, heat map colorate, liste di CVE con punteggi CVSS il management chiede: “Va bene, ma quanto ci costa questo rischio? Quale rischio affrontiamo prima se abbiamo budget limitato?” Il linguaggio tecnico della sicurezza non parlava la lingua economica del business e questo gap comunicativo rendeva impossibile prendere decisioni sull’allocazione delle risorse sia finanziarie che umane.

FAIR propose un approccio radicalmente diverso: tradurre ogni rischio in valori monetari. Non più “rischio critico”, ma “perdita annuale attesa tra 500.000 e 2.000.000 di euro con probabilità del 70%”. Questa traduzione finanziaria richiedeva però di scomporre il rischio in componenti più fondamentali e per farlo parte da una definizione semplice ma potente: il rischio è la combinazione di quanto spesso succede qualcosa (frequenza) e quanto fa male quando succede (impatto).

Formalmente il Rischio = Loss Event Frequency × Loss Magnitude.

Frequenza, capacità e resistenza

La Loss Event Frequency (LEF), la frequenza con cui si verifica una perdita, è determinata da due fattori:

Threat Event Frequency (TEF): quanto spesso qualcuno tenta di attaccare questo specifico asset? Qui entrano in gioco considerazioni che il CVSS ignora completamente in quanto un server web pubblico che ospita un e-commerce è oggetto di migliaia di tentativi di attacco ogni giorno, ma un un database interno raggiungibile solo tramite VPN subisce forse uno o due tentativi di accesso non autorizzato all’anno;

Vulnerability (Vuln): data la frequenza dei tentativi, con quale probabilità uno di questi tentativi ha successo? Qui il potenziale di attacco trova la sua nuova dimensione. FAIR non usa il punteggio CVSS direttamente, ma ne riprende l’intuizione fondamentale, articolandola ulteriormente. La vulnerabilità non è più semplicemente “questa falla ha score 9.8”, ma diventa un confronto probabilistico tra due forze opposte:

• Threat Capability (TCap): quanto è capace l’attaccante? Parliamo di un insider con accesso fisico ai server e conoscenza approfondita dell’infrastruttura, o di un attaccante esterno che deve scoprire tutto da zero?
• Resistance Strength (RS): quanto sono forti le difese? Non solo la presenza o assenza della patch per quella specifica vulnerabilità, ma l’intera postura di sicurezza: firewall, segmentazione di rete, MFA, logging e monitoring.

La vulnerabilità, in FAIR, è la probabilità che TCap superi RS. Se l’attaccante medio che tenta di colpire quel sistema ha capacità 6/10 e le difese hanno forza 8/10, la probabilità di successo è bassa. Se l’attaccante medio ha capacità 9/10 e le difese hanno forza 4/10, la probabilità di successo è alta. Stesso sistema, stessa vulnerabilità tecnica, ma potenziale di attacco completamente diverso.

Impatto economico: perdite primarie e secondarie

La Loss Magnitude (LM), l’impatto quando l’attacco riesce, completa il quadro distinguendo tra:

Perdite primarie costi diretti e immediati. Perdita di produttività (quanto tempo serve per ripristinare i sistemi?), costi di risposta all’incidente (quanto costa il team forense esterno? quante ore-uomo interne?), sostituzione di asset compromessi, perdita di dati.

Perdite secondarie costi derivanti dalle reazioni di stakeholder esterni. Sanzioni normative (GDPR, settore finanziario, sanità,..), perdita di quote di mercato perché i clienti si spostano verso competitor percepiti come più sicuri, danni reputazionali, cause legali da parte di clienti o partner, aumento dei premi assicurativi.

Il risultato finale è una stima probabilistica dell’esposizione finanziaria. Questo approccio mira a sbloccare decisioni puramente manageriali dove concetti come Return on Security Investment (ROSI) e “prioritizzazione tra rischi” si devono scontrare con domande importanti come “quale rischio affrontare prima con budget limitato?”.

FAIR introduce però complessità significative, condivise da tutti i modelli quantitativi, che ne hanno limitato l’adozione di massa. Un’analisi di questo tipo richiede tempo, competenze specifiche, raccolta dati manuale intensiva. Bisogna stimare frequenze di attacco, capacità degli attaccanti, forza delle difese, impatti primari e secondari. Molte di queste stime si basano su dati insufficienti, giudizi soggettivi di esperti, estrapolazioni da incidenti storici.

2020 – oggi: estensione ad automotive, OT/ICS, AI (GOE)

Il concetto di potenziale di attacco si trova oggi a confrontarsi con una realtà che i suoi ideatori non avevano previsto: sistemi che si muovono fisicamente, che controllano processi industriali critici, che prendono decisioni autonome usando intelligenza artificiale.

I framework tradizionali, CVSS compreso, erano nati per valutare software che gira su server, workstation, dispositivi di rete. Sistemi IT classici dove una compromissione significa perdita di dati, interruzione di servizi, accesso non autorizzato. Ma cosa succede quando la vulnerabilità non è in un web server che ospita un e-commerce, ma nel sistema di controllo elettronico di un’automobile che viaggia a 130 km/h in autostrada? O nel PLC (Programmable Logic Controller) che gestisce la temperatura di un reattore chimico? O nell’algoritmo di machine learning che decide se approvare un prestito o se segnalare un volto come sospetto?

La superficie di attacco si è espansa oltre il dominio puramente informatico, entrando nel mondo fisico e cognitivo. E con essa, il concetto di potenziale di attacco ha dovuto adattarsi, frammentarsi, specializzarsi per settori con vincoli, minacce e conseguenze radicalmente diversi.

Automotive

Un’automobile moderna contiene decine di ECU (Electronic Control Units) interconnesse che controllano tutto: motore, freni, sterzo, airbag, infotainment, connettività e sempre più spesso, questi sistemi ricevono aggiornamenti Over-The-Air (OTA), esattamente come uno smartphone. Ma a differenza di uno smartphone che crasha, un’automobile compromessa può causare incidenti fisici, feriti. La posta in gioco non è più solo confidenzialità, integrità, disponibilità di dati, ma sicurezza fisica delle persone.

In questo contesto sono nate metodologie specifiche come EVITA (E-safety Vehicle Intrusion Protected Applications) e HEAVENS (HEAling Vulnerabilities to ENhance Software Security and Safety) che introducono un modo diverso di calcolare il potenziale di attacco, più vicino ai Common Criteria originali che al CVSS, ma adattato alle specificità automotive.

Il calcolo del potenziale di attacco in EVITA/HEAVENS si basa sulla somma di cinque parametri:
AP = E + T + K + ER + WO
Dove:
• E (Expertise): quale livello di competenza tecnica serve?
• T (Elapsed Time): quanto tempo serve per portare a termine l’attacco?
• K (Knowledge of the system): quante informazioni sul sistema target deve possedere l’attaccante?
• ER (Equipment Required): quale attrezzatura fisica serve? Strumenti standard facilmente acquistabili, o apparecchiature specializzate costose, laboratori dedicati, chip customizzati?
• WO (Window of Opportunity): quanto accesso fisico o temporale serve? L’attacco può essere eseguito da remoto in qualsiasi momento, o richiede accesso fisico prolungato al veicolo?

Sommando questi cinque parametri, si ottiene un punteggio complessivo di potenziale di attacco. Questa metodologia introduce qualcosa che né CVSS né FAIR catturano esplicitamente: la dimensione fisica del potenziale di attacco. Non basta valutare attack vector (network/local/physical nel CVSS), serve capire quanto accesso fisico, per quanto tempo, con quale attrezzatura.

OT/ICS: dalla sicurezza informatica alla sicurezza industriale

Una evoluzione parallela si è verificata nel mondo dei sistemi di controllo industriale (ICS) e della tecnologia operativa OT: raffinerie, centrali elettriche, impianti di trattamento acque, dighe idroelettriche, stabilimenti chimici, reti di distribuzione,…

Il potenziale di attacco in ambienti OT/ICS richiede considerazioni specifiche che i framework IT tradizionali non catturano:

Safety vs Security un sistema OT deve garantire la sicurezza fisica (safety) prima ancora della sicurezza informatica (security). Questo crea paradossi in quanto un sistema potrebbe essere deliberatamente lasciato vulnerabile; un PLC che controlla una valvola critica potrebbe non richiedere autenticazione forte perché, in caso di emergenza, deve essere possibile intervenire manualmente senza ritardi.

Air-gap illusorio molti sistemi OT si presumono “isolati” (air-gapped), ma nella pratica raramente lo sono. Connessioni temporanee per manutenzione remota, integrazione con sistemi MES (Manufacturing Execution System) che hanno connettività esterna. Il potenziale di attacco deve considerare non solo l’architettura di design, ma la realtà operativa dove gli air-gap sono frequentemente violati per necessità pratiche.

Longevità dei sistemi un server IT ha lifecycle di 3-5 anni, ma un SCADA o un PLC può operare per 20-30 anni, spesso senza mai essere patchato perché gli aggiornamenti richiedono fermi produzione costosi o perché il vendor non esiste più. Questo significa che vulnerabilità scoperte oggi resteranno sfruttabili per decenni, aumentando progressivamente il potenziale di attacco man mano che diventano note, documentate, automatizzate.

Impact asimmetrico: in IT, l’impatto di un attacco è spesso correlato alla complessità dell’attacco stesso. In OT, un attacco relativamente semplice (modificare un setpoint di temperatura di pochi gradi) può causare conseguenze catastrofiche se eseguito al momento giusto nel processo industriale. Il potenziale di attacco non dipende solo dalla difficoltà tecnica, ma dalla comprensione del processo fisico controllato.

AI e automazione degli attacchi: il Graph of Effort (GOE)

L’ultimo dominio dove il concetto di potenziale di attacco sta subendo una trasformazione radicale è quello dell’intelligenza artificiale, ma non come bersaglio degli attacchi (AI security), bensì come strumento degli attaccanti (Offensive AI).
L’intelligenza artificiale sta abbassando drasticamente le barriere d’ingresso per molte fasi della kill chain degli attacchi. Attività che tradizionalmente richiedevano competenze specialistiche, tempo, risorse umane, stanno diventando automatizzabili, scalabili, accessibili anche ad attaccanti meno qualificati.

In questo contesto, è emersa una metodologia recente chiamata Graph of Effort (GOE), proposta specificamente per quantificare come l’AI riduce il potenziale di attacco (nel senso di effort richiesto all’attaccante).
GOE utilizza un albero decisionale binario per calcolare un punteggio di “sforzo” per ogni fase della kill chain (ricognizione, weaponization, delivery, exploitation), valutando tre dimensioni:

• AT (Automation Tool exists): esiste già uno strumento che automatizza questa fase? Se sì, lo sforzo è zero. Se no, si valuta se l’AI può colmare il gap.
• TAI (Trainable AI): è possibile addestrare un modello di AI per eseguire questa fase? Se sì, lo sforzo si riduce ma non è zero (serve expertise per preparare dati, addestrare, validare il modello).
• G (Generatable data): i dati necessari per addestrare l’AI sono generabili sinteticamente o facilmente reperibili? Se sì, lo sforzo scende ulteriormente. Se no (dati rari, sensibili, difficili da ottenere), lo sforzo resta elevato anche con AI.

Combinando queste tre dimensioni, GOE assegna un punteggio da 0 (completamente automatizzato, sforzo minimo) a 3 (manuale, richiede expertise umana significativa) per ogni fase dell’attacco. Un punteggio complessivo basso indica che l’AI ha ridotto drasticamente il potenziale di attacco (inteso come sforzo richiesto), democratizzando tecniche prima riservate ad attaccanti sofisticati.
Questo ribalta parzialmente la prospettiva tradizionale: mentre CVSS, FAIR, EVITA misurano quanto è difficile per l’attaccante avere successo, GOE misura quanto l’AI sta riducendo quella difficoltà nel tempo.

Conclusioni

La frammentazione dei diversi modelli di valutazione del potenziale di attacco è inevitabile, ma problematica in quanto le organizzazioni che operano in più domini (un’azienda automotive che gestisce anche infrastruttura IT e sistemi di produzione OT) si trovano a dover gestire metriche incompatibili, framework non integrabili e report non confrontabili.

Non esiste ancora una risposta soddisfacente. Alcuni vendor stanno tentando di creare “traduttori” tra metriche, mappando CVSS su EVITA, EVITA su FAIR, ma le assunzioni sottostanti sono così diverse che le conversioni spesso perdono di significato. Il potenziale di attacco, nato come concetto unificante per descrivere lo sforzo richiesto all’attaccante, si trova oggi spezzettato in dialetti verticali che parlano lingue sempre meno compatibili.

E questo è forse il paradosso finale: più il concetto maturo, sofisticato e si adatta a contesti specifici, più perde la sua forza originaria di lingua comune. Il futuro del potenziale di attacco probabilmente non sarà un singolo framework universale, ma un ecosistema di metodologie specializzate, collegate da traduzioni imperfette, unite solo dall’intuizione fondamentale che le ha generate, ovvero capire quanto è difficile, davvero, che qualcuno riesca a farci del male.