Commissionare un penetration test: Rules of Engagement, contratto e come riconoscere una scansione venduta come pentest
Autorizzazioni, Rules of Engagement e clausole contrattuali: che cosa definire prima di commissionare un penetration test e come riconoscere una scansione venduta come tale.
Commissionare un penetration test è sempre più comune: nell’esperienza di Nexsys la richiesta cresce con la NIS2, con le verifiche dei clienti sui fornitori e con le certificazioni che prevedono test periodici. È cresciuta anche l’offerta, in modo molto eterogeneo. Non esiste una definizione normativa generale di penetration test; esistono regimi specifici, come il TLPT previsto per il settore finanziario da DORA e dal regolamento delegato (UE) 2025/1190. Sotto lo stesso nome si trovano servizi molto diversi: da settimane di lavoro di un team specializzato a poche ore di scansione automatica con un report generato dallo strumento.
Il problema, per chi commissiona, è che i due servizi possono produrre documenti dall’aspetto simile. Uno descrive come un attaccante potrebbe davvero entrare; l’altro elenca vulnerabilità potenziali. Se il secondo viene scambiato per il primo, l’organizzazione ottiene un falso senso di sicurezza e, nei casi peggiori, presenta a clienti e auditor una garanzia che non ha.
Proteggersi da questo rischio dipende in larga parte da come il test viene impostato prima di iniziare: autorizzazioni, regole di ingaggio e contratto. Sono anche gli aspetti su cui un fornitore serio si sofferma di più.
Prima di tutto: chi può autorizzare il test
Un penetration test è, tecnicamente, un tentativo di accesso non convenzionale a sistemi informatici. Ciò che lo distingue da un attacco è l’autorizzazione, che deve essere scritta, specifica e firmata da chi ha titolo per concederla. Il codice penale (articolo 615-ter) punisce chi si introduce abusivamente in un sistema informatico o telematico protetto da misure di sicurezza o vi si mantiene contro la volontà espressa o tacita di chi ha diritto di escluderlo. L’autorizzazione tutela quindi sia il fornitore sia il committente.
La domanda da porsi non è solo se il responsabile IT è d’accordo, ma a chi appartengono i sistemi nel perimetro. Applicazioni ospitate da un provider, servizi gestiti in outsourcing, piattaforme SaaS e infrastrutture condivise richiedono spesso il consenso, o almeno il rispetto delle regole, di un terzo.
I principali cloud provider pubblicano proprie regole. Microsoft, ad esempio, non richiede più un’approvazione preventiva per i test sulle risorse Azure del cliente (dal 2017, e solo per Azure). Impone però di rispettare le Microsoft Cloud Unified Penetration Testing Rules of Engagement, che vietano tra l’altro i test che generano traffico eccessivo e le attività verso risorse di altri clienti. Verificare questi vincoli prima di definire il perimetro evita di dover interrompere il test a metà, o di violare un contratto senza saperlo.
Le Rules of Engagement: che cosa deve esserci
Le Rules of Engagement sono il documento operativo che traduce l’autorizzazione in regole precise. Non sono una formalità: definiscono che cosa il tester può fare, quando e come, e che cosa succede se qualcosa va storto. Esistono modelli pubblici utili come traccia, come il worksheet di SANS, ma alcuni elementi non dovrebbero mai mancare.
- Perimetro incluso ed escluso, con indirizzi IP, domini, applicazioni e ambienti indicati in modo esplicito. Ciò che non è scritto non è autorizzato.
- Finestre temporali in cui il test può svolgersi, con eventuali periodi di esclusione legati a chiusure contabili, picchi di produzione o rilasci.
- Tecniche ammesse e vietate: test di negazione del servizio, ingegneria sociale, accesso fisico, sfruttamento di vulnerabilità che possono compromettere la stabilità dei sistemi, movimenti verso ambienti OT.
- Indirizzi IP di origine del tester, da comunicare al SOC o al fornitore di servizi gestiti, perché l’attività possa essere distinta da un attacco reale.
- Referenti e catena di escalation, con contatti raggiungibili durante tutta la finestra di test e una procedura di interruzione immediata in caso di malfunzionamenti.
- Gestione delle scoperte critiche: se durante il test emerge una vulnerabilità grave o segni di una compromissione reale già in corso, il committente deve esserne informato subito, non nel report finale.
- Gestione dei dati: che cosa il tester può consultare, copiare o portare fuori dal perimetro come prova, e come vengono rimossi al termine account di test, file e strumenti installati.
Gli aspetti contrattuali che spesso mancano
Molti incarichi di penetration test si basano su un’offerta commerciale firmata e poco altro. È una base fragile, perché diversi aspetti rilevanti non compaiono in un preventivo.
Il primo è la responsabilità. Anche un test condotto con cura può causare un rallentamento o un’interruzione. Il contratto deve chiarire come vengono gestiti questi eventi, quali limiti di responsabilità si applicano e se il fornitore dispone di una copertura assicurativa adeguata. Il secondo è la riservatezza: il report di un penetration test descrive come entrare nei sistemi dell’azienda ed è, a tutti gli effetti, un documento sensibile. Vanno definiti chi lo riceve, come viene trasmesso, per quanto tempo il fornitore conserva i dati raccolti e come li distrugge.
C’è poi il trattamento dei dati personali. Durante il test il fornitore può accedere a dati personali di dipendenti e clienti. In questi casi di norma opera come responsabile del trattamento ai sensi dell’articolo 28 del GDPR, e il rapporto va formalizzato con un accordo specifico. Infine, il subappalto: è legittimo chiedere chi eseguirà materialmente il test, con quali competenze, e se parte dell’attività sarà affidata a terzi. Un fornitore che non sa o non vuole rispondere a questa domanda offre già un’indicazione utile.
Il contratto dovrebbe anche descrivere con precisione i risultati attesi: struttura del report, sintesi per la direzione, tempi di consegna, eventuale presentazione dei risultati e, soprattutto, se il retest dopo le correzioni è incluso. Lasciare questi punti impliciti significa scoprirli quando il budget è già stato speso.
Come riconoscere una scansione venduta come penetration test
La differenza sostanziale è nota: una scansione automatica individua vulnerabilità potenziali, un penetration test verifica quali sono realmente sfruttabili e fino a dove portano. La guida del PCI Security Standards Council, aggiornata nel settembre 2017 (versione 1.1), dedica a questa distinzione una sezione specifica e propone anche una checklist per valutare la completezza e la qualità di un report. In pratica, alcuni segnali permettono di riconoscere il problema prima e dopo l’acquisto.
In fase di offerta, il primo segnale è l’assenza di domande. Un penetration test richiede di capire il perimetro, gli obiettivi, i vincoli e il contesto: un fornitore che quota un prezzo per indirizzo IP senza alcuna fase di analisi sta probabilmente vendendo una scansione. Il secondo segnale è l’incoerenza tra perimetro, tempi e prezzo: verificare manualmente decine di sistemi o un’applicazione complessa richiede giorni di lavoro qualificato, non poche ore. Il terzo è l’assenza di riferimenti metodologici, come OWASP Web Security Testing Guide o NIST SP 800-115, e di informazioni su chi eseguirà il test.
Nel report, i segnali sono ancora più chiari. Le descrizioni delle vulnerabilità ricalcano quelle generiche degli strumenti, spesso con gli stessi identificativi interni. Mancano le prove di sfruttamento: schermate, richieste e risposte, passaggi riproducibili che dimostrino che cosa è stato effettivamente ottenuto. I risultati sono ordinati solo per punteggio CVSS, senza alcuna descrizione di come le singole debolezze si combinano tra loro. Nelle applicazioni web non compaiono problemi di logica applicativa, autorizzazione o gestione delle sessioni, che nessuno scanner rileva in modo affidabile. E le raccomandazioni si riducono, per quasi ogni voce, all’aggiornamento all’ultima versione disponibile.
Non si tratta di demonizzare la scansione automatica, che ha un ruolo preciso nella gestione delle vulnerabilità ed è spesso il punto di partenza di un buon penetration test. Il problema nasce quando viene venduta, e pagata, come qualcosa che non è.
Le domande da fare prima di firmare
Per chi deve commissionare un penetration test e confrontare più offerte, alcune domande permettono di separare rapidamente i servizi:
- Quali attività saranno svolte manualmente e quali in modo automatico, e con quale ripartizione del tempo?
- Chi eseguirà il test, con quale esperienza, e l’attività sarà subappaltata?
- Quale metodologia di riferimento verrà seguita?
- Potete mostrare un report di esempio, anche anonimizzato?
- Come verranno gestite le scoperte critiche durante il test?
- Il retest dopo le correzioni è incluso, e con quali tempi?
Un fornitore strutturato di penetration test risponde a queste domande senza difficoltà, e spesso le anticipa nella proposta. Quando le risposte sono vaghe, la scelta più prudente è considerare l’offerta per ciò che probabilmente è: una scansione.
Perché conta
Un penetration test vale quanto il lavoro che c’è dietro, e quel lavoro è in gran parte invisibile a chi lo acquista. Per commissionare un penetration test che valga il suo prezzo servono autorizzazioni corrette, Rules of Engagement precise e un contratto che copra responsabilità, dati e risultati attesi. Sono gli strumenti con cui il committente rende visibile ciò che compra. Saper distinguere un test da una scansione non richiede competenze offensive: richiede di sapere quali domande fare e che cosa cercare nel report. È la differenza tra conoscere davvero la propria esposizione e possedere soltanto un documento che lo afferma.
Francesco Pandiscia, CEO e fondatore di Nexsys Srl, ha oltre vent’anni di esperienza nel settore IT e opera come consulente senior sulla sicurezza delle infrastrutture aziendali. Coordina i servizi di cybersecurity di Nexsys, dal vulnerability assessment al penetration test fino alla risposta agli incidenti, ed è autore di percorsi formativi su ethical hacking, difesa delle infrastrutture, sicurezza di Active Directory e gestione degli incidenti, rivolti a team IT e organizzazioni enterprise.
Contenuto realizzato in collaborazione con Nexsys.
