La ISO/IEC 27001 non chiede una scansione delle vulnerabilità: chiede un processo. Il controllo 8.8 dell'Allegato A, gestione delle vulnerabilità tecniche, vuole che l'organizzazione ottenga informazioni tempestive sulle vulnerabilità dei sistemi che usa, valuti la propria esposizione e adotti misure appropriate. In audit questo si traduce in tre evidenze: una procedura scritta con ruoli e tempi, la cronologia delle esecuzioni con le date, e la prova che ciò che è stato trovato è stato deciso e chiuso.
Nella ISO/IEC 27001:2022 i controlli dell'Allegato A sono 93, organizzati in quattro temi: organizzativi, relativi alle persone, fisici e tecnologici. Quello che riguarda direttamente questa pagina è il controllo 8.8, Gestione delle vulnerabilità tecniche.
Il testo chiede all'organizzazione di ottenere in modo tempestivo informazioni sulle vulnerabilità tecniche dei sistemi informativi in uso, di valutare la propria esposizione a tali vulnerabilità e di adottare misure appropriate. Tre verbi: ottenere informazioni, valutare l'esposizione, adottare misure.
Quello che la norma non dice è altrettanto importante:
Attorno all'8.8 ruotano altri controlli che gli auditor guardano insieme: il 5.7 sulla threat intelligence, perché per sapere cosa ti riguarda devi ricevere informazioni dall'esterno; l'8.9 sulla gestione delle configurazioni, perché una configurazione che cambia da sola vanifica la correzione; l'8.16 sulle attività di monitoraggio; e il 5.19 e seguenti sulla sicurezza nei rapporti con i fornitori, perché la vulnerabilità di un fornitore è esposizione tua.
Un audit sul controllo 8.8 si svolge quasi sempre allo stesso modo, e le domande sono prevedibili.
L'inversione mentale utile è questa: l'auditor non verifica che tu sia sicuro, verifica che tu abbia un processo che funziona e che tu possa dimostrarlo. Un elenco pieno di problemi gestiti vale più di un elenco vuoto senza storia.
La norma lascia la scelta a te, ma la scelta va motivata e poi rispettata. Quello che si difende bene in audit:
| Ambito | Frequenza difendibile | Perché |
|---|---|---|
| Servizi raggiungibili da internet | Continua o almeno settimanale | È il perimetro che cambia più in fretta e quello che un attaccante controlla ogni giorno |
| Rete interna | Mensile, più il monitoraggio continuo del traffico | Cambia più lentamente, ma è dove un'intrusione si propaga |
| Applicazioni sviluppate internamente | A ogni rilascio rilevante | Il codice nuovo introduce difetti nuovi |
| Immagini e container | A ogni build e poi periodicamente | Le vulnerabilità compaiono nei livelli di base dopo la pubblicazione |
| Verifica approfondita condotta da persone | Annuale o dopo un cambiamento architetturale | Copre le falle logiche che nessuna verifica automatica trova |
La regola pratica per non sbagliare: non scrivere nella procedura una frequenza più alta di quella che riuscirai a sostenere. La non conformità nasce dallo scarto fra documento e registri, non dalla frequenza in sé. Una procedura che dichiara la verifica mensile ed esegue mensilmente passa; una che dichiara la verifica settimanale ed esegue quando qualcuno se ne ricorda non passa.
Una verifica continua risolve il problema alla radice, perché la cronologia si forma da sola e il registro non dipende dal fatto che una persona si ricordi di eseguirla.
L'auditor chiede quasi sempre di vedere il criterio con cui si decide cosa correggere prima. Un impianto semplice e difendibile:
Poi i tempi. Un esempio che regge in audit per una PMI, da adattare al proprio rischio: critiche entro 7 giorni, alte entro 30, medie entro 90, basse al prossimo ciclo di manutenzione pianificata. Se non riesci a rispettarli, cambia i numeri nella procedura: sono tuoi.
Serve infine un registro delle eccezioni. Quando una vulnerabilità non può essere corretta, per esempio perché il fornitore di un macchinario non rilascia aggiornamenti, si registra la decisione, la misura compensativa adottata, chi ha approvato e la data di riesame. Un'eccezione documentata e riesaminata è conforme; la stessa situazione senza documento è una non conformità.
Il controllo 8.8 compare nella Dichiarazione di applicabilità, il documento che elenca i 93 controlli e per ciascuno dice se è applicabile, come è implementato e perché. La riga dell'8.8 deve rimandare alla procedura reale e non contenere promesse più ambiziose di quello che succede davvero.
Dal punto di vista del sistema di gestione, i dati della gestione delle vulnerabilità alimentano tre punti della parte normativa: il monitoraggio e la misurazione delle prestazioni del punto 9.1, per il quale servono indicatori, per esempio il tempo medio di correzione per classe di gravità o la percentuale di asset coperti dalle verifiche; l'audit interno del punto 9.2; e il riesame della direzione del punto 9.3, dove l'andamento va presentato ai vertici. Le non conformità e le azioni correttive del punto 10.2 chiudono il cerchio.
Chi sta preparando la certificazione o la mantiene trova nella parte di consulenza di Fidem sulla certificazione ISO 27001 il lavoro sul sistema di gestione; questa pagina riguarda l'evidenza tecnica che il controllo 8.8 richiede.
Le tre cornici chiedono in larga parte la stessa cosa con parole diverse, e questo è un vantaggio se si costruisce l'evidenza una volta sola.
| Cornice | Riferimento | Cosa chiede sulla gestione delle vulnerabilità |
|---|---|---|
| ISO/IEC 27001 | Allegato A, controllo 8.8 | Informazioni tempestive, valutazione dell'esposizione, misure appropriate |
| NIS2 | Articolo 21 | Gestione e divulgazione delle vulnerabilità fra le misure minime, più valutazione dell'efficacia |
| GDPR | Articolo 32, comma 1, lettera d | Procedura per testare, verificare e valutare regolarmente l'efficacia delle misure |
Una cronologia continua di verifiche, con priorità e correzioni datate, soddisfa tutte e tre. Il lavoro aggiuntivo è solo di presentazione: lo stesso registro si legge come evidenza del controllo 8.8 per l'auditor, come misura dell'articolo 21 per la NIS2 e come prova della lettera d per le misure dell'articolo 32 GDPR.
Ricorrono sempre gli stessi, e nessuno richiede tecnologia per essere evitato.
La parte tecnica del controllo 8.8 si può coprire senza costruire nulla in casa.
Restano lavoro dell'organizzazione la procedura, i criteri di priorità, i tempi di intervento, le eccezioni e il riesame: sono decisioni, e nessuno strumento le prende al posto di chi risponde del sistema di gestione.
Obbliga ad avere un processo di gestione delle vulnerabilità tecniche, che è il controllo 8.8 dell'Allegato A: ottenere informazioni tempestive sulle vulnerabilità dei sistemi in uso, valutare l'esposizione e adottare misure appropriate. Non nomina strumenti né tecniche. In pratica, per i sistemi raggiungibili da internet, la verifica ripetuta delle vulnerabilità è il modo ordinario di soddisfarlo, ed è quello che gli auditor si aspettano di vedere insieme alla procedura e ai registri.
La norma non fissa una frequenza: la scegli tu in base al rischio, la scrivi nella procedura e poi la rispetti. Frequenze che si difendono bene in audit sono la verifica continua o settimanale per i servizi esposti su internet, mensile per la rete interna, a ogni rilascio per le applicazioni sviluppate internamente e annuale per la verifica approfondita condotta da persone. L'errore da evitare è dichiarare una frequenza più alta di quella che riuscirai a sostenere: il rilievo nasce dallo scarto fra documento e registri.
Tre. La procedura scritta, con ruoli, frequenza, criteri di classificazione, tempi di intervento per classe di gravità e regole per le eccezioni. La cronologia delle esecuzioni con le date, per l'intero periodo coperto dall'audit. E la chiusura del ciclo su un campione: quando una vulnerabilità è stata trovata, come è stata classificata, cosa è stato deciso, quando è stata corretta e come è stato verificato. Una vulnerabilità ancora aperta non è una non conformità se ha una data, una decisione e una motivazione.
No, se sono gestite. L'auditor non verifica l'assenza di vulnerabilità, che sarebbe una pretesa irrealistica, ma l'esistenza di un processo che le individua, le classifica, le porta a decisione e le chiude nei tempi che l'organizzazione stessa si è data. Un registro con molte voci chiuse nei termini è un'evidenza migliore di un registro vuoto senza storia. Fanno scattare un rilievo le vulnerabilità senza data, senza esito o corrette fuori dai tempi dichiarati senza una motivazione.
Non è richiesto esplicitamente. Il controllo 8.8 parla di ottenere informazioni sulle vulnerabilità e valutare l'esposizione, e non distingue fra verifica automatica e test condotto da persone. Molte organizzazioni includono comunque un penetration test annuale nel proprio processo, perché copre le falle logiche delle applicazioni che nessuna verifica automatica individua, e perché è la risposta a una domanda ricorrente di clienti e assicuratori. Se lo inserisci nella procedura, poi devi eseguirlo con la cadenza dichiarata.
Sì, indirettamente e in modo stringente. La tua esposizione comprende i sistemi di terze parti che trattano i tuoi dati o che sono connessi ai tuoi. I controlli sulla sicurezza nei rapporti con i fornitori lavorano insieme all'8.8: devi sapere quali fornitori sono nel perimetro, cosa hanno dichiarato sulle proprie misure e come lo verifichi nel tempo. Escludere i sistemi gestiti da terzi dalla gestione delle vulnerabilità senza motivarlo è uno dei rilievi più comuni.
Bastano pochi indicatori, purché siano misurati davvero e presentati al riesame della direzione. I più usati sono il tempo medio di correzione per classe di gravità, confrontato con i tempi dichiarati nella procedura; la percentuale di asset coperti dalle verifiche rispetto all'inventario; il numero di vulnerabilità aperte oltre i termini; e l'andamento nel tempo del totale. Sono anche i numeri che rendono visibile un miglioramento, che è ciò che il punto 10 chiede.
No, ma riduce molto il lavoro. Le tre cornici chiedono cose largamente sovrapposte con parole diverse, e una cronologia continua di verifiche con priorità e correzioni datate serve come evidenza per tutte e tre. Restano differenze sostanziali: il GDPR ha obblighi propri verso gli interessati e termini di notifica specifici, la NIS2 ha i propri tempi di segnalazione e responsabilizza gli organi di amministrazione, e il perimetro di una certificazione può essere più stretto dei trattamenti o dei servizi regolati.
Ogni ciclo di verifica lascia un esito datato e confrontabile con il precedente, senza che nessuno debba ricordarsi di eseguirlo. Guarda il vulnerability assessment continuo oppure parla con noi del perimetro da coprire.