E’ già Mercoledì, e io no

(*) "E' già Mercoledì, e io no" è il titolo di un libro di Alessandro Bergonzoni

Il 2° Martedì del mese Microsoft rilascia gli aggiornamenti...

...e il Mercoledì successivo gli Amminstratori del Dipartimento IT hanno gli incubi !

Molti di questi aggiornamenti sono aggiornamenti di sicurezza, fatti per correggere vulnerabilità che altrimenti potrebbero essere sfruttate per un attacco ai nostri sistemi.

Sul PC di casa siamo ormai abituati a vedere le notifiche che ci arrivano dal servizio di Windows Update quando gli aggiornamenti vengono automaticamente rilevati, scaricati ed installati. Ogni tanto (spesso) è necessario anche riavviare il PC per completare l'aggiornamento, e sappiamo bene che questo comporterà un certo tempo di attesa.
Dopo queste operazioni, il nostro PC dovrebbe ripartire tranquillamente e tutto dovrebbe funzionare di nuovo come prima (o meglio).

Il condizionale è d'obbligo, in quanto non è detto che tutto ritorni a funzionare come prima dopo un aggiornamento !

Ecco perchè, prima di effettuare aggiornamenti importanti sul PC, il servizio di Windows Update crea un punto di ripristino da cui è possibile far ripartire il tutto, nel caso qualcosa vada storto.
Di recente, Microsoft ha addirittura previsto la rimozione automatica degli aggiornamenti che causano problemi all'avvio del PC, per problemi hardware, danneggiamento dei file o per la presenza di software non compatibili.

...e per l'aggiornamento dei PC Aziendali ?

Di norma, l'installazione degli aggiornamenti sui PC Aziendali viene gestita e controllata centralmente dal Dipartimento IT tramite i servizi WSUS (Windows Server Update Services).

Un apposito Server Aziendale dedicato (WSUS Server) connesso a Internet riceve periodicamente tutti gli aggiornamenti rilasciati da Microsoft e li memorizza localmente.
Gli Amministratori del Dipartimento IT verificano e pianificano l'installazione degli aggiornamenti sui vari Gruppi di PC Aziendali, in base alle esigenze operative e tenendo conto delle diverse configurazioni specifiche di ogni Gruppo.

In questo modo:

• non è necessario che ogni PC Aziendale si scarichi i propri aggiornamenti da Internet - gli aggiornamenti vengono scaricati una volta sola sul Server WSUS;
• gli Amministratori del Dipartimento IT possono preventivamente verificare, su un campione di ogni Gruppo di PC, che l'installazione di questi aggiornamenti non provochi malfunzionamenti con le applicazioni Aziendali;
• l'installazione degli aggiornamenti sui PC Aziendali non richiede che gli Utenti possiedano privilegi di Amministratore - cosa che (come abbiamo visto) è meglio evitare.

Anche i Server Aziendali vanno aggiornati...

Applicare gli aggiornamenti di sicurezza ai Server Aziendali (soprattutto a quelli esposti su Internet) è ancora più importante dei PC !

Purtroppo, l'installazione degli aggiornamenti di sicurezza sui Server è condizionata da diversi fattori:

Impatto sui Servizi IT erogati

Bisogna assicurarsi che l'installazione degli aggiornamenti su ogni Server non abbia impatto sui Servizi IT che esso eroga. Il rischio è quello di trovarsi - dopo l'installazione degli aggiornamenti - con un Sistema che non è più in grado di svolgere correttamente il proprio compito all'interno dell'infrastruttura IT Aziendale, con la conseguenza di pesanti ripercussioni sul business.

Per questo motivo il Dipartimento IT dovrebbe sottoporre gli aggiornamenti ad una fase di TEST in un apposito ambiente allo scopo dedicato, prima del loro rilascio in Produzione. L'effettiva disponibilità di questo ambiente di TEST (che dovrebbe replicare piuttosto fedelmente l'ambiente di Produzione) e la complessità delle prove da effettuare (per avere una sufficiente garanzia di continuità dei Servizi IT) condizionano fortemente le tempistiche di aggiornamento dei Server in ambiente di Produzione.

Si potrebbe pensare di abbreviare i tempi "saltando" la fase di TEST ed applicando gli aggiornamenti direttamente in Produzione, ma:

• si rischia di causare un DISASTRO

• il risultato che si ottiene, spesso non è all'altezza delle aspettative

Programmazione dei fermi di Sistema

In un mondo ideale, l'infrastruttura IT di una Azienda dovrebbe essere sempre disponibile (24 ore su 24 - 7 giorni su 7) in modo da consentire al business di operare sempre al 100% delle proprie capacità.

Questo però non è possibile, perchè:

• è necessario svolgere periodiche operazioni di manutenzione ordinaria sui Sistemi (come ad esempio la riorganizzazione di Basi Dati, i salvataggi ed eventuali ottimizzazioni / riconfigurazioni);
• è necessario procedere al rilascio in Produzione delle nuove funzionalità che vengono sviluppate nell'ambito dei numerosi progetti di innovazione (che spesso vanno a rimpiazzare o estendere Servizi già esistenti).

Per questo il Dipartimento IT stila solitamente un calendario di fermi programmati, appositamente studiato e concordato con il business,  in cui poter effettuare queste indispensabili operazioni.

Dal punto di vista del business le operazioni di manutenzione ordinaria e di rilascio delle nuove funzionalità sono considerate ad alta priorità in quanto indispensabili per il funzionamento e l'evoluzione dei Sistemi IT.
Invece le operazioni di installazione degli aggiornamenti di sicurezza sono considerate non prioritarie perchè tanto «i Sistemi funzionano lo stesso»...

Succede quindi che - specialmente in alcuni periodi perticolarmente "critici" per il business - nel calendario dei fermi programmati non si riesca a trovare spazio per l'installazione degli aggiornamenti di sicurezza.

Facciamo un pò di conti...

Proviamo a valutare una ipotesi sulla tempistica di installazione (T_inst - T₀) degli aggiornamenti di sicurezza ai Server di una generica Azienda di medie dimensioni.

T₀

Partiamo considerando come istante iniziale il momento il cui l'aggiornamento di sicurezza viene reso disponibile da Microsoft attraverso un Security Bulletin nell'ambito di uno dei "Patch Tuesday" programmati (il secondo Martedì di ogni mese), trascurando il fatto che:

• la vulnerabilità a cui si riferisce è certamente stata scoperta ben prima del rilascio dell'aggiornamento che la corregge;
• la vulnerabilità potrebbe già essere nota "in-the-wild", in quanto non è detto che chi l'ha scoperta faccia parte di quella ristretta schiera di ricercatori di sicurezza (white-hat) che rispettano il principio di "responsible disclosure";
• potrebbe essere già disponibile "in-the-wild" un exploit che sfrutta questa vulnerabilità;
• l'aggiornamento che risolve la vulnerabilità potrebbe essere disponibile già prima del suo rilascio, ma - per rispettare le tempistiche standard - ne viene programmato il rilascio nell'ambito del primo "Patch Tuesday" disponibile.

T₁ = T₀ + 3 mesi

All'interno del Dipartimento IT è solitamente presente una struttura funzionale che ha il compito di gestire, regolamentare e pianificare i cambiamenti che vanno effettuati all'infrastruttura IT.
Di solito questa struttura funzionale (denominata Change Control Board) è costituita da un Comitato di tecnici ed esperti che si riunisce periodicamente per valutare e pianificare le richieste di rilascio in Produzione di software e Sistemi IT.
Supponiamo che il Change Control Board si riunisca una volta al mese, ma che - per ottimizzare le valutazioni inerenti gli aggiornamenti di sicurezza - prenda in esame un gruppo di aggiornamenti relativo ad esempio agli ultimi 3 Security Bulletin rilasciati da Microsoft.
Tralasciando il tempo che intercorre tra il rilascio dell'ultimo Security Bulletin e la convocazione del Change Control Board possiamo quindi stimare che tra il rilascio del Security Bulletin più vecchio (T₀) e l'esame da parte del Change Control Board (T₁) siano trascorsi al massimo 3 mesi.

T₂ = T₁ + 2 mesi

Consideramo trascurabile il tempo necessario al Change Control Board per elaborare e sottoporre all'approvazione del business il Piano dei fermi di Sistema relativi alle richieste di cambiamento esaminate.
I cambiamenti approvati dal Change Control Board devono essere sottoposti ad una verifica in ambiente di TEST, per controllare che tutte le funzionalità che devono continuare ad essere attive non vengano in alcun modo compromesse dalla implementazione di questi cambiamenti.
Possiamo stimare che tra l'approvazione del Change Control Board (T₁) ed il completamento di tutte le verifiche sui cambiamenti che fanno parte di questo lotto di aggionamenti (T₂) siano necessari al massimo 60 giorni.

T_inst = T₂ + 1 mese

E' ora finalmente giunto il momento di rilasciare questo lotto di aggiornamenti (approvato e testato) in ambiente di Produzione.
Le attività di rilascio in Produzione non sono solitamente molto corpose, ma richiedono una scrupolosa preparazione preliminare che comprende l'effettuazione di salvataggi dell'ambiente prima della modifica e la predisposizione di un piano di ripristino, nel caso in cui le operazioni non vadano a buon fine.
E' possibile quindi stimare che tra l'OK al rilascio in Produzione (T₂) e il completamento dell'installazione (T_inst) possano trascorrere al massimo 30 giorni.

Risultato: T_inst - T₀ = 6 mesi

Questo vuol dire che (nel caso peggiore) per un periodo di 6 mesi i Sistemi resteranno esposti al rischio di un attacco che sfrutta una vulnerabilità nota, ma per cui è già da diverso tempo disponibile un aggiornamento di sicurezza !

Virtual Patching - una soluzione ?

Come porre rimedio a questo enorme e cronico ritardo nell'installazione degli aggiornamenti di sicurezza sui Server Aziendali ?
Si potrebbe tentare di ridurre un poco i tempi di TEST degli aggiornamenti e prevedere una pianificazione dei fermi di sistema un pò più frequente, ma anche facendo così la finestra temporale durante la quale i sistemi restano vulnerabili rimarrebbe comunque elevata.

Occorre cercare una soluzione alternativa che consenta di proteggere in qualche modo i sistemi vulnerabili dai possibili attacchi, in attesa del completamento dell'iter di installazione degli aggiornamenti.

Le soluzioni di Intrusion Prevention ci possono venire in aiuto in questo compito.

Un Intrusion Prevention System può intercettare ed analizzare in tempo reale il traffico di rete diretto ai Server, individuando e bloccando il traffico riconducibile ad un attacco che tenta di sfruttare le vulnerabilità non ancora corrette.

Questo tipo di funzionalità viene chiamata "Virtual Patching":

Una patch è una correzione che viene apportata ad una porzione del codice per eliminare una vulnerabilità di sicurezza. In genere una patch viene sviluppata e distribuita come sostituzione di uno o più elementi nel codice compilato. Una volta installata, la patch rende il sistema e/o l'applicazione immuni a tutti i vettori di attacco che tentano di sfruttare quella vulnerabilità.

 

Una patch virtuale invece non implementa correzioni, ma si limita ad analizzare e controllare il traffico diretto alle applicazioni ed ai sistemi per impedire che il traffico dannoso raggiunga l'applicazione vulnerabile. Una volta attivata, la patch virtuale impedisce che il vettore di attacco raggiunga la destinazione senza introdurre alcuna modifica nel sistema e/o nell'applicazione vulnerabile.

 

Questo approccio offre numerosi vantaggi rispetto alle patch convenzionali:

• Una patch virtuale può proteggere componenti mission-critical che devono rimanere online, quindi le operazioni non vengono interrotte come spesso invece accade con una patch convenzionale.
• Una patch virtuale riduce il rischio di un exploit rapidamente, fino a quando una patch efficace e permanente verrà testata e rilasciata in Produzione.
• Una patch virtuale può essere attivata e disattivata dinamicamente, secondo necessità, senza dover ricorrere a complesse operazioni di ripristino.
• Poiché il codice applicativo e le librerie di supporto non vengono modificati, è improbabile che una patch virtuale produca conflitti nel sistema.

Va comunque considerato che:

• Una patch virtuale potrebbe non affrontare tutti i possibili modi o tutte le possibili situazioni in cui un exploit può verificarsi a causa di una particolare vulnerabilità.
• La disponibilità di patch virtuali per ogni nuova vulnerabilità che viene scoperta è fortemente condizionata dal Fornitore della soluzione di Virtual Patching.
• Una volta che una patch virtuale è stata implementata e si è dimostrata efficace, un'organizzazione potrebbe sentirsi scarsamente motivata ad implementare una patch permanente.
• Mentre una patch virtuale può evitare una crisi immediata, non è probabile che offra altrettanti benefici a lungo termine come farebbe una patch permanente, perché la patch virtuale non può eliminare i difetti intrinseci in un programma applicativo.

Buon Mercoledì a tutti.

Cordialmente vostro,
Autostoppista Cyber Galattico.