Audit ISO 27001: quali processi e registri sono richiesti esattamente per la gestione delle vulnerabilità?

Dividete il perimetro in due: infrastruttura e codice. Per l'infrastruttura lanciate uno scanner di vulnerabilità open source sui vostri blocchi IP una volta al mese ed estraete il report. Per il codice inserite un controllo delle dipendenze nella pipeline CI/CD: se in fase di build rileva librerie con vulnerabilità critiche note, il processo si blocca. Questi log di pipeline sono tra le evidenze tecniche più apprezzate dagli auditor.

Durante l'audit dell'anno scorso abbiamo fissato tempistiche di remediation realistiche: 7 giorni per le critiche, 30 giorni per le alte e 90 giorni per le medie. L'auditor ha individuato 4 vulnerabilità alte non ancora risolte, ma vedendo i relativi 'moduli di accettazione del rischio' debitamente motivati a livello di business ha approvato il controllo senza sollevare alcuna non conformità.

Nel faldone dell'audit non devono assolutamente mancare questi quattro elementi: 1) Policy di gestione vulnerabilità approvata con tabella SLA, 2) Report di sintesi delle scansioni datati degli ultimi tre mesi, 3) Log di lavorazione dei ticket per le vulnerabilità corrette, 4) Documenti firmati di Accettazione del Rischio per le vulnerabilità non risolvibili per motivi tecnici o operativi.

non dite assoluutamente all'auditor "da noi non esce mai mezza vulnerabilità" si insospettiscono subito e vanno ancora più a fondo. la cosa migliore è sempre mostrare una lista di tracciamento trasparente che dimostri che le falle vengono fuori, che le ordinate per gravità e che le risolvete.

edit: ho scritto da telefono, scusate gli errori di battitura.

ma l'auditor ISO accetta come documento ufficiale i report generati con tool di scansione open source gratuiti oppure servono per forza i report con licenza di costosissimi software di cybersecurity enterprise?

All'auditor non frega niente del marchio del tool guarda la metodologia. Fate subito una scansione di tutti i vostri IP esterni con uno strumento gratuito, buttate le vulnerabilità emerse su un foglio di calcolo assegnatele agli sviluppatori responsabili e mettete le date di chiusura. Se mostrate questo ciclo su due mesi, passate l'audit in scioltezza.

Di solito i consulenti cercano di spaventarvi per farvi comprare software di scansione costosissimi. In realtà lo standard non vi chiede la perfezione, ma un meccanismo di controllo ben definito. Se inseriti in un quadro logico, anche un semplice script di automazione scritto da voi e uno storico regolare dei ticket passano l'audit senza problemi.

Ci proverò.

Separiamo i concetti, vengono confusi. Se la verifica in due passaggi è attiva, una password rubata da sola non serve a nulla.

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

In teoria è giusto, in pratica non funziona così. La risposta varia molto in base al settore, non esiste una regola generale.

Buon lavoro.

raro trovare articoli che spiegano le cose così chiaramente.

Sono d'accordo, anzi vorrei sottolinearlo. Se ricevete tre risposte diverse su un argomento, la domanda è posta male.

Buon lavoro.

C'è una trappola qui, non posso non segnalarla. Inizia con un piccolo test, non impegnarti subito su tutto.

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

Tre cose da controllare mentre lo fai. L'errore commesso da gestione delle vulnerabilità è generalmente reversibile ma costoso.

Gli ambienti di test dimenticati diventano spesso un punto d'accesso più frequente del sistema live.

Direi di non avere fretta. Le persone difendono le abitudini, non i processi. La resistenza nasce da lì.

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

salvato.

Stavo pensando la stessa cosa. Quando prendi una decisione, guarda prima quali dati hai a disposizione.

I primi tre mesi vanno bene, i problemi emergono al quarto mese. Io seguirei questa strada.

Preso nota, grazie.