Report vulnerability assessment: come leggerlo con CVSS

Il vulnerability assessment è concluso e il report è arrivato: decine di pagine, sigle, punteggi, colori. La tentazione è contare le voci in rosso e girare tutto al fornitore IT.

Sarebbe un'occasione persa. Un report di vulnerability assessment è uno strumento di decisione: indica dove intervenire per primo, cosa può attendere e come dimostrare di avere la situazione sotto controllo.

La struttura del report

Un report completo contiene di norma:

• perimetro e metodo: sistemi analizzati, modalità (white box, gray box o black box) e periodo;
• sintesi dei risultati: numero di vulnerabilità per livello di gravità;
• schede delle vulnerabilità: descrizione, sistemi coinvolti, evidenze, punteggio, indicazioni di remediation;
• valutazione del rischio: peso di ogni problema nel contesto aziendale;
• raccomandazioni e priorità.

Conviene leggere per primo il perimetro. Un report descrive solo i sistemi analizzati, nel momento dell'analisi. Ciò che resta fuori perimetro non è "sicuro": semplicemente non è stato valutato.

Il punteggio CVSS

Il CVSS (Common Vulnerability Scoring System) è lo standard gestito da FIRST per esprimere la gravità di una vulnerabilità con un punteggio da 0,0 a 10,0. La versione più diffusa nei report è la 3.1; nel novembre 2023 FIRST ha pubblicato la versione 4.0, in progressiva adozione.

I livelli di gravità

La scala qualitativa, identica in CVSS v3.1 e v4.0:

• 0,0: nessuna (None);
• 0,1 – 3,9: bassa (Low);
• 4,0 – 6,9: media (Medium);
• 7,0 – 8,9: alta (High);
• 9,0 – 10,0: critica (Critical).

Le metriche

In CVSS v3.1 il punteggio deriva da tre gruppi di metriche:

• Base: caratteristiche intrinseche della vulnerabilità, come sfruttabilità dalla rete, complessità, privilegi o interazione richiesti, impatto su riservatezza, integrità e disponibilità;
• Temporal: elementi che cambiano nel tempo, come la disponibilità di exploit o di una correzione;
• Environmental: adattamento all'ambiente specifico, ad esempio l'importanza del sistema coinvolto.

In CVSS v4.0 il gruppo Temporal diventa Threat e si aggiunge un gruppo Supplemental, con informazioni che non modificano il punteggio. La v4.0 introduce anche una nomenclatura che chiarisce le metriche utilizzate: CVSS-B, CVSS-BT, CVSS-BE e CVSS-BTE.

Accanto al punteggio compare spesso il vettore, una stringa che inizia ad esempio con "CVSS:3.1/AV:N/AC:L", utile a rendere il calcolo verificabile.

Gravità non significa rischio

La specifica CVSS v3.1 è esplicita: il CVSS misura la gravità di una vulnerabilità e non dovrebbe essere usato da solo per valutare il rischio. Il punteggio Base pubblicato nei database è uguale per tutti; il rischio dipende invece da dove si trova il sistema, da cosa contiene e da chi può raggiungerlo.

Dalla gravità alla priorità

Per questo un buon report affianca al CVSS un'analisi del rischio contestualizzata. Due esempi di ragionamento:

• una vulnerabilità alta su un server esposto su internet con dati di clienti o di progetto merita precedenza rispetto a una critica su una macchina di test isolata e spenta;
• una vulnerabilità media presente su molte postazioni e sfruttabile senza autenticazione può richiedere più attenzione di quanto suggerisca il punteggio.

Le domande che orientano la priorità riguardano l'esposizione del sistema, la sua criticità per l'azienda, l'esistenza di exploit noti o di sfruttamento attivo, la disponibilità di una correzione e la presenza di misure che già riducono il rischio, come segmentazione o autenticazione a più fattori.

Il piano di rientro

Il piano di rientro trasforma il report in azioni. Per ogni vulnerabilità, o gruppo di vulnerabilità simili, si definiscono azione, responsabile (interno o fornitore IT), scadenza coerente con la priorità e stato (aperta, in corso, chiusa, rischio accettato).

Alcuni principi utili:

• raggruppare: spesso molte vulnerabilità si chiudono con un unico aggiornamento o modifica di configurazione;
• documentare il rischio accettato: quando una correzione non è possibile, ad esempio su un sistema legacy, vanno registrati motivazione, misure compensative e responsabile della decisione;
• verificare la chiusura: una vulnerabilità risulta chiusa quando una nuova verifica lo conferma;
• ripetere il VA periodicamente per misurare i progressi.

Un piano di rientro tracciato è anche un'evidenza preziosa. La ISO/IEC 27001:2022 dedica un controllo alla gestione delle vulnerabilità tecniche, la NIS 2 la include tra le misure di sicurezza e il catalogo VDA ISA per l'assessment TISAX® prevede requisiti analoghi. In tutti i casi conta dimostrare un processo, non un singolo report.

Il servizio di General Tech di Rosario Zappalà

Nel vulnerability assessment condotto da Rosario Zappalà, consulente indipendente con competenze Red Team e Blue Team, il report non arriva come un allegato da decifrare. Dopo autorizzazione formale scritta, analisi degli asset, scansioni, verifica manuale e classificazione CVSS v3.1 con analisi del rischio contestualizzata, l'azienda riceve report tecnico, executive summary per la direzione, calcolo del rischio e una sessione di presentazione in cui vengono condivise le priorità e impostato il piano di rientro. Il VA è una valutazione, non una certificazione.

Domande frequenti

Tutte le vulnerabilità del report vanno corrette?

Non necessariamente, e non tutte subito. Si interviene in base alla priorità di rischio; le vulnerabilità non corrette vanno documentate come rischio accettato, con motivazione ed eventuali misure compensative.

Perché il punteggio CVSS del report differisce da quello pubblicato online?

Il punteggio pubblico è di solito il Base, uguale per tutti. Nel report la valutazione può considerare ambiente e contesto di sfruttamento: è proprio questo il valore aggiunto.

Cosa cambia con CVSS v4.0?

La v4.0 rende più precisa la valutazione e rinomina il gruppo Temporal in Threat; la scala di gravità resta invariata. Punteggi calcolati con versioni diverse non vanno confrontati direttamente.

Il report è utile per TISAX o NIS 2?

È un'evidenza utile, soprattutto se accompagnato da un piano di rientro tracciato e da VA ripetuti nel tempo. Da solo non basta: serve un processo di gestione delle vulnerabilità inserito nel sistema di gestione della sicurezza.