Esistono motivi concreti e pragmatici per considerare convalida e verifica due passaggi fondamentali della procedura di gestione delle patch di sicurezza. La prima è il processo che permette di esaminare le nuove patch disponibili per identificare quelle applicabili all’ambiente IT dell’organizzazione. Ciò significa poter poi testare le patch scelte per determinare se possono causare problemi. La verifica delle patch software richiede invece la creazione di un ambiente di test che riproduca un segmento rappresentativo dell’infrastruttura complessiva.
Verifica della distribuzione delle patch
La verifica non è però terminata. Tale processo continua con il controllo dei file correlati, delle versioni binarie e delle impostazioni del registro di sistema per confermare che una patch ha avuto effetto. Se lo strumento di gestione delle patch utilizzato non è in grado di farlo, il processo deve essere eseguito manualmente. È possibile anche utilizzare uno scanner apposito per verificare che le vulnerabilità che la patch intende mitigare non siano più presenti o sfruttabili.
Per aumentare l’efficacia della verifica, lo strumento di gestione delle patch utilizzato per distribuire l’aggiornamento di sicurezza deve essere in grado di monitorare i sistemi patchati dopo la distribuzione. Lo stesso deve anche verificare che la patch di sicurezza sia stata installata correttamente e identificare eventuali problemi successivi alla distribuzione eseguendo degli smoke test. Non è finita: deve anche tenere traccia dei sistemi che sono stati patchati.
È importante che lo strumento sia davvero in grado di fare tutto ciò, altrimenti diventa necessario creare un metodo manuale o una sotto-procedura per completare le diverse attività di verifica.
Verifica dello stato delle patch
La procedura di controllo delle modifiche dell’organizzazione, che si tratti di uno strumento, di un ticket o di un modulo, deve essere aggiornata al completamento di ogni fase e deve essere generato un report per registrare lo stato di ogni patch.
Questi documenti possono essere generati anche dal sistema di gestione delle modifiche utilizzato. I report vengono distribuiti al personale interessato, tra cui il team di gestione delle patch e il personale IT coinvolto nella fase di revisione e devono contenere le seguenti informazioni:
- Numero di sistemi patchati con successo.
- Numero di sistemi che non sono riusciti a eseguire la patch o che non hanno avuto successo.
- Riepilogo dei motivi dei guasti e dei passi successivi.
- Riepilogo dei rapporti sulle richieste di riavvio.
- Numero di sistemi che sono stati omessi dal processo, che di solito viene fornito nel rapporto di eccezione allegato.
- Riepilogo dei motivi per cui questi sistemi sono stati omessi dal processo e di eventuali soluzioni temporanee adottate.
- Riepilogo dell’efficacia della segnalazione.
È necessario sviluppare KPI per la procedura di gestione delle patch che consentano all’organizzazione di misurare l’efficacia e l’efficienza delle iniziative di gestione.
I responsabili della gestione delle patch devono analizzare regolarmente i report e utilizzare i KPI e altre informazioni per rispondere alle seguenti domande sui processi di correzione e risposta:
- Quanto è efficace il processo?
- Se il tasso di fallimento è elevato, quali sono i fattori che vi contribuiscono?
- Dove si possono apportare miglioramenti alla procedura di gestione delle patch?
Queste informazioni stabiliscono le prestazioni di base della procedura di gestione delle patch, che possono poi essere utilizzate per esporre l’accuratezza e l’efficacia contro gli attacchi. Il completamento di quest’ultima fase della procedura assicura che l’iniziativa di gestione delle patch di un’organizzazione sia proattiva.
