La distribuzione e l’applicazione delle patch al software sono due delle attività più importanti affidate al team IT di un’organizzazione.
Esistono numerosi strumenti progettati per gestire tali attività, che rientrano nella categoria generale della gestione del software “ ” ().
Ciò che tuttavia spesso viene trascurato è che, indipendentemente dagli strumenti che il reparto IT possa scegliere per svolgere tale compito, è necessario affrontare le questioni relative ai processi e alle politiche prima che un’organizzazione possa assumere realmente il controllo del proprio ambiente software.
E molte organizzazioni non hanno modificato il proprio approccio alla gestione del software sin dai primi anni 2000s. In questo blog, metto in evidenza alcune di queste considerazioni relative al processo e ne spiego l’importanza.
Lista di controllo: le moderne pratiche di gestione del software da conoscere
La distribuzione centralizzata del software e l’applicazione delle patch rappresentano le soluzioni più efficaci
In base alla mia esperienza, le imprese che adottano un modello decentralizzato per la gestione del software presentano standard di sicurezza molto inferiori rispetto alle aziende che adottano un modello centralizzato.
E per “centralizzato” intendo che un’organizzazione può avere personale di supporto decentralizzato, ma un’unica autorità centralizzata che stabilisce quali software e quali aggiornamenti software verranno installati e quando. I team di assistenza distribuiti seguono tutti quella linea di condotta.
La centralizzazione favorisce la rapidità delle operazioni di test e di applicazione delle patch
Uno degli aspetti più importanti della gestione del software è la rapidità dei test e dell’applicazione delle patch. Nel passare a un modello centralizzato, è opportuno procedere a un’implementazione graduale o per fasi. Prima di passare all'ambiente di produzione, è opportuno effettuare alcune fasi di test. "Qualche" significa due o tre, non 20!
Il punto è che non è auspicabile che i dispositivi endpoint rimangano vulnerabili per troppo tempo, pertanto è opportuno distribuire tali aggiornamenti il più rapidamente possibile. In generale, un obiettivo realistico è di 7-15 giorni, ma tale durata potrebbe essere inferiore a seconda della criticità dell’aggiornamento.
Questo è l’aspetto normativo della gestione del software. Definisca gli accordi sul livello di servizio (SLA) per le sue patch più critiche. Si cerchi di ridurre il numero il più possibile. Non basi una cifra su ciò che ha fatto negli ultimi 20 anni. Fissate obiettivi ambiziosi.
30 giorni sono un periodo di tempo piuttosto lungo
Se mi reco presso un’azienda e il suo ciclo di applicazione delle patch supera i 30 giorni, il primo passo consiste nel far sì che tali aggiornamenti vengano rilasciati e installati su tutti i dispositivi entro 30 giorni. Non dovrebbe essere peggio di così.
Dovete capire che, quando vengono rilasciati questi aggiornamenti, anche i malintenzionati ne vengono a conoscenza. Coloro che intendono infiltrarsi nei vostri sistemi possono consultare la documentazione; possono vedere quali componenti vengono aggiornati e per quale motivo. Il tempo stringe e dovete aggiornare il vostro software prima che vengano sviluppate e utilizzate delle vulnerabilità. Ecco perché affermo che 30 giorni sono un periodo di tempo piuttosto lungo.
Ora, potrebbe non essere sempre opportuno applicare immediatamente le patch ai vostri sistemi di produzione. Forse sta riscontrando delle difficoltà legate alle dipendenze interne delle applicazioni. Ad esempio, le patch .NET potrebbero non funzionare correttamente con una delle vostre applicazioni personalizzate sviluppate internamente. Queste cose accadranno.
In genere si dispone di un periodo di circa una settimana durante il quale è possibile verificare l’eventuale presenza di tali conflitti. E, in definitiva, il vostro obiettivo è quello di ridurre quei 30 giorni il più possibile, fino ad avvicinarli il più possibile a una settimana. Questo dovrebbe essere l'obiettivo.
Ma quanto è grave la situazione? Il mondo delle “correzioni a posteriori”
Ciò che mi ha davvero aperto gli occhi nel corso degli anni è il numero di aziende che ritengono di stare andando alla grande o, quantomeno, di non stare andando male. Si attribuiscono un “B+”.
Ma poi effettuiamo una valutazione e individuiamo migliaia di patch critiche risalenti addirittura al 2007. È evidente che qualcosa non funziona. Di solito si tratta di una combinazione di strumenti e processi. È necessario affrontare entrambe le questioni.
Per molte aziende, la metodologia di applicazione delle patch “ ” che utilizzano oggi è la stessa che veniva impiegata nel 2007 o nel 2010. Ma il contesto in cui operano è cambiato. Hanno accumulato patch mancanti relative a un decennio o più, indipendentemente dal fatto che ne fossero a conoscenza o meno.
Non è raro iniziare con gli aggiornamenti di sicurezza critici e importanti per i propri sistemi operativi. A tutti questi aggiornamenti è associato un livello di gravità; potete quindi utilizzarli per farvi un’idea del grado di vulnerabilità dei vostri sistemi operativi.
Esistono inoltre livelli di gravità associati agli aggiornamenti delle applicazioni di terze parti , quali Adobe Acrobat (si veda il nostro blog sulla fine del ciclo di vita (EOL) di Adobe Flash ), browser web come Chrome e Firefox, nonché applicazioni di produttività come Office365.
Per quanto riguarda l’“aggiornamento cumulativo”, iniziate dagli aggiornamenti più critici e importanti. In un ambiente distribuito, ciò vi garantisce il miglior rapporto qualità-prezzo, ma non fermatevi qui.
Valutare dal punto di vista tecnico le carenze nella gestione del software è facile; risolverle, invece, non lo è
Non occorre molto tempo per individuare le lacune nelle metodologie di distribuzione del software e di applicazione delle patch. Tuttavia, raggiungere un consenso sulle politiche e sulle procedure volte a colmare tali lacune può richiedere molto tempo ed essere fonte di controversie.
Le persone costruiscono la propria carriera agendo in un determinato modo e spesso non desiderano cambiare. In molti casi, finché non iniziano davvero a valutare e a riflettere sulle proprie politiche, non si rendono nemmeno conto che l’unica ragione per cui tali politiche esistono è che «abbiamo sempre fatto così». Uno degli aspetti in cui è probabile che si incontri la maggiore resistenza riguarda il riavvio del sistema dopo un aggiornamento.
Questo perché il riavvio del sistema ha ripercussioni sugli utenti finali. Per le organizzazioni può letteralmente richiedere mesi decidere come riavviare gli endpoint garantendo al contempo un’adeguata notifica — evitando di riavviare il dispositivo di un utente mentre si allontana per andare a pranzo, nel bel mezzo di una presentazione o mentre sta lavorando su un documento critico.
È proprio in questo contesto che una forte leadership esecutiva risulta essenziale per una politica di riavvio del sistema ( Enforce ), poiché, soprattutto nel mondo delle applicazioni a ciclo di vita continuo ( Windows ), una patch non viene effettivamente installata e il codice vulnerabile sostituito finché il sistema o l’applicazione non viene riavviato.
Alcune organizzazioni lasciano all’utente finale la responsabilità di riavviare il sistema e non viene inviata alcuna notifica che indichi la necessità di un riavvio. Gli utenti finali si adegueranno a politiche più rigorose, qualora queste vengano applicate.
Impareranno a riavviare il sistema la prima o la seconda volta che ricevono una notifica — magari prima di pranzo — anziché cliccare su “Rimanda” fino a quando il riavvio non viene imposto in un momento inopportuno.
Quando collaboriamo con un cliente in materia di distribuzione di software, una delle prime cose che verifichiamo è l’ultimo riavvio. E spesso ci accorgeremo che il 75 % dei sistemi di un’organizzazione necessita di un riavvio. Allora, quelle patch che ha applicato? Non lo sono affatto.
Risk è un tema ricorrente in ogni discussione sulle patch software
Il motivo principale per cui le organizzazioni non applicano tempestivamente le patch è il timore di causare malfunzionamenti. Quando parlo con i vicepresidenti e i dirigenti di alto livello in merito agli aggiornamenti software, il tema del rischio emerge in ogni conversazione. «Qual è il rischio che il mio sistema rimanga vulnerabile per 45 giorni rispetto al rischio di implementare qualcosa in 30 giorni e causare il malfunzionamento della mia applicazione?» È la paura dell’ignoto. È il timore di un’interruzione dell’attività.
Se disponete di un piano di test e di metriche, potrete ridurre tale timore. Anche se tale piano di test consistesse semplicemente nel dire: «Distribuiamo questo aggiornamento su una serie di sistemi e vediamo se qualcosa smette di funzionare». Ma dovrebbe essere in grado di capire se qualcosa si è rotto. Dovreste disporre di tali dati senza dover fare affidamento sull’apertura di un ticket di assistenza da parte di qualcuno.
Se i responsabili delle applicazioni dispongono di dati concreti che dimostrano la sicurezza delle patch, saranno più propensi ad accettare quando Le comunicherà che intende ridurre il ciclo di applicazione delle patch da 30 a 15 giorni.
Per scoprire in che modo Tanium semplifica la gestione del software di terze parti , vi invitiamo a consultare 9 modi in cui Tanium vi consente di assumere il controllo del vostro ambiente software degli endpoint.
Se siete pronti a vederlo in azione, richiedete oggi stesso una demo all’indirizzo .
