Un penetration tester fa ciò che fa un intruso: cerca una via d’accesso e la usa. Nella maggior parte dei paesi le leggi sui reati informatici non chiedono quali fossero le intenzioni. Chiedono se l’accesso era autorizzato. Tutta la differenza tra un servizio e un reato sta in un insieme di documenti, firmati dalla persona giusta prima che il lavoro cominci.
Questo articolo descrive quei documenti. Non è una consulenza legale: la legge cambia da paese a paese, e sono i tuoi legali a decidere che cosa si applica a te.
I documenti
Contratto
L’accordo commerciale: che cosa si fa, entro quando, a quale prezzo, con quale responsabilità e quale riservatezza. Il contratto da solo non è l’autorizzazione. Obbliga le parti l’una verso l’altra; non stabilisce di per sé che cosa si può attaccare.
Lettera di autorizzazione
La dichiarazione con cui il proprietario dei sistemi autorizza il test. Dovrebbe indicare:
- i sistemi, per indirizzo, dominio o altro identificativo univoco;
- il periodo in cui i test sono consentiti;
- le persone o la società autorizzate a testare;
- chi firma, e in quale veste firma.
I tester la portano con sé, alla lettera o in senso figurato, per tutto l’incarico. Quando un fornitore di hosting o le forze dell’ordine chiedono che cosa sta succedendo, è questo il documento che risponde.
Regole di ingaggio
I limiti tecnici: quali tecniche sono consentite e quali escluse, gli orari dei test, la frequenza delle richieste, che cosa succede quando un sistema diventa instabile, chi chiamare di notte. NIST SP 800-115 considera le regole di ingaggio una parte obbligatoria della pianificazione, e PTES le colloca nella fase degli accordi preliminari per lo stesso motivo: le questioni non risolte prima del test si risolvono durante un incidente.
Descrizione del perimetro
L’elenco di ciò che è dentro e di ciò che è fuori. Le esclusioni contano quanto le inclusioni: il fornitore dei servizi di pagamento dietro il checkout, la piattaforma condivisa della società di hosting, il servizio di single sign-on che appartiene alla capogruppo.
Riservatezza e protezione dei dati
Un accordo di riservatezza (NDA), firmato prima di scambiarsi dettagli tecnici. Se si possono incontrare dati personali, un accordo sul trattamento dei dati. Nell’Unione europea ciò discende dall’articolo 28 del GDPR quando il tester tratta dati personali per conto del cliente.
Chi può firmare
L’autorizzazione vale quanto il potere di chi la firma.
- Il proprietario del sistema, non chi lo usa. Un’azienda non può autorizzare il test di un prodotto SaaS a cui è abbonata.
- Una persona con il potere di impegnare l’azienda. Uno sviluppatore che commissiona un test del sistema di produzione del datore di lavoro all’insaputa della direzione non ha autorizzato nulla.
- Ogni proprietario, se sono più di uno. Un sistema gestito da un’azienda sull’infrastruttura di un’altra può richiedere l’autorizzazione di entrambe.
Un fornitore scrupoloso lo verifica: controlla il registro commerciale e la proprietà dei domini, e conferma l’ordine attraverso un canale ufficiale dell’azienda. Un fornitore che non chiede nulla dovrebbe preoccuparti.
Terzi
La tua autorizzazione copre ciò che è tuo. Intorno di solito ci sono sistemi che non lo sono.
Fornitori cloud. I grandi fornitori pubblicano politiche per i test delle risorse che i clienti gestiscono sulle loro piattaforme. Nel momento in cui scriviamo, AWS, Microsoft Azure e Google Cloud consentono ai clienti di testare le proprie risorse senza approvazione preventiva, nel rispetto delle regole che ciascuno di essi pubblica; AWS elenca inoltre i servizi che si possono testare. Tutti e tre limitano i test di denial of service (DoS). Le politiche cambiano, quindi vanno controllate prima di ogni incarico e non ricordate dall’incarico precedente.
Hosting e servizi gestiti. L’hosting condiviso, i database gestiti e le content delivery network hanno condizioni proprie. Alcuni richiedono un preavviso, altri vietano del tutto i test.
Fornitori e partner. Un’integrazione con un partner non estende la tua autorizzazione al lato del partner. Senza il consenso scritto del partner, i test si fermano al tuo confine.
Le lacune abituali
- Il test è iniziato, la lettera è ancora «in firma».
- Il perimetro indica un dominio, e l’applicazione dietro di esso si è spostata a un altro indirizzo il mese scorso.
- La lettera è firmata da qualcuno che non aveva il potere di firmarla.
- La produzione è nel perimetro, e nessuno ha avvisato il team operativo.
- Una controllata in un altro paese viene testata con l’autorizzazione della capogruppo.
Ognuna trasforma un test autorizzato in uno non autorizzato per una parte del lavoro, e nessuna è visibile dal lato tecnico.
Anche il bug bounty è un’autorizzazione
Un programma di bug bounty è un’autorizzazione data pubblicamente: la politica del programma dice che cosa si può testare e come, e chi la rispetta agisce con l’autorizzazione del proprietario. Una clausola di safe harbor aggiunge l’impegno del proprietario a non perseguire i ricercatori che restano entro la politica. Vincola solo il proprietario. Non cambia la legge penale e non vincola i terzi: per questo la politica va seguita alla lettera, e per questo un sistema senza programma non è un bersaglio.
In breve
Prima che parta il primo pacchetto dovrebbero esserci un contratto, una lettera di autorizzazione firmata da chi ha il potere di firmarla, le regole di ingaggio, un perimetro con le sue esclusioni e il consenso di ogni terzo i cui sistemi vengono toccati. I dettagli su come lo gestiamo sono nella pagina Come lavoriamo.