Vulnerability Assessment: cos’è, come funziona e quando serve

Il vulnerability assessment (VA) risponde a una domanda semplice: quali debolezze tecniche esistono oggi nella mia infrastruttura e quali vanno chiuse per prime. Sembra banale, ma nella maggior parte degli incidenti che colpiscono le PMI italiane l’accesso iniziale sfrutta una vulnerabilità nota da mesi, un servizio pubblicato che nessuno ricordava o una configurazione debole mai verificata. Il VA serve a vedere queste cose prima che le veda qualcun altro.

Cosa si intende per vulnerability assessment

Un vulnerability assessment è un’attività tecnica strutturata in cui sistemi e servizi compresi in un perimetro definito vengono analizzati alla ricerca di vulnerabilità note (CVE), software non aggiornato, protocolli legacy, configurazioni deboli ed esposizioni non necessarie. Ogni rilevazione viene poi verificata, per ridurre i falsi positivi, e classificata per gravità e priorità operativa.

Il termine viene spesso confuso con due cose diverse:

• Vulnerability scan: è solo la fase automatica. Uno scanner produce una lista; l’assessment la trasforma in decisioni.
• Penetration test: verifica se una debolezza è sfruttabile davvero e con quale impatto. Il VA misura l’ampiezza dell’esposizione, il PT ne misura la profondità. La differenza è spiegata punto per punto nella guida Vulnerability Assessment vs Penetration Test.

Come funziona un vulnerability assessment: le fasi

1. Scoping

Si definiscono asset, subnet, IP pubblici, esclusioni, finestre operative e criteri di stop. Senza uno scope scritto non esiste un assessment, esiste una scansione.

2. Discovery

Mappatura degli host e dei servizi realmente presenti. Qui emergono gli asset dimenticati: il vecchio portale di test ancora pubblicato, la stampante con l’interfaccia web esposta, il server fuori supporto che «non usa più nessuno».

3. Scansione

Uso di scanner professionali con profili coerenti allo scope. Può essere non autenticata (ciò che vede un attaccante dall’esterno) o autenticata (con credenziali: visibilità su patch, pacchetti, configurazioni locali). In molti assessment interni si usano entrambe. Exploit attivi e test di disponibilità restano esclusi.

4. Validazione

I finding significativi vengono riesaminati: versione reale del software, condizioni necessarie allo sfruttamento, presenza di controlli compensativi. È la fase che distingue un assessment da un PDF di 400 pagine.

5. Prioritizzazione

I finding validati vengono messi in coda di lavoro incrociando gravità tecnica, sfruttamento osservato ed esposizione dell’asset: non in semplice ordine di CVSS. Il criterio è spiegato nella sezione successiva.

6. Report e retest

Consegna, sessione di restituzione con il team IT e, dopo la remediation, rescan delle vulnerabilità corrette.

Cosa rileva davvero un vulnerability assessment

• Patch mancanti e sistemi fuori supporto (OS, hypervisor, apparati, application server).
• Servizi esposti su Internet che non dovrebbero esserlo (RDP, database, pannelli di gestione, VPN con versioni vulnerabili).
• Configurazioni deboli: TLS obsoleto, SMBv1, cifrari deboli, credenziali di default, SNMP pubblico.
• Componenti web vulnerabili: librerie, framework e CMS non aggiornati.
• Esposizioni cloud e identità a livello preliminare (tenant, MFA, account legacy), da approfondire con assessment dedicati.

Cosa non rileva: errori di logica applicativa, catene di attacco tra più debolezze, movimento laterale. Per questi serve un penetration test o un WAPT.

Perché il CVSS da solo non basta: come si ordinano i finding

Il punteggio CVSS misura la gravità tecnica astratta di una vulnerabilità, non quanto è urgente per la tua azienda. Un VA utile incrocia almeno quattro segnali:

Il risultato è una coda di lavoro in quattro livelli: criticità da chiudere subito (Internet-facing + KEV), exploit disponibile su asset critico, remediation pianificabile, rischio mitigato o accettato.

Cosa contiene il report di un vulnerability assessment

Un report leggibile ha due lettori: la direzione e il team IT. Deve contenere:

1. Executive summary: livello di esposizione, numero di finding per severità, decisioni richieste.
2. Perimetro e asset: cosa è stato analizzato e cosa no.
3. Finding validati: asset, CVE/CWE, CVSS, EPSS, presenza in KEV, evidenza, rilevanza per il business.
4. Priorità operativa distinta dalla severità.
5. Remediation: patch, upgrade, hardening, disabilitazione servizi, segmentazione, mitigazioni temporanee.
6. Quick win ad alto impatto e basso sforzo.
7. Roadmap con tempi concordabili e retest.

Un esempio di come si presenta la sintesi: Critical 2 · High 7 · Medium 18 · Low 24, con i 2 critical entrambi Internet-facing e in KEV → priorità P0, remediation entro 72 ore, retest programmato.

Ogni quanto va ripetuto

Non esiste una frequenza universale. Dipende da esposizione Internet, velocità dei cambiamenti, criticità degli asset e capacità di remediation. In pratica: un assessment one-shot crea la baseline; per perimetri Internet-facing o in evoluzione la scansione ricorrente (mensile o trimestrale) misura il tempo di esposizione e verifica che il patch management funzioni davvero.

Vulnerability assessment, NIS2, ISO 27001 e GDPR

La NIS2 (art. 21) include la gestione e divulgazione delle vulnerabilità tra le misure di gestione del rischio; per i soggetti coperti dal Regolamento di esecuzione (UE) 2024/2690 sono previsti, ove appropriato, vulnerability scan pianificati con registrazione dei risultati. ISO/IEC 27001:2022 tratta il vulnerability management tra i controlli tecnici dell’Annex A; il GDPR (art. 32) richiede misure adeguate al rischio. In nessun caso il VA da solo «rende conformi»: è l’evidenza tecnica di un processo. Per obblighi e scadenze: guida NIS2 per le PMI.

Chi lo esegue e cosa serve per partire

Serve un perimetro (IP pubblici/FQDN, subnet, numero di server ed endpoint), un referente tecnico, le finestre operative e la decisione su scansioni autenticate. Con questi dati il servizio si dimensiona in modo preciso.