A differenza di una scansione automatica, il penetration test concatena le debolezze: usa una credenziale trovata in un punto per accedere altrove, sfrutta una configurazione permissiva per allargare i privilegi, e arriva dove un attaccante reale arriverebbe. Il risultato non è un elenco di rischi teorici ma un percorso dimostrato.
Ha senso quando l’igiene di base è già a posto. Farlo su un’infrastruttura senza aggiornamenti e senza secondo fattore produce un rapporto prevedibile e costoso: si sapeva già che sarebbero entrati.
Non è la stessa cosa di un vulnerability assessment
I due termini vengono usati come sinonimi e non lo sono, e la confusione porta ad acquistare la cosa sbagliata.
Un vulnerability assessment è un censimento: uno strumento automatico esamina i sistemi ed elenca le debolezze note, ordinandole per gravità. È ampio, ripetibile, relativamente economico, e va fatto con regolarità.
Un penetration test è una simulazione di attacco condotta da persone: si prova davvero a entrare, concatenando debolezze che prese singolarmente sembrerebbero minori. È più profondo, più costoso e fotografa un momento.
L’ordine sensato è quello: prima si censisce e si sistema ciò che emerge, poi eventualmente si mette alla prova. Commissionare un penetration test a un’azienda che non ha mai fatto un censimento significa pagare qualcuno per scoprire cose che si sarebbero trovate da sole.
Che cosa chiedere prima di commissionarlo
Tre punti decidono se il risultato sarà utile o solo un documento.
Il perimetro, scritto
Quali sistemi, da quale posizione — dall’esterno, dall’interno, come dipendente — e cosa è escluso. Un test senza perimetro definito produce risultati non confrontabili nel tempo.
Che cosa consegnano
Un elenco di problemi ordinati per rischio reale e con indicazioni pratiche di rimedio, non uno scarico dello strumento. La differenza fra i due si vede subito ed è la parte che si paga.
La verifica dopo i rimedi
Un test che non prevede un secondo passaggio dopo le correzioni lascia aperta la domanda più importante, cioè se il problema sia stato davvero chiuso.
Perché conta per un’azienda
Serve soprattutto a due cose: dimostrare a un committente o a un’assicurazione che la verifica è stata fatta, e convincere una direzione scettica con una prova invece che con un’opinione.
L’errore che vediamo più spesso
Va concordato per iscritto nel perimetro e nei tempi, e va comunicato a chi gestisce i sistemi. Un test non annunciato che fa scattare le difese durante l’orario di produzione crea un incidente vero per simularne uno finto.