Indicazioni per la correzione

Trovare le vulnerabilità è solo metà del lavoro. Il valore duraturo di un pentest consiste nell'aiutare il team a correggerle.

Buone indicazioni per la correzione trasformano un report da semplice denuncia a guida operativa.

Consigli generici come "sanificare l'input" fanno perdere tempo al lettore. Colleghi la correzione alla tecnologia esatta in uso.

• Debole: convalidare l'input dell'utente.
• Forte: utilizzare query parametrizzate tramite l'API delle prepared statement.

Quando possibile, includa un breve esempio del pattern corretto. I tecnici intervengono più rapidamente quando possono vedere la forma che il codice dovrebbe assumere.

Mostri affiancati il codice vulnerabile e quello corretto.

Raccomandi correzioni che affrontino la causa principale, non soltanto il sintomo rilevato.

Se un endpoint presentava una SQL injection, la vera correzione consiste nell'imporre query parametrizzate ovunque, non nel correggere quella singola riga.

Raccomandi controlli stratificati, in modo che un singolo errore non porti alla compromissione.

• Correzione primaria: query parametrizzate.
• Secondaria: account del database con privilegi minimi.
• Rilevamento: avvisi sulle query anomale.

I diversi livelli fanno guadagnare tempo e riducono l'ampiezza dell'impatto.

A volte una correzione completa richiede settimane. Offra sia una mitigazione rapida sia una correzione duratura, così il cliente può ridurre il rischio già da oggi.

Specifichi chiaramente che la mitigazione è temporanea.

Aiuti il cliente a pianificare stimando l'impegno insieme alla priorità. Un bug critico che richiede dieci minuti per essere corretto è chiaramente il primo intervento da eseguire.

Combini la gravità con l'impegno per suggerire un ordine sensato.

Indichi fonti affidabili come le OWASP Cheat Sheets, le guide dei fornitori per il rafforzamento della sicurezza e le note CWE sulle misure di mitigazione.

In questo modo offre ai tecnici una risorsa per approfondire e dimostra che i suoi consigli sono in linea con il settore.

Spieghi al cliente come verificare ogni correzione e offra un nuovo test. Una correzione non verificata potrebbe essere incompleta.

Riutilizzi i passaggi di riproduzione come test di verifica: se i passaggi non funzionano più, la correzione ha avuto effetto.

Presenti le indicazioni in modo collaborativo. Il team di sviluppo conosce il proprio stack e i propri vincoli meglio di Lei.

Offra delle alternative quando è ragionevole farlo ed eviti un tono accusatorio. Il suo obiettivo è rendere più sicuri i sistemi del team, non vincere una discussione.

Raccomandi al cliente di monitorare ogni finding fino alla chiusura nel proprio sistema di ticketing, collegandolo all'ID del report.

Un finding non è concluso quando viene letto, ma quando è stato corretto, verificato e chiuso.

Verifichi la sua comprensione delle indicazioni per la correzione.

Ha imparato a fornire indicazioni efficaci per la correzione.

• Sia specifico rispetto alla tecnologia e mostri il codice corretto.
• Corregga le cause principali, non soltanto i sintomi.
• Raccomandi la difesa in profondità e correzioni a breve e lungo termine.
• Stimi l'impegno per aiutare a stabilire le priorità e faccia riferimento a OWASP/CWE.
• Offra verifica e nuovi test e monitori i finding fino alla chiusura.

Ha completato il corso Penetration Test Reporting.