Risposta rapida
Un vulnerability assessment è utile quando risponde a tre domande: cosa è esposto, quali vulnerabilità sono reali e quali vanno chiuse per prime. Questa checklist raccoglie i 25 controlli che servono per arrivarci, divisi in cinque blocchi, e una matrice di priorità con quattro fasce di intervento: 7, 30, 90 e 180 giorni.
Il blocco sulla priorità è quello che più spesso manca nei report alle PMI. Il punteggio CVSS dice quanto è grave una vulnerabilità in astratto, non quanto è urgente nella tua rete. Per decidere l’ordine degli interventi la checklist usa anche lo sfruttamento reale (catalogo KEV della CISA ed EU KEV di ENISA), la probabilità di sfruttamento (EPSS) e le quattro variabili del modello che la CISA ha adottato a giugno 2026 con la BOD 26-04. Ne nasce una matrice con quattro fasce di intervento: 7, 30, 90 e 180 giorni.
Come usare la checklist
Ogni controllo ha tre voci: perché conta, come si verifica, quale evidenza conservare. Puoi usarla in due modi:
- prima del vulnerability assessment, per definire il perimetro e le regole con chi lo esegue;
- dopo, per capire se il report che hai ricevuto è completo e se il piano di remediation regge.
Se parti da zero, leggi prima cos’è e come funziona un vulnerability assessment. Il vulnerability assessment rileva e ordina le vulnerabilità, ma non le sfrutta: per verificare cosa può fare davvero un attaccante serve un penetration test (le differenze, in breve).
Blocco 1: Perimetro e inventario
Un assessment vale quanto il perimetro da cui parte: ciò che non è nell’inventario non viene scansionato, e di solito è proprio ciò che nessuno aggiorna.
| Controllo | Perché conta | Come si verifica | Evidenza da conservare |
|---|---|---|---|
| 1. Inventario di IP pubblici e FQDN | Non si protegge ciò che non si sa di avere esposto. | Confronto tra elenco interno, record DNS pubblici, range IP del provider e una discovery dall’esterno. | Elenco datato degli asset in scope, con un referente per ciascuno. |
| 2. Servizi esposti senza motivo | RDP, SMB, pannelli di amministrazione e interfacce di gestione di firewall e VPN sono tra i primi bersagli. | Scansione delle porte sul perimetro e confronto con i servizi autorizzati. | Elenco dei servizi esposti con la motivazione o la data di chiusura. |
| 3. Sottodomini e asset dimenticati | Ambienti di test, vecchi portali e sottodomini che puntano a servizi dismessi restano fuori dal patching. | Enumerazione dei sottodomini (DNS, certificate transparency) e verifica di cosa risponde. | Elenco degli asset trovati, con la decisione: dismettere, aggiornare o includere. |
| 4. Certificati e TLS | Certificati scaduti, protocolli obsoleti e cifrari deboli sono finding frequenti e veloci da chiudere. | Test TLS su ogni servizio HTTPS e VPN esposto. | Versioni TLS attive e scadenze dei certificati. |
| 5. Servizi SaaS e applicazioni gestite da terzi | Sono nel perimetro di rischio, ma non si possono scansionare senza il permesso di chi li gestisce. | Per ogni servizio: chi lo gestisce e se il contratto consente test. Senza autorizzazione si passa alla valutazione del fornitore. | Autorizzazioni scritte, oppure questionario di sicurezza del fornitore. |
Blocco 2: Scansione
La scansione è la parte automatica dell’assessment: va impostata in modo da vedere abbastanza senza fermare la produzione.
| Controllo | Perché conta | Come si verifica | Evidenza da conservare |
|---|---|---|---|
| 6. Regole d’ingaggio scritte | Fissano perimetro, esclusioni, finestre, intensità, referenti e criteri di stop: tutelano l’azienda e chi esegue il test. | Documento approvato prima dell’avvio. | Regole d’ingaggio firmate. |
| 7. Scansione autenticata dove serve | Senza credenziali lo scanner vede solo ciò che risponde in rete, non le patch mancanti sul sistema. | Account dedicato con i soli privilegi necessari; percentuale di host su cui l’accesso è riuscito. | Elenco degli host con l’esito dell’autenticazione. |
| 8. Protezione degli apparati fragili | PLC, sistemi OT, telecamere e stampanti possono bloccarsi sotto una scansione aggressiva. | Profili con safe check, limiti di velocità, esclusioni o finestre dedicate. | Elenco degli asset esclusi o trattati a parte, con la motivazione. |
| 9. Copertura degli endpoint | Le postazioni sono spesso il punto d’ingresso: una scansione solo sui server lascia fuori una parte del rischio. | Confronto tra host scansionati e inventario, o console di gestione degli endpoint. | Percentuale di copertura per categoria di asset. |
| 10. Componenti web, non logica applicativa | Lo scanner trova versioni vulnerabili di librerie, CMS e configurazioni HTTP; la logica dell’applicazione richiede un Web Application Penetration Test. | Elenco delle applicazioni web in scope e di ciò che resta fuori. | Limiti del test dichiarati nel report. |
Blocco 3: Sistemi Windows e identità
Nelle PMI con infrastruttura Microsoft il rischio più alto si concentra su pochi server: i domain controller e i sistemi rimasti senza aggiornamenti.
| Controllo | Perché conta | Come si verifica | Evidenza da conservare |
|---|---|---|---|
| 11. Patch di server e domain controller | I domain controller sono gli asset più critici della rete: una patch mancante lì pesa più di molte sulle postazioni. | Scansione autenticata dei domain controller e confronto con gli ultimi aggiornamenti cumulativi. | Elenco dei server con la data dell’ultimo aggiornamento. |
| 12. Protocolli legacy attivi | SMBv1, NTLMv1, LLMNR e NetBIOS facilitano il furto di credenziali e il movimento laterale. | Verifica di configurazione sui sistemi; il vulnerability assessment li rileva, non li sfrutta. | Elenco dei sistemi con protocolli legacy e piano di dismissione. |
| 13. Sistemi fuori supporto | Un sistema senza aggiornamenti di sicurezza accumula vulnerabilità che non verranno corrette. | Inventario delle versioni di sistema operativo e software; per ciascuno: aggiornamento, isolamento, aggiornamenti estesi o micropatch. | Elenco con data di fine supporto e misura adottata. |
Per le verifiche approfondite su Active Directory (deleghe, account privilegiati, percorsi di attacco) usa la checklist per l’assessment di Active Directory.
Blocco 4: Prioritizzazione
Un report che ordina i finding solo per CVSS produce una coda che nessun team IT di una PMI riesce a smaltire: la priorità nasce dall’incrocio di sei segnali.
| Controllo | Perché conta | Come si verifica | Evidenza da conservare |
|---|---|---|---|
| 14. Severità tecnica (CVSS) | Il CVSS, versione 4.0 o 3.1, misura quanto è grave una vulnerabilità in astratto, non quanto è urgente nella tua rete. | Il report riporta punteggio e vettore, non solo “critica” o “alta”. | Punteggio e vettore CVSS per ogni finding. |
| 15. Sfruttamento noto: CISA KEV ed EU KEV | Una vulnerabilità già usata negli attacchi viene prima di una più grave mai sfruttata. | Incrocio dei CVE con il catalogo Known Exploited Vulnerabilities della CISA e con le vulnerabilità sfruttate pubblicate da ENISA nell’EUVD. | Colonna “sfruttata”: sì o no, fonte e data. |
| 16. Probabilità di sfruttamento (EPSS) | EPSS, mantenuto da FIRST, stima la probabilità che un CVE venga sfruttato nei 30 giorni successivi. Aiuta a ordinare i finding non ancora in KEV. | Punteggio e percentile EPSS alla data del report. | Valore EPSS con la data, perché cambia ogni giorno. |
| 17. Esposizione dell’asset | La stessa vulnerabilità su un server raggiungibile da Internet e su uno isolato non ha la stessa urgenza. | Per ogni finding: l’asset è raggiungibile da Internet? | Colonna “esposto”: sì o no. |
| 18. Attacco automatizzabile e impatto tecnico | Sono le due variabili del modello CISA meno usate nei report alle PMI: se l’attacco si può automatizzare e se dà il controllo totale del sistema o solo parziale. | La CISA pubblica per ogni CVE la valutazione di automatizzabilità e impatto tecnico (programma Vulnrichment); il tecnico che valida il finding la conferma sul contesto. | Due colonne sì o no, con la motivazione nei casi dubbi. |
| 19. Criticità dell’asset per l’azienda | Una vulnerabilità da 7.5 sul server della produzione conta più di una da 9.8 su un sistema di test isolato. | Classificazione degli asset (alta, media, bassa) concordata con l’azienda. | Classificazione allegata al report. |
I controlli 15, 17 e 18 corrispondono alle quattro variabili della BOD 26-04: esposizione dell’asset, presenza nel catalogo KEV, sfruttamento automatizzabile, impatto parziale o totale. La direttiva vincola solo le agenzie federali civili statunitensi, ma la CISA invita tutte le organizzazioni ad adottare lo stesso approccio basato sul rischio.
Blocco 5: Remediation e verifica
Il report non chiude nessuna vulnerabilità: la chiudono un responsabile, una data e un retest che lo dimostri.
| Controllo | Perché conta | Come si verifica | Evidenza da conservare |
|---|---|---|---|
| 20. Un responsabile per ogni finding | Un finding senza un nome accanto resta aperto. | Ogni riga del piano ha un responsabile e una data obiettivo. | Piano di remediation con i responsabili. |
| 21. Tempi per fascia di priorità | Tempi concordati prima evitano che tutto diventi urgente, o che niente lo diventi. | Applicazione della matrice qui sotto: 7, 30, 90 o 180 giorni. | Data obiettivo per ogni finding. |
| 22. Mitigazioni quando la patch non c’è | Tra la scoperta e la correzione il rischio si può ridurre: chiudere l’esposizione, filtrare, segmentare, disattivare la funzione vulnerabile. | Per ogni finding senza patch, la misura adottata. | Misura e data di applicazione. |
| 23. Accettazione del rischio documentata | Alcuni finding non si correggono per vincoli reali: lo decide chi ne ha l’autorità, non lo lascia aperto il tempo. | Elenco dei rischi accettati con firma e data di revisione. | Registro dei rischi accettati. |
| 24. Retest delle correzioni | Solo il retest dimostra che la vulnerabilità è chiusa: una patch installata non sempre corregge, per esempio senza riavvio o con una configurazione rimasta vulnerabile. | Nuova verifica sui finding dichiarati corretti. | Report di retest con lo stato di ogni finding. |
| 25. Metriche nel tempo | Tempo di esposizione e vulnerabilità ricomparse dicono se il processo funziona; servono anche come evidenza per NIS2 e ISO/IEC 27001. | Confronto tra assessment successivi. | Delta report: vulnerabilità nuove, chiuse e ricomparse. |
Per chiudere i finding in modo continuativo, il vulnerability assessment va affiancato a un processo di patch management.
La matrice di priorità
La matrice assegna ogni finding a una di quattro fasce, partendo da due domande: la vulnerabilità è già sfruttata? L’asset è raggiungibile da Internet?
| Fascia | Quando ci rientra un finding | Tempo indicativo |
|---|---|---|
| Massima | Sfruttata (CISA KEV o EU KEV) su un asset esposto a Internet; oppure asset esposto, attacco automatizzabile e controllo totale del sistema. | Entro 7 giorni |
| Alta | Sfruttata su un asset interno; oppure asset esposto, non ancora in KEV, con impatto totale o EPSS nel percentile alto. | Entro 30 giorni |
| Media | Non sfruttata su un asset interno con impatto totale; oppure asset esposto con impatto parziale. | Entro 90 giorni |
| Bassa | Non sfruttata, non esposta, impatto parziale ed EPSS basso. | Entro 180 giorni, o accettazione documentata |
Due regole completano la matrice:
- 1La criticità dell’asset (controllo 19) sposta un finding di una fascia in su o in giù.
- 2Se una vulnerabilità entra nel catalogo KEV dopo il report, il finding si rivaluta subito, senza attendere il prossimo assessment.
“Percentile alto” ed “EPSS basso” restano un giudizio del tecnico che valida il finding, non una soglia fissa. I tempi sono una raccomandazione di Nexsys per PMI con poche persone dedicate all’IT. Non sono un requisito normativo: la BOD 26-04, che vincola solo le agenzie federali statunitensi, prevede per la fascia più alta tre giorni.
Esempio: lo stesso report, due ordini diversi
Ordinati per CVSS, il server web interno sarebbe tra le prime urgenze e il domain controller verrebbe dopo; con la matrice il server web scende a 90 giorni e il domain controller sale nella fascia massima.
Esempio illustrativo con valori inventati, non tratto da un cliente.
| Finding | CVSS | Sfruttata | Esposto | Impatto | Fascia e tempo |
|---|---|---|---|---|---|
| Gateway VPN con vulnerabilità di bypass dell’autenticazione | 9.8 | Sì (KEV) | Sì | Totale | Massima, 7 giorni |
| Domain controller con vulnerabilità di escalation dei privilegi | 7.8 | Sì (KEV) | No | Totale | Alta, portata a massima per criticità dell’asset: 7 giorni |
| Server web interno con libreria vulnerabile, EPSS basso | 9.8 | No | No | Totale | Media, 90 giorni |
| Portale clienti con TLS 1.0 ancora attivo | 5.9 | No | Sì | Parziale | Media, 90 giorni |
| Stampante di rete con firmware obsoleto in una rete isolata | 6.5 | No | No | Parziale | Bassa, 180 giorni o accettazione documentata |
Checklist e NIS2
La checklist non rende conforme nessuno, ma sei controlli producono le evidenze che un programma NIS2 chiede sulla gestione delle vulnerabilità.
La direttiva NIS2, recepita in Italia con il D.Lgs. 138/2024, inserisce la gestione delle vulnerabilità tra le misure di sicurezza. Per alcune categorie di soggetti del digitale, come i fornitori di servizi gestiti e di cloud, il Regolamento di esecuzione (UE) 2024/2690 (allegato, punto 6.10.2) chiede di effettuare, se opportuno, scansioni delle vulnerabilità a intervalli pianificati, conservarne i risultati e affrontare senza indebito ritardo quelle critiche.
| Controllo | Evidenza utile |
|---|---|
| 1. Inventario di IP pubblici e FQDN | Perimetro documentato e aggiornato |
| 6. Regole d’ingaggio scritte | Attività pianificata e autorizzata |
| 21. Tempi per fascia di priorità | Criteri di remediation definiti prima |
| 23. Accettazione del rischio documentata | Decisioni tracciate con responsabile e data |
| 24. Retest delle correzioni | Prova della chiusura |
| 25. Metriche nel tempo | Andamento tra un assessment e il successivo |
Per perimetro, obblighi e scadenze consulta la guida NIS2 per le PMI.
Chi l’ha scritta
Francesco Pandiscia è CTO e trainer di Nexsys e Microsoft Certified Trainer. Nexsys esegue vulnerability assessment e penetration test per PMI italiane, su perimetro esterno, reti interne e infrastrutture Microsoft.
Fonti
- CISA, Known Exploited Vulnerabilities Catalog
- CISA, BOD 26-04: Prioritizing Security Updates Based on Risk (10 giugno 2026)
- FIRST, Exploit Prediction Scoring System (EPSS)
- ENISA, Vulnerability Services: EUVD ed EU KEV
- Regolamento di esecuzione (UE) 2024/2690, EUR-Lex
- D.Lgs. 4 settembre 2024, n. 138, Normattiva
Vuoi applicare la checklist al tuo perimetro?
Il Vulnerability Assessment One-Shot di Nexsys parte da 600 € + IVA per 10 IP, esterni oppure interni, con validazione dei finding e piano di remediation. La call di scoping è gratuita e senza impegno.