Il patching in un piccolo ambiente

Nei reparti IT delle grandi aziende, il patching dei sistemi è un processo complicato che coinvolge un gran numero di sistemi di test che rispecchiano i sistemi di produzione, in modo che ogni nuova patch in arrivo dai fornitori di sistemi operativi e software possa essere testata in un ambiente reale per verificare come interagisce con le combinazioni di hardware e software disponibili nell’organizzazione. In un mondo ideale, ogni reparto disporrebbe di un processo di patching gestito che rispondesse immediatamente alle patch appena pubblicate, le testasse istantaneamente e le applicasse non appena la patch fosse ritenuta sicura e applicabile. Ma il mondo non è ideale e nella vita reale dobbiamo arrangiarci con risorse limitate: fisiche, temporali e finanziarie.

Le patch vengono generalmente rilasciate per alcuni motivi chiave: sicurezza, stabilità, prestazioni e, occasionalmente, per fornire nuove funzionalità. Fatta eccezione per l’aggiunta di nuove funzionalità, che normalmente viene gestita attraverso un diverso processo di rilascio, le patch rappresentano la correzione di un problema noto. Non si tratta di uno scenario del tipo “se non è rotto, non aggiustarlo”, bensì di uno scenario del tipo “è rotto e non si è ancora guastato del tutto”, che richiede attenzione – prima è, meglio è. Adottare un atteggiamento del tipo “aspettiamo e vediamo” nei confronti delle patch è imprudente, poiché l’esistenza di una nuova patch significa che gli hacker malintenzionati dispongono di una “correzione” da analizzare e, anche se in precedenza un exploit non esisteva, esisterà entro brevissimo tempo. Il rilascio della patch stessa può rappresentare l’innesco della necessità immediata di tale patch.

Questo ecosistema delle patch crea la necessità di una mentalità improntata al “patching rapido”. Le patch non dovrebbero mai restare inattive, devono essere applicate spesso non appena vengono rilasciate e testate. Attendere prima di applicare le patch può significare operare con bug di sicurezza critici o mantenere i sistemi inutilmente poco affidabili.

I piccoli reparti IT raramente, se non mai, dispongono di ambienti di test, che si tratti di server, apparecchiature di rete o persino desktop. Non è l’ideale ma, realisticamente, anche qualora tali ambienti fossero disponibili, pochi piccoli reparti dispongono delle risorse umane IT in eccesso necessarie per eseguire quei test in modo tempestivo.

La situazione non è così desolante come sembra. I test eseguiti per la maggior parte delle patch sono ridondanti rispetto al patching già testato dal fornitore. I fornitori non possono certo testare ogni interazione hardware e software che potrebbe mai verificarsi con i loro prodotti, ma generalmente testano un’ampia gamma di permutazioni ed esaminano le aree in cui le interazioni sono più probabili. È raro che un grande fornitore comprometta il proprio software con patch difettose. Sì, accade, e disporre di buoni backup e piani di rollback è importante, ma nelle operazioni quotidiane il patching è un processo relativamente sicuro che è di gran lunga più importante eseguire prontamente piuttosto che attendere opportunità che potrebbero verificarsi o meno.

Come qualsiasi modifica di sistema, le patch vengono applicate al meglio in dosi frequenti e ridotte. Se le patch vengono applicate prontamente, allora normalmente è necessario applicare contemporaneamente solo una o poche patch. Per i sistemi operativi potreste comunque dover gestire più patch alla volta, soprattutto se applicate le patch solo settimanalmente, ma raramente dovrete applicare patch a decine o centinaia di file contemporaneamente se procedete in questo modo. Operando così è enormemente più semplice valutare gli effetti negativi delle patch ed eseguire il rollback se un processo di patching va male.

Lo scenario peggiore per una piccola azienda priva di un adeguato flusso di lavoro per il test delle patch è attendere prima di applicarle. Attendere significa che i sistemi restano privi delle cure necessarie per lunghi periodi di tempo e, quando le patch vengono finalmente applicate, ciò avviene spesso in processi di patching massivi e ingenti. Applicare molte patch contemporaneamente aumenta le probabilità che qualcosa vada storto e, quando ciò accade, individuare quale patch (o quali patch) sia responsabile e tracciare un percorso di risoluzione può rivelarsi molto più difficile.

Il patching ritardato è un processo che offre poco o nessun vantaggio né all’IT né all’azienda, ma comporta un rischio considerevole per la sicurezza, la stabilità e le prestazioni. Le migliori pratiche per il patching in un piccolo ambiente consistono nel consentire ai sistemi di applicare le patch in autonomia il più rapidamente possibile, oppure nel pianificare un regolare processo di patching, magari settimanale, in un momento in cui l’azienda sia maggiormente preparata all’eventualità che il patching fallisca e alla gestione della relativa risoluzione. Sia che scegliate di applicare le patch automaticamente sia che scegliate semplicemente di farlo con regolarità attraverso un processo manuale, applicate le patch spesso e prontamente per ottenere i migliori risultati.