Sempre più spesso negli ambienti dell’Information Technology si sente parlare di patching, alle volte quasi alla stregua o in sostituzione di ciò che gli amministratori di sistema più veterani conoscono come “aggiornamento dei sistemi”.
Tuttavia, prima di addentrarci nel come impostare una politica di patching in azienda al passo con le moderne sfide digitali, è opportuno dare un po’ più di rigore al termine “patching”: espressione anglosassone che letteralmente significa “mettere una pezza” o meglio “rinforzare un punto debole”.
Focalizzandosi su questa semplice definizione emerge prepotente la totale diversità della natura del patching rispetto a quello che la stragrande maggioranza degli amministratori di sistema fa, ed è abituato a fare: ovvero gestire e mantenere politiche di aggiornamento dei sistemi.
Sì, è certamente vero che i due concetti hanno sovrapposizioni, tant’è che molte volte uno dei principali mantra che si sentono ripetere è “I tuoi sistemi non sono sicuri, li devi aggiornare.”, ma quando si entra nel merito del come gestire e del quando attuare queste modifiche, le differenze ci sono e risiedono proprio nelle fondamenta di questi termini.
Indice degli argomenti
Patching e aggiornamenti di sistema: le differenze
Pensando alle motivazioni per cui si effettuano gli aggiornamenti dei sistemi, la sicurezza non è affatto al primo posto.
In tantissimi casi aggiorniamo le nostre infrastrutture e i nostri applicativi per avere più funzionalità, per risolvere quei problemi di compatibilità che tanto ci hanno infastidito, oppure per integrare i sistemi aziendali con nuove tecnologie e piattaforme che ci faranno lavorare meglio e più efficientemente. E poi anche per questioni di sicurezza, che male non fa.
Questa pratica è ormai consolidata, tant’è che molte aziende adottano politiche di aggiornamento dei sistemi: alle volte in misura periodica o alla peggio relegano l’attività a quando il personale ha sufficiente tempo, con priorità tipicamente timide, specie quando i sistemi sono moderatamente complessi e soprattutto quando già funzionano bene.
Molto più comune di quanto si pensi, specie negli ambienti industriali dove i sistemi informatici governano processi fisici ed operazioni su macchinari.
Da qui la prima considerazione. Come ci sentiremmo a girare per strada con le tasche dei pantaloni bucate che lasciano cadere a terra tutto ciò che vi riponete e con la serratura dell’auto rotta? Tanto, il vestito lo si cambierà il prossimo gennaio e l’auto la si porterà a riparare quando e se si romperà il cambio.
Quando si parla di patching l’approccio è ben diverso. Le attività sono guidate da altre necessità. Tornando allo scenario di poco fa, la decisione di fare qualcosa è guidata ad esempio dal desiderio di smettere di rompere o smarrire tutti gli smartphone che puntualmente infiliamo nelle tasche dei nostri pantaloni bucati, quelli che cambieremo il prossimo gennaio.
Qui, una politica di patching potrebbe portare a decidere di rattoppare subito i pantaloni, di non mettere più lo smartphone in tasca, o addirittura di acquistarne subito un nuovo paio. Il focus è quindi nell’accorgersi di avere una problema e nel gestirlo di conseguenza.
Patching: cosa dicono le normative
Benché il GDPR non reciti nulla di esplicito riguardo alle politiche di patching, l’art. 32 sulla “Sicurezza del trattamento” offre sponde più che fertili su questo tema.
Si parla infatti dell’adesione a codici di condotta e della valutazione di un adeguato livello di sicurezza, lasciando ampi margini interpretativi.
Parlando di valutazione del livello sicurezza, fare riferimento alla norma ISO-IEC 27001:2103, standard de facto per la realizzazione di controlli di sicurezza, non è affatto un errore.
In particolare, si può trovare un interessante spunto nel Controllo 12.6, che entra nel merito della gestione delle vulnerabilità tecniche specificando che le falle di sicurezza e le vulnerabilità nei sistemi devono essere valutate e prese in carico dall’organizzazione.
Oppure, riferendosi invece al “Framework Nazionale per la Cyber Security e la Data Protection”, adottato dall’Italia per la definizione delle linee guida per gli Operatori di Servizi Essenziali sottoposti alla Direttiva NIS, si possono trovare indicazioni proprio in questo senso nella funzione di risk assessment, dove non solo viene richiesta la documentazione di debolezze e falle, ma anche l’esplicito reperimento di informazioni su vulnerabilità e minacce da fonti esterne ed enti specializzati.
Pare quindi che un qualcosa che rimanda fortemente al concetto di patching e di politiche di patching, non sia affatto alieno per le principali normative vigenti.
Il programma di patch management
A questo punto, si entra nel vivo del discorso: come si mette effettivamente in piedi una politica ed un programma di gestione del patch? Ed è proprio qui che si possono maggiormente apprezzare le differenze nei fondamentali del patching rispetto al più tradizionale concetto di aggiornamento dei sistemi dove, di fatto, la gestione ha degli elementi preparatori più complessi ed una operatività differente.
Procedendo per gradi, una politica di gestione delle patch deve chiarire quali siano le priorità in tal senso, quali siano soglie e tempistiche accettabili e soprattutto quali siano i sistemi più di valore per l’azienda.
Nel concreto, tutto ciò si può realizzare con un programma strutturato che preveda:
- il mantenimento di un inventario dei sistemi, inclusi sistemi operativi, macchine, locazioni fisiche, programmi commerciali e servizi presenti nelle reti aziendali. Uno degli obiettivi principe di questa fase è l’identificazione delle infrastrutture e dei sistemi importanti per il business dell’azienda, quelli che se non funzionanti o se compromessi dai cyber criminali potrebbero causare danni rilevanti;
- un piano di razionalizzazione, per tendere ad un livello di uniformità tecnologica accettabile. Altrimenti il rischio è che il Dipartimento IT si ritrovi ad avere più applicativi e tecnologie di quelle che è in grado di gestire efficacemente. E possibilmente avere delle politiche di aggiornamento periodico per di essi;
- l’inventario dei controlli di sicurezza, ad esempio antivirus, sistemi di rilevamento e prevenzione delle intrusioni, firewall eccetera. Di grande valore per quando si dovrà decidere come gestire le falle;
- la comparazione delle vulnerabilità con l’inventario dei sistemi, aspetto per nulla banale che spesso richiede l’aiuto di specialisti e che comporta il reperimento di informazioni attendibili su vulnerabilità e minacce. Questa fase è realizzabile in tanti modi, ad esempio utilizzando i cosiddetti Vulnerability Assessment o con l’ausilio di servizi di Vulnerability Intelligence;
- una fase di valutazione, di classificazione dei rischio e della probabilità che un avvenga un attacco ai danni dei sistemi aziendali. Questo comporta non solo la conoscenza di cosa sia “mission-critical” per l’organizzazione, ma anche di quello che sta avvenendo nella Internet e di quello che potrebbe comportare nel contesto aziendale. Un tipo di conoscenza che solo poche realtà specializzate hanno.
- l’applicazione delle patch, fase ultima che nasconde altrettante insidie. Infatti, l’applicazione degli aggiornamenti di sicurezza deve essere anch’essa sicura: le stesse patch e le modalità di applicazione devono garantire la funzionalità dei sistemi.
Ed è proprio per questo che l’installazione degli aggiornamenti a volte può non essere la soluzione migliore, specie in casi di emergenza, dove gli amministratori di sistema, forti del lavoro preparatorio delle fasi 1) e 3), possono valutare se applicare modifiche alle configurazioni di rete o blocchi temporanei in attesa degli esiti dei test di applicazione delle patch.
Patching in azienda: mantenersi informati
Come visto poc’anzi, gestire delle politiche di patching richiede vari elementi. Ma soprattutto richiede accesso ad informazioni su vulnerabilità e minacce, informazioni alle quali le aziende, ad oggi, non sono particolarmente avvezze.
Esistono vari strumenti e metodologie per acquisire queste informazioni, anche se molto spesso la scelta ricade nel l’ausilio di professionisti, specie per via della varietà di tecnologie che pervadono le reti aziendali e per la complessità del reperimento e della comprensione di questo tipo di informazioni, pena il perenne stato di allerta e la conseguente gestione fallimentare delle politiche di patching.
Tuttavia, per le aziende italiane più lungimiranti sulla cyber security che desiderano muovere i primi passi nella gestione del patching, è possibile attingere gratuitamente ad un canale informativo curato direttamente dal Ministero dello Sviluppo Economico: il CERT Nazionale, principale Computer Emergency Response Team italiano.
Le attività che il CERT Nazionale porta avanti si rivolgono infatti alle imprese ed ai cittadini italiani, al tessuto produttivo nazionale.
Il CERT Nazionale ha tra i suoi obiettivi proprio quello di fornire informazioni tempestive su potenziali minacce informatiche che possano recare danno ad imprese e cittadini, tra le quali anche le vulnerabilità più gravi che affliggono applicativi, sistemi e tecnologie maggiormente diffuse nel panorama cibernetico nazionale.
Conclusioni
Avere una politica di patching, e soprattutto attuarla programmaticamente, significa fare qualcosa di diverso rispetto al passato. Benché la gestione del patching abbia aree di sovrapposizione con le pratiche di aggiornamento dei sistemi, essa differisce profondamente in vari aspetti chiave. Vi sono infatti:
- fasi preparatorie più complesse che richiedono di comprendere cosa sia più importante per l’azienda e quali controlli di sicurezza operabili in caso di emergenza;
- momenti di valutazione volti a capire i rischi dell’avere una particolare debolezza nei propri sistemi, fatto che comporta anche reperimento di informazioni accurate su vulnerabilità e minacce (e la loro non banale comprensione);
- azioni di “patching” che vanno al di là della semplice installazione degli aggiornamenti.
Ed è proprio per questo che avere un programma di aggiornamento dei sistemi, cosa del tutto positiva anche per la sicurezza, non equivale ad avere una politica di patching.
Tuttavia, muovere i primi passi nella gestione delle patch non è prerogativa delle grandi aziende e delle multinazionali, è possibile farlo con accortezze, competenze e strumenti alla portata anche delle PMI.
