Come sapere quando è stato completato un pen-test?

Quindi questa è in realtà una domanda molto interessante per l'industria in generale. Il modo in cui ti suggerisco di gestirlo è

• Avere qualcosa nel contratto che disconosce la responsabilità per le vulnerabilità non annotate durante i test. Il motivo è che è praticamente impossibile essere sicuri di aver trovato tutti i problemi sfruttabili in un sito Web o in qualsiasi altro sistema. Per scegliere un esempio, pensa a tutti i siti che erano vulnerabili a shellshock per anni e anni, se tutti le aziende pen-test che hanno toccato uno di questi siti sono responsabili per non aver detto ai propri clienti?

• Avere una metodologia, dicendo quello che farai. Questo dovrebbe coprire le aree generali di test che saranno completate. Per i siti Web, considera la possibilità di basarsi su qualcosa come OWASP Top 10 come punto di partenza. Questo ti dà una base comune con il cliente su ciò che guarderai.

• Assicurati che la tua azienda copra le nozioni di base con un elenco di controllo. come @rapli dice sopra documenta tutte le piccole cose, ma non esagerare con la severità. Anche se è importante assicurarsi che il test non sia solo un elenco di controllo, l'uso di uno può evitare di mettere in imbarazzo gli errori in cui i test di base vengono persi.

Il problema che potresti / incorrerai è aspettative irrealistiche da parte dei clienti. questo è un caso per caso da affrontare. Se ottieni un cliente che si aspetta che la sua complessa applicazione venga completamente rivista in 5 giorni-persona di test, dovresti spiegare perché non è un concetto pratico:)

Specifica nel contratto quali aspetti di sicurezza investigi e prendi la responsabilità solo per quelli. Non troverai sempre vulnerabilità. Ma ti garantisco che troverai poche cose minori, e ti suggerisco di includere ogni piccolo dettaglio che puoi nel rapporto, mancare le HST nelle intestazioni, i cifrari deboli, ecc. Quindi vedono che hai fatto qualcosa.

Esistono alcuni strumenti di segnalazione che conosco, ma non sono disponibili pubblicamente o prodotti a pagamento.

Come aggiunta alle altre risposte:

Quando il contratto stabilisce il tuo ambito e quali vulnerabilità testare, potresti annotare che hai effettivamente testato casi nell'ambito delle vulnerabilità note definite nel contratto. Qualcosa come:

SQL injection:

SQL-Injections are ...

We identified 42 Input fields in the Webpages in Scope. We identified 0 
Input fields vulnerable to SQL injection (with our used method).

Lo svantaggio è: nel caso ci sia effettivamente un'iniezione SQL in uno dei campi elencati in allegato al rapporto; non hai promesso il 100% di sicurezza ma hai promesso che questa non è una vulnerabilità, ma sicuramente hai fatto qualcosa di sbagliato - ecco perché dovresti in qualche modo stabilire quale tipo di test hai usato, quale tipo di SQL-Injection sono allo stato dell'arte nell'introduzione a SQL-Injections, quindi non verrai accusato di non trovare attacchi che verranno trovati in futuro.

Questo funziona anche per la sicurezza generale del sito web:

HTTPS: https is ... recommended to use TLS X.Y ...

We determined the usage of https for all websites in Scope with TLS X.Y.
Certificates expire Dates are set to Date X which is in the recommended
certificate expire time range. Certificates hold an 4096-Bit key which is
acceptable for current usage.

Prova anche a creare i modelli dei tuoi rapporti poiché non vuoi riscrivere tutto su SQL-Injection e HTTPS / TLS ecc. ancora e ancora, quindi devi solo riempire i risultati dei tuoi test. Ciò assicurerà anche che tu abbia effettuato tutti i test e che non ne sia venuto a mancare, quando vedi che alcuni paragrafi non sono stati scritti per essere eseguiti e non hanno trovato nulla o non hanno trovato alcun risultato.