Severity delle vulnerabilità: da dove cominciare a intervenire

Quando un report di sicurezza arriva sul tavolo, la prima cosa che si guarda è la colonna dei punteggi. Sembra il criterio più ovvio: si parte dai numeri alti e si scende. È anche il criterio che porta a intervenire nell’ordine sbagliato.

La severity di una vulnerabilità e il rischio che quella vulnerabilità rappresenta per voi sono due cose diverse. La prima è una proprietà del difetto, calcolata una volta e valida per chiunque lo abbia nei propri sistemi. Il secondo dipende da dove si trova quel difetto, da cosa protegge e da cosa avete già in piedi attorno.

Vediamo cosa misura davvero un punteggio di gravità, cosa gli manca, e come si passa da una lista di severity a una scala di priorità su cui il reparto IT può lavorare.

1. Cosa misura la severity
2. Perché la severity non è il rischio
3. I quattro elementi che trasformano una severity in un rischio
4. Le due liste che avete in mano
5. Come si costruisce una scala utilizzabile

Cosa misura la severity

La severity esprime quanto è grave un difetto in sé. Lo standard più usato per calcolarla è il Common Vulnerability Scoring System, che assegna un punteggio da 0 a 10 valutando caratteristiche intrinseche: da dove si può sfruttare la vulnerabilità, quanto è complicato farlo, se serve un’autenticazione, se serve che un utente compia un’azione, e cosa comporta lo sfruttamento in termini di riservatezza, integrità e disponibilità.

Tutte queste caratteristiche riguardano la vulnerabilità, non voi. Il punteggio di una falla in una libreria è identico per un’azienda di dieci persone e per una multinazionale, perché descrive il difetto e non il contesto in cui si trova.

È una scelta deliberata dello standard, e ha senso: serve un linguaggio comune, così che quando qualcuno dice “critica” tutti intendano la stessa cosa. Il problema nasce quando quel numero viene usato per decidere in che ordine intervenire.

Perché la severity non è il rischio

Provate a considerare due vulnerabilità nello stesso report. La prima ha punteggio alto e si trova su un ambiente di collaudo isolato, che non contiene dati veri e non è raggiungibile dall’esterno. La seconda ha punteggio medio e si trova sul portale con cui i vostri clienti accedono ai propri documenti.

Ordinando per punteggio, si interviene prima sulla prima. Ordinando per rischio, si interviene prima sulla seconda.

Il punteggio dice quanto è grave il difetto, il rischio dice quanto vi costa se qualcuno lo sfrutta. Sono la stessa informazione solo nel caso in cui tutti i vostri sistemi abbiano lo stesso valore e la stessa esposizione, che è una condizione che non si verifica in nessuna azienda reale.

C’è poi un secondo elemento che il punteggio base non contiene: se quella vulnerabilità viene effettivamente sfruttata nel mondo. Esistono difetti con punteggio alto per cui non è mai comparso uno strumento di attacco funzionante, e difetti con punteggio medio che compaiono in campagne attive da settimane. Su questo esistono riferimenti specifici, e il ragionamento completo è nell’articolo su CVSS, EPSS e CISA KEV.

I quattro elementi che trasformano una severity in un rischio

Per passare dal punteggio alla priorità servono quattro informazioni che nessuno standard può avere, perché riguardano solo voi.

L’ultima riga è quella che cambia le carte in tavola più spesso. Un sistema di poco valore, con una vulnerabilità di punteggio medio, ma collocato in una porzione di rete da cui si arriva ai sistemi centrali, vale in priorità più di una falla grave su una macchina che non parla con nessuno.

Verificarlo però non si fa leggendo un report: si fa provando ad arrivarci. È la differenza fra sapere che una porta è aperta e sapere cosa c’è dietro, ed è quello che fa un penetration test a partire da una vulnerabilità individuata.

Le due liste che avete in mano

Dopo un’analisi di sicurezza un’azienda si trova con un elenco di rilievi. Quell’elenco può arrivare in due forme molto diverse, e la differenza si vede al primo sguardo.

La prima è la lista ordinata per punteggio: quaranta voci, dalla più alta alla più bassa, ciascuna con la descrizione standard della vulnerabilità e il rimedio indicato dal produttore. È corretta e completa, e non dice da dove cominciare. Chi la riceve la legge, si spaventa alle prime cinque righe, e poi la archivia.

La seconda è la lista ordinata per contesto: le stesse quaranta voci, ma raggruppate in base a cosa conviene fare prima, con l’indicazione di quali sono raggiungibili da fuori, quali sono state verificate come realmente sfruttabili, e quali si possono contenere in attesa di una finestra di aggiornamento.

La seconda lista non si genera: si scrive. Richiede che qualcuno abbia guardato la rete, capito cosa fa ciascun sistema e provato le vulnerabilità una per una. È il motivo per cui il numero di rilievi non è un indicatore di qualità di un report, e il tema è affrontato per esteso a proposito dei limiti degli assessment automatici.

Come si costruisce una scala utilizzabile

Il criterio pratico è uno: la scala di priorità deve corrispondere a quello che il reparto IT può effettivamente fare nelle prossime settimane. Una lista di quaranta interventi tutti urgenti non è una scala, è un elenco.

Il modo che funziona è ridurre a tre gruppi. Il primo contiene quello che va chiuso subito, e per essere utile deve restare corto: vulnerabilità raggiungibili dall’esterno, verificate come sfruttabili, su sistemi che trattano dati o sostengono l’attività. Il secondo contiene quello che entra nella prossima finestra di manutenzione programmata. Il terzo contiene quello che resta e va tenuto sotto osservazione, con la decisione di non intervenire subito messa per iscritto insieme al motivo.

Quel terzo gruppo è la parte che le aziende trascurano, e serve più di quanto sembri. Un rilievo che nessuno ha corretto e di cui nessuno ha scritto perché è indistinguibile da un rilievo che nessuno ha visto. La differenza fra i due la fa una riga di documentazione, e conta quando arriva un audit o un questionario di un cliente.

Va infine ricordato che la scala non regge nel tempo. Cambia quando cambia l’esposizione di un sistema, quando compare uno strumento di attacco per una vulnerabilità che sembrava teorica, e quando l’infrastruttura si modifica. Per i soggetti che rientrano nella direttiva NIS 2 la gestione delle vulnerabilità è fra le misure di sicurezza di base da avere operative, e operative significa ripetute, non fatte una volta.