Prima che una patch venga distribuita sulla rete, è importante testarla in un ambiente non di produzione per assicurarsi un rollout prevedibile. Sarebbe una delle prime regole da seguire. Spesso invece accade che si installino patch di software e firmware per correggere bug, rimuovere vulnerabilità e aggiungere nuove funzionalità senza effettuare un test preliminare. Si corre così il rischio di rendere i sistemi inefficienti o instabili.
Perché è importante testare le patch del software?
Una premessa è necessaria: nessun software sarà mai completamente privo di bug, anche quando si seguono le best practice di sviluppo pedissequamente. Questa imperfezione persistente spiega l’esistenza del vendor patching, un aggiornamento successivo al rilascio che corregge i bug appena scoperti nel software. Vale sia per sistemi operativi, che per firmware di apparecchiature di rete, applicazioni o app mobili.
Nonostante i fornitori di software testino rigorosamente le patch prima di rilasciarle, è chiaramente per loro impossibile riuscire a valutare le infinite configurazioni e i potenziali scenari in cui ciascuna verrà distribuita.
Spetta alle singole organizzazioni che ne fanno il deployment, quindi, controllare che non si verifichino problemi quando una patch viene installata. Si può rischiare il malfunzionamento immediato di un dispositivo o di un’applicazione, con un impatto anche enorme. Non accade sempre così, però: alcuni problemi si manifestano solo quando una particolare combinazione di eventi innesca un errore.
Per evitare potenziali interruzioni e disservizi, le patch devono essere testate a fondo prima di essere installate sui sistemi di produzione. Questa fase può essere considerata la più critica del processo di gestione delle patch aziendali. È però cruciale per minimizzare il rischio che quelle non testate destabilizzino l’ambiente IT.
Come si testa una patch software?
L’obiettivo del patch testing è comprendere se una patch possa causare problemi all’interno della combinazione specifica di hardware, software e impostazioni di configurazione che un’organizzazione presenta di volta in volta. Il modo migliore per farlo è creare un ambiente di test che rispecchi il più possibile quello di produzione. Può risultare un passaggio costoso se comporta la manutenzione di ambienti duplicati del mondo reale, quando diventa impossibile, si utilizza un campione rappresentativo di risorse.
Si può installare una patch solo su un gruppo di prova di workstation di dipendenti, per esempio, così se l’installazione fallisce o causa problemi, pochi ne risentono. Un’alternativa è creare un ambiente di test virtuale, ma l’ideale è eseguire tutti i test completi, ogni volta che è necessario e a un costo accettabile.
È previsto anche il confronto delle performance dell’applicazione prima e dopo l’implementazione della patch, verificando anche che non ci siano impatti sulle altre in esecuzione nell’ambiente di destinazione.
Per completezza vengono anche simulati i cicli di utilizzo e i picchi di lavoro stagionali. Alcuni problemi, infatti, emergono solo al di sopra di una certa soglia o quando vengono eseguite determinate funzioni, come per esempio le buste paga mensili. Automatizzare questo tipo di test può ridurre i problemi legati agli aggiornamenti di sicurezza.
È importante verificare che una patch risolva effettivamente il problema identificato, richiedendo il riavvio del sistema. Deve anche poter sempre essere rimossa o annullata senza causare criticità. Ci saranno poi dei registri di gestione delle modifiche con tutti i dettagli sulle singole patch, sui risultati dei test e sul rollout ordinatamente documentati.
Best practice per il security patching test
Il patching è un processo fondamentale della gestione delle vulnerabilità; quindi, è essenziale che sia svolto correttamente. Alcune best practice di software patching test rivelano conflitti con le configurazioni esistenti che si verificano unicamente per i sistemi su cui verrà installata. È l’unico modo per evitare di interrompere le operazioni aziendali.
Individuare le maggiori criticità
L’identificazione di problemi di sicurezza e aggiornamenti rilevanti per un particolare ambiente inizia con un solido inventario di risorse e software. In ambienti complessi, il modo migliore per realizzarlo è utilizzare uno strumento che automatizzi la gestione delle patch.
Assegnato a tutti gli asset un livello di criticità, si può valutare la loro importanza nei processi aziendali, i periodi di inattività ottimali e i livelli di rischio di vulnerabilità. Dando priorità alle patch e testando, si possono programmare e distribuire quelle critiche prima di quelle meno essenziali.
La gestione delle modifiche è fondamentale. È necessario eseguire e tenere traccia di ogni aggiornamento e di ogni fase del patching. La policy dedicata, al contempo, deve ben descrivere come identificare e distribuire le patch e indicare i responsabili di ogni fase del workflow.
I provider rilasciano regolarmente patch ed è importante conoscere le più critiche. Uno strumento utile per valutare la gravità delle vulnerabilità di sicurezza di un’ampia gamma di prodotti software è il Common Vulnerability Scoring System (CVSS). Essendo neutrale rispetto alle applicazioni e ai fornitori, il CVSS supporta il team di sicurezza nella identificazione dell’impatto delle vulnerabilità sui loro sistemi e nello stabilire con che priorità correggerle.
Per le applicazioni sviluppate internamente, meglio puntare su uno strumento di analisi della composizione del software che mappa tutti i componenti open source e di terze parti. È la soluzione che permette di tracciare sia gli aggiornamenti dei provider, sia gli annunci di patch collegati.
Una volta fatto il download di una patch, ne vanno verificate sempre l’origine e l’integrità attraverso una firma digitale fornita ad hoc. A meno di minacce imminenti, è un’ottima idea consultare i forum dedicati alla specifica patch per eventuali segnalazioni di problemi a seguito della sua installazione. Spesso, quindi, non essere i primi è un grande vantaggio, quando si seguono le best practice per il security patch testing.
Replicare ambienti attraverso la virtualizzazione
La virtualizzazione è un elemento fondamentale all’interno di una strategia di software patch testing perché consente di replicare ambienti di produzione su un unico computer, anche con lo stesso hardware. L’esecuzione virtuale di più sistemi operativi consente di risparmiare tempo, spazio e denaro.
Con la virtualizzazione diventa possibile anche verificare che, applicando delle patch, non si verifichino imprevisti. Con l’aumento della complessità delle infrastrutture, oggi è difficile esporre una patch a numerosi scenari. I servizi cloud, come Microsoft Azure e AWS, rappresentano quindi una via a basso costo per creare un ambiente dedicato al patch testing identico al sistema di produzione. I servizi online che replicano tutto o parte dell’ambiente di produzione sono un’altra opzione.
Il software patch testing garantisce che i dispositivi si riavviino correttamente, ma non solo. È necessario verificare che il deployment della patch sia stato eseguito con successo ed effettuare smoke test per avere conferma che tutte le funzioni principali del software non presentino problemi. Potrebbero infatti emergere imprevisti nell’ambiente di test, come i seguenti:
- fallimento del programma
- permessi modificati
- nuovi servizi disabilitati o abilitati
- codice corrotto o rovinato
- errori generici interni all’applicazione
Se il test non va a buon fine, prima di andare avanti va identificata la causa principale del problema.
L’avvio della produzione, se condotto in più fasi, è un’altra parte importante del testing. Va applicato il rollout iniziale ai sistemi meno critici e, se funzionano come previsto, si può proseguire con l’aggiornamento di tutto il resto dei sistemi. Il testing è terminato quando il rollout è stato completato senza che siano segnalati problemi entro una settimana. Se un sistema legacy non può essere patchato, è fondamentale elaborare una strategia alternativa per mitigare le minacce che ne derivano.
Attenzione al riavvio
Almeno il 90% delle implementazioni di patch richiede il riavvio del sistema. Meglio pianificare quindi una finestra di manutenzione per applicare le patch al sistema di produzione, evitando che un riavvio imprevisto interferisca con le operazioni aziendali o causi altri problemi. Esistono una serie di strategie di patching, tra cui l’esecuzione mensile regolare oppure nel fine settimana, se si preferisce applicare le patch a tutti i sistemi in una sola volta. Si possono però anche distribuire piccoli aggiornamenti nel corso del mese. L’obiettivo delle best practice per il software patch testing è sempre evitare che i problemi legati alle patch si manifestino tutti insieme.
Anche con un programma di test approfondito, meglio disporre di un piano di emergenza e di rollback nel caso in cui qualcosa vada storto. È un accorgimento per esser certi che i sistemi possano essere ripristinati allo stato precedente alla patch. Vanno eseguiti un backup o un’immagine istantanea di ogni sistema prima di iniziare la distribuzione delle patch, anche con il supporto di un provider esterno. Esistono infatti aziende che forniscono servizi di patch, come il patch testing, per le applicazioni più utilizzate. Oppure la preparazione degli script per la distribuzione delle patch ai sistemi di produzione. Da evitare, però, l’uso di strumenti di aggiornamento automatico sui sistemi mission-critical, perché si ha un controllo molto minore nel momento in cui le patch vengono applicate.
Utili considerazioni sui test
Mantenere un ambiente IT di grandi dimensioni completamente patchato è un lavoro che richiede molto tempo. Se non gestito correttamente, può comportare inutili tempi di inattività o vulnerabilità. Per semplificare i processi di patch testing e di rollout, si può puntare sul consolidamento e la standardizzazione del software utilizzato in tutta l’organizzazione. È il modo migliore per ridurre notevolmente il numero di applicazioni da monitorare, testare e patchare.
Consapevoli che non tutti gli aggiornamenti delle patch filano lisci, è importante prendere nota di cosa accade e mettersi nell’ottica di imparare dai propri errori per non ripeterli.
Può capitare che un dispositivo o un’applicazione non possano essere aggiornati con una patch di sicurezza importante. In queste situazioni, è fondamentale testare metodi alternativi per mitigare la vulnerabilità e distribuirli il prima possibile.
Le patch svolgono infatti un ruolo fondamentale nel garantire la sicurezza dei sistemi. Diversi audit, standard e normative richiedono report sull’implementazione delle patch. Quando si scopre che i sistemi di un’organizzazione e i dati dei clienti sono stati esposti a rischi a causa di software non patchato, le multe e i costi di violazione possono essere estremamente elevati.
