Un penetration test si paga a giornata. Ogni giorno che i tester passano ad aspettare un account, a indovinare come dovrebbe funzionare una funzionalità o bloccati dal tuo stesso firewall è un giorno non speso a cercare vulnerabilità. Gran parte di queste attese si può eliminare prima dell’inizio.
Decidi
Qual è la domanda? «Possiamo rilasciare in sicurezza il nuovo flusso di pagamento» e «che cosa può farci qualcuno da internet» portano a test diversi. Scrivi la domanda in una frase; il perimetro ne deriva.
Che cosa è nel perimetro e che cosa no? Elenca le applicazioni, gli indirizzi, gli ambienti. Elenca anche le esclusioni: il fornitore dei servizi di pagamento, i sistemi della capogruppo, il vecchio servizio che cade appena qualcuno lo guarda.
Quale ambiente? Un ambiente di staging che rispecchia la produzione è la scelta migliore: i tester possono lavorare a fondo e non si mette a rischio nulla di reale. Se esiste solo la produzione, concorda gli orari e le tecniche vietate.
Quanto sanno i tester? Un test con account e documentazione trova di più in una giornata di un test alla cieca. Un test alla cieca risponde a una sola domanda, circoscritta: che cosa ottiene un estraneo senza alcuna informazione. Decidi per quale dei due stai pagando.
Prepara
Account. Uno per ogni ruolo, e in due tenant separati se il prodotto prevede tenant: il controllo degli accessi tra clienti non si può testare con un solo cliente. Creali prima dell’inizio, accedi una volta con ciascuno e controlla che contengano dati realistici.
Documentazione. Le specifiche delle API, uno schema dell’architettura, una descrizione dei ruoli e dei principali flussi di lavoro. Documenti imperfetti sono meglio di nessun documento.
Accesso. Se l’ambiente di test è dietro una VPN o una lista di indirizzi consentiti, predisponi l’accesso in anticipo e provalo. Decidi se il web application firewall resta attivo. Se l’oggetto del test è l’applicazione, fai passare i tester attraverso il firewall; se l’oggetto è il firewall, lascialo attivo e dillo.
Dati. Popola l’ambiente di test con dati simili a quelli reali nella struttura, non nel contenuto. Dati personali reali in un ambiente di test sono un rilievo prima ancora che il test cominci.
Backup. Accertati che l’ambiente sottoposto a test si possa ripristinare. I tester sono prudenti; i backup servono per il caso in cui la prudenza non è bastata.
Avvisa
Il team operativo e il team di monitoraggio, a meno che il test non debba metterli alla prova. Comunica loro gli indirizzi di origine dei tester e le date. Altrimenti il primo giorno finisce con i tester bloccati e un incidente aperto.
Il fornitore di hosting o cloud, se la sua politica lo richiede. I grandi fornitori cloud non chiedono un preavviso per i test sulle tue risorse svolti entro le regole che pubblicano; le società di hosting più piccole spesso sì.
I fornitori i cui sistemi vengono toccati. Serve il loro consenso scritto.
Un referente, raggiungibile durante le ore di test, con l’autorità di prendere decisioni: prolungare un account, riavviare un servizio, fermare il test.
Firma
- l’accordo di riservatezza (NDA), prima di consegnare qualsiasi cosa tra quelle elencate sopra;
- il contratto;
- la lettera di autorizzazione e le regole di ingaggio.
A che cosa serve ciascuno è spiegato in «Che cosa rende legale un penetration test».
Durante il test
- Non rilasciare modifiche nell’ambiente sottoposto a test senza avvisare i tester. Un rilievo che sparisce durante la notte costa una giornata di confusione.
- Non correggere i rilievi a test in corso, tranne quelli di gravità critica. Se ne correggi uno, dillo.
- Rispondi subito alle domande. Un tester che chiede come dovrebbe funzionare una funzionalità di solito ha trovato qualcosa.
- Aspettati subito i rilievi urgenti. Una vulnerabilità critica viene comunicata appena è confermata, non nel report finale.
Dopo il test
- Leggi la sintesi con la direzione e i rilievi con i team tecnici. Sono scritti per lettori diversi.
- Partecipa al debriefing. È l’ora meno costosa dell’incarico.
- Pianifica le correzioni per priorità e avvisa i tester quando sono state rilasciate.
- Usa il retest. Una correzione non verificata è un’ipotesi.
- Tieni riservato il report. Finché le correzioni non sono applicate, è un manuale per attaccarti. Per clienti e auditor c’è la lettera di attestazione.
La checklist
| Prima dell’inizio | Fatto |
|---|---|
| Domanda e perimetro messi per iscritto, esclusioni comprese | |
| Ambiente scelto, finestre di test concordate | |
| Account creati per ogni ruolo, in due tenant se il prodotto prevede tenant | |
| Documentazione consegnata | |
| Accesso di rete predisposto e provato | |
| Dati di test pronti, nessun dato personale reale | |
| Backup verificati | |
| Team operativo, monitoraggio e fornitori avvisati | |
| Referente indicato | |
| NDA, contratto, lettera di autorizzazione, regole di ingaggio firmati |
La pagina di ogni servizio elenca che cosa serve da te per quel test specifico.