Pentest web su sito in produzione: come redigere il test plan per evitare downtime?

Occhio alla funzione di compilazione automatica dei form negli scanner di vulnerabilità. Se iniziano a scansionare l'iscrizione alla newsletter o il modulo contatti, in 10 minuti possono inserire 20 mila mail finte nella coda, facendo finire in blacklist il vostro server di posta in uscita. Escludete questi form dalla scansione.

Create un'utenza di test dedicata per il team di sicurezza e assegnatele un credito fittizio. Evitate assolutamente che provino a eliminare o prenotare a carrello articoli reali a magazzino visibili ai clienti, altrimenti le scorte si bloccano.

Due anni fa abbiamo fatto un test in produzione e il pentester, cercando SQL Injection nel DB, ha lanciato una query con istruzione di sleep. Il connection pool del database si è saturato in 3 minuti e l'intero checkout del sito è andato in errore per 20 minuti. Un devops reperibile è d'obbligo.

Noi l'abbiamo fatto fare tra le 02:00 e le 06:00 di notte. Su un sito da 1.000 ordini al giorno, di notte gli ordini scendono a circa 15. In caso di blocco il nostro danno economico è stato vicino allo zero: mai fare pentest in produzione durante l'orario di lavoro.

Come testeranno la parte del gateway di pagamento? Faranno transazioni da pochi centesimi sul POS reale o metterete in piedi un gateway simulato? Se questo punto non è chiarito a contratto, l'amministrazione impazzisce.

inserite assolutamente un unico numero di telefono autorizzato nel piano di test. appena si nota qualcosa di strano chi fa il pentest deve spegnerre i tool non appena riceve la chiamata di stop da quel numero.

Non riuscire a fare un ambiente di staging identico a quello di produzione e fare pentest in produzione come fosse uno stress test è proprio la classica ricerca del brivido tipica del nostro settore. Almeno fate un backup completo un'ora prima del test, così la mattina dopo vi evitate uno scenario apocalittico.

Nel contratto di test da redigere devono essere specificate chiaramente le responsabilità delle parti, stabilendo che la ditta appaltatrice sarà responsabile per eventuali danni commerciali derivanti dall'inosservanza del piano e degli orari concordati da parte del team di test.

L'anno scorso abbiamo vissuto quasi la stessa cosa. Quando prendi una decisione, guarda prima quali dati hai a disposizione.

Confermato dall'esperienza.

Tre cose da controllare mentre lo fai. Il vero problema non è il numero, ma su cosa si basa quel numero.

Il fatto che tutti facciano una cosa non significa che sia quella giusta. Io seguirei questa strada.

Sono d'accordo.

Sono emerse tre opinioni diverse si completano a vicenda. Se ricevete tre risposte diverse su un argomento la domanda è posta male.

Correggetemi se sbaglio.

Ti seguo.

Tre cose da controllare mentre lo fai. Se rimproverate i falsi allarmi nessuno segnalerà più nulla.

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

Esatto, e non è nemmeno così noto. Cercare di farlo da soli è la strada più costosa.

L'anno scorso abbiamo vissuto quasi la stessa cosa. Le soluzioni che funzionano su piccola scala crollano quando si cresce, l'ho imparato tardi.

Spero che le sia utile.

Ho lavorato a lungo su questo. Se il percorso di notifica è lungo, la notifica non arriva; una notifica mancante significa un evento scoperto tardi.

Lascio una nota, potrebbe servire.

Grazie per averlo scritto, è proprio così. boh avere il backup accessibile sulla stessa rete e con le stesse credenziali lo rende parte del bersaglio.

L'errore commesso da piano di test web pentest è generalmente reversibile ma costoso. insomma se avete domande, scrivete, rispondo per quanto possibile.