Le vulnerabilità non sono tutte uguali

TL;DR Le vulnerabilità cyber non sono tutte uguali e vanno sempre valutate secondo il proprio contesto di riferimento. Le metriche dei sistemi di valutazione, come CVSS, vanno sempre interpretate senza fermarsi alla cifra finale del base score.

Uno degli aspetti spesso più sottovalutato è la reale criticità di un vulnerabilità. Come ben sappiamo, nuove vulnerabilità vengono scoperte quotidianamente, alcune più critiche altre meno. Ma su quali basi si fonda la criticità di una vulnerabilità?

Abbiamo, per stabilire la criticità secondo criteri oggettivi, framework di valutazione come CVSS, Common Vulnerability Scoring System, che per ogni vulnerabilità assegna un valore a specifiche metriche per il calcolo di punteggi[1] in modo analitico.

Ad esempio, il base score per il CVSSv3, valore da 0 (minima gravità) a 10 (massima gravità), è dato da queste metriche:

Attack Vector (AV)
Attack Complexity (AC)
Privileges Required (PR)
User Interaction (UI)
Scope (S)
Confidentiality (C)
Integrity (I)
Availability (A)

per il temporal score in CVSSv3 si considerano invece queste metriche:

Exploit Code Maturity (E)
Remediation Level (RL)
Report Confidence (RC)

a cui si aggiunge la environmental score, metrica relativa al contesto:

Confidentiality Requirement (CR)
Integrity Requirement (IR)
Availability Requirement (AR)
Modified Attack Vector (MAV)
Modified Attack Complexity (MAC)
Modified Privileges Required (MPR)
Modified User Interaction (MUI)
Modified Scope (MS)
Modified Confidentiality (MC)
Modified Integrity (MI)
Modified Availability (MA)

Le differenti metriche servono a misurare differenti aspetti relativi ad una vulnerabilità ed a valutare il rischio (dato da probabilità per impatto) per la nostra situazione.

Ad esempio, una vulnerabilità come la CVE-2023-27992, il cui punteggio totale del base score è 9.8 (quindi una vulnerabilità critica) ha le metriche CVSS3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H che, scorporate, significano:

AV:N = il vettore di attacco è la rete;
AC:L = la complessità dell’attacco è low, bassa;
PR:N = nessuno privilegio richiesto per compiere l’attacco;
UI:N = nessuna interazione utente necessaria per l’exploiting;
S:U = l’exploiting della vulnerabilità coinvolge altre risorse all’interno del medesimo contesto di sicurezza;

per poi valutare i tre elementi della triade CIA relativi alle informazioni contenute nel dispositivo attaccato:

C:H = la perdita di confidenzialità delle informazioni coinvolte nell’attacco è totale, high;
I:H = la perdita di integrità delle informazioni coinvolte nell’attacco è totale, high;
A:H = il rischio di perdita dell’accessibilità è totale, high;

Parliamo di una vulnerabilità piuttosto grave che coinvolge dispositivi NAS della Zyxel, descritta così: “The pre-authentication command injection vulnerability in the Zyxel NAS326 firmware versions prior to V5.21(AAZF.14)C0, NAS540 firmware versions prior to V5.21(AATB.11)C0, and NAS542 firmware versions prior to V5.21(ABAG.11)C0 could allow an unauthenticated attacker to execute some operating system (OS) commands remotely by sending a crafted HTTP request.“

Se uno score di 9.8 su 10 può farci sobbalzare sulla sedia, soprattutto se nel nostro contesto abbiamo apparati di questo tipo, ma valutazione del rischio che essa possa essere sfruttata dipende da alcuni fattori:

gli apparati in nostro possesso sono suscettibili a questa vulnerabilità? Una verifica è necessaria per assicurarsi che le versioni vulnerabili siano quelle attualmente presenti e, nel caso, verificare la presenza di aggiornamenti disponibili.

gli apparati vulnerabili sono accessibili on-the-wild oppure sono accessibili solo da rete interna? E’ evidente che una vulnerabilità su apparati/servizi esposti on-the-wild ha un rischio maggiore di essere sfruttata.

esiste una PoC con cui verificare lo sfruttamento della vulnerabilità? Qui ci viene in aiuto il KEV –Known Exploitable Vulnerabilities catalog– del NIST[2], che raccoglie le vulnerabilità exploited in the wild.

a cui, poi, va effettuata una valutazione sulle azioni di risoluzione/mitigazione della vulnerabilità, ovvvero:

quale impatto ha sulla business continuity l’operazione di risoluzione della vulnerabilità? Nel caso l’applicazione di una patch e/o di un aggiornamento possa impattare in modo rilevante, l’operazione va pianificata attentamente[3].

le conseguenze di una violazione/sfruttamento della vulnerabilità sono superiori al costo di risoluzione della stessa? Certe volte ci sono delle vulnerabilità, fortunamente non sempre critiche, la cui risoluzione comporta un lavoro piuttosto oneroso e rischi non trascurabili. Costi che talvolta sono superiori al rischio che vi sia un reale sfruttamento della vulnerabilità stessa.

Niente di nuovo per chi è nel settore, considerando che parliamo di quanto ampiamente definito in molti framework di cybersecurity, tra cui il NIST. Tuttavia spesso mi capita di confrontarmi con persone che si concentrano sullo score di un vulnerabilità senza contestualizzarla, che è una delle valutazioni che solamente chi è ben consapevole del contesto e dei potenziali rischi può fare.

E’ anche uno dei motivi per i quali l’assets management rappresenta un elemento critico di ogni cyber risk assesment, poiché senza la conoscenza puntuale del contesto di riferimento è impossibile comprendere e valutare a pieno l’impatto che una nuova vulnerabilità può avere sulla infrastruttura. Così come la definizione delle procedure e criteri per change and configuration management[3], essenziale per evitare conseguenze alla business continuity durante eventuali modifiche ai sistemi.

Spero che questo articolo, decisamente incompleto e parziale, possa comunque aiutare a comprendere al meglio come la valutazione delle vulnerabilità deve essere sempre calato nel contesto di riferimento.

[1] Common Vulnerability Scoring System Version 3.1 Calculator
[2] Known Exploited Vulnerabilities Catalog
[3] CISA – Configuration and change management