Abbiamo ricevuto un report di penetration test di 40 pagine: avete un report di esempio con cui fare un confronto?

Se nel report manca la prova di exploit (Proof of Concept), il test di fatto non è stato eseguito. Se ad esempio dichiarano di aver trovato una SQL Injection, devono mostrare passo dopo passo come hanno estratto un dato innocuo dal database. Non possono limitarsi a incollare l'alert del software di scansione e chiuderla lì.

Due anni fa siamo cascati nella stessa trappola per 2.500 sterline. L'auditor di sicurezza del nostro cliente ha respinto il report all'istante, dicendoci chiaramente che non si trattava di un penetration test ma di un semplice vulnerability assessment. Abbiamo dovuto rifare tutto da capo con un altro professionista.

3.500 sterline sul mercato britannico sono un budget davvero al limite per un test manuale approfondito. A queste cifre di solito lanciano il tool automatico e stampano il report così com'è. Un test vero richiede almeno 3-5 giorni/uomo di lavoro manuale, e i costi lievitano di conseguenza.

Rimandate indietro il documento all'azienda e pretendete due cose: primo, un executive summary di una pagina con rischi e impatti aziendali; secondo, i passaggi concreti per consentire al vostro team di sviluppo di verificare le correzioni. Se nel contratto c'è una clausola sui test manuali, sono tenuti a rettificarlo.

Nel contratto di fornitura, come viene definita esattamente la tipologia di test? Vulnerability assessment o penetration test? Purtroppo nel settore c'è molta confusione tra i due servizi e, se sul contratto compare "vulnerability assessment/scan", sarà difficile contestare il risultato.

nn fatevi ingannare dal numero di pagine ma comunque un report pulito di 15 pagine redatto a mano e dritto al punto vale dieci volte più di un dump auttomatico da 80 pagine.

Nel vostro interesse, vi consiglio vivamente di chiedere una revisione al fornitore di sicurezza prima di inoltrare questo report al cliente enterprise. Un auditor esperto riconoscerà immediatamente l'output di uno scanner automatico, e questo comprometterà la vostra credibilità.

correzione: mi ricordavo male il numero, era un po' più basso.

Per verificare il report che avete ricevuto, controllate questi tre punti: 1) I falsi positivi sono stati filtrati o ogni singolo avviso è finito nel report? 2) I punteggi di rischio sono contestualizzati rispetto al vostro modello di business? 3) Chi scrive il codice, leggendolo, riesce a capire operativamente come sistemare la falla?

Argomento molto attuale.

Ha ragione.

raro trovare articoli che spiegano le cose così chiaramente.

Sono una piccola impresa, vi parlo dal mio punto di vista. La risposta varia molto in base al settore, non esiste una regola generale.

Lascio una nota potrebbe servire.

Grazie mille, mi è stato molto utile. La maggior parte degli incidenti non inizia da una vulnerabilità, ma da una password trapelata.

Questa è la mia opinione, non la scrivo come verità assoluta.

In generale è corretto, ma manca un pezzo. Da noi la cosa che faceva perdere più tempo era non sapere chi decidesse.

Chiunque abbia fretta su report di penetration test si blocca nello stesso punto.

In teoria è giusto, in pratica non funziona così. Il tempo che impiegate a rilevare un problema ne determina direttamente il costo.

Naturalmente cambia se la vostra situazione è diversa.

Sono d'accordo.

Dopo aver vissuto questa cosa, il mio punto di vista è cambiato. Se rimproverate i falsi allarmi, nessuno segnalerà più nulla.

Stavo pensando la stessa cosa. Un report di scansione automatica e un penetration test non sono la stessa cosa.