Il recente bug Spectre e Meltdown nella progettazione dei processori di tutti i principali produttori ha prodotto una enorme quantità di bollettini ed approfondimenti sul tema, che concludevano consigliando di “installare le patch”, come spesso accade quando viene scoperta una nuova vulnerabilità.
Se ad un pubblico consumer, o di micro-aziende senza governance dei sistemi informatici o del sistema di gestione della sicurezza delle informazioni, è possibile consigliare in modo semplice di applicare gli aggiornamenti per tutti i dispositivi elettronici che lo richiedano, per le aziende o PA con maggiore complessità questo consiglio nasconde in realtà l’esigenza di un processo strutturato per la gestione del tema.
I rischi delle patch nelle aziende
L’installazione di aggiornamenti, in contesti dal medio al large enterprise, passando per la PAC, nasconde dei rischi non indifferenti. Spesso molte applicazioni sono personalizzate per il contesto specifico, alcune applicazioni sono state sviluppate specificatamente per un’organizzazione. Altre volte alcune patch contengono degli errori che creano problemi o effetti non voluti.
Si pensi, a titolo di 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 large enterprise, un blocco dovuto ad un aggiornamento magari colpirebbe un solo ufficio, quello che usa quello specifico servizio. Ma potrebbe essere un ufficio di centinaia di persone o una funzione di business critica.
Questi, che sono scenari da tenere normalmente in considerazione, nel caso specifico delle patch rilasciate da Intel per i bug Spectre e Meltdown, hanno realizzato i peggiori incubi di tutti. Il produttore, infatti, ha consigliato di non installare le patch rilasciate perché, in alcuni casi, potrebbero bloccare completamente i sistemi aggiornati.
Nelle comunicazioni di Intel, infatti, si trova il seguente consiglio: “We recommend that OEMs, Cloud service providers, system manufacturers, software vendors and end users stop deployment of current versions on the below platforms, as they may introduce higher than expected reboots and other unpredictable system behavior.”
Per maggiori informazioni è possibile consultare il comunicato stampa e l’approfondimento tecnico.
Le best practice per la gestione delle patch
Per questa ragione le best practice prevedono una procedura di test degli aggiornamenti, per verificare che non creino problemi non voluti, prima del “mass deploy”, dell’aggiornamento automatico di tutti i dispositivi interessati.
Questo comporta un ambiente non di produzione, un ambiente di test, non utilizzato dai collaboratori per lavorare, su cui eseguire i test. Significa che tale ambiente deve essere il più possibile fedele a quello di produzione (pena l’inefficacia del test) e che secondo leggi (Es. GDPR) e best practice (es. ISO/IEC 27001:2013) preveda la corretta gestione del se e quali dati reali possono esistere in tali ambienti (gestione dei dati di test). È necessario, quindi, avere una checklist formale dei test da eseguire e dell’esito atteso, così da poter marcare il test come di successo. È poi pensabile, a seconda del contesto, un primo rilascio controllato su una porzione dei sistemi di produzione, assicurandosi la possibilità di eseguire rapidamente roll-back in caso di problemi, vale a dire la possibilità di rimuovere gli aggiornamenti appena installati.
Se queste procedure sono una indispensabile misura a tutela dell’organizzazione parlando di device end-user (computer, telefoni, tablet, etc.) diventano molto più complesse da gestire parlando di Internet of Things (che nel caso specifico del bug delle CPU è uno degli ambiti in cui si trovano molti device vulnerabili) o server.
Se poi, come in tutte le moderne organizzazioni è presente una infrastruttura virtualizzata (si pensi alle soluzioni Vmware, Citrix, Microsoft solo per fare qualche esempio), l’impatto di una patch “problematica” rischia di essere incommensurabile: un piccolo set di server che dovesse smettere di funzionare, o rallentare significativamente, potrebbe rendere non più disponibili decine di servizi.
Il problema tempo e la window of exposure agli attacchi
Anche l’introduzione di nuovi strumenti (es. gli ad-blocker consigliati per evitare che tali bug possano essere sfruttati da siti malevoli visitati per sbaglio) spesso comportano progetti che tra test e deploy potrebbero richiedere settimane.
L’applicazione massiva di patch, inoltre, in organizzazioni complesse, richiede, oltre al tempo necessario per i test, giorni se non settimane per il deploy. Si immagini una rete geografica con anche solo centinaia di end-point: oltre ai normali tempi necessari per i test ci sono i tempi di distribuzione, applicazione, reboot dei device e gestione della piccola percentuale sistematica di device che hanno dato errore durante la procedura automatica e vanno quindi gestiti a meno.
In questi casi significa che la finestra temporale in cui l’organizzazione resta esposta al rischio di subire un attacco andato a buon fine, la window of exposure, non finisce, come troppo spesso si sente dire, nel momento in cui la patch è disponibile, ma quando è stata effettivamente installata su tutti i dispositivi. La durata della window of exposure, quindi inizia con la scoperta di un metodo di utilizzo della vulnerabilità per sferrare un attacco, metodo noto al grande pubblico oppure no, e termina con la reale messa in sicurezza di tutti i device.
Approfondimento: la gestione dei dati di test
Questo tema è molto delicato poiché, oltre a mettere a rischio la riservatezza dei dati aziendali, ha profonde implicazioni nell’adeguamento al GDPR.
Gli ambienti di test, troppo spesso vengono creati clonando gli ambienti di produzione: questa tecnica ha il vantaggio di creare un ambiente estremamente fedele in cui condurre le simulazioni, ma crea l’enorme rischio di avere un ambiente meno controllato, spesso con maggiori accessi da parte di esterni (es. sviluppatori software) ai dati aziendali.
Per questa ragione tutte le best practice suggeriscono di valutare se e quali reali dati sia effettivamente necessario conservare nell’ambiente di test e di adottare soluzioni tese ad anonimizzare o mascherare i dati presenti.
Anonimizzare prevede, ad esempio, il sostituire tutti i cognomi, mail, codici fiscali, numeri di carta di credito con asterischi. L’anonimizzazione è di certo la soluzione più efficace, ma potrebbe rendere poco leggibili gli output del programma in caso di test.
Il masking, invece, prevede di sostituire i contenuti reali con contenuti simili, ma generati “casualmente”. Facendo i test, quindi, selezionando la maschera che mi dà accesso, ad esempio, all’anagrafica Clienti, vedrei nomi, cognomi mail nel formato corretto, ma nessuno dei dati visualizzati sarebbe una delle informazioni reali presenti sui sistemi di produzione.
Conclusioni
Applicare le patch in tempi rapidi ed in modo massivo è una esigenza di tutte le organizzazioni, imprese o PA che siano. Questo, tuttavia, è un processo che rischia di essere insidioso e di creare non pochi problemi, se non gestito adeguatamente. Per questa ragione diventa indispensabile avere i processi e le procedure corrette al fine di assicurare la sicurezza delle informazioni, patrimonio dell’organizzazione, di cui deve essere garantita non solo la riservatezza, ma anche la disponibilità.
