Il penetration test ha rilevato 40 vulnerabilità: serve davvero un tool dedicato per gestirne la risoluzione?

Rifiutate subito l'offerta della licenza. Non fatevi spaventare dal numero 40: partite solo da critiche e alte. Con una settimana di lavoro dei dev sistemate l'80% del rischio reale. Il resto delle cose a bassa priorità ve le spalmate con calma nei prossimi sprint e amen.

L'anno scorso noi con 20 persone abbiamo ricevuto un report con 38 issue. Il consulente ha provato a venderci un tool simile, abbiamo detto di no. Abbiamo creato una label apposita sul nostro sistema di ticketing: in 45 giorni ne abbiamo chiuse 34 e accettato il rischio sulle 4 basse. Audit superato a zero spese extra.

Il fatto che l'azienda che ha fatto il test vi proponga subito dopo un tool da 6.000 dollari è una classica mossa di upselling. Molto probabilmente sono partner o rivenditori di quel software e prendono una commissione su ogni vendita. Per un'azienda di 14 persone, destinare budget a uno strumento del genere sarebbe un totale spreco di risorse.

Il dettaglio tecnico a cui dovete fare attenzione quando trasferite il tutto sul vostro sistema è questo: non dite semplicemente agli sviluppatori 'risolvi la vulnerabilità X'. Inserite nella descrizione del ticket il punteggio di gravità presente nel report, l'URL o la versione della libreria interessata e i passaggi per riprodurre l'exploit. Altrimenti il programmatore dice di aver risolto, ma magari ha solo cambiato il nome del parametro lasciando la falla aperta.

Nel vostro contratto per il test è prevista una clausola di 're-test' ossia di nuova verifica? Se sì, che tempistiche prevede? Nella maggior parte dei contratti ci sono 30 o 60 giorni per le correzioni con verifica gratuita inclusa. Se ce l'avete, il controllo che farebbe il tool potete farlo fare direttamente al consulente come da contratto.

noi ce la siamo cavata con un semplice foglio di calcolo... nelle colonne abbiamo messo nome della vulnerabilità livello sviluppatore assegnato e stato... insomma una riunione di 15 minuti a settimana per fare il punto ed è stato risolto tutto in due mesi. non serve a niente spendere quei soldi.

Né i clienti né le normative vi impongono l'uso di uno strumento di vulnerability tracking. L'unica cosa che interessa agli auditor è avere traccia del fatto che le falle individuate siano state chiuse tramite un processo documentato e che la risoluzione sia stata verificata a livello tecnico. Lo storico dei vostri ticket attuali soddisfa ampiamente questo requisito.

L'opinione generale è chiarissima: 1) Non comprate il tool da 6.000 dollari, 2) Aprite i task con un'etichetta sicurezza sul vostro attuale sistema di project management, 3) Controllate se da contratto avete diritto al re-test gratuito e usate quello per la verifica. Un software in più non farebbe altro che appesantirvi il lavoro.

Separiamo i concetti, vengono confusi. Gli ambienti di test dimenticati diventano spesso un punto d'accesso più frequente del sistema live.

Naturalmente cambia se la vostra situazione è diversa.

Sì, per quanto riguarda strumenti di remediation la situazione è esattamente così. Un report di scansione automatica e un penetration test non sono la stessa cosa.

Mi farebbe piacere se scrivesse il risultato. Nessun processo migliora senza tracciamento, perché non sai cosa correggere.

Correggetemi se sbaglio.

Lascio un avvertimento. Un report di scansione automatica e un penetration test non sono la stessa cosa.

Inizia con un piccolo test, non impegnarti subito su tutto. Lascio una nota, potrebbe servire.

Raro trovare articoli che spiegano le cose così chiaramente. Gran parte del tempo perso si accumula nelle pratiche in attesa di approvazione.

Riassumo l'argomento, perché sono state date diverse risposte. Le decisioni affrettate diventano decisioni da correggere sei mesi dopo.

Il fatto che tutti facciano una cosa non significa che sia quella giusta. Correggetemi se sbaglio.

Ottimo lavoro. Se non lo rendete scritto fin dall'inizio, poi nascono discussioni.

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

La discussione si è dispersa, la riassumo. Le soluzioni che funzionano su piccola scala crollano quando si cresce, l'ho imparato tardi.

Se ricevete tre risposte diverse su un argomento, la domanda è posta male. Sono curioso di sapere se qualcuno lo fa in modo diverso.

Avrei una domanda, non vorrei deviare dall'argomento, ma... Ogni punto non scritto è un punto che in futuro le due parti ricorderanno diversamente.

Il vero problema non è il numero, ma su cosa si basa quel numero. Se avete domande, scrivete, rispondo per quanto possibile.

A me è successo l'esatto contrario per questo scrivo. Se ricevete tre risposte diverse su un argomento, la domanda è posta male.

Io seguirei questa strada.