Server patch management 101: Strategies for secure infrastructure

I server non ricevono le patch allo stesso modo dei computer portatili. Un aggiornamento non riuscito sulla postazione di lavoro di un dipendente causa disagi a una persona. Un aggiornamento non andato a buon fine su un server di database può compromettere o interrompere temporaneamente le transazioni a livello dell’intera unità aziendale, rendendo indispensabile la pianificazione del rollback.

Le prassi standard di gestione dei dispositivi concepite per gli endpoint semplicemente non sono applicabili agli ambienti server. La posta in gioco dal punto di vista operativo, le catene di dipendenza e i requisiti di disponibilità sono categoricamente diversi.

Tale differenza nel raggio d'azione cambia radicalmente il modo in cui la correzione viene pianificata, organizzata ed eseguita. La gestione delle patch dei server comporta il coordinamento in base ai requisiti di operatività, alle dipendenze delle applicazioni e ai flussi di lavoro di gestione delle modifiche, aspetti che l’applicazione di patch all’ endpoint e in genere non richiede.

La presente guida illustra i vincoli operativi che rendono l’applicazione delle patch ai server un processo a sé stante, a partire dall’inventario e dalla mappatura delle dipendenze, passando per la definizione delle priorità basata sul rischio, l’implementazione per anelli, il coordinamento tra i team e la verifica post-implementazione.

Perché l’applicazione delle patch ai server richiede un approccio operativo diverso

Un solo aggiornamento fallito su un server di database può paralizzare un’intera unità aziendale. Ecco perché l’applicazione delle patch ai server non è semplicemente una versione su larga scal e della gestione delle patch : si tratta di una disciplina operativa fondamentalmente diversa.

Il processo generale di gestione delle patch prevede l’individuazione degli aggiornamenti mancanti, il collaudo delle patch in un ambiente di staging, la loro distribuzione durante le finestre di manutenzione e la rendicontazione dei risultati. Tra le migliori pratiche figurano l’automazione delle attività ripetitive, il rispetto di una cadenza regolare per l’applicazione delle patch, come ad esempio il “ Microsoft'’s Patch Tuesday” per gli ambienti Windows , l’adesione ai cicli di rilascio specifici dei fornitori per Linux e altre piattaforme, nonché la creazione di backup o snapshot prima dell’applicazione degli aggiornamenti.

Ma questo è il quadro di riferimento standard. La realtà per i team aziendali che gestiscono i server è più complessa.

I server eseguono spesso 24/7 carichi di lavoro con finestre di manutenzione ristrette, concordate con settimane di anticipo. Se si perde questa occasione, i tempi di esposizione si prolungano di settimane, anche quando le patch sono già state approvate e preparate per il rilascio. Nella gestione standard endpoint, i dispositivi possono riavviarsi durante la pausa pranzo con interruzioni minime. I server non dispongono di tale flessibilità.

C'è poi il problema delle dipendenze. I server operano raramente in modo isolato. Un aggiornamento applicato a un server può compromettere il funzionamento di un’API da cui dipende un altro server, il che a sua volta influisce su un terzo sistema a valle. È proprio questa rete interconnessa di servizi e dipendenze a rendere l’applicazione delle patch ai server sostanzialmente più complessa rispetto a quella alle post endpoint i, ed è per questo che le modifiche devono essere sequenziate con cura anziché distribuite in blocco.

I vincoli relativi all'applicazione delle patch ai server non rendono impossibile il lavoro. Lo rendono operativamente distinto. Le sezioni seguenti illustrano come affrontare ciascun vincolo in modo da ridurre i rischi senza creare nuovi problemi operativi.

Inventario dei server e mappatura delle dipendenze

Prima di implementare qualsiasi cosa, è necessario sapere su cosa si sta applicando la patch e quali elementi dipendono da essa. Un inventario dei server incompleto può compromettere le attività di applicazione delle patch prima ancora che la distribuzione abbia inizio.

Un inventario dei server finalizzato all’applicazione delle patch va oltre il semplice rilevamento delle risorse. Comprende le versioni dei sistemi operativi, le applicazioni installate, i livelli di patch e le funzioni aziendali supportate da ciascun server. Senza queste informazioni, i team finiscono per applicare le patch alla cieca, senza sapere con certezza se un determinato server ospiti un carico di lavoro di test o un database di produzione.

[Scoprite come un inventario completo e in tempo reale delle risorse IT possa migliorare la vostra capacità di gestire i rischi prima che si trasformino in violazioni]

La mappatura delle dipendenze aggiunge un ulteriore livello. I server ospitano spesso servizi a cui altri sistemi si rivolgono. Una patch che richiede il riavvio di un server middleware può interrompere temporaneamente le connessioni alle applicazioni a valle. In ambienti basati su cloud e container d , l’applicazione delle patch può anche comportare la ricostruzione delle immagini di riferimento e la ridistribuzione dei carichi di lavoro (infrastruttura immutabile), anziché l’aggiornamento in loco delle istanze a lunga durata.

Sapere quali elementi sono collegati a ciascun server e quali elementi interagiscono con esso consente ai team di organizzare correttamente l’applicazione delle patch e di informare le parti interessate coinvolte.

I processi manuali di inventario faticano a tenere il passo con la proliferazione dei server. Negli ambienti cloud i server vengono avviati e disattivati, e l’infrastruttura on-premise subisce cambiamenti con la stessa frequenza, attraverso disattivazioni, riconfigurazioni e nuove implementazioni che non sempre vengono registrate. Le variazioni nella configurazione si accumulano nel tempo. Le squadre che si affidano a verifiche trimestrali spesso individuano le lacune solo dopo che una patch non ha funzionato o una verifica ha segnalato una copertura insufficiente.

La visibilità delle risorse in tempo reale può risolvere questo problema monitorando costantemente lo stato dei server. Quando un nuovo server viene messo in funzione o la configurazione di un server esistente viene modificata, l’inventario può aggiornarsi automaticamente, a seconda della configurazione e della connettività.

I moderni software di gestione delle patch devono integrare questa funzionalità di inventario in tempo reale direttamente nel flusso di lavoro relativo all’applicazione delle patch, fornendo ai team un quadro aggiornato anziché un’istantanea obsoleta ed eliminando la riconciliazione manuale che rallenta gli approcci tradizionali.

Una volta predisposti un inventario completo e una mappa delle dipendenze, la domanda successiva è: a quali server applicare per primi le patch?

Come stabilire le priorità delle patch per i server utilizzando EPSS, CISA KEV e il livello di criticità delle risorse

Non tutte le vulnerabilità comportano lo stesso rischio. Un punteggio CVSS (Common Vulnerability Scoring System) pari a 9,8 su un server di prova non esposto alla rete è meno urgente di un punteggio CVSS pari a 7,5 su un server di produzione che gestisce le transazioni dei clienti. Una definizione efficace delle priorità tiene conto sia della gravità della vulnerabilità sia del contesto aziendale. Si tratta della pietra angolare di un programma maturo di gestione delle vulnerabilità che va oltre la semplice individuazione dei problemi per ridurre attivamente l’esposizione agli attacchi.

Tre indicatori consentono di affinare la definizione delle priorità al di là dei punteggi CVSS grezzi:

1. Sistema di valutazione della probabilità di sfruttamento delle vulnerabilità (EPSS): L’EPSS stima la probabilità che una vulnerabilità venga sfruttata in ambiente reale entro i prossimi 30 giorni. Una vulnerabilità con un punteggio CVSS elevato ma un punteggio EPSS basso potrebbe risultare meno urgente rispetto a una con un punteggio CVSS moderato e un punteggio EPSS elevato.
2. Catalogo KEV della CISA: Se una vulnerabilità compare nell'elenco KEV della CISA, significa che gli autori degli attacchi la stanno già sfruttando. Le vulnerabilità presenti in questo elenco vengono inserite in cima alla lista, indipendentemente dagli altri punteggi. Ciò è particolarmente rilevante per le piattaforme server ampiamente diffuse, tra cui Windows Server e le più diffuse distribuzioni Linux , che compaiono spesso negli elenchi KEV a causa della loro diffusione in ambito aziendale e nella rete Internet.
3. Asset criticità: Il ruolo di un server nelle operazioni aziendali influisce sulla rapidità con cui è necessario applicare le patch. I server che ospitano applicazioni generatrici di ricavi, dati soggetti a regolamentazione o servizi rivolti ai clienti richiedono in genere un intervento di risoluzione dei problemi più rapido. Rappresentano inoltre gli obiettivi più allettanti per gli autori di attacchi ransomware, che individuano deliberatamente sistemi di alto valore per massimizzare il proprio potere contrattuale.

Le vulnerabilità elencate nel KEV richiedono spesso di interrompere il normale ciclo di patch. Un programma di patch ben consolidato supporta la risposta fuori banda per le vulnerabilità incluse nell’elenco KEV o altamente esposte, anche qualora ciò comporti un’interruzione della cadenza di manutenzione ordinaria.

La combinazione dei segnali dà origine a una matrice di priorità. Una vulnerabilità con un punteggio EPSS elevato, presente nel KEV della CISA e presente su un server di produzione di livello 1 riceve immediata attenzione. Una vulnerabilità con un EPSS basso, non presente nell’elenco KEV e presente su un server di sviluppo può attendere la prossima finestra di manutenzione programmata. L'obiettivo non è quello di risolvere tutti i problemi in una volta sola. L'obiettivo è quello di ridurre sistematicamente la superficie di attacco, affrontando per prime le vulnerabilità che presentano il maggior rischio di essere sfruttate.

RiskUna definizione delle priorità basata su questo criterio aiuta i team a concentrare i propri sforzi laddove è possibile ridurre al massimo l’esposizione al rischio. Una volta stabilite le priorità, la sfida successiva consiste nell’applicare le patch senza compromettere il funzionamento dei sistemi.

Una definizione più efficace delle priorità relative alle vulnerabilità grazie a Tanium Comply

I backlog relativi alle vulnerabilità non si riducono lavorando di più, ma lavorando in modo più intelligente. Questo episodio della serie “ Tanium Tech Talks” illustra in che modo Tanium Comply integra le informazioni relative agli exploit ,, endpoint , nonché i dati relativi alla criticità e ai prodotti rilevati, ai punteggi CVSS, offrendo ai team un metodo più preciso e meglio giustificabile per decidere quali problemi risolvere per primi.

Se il Suo flusso di lavoro relativo all’applicazione delle patch al server inizia ancora con un foglio di calcolo e una valutazione intuitiva, vale la pena guardare questo video.

Strutturazione della distribuzione delle patch sui server tramite un approccio a anelli

L'applicazione simultanea delle patch su tutti i server è una fonte certa di interruzioni di servizio su larga scala. L'implementazione basata su anelli distribuisce le patch a gruppi progressivamente più ampi, individuando tempestivamente eventuali problemi prima che questi possano influire sui sistemi critici per la produzione.

Una struttura ad anello tipica si presenta come segue:

Anello 0: Canario

Un piccolo gruppo di server non critici riceve le patch per primo. I server Canary rispecchiano le configurazioni di produzione, ma non gestiscono i carichi di lavoro di produzione. Se una patch causa problemi, il danno è circoscritto.

Anello 1: Pilot

Dopo che i server canary hanno funzionato in modo stabile per un periodo prestabilito, le patch vengono trasferite a un gruppo pilota. Il gruppo pilota comprende una gamma più ampia di tipologie di server e potrebbe includere alcuni sistemi di produzione di livello inferiore. In questa fase il monitoraggio si intensifica.

Ring 2: Diffusione su larga scala

Una volta completate le fasi “canary” e “pilot”, le patch vengono distribuite alla maggior parte dei server. Questa fase viene spesso eseguita durante le finestre di manutenzione programmata e comprende controlli automatici dello stato di funzionamento prima e dopo l'implementazione. I dati provenienti dalle fasi precedenti consentono ai team di perfezionare la tempistica, le dimensioni dei lotti e la sequenza prima che l’implementazione raggiunga la sua portata massima.

Anello 3: Critico per la produzione

I server più sensibili ricevono in genere le patch solo dopo che queste sono state validate con esito positivo negli anelli precedenti, a meno che la gravità e l’esposizione dell’exploit non richiedano un intervento correttivo urgente. A questo punto, la patch si è dimostrata stabile su centinaia o migliaia di altri server.

I cancelli di feedback automatizzati controllano il passaggio tra gli anelli. Se in un anello si verifica un picco dei tassi di errore o i controlli di integrità falliscono, la distribuzione viene sospesa prima di proseguire. Ciò impedisce che una patch problematica si diffonda a cascata all’intera flotta.

L'implementazione basata su anelli funziona al meglio se integrata con i processi di gestione delle modifiche. Tale coordinamento rappresenta il prossimo tassello del puzzle.

Coordinamento dell’applicazione delle patch ai server tra i reparti di operazioni IT, sicurezza e gestione delle modifiche

L'applicazione delle patch ai server raramente rientra nelle competenze di un unico team. In un ambiente IT complesso, il reparto di sicurezza individua le vulnerabilità e stabilisce le tempistiche per la loro risoluzione, mentre il reparto operativo IT gestisce i server ed esegue le implementazioni; infine, la gestione delle modifiche regola quando e come tali modifiche vengono apportate. In assenza di un chiaro coordinamento tra queste funzioni, le patch rimangono bloccate nelle code di approvazione oppure vengono distribuite senza un adeguato controllo.

La chiarezza sui ruoli è di grande aiuto. Un modello comune assegna le responsabilità nel modo seguente:

• Sicurezza: Individua le vulnerabilità, stabilisce i criteri di priorità e definisce gli SLA relativi alle misure correttive
• Operazioni IT: Gestisce l’inventario dei server, esegue l’implementazione delle patch e monitora lo stato di funzionamento dopo l’implementazione
• Gestione delle modifiche: Approva le modifiche, pianifica le finestre di manutenzione e documenta le eccezioni

L'approvazione da parte del comitato consultivo per le modifiche (CAB) costituisce spesso un requisito imprescindibile per l'applicazione delle patch ai server, in particolare per i sistemi di produzione. L'integrazione dei flussi di lavoro relativi alle patch con piattaforme di gestione dei servizi IT (ITSM) quali ServiceNow semplifica tale processo. Patch Le richieste vengono gestite tramite ticket di modifica standard; le approvazioni vengono inoltrate automaticamente in base al livello del server e gli aggiornamenti sullo stato della distribuzione vengono riportati nel ticket in tempo reale.

Per le organizzazioni in cui l’applicazione delle patch viene fornita come servizio IT, sia internamente che tramite un fornitore di servizi gestiti, è proprio questo tipo di integrazione dei flussi di lavoro a rendere possibile un’esecuzione coerente e verificabile su larga scala. I fornitori di servizi gestiti (MSP), in particolare, traggono vantaggio da questa integrazione, poiché essa consente loro di Enforce standard di applicazione delle patch uniformi in diversi ambienti dei clienti senza dover creare flussi di lavoro personalizzati per ciascuno di essi.

Molti MSP distribuiscono le patch tramite piattaforme di monitoraggio e gestione remota (RMM), che garantiscono visibilità e controllo centralizzati sugli ambienti dei clienti; tuttavia, tali piattaforme presentano livelli diversi di efficacia nella gestione delle complesse dipendenze dei server e della logica di distribuzione basata su anelli.

Anche la gestione delle eccezioni richiede coordinamento. Alcuni server non possono essere aggiornati secondo il programma previsto a causa di vincoli aziendali, dipendenze dai fornitori o limitazioni tecniche. La documentazione delle eccezioni, unitamente ai controlli compensativi, garantisce la correttezza delle tracce di audit e assicura che i team di sicurezza comprendano il rischio residuo.

Per i server non aggiornati che presentano un rischio elevato, l’integrazione degli avvisi in una piattaforma di gestione delle informazioni e degli eventi di sicurezza (SIEM) può fornire il monitoraggio continuo necessario per Detect i tentativi di sfruttamento fino a quando non sarà possibile procedere alla correzione.

Una volta distribuite le patch e aggiornati i registri delle modifiche, l’ultimo passo consiste nel verificare che tutto abbia funzionato correttamente.

Verifica dell’avvenuta applicazione delle patch su tutto il parco server

L'applicazione di una patch non equivale alla sua installazione corretta. L'installazione delle patch può fallire per diversi motivi: limiti di spazio su disco, conflitti tra programmi, interruzioni di rete o operazioni di riavvio non portate a termine.

In assenza di verifica, i team agiscono sulla base di ipotesi anziché di fatti. È proprio questa differenza a distinguere un processo di applicazione delle patch ben consolidato da uno che crea un falso senso di sicurezza.

La possibilità di effettuare interrogazioni in tempo reale sull’intera flotta è ciò che rende la verifica a ciclo chiuso praticabile su larga scala. Anziché effettuare controlli a campione su una selezione di server e dare per scontato lo stato degli altri, i team possono verificare lo stato delle patch su ogni server gestito entro pochi minuti dalla distribuzione, con le installazioni non riuscite che vengono segnalate automaticamente per essere risolte.

La verifica post-implementazione fornisce risposta a tre domande:

• La patch è stata installata? Verifichi che l'aggiornamento sia stato registrato dal sistema operativo o dal gestore dei pacchetti e che rifletta lo stato previsto del pacchetto, del KB, della build o della versione.
• La correzione ha avuto effetto? Verifichi che i riavvii o i riavvii dei servizi richiesti siano stati completati e che la versione del kernel o del servizio in esecuzione rifletta lo stato corretto.
• La patch ha causato dei problemi? Verifichi i controlli di integrità e gli indicatori di livello di servizio (log, tassi di errore, latenza) e confermi i percorsi di rollback/failover qualora dovessero verificarsi problemi.

La verifica automatizzata consente di estendere questo processo a flotte di grandi dimensioni. Anziché effettuare controlli a campione su un gruppo di server, i team possono interrogare ogni singolo server in tempo reale per verificare lo stato delle patch. I server per i quali l'installazione non è andata a buon fine vengono contrassegnati per essere sottoposti a correzione. I server la cui installazione è andata a buon fine aggiornano i propri record nel database di gestione della configurazione (CMDB).

La verifica chiude il ciclo. Trasforma l’applicazione delle patch da un’attività di implementazione a un’attività di riduzione dei rischi con risultati misurabili.

Mantenere la preparazione alle verifiche di conformità delle patch dei server

I quadri normativi in materia di conformità, tra cui l’ PCI DSS, l’HIPAA e il DORA (Digital Operational Resilience Act dell’Unione Europea), impongono alle organizzazioni di documentare e dimostrare le proprie pratiche di gestione delle patch e delle vulnerabilità.

I revisori non si accontentano di sapere semplicemente che le patch sono state installate. Chiedono prove: registri di implementazione, rapporti sulla copertura, documentazione relativa alle eccezioni e tempistiche di risoluzione. Una politica di gestione delle patch documentata , che definisca ruoli, tempistiche, procedure di eccezione e percorsi di escalation, è spesso il primo documento richiesto dai revisori, e la sua assenza costituisce un riscontro ricorrente nelle verifiche di conformità.

La preparazione alla revisione contabile inizia con una tenuta accurata dei registri. Ogni distribuzione di patch genera record che rispondono alle seguenti domande:

• Quali server sono stati presi di mira?
• Quali patch sono state applicate?
• Quando è avvenuta la messa in servizio?
• Qual è stato il tasso di successo?
• Quali server hanno subito un guasto e quali misure correttive sono state adottate?
• Quali server sono stati esclusi e quali controlli compensativi sono previsti?

L’integrazione degli strumenti di applicazione delle patch con le piattaforme di gestione delle informazioni sulla sicurezza ( CMDB ) e di gestione del ciclo di vita dei servizi IT (ITSM) consente di centralizzare tali dati. Quando un revisore richiede informazioni sulla copertura delle patch sui server gestiti d PCI, la risposta viene fornita tramite una query anziché tramite una riconciliazione manuale su un foglio di calcolo.

La documentazione relativa alle eccezioni merita particolare attenzione. I revisori sono consapevoli del fatto che non tutti i server possono essere aggiornati immediatamente. Ciò che cercano sono prove del fatto che le eccezioni vengano monitorate, sottoposte a valutazione dei rischi e accompagnate da controlli compensativi.

Un server che non può essere aggiornato a causa di vincoli imposti dal fornitore potrebbe disporre di segmentazione della rete o di un monitoraggio avanzato come controlli compensativi.

In che modo “ Tanium ” supporta la gestione delle patch dei server

Tanium 'La piattaforma IT autonoma di considera la gestione delle patch dei server come un processo continuo e basato sui dati. Effettua l'interrogazione direttamente sugli endpoint anziché basarsi su istantanee del database o su cicli di scansione programmati; pertanto, le decisioni si basano su ciò che è vero in questo momento, non su ciò che era vero al momento dell'ultima scansione.

I team addetti alle operazioni IT e alla sicurezza possono ottenere, da un’unica console, una panoramica aggiornata su quali server non dispongano delle patch necessarie, quali siano pronti per l’applicazione delle patch e quali richiedano un rinvio, su Windows, Linux e macOS .

• Visibilità in tempo reale su endpoint : Stato aggiornato delle patch su richiesta per Windows, Linux e macOS, non risultati di scansioni periodiche
• Risk Priorità basata su: Dati relativi alle vulnerabilità combinati con EPSS, CISA KEV, criticità delle risorse e punteggi di affidabilità, al fine di concentrare gli sforzi laddove ciò consenta di ridurre maggiormente il rischio
• Punteggi di affidabilità (Windows ): Analisi predittiva dell’impatto delle implementazioni relative a Windows e, basata sui tassi di successo dell’installazione, sulla frequenza dei crash e sulle metriche delle prestazioni, prima del lancio su larga scala; i punteggi sono ricavati dai dati telemetrici di implementazione anonimizzati dei clienti partecipanti, in modo che il segnale rifletta il comportamento effettivo delle patch nel mondo reale e non si basi su ipotesi
• Implementazione progressiva basata su anelli: Implementazioni graduali che verificano i risultati rispetto a soglie di affidabilità prima di procedere alla scalabilità, con l’applicazione delle patch ai server critici per ultimi, in modo che i sistemi di produzione e quelli critici per l’azienda possano beneficiare della verifica effettuata negli anelli precedenti prima di essere interessati dal cambiamento
• Playbook di automazione gestiti: Flussi di lavoro in più fasi, basati su condizioni, con livelli di autorizzazione da parte degli operatori e tracciabilità completa
• Applicazione di patch a software di terze parti: Modelli integrati per l’applicazione di patch alle applicazioni e gli aggiornamenti di terze parti, senza dover reperire manualmente i pacchetti dai siti dei fornitori
• Tanium Guardian Threat Intelligence: Avvisi tempestivi e indicazioni mirate per la risoluzione di numerose vulnerabilità critiche e zero-day, supportati da Tanium VERT, con l’individuazione delle minacce emergenti e l’invio di azioni correttive specifiche direttamente alla console senza necessità di passare da uno strumento all’altro
• Convalida a ciclo chiuso: Verifica post-distribuzione dello stato delle patch su tutti gli endpoint gestiti, con individuazione rapida delle installazioni non andate a buon fine
• Valutazione della conformità: SCAP- e valutazioni basate su OVAL allineate ai controlli tecnici pertinenti a PCI, HIPAA, SOX e altri quadri normativi, con aggiornamenti quotidiani dei contenuti
• Reporting Per la preparazione agli audit: Report a livello organizzativo e di dispositivo con monitoraggio delle eccezioni e dashboard di conformità
• Integrazione ITSM: Flussi di lavoro di Patch collegati a ServiceNow e ad altri strumenti ITSM, con aggiornamenti automatici dello stato dei ticket
• Operazioni assistite dall’intelligenza artificiale: Interrogazioni in linguaggio naturale per la gestione dei dati, delle indagini e del software relativi all’ endpoint , con un processo di autorizzazione che prevede l’intervento umano (human-in-the-loop) per garantire che le azioni automatizzate siano controllate e verificabili

Le funzionalità e i risultati descritti si basano sulla documentazione relativa ai prodotti dell’ Tanium , su casi di studio dei clienti verificati e sull’utilizzo effettivo. I risultati effettivi possono variare a seconda dell'ambiente di implementazione, della configurazione e del grado di maturità organizzativa.

Risultati concreti: un'unica fonte attendibile per la conformità delle patch dei server

Prima dell’adozione di Tanium e , Honeywell non disponeva di un metodo affidabile per misurare la conformità in modo coerente tra i vari team: i reparti di sicurezza e operazioni IT monitoravano ciascuno metriche diverse e le divergenze sui dati erano all’ordine del giorno.

Tanium ha consentito a entrambe le squadre di avere accesso agli stessi dati, garantendo così la coerenza dei dati relativi alla conformità, indipendentemente dal fatto che provenissero dal reparto sicurezza o da quello delle operazioni IT. Tale coerenza ha consentito al team IT di Honeywell di fornire con sicurezza dati accurati sia ai dirigenti di alto livello che ai responsabili dei servizi.

[Legga il caso di studio]

«Prima di utilizzare Tanium, il nostro livello di conformità alle patch era basso. Ora, grazie a “ Tanium”, abbiamo superato la soglia del 90% di conformità alle patch per tre mesi consecutivi. È un dato significativo.”

Manish Chopra, direttore IT di Honeywell

Domande frequenti sulla gestione delle patch dei server

L’applicazione delle patch ai server comporta alcune difficoltà di coordinamento che le guide generiche sulla gestione delle patch spesso tralasciano. Di seguito sono riportate le domande più frequenti che i team aziendali pongono quando sviluppano o migliorano i programmi di applicazione delle patch ai server.

In che modo l’applicazione delle patch ai server differisce dall’applicazione delle patch all endpoint ?

I server eseguono in genere 24/7 carichi di lavoro con finestre di manutenzione ristrette, mentre gli endpoint possono essere riavviati durante i periodi di inattività degli utenti. I server presentano inoltre dipendenze più complesse, il che significa che un aggiornamento applicato a un server può influire sulle applicazioni in esecuzione su altri server.

L’impatto di una patch non riuscita su un server è solitamente più ampio rispetto a quello di una patch non riuscita su endpoint , il che modifica il modo in cui i team affrontano i test, la fase di staging e la pianificazione del rollback.

Per quanto tempo i server possono funzionare in sicurezza senza l’applicazione delle patch?

Non esiste una risposta valida per tutti. Le vulnerabilità critiche presenti nell’elenco KEV della CISA richiedono un’attenzione immediata, poiché gli autori degli attacchi le stanno sfruttando attivamente. Per quanto riguarda le altre vulnerabilità, i tempi dipendono da fattori quali l’esposizione del server, i controlli compensativi e i vincoli aziendali.

I requisiti di conformità variano a seconda del quadro normativo e del contesto di rischio. Per quanto riguarda i DSS ( PCI ), le organizzazioni in genere definiscono gli SLA relativi alle patch in base al rischio (fissando spesso un termine di circa 30 giorni per le vulnerabilità ad alto rischio e tempi più lunghi per i problemi a rischio inferiore), insieme a eccezioni documentate e controlli compensativi.

I team che superano i limiti previsti accumulano sia rischi per la sicurezza che riscontri di audit.

Cosa accade quando non è possibile applicare le patch a un server nei tempi previsti?

Si documenti l’eccezione, si valuti il rischio residuo e si attuino controlli compensativi. Le misure correttive potrebbero includere la segmentazione della rete per limitare l’esposizione, un monitoraggio rafforzato per Detect i tentativi di sfruttamento della vulnerabilità, oppure misure a livello di applicazione volte a mitigarne l’impatto. I revisori si aspettano di prendere visione di tale documentazione, unitamente a un piano per eventuali misure correttive.

In che modo i team gestiscono le patch che richiedono il riavvio dei server sempre attivi?

Le opzioni includono tecnologie di patching in tempo reale (disponibili per alcune distribuzioni Linux e aggiornamenti del kernel nell’ambito di specifiche distribuzioni e contratti di assistenza), il failover su server ridondanti durante la finestra di riavvio, oppure la pianificazione dei riavvii durante i periodi di traffico ridotto con notifica alle parti interessate.

L'approccio corretto dipende dal ruolo del server, dalla tolleranza dell'organizzazione nei confronti dei tempi di inattività e dall'eventuale presenza di ridondanza. Alcuni aggiornamenti di sicurezza richiedono semplicemente il riavvio del sistema o dei servizi per essere attivati, e tenere conto di questa realtà fa parte della prassi di applicazione delle patch ai server.

Una patch installata ma non applicata lascia comunque aperta la vulnerabilità. In pratica, il coordinamento dei riavvii rappresenta spesso il vero collo di bottiglia, non la distribuzione delle patch in sé, soprattutto nel caso di sistemi in cluster e servizi critici per l’azienda.

Per i servizi di produzione, i piani di applicazione delle patch dovrebbero inoltre includere criteri di rollback e un percorso di ripristino, quali snapshot, ove opportuno, oppure il failover in ambienti clusterizzati e ad alta disponibilità (HA).

L'applicazione delle patch ai server su scala aziendale richiede ben più di una semplice lista di controllo. Ciò richiede visibilità in tempo reale, definizione delle priorità basata sul rischio, implementazione graduale e verifica che le patch abbiano effettivamente ridotto l’esposizione.
Tanium riunisce queste funzionalità in un’unica piattaforma, aiutando i team IT e di sicurezza ad applicare le patch ai server con sicurezza, anziché basarsi su supposizioni. Prenoti una demo gratuita all'indirizzo per vedere oggi stesso Tanium in azione.