Il report è la parte di un penetration test che resta nel tempo. I test si svolgono nell'arco di alcuni giorni o settimane; il report è ciò su cui lavorano i Suoi sviluppatori per le correzioni, ciò che legge la direzione e ciò che può condividere con un cliente o un partner. Un report debole può far sembrare superficiale un test accurato, mentre uno chiaro trasforma i rilievi in decisioni. Questa guida spiega che cosa contiene di solito un report professionale di penetration test, come leggerlo e che cosa chiedere prima dell'avvio dell'incarico.
Che cos'è
Un report di penetration test è una registrazione scritta di che cosa è stato testato, come, in quali condizioni e che cosa è stato trovato. Deve essere leggibile da due pubblici. Gli interlocutori non tecnici hanno bisogno di una breve sintesi del rischio complessivo, dei problemi più importanti e delle priorità consigliate. I team tecnici hanno bisogno, per ciascun rilievo, di dettagli sufficienti a comprenderlo, riprodurlo in un ambiente sicuro e correggerlo. Un buon report registra anche i propri limiti: che cosa era fuori perimetro, che cosa non è stato possibile testare ed eventuali condizioni che hanno inciso sulla copertura, come account di test non disponibili o una finestra ridotta. Senza questi limiti, i lettori possono presumere che il report copra più di quanto effettivamente copre.
Per Chi È
Questa guida è utile per:
- Acquirenti che confrontano proposte e vogliono sapere quale deliverable riceveranno effettivamente
- Responsabili tecnici che riceveranno i rilievi e dovranno pianificare il rimedio
- Manager che devono condividere una sintesi con un cliente, un partner, un auditor o il consiglio di amministrazione senza sopravvalutare il risultato
- Team che hanno ricevuto un report precedente e lo hanno trovato difficile da tradurre in azioni
Cosa Aiuta A Chiarire
Conoscere la struttura attesa La aiuta a verificare:
- Se il perimetro e le regole d'ingaggio riportati nel report corrispondono a quanto concordato
- Se ogni rilievo ha evidenze, una classificazione di gravità chiara e indicazioni di rimedio pratiche
- Quali problemi richiedono un intervento immediato e quali possono essere pianificati nei normali cicli di sviluppo
- Quali affermazioni possono essere condivise all'esterno in sicurezza e quali sono destinate solo al personale tecnico
Cosa è incluso
- Executive summary: quadro complessivo, rilievi più significativi e priorità consigliate in linguaggio semplice
- Perimetro e regole d'ingaggio: obiettivi, ambienti, ruoli utente, date, finestra di test ed esclusioni
- Sintesi della metodologia: l'approccio e i framework di riferimento utilizzati, come le linee guida OWASP per le applicazioni web
- Registro dei rilievi: ogni problema con titolo, gravità, asset interessato, descrizione, riferimento all'evidenza e impatto sul business
- Dettaglio tecnico: passaggi che il Suo team può utilizzare per comprendere e riprodurre il problema in sicurezza
- Indicazioni di rimedio: correzioni pratiche e, ove utile, mitigazioni a breve termine
- Limitazioni: che cosa non è stato possibile testare e perché
- Sezione di retest: lo stato dei rilievi concordati dopo la correzione da parte del Suo team, ove sia previsto un retest
Cosa non è incluso
- Una dichiarazione che il sistema è sicuro o privo di vulnerabilità residue dopo il test
- Rilievi esterni al perimetro concordato presentati come se fossero stati testati
- Certificazione, approvazione di conformità o un parere di audit formale
- L'implementazione delle correzioni, salvo accordo separato
Quando sceglierlo
Legga questa guida prima di firmare una proposta di test, così da poter chiedere un report di esempio e confermarne la struttura. È utile anche quando arriva un report: utilizzi le sezioni sopra come checklist per verificare se manca qualcosa. Se un interlocutore Le ha chiesto di "inviare il report del pentest", decida in anticipo se ha bisogno del documento tecnico completo oppure di un executive summary e di una lettera sullo stato del rimedio. Condividere ampiamente il dettaglio tecnico completo aumenta il rischio, perché descrive le debolezze dei Suoi sistemi.
Il nostro approccio
Chieda chiarezza sulla gravità prima dell'inizio dei test. Molti fornitori utilizzano una scala basata su probabilità e impatto, talvolta con riferimento al CVSS; ciò che conta è che sia coerente e spiegata. Concordi come verranno conservate e condivise le evidenze e chi sono i Suoi referenti nominativi. Quando arriva il report, pianifichi un debriefing affinché gli sviluppatori possano porre domande finché il contesto è ancora fresco. Trasformi il registro dei rilievi in ticket con responsabili e date obiettivo e corregga per primi i problemi di gravità più alta. Poi richieda un retest dei rilievi concordati, così che il report possa registrare ciò che è stato risolto. Il nostro servizio Penetration Testing fornisce un executive summary, una sintesi del perimetro e delle regole d'ingaggio, un registro dei rilievi classificati per gravità con riferimenti alle evidenze, il dettaglio tecnico di ciascun rilievo, una roadmap di rimedio prioritizzata e l'esito del retest, ove previsto. Qualunque fornitore scelga, conservi ogni versione del report, registri quali rilievi sono stati accettati come rischi anziché corretti e annoti chi ha preso tale decisione. Questa documentazione è spesso preziosa quanto il test stesso la prossima volta che qualcuno chiederà della Sua postura di sicurezza.
Domande frequenti
Articoli correlati
Inizia
Desidera un report su cui il Suo team possa davvero agire?
Ci indichi quali sistemi devono essere testati e chi leggerà i risultati. Confermeremo per iscritto perimetro, regole d'ingaggio e struttura del report.
Richieda un perimetro scritto