Vulnerability assessment e penetration test (VA/PT): differenze e quando servono

Il glossario del NIST CSRC, riprendendo la CNSSI 4009-2022, definisce il vulnerability assessment come «l'esame sistematico di un sistema informativo o di un prodotto per determinare l'adeguatezza delle misure di sicurezza, individuare le carenze, fornire dati per prevedere l'efficacia delle misure proposte e confermarne l'adeguatezza dopo l'implementazione» (traduzione nostra). In pratica si svolge soprattutto con scanner di vulnerabilità che, come spiega il NIST SP 800-115, individuano gli host e le loro caratteristiche e le confrontano con le vulnerabilità note contenute nei propri database.

Lo stesso glossario definisce il penetration test come «una metodologia di test in cui i valutatori, di norma entro vincoli specifici, tentano di aggirare o superare le funzioni di sicurezza di un sistema». L'SP 800-115 aggiunge che spesso comporta «attacchi reali su sistemi e dati reali» e che la maggior parte dei penetration test cerca combinazioni di vulnerabilità che consentono di ottenere più accesso di quanto ne darebbe una singola vulnerabilità.

L'SP 800-115 colloca i due in famiglie diverse. La scansione di vulnerabilità è una tecnica di identificazione e analisi dei bersagli. Il penetration test è una tecnica di validazione, il cui obiettivo è «dimostrare che una vulnerabilità esiste e mostrare le esposizioni di sicurezza che si verificano quando viene sfruttata». In breve: un VA produce un elenco di debolezze probabili, un PT produce una prova.

VA/PT o VAPT è semplicemente il nome di un incarico, o di un programma, che comprende entrambi: di solito un assessment ampio seguito da penetration test sui sistemi dove la sfruttabilità conta di più.

• Domanda a cui risponde. VA: quali debolezze note esistono e quanto sembrano gravi? PT: un attaccante può usarle, da sole o concatenate, per arrivare a qualcosa che conta?
• Perimetro. VA: ampio, spesso tutti gli host e le applicazioni di un inventario. PT: più stretto e orientato a un obiettivo, come il perimetro esposto su internet, un'applicazione critica o il percorso fino al domain admin.
• Profondità. VA: si ferma al rilevamento e a un punteggio di severità. PT: tenta lo sfruttamento, poi l'escalation dei privilegi e il movimento laterale, se le regole d'ingaggio lo consentono.
• Risultato. VA: un elenco di finding ordinati per punteggio, spesso lungo. PT: meno finding, ciascuno con la prova di cosa è stato sfruttato e della catena che ci ha portato.
• Falsi positivi. VA: frequenti, perché il rilevamento è dedotto da versioni e firme. PT: rari per i finding sfruttati, perché l'exploit è la prova.
• Rischio per la produzione. VA: basso, anche se scansioni aggressive e controlli di denial of service possono disturbare sistemi fragili. PT: più alto, perché usa exploit reali su sistemi reali; l'SP 800-115 avverte che i sistemi possono essere danneggiati o resi inutilizzabili.
• Competenze. VA: strumenti più qualcuno in grado di interpretare i risultati. PT: l'SP 800-115 lo definisce ad alta intensità di lavoro e scrive che richiede grande esperienza per ridurre al minimo il rischio per i sistemi testati.
• Frequenza tipica. VA: da continua a trimestrale. PT: annuale o dopo modifiche importanti, a meno che non sia automatizzato.

Sugli scanner l'SP 800-115 è diretto: anche se il processo è molto automatizzato, gli scanner di vulnerabilità possono avere un alto tasso di falsi positivi, cioè segnalare vulnerabilità che non esistono, e i risultati vanno interpretati da un esperto. Il documento indica anche il problema opposto. Le debolezze raramente esistono isolate: più finding a basso rischio possono, combinati, rappresentare un rischio più alto, gli scanner non riescono a rilevare queste combinazioni, e un modo più affidabile di misurare il rischio complessivo delle vulnerabilità è il penetration test.

Per questo un report di VA da solo produce spesso due tipi di spreco. Il team perde tempo su finding che non sono reali o non sono raggiungibili, e mette in fondo alla coda finding con punteggio basso che insieme formano il percorso che un attaccante seguirebbe. Un penetration test riduce entrambi: un finding sfruttato è reale, e la catena seguita mostra quali punteggi bassi contano.

Anche il penetration test ha un punto cieco: i falsi negativi. Un test dimostra ciò che ha funzionato, entro il suo perimetro, il suo tempo e le sue tecniche. Un esito pulito significa che le tecniche provate non hanno avuto successo, non che nient'altro funzionerebbe. Lo stesso vale per una scansione pulita, che significa solo che nessuna firma ha trovato corrispondenza.

Poiché la scansione è automatica, un VA può girare con la stessa frequenza con cui cambia l'ambiente: ogni settimana, ogni giorno o dopo ogni modifica. Diverse norme fissano dei minimi: il PCI DSS chiede scansioni interne ed esterne almeno ogni tre mesi e dopo modifiche significative, e l'RTS DORA sulla gestione del rischio ICT chiede una scansione automatica delle vulnerabilità almeno settimanale sugli asset che supportano funzioni essenziali o importanti.

Il penetration test è stato tradizionalmente annuale. Quando fu scritto, nel 2008, l'SP 800-115 osservava che, per il costo elevato e il potenziale impatto, un penetration test annuale della rete e dei sistemi di un'organizzazione «può essere sufficiente». Le norme usano ancora quell'intervallo come minimo: il PCI DSS 11.4 e il NYDFS 500.5 chiedono almeno un penetration test l'anno, ed entrambi chiedono ulteriori test o scansioni dopo modifiche significative o rilevanti.

Il problema pratico è il vuoto tra un test e l'altro. Una rete che cambia ogni settimana viene verificata sulla sfruttabilità una volta l'anno, e nel frattempo i finding del VA restano non dimostrati. È il vuoto che il pentest automatizzato e quello autonomo servono a colmare, come spiegato più avanti.

Nessuno dei due test ha un listino, ma i fattori di costo sono noti. Chiedi a ogni fornitore di quotare lo stesso perimetro e confronta voce per voce.

• Asset nel perimetro. Il numero di host attivi, applicazioni e API. Per un VA è il fattore principale; per un PT conta meno della profondità.
• Profondità e punto di partenza. Solo black box dall'esterno, oppure gray box con credenziali utente, codice sorgente o una posizione assumed breach dentro la rete. Ogni opzione aggiunge giornate.
• Lavoro manuale. Un VA è soprattutto tempo macchina più revisione; un PT si paga a giornate uomo. Le tariffe massime del listino federale GSA riassunte nella nostra guida ai costi collocano la tariffa massima mediana di un penetration tester sul listino federale statunitense intorno a 158 dollari l'ora.
• Frequenza e retest. Un secondo test dopo la correzione, o un test dopo ogni modifica significativa, moltiplicano il prezzo di un incarico puntuale.
• Chi può testare. Alcune norme indicano il soggetto: nel PCI DSS le scansioni esterne devono farle un Approved Scanning Vendor, e i test threat-led come TLPT e CBEST hanno requisiti propri sui tester.
• Report ed evidenze. Un report pensato per un auditor o un'autorità, con metodologia, qualifiche dei tester e registri di correzione, richiede tempo.

Per i valori dei contratti pubblici delle piattaforme di pentest automatizzato e un metodo di confronto su tre anni, vedi quanto costa il pentest automatizzato.

Questa sintesi riprende le nostre guide già verificate; ogni link cita il testo e la fonte primaria. La mappa completa è in requisiti di penetration test per normativa.

• NIS2 (UE). La direttiva non nomina mai il penetration test. L'art. 21(2), lettere e) ed f), chiede la gestione delle vulnerabilità e politiche per valutare l'efficacia delle misure; il regolamento di esecuzione (UE) 2024/2690 chiede ai fornitori digitali che rientrano nel suo ambito una politica di security testing e, ove opportuno, scansioni di vulnerabilità.
• Italia, misure ACN. La misura ID.RA-01 impone ai soggetti essenziali, almeno sui sistemi rilevanti, attività che comprendono «almeno vulnerability assessment e/o penetration test», periodicamente e comunque prima della messa in esercizio, documentate in relazioni. I soggetti importanti non hanno un obbligo esplicito di VA/PT, ma devono avere un piano di gestione delle vulnerabilità approvato dagli organi di amministrazione (ID.RA-08). Dettagli in VA/PT e NIS2.
• PCI DSS v4.0.1. Entrambi, come requisiti distinti: 11.3 scansioni di vulnerabilità interne ed esterne almeno ogni tre mesi (quelle esterne da un ASV), 11.4 penetration test interni ed esterni almeno ogni 12 mesi e dopo modifiche significative, con test ripetuti per verificare le correzioni. Vedi PCI DSS 11.3 e 11.4.
• DORA. Ogni entità finanziaria deve avere un programma di test basato sul rischio; l'art. 25(1) elenca i test previsti, dalle scansioni di vulnerabilità al penetration test, i sistemi che supportano funzioni essenziali o importanti vanno testati almeno una volta l'anno e quegli asset scansionati almeno ogni settimana. Vedi test DORA oltre il TLPT.
• NYDFS 23 NYCRR 500.5. Un penetration test annuale dall'interno e dall'esterno del perimetro, eseguito da un soggetto qualificato, più scansioni automatiche e una revisione manuale dei sistemi che le scansioni non coprono. Vedi il playbook NYDFS Part 500.

Lo schema è questo: le norme che badano alla sfruttabilità chiedono il penetration test per nome, quelle basate sul rischio lasciano scegliere, e in quel caso un programma di sole scansioni è difficile da difendere dove la domanda è se una debolezza si può sfruttare.

Entrambi i test possono partire da livelli di conoscenza diversi, e la scelta cambia cosa misurano. Un test black box parte dall'esterno con il solo perimetro autorizzato; un test gray box parte da una conoscenza parziale, come le credenziali di un utente standard, la documentazione o il codice sorgente.

Per un VA l'equivalente gray box è la scansione autenticata, che accede ai sistemi e legge versioni e configurazioni installate invece di dedurle dalla rete; il PCI DSS 11.3.1.2 oggi richiede scansioni interne autenticate. Per un PT il gray box rappresenta un insider o un attaccante che ha già rubato un account con il phishing, e di solito arriva più lontano di un black box nello stesso tempo. Un programma maturo usa entrambi. Vedi penetration test black box e gray box.

Il penetration test automatizzato prende il ciclo di un penetration test (ricognizione, tentativi di sfruttamento, post-exploitation, evidenze, retest) e lo fa eseguire al software. Gli strumenti autonomi, o agentici, lasciano che siano agenti AI a scegliere il passo successivo in base a ciò che trovano, invece di seguire una sequenza fissa.

Nello spettro VA/PT stanno nel mezzo:

• Come un VA, girano a calendario, coprono molti asset e costano poco da ripetere.
• Come un PT, tentano lo sfruttamento e concatenano le debolezze, quindi un finding arriva con una prova invece che con una corrispondenza di versione, e possono ritestare una correzione con la stessa prova.
• A differenza di un PT umano, sono deboli sui difetti di logica applicativa, non fanno social engineering né accesso fisico e non soddisfano le norme che indicano chi deve testare, come TLPT o CBEST.

Il modello che funziona per la maggior parte dei programmi: VA continuo per l'ampiezza, pentest automatizzato o autonomo per una prova frequente della sfruttabilità, e penetration test condotti da persone per la profondità, per ciò che gli strumenti non raggiungono e ovunque una norma richieda un tester qualificato o accreditato.

1. Ti serve un inventario ripetuto delle debolezze note su tutto il perimetro? È un VA, e dovrebbe girare in continuo o almeno all'intervallo fissato dalle norme che ti riguardano.
2. Ti serve sapere se un attaccante può raggiungere sistemi specifici, o dare priorità alle correzioni in base alla sfruttabilità dimostrata? È un PT, umano o automatizzato.
3. Una norma nomina il test? Il PCI DSS li chiede entrambi; il NYDFS chiede un pentest annuale; la misura ACN ID.RA-01 accetta VA e/o PT, ma la scelta deve seguire il tuo piano di gestione delle vulnerabilità.
4. Una norma indica chi deve testare? Scansioni ASV, fornitori TLPT e CBEST non sono opzionali, e nessuno strumento li sostituisce.
5. Quanto spesso cambia l'ambiente? Se cambia ogni settimana, un pentest annuale lascia senza prova quasi tutto l'anno.
6. Quale attaccante vuoi rappresentare? Solo l'esterno (black box) o anche un insider o un utente vittima di phishing (gray box)?
7. I sistemi reggono il test? Sistemi fragili o OT possono richiedere un assessment passivo, oppure un'eccezione documentata con misure compensative invece dello sfruttamento.
8. Quali evidenze ti serviranno? Report con metodologia, tester, finding, correzioni ed esiti dei retest, conservati per il periodo di conservazione più lungo che ti si applica.

Le sezioni precedenti valgono qualunque strumento o fornitore tu scelga. Questa descrive come si colloca Zero Hunt, il prodotto dietro questo sito.

• VA e PT in una sola campagna. Zero Hunt è un red team AI autonomo per reti e infrastrutture. Le sue campagne individuano le vulnerabilità e poi tentano di sfruttarle, quindi ogni finding registra se è stato dimostrato sfruttabile nel tuo ambiente.
• Black box e gray box. Le campagne girano in black box per impostazione predefinita, e in gray box tramite test autenticati con credenziali fornite da te o tramite l'analisi del sorgente della versione esatta del software in uso.
• In continuo, con retest. Le campagne girano una volta, ogni giorno, ogni settimana, ogni mese o con una pianificazione personalizzata, e si possono rilanciare dopo una correzione, così la chiusura è dimostrata con evidenze firmate.
• Human in the loop. Cinque livelli di autonomia stabiliscono quali azioni attendono un operatore; la verifica dello sfruttamento è abilitata solo ai due livelli più alti, e sotto un operatore può eseguire un singolo proof of concept dopo un consenso scritto e nominativo.
• Evidenze. Ogni tentativo di attacco è un record firmato Ed25519 in una catena di hash SHA-256; i finding sono mappati su 34 framework di compliance. Il motore non mappa i codici delle misure ACN, quindi il collegamento dei report a ID.RA-01 resta nella tua documentazione.
• On-premise, AI privata. Gira su un'appliance con modelli propri; nessun dato del cliente la lascia, e può funzionare in modalità air-gapped.

Non sostituisce un ASV PCI, i tester qualificati che alcune norme richiedono, né i fornitori TLPT e CBEST. Leggi del red team AI on-premise, oppure prenota una call di 30 minuti sulla readiness per verificare quali test ti chiedono le norme e dove le tue evidenze hanno lacune.

• Vulnerability assessment, definizioni del glossario (NIST CSRC)
• Penetration testing, definizioni del glossario (NIST CSRC)
• NIST SP 800-115, Technical Guide to Information Security Testing and Assessment (NIST CSRC), sezioni 4.3, 5, 5.2 e 7.3
• ACN Allegato 2, misure di base per i soggetti essenziali, ID.RA-01 (PDF, acn.gov.it)
• PCI Data Security Standard (PCI SSC)
• Regolamento (UE) 2022/2554 (DORA) (EUR-Lex)
• 23 NYCRR Part 500 come modificato dal Second Amendment (NYDFS, PDF)

Le sintesi normative riprendono le guide di dettaglio linkate nel testo, che citano tutte le fonti primarie.