Come leggere il report di un penetration test

Il report è la parte di un penetration test che le resta dopo che i tester se ne sono andati. Leggerlo bene significa correggere prima le cose giuste e trarre un valore reale dal retest. Aiuta anche a riconoscere un “pentest” che in realtà era una scansione automatica con una copertina.

Cosa contiene un buon report

La OWASP Web Security Testing Guide descrive una struttura del report che costituisce un utile termine di paragone. Ogni parte si rivolge a un lettore diverso, e la guida suggerisce che le sezioni possano essere stampate separatamente per i team che ne hanno bisogno.

Legga con attenzione la sezione sulle limitazioni. Se i blocchi degli account hanno interrotto i test, o se un server è stato escluso dal perimetro il secondo giorno, il report dovrebbe dirlo. Un risultato pulito per un’area che non è mai stata testata non dice nulla.

Il National Cyber Security Centre (NCSC) britannico aggiunge due elementi facili da trascurare. Un buon report riporta l’opinione dei tester su quanto fosse accurata la sua valutazione interna delle vulnerabilità e consigli su come migliorare quel processo.

Anatomia di un buon rilievo

Ogni rilievo dovrebbe permettere a un tecnico che non ha partecipato al progetto di capire il problema, riprodurlo e correggerlo. Verifichi che ci siano:

• un ID univoco e un titolo chiaro
• una valutazione della gravità, con il vettore CVSS quando si usa CVSS
• gli asset esatti interessati, come host, URL, parametri o ruoli
• una descrizione della debolezza e del motivo per cui è importante per la sua attività
• le evidenze, come richieste e risposte, screenshot o output dei comandi
• i passaggi per riprodurlo
• indicazioni di correzione specifiche, con riferimenti come un bollettino del produttore

Ecco un esempio sintetico di come appare in pratica:

ID        AF-07  Invoice download does not check ownership
Severity  Medium  CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N (6.5)
Affected  GET /api/v1/invoices/{id}/pdf on portal.example.eu
Evidence  Logged in as customer A, a request for invoice 10452
          (customer B) returned customer B's PDF.
Impact    Any customer can download other customers' invoices,
          including names, addresses and amounts.
Fix       Check on the server that the invoice belongs to the
          logged-in customer for every request.
Retest    Request another customer's invoice and expect 403 or 404.

Il vettore permette di capire perché il punteggio è medio (Medium): la riservatezza è compromessa, integrità e disponibilità no. Permette anche di dissentire con buone ragioni. Poiché le fatture contengono dati personali, potrebbe decidere che il problema meriti una priorità più alta di quella suggerita dal punteggio.

Come vengono classificati i rilievi

Molti report classificano i rilievi con il Common Vulnerability Scoring System (CVSS) gestito da FIRST, e l’NCSC lo cita tra gli schemi di valutazione che si possono richiedere. CVSS v3.1 e v4.0 usano le stesse fasce qualitative:

Tre aspetti aiutano a leggere queste valutazioni:

• Un punteggio base misura la gravità, non il suo rischio. FIRST lo descrive come il riflesso delle caratteristiche intrinseche della vulnerabilità in uno scenario peggiore ragionevole, e afferma che chi lo utilizza dovrebbe integrarlo con informazioni sul proprio ambiente.
• La gravità è un dato di partenza. La guida OWASP raccomanda che la sintesi per la direzione lo dichiari esplicitamente: la valutazione alimenta il processo di gestione del rischio, non lo sostituisce.
• I tester non conoscono il contesto aziendale. L’NCSC consiglia di valutare i rilievi in autonomia, perché le valutazioni possono essere troppo alte o troppo basse. Mette però in guardia dall’usare questo argomento per minimizzare i problemi.

Cosa correggere per primo

1. Tutto ciò che è sfruttabile da internet senza autenticazione, soprattutto se porta all’esecuzione di codice, all’accesso ai dati o al controllo amministrativo.
2. Le catene di attacco. Un buon report mostra come più rilievi di gravità inferiore si combinano in uno grave. La NIST SP 800-115 osserva che gli scanner non possono rilevare debolezze che emergono solo combinando più vulnerabilità. Trovare queste catene è gran parte del valore aggiunto da un tester umano.
3. I sistemi che custodiscono le chiavi, come identity provider, server di backup, gateway di accesso remoto e tutto ciò che tratta dati personali.
4. Le correzioni rapide. A volte una sola modifica di configurazione chiude più rilievi in una volta.
5. Le cause profonde. Il NIST raccomanda un’analisi delle cause principali dopo una valutazione, perché i risultati possono indicare processi deboli oltre che sistemi deboli. Cinque patch mancanti su cinque server sono un unico rilievo sulla gestione delle patch, non cinque problemi indipendenti.

L’NCSC presenta il penetration test come una verifica della propria gestione delle vulnerabilità, non come il modo principale per trovarle. Con le sue parole, le nuove scoperte “dovrebbero essere l’eccezione, non la regola”. Se il report la sorprende, questo dice qualcosa anche sui suoi processi interni.

Il retest

Concordi il retest al momento della firma del contratto, compreso ciò che copre e quanto tempo avrà prima per correggere. Chieda i risultati come report aggiornato o come allegato, con uno stato per ogni rilievo: corretto, corretto in parte, non corretto o rischio accettato.

Un retest conferma correzioni specifiche. Non è un nuovo test. L’NCSC sottolinea che un test mostra solo lo stato dei sistemi nel giorno in cui è stato eseguito, e che è comune lasciar passare un anno o più tra un test e l’altro. Continui a effettuare verifiche nel frattempo.

Campanelli d’allarme in un “pentest” economico

La scansione automatica ha la sua utilità, e la NIST SP 800-115 la tratta come una delle tecniche di valutazione standard. Osserva però anche che gli scanner possono avere un alto tasso di falsi positivi e richiedono una persona con le competenze giuste per interpretarli. Il problema nasce quando l’output di una scansione non revisionato viene venduto come penetration test. I segnali d’allarme includono:

• rilievi con testo generico e copiato, senza alcuna evidenza che qualcuno li abbia confermati
• decine di voci a basso impatto su banner e cifrari TLS, ma nulla su controllo degli accessi, autenticazione o logica applicativa, che richiedono un test manuale
• gravità riprese direttamente dallo strumento; secondo il NIST i valutatori dovrebbero stabilire autonomamente il livello di rischio invece di accettare le valutazioni dello scanner
• nessuna sezione su perimetro, metodologia o limitazioni
• nessun passaggio per la riproduzione, quindi il suo team non può verificare una correzione
• nessun tester indicato per nome né qualifiche dichiarate; secondo l’NCSC i test dovrebbero essere eseguiti solo da personale qualificato ed esperto
• un “retest” che è semplicemente la stessa scansione eseguita di nuovo

Da dove iniziare

Prima del prossimo test, chieda al fornitore:

• Cosa rientra esattamente nel perimetro e cosa ne è escluso?
• I tester avranno account per ogni ruolo utente che si vuole coprire?
• È possibile vedere un report di esempio anonimizzato?
• Come vengono classificati i rilievi, e ognuno includerà un vettore CVSS?
• È incluso un retest, e con quale finestra temporale?

Se sta pianificando un test e vuole prima discutere il perimetro, consulti il nostro servizio di penetration test.