Il penetration test ha trovato 40 vulnerabilità: come organizzare la remediation senza impazzire?

Non fatevi ingannare ciecamente dai punteggi CVSS. Ad esempio, una vulnerabilità con punteggio alto su un endpoint API interno ha un rischio reale basso se si trova dietro autenticazione. Al contrario, un information disclosure di livello medio su un parametro esposto pubblicamente su internet può crearvi problemi molto prima. Considerate sempre il contesto di reale sfruttabilità.

L'anno scorso ci siamo trovati nella stessa situazione con un report di 38 vulnerabilità. Il team all'inizio pensava che non avrebbe più sviluppato nuove feature per settimane. Approfondendo, abbiamo scoperto che 14 di quei 38 problemi si risolvevano semplicemente aggiornando due vecchie dipendenze di pacchetti. Quegli update hanno spazzato via un terzo del carico di lavoro in appena 3 ore.

Chiedete subito alla società che ha fatto il test quali siano le tempistiche contrattuali per il re-test. Spesso i contratti prevedono una finestra di verifica gratuita di 30 o 45 giorni per le correzioni. Se non chiudete le critiche e le alte prima di quella scadenza per farvi rilasciare il report di approvazione vi toccherà pagare un supplemento.

Regola di capacità dello sprint per non bloccare il flusso di lavoro: 1) Dedicate il 30% del prossimo sprint esclusivamente alle vulnerabilità critiche. 2) Con il restante 70% di capacità continuate con i task principali concordati con i clienti. 3) Spostate i bug a bassa priorità nel backlog del debito tecnico e smaltiteli nei cicli successivi.

Dopo il nostro primo penetration test arrivò un report di 50 pagine: i nostri programmatori la presero sul personale mettendosi sulla difensiva, con l'idea che gli esperti di sicurezza avessero esagerato. La cosa più critica qui è preservare il morale del team. Il report non va presentato agli sviluppatori come una pagella, ma come una normale lista di debito tecnico individuata da un occhio esterno. Altrimenti si creano attriti del tutto inutili tra dev e security.

Di quegli 11 rilievi a basso impatto, almeno 5 sono quasi sicuramente cose standard tipo supporto TLS, flag dei cookie o versione del server esposta. Roba che a un attaccante non fa né caldo né freddo; non perdete tempo con queste e concentratevi subito sulle falle di gestione sessioni e autorizzazioni.

Il vostro cliente enterprise vi ha fissato una tempistica formale a contratto (SLA) per la risoluzione? Se non c'è una clausola vincolante, tipo 14 giorni per i critici e 30 per gli alti, potete gestire la roadmap con molta più flessibilità in base ai vostri ritmi di sviluppo.

Il piano in sintesi è chiaro: fate subito gli aggiornamenti delle librerie per sfoltire la lista, fate rientrare critici e alti nella finestra di re-test dell'azienda e inviate al cliente una roadmap di remediation di una sola pagina con date precise.

Breve riassunto per i nuovi arrivati: Non fidatevi di una sola misura di sicurezza; procedete per livelli.

Naturalmente cambia se la vostra situazione è diversa.

L'anno scorso abbiamo vissuto quasi la stessa cosa. Inizia con un piccolo test, non impegnarti subito su tutto.

Non fidatevi di una sola misura di sicurezza; procedete per livelli.

Esatto, e non è nemmeno così noto. Chiunque abbia fretta su processo di remediation si blocca nello stesso punto.

Sono passato da qui, vi racconto. Se permessi e ambito non sono scritti, quel test non deve iniziare.

Se scrivete qui il risultato, sarà utile anche ad altri.

Racconto la mia esperienza. La maggior parte degli incidenti non inizia da una vulnerabilità, ma da una password trapelata.

Questo consiglio non va bene per tutti, secondo me. Prendere appunti per due settimane dà risultati migliori rispetto a una stima di sei mesi.

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

non lo sapevo.

Mi farebbe piacere se scrivesse il risultato.

Mi chiedo anch'io.

riassumo l'argomento, perché sono state date diverse risposte. da noi la cosa che faceva perdere più tempo era non sapere chi decidesse.

le modifiche ai dati di pagamento non vanno mai verificate tramite il caanle di provenienza. questa è la mia opinione, non la scrivo come verità assoluta.