Ci hanno chiesto di fare un penetration test: un esempio pratico di cos'è e se ci serve davvero?

I grandi retailer sono terrorizzati dal rischio legato alla supply chain. Se sul vostro database finiscono i dati dei loro negozi o del loro fatturato, devono poterne rispondere al consiglio di amministrazione. Non provate assolutamente a spacciare il report di uno scanner automatico di vulnerabilità per un penetration test: i team di sicurezza enterprise se ne accorgono alla prima pagina e mandate a monte l'accordo.

Lo abbiamo fatto per la prima volta lo scorso autunno per un nostro software di logistica di dimensioni simili. Il test è durato 4 giorni lavorativi e abbiamo speso 3.200 GBP. Hanno trovato in tutto 6 falle, di cui una critica. Eravamo convintissimi del nostro codice, ma da un leak negli header del server si leggeva chiaramente la versione esatta del nostro database. Abbiamo patchato tutto in una settimana e, appena visto il report, il cliente ha firmato il contratto all'istante.

Fate molta attenzione quando definite il perimetro del contratto. Non includete il provider di hosting della vostra infrastruttura cloud; limitatevi al codice proprietario, ai meccanismi di autorizzazione e alle API. Altrimenti cercheranno di scansionare i servizi del provider cloud, raddoppiando tempi di test e budget.

Non accettate subito i primi preventivi inviati dalle società di sicurezza. Molte agenzie sparano cifre assurde come 10.000 GBP per poi limitarsi a far girare tool automatici. Chiedete 2-3 preventivi diversi a professionisti senior certificati o realtà boutique indipendenti. Verificate che il report venga redatto secondo metodologie riconosciute a livello internazionale.

A fronte di un contratto che genererà 52.000 GBP all'anno, un costo di circa 3.000 GBP per il test è a tutti gli effetti un costo di acquisizione cliente da sostenere senza esitazioni. Inoltre, una volta ottenuto il report, potrete usarlo per i successivi 12 mesi come prova di affidabilità con tutti gli altri clienti enterprise con cui tratterete.

se durante il test trovano dele falle e non riusciamo a sistemarle subito cosa succede? la società di sicurezza manda il report direttamente al cliente o prima lo consegna a noi?

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

Il flusso standard si articola in 4 fasi: 1) Definizione del perimetro e firma dell'accordo di riservatezza, 2) Simulazione di attacco in ambiente di staging (un server clonato privo di dati reali), 3) Consegna al vostro team del report intermedio con l'elenco delle vulnerabilità e relativa risoluzione, 4) Verifica delle correzioni e stesura del report finale pulito da presentare all'ente.

Racconto cosa mi è successo, magari vi è utile. La maggior parte degli incidenti non inizia da una vulnerabilità, ma da una password trapelata.

Confermato dall'esperienza.

Come avete risolto questo? Se non lo rendete scritto fin dall'inizio, poi nascono discussioni.

Quando prendi una decisione, guarda prima quali dati hai a disposizione. È tutto, scusate se mi sono dilungato.

Secondo me è difficile essere così netti sul lato esempio penetration test. Se rimproverate i falsi allarmi, nessuno segnalerà più nulla.

Io seguirei questa strada.

Preso nota grazie.

Mi chiedo anch'io. Quando decidiamo senza misurare, finiamo sempre nello stesso punto.

La sicurezza non è assoluta; significa rendere l'attacco non conveniente. Sono curioso di sapere se qualcuno lo fa in modo diverso.

Grazie per aver scritto. Se è la prima volta, inizia in piccolo, il ridimensionamento viene dopo.

Chiunque abbia fretta su esempio penetration test si blocca nello stesso punto. Confermato dall'esperienza.

Sono d'accordo in parte, in parte no. Se ricevete tre risposte diverse su un argomento, la domanda è posta male.

Le soluzioni che funzionano su piccola scala crollano quando si cresce, l'ho imparato tardi. Naturalmente cambia se la vostra situazione è diversa.

Racconto la mia esperienza. Chiunque abbia fretta su esempio penetration test si blocca nello stesso punto.

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

Sono d'accordo, anzi vorrei sottolinearlo. La risposta varia molto in base al settore, non esiste una regola generale.

Naturalmente cambia se la vostra situazione è diversa.

Ottimo lavoro.

La risposta sopra ha colto l'essenza della questione. Quando prendete una decisione scrivete anche lo scenario peggiore, non solo quello migliore.

Le modifiche ai dati di pagamento non vanno mai verificate tramite il canale di provenienza. Confermato dall'esperienza.