Cosa dovrebbe davvero dirti un report di penetration test
La maggior parte dei report è un export di scanner con sopra un logo. Ecco cosa pretendere invece, e come capire in dieci minuti se ti hanno venduto test veri.
A red pen over a printed page
Close crop of one hand holding a red pen above a printed page, mid-annotation. Bare pale surface, nothing else in frame. The pen is the only colour.
2400×1350 · WebP · <350KB
Di solito si capisce in dieci minuti. Apri il report, vai a un rilievo e fai una domanda: il mio ingegnere potrebbe correggerlo lunedì usando solo ciò che è scritto qui? Se la risposta è no, non hai comprato un penetration test. Hai comprato una licenza di scanner con la carta intestata di un consulente.
Il segnale: severità senza racconto
Uno scanner produce un elenco. Quaranta rilievi, ciascuno con un punteggio CVSS, ciascuno vero per conto suo e nessuno collegato agli altri. Un tester produce un racconto: quel sottodominio dimenticato esponeva una pagina di login di staging, staging condivideva una password con la produzione, e la produzione non aveva MFA sugli account amministrativi. Presi da soli sono medio, medio e basso. Concatenati, è così che qualcuno possiede il tuo ambiente prima di pranzo.
Se il tuo report non contiene alcuna catena — nessuna frase che inizi con «combinando i rilievi 12, 19 e 27» — nessuno ti ha davvero testato. Hanno puntato uno strumento verso di te.
Quaranta rilievi ordinati per punteggio ti dicono cosa ha notato uno scanner. Nove rilievi ordinati per ciò che un attaccante ne farebbe ti dicono cosa correggere.
Cosa serve a ogni rilievo
- Passi di riproduzione che il tuo ingegnere possa seguire senza chiamare il tester. La richiesta esatta, il parametro esatto, la precondizione esatta.
- Evidenze. Uno screenshot o una risposta catturata che dimostri che il problema è reale e non teorico.
- Impatto nei tuoi termini. Non «divulgazione di informazioni», ma «un utente non autenticato può enumerare ogni indirizzo e-mail dei clienti».
- Una correzione che nomina la cosa. Il file, la chiave di configurazione, l'header. Non «implementate la validazione degli input».
- Una severità onesta, adattata al tuo ambiente. Una RCE su una macchina isolata senza dati non è una criticità, qualunque cosa dica lo scanner.
Le parti che quasi tutti i report saltano
Un buon report ti dice anche cosa non è stato testato e perché. I confini del perimetro, i sistemi esclusi, le credenziali mai arrivate, l'ambiente rimasto giù due giorni della finestra. Quelle lacune sono rischio che continui a portarti, e nasconderle rende il report più bello e te meno sicuro.
Dovrebbe dirti anche cosa ha retto. Se il tuo WAF ha bloccato i tentativi di injection e il tuo EDR ha ucciso il payload, quello merita di stare per iscritto. L'hai pagato; dovresti poterlo dimostrare.
Il retest fa parte del lavoro
Un rilievo non è chiuso perché è stato chiuso un ticket. È chiuso perché qualcuno ha riprovato l'exploit e ha fallito. Qualsiasi società che fatturi a parte la verifica dei propri rilievi ha un incentivo che non vuoi in questa relazione. Il retest dovrebbe essere incluso, e il report riemesso dovrebbe mostrare il rilievo barrato con la data della verifica.
Una breve checklist
- C'è almeno un percorso d'attacco concatenato, scritto come racconto?
- Un ingegnere riesce a riprodurre il rilievo principale senza fare domande?
- Ogni correzione nomina un file, un'impostazione o un header?
- C'è una sezione su cosa è rimasto fuori perimetro o non testato?
- Il retest è incluso, ed entro quando?
- I rilievi critici sono stati comunicati durante il test, e non conservati per la restituzione finale?
Quest'ultimo punto pesa più di tutti gli altri messi insieme. Se un tester trova una compromissione attiva o una criticità esposta su internet il secondo giorno, dovresti saperlo entro un'ora. Scoprirlo da un PDF tre settimane dopo non è uno stile di reportistica. È negligenza.