2026-07-19 · GUIDA · Il team di Offensive Technology

Come prepararsi al primo penetration test

Gran parte del valore di un penetration test si gioca prima ancora di toccare la tastiera. Un team che si presenta con un perimetro vago, senza account di test e con un responsabile dell'engineering nervoso trascorrerà i primi due giorni gestendo aspetti logistici anziché individuare ciò per cui lo avete pagato. Se questo è il vostro primo test, poche ore di preparazione vi garantiranno un risultato nettamente migliore. Ecco la checklist che vorremmo tutti i nuovi clienti avessero davanti a sé.

Chiarire l'obiettivo del test

Tutto il resto dipende da questo. State facendo il test perché lo richiede il contratto con un cliente o un auditor, perché lo ha chiesto l'assicurazione o perché volete davvero sapere quanto siete esposti? Un test orientato alla compliance potrebbe avere un perimetro dettato dallo standard. Un test basato sul rischio dovrebbe puntare a ciò che causerebbe i danni maggiori in caso di compromissione. Scrivete la motivazione in una sola frase. Risolverà decine di discussioni successive su cosa sia incluso nel perimetro.

Definire il perimetro, per iscritto

Il perimetro (scope) è l'elemento fondamentale più importante. È l'elenco esatto di ciò che i tester possono toccare: quali domini, quali applicazioni, quali intervalli IP, quali API e quali tecniche sono escluse. Lo standard aperto Penetration Testing Execution Standard (PTES) tratta questa fase preliminare come una fase a sé stante per una ragione precisa, ovvero che un perimetro poco chiaro produce un test poco chiaro.

Siate specifici ed onesti riguardo ai confini. Se un sistema è gestito da un fornitore terzo, di norma non potete autorizzare test senza il suo consenso, e nessun tester serio lo attaccherà sulla base della vostra sola parola. Decidete cosa è dentro, cosa è fuori, e fatelo verbalizzare e firmare. Quel documento, spesso chiamato regole di ingaggio (rules of engagement), tutela voi tanto quanto i tester.

Scegliere l'ambiente: produzione o staging

Vi verrà chiesto se eseguire il test in produzione o su una copia di staging. Entrambe le opzioni presentano vantaggi e svantaggi.

• La produzione è l'ambiente reale, quindi i riscontri sono reali, ma c'è una piccola possibilità che i test causino rallentamenti o effetti collaterali. I tester esperti lavorano con cautela, ma è comunque opportuno prevedere questa eventualità e pianificarla.
• Lo staging è più sicuro da mettere sotto stress, ma è utile solo se rispecchia fedelmente la produzione. Un ambiente di staging indietro di tre versioni, con dati fittizi e una configurazione diversa, produce risultati che potrebbero non applicarsi al sistema effettivamente utilizzato dai clienti.

Se scegliete lo staging, assicuratevi che sia una copia fedele. Un ambiente fuorviante è peggiore di uno leggermente rischioso.

Preparare gli accessi e gli account di test

Se volete che il test copra ciò che un utente o cliente autenticato può fare, e quasi sempre dovreste desiderarlo, i tester hanno bisogno di credenziali funzionanti. I test non autenticati vedono solo l'ingresso principale. La maggior parte dei danni reali si verifica dietro una schermata di login.

Prima dell'inizio del test, preparate:

• Account utente per ciascun ruolo rilevante: utente standard, admin e qualsiasi livello intermedio.
• Più di un account per ruolo, in modo che i tester possano verificare se un utente può accedere ai dati di un altro utente.
• Eventuali chiavi API, token o documentazione necessari per interagire con l'applicazione come farebbe un vero client.
• Un'indicazione di tutto ciò che potrebbe attivare blocchi degli account, fatturazione o invio di email, per evitare sorprese.

Definire tempistiche e comunicazioni

Concordate una finestra temporale per i test e stabilite chi debba essere informato. Indicate un unico referente tecnico in grado di rispondere rapidamente alle domande e con l'autorità di interrompere il test con un solo messaggio in caso di problemi.

Decidete in anticipo come gestire le vostre difese. Se un web application firewall o un sistema di monitoraggio blocca il traffico di test o genera alert, dovreste concordare con i tester se inserire in allowlist il loro indirizzo sorgente, poiché un firewall che si limita a bloccare il test può nascondere proprio le vulnerabilità presenti al di sotto. Avvisate i team di operations e supporto per evitare che un picco di traffico anomalo scateni una chiamata di emergenza alle 3 di notte.

Preparare la documentazione

I tester entrano a regime più velocemente se fornite loro il contesto. La OWASP Web Security Testing Guide, una metodologia open ampiamente utilizzata, considera la raccolta di informazioni la base di un buon test. Potete accorciare questa fase fornendo una panoramica dell'architettura, la documentazione delle API, l'elenco dei ruoli utente e note su qualsiasi elemento insolito o fragile. Non state facendo il lavoro al posto loro, state garantendo che il loro tempo sia dedicato a individuare i problemi, piuttosto che a riscoprire come è strutturata la vostra applicazione.

Resistere all'impulso di sistemare le cose all'ultimo momento

Prima di un primo test c'è spesso la tentazione di applicare rapidamente patch e sistemare tutto per far apparire il report impeccabile. Non fatelo. L'obiettivo è conoscere il vostro stato reale, non allestire una simulazione perfetta. Risolvere problemi noti è corretto e raccomandato in generale, ma non nascondete o disabilitate elementi solo per evitare che vengano rilevati. Finireste solo per pagare per ingannare voi stessi.

Sapere cosa riceverete al termine

Confermate il deliverable prima del primo giorno: un report scritto con i riscontri classificati per gravità e passaggi chiari per la riproduzione, e idealmente una call per esaminarlo insieme. Chiedete se il retest delle correzioni sia incluso o comporti un costo extra, perché una vulnerabilità non è chiusa finché non si conferma che la correzione funziona davvero.

Un primo passo più economico, se non siete ancora pronti

Se un penetration test completo vi sembra un impegno troppo grande per iniziare, è ragionevole partire da qualcosa di più contenuto e comprendere innanzitutto la vostra esposizione esterna. Questo è lo scopo del nostro controllo da $100: un'analisi mirata della superficie di attacco esterna, su un perimetro di cui avete verificato la proprietà e autorizzato per iscritto, esaminata da un operatore senior e consegnata con una sessione di restituzione di 30 minuti.

Abbiate chiaro cosa sia e cosa non sia. Il controllo è un primo sguardo, non un intervento completo, e non soddisferà un auditor che ha richiesto un penetration test. Ciò che farà è mostrarvi cosa vede un attaccante dall'esterno e aiutarvi a definire correttamente il perimetro del test reale, in modo che, quando ne prenoterete uno, arriviate preparati.

Letture correlate

• Controllo, scansione o pentest completo?
• Cosa possono vedere gli attaccanti della vostra azienda?