2026-07-15 · PRACTICE · The Offensive Technology team

Perché ogni attività inizia con una firma

C'è esattamente una cosa che separa un penetration test da un reato informatico, e non si tratta di competenze, strumenti o intenzioni. Si tratta dell'autorizzazione. Lo stesso comando eseguito sullo stesso server è un servizio professionale il martedì e un reato grave il mercoledì, e l'unica differenza è un pezzo di carta.

Quindi, prima di toccare qualsiasi cosa, ci assicuriamo che quel documento sia corretto. Ecco cosa significa concretamente nella pratica e perché non lo salteremo mai, nemmeno quando un cliente ha fretta.

Proprietà prima dell'accesso

La prima domanda non è "cosa vuoi sottoporre a test", ma "puoi dimostrare di averne il controllo". Chiunque può digitare un dominio in un modulo. Questo non significa che ne sia il proprietario, e se non lo è, analizzarlo mette entrambi dalla parte sbagliata della legge.

Quindi verifichiamo. Di solito questo significa inserire un token in un record DNS che possiamo leggere, o confermare da un indirizzo email appartenente al dominio stesso. Richiede pochi minuti e non è negoziabile. Se non puoi dimostrare il controllo del target, non c'è alcuna attività da avviare.

Non ci affidiamo nemmeno alla sola firma. Richiediamo un'autorizzazione scritta da parte di una persona con nome e cognome e pretendiamo comunque la prova tecnica sottostante, perché una firma sulla carta intestata sbagliata è proprio il modo in cui un tester finisce per puntare al target errato.

Lo scope è un recinto, non un suggerimento

Una volta definita la proprietà, mettiamo per iscritto esattamente cosa rientra nel perimetro e cosa no: quali host, quali applicazioni, quali tecniche e quali sono esplicitamente escluse. Quel documento è il recinto. Restiamo al suo interno anche quando qualcosa di interessante è chiaramente raggiungibile appena fuori.

• Gli asset che siamo autorizzati a toccare, elencati per nome.
• Le tecniche che hai approvato e quelle che hai escluso.
• Le finestre temporali, in modo che i test non sorprendano mai il tuo team o i tuoi clienti.
• Un referente designato in grado di interrompere l'intera attività con un solo messaggio.

Lo stesso documento chiarisce due aspetti che spesso si dimenticano finché non diventano critici. Primo, l'ambiente: stiamo testando la produzione, dove una richiesta pesante può impattare sui clienti reali, o una copia di staging che la rispecchia? Entrambe sono opzioni valide, ma la scelta deve essere deliberata, non scoperta a metà test. Secondo, la condizione di arresto: chi può ordinare l'interruzione, come può contattarci e cosa succede agli accessi già ottenuti in quel caso. Si tratta di un accordo preliminare firmato, non di un'intesa informale. Quando è fatto bene, nessuno deve improvvisare sotto pressione.

Quando il target non è interamente tuo

Essere proprietari di un nome di dominio non equivale a possedere tutto ciò a cui esso punta, ed è qui che gli scope definiti in buona fede falliscono. Un esempio comune: un cliente inserisce app.clientco.com nello scope. Effettuiamo una verifica ed è un CNAME verso una piattaforma SaaS di terze parti a cui il cliente è abbonato ma che non gestisce direttamente. Il cliente controlla il nome DNS, ma non i server sottostanti. Testare quell'host significa testare il fornitore, che non ha acconsentito a nulla. Di conseguenza, l'host viene escluso dallo scope, oppure il cliente deve prima ottenere un'autorizzazione scritta dal fornitore.

La stessa cautela si applica agli asset su hosting condiviso o dietro una CDN condivisa, dove un singolo indirizzo IP può servire migliaia di tenant non correlati, e a un dominio acquisito tramite una transazione i cui record risolvono ancora sull'infrastruttura del venditore. Anche i principali provider cloud pubblicano le proprie policy sui test consentiti, e alcune attività, in particolare il denial-of-service e lo stress testing, richiedono comunque il loro preavviso o la loro approvazione anche su risorse di tua proprietà. Chiarire cosa sia effettivamente tuo fa parte della mappatura della superficie di attacco esterna, e avviene prima di qualsiasi test, non durante.

La legge dietro al limite

Il motivo per cui siamo intransigenti su questo punto non è una policy interna. La maggior parte dei Paesi considera l'accesso non autorizzato a un sistema informatico come un reato in sé. Negli Stati Uniti si tratta del Computer Fraud and Abuse Act; nel Regno Unito, del Computer Misuse Act 1990; nell'Unione Europea, gli Stati membri puniscono l'accesso illegale nell'ambito delle leggi nazionali che recepiscono la direttiva dell'UE relativa agli attacchi contro i sistemi di informazione. I dettagli variano a seconda della giurisdizione, ma il filo conduttore è lo stesso: l'accesso senza il consenso del proprietario costituisce il reato e le buone intenzioni non rappresentano una difesa. Questo non costituisce una consulenza legale, ed è un avvocato la persona idonea a valutare le normative applicabili al tuo caso. È semplicemente la ragione per cui non viene inviata nemmeno una singola richiesta finché l'autorizzazione e la proprietà non sono state stabilite.

Perché siamo severi sulla parte più noiosa

A volte i clienti vedono tutto questo come burocrazia. È l'opposto. Un'autorizzazione rigorosa è ciò che ci permette di essere aggressivi all'interno del recinto senza che nessuno debba preoccuparsi. Quando i confini sono messi per iscritto e firmati, possiamo concatenare gli attacchi in modo incisivo e dimostrare l'impatto reale, perché tutti hanno già concordato dove si trovano i limiti.

I team che si fanno male sono quelli che hanno trattato lo scope come una formalità. Noi lo trattiamo come le fondamenta, perché è esattamente ciò che è.

Autorizzazione prima di tutto: risposte rapide

Ho bisogno di un'autorizzazione scritta per testare sistemi che già possiedo?

In pratica, sì. L'autorizzazione scritta dimostra che il tuo stesso team ha approvato il test, il che ti protegge internamente e protegge l'operatore che lo esegue. Se una qualsiasi parte dell'ambiente risiede su un'infrastruttura che non controlli completamente, come una piattaforma cloud o un prodotto SaaS in hosting, potresti aver bisogno anche del permesso del provider. Ottieni tutto per iscritto prima di eseguire qualsiasi cosa.

Che cos'è un documento delle regole di ingaggio?

È l'accordo scritto che definisce il test: i target esatti nello scope, le tecniche consentite e vietate, la finestra temporale di test, i referenti indicati da entrambe le parti e le condizioni per l'interruzione delle attività. Trasforma un vago "fateci un test" in un impegno vincolante per entrambe le parti.

È illegale effettuare la scansione di un sito web che non possiedo?

Può esserlo. Molte giurisdizioni puniscono penalmente l'accesso non autorizzato ai sistemi informatici e il confine tra una scansione e un accesso non è sempre dove le persone immaginano. Senza autorizzazione e senza la prova di controllare il target, non puntare nulla contro di esso. Questa non è una consulenza legale; consulta un avvocato qualificato per la tua giurisdizione.

Come verificate che io sia il proprietario di un target prima di testarlo?

Di solito tramite un record che ti chiediamo di pubblicare nel DNS del target, oppure tramite una risposta da una casella di posta sul dominio stesso. Entrambi dimostrano il controllo in un modo che un modulo web non può garantire. Finché questo controllo non viene superato, non c'è alcuna attività.

Letture correlate

• Check, scansione o pentest completo?
• Come prepararsi al primo penetration test
• Cosa dimostrano concretamente OSCP, OSEP e CRTO