“Patchare è già mitigare”. Si usa dire che prevenire sia meglio che curare. Di certo, da sempre, nel duro mondo dell’O&M – Operation & Maintenance ICT, ed ora sempre di più in quello della cyber security, patchare con regolarità è già mitigare il rischio. Ed è per questo che sarebbe utile adottare politiche di patching per la sicurezza dell’azienda.
È dunque utile approfondire l’argomento in quanto l’adozione di questa strategia è utile in azienda, sia per i benefici in ambito security sia a livello di business.
Indice degli argomenti
Patch, che cos’è e a cosa serve
Un abc minimo: cos’è una patch? Che significa patchare? Definizioni in rete quante ne volete, ci è piaciuto distillare queste.
Patch (in inglese “toppa”): in informatica indica un pezzo di software scritto per aggiornare, correggere, migliorare un programma. Le correzioni, i miglioramenti comprendono il superamento di vulnerabilità di sicurezza e altri errori (bug) generici. In tal caso queste patch vengono anche chiamate fix o bugfix.
Patching, da cui il neologismo patchare, è l’applicazione delle patch. Può essere un’installazione fatta “a caldo” (hot patching o live patching), cioè senza fermare e far ripartire il sistema o il software oggetto delle modifiche, oppure “a freddo” con stop/start e relativa indisponibilità del servizio che il sistema o il programma oggetto di patching fornisce.
Se queste attività vengono svolte con regolarità e all’interno di un processo dipartimentale o aziendale si parla di Patch Management Process e se si utilizzano a supporto anche dei tool hardware/software che permettono in modo automatico o semiautomatico di programmare ed eseguire la distribuzione e l’installazione delle patch su sistemi e programmi della propria rete, si parla di Patch Management System.
Ecco delineato l’argomento della nostra conversazione odierna: riflettere insieme sull’estrema importanza operativa e di security ma, soprattutto, sui benefici economici e di business che una efficiente patching policy a livello aziendale unita ad una regolare attività di manutenzioni preventive – che del patching costituisce l’altra faccia della medaglia – produce nel breve e medio periodo e, sicuramente, a lungo termine.
La manutenzione preventiva
Quando si parla del tagliando di manutenzione pensiamo subito alla nostra automobile, non al nostro PC. E invece una manutenzione preventiva ben organizzata ed eseguita in modo continuo, conservativo e pianificato consente di ridurre significativamente i rischi operativi in termini di diminuzione di fault e tempi di ripristino e, conseguentemente, di impatto sui Livelli di Servizio (SLA) e su eventuali Key Performance Indicators (KPI) forieri di possibili pagamenti di penali.
Ma cos’è una manutenzione preventiva, vi chiederete? Si definisce come tale l’insieme di attività cicliche periodiche finalizzate a mantenere sotto controllo lo stato di oggetti hw/fw/sw che costituiscono l’infrastruttura ICT per garantire la loro piena efficienza.
Ci soffermiamo in questo caso principalmente sull’infrastruttura ICT perché è la più complessa e delicata da gestire in termini di uptime, availability, shutdown/reboot… ma va da sé che il medesimo discorso può essere fatto per ognuna delle componenti del microcosmo ICT, prima fra tutte la parte applicativa.
Una policy di manutenzione preventiva si può determinare applicando il modello descritto di seguito:
- analisi preliminare delle aree tecniche ICT interessabili al programma di manutenzioni preventive;
- identificazione degli oggetti critici ICT per i quali ricercare massima disponibilità di servizio;
- definizione delle attività di manutenzione per gli oggetti identificati;
- pianificazione degli interventi ciclici e periodici di manutenzione.
Per andare al sodo, un’analisi preliminare come quella indicata, facendo riferimento ad una infrastruttura ICT standard di un cliente medio-grande, dovrebbe dare come output per le aree tecniche Sistemi, Rete IP, Storage, Database e Middleware una serie di oggetti interessabili ad un processo strutturato di manutenzione preventiva come: uptime, stato File System, interfacce di rete, NTP, disco mirror (W2K), Tablespace, Next Extent, Alert, DB alive, Listener; Check temperature, Check CPU, Check interfacce (LAN, WAN).
Le linee guida
Ecco dunque quali criteri-guida utilizzare per indirizzare gli interventi. Eccone alcuni:
- HW/FW/SW installati sui sistemi di Produzione dovranno essere mantenuti aggiornati alle ultime versioni disponibili e installabili, cioè compatibili con le versioni applicative e gli ambienti di Prodizione running in quel momento;
- l’uso delle risorse HW/SW di sistemi e apparati dovrà essere mantenuto al di sotto di livelli di soglia che garantiscano un margine operativo che consenta di far fronte a eventuali picchi di richieste di risorse superiori alla media;
- in aggiunta alla normale attività di monitoring, una serie di parametri specifici di sistemi e apparati dovrà essere controllata separatamente per identificare in anticipo possibili criticità di funzionamento e poter pianificare interventi proattivi di correzione.
Sulla base dei criteri descritti dovranno essere identificati e implementati una serie di controlli – e interventi correttivi – ad hoc che saranno registrati in log puntuali riferiti ai sistemi e agli oggetti interessati.
Tali log saranno i mattoni che consentiranno di costruire in modo automatico o semi-automatico la fotografia periodica dello stato della nostra infrastruttura ICT generando i report che saranno consegnati periodicamente al management operativo e le dashboard che atterreranno sulle scrivanie del top management.
Le politiche di patching in azienda
E arriviamo al patching, il cuore delle manutenzioni preventive, l’asse portante perché si applica principalmente al sistema operativo che regge e fa funzionare tutto l’ecosistema che costituisce una macchina informatica, un computer, sia esso fisico o virtuale, sia esso operante con Linux, Windows, Unix, Debian, OS X, Ubuntu, SunOS, HP-UX o quant’altro.
Per questo motivo la gestione del patching è tutt’altro che semplice e rifuggite come la peste da coloro che vi dicono il contrario: la gestione delle patch è una delle attività più difficili e critiche per un’impresa.
Perché? Un processo di Patch Management per essere efficace ed efficiente dovrà tenere in considerazione e, soprattutto, in equilibrio un insieme non indifferente di fattori, spesso tra loro in perenne conflitto di interesse.
Una piccola serie, non esaustiva, delle complessità standard da gestire nel patching è la seguente:
- riuscire a testare facilmente e rapidamente le patch prima dell’installazione in Produzione: richiede un ambiente molto simile alla Produzione per poter valutare gli effetti del patching e poter effettuare rapidamente marcia indietro in caso di problemi;
- possibilità o meno di hot/live patching per non fermare la Produzione durante il patching;
- inserire l’installazione delle patch durante i fermi applicativi per ridurre al minimo le finestre di down operativo;
- gestire le out-of-band patch: modifiche di emergenza del software che vengono distribuite immediatamente e non in occasione degli aggiornamenti programmati di routine;
- riuscire a guadagnare finestre di installazione lunghe nel caso di kernel patch o altre patch che richiedano parecchi step di installazione per essere completate;
- in ambienti estremamente eterogenei con migliaia di oggetti ICT e differenti sistemi operativi con differenti versioni degli stessi come gestire il patching e l’allineamento del livello di patch.
Politiche di patching: approccio strutturato e best practice
Di fronte a una complessità simile non resta che utilizzare un metodo strong che da un lato consideri in modo ponderato e saggio i rischi insiti nell’installazione delle patch in aziende a più elevata complessità e dall’altra metta in campo una “macchina da guerra” adatta alla sfida da compiersi.
Serve un approccio strutturato, ITIL-like, PPT: Processes, Persons, Tools. A partire da questi punti base:
- Identificazione oggetti critici (KPI-involved): si dovranno identificare per le varie categorie tecniche infrastrutturali (Sistemi, Rete IP, Storage, Database e MiddleWare) gli oggetti critici cioè quegli elementi con diretta influenza sull’andamento dei KPI (KPI-involved). A tale proposito l’esistenza in azienda di un CMDB (Configuration Management Data Base) dove fissare l’attributo di oggetto critico e il KPI correlato sarebbe ideale in questo frangente: in tal modo, infatti, dato un determinato KPI si potranno sempre conoscere quali siano gli oggetti ICT coinvolti e per i quali dovranno essere adottati tutti gli accorgimenti necessari al loro buon funzionamento.
- Focalizzazione patching su oggetti KPI-involved: gli interventi di patching dovranno essere prioritariamente eseguiti sugli oggetti critici cioè sugli elementi con diretta influenza sull’andamento dei KPI (KPI-involved).
- Fast Lane: le attività di patching sugli oggetti KPI-involved dovranno godere di una “corsia preferenziale” che consenta la loro effettiva programmazione entro 1 mese dalla prima richiesta di pianificazione in produzione.
- Priorità al patching infrastrutturale: nell’ambito delle attività che godono di ‘fast lane’ dovranno considerarsi prioritari, dato il forte impatto sul servizio e il notevole impegno in termini di pianificazione e di impiego di risorse, gli interventi di patching infrastrutturali rispetto a quelli applicativi.
- Pianificazione trimestrale: la pianificazione delle attività di patching dovrà avere carattere trimestrale per consentire una migliore distribuzione di impatti e carichi di lavoro e dovrà essere integrata con le altre esigenze operative (canvass, upgrade per capacity planning, CR tecniche…).
- Ownership unificata: si suggerisce inoltre, per assicurare efficacia al processo e diminuirne i rischi di frammentazione, di definire una ownership unica per tutti i gruppi O&M ICT allo scopo di garantire unità nella redazione dei piani trimestrali, nella verifica dell’andamento degli interventi e nella gestione delle eventuali criticità.
- Reporting: allo scopo di mantenere un effettivo controllo sulle attività dovrà essere predisposto un apposito report periodico ad uso del management per la verifica quantitativa e qualitativa delle attività eseguite e la notifica di eventuali criticità di processo.
Servono anche delle best practice che facciano da boe, punti di riferimento operativi sicuri per orientarsi tra i rischi e le onde del vasto mare del patching. Bisogna prestare attenzione a:
- personalizzazione: in contesti medio-grandi spesso molte applicazioni sono personalizzate per il contesto specifico oppure, addirittura, alcune applicazioni sono state sviluppate specificatamente per un’organizzazione;
- errori delle patch: alcune patch contengono degli errori che creano problemi o effetti non voluti. Spesso si dice che per un errore corretto una patch ne inoculi nel sistema/programma almeno altri 7;
- configurazioni speciali: vi sono software che per funzionare richiedono solo specifiche versioni di sistema operativo o di browser e patch che inibiscono il funzionamento di alcune componenti dei browser stessi;
- infrastrutture virtualizzate: una patch “problematica” potrebbe avere un enorme impatto: un numero ristretto di server furi uso, o significativamente rallentato, potrebbe rendere non più disponibili molte decine di servizi;
- prevedere ambienti e procedure di test delle patch per verificare che non creino problemi: ciò significa avere un ambiente di test il più possibile fedele a quello di produzione e con dati che, rispettando leggi e regolamenti vigenti, ad esempio in termini di privacy e riservatezza (rif. GDPR), si avvicinino ai dati di produzione;
- rilasci campione: potrebbe poi essere ragionevole effettuare dei rilasci campione su una porzione di sistemi di produzione, assicurandosi la possibilità di eseguire rapidamente roll-back, rimuovere cioè gli aggiornamenti appena installati, in caso di problemi;
- Window of Exposure: l’applicazione massiva di patch in organizzazioni complesse richiede, oltre al tempo necessario per i test, anche giorni, se non settimane, per il deploy. Bisogna sempre cercare di ridurre il più possibile, mantenendo al tempo stesso in sicurezza l’azienda e la sua Produzione, la finestra temporale in cui l’organizzazione rimane esposta al rischio di subire un attacco che andrà a buon fine, la cosiddetta window of exposure. Tale finestra termina solo quando la patch è stata effettivamente installata su tutti i dispositivi non quando la patch diventa disponibile;
- stabilire criteri temporali: decidere in base alle proprie esigenze e a quanto consigliano vendor e letteratura tecnica, dei tempi minimi/massimi per il patching: per esempio quante volte l’anno effettuare il patching di OS e firmware –> min 1 volta per anno.
Conclusioni
Come abbiamo visto non è tutto e solo patching anche se, con riferimento a un sempre più crescente bisogno di difesa dagli attacchi quotidiani e sempre più sofisticati del cybercrime, il patching ha assunto un ruolo centrale fondamentale in ottica sicurezza. E questo soprattutto perché gli attacchi sfruttano vulnerabilità presenti in parti dei sistemi operativi e dei programmi che non sono strettamente attinenti alla sicurezza.
La gestione strutturata e integrata di un programma di patching e insieme di manutenzioni preventive può fare molto in tal senso e, soprattutto, dire molto del livello di maturità raggiunto dalla organizzazione ICT di una azienda: come sempre avviene per le situazioni più complesse dovrà essere una gestione modulare e a più livelli, con una strategia unica che si dipani in diverse articolazioni operative.
In ogni caso, infine, la presenza di almeno uno, se non di entrambi, i rami operativi illustrati quest’oggi costituisce sempre, di per sé sola, elemento di successo nei termini di riduzione del rischio operativo che si traduce in benefici economici derivati dal cost saving per minori fault e fermi macchina e migliori SLA e KPI.
