I nostri clienti richiedono un report di penetration test di rete, cosa viene controllato esattamente nella nostra infrastruttura durante questo processo?

Nel modulo di sicurezza inviato dai clienti è stato richiesto un test della rete esterna o anche di quella interna? Spesso le grandi aziende inviano template standard senza personalizzarli. Se gli endpoint API e i servizi web che gestiscono i dati dei clienti risiedono esclusivamente sui server cloud potete escludere la rete interna dell'ufficio dal perimetro per abbattere i costi.

I punti chiave che verranno controllati sono: porte SSH e RDP lasciate aperte, algoritmi di cifratura del server VPN, vulnerabilità nei trasferimenti di zona DNS e versioni obsolete del software web server. Gli analisti non causano disservizi; quando individuano una vulnerabilità, salvano uno screenshot come prova e interrompono l'azione prima di procedere con l'escalation dei privilegi o la lettura dei dati.

L'anno scorso abbiamo affrontato una richiesta analoga: per la nostra infrastruttura da 4 server a Mosca abbiamo pagato 180.000 RUB. I test sono durati 4 giorni lavorativi e la redazione del report ha richiesto 3 giorni. Hanno rilevato 2 vulnerabilità di autorizzazione di livello medio e una libreria non aggiornata. Abbiamo applicato i fix, fatto rifare il test e il cliente ha approvato il documento senza problemi.

Occhio a chi propone offerte tra 50.000 e 70.000 RUB. La maggior parte lancia solo uno scanner di vulnerabilità automatico e vi gira il PDF grezzo spacciandolo per report. I revisori di sicurezza dei clienti corporate se ne accorgono subito e bocciano tutto.

Prima di firmare il contratto, formalizzate assolutamente questi tre punti: 1) esecuzione dei test fuori dall'orario di lavoro e nel rispetto dei piani di backup, 2) notifica immediata in caso di rilevamento di una falla critica, 3) inclusione di un re-test gratuito entro 30 giorni dalla risoluzione dei problemi.

prima di iniziare il test fate assolutamente uno snapshot di backup di tutte le vm... evitate pure di fare grossi aggiornamenti o deploy di codice nei giorni concordati x i test altrimenti i log del traffico si incasinano.

È opportuno richiedere le certificazioni dei professionisti dell'azienda che svolgerà l'audit. Il possesso di attestati riconosciuti a livello internazionale nell'ambito dell'ethical hacking o della sicurezza di rete faciliterà la rapida approvazione del report da parte del comitato di sicurezza delle informazioni del vostro cliente.

Preso nota grazie.

Nel nostro caso è andata così. Le modifiche ai dati di pagamento non vanno mai verificate tramite il canale di provenienza.

Quando prendi una decisione, guarda prima quali dati hai a disposizione. Confermato dall'esperienza.

Argomento molto attuale.

Bisogna fare una distinzione qui. I primi tre mesi vanno bene i problemi emergono al quarto mese.

Naturalmente cambia se la vostra situazione è diversa.

Lascio un avvertimento. Un backup non testato non è un backup.

Cercare di farlo da soli è la strada più costosa. Io seguirei questa strada.

Può approfondire un po'? Gran parte del tempo perso si accumula nelle pratiche in attesa di approvazione.

È tutto, scusate se mi sono dilungato.

Ha ragione. La sicurezza non è assoluta; significa rendere l'attacco non conveniente.

Concordo pienamente. Il tempo che impiegate a rilevare un problema ne determina direttamente il costo.

Avere il backup accessibile sulla stessa rete e con le stesse credenziali lo rende parte del bersaglio.

Mi chiedo anch'io. Se il percorso di notifica è lungo, la notifica non arriva; una notifica mancante significa un evento scoperto tardi.

Il tempo che impiegate a rilevare un problema ne determina direttamente il costo. Lascio una nota, potrebbe servire.

Sono passato da qui, vi racconto. I primi tre mesi vanno bene i problemi emergono al quarto mese.

Confermato dall'esperienza.

Sono una piccola impresa vi parlo dal mio punto di vista. Il fatto che tutti facciano una cosa non significa che sia quella giusta.