Patch Management sugli Asset Informatici: creazione e gestione del Report
Patch Management e il GDPR: l’articolo 32 del GDPR prevede che il titolare del trattamento metta in atto misure tecniche ed organizzative per garantire un livello di sicurezza adeguato al rischio. Devono pertanto essere previste delle procedure di test, di verifica e di valutazione per misurare l’efficacia delle misure sopracitate da eseguirsi con cadenza periodica.
Per assolvere a tale obbligo è strumentale dotarsi su ogni macchina, PC o server, di un report certificato, generato e gestito da un software specifico, sull’asset informatico che restituisca per ognuna delle macchine presenti in azienda:
- report delle caratteristiche hardware e stato di aggiornamento degli asset informatici;
- report del Sistema Operativo e del suo stato di aggiornamento;
- elenco dei software installati sui dispositivi. Questo report consente al titolare del trattamento di essere consapevole dell’eventuale installazione, da parte del suo personale, di software non autorizzato e/o pericoloso per l’incolumità dei dati aziendali e personali;
- confronto periodico tra la versione precedente e quella successiva dell’asset informatico e report delle differenze riscontrate. Qualora dovessero insorgere dei problemi causati dai nuovi aggiornamenti, tramite un software di back up, si ripristina la versione precedente.
Patch Management sugli Asset Informatici: software e obiettivo
Il sistema di Patch Management (un valido software è rappresentato da “F-Secure Protection Service for Business”) per gli asset informatici consente di aggiornare periodicamente il parco macchine con dei costi molto contenuti.
Pertanto l’obiettivo finale del Patch Management è quello di allineare i sistemi operativi e i software alle ultime versioni, sia per risolvere i bug funzionali sia per ottemperare alla normativa GDPR.
Patch Management sugli Asset Informatici: quali i rischi da considerare
L’installazione di aggiornamenti, in contesti che vanno dalla piccola alla grande impresa, nasconde dei rischi non trascurabili che possono mettere a rischio la “Business Continuum”.
Un aspetto da tenere in considerazione è la gestione delle patch in ambienti dove molto spesso le applicazioni sono personalizzate per il contesto specifico nel quale opera l’impresa. Pertanto si può verificare che in fase di aggiornamento alcune patch contengono degli errori che creano problemi o effetti non voluti.
Si pensi ad esempio a gestionali o CRM che per funzionare richiedono specifiche versioni di sistema operativo o browser, o di patch che inibiscono il funzionamento di alcune componenti.
In un quadro che comporti il minimo di complessità ed una forza lavoro non numericamente impressionante, applicare un aggiornamento che blocchi completamente l’accesso ad una applicazione o ad una funzionalità potrebbe bloccare completamente l’organizzazione.
In uno scenario di grande impresa, un blocco dovuto ad un aggiornamento di una patch “difettosa” magari potrebbe colpire solo un ufficio, l’ufficio che usa quello specifico applicativo; ma potrebbe essere un ufficio composto da centinaia di persone o una funzione di business strategica.
Patch Management degli Asset Informatici: l’importanza dell’ambiente di test
Per tutti questi motivi le “best practice” prevedono una procedura di test degli aggiornamenti, per verificare che non creino problemi prima del “rilascio” in produzione dell’aggiornamento automatico su tutti gli asset informatici interessati.
Questo comporta la creazione di un ambiente di test. Tale ambiente deve essere il più possibile fedele a quello di produzione (pena l’inefficacia del test) e che secondo la normativa del GDPR e delle best practice (es. ISO/IEC 27001) preveda la corretta “gestione del se” e quali dati reali possono esistere in tali ambienti (gestione dei dati di test).
Patch Management per gli Asset Informatici: una Checklist per ottenere test di successo
Pertanto è necessario, dotarsi di una checklist formale dei test da eseguire e dell’esito atteso, così da poter segnare il test come di successo.
È poi pensabile, a seconda del contesto aziendale, un primo rilascio controllato su una piccola porzione degli asset informatici in produzione per assicurarsi la possibilità di eseguire rapidamente un “roll-back” in caso insorgessero problematiche. Per roll-back si intende la possibilità di rimuovere gli aggiornamenti appena installati.
Se poi, come in molte organizzazioni moderne è presente una infrastruttura virtualizzata (si pensi alle soluzioni Vmware, Citrix, Microsoft…), l’impatto di una patch “fallata” rischia di produrre un danno incalcolabile, infatti una piccola dotazione di server che dovesse smettere di funzionare, potrebbe inficiare la “business continuum”.
