Penetration test e vulnerability assessment: differenze, costi e come commissionarli

Un vulnerability assessment cerca in modo sistematico e in gran parte automatico i punti deboli noti (software non aggiornato, configurazioni errate); un penetration test (pen test) simula invece l'azione di un attaccante per verificare se quelle debolezze possono essere sfruttate davvero e fin dove si arriva. Il primo è più rapido ed economico e dà un quadro ampio; il secondo è più lungo, richiede competenze elevate e costa di più. Per una PMI il percorso ragionevole è spesso: prima mettere in ordine le basi, poi un assessment, infine un pen test mirato sui sistemi più esposti.

I costi dipendono dal perimetro e dall'effort: nessun importo in questa guida è un prezzo di mercato, e gli esempi di calcolo sono illustrativi.

Le differenze principali

Tipi di pen test

• Esterno: parte da internet e prova a violare siti, servizi esposti, VPN, posta.
• Interno: simula un attaccante già dentro la rete (per esempio tramite un computer compromesso) e valuta quanto può diffondersi.
• Applicativo (web o mobile): verifica sito, portale clienti o app, spesso seguendo metodologie come la OWASP.
• Social engineering: prova la resistenza dei dipendenti a phishing e altri inganni, solo con regole chiare e consenso formale.
• Red team: simulazione estesa e prolungata, adatta a organizzazioni mature, raramente necessaria per una PMI.

Gli approcci si distinguono anche per le informazioni date al tester: black box (nessuna), grey box (credenziali o documentazione parziale), white box (accesso completo). Più informazioni permettono di trovare più cose nello stesso tempo.

Da cosa dipende il prezzo

Il costo di un test è in genere legato ai giorni-uomo di lavoro, moltiplicati per la tariffa del professionista. I fattori principali:

1. Numero e complessità dei sistemi (indirizzi IP, applicazioni, utenti da testare).
2. Profondità: scansione, verifica manuale, sfruttamento.
3. Competenze richieste per tecnologie particolari.
4. Rapporto finale: livello di dettaglio, presentazione ai responsabili.
5. Retest per verificare le correzioni, spesso trascurato nei preventivi.

Esempio illustrativo del ragionamento: se un test applicativo richiedesse 6 giorni di lavoro e un retest 1 giorno, e la tariffa giornaliera ipotetica fosse X, il preventivo sarebbe 7 x X più eventuali spese. Confronta le offerte per giorni di effort dichiarati e per contenuti del report, non solo per prezzo totale.

Come definire il perimetro e le regole d'ingaggio

Un pen test senza regole scritte può diventare un problema legale e operativo. Prima di firmare:

• elenca cosa è incluso (indirizzi, applicazioni, sedi) e cosa è escluso;
• definisci quando può essere eseguito (anche fuori orario) e come interrompere i test se c'è impatto sulla produzione;
• ottieni le autorizzazioni dei terzi se i sistemi sono ospitati da fornitori cloud o hosting: molti prevedono procedure specifiche;
• stabilisci come saranno gestiti i dati eventualmente visti dal tester: riservatezza, nomina a responsabile del trattamento se tratta dati personali, cancellazione finale;
• indica un referente aziendale raggiungibile durante le attività.

Ricorda che l'accesso a un sistema informatico senza autorizzazione è un reato (articolo 615-ter del codice penale): l'autorizzazione scritta del titolare dei sistemi è ciò che rende l'attività lecita.

Come leggere il report

Un buon rapporto contiene:

1. un sommario per la direzione, in linguaggio non tecnico;
2. l'elenco delle vulnerabilità con gravità e spiegazione dell'impatto per l'azienda;
3. le prove (schermate, passaggi) per riprodurre il problema;
4. le raccomandazioni di correzione, ordinate per priorità;
5. la metodologia e il periodo di esecuzione.

Diffida di report che sono solo l'esportazione di uno scanner, con centinaia di voci non verificate: il valore è nella selezione e nella spiegazione. Spesso le gravità si indicano con il sistema CVSS, ma una vulnerabilità "media" su un sistema critico può meritare più urgenza di una "alta" su un sistema isolato.

Dopo il test: correggere

Il test serve solo se seguito da azioni. Crea un piano con responsabili e scadenze: le correzioni critiche entro pochi giorni, le altre secondo priorità. Poi chiedi un retest per confermare che i problemi siano risolti. Un report archiviato senza interventi non riduce il rischio e, in caso di incidente, può mostrare che i problemi erano noti.

Se l'azienda rientra nella direttiva NIS2, test e valutazioni periodiche rientrano tra le misure di gestione del rischio da documentare; vedi la guida NIS2 per le PMI.

Quando conviene farlo

• Prima del lancio di un portale clienti o di un e-commerce.
• Dopo una migrazione di infrastruttura o l'adozione di nuovi servizi esposti.
• Se un cliente o una polizza cyber lo richiede.
• Dopo un incidente, per verificare che le cause siano state eliminate.
• Come verifica annuale se tratti dati particolarmente sensibili.

Domande frequenti

Un assessment basta o serve il pen test?

Per iniziare un assessment dà una buona panoramica a costo contenuto. Il pen test è utile quando vuoi capire l'impatto reale di un attacco sui sistemi più importanti.

Posso usare uno scanner gratuito da solo?

Si può, ma i risultati richiedono competenza per essere interpretati e contengono falsi positivi. Inoltre scansioni non autorizzate su sistemi di terzi sono vietate.

Quanto dura la validità di un test?

È una fotografia al momento dell'esecuzione: ogni modifica o nuova vulnerabilità può cambiarne l'esito. Per questo è consigliabile ripeterlo periodicamente.

Il tester vedrà i miei dati?

Potrebbe accadere. Per questo servono accordi di riservatezza, regole sui dati e, se tratta dati personali, un atto di nomina ai sensi dell'articolo 28 del GDPR.

Fonti ufficiali

• Agenzia per la Cybersicurezza Nazionale — indicazioni su gestione del rischio e misure di sicurezza.
• OWASP — progetto internazionale con guide sulla sicurezza delle applicazioni web.
• Garante per la protezione dei dati personali — nomina dei responsabili del trattamento.