Come si fa un penetration test — come gestire il processo sul sito in produzione senza disservizi?

La regola d'oro per evitare disservizi è limitare la velocità delle richieste (rate limit) degli strumenti di scansione. Imponete al team di test un limite massimo di 5-10 richieste al secondo. Esigete inoltre che i tentativi massivi di injection sugli endpoint di ricerca che gravano pesantemente sui filtri del database vengano eseguiti manualmente e in modo controllato.

Punti che non devono mancare nel capitolato pre-test: 1) Nessun attacco DoS/DDoS o di forza bruta in produzione, 2) Vietata la cancellazione o la modifica di dati sul database di produzione, 3) Test da eseguire solo nella fascia oraria 01:00-06:00, 4) In caso di falla critica, notifica immediata senza attendere la data di consegna del report.

Durante il nostro primo pentest, il tester ha lanciato tentativi automatici sul form di registrazione scatenando il nostro servizio di verifica SMS. In tre ore sono partiti 14.000 SMS di verifica e l'operatore ci ha bloccato la linea per sospetto spam. Prima di iniziare il test impostate tassativamente in modalità mockup o sandbox le notifiche esterne, gli SMS e i servizi di pagamento.

Il vostro cliente richiede un pentest certificato TSE o basta il report di una società con certificazioni internazionali (come CREST, OSCP)? Questa distinzione cambia totalmente le aziende a cui chiedere preventivo e il budget finale da spendere.

Abbiamo fatto fare un test grey box per la nostra piattaforma B2B di dimensioni simili. Il processo è durato in tutto 5 giorni lavorativi. Sono emerse 2 falle critiche e 4 di medio livello. Avendo scelto la fascia oraria giusta, l'uso della CPU del server non ha mai superato il 40 percento e non abbiamo avuto il minimo disservizio.

Se la vostra infrastruttura server lo permette, create un ambiente di staging identico clonando il database di produzione con dati opportunamente mascherati. Facendo fare il test lì, il vostro traffico reale di ordini e utenti non correrà alcun rischio.

Non ingigantite la cosa, nessun professionista della sicurezza che lavora a livello enterprise si comporterebbe in modo così incosciente da buttare giù un sistema in produzione. cioè finché tenete aperta la comunicazione ed escludete i test DoS, il processo filerà liscio come l'olio.

PS: è stato chiesto qui sotto, ho scritto la risposta nel secondo messaggio.

Prima di iniziare il test è fondamentale formalizzare e firmare di proprio pugno un accordo di riservatezza (NDA) e una lettera di autorizzazione (Authorization Letter). Stabilire i limiti di responsabilità legale e mantenere la facoltà di stop immediato all'interno della vostra azienda è basilare per la corretta gestione della sicurezza delle informazioni.

C'è una cosa a cui prestare attenzione. Le persone difendono le abitudini, non i processi. La resistenza nasce da lì.

Bisogna procedere con ordine. Se il percorso di notifica è lungo, la notifica non arriva; una notifica mancante significa un evento scoperto tardi.

Spero che le sia utile.

Ti seguo.

Non lo sapevo.

A me è successo l'esatto contrario, per questo scrivo. Gli ambienti di test dimenticati diventano spesso un punto d'accesso più frequente del sistema live.

Confermato dall'esperienza.

Per un periodo ci siamo bloccati anche noi nello stesso punto. Se la verifica in due passaggi è attiva, una password rubata da sola non serve a nulla.

Lascio una nota, potrebbe servire.

Questo consiglio non va bene per tutti secondo me. comunque se la verifica in due passaggi è attiva una password rubata da sola non serve a nulla.

Grazie per averlo scritto, è proprio così. Se rimproverate i falsi allarmi, nessuno segnalerà più nulla.

Naturalmente cambia se la vostra situazione è diversa.

La penso diversamente. Le soluzioni che funzionano su piccola scala crollano quando si cresce, l'ho imparato tardi.

Io seguirei questa strada.

Può approfondire un po'? La risposta varia molto in base al settore, non esiste una regola generale.

Sono curioso di sapere se qualcuno lo fa in modo diverso.