Redazione dei risultati

Un finding è l'unità di valore di un report di pentest. Un buon finding è chiaro, supportato da prove e attuabile.

Il lettore dovrebbe riuscire a comprendere il problema, convincersi che sia reale e sapere cosa fare, tutto dalla stessa voce.

Utilizzi un unico modello coerente per ogni finding. La coerenza genera fiducia e rende i finding confrontabili.

Ogni finding contiene le stesse sezioni fisse.

Il titolo dovrebbe indicare in poche parole la classe e la posizione della vulnerabilità. È la prima cosa che il lettore scorre.

• Buono: SQL injection nel modulo di accesso
• Debole: Problema del database

Sia specifico, non vago.

La descrizione spiega in cosa consiste il difetto e perché esiste, in due o tre frasi. Presuma che il lettore sia un tecnico competente che non ha ancora visto il bug.

Indichi la causa principale, non soltanto il sintomo.

Elenchi i passaggi per riprodurre il problema, precisi e numerati. Chiunque faccia parte del team dovrebbe poterli seguire e osservare lo stesso risultato.

Includa la richiesta, il payload e la risposta osservata.

L'impatto risponde alla domanda che ogni dirigente pone: e quindi? Traduca il difetto tecnico in conseguenze aziendali.

• Accesso completo in lettura al database degli utenti.
• Elusione dell'autenticazione per qualsiasi account.
• Potenziale violazione normativa.

Dichiari soltanto ciò che ha dimostrato. Se non ha estratto dati, dica che il difetto consente l'estrazione dei dati, non che ha esfiltrato dei record.

Indichi chiaramente come potenziali, e non confermate, le ipotesi non verificate.

Alleghi le prove minime necessarie a dimostrare il finding: una coppia richiesta/risposta o uno screenshot annotato.

Oscuri i segreti e i dati personali reali. Le prove aumentano la credibilità; un eccesso di prove nasconde il punto fondamentale.

Colleghi ogni finding a una classificazione riconosciuta, come CWE o OWASP Top 10.

I riferimenti consentono al cliente di approfondire autonomamente il problema e dimostrano che il suo lavoro si basa su standard riconosciuti.

Utilizzi la forma attiva, frasi brevi e nessun gergo non spiegato. Definisca un acronimo la prima volta che lo utilizza.

Ricordi che il pubblico è duplice: le righe di sintesi devono essere comprensibili a un responsabile, mentre i passaggi devono soddisfare un tecnico.

Eviti questi errori frequenti nella scrittura dei finding.

• Copiare e incollare l'output grezzo di uno scanner come finding.
• Assenza di una chiara descrizione dell'impatto.
• Passaggi impossibili da riprodurre.
• Gravità incoerente per problemi simili.

Ha imparato a scrivere finding chiari e attuabili.

• Utilizzi un unico modello coerente per ogni finding.
• Titoli specifici, descrizioni della causa principale e passaggi numerati per la riproduzione.
• Traduca i difetti nel loro impatto aziendale.
• Dichiari soltanto ciò che ha dimostrato e oscuri le prove.
• Inserisca collegamenti ai riferimenti CWE e OWASP.

Ora imparerà a fornire indicazioni efficaci per la correzione.