Gestione patch: serve una policy e una guida per scriverla

Nel mondo dei software, la precisione è un concetto più che mai astratto. Quando i fornitori ne rilasciano per la prima volta uno, è inevitabile che emergano bug, falle di sicurezza e carenze funzionali. Non serve perdere la pazienza: meglio individuare una saggia policy che faccia sì che il software non debba soffrire di problemi di prestazioni e di sicurezza.

Perché una policy di gestione delle patch?

Sia il software che il firmware devono essere patchati per uno dei tre seguenti motivi:

• Aggiungere nuove caratteristiche e funzionalità
• Correggere il codice che ha inavvertitamente causato problemi di prestazioni e operatività
• Rimediare alle vulnerabilità di sicurezza che potrebbero essere sfruttate attraverso la modifica del codice.

Fattori da considerare nella gestione delle patch

Una policy completa richiede una serie continua di azioni, altrimenti si rischia sorgano numerosi problemi che impattano sull’usabilità dei sistemi IT e OT. Inoltre, la mancanza di patch corrette apre la porta a una serie di problemi di cybersecurity, tra cui il furto e la perdita di dati e gli attacchi denial-of-service ai servizi mission-critical.

La velocità della patch varia a seconda dei sistemi in questione e del potenziale impatto sulle prestazioni, sull’usabilità o sulla sicurezza. Maggiore è tale impatto, più rapida deve essere l’applicazione di una patch.

Cosa non può mancare in una policy di gestione delle patch?

Da una prospettiva di alto livello, una policy di gestione delle patch consiste nelle seguenti procedure.

Identificazione del sistema

Serve un continuo inventario della rete aziendale, per identificare tutti i componenti che possono e devono essere aggiornati. Pertanto, la policy deve prevedere una combinazione di attività manuali e automatizzate utilizzate per individuare sistemi e applicazioni e classificarli in gruppi gestibili.

Raccolta di informazioni sulle patch

L’inventario raccolto dei sistemi IT coinvolti aiuta a determinare quando è necessaria una patch e dove trovarla e scaricarla. Devono essere inclusi sottoprocessi e strumenti, come l’uso di scansioni delle vulnerabilità di sicurezza, verifiche programmate della gestione delle patch, annunci di notifica delle patch da parte dei fornitori e una revisione del bug, della funzionalità o del problema di vulnerabilità per cui la patch è stata progettata.

Priorità delle patch

Sulla base delle informazioni raccolte, le patch del software e del firmware vengono classificate per priorità e programmate in base a fattori di rischio/ricompensa. Le patch che risolvono bug critici o vulnerabilità gravi, per esempio, avranno una priorità più alta e saranno applicate più rapidamente rispetto a quelle per correzioni non critiche o miglioramenti di funzionalità.

Richiesta e approvazione della patch

Questa parte formale del processo di patch prevede che i responsabili dell’implementazione richiedano una finestra di manutenzione per l’aggiornamento del software. La richiesta deve specificare le fasi di distribuzione e rollback.

Test delle patch

Per garantire il successo dell’implementazione, una patch software deve essere testata in un ambiente sandbox o di laboratorio perché se ne possa valutare l’impatto potenziale, una volta messa in produzione. Il test aiuta a garantire che la patch produca i risultati desiderati e non abbia un impatto negativo sui sistemi o sulle applicazioni di produzione.

Distribuzione delle patch

La sezione di implementazione o distribuzione della policy di gestione delle patch illustra l’aggiornamento del software descritto nella procedura di richiesta e approvazione delle patch.

Monitoraggio dei risultati delle patch

Indipendentemente dall’entità della patch, i sistemi e le applicazioni aggiornati con il nuovo codice devono essere monitorati per verificare che la patch abbia risolto un problema specifico o che non abbia avuto effetti collaterali indesiderati non rilevati nella fase di test che potrebbero avere un impatto negativo sulle operazioni aziendali. Se si verificano problemi gravi, vengono eseguite le fasi di rollback descritte nella procedura di richiesta e approvazione della patch per ripristinare le modifiche.

Documentazione dei risultati delle patch

Le patch riuscite e quelle non riuscite devono essere documentate con informazioni sui risultati dell’installazione della patch e con eventuali suggerimenti o avvertenze che potrebbero contribuire a semplificare gli aggiornamenti futuri.

KPI per la gestione delle patch

Può essere utile un elenco di indicatori di performance chiave per misurare il successo complessivo di una policy di gestione delle patch.

Come creare una policy di gestione delle patch

Quando si formula una policy di gestione delle patch, è necessario intraprendere le seguenti azioni:

1. Delineare la procedura per determinare le modalità di identificazione e categorizzazione di software e dispositivi
2. Identificare i responsabili delle patch per le varie categorie di software e dispositivi considerando anche i fornitori di software e sistemi.
3. Documentare il modo in cui verranno utilizzati strumenti, processi e risorse esterne per individuare le vulnerabilità rilevanti e gli aggiornamenti di bug e funzionalità
4. Formulare un modello di richiesta di modifica della patch, insieme a un processo di approvazione e a procedure di rollback
5. Creare delle scadenze del ciclo di vita delle patch per le varie patch di sistema che specifichino la velocità con cui una patch deve essere testata e distribuita in base a fattori aziendali e di cybersecurity
6. Definire un processo per monitorare gli effetti di una patch e gli effetti collaterali negativi che meriterebbero un rollback
7. Formulate un modello di documentazione dei risultati delle patch da utilizzare dopo ogni finestra di manutenzione delle patch.

Best practice per la gestione delle patch

Quando si crea una policy di gestione delle patch per il proprio reparto IT, è importante adottare misure per garantire che nessun processo o attività vada perso. Ecco un elenco di best practice, con indicazioni su ciascuna procedura.

• Valutazione dei rischi e della compliance. Il team di sicurezza dovrebbe condurre regolari valutazioni di vulnerabilità e conformità realizzando un report di valutazione facilmente accessibile dai responsabili IT e dagli integratori di patch. Serve per identificare eventuali difetti e dare priorità agli interventi di patch in base al livello di rischio.
• Strumenti di gestione delle patch. L’utilizzo di software che semplificano il processo di test e distribuzione può far risparmiare tempo. L’IT deve effettuare ogni anno una verifica approfondita degli strumenti di automazione delle patch.
• Repository di patch centralizzato. Per mantenere organizzate e visibili le patch del software e del sistema, create un catalogo di patch centralizzato in cui gestire e archiviare i pacchetti di aggiornamento del software passati e futuri.
• Patch sandbox. Creare un ambiente fisico o virtuale per il test delle patch, dove gli aggiornamenti del software possono essere testati senza impattare sull’ambiente di produzione. Nella maggior parte dei casi, una sandbox virtuale è l’ideale perché è più economica e può essere regolata più facilmente per imitare l’ambiente di produzione.
• Pianificazione delle patch. La creazione di un programma di patch per tutta l’organizzazione creerà visibilità sui sistemi e sulla loro storia di patch passata e presente. La pianificazione indicherà anche la frequenza di revisione e distribuzione delle patch necessaria per ogni applicazione o sistema e quando ciascuno dovrebbe essere aggiornato per ridurre al minimo i tempi di inattività della produzione.
• Priorità delle patch di sistema. A meno che i rapporti sulle vulnerabilità o sulla conformità non indichino diversamente, un documento di prioritizzazione delle patch è il luogo in cui indicare le applicazioni e i sistemi più critici della rete e quali devono avere la priorità sugli altri.
• Monitoraggio post-patch. È importante creare procedure di monitoraggio per ogni applicazione o sistema. Questi documenti descrivono in dettaglio le procedure di monitoraggio e di test utilizzate per garantire che una patch abbia avuto successo e che non si siano verificati effetti collaterali inattesi.
• Procedure di rollback e ripristino delle patch. La velocità è fondamentale quando una patch va male. Lo sviluppo di un piano di rollback per ogni sistema software e hardware aiuta a garantire che le patch possano essere ripristinate o aggirate per ridurre al minimo le interruzioni delle operazioni aziendali.
• Gestione delle modifiche. Dovrebbe esistere una politica di controllo delle modifiche che prescriva un insieme generale di processi per documentare le modifiche apportate agli ambienti di produzione, e le patch sono un tipo importante di modifica da includere in tale politica.
• Documentazione dei risultati delle patch e revisione delle politiche. La documentazione dei risultati dei tentativi di patch, sia quelli riusciti che quelli falliti, può far conoscere le sfide tipiche, le possibili soluzioni e le lezioni apprese. Questa fase è anche l’occasione per prendere in considerazione le modifiche da apportare alla politica generale sulle patch.

Vantaggi di una policy di gestione delle patch ben fatta

Una policy di gestione delle patch può fornire tranquillità agli stakeholder IT, ai responsabili delle decisioni e agli integratori di patch, specificando i processi che, se seguiti correttamente, garantiranno che il software e l’infrastruttura siano privi di bug e vulnerabilità e forniscano un valore ottimale all’azienda. Un processo di patch graduale supporta anche la gestione del rischio, elimina una grande quantità di rischi per la sicurezza e include procedure e risultati ben documentati che consentono una revisione storica e un audit efficaci.