Ivanti Blog: Gestione delle patch

Per elevare la maturità della sicurezza, ripensate le capacità di remediation delle vulnerabilità

Thu, 28 May 2026 14:00:05 Z

I team di sicurezza sono sommersi dalle vulnerabilità. Parliamo di decine di migliaia di rilevamenti ogni trimestre. Centinaia di migliaia nelle organizzazioni più grandi. Gli ambienti IT di oggi non hanno confini e si estendono su ogni piattaforma OS. Gestire e proteggere questo patrimonio in modo lineare non è più sostenibile, così come non lo è un processo di remediation delle vulnerabilità che tratta ogni correzione come un’attività semplice e a basso impatto.

La prioritizzazione basata sul rischio aiuta a fare chiarezza in questo rumore introducendo il contesto delle minacce e il contesto di business nel processo di remediation delle vulnerabilità. È stato un passo avanti significativo. Ma molte organizzazioni che hanno adottato la prioritizzazione basata sul rischio continuano a non rispettare gli SLA, a generare attriti con l’IT e a vedere accumularsi eccezioni più rapidamente delle remediation.

Sapere cosa correggere per primo è solo una parte dell’equazione.

La parte più complessa, e quella che molti programmi ancora non hanno, è comprendere quale sarà l’impatto reale di quella correzione. E, soprattutto, come accelerare la remediation, passando da una cadenza mensile a un processo continuo, bilanciando rischio e impatto.

Questa è la remediation bilanciata a livello operativo: la pratica di valutare l’impatto reale di una correzione prima di implementarla. È il tassello critico mancante in molti programmi di remediation delle vulnerabilità e uno degli indicatori più chiari della maturità nella gestione dell’esposizione. Il Modello di maturità della gestione dell’esposizione di Ivanti la identifica come una delle sei capacità fondamentali che distinguono i programmi di sicurezza maturi da quelli reattivi.

Che cos’è la remediation bilanciata a livello operativo?

Il modello di maturità la definisce in modo semplice: la capacità di correggere o mitigare le esposizioni in modo efficace e praticabile. L’urgenza della sicurezza viene bilanciata con le realtà dell’IT, come la disponibilità dei sistemi, il test delle patch e la continuità operativa.

In pratica, si riduce a un’equazione: rischio di sicurezza più impatto reale uguale decisione di remediation informata. Identificare le esposizioni non ha valore se non è possibile porvi rimedio. E una remediation che causa downtime non pianificato, compromette i sistemi di produzione o attiva rollback non ha ridotto il rischio: lo ha solo spostato.

Il percorso di maturità della remediation delle vulnerabilità: da reattiva a strategica

Fase 1: gestione tradizionale delle vulnerabilità (l’era scan-and-patch)

È da qui che è iniziata la remediation delle vulnerabilità per molte organizzazioni, e dove molte si trovano ancora. La prioritizzazione è guidata dal CVSS e segue il criterio first-in-first-out. Lo scanner indica “Hai 10.000 CVE” senza alcun contesto su quali siano davvero rilevanti.

Le eccezioni restano non documentate. Le scansioni delle vulnerabilità e i workflow di remediation risiedono in strumenti separati, con un’integrazione minima.

Il risultato è una modalità reattiva: inseguire l’ultima divulgazione di alto profilo invece di affrontare ciò che rappresenta il rischio maggiore per l’ambiente.

Fase 2: prioritizzazione delle vulnerabilità basata sul rischio (aggiungere contesto)

La prioritizzazione basata sul rischio ha introdotto due domande migliori: “Questa vulnerabilità viene sfruttata attivamente?” e “Quanto è critico l’asset interessato?”. Combinare la gravità con la threat intelligence e la criticità degli asset ha offerto ai team di sicurezza un focus più preciso per le attività di remediation delle vulnerabilità. L’intelligence sulle vulnerabilità basata sull’AI e il punteggio di affidabilità delle patch hanno accelerato ulteriormente questo processo riducendo il carico di analisi manuale che in passato costringeva i team di sicurezza a prendere decisioni di prioritizzazione con dati incompleti.

Ma manca ancora un tassello. La prioritizzazione basata sul rischio indica alla sicurezza cosa correggere. Non dice nulla su ciò che l’IT deve mantenere in funzione. La collaborazione tra i due team avviene ancora spesso caso per caso, e l’impatto della remediation sulle operazioni IT resta un aspetto secondario o, più spesso, un freno che impedisce alle organizzazioni di accelerare le attività di remediation.

Fase 3: il tassello mancante — remediation bilanciata a livello operativo

Per le organizzazioni che hanno sviluppato la maturità necessaria a comprendere i rischi reali di un’esposizione, la domanda successiva è: “Quale sarà l’impatto di questa correzione sui sistemi che dobbiamo mantenere in funzione, e possiamo permetterci di lasciarla esposta?”

Quando la remediation delle vulnerabilità viene imposta senza considerare gli effetti a valle, il risultato è downtime, resistenza da parte dell’IT e un backlog crescente di eccezioni che compromettono proprio gli obiettivi di sicurezza alla base dell’urgenza.

Il report State of Cybersecurity 2026 di Ivanti ha rilevato che il 48% dei professionisti della sicurezza afferma che i team IT non rispondono con urgenza alle problematiche di cybersecurity, mentre il 40% ritiene che l’IT non comprenda la tolleranza al rischio della propria organizzazione. È ciò che accade quando sicurezza e IT operano con priorità diverse e senza un modo condiviso per risolverle.

I programmi più maturi affrontano questo aspetto non solo attraverso l’allineamento dei processi, ma anche tramite l’automazione, che elimina i passaggi manuali in cui si accumulano gli attriti. Le capacità automatizzate di self-healing possono rilevare, diagnosticare e risolvere proattivamente i problemi di endpoint e di igiene informatica. Questo riduce fin dall’inizio il volume di vulnerabilità che richiedono triage manuale. Quando la remediation è integrata nel funzionamento degli endpoint, anziché aggiunta a posteriori, il divario tra l’urgenza della sicurezza e la capacità dell’IT si riduce naturalmente.

L’indicatore di maturità, in questo caso, è chiaro: KPI condivisi tra sicurezza e IT, processi di eccezione documentati e un sistema di monitoraggio della remediation delle vulnerabilità che tenga conto sia della riduzione del rischio sia della continuità operativa. Per ottenere tutto questo in modo continuativo, IT e sicurezza devono operare a partire da dati e workflow condivisi.

Quando la visibilità sugli asset, l’aggregazione delle esposizioni, la prioritizzazione basata sul rischio e la remediation operano su una piattaforma unificata, l’allineamento richiesto dalla Fase 3 diventa una proprietà strutturale del sistema, anziché un risultato culturale ottenuto con grande fatica.

In che modo la remediation bilanciata a livello operativo si differenzia dalla prioritizzazione basata sul rischio

Il modo più semplice per vedere la progressione è osservare le domande a cui ciascun approccio può rispondere.

Approccio	Domande a cui risponde	Cosa manca
VM tradizionale	Quante vulnerabilità esistono?	Contesto e prioritizzazione
Prioritizzazione basata sul rischio	Quali vulnerabilità rappresentano il rischio maggiore?	Fattibilità e impatto operativi
Remediation bilanciata a livello operativo	Quali vulnerabilità dovremmo correggere per prime, considerando sia il rischio di sicurezza sia i vincoli operativi? In che modo l’automazione può garantire che tali correzioni vengano eseguite in modo efficiente e senza interruzioni?	Approccio più completo

Questo approccio aggiunge un livello di contesto alla gestione della remediation delle vulnerabilità: requisiti di test delle patch, dipendenze dei sistemi, finestre di manutenzione, potenziale downtime e capacità di rollback. Questi elementi determinano se una correzione regge o se crea nuovi problemi che richiedono un rollback.

Perché la remediation bilanciata a livello operativo è centrale nella gestione dell’esposizione

Il modello di maturità identifica sei capacità fondamentali: visibilità sugli asset, importanza degli asset, valutazione delle vulnerabilità nel mondo reale, prioritizzazione delle vulnerabilità guidata dal business, remediation bilanciata a livello operativo e integrazione di dati/workflow.

Tra queste, la remediation bilanciata a livello operativo è il livello di esecuzione che rende tutto il resto attuabile.

Senza di essa, la gestione dell’esposizione resta teorica. È possibile creare inventari degli asset perfetti, assegnare punteggi a ogni vulnerabilità con precisione e produrre dashboard dall’aspetto convincente.

Ma se il processo di remediation delle vulnerabilità resta separato, crea attrito tra sicurezza e IT, i rischi noti si accumulano, le patch vengono ritardate e le metriche su quelle dashboard smettono di riflettere la reale postura di rischio.

La progressione della maturità va dalla prioritizzazione ad hoc (Fase 1), alla collaborazione caso per caso (Fase 2), fino alla remediation guidata da KPI condivisi (Fase 3) e, infine, a retrospettive sottoposte ad audit con un ciclo di miglioramento continuo (Fase 4). Non tutte le organizzazioni devono raggiungere la Fase 4 in ogni capacità. Ma il passaggio da una remediation ad hoc a una remediation condivisa e guidata dai KPI è il punto in cui si ottengono i benefici reali.

Il business case: bilanciare sicurezza e obiettivi operativi

I costi nascosti della remediation senza contesto operativo

Quando la remediation delle vulnerabilità è guidata esclusivamente dall’urgenza della sicurezza, i costi si accumulano in modi che restano invisibili finché non diventano sistemici.

Il downtime non pianificato è il costo più evidente: sistemi business-critical messi offline senza un’adeguata valutazione dell’impatto. Ma gli effetti a valle sono altrettanto dannosi.

I team IT creano soluzioni alternative quando le imposizioni della sicurezza sono impraticabili, generando processi ombra che aumentano il rischio invece di ridurlo. La stanchezza da eccezioni prende piede quando le eccezioni superano i casi conformi, rendendo gli SLA privi di significato. E la fiducia tra sicurezza e IT si erode quando ciascuna parte vede l’altra come avventata o ostruzionista.

La ricerca di Ivanti conferma quanto sia diffuso questo attrito. Il 39% dei professionisti della cybersecurity afferma di avere difficoltà a prioritizzare la remediation del rischio e la distribuzione delle patch, mentre il 35% segnala difficoltà nel mantenere la conformità delle patch.

Nel frattempo, solo il 60% utilizza l’analisi dell’impatto sul business per orientare la prioritizzazione del rischio, e appena il 51% utilizza un punteggio di esposizione alla cybersecurity o un indice basato sul rischio.

Molti si affidano ancora a metriche di processo, come il tempo medio di remediation o la percentuale di esposizioni risolte, che possono apparire positive se considerate isolatamente ma dicono poco sul fatto che il processo di remediation delle vulnerabilità stia effettivamente migliorando la postura di rischio.

Il ROI della remediation automatizzata delle vulnerabilità bilanciata a livello operativo

Quando le organizzazioni compiono questo passaggio, i risultati emergono rapidamente. I KPI condivisi favoriscono tempistiche di remediation realistiche, che a loro volta migliorano la conformità agli SLA. Il tempo mediano di remediation diminuisce quando le barriere alla distribuzione sono previste, anziché scoperte a rollout già avviato.

Le correzioni durano perché tengono conto delle dipendenze dei sistemi e delle finestre di manutenzione, invece di creare nuovi problemi che richiedono un rollback. La distribuzione ad anelli è un buon esempio: le patch vengono distribuite a gruppi progressivamente più ampi e convalidate in ogni fase prima dell’espansione. È questo che rende praticabile la remediation bilanciata.

Combinati con workflow automatizzati che gestiscono correlazione, triage e orchestrazione della distribuzione, questi meccanismi trasformano la remediation bilanciata da concetto a sistema operativo continuo. Quando la piattaforma gestisce la complessità operativa, i team di sicurezza dedicano meno tempo alla gestione del processo di remediation e più tempo alla convalida dei risultati.

Le organizzazioni alla Fase 3 o alla Fase 4 di maturità nel modello Ivanti monitorano la remediation delle vulnerabilità con metriche che riflettono sia i risultati di sicurezza sia quelli operativi:

SLA suddivisi per vulnerabilità sfruttate note rispetto alle severità tradizionali
Tempo mediano di remediation (MTTR) per le vulnerabilità sfruttate
Percentuale di richieste di eccezione esaminate congiuntamente da sicurezza e IT
Riduzione delle eccezioni ricorrenti nel tempo

Il valore strategico va oltre. Quando la gestione della remediation delle vulnerabilità tiene conto di ciò che l’IT deve mantenere in funzione, la sicurezza smette di essere percepita come un ostacolo e inizia a operare come abilitatore del business. È questo cambiamento a sbloccare investimenti sostenuti e supporto esecutivo per la gestione dell’esposizione.

Dalla prioritizzazione all’esecuzione: colmare il divario

La prioritizzazione delle vulnerabilità basata sul rischio è stata un’evoluzione necessaria. Ma ha risolto solo metà del problema. Sapere cosa correggere per primo ha un valore limitato se l’atto stesso di correggerlo genera downtime, resistenze o un accumulo crescente di eccezioni non documentate.

La remediation bilanciata a livello operativo colma il divario facendo lavorare sicurezza e IT sulla base dello stesso playbook. Questo si traduce in KPI condivisi, eccezioni chiaramente definite e finestre di manutenzione che proteggono la continuità operativa. Significa anche automatizzare i workflow di remediation in grado di individuare ed evitare potenziali downtime prima che diventino un problema.

Con prioritizzazione, generazione di insight e orchestrazione, la remediation può tenere il passo con l’ambiente invece di restare indietro. E con una piattaforma unificata che collega i dati degli endpoint e della sicurezza, i team non combattono contro i silos: si muovono in modo sincronizzato.

Per un approfondimento su come valutare la maturità attuale della vostra organizzazione e costruire un piano di crescita mirato, consultate il Modello di maturità della gestione dell’esposizione di Ivanti.

Siamo nell’apocalisse delle patch. Ecco perché queste tre scuse IT non funzioneranno più.

Wed, 29 Apr 2026 14:00:07 Z

Il 7 aprile, Anthropic ha annunciato che il suo modello Claude Mythos Preview aveva identificato autonomamente migliaia di vulnerabilità zero-day ad alta gravità e critiche in tutti i principali sistemi operativi e browser web. Oltre il 99% non era stato corretto con patch il giorno della divulgazione.

Due settimane dopo, il 21 aprile, Mozilla ha dichiarato di aver utilizzato lo stesso modello per individuare e correggere con patch 271 vulnerabilità nell’ultima release di Firefox. La valutazione di Mozilla: “Finora non abbiamo trovato alcuna categoria o complessità di vulnerabilità che gli esseri umani possano individuare e che questo modello non sia in grado di trovare”.

271 è solo la prima ondata. Chrome, Edge, Windows, macOS, Linux, FreeBSD: la falla di esecuzione di codice da remoto vecchia di 17 anni in FreeBSD divulgata dal red team di Anthropic (CVE-2026-4747) è un primo esempio di ciò che sta arrivando. Ogni vendor nell’ambito del Project Glasswing di Anthropic è nella posizione di rilasciare correzioni a un ritmo mai visto prima nel settore. Tutte queste correzioni diventano CVE pubbliche con patch disponibili, e finiscono tutte nello stesso posto: il tuo ambiente.

Anche la storia del contenimento presenta una crepa. Il 21 aprile, Bloomberg ha riferito che un gruppo collegato a Discord ha ottenuto accesso non autorizzato a Mythos tramite l’ambiente di un vendor di terze parti. Anthropic afferma che l’attività non si è estesa oltre quel vendor. Indipendentemente dal fatto che capacità simili siano già o meno nelle mani degli attaccanti, il margine di manovra difensivo è più breve di quanto lasciasse intendere l’annuncio del 7 aprile.

Mythos è arrivato in un mondo che stava già andando in questa direzione. Il Global Threat Report 2026 di CrowdStrike ha documentato nel 2025 un aumento dell’89% su base annua degli attacchi abilitati dall’AI. Questa tendenza era precedente a Mythos.

Chiamiamola apocalisse delle patch. Quella operativa, concreta: il volume e la cadenza delle CVE pubbliche con patch disponibili stanno per superare il modo in cui oggi lavora la maggior parte dei team IT e di sicurezza.

Il NIST sta già subendo gli effetti dell’apocalisse delle patch. Ad aprile, l’agenzia ha annunciato un importante cambiamento nelle operazioni del National Vulnerability Database (NVD) in risposta a un aumento del 263% delle segnalazioni. Il NIST non fornirà più un arricchimento dettagliato per tutte le vulnerabilità inviate e lo farà invece solo per quelle che soddisfano criteri di rischio elevato, come le vulnerabilità presenti nel catalogo CISA Known Exploited Vulnerabilities o quelle che interessano software governativo critico. Il NIST farà affidamento sulle CVE Numbering Authorities (CNA), come Ivanti, anziché condurre una propria valutazione indipendente.

Dall’annuncio, ho sentito tre versioni della stessa risposta da clienti e colleghi. Tutte e tre sono varianti di un programma pensato per un mondo più lento.

“Abbiamo uno scanner di vulnerabilità”

Qualys, Rapid7 e Tenable svolgono bene l’attività di discovery delle vulnerabilità. Gli scanner individuano, segnalano, assegnano punteggi ed elencano. Distribuzione, verifica, gestione dei riavvii e rollback sono fuori dal loro ambito. Quel lavoro deve comunque essere svolto da qualche parte. Nella maggior parte dei programmi avviene in uno strumento separato, con un team separato, seguendo una cadenza separata.

Con la finestra di exploit ormai misurata in ore e la coda di Glasswing destinata quasi a raddoppiare il backlog, uno scanner che produce 587 vulnerabilità critiche e passa l’elenco a un team umano diventa una responsabilità. La scelta pratica è collegare lo scanner che già possiedi a un motore di remediation in grado di agire automaticamente sui risultati. Una piattaforma di gestione autonoma degli endpoint (AEM), con distribuzione ad anelli e rollback, e intelligence sulle vulnerabilità per fornire un contesto basato sul rischio a supporto di decisioni di remediation efficienti, così l’elenco si riduce senza che siano gli esseri umani a prendere ogni decisione.

“Gestiamo le approvazioni tramite il nostro sistema di ticketing”

A proposito di esseri umani che devono prendere decisioni… I lunghi processi di approvazione lineari rallenteranno in modo significativo la remediation. Quand’è stata l’ultima volta che hai dovuto decidere se distribuire l’ultimo aggiornamento del sistema operativo o del browser?

Le organizzazioni sanno già che distribuiranno questi aggiornamenti. Spesso il processo di approvazione è dovuto a complesse dinamiche interne e a un disallineamento sugli obiettivi di sicurezza. Il risultato? Un processo molto lineare che richiede lo scanner di vulnerabilità citato in precedenza, un analista che approvi ciò che sai già debba essere fatto, ticket inviati ai responsabili di business per l’approvazione e lasciati nelle caselle di posta in attesa, e in definitiva tempo prezioso sprecato per una decisione che era sostanzialmente già chiara e non doveva essere presa.

Il passaggio del mercato all’Exposure Management affronta questo processo in modo molto diverso, concentrandosi sulla definizione della propensione al rischio di un’organizzazione e sul monitoraggio della postura di rischio. La prossima volta che verrà rilasciato un aggiornamento del sistema operativo Windows, saprai già che lo distribuirai, con quale pianificazione lo farai e con quali SLA e metriche di conformità misurerai il successo. Quello che vuoi davvero sapere è:

1. Devo muovermi più rapidamente perché l’aggiornamento include vulnerabilità note sfruttate attivamente?

Oppure

2. L’aggiornamento sta impattando le operazioni e dobbiamo rallentare (per fortuna la piattaforma di Autonomous Endpoint Management include la distribuzione ad anelli con rollback)?

“Abbiamo Intune”

Microsoft Intune presenta due limiti di ambito che qui contano.

In primo luogo, gestisce solo i dispositivi registrati. Gli endpoint non registrati e non gestiti — server, laptop di collaboratori esterni, shadow IT, dispositivi edge trascurati — restano completamente fuori dalla sua visibilità. Nei periodi di aumento del volume di vulnerabilità, questi punti ciechi si moltiplicano più rapidamente di quanto i team possano gestire manualmente.

In secondo luogo, sebbene Intune semplifichi la distribuzione e gli aggiornamenti delle applicazioni, la copertura delle applicazioni di terze parti e la profondità della prioritizzazione sono più limitate di quanto la maggior parte degli amministratori immagini. Intune può dirti cosa non è aggiornato, ma non cosa aumenta davvero la tua esposizione––costringendo i team ad applicare patch a tutto in modo reattivo, oppure basandosi su ipotesi quando il tempo è poco.

La maggior parte degli ambienti enterprise non è esclusivamente Windows, completamente registrata o basata su uno stack applicativo ridotto e omogeneo. Quando le divulgazioni di vulnerabilità aumentano improvvisamente, instradare il patching lascia lacune e si trasforma in un rischio sistemico.

Mantieni Intune. Affiancalo a un livello di discovery e remediation che trovi gli asset che Intune non riesce a vedere, dia priorità alle vulnerabilità più importanti e applichi le patch con fiducia nelle applicazioni che Intune non copre.

Cosa fare

L’automazione è il modello operativo. Deve essere integrata nel workflow.

I professionisti conoscono questo principio da tempo. Si manifesta in tre aree:

Triage continuo. Le vulnerabilità note sfruttate attivamente possono seguire un percorso di risposta zero-day, soprattutto nelle aree meno sicure dell’organizzazione, come i sistemi degli utenti finali. Inoltre, definisci applicazioni specifiche, come browser e app di telecomunicazione, da aggiornare su un percorso prioritario controllato settimanalmente o anche quotidianamente. Tutto il resto può attendere la finestra di manutenzione ordinaria.
Distribuzione ad anelli con rollback automatizzato. Anello di test, anello early adopter, produzione estesa, sistemi mission-critical. La sequenza è poco entusiasmante, ma funziona per la maggior parte delle attività di manutenzione. Ciò che è cambiato è che alcuni aggiornamenti dovranno essere compressi per rientrare nella finestra di exploit, anziché attendere la manutenzione mensile. L’anello di test deve essere automatizzato e strumentato: una checklist umana non può muoversi a quella velocità.
Verifica a ciclo chiuso. La patch non è distribuita finché non viene verificata l’installazione sull’endpoint, e la CVE non viene chiusa finché una nuova scansione non lo conferma. La maggior parte dei team salta questo passaggio, ed è per questo che la prova di conformità diventa un’emergenza la settimana prima dell’audit. È per questo che questa settimana abbiamo rilasciato la conformità continua nella nostra piattaforma: così le evidenze di conformità vengono prodotte in modo continuo e automatico man mano che le patch vengono distribuite, mentre l’automazione gestisce le decisioni di prioritizzazione per cui la maggior parte dei team non ha capacità disponibile.

Le 271 vulnerabilità di Firefox individuate da Mozilla sono un’anticipazione. Ogni principale vendor software sotto Glasswing sta per iniziare a correggere più vulnerabilità e a un ritmo accelerato, e gli attaccanti con la stessa classe di capacità cercheranno esattamente quelle aperture ogni volta che avranno accesso a un modello simile. La conseguente corsa agli armamenti basata sull’AI avrà un effetto diretto sul numero e sulla frequenza degli aggiornamenti che le organizzazioni dovranno gestire con attività di remediation, e a un ritmo accelerato. L’automazione è ciò che consente a un programma di reggere. I team che ancora applicano patch solo su base mensile si troveranno ad affrontare un periodo difficile.

Se gestisci un programma IT o di sicurezza, vale la pena fare ora un’autovalutazione. Prendi l’ultima patch critica che hai distribuito. Ancora meglio: se uno zero-day uscisse di venerdì, riusciresti a risolverlo entro lunedì? Misura il tempo dalla pubblicazione della CVE all’installazione verificata sull’ultimo endpoint. Se quel numero si misura in settimane, l’apocalisse delle patch ti raggiungerà.

In che modo l’automazione basata sull’AI risolve i silos nella gestione delle patch

Thu, 02 Apr 2026 15:37:11 Z

"Vediamo 10.000 vulnerabilità critiche!"

"Abbiamo installato tutte le patch la scorsa settimana!"

Questa conversazione avviene ogni giorno nei reparti IT aziendali. I team di sicurezza presentano dashboard piene di avvisi rossi. I team IT mostrano report di distribuzione con un successo del 98%. Entrambi i team osservano dati reali. Entrambi hanno pienamente ragione. Ed entrambi sono del tutto all’oscuro di ciò che accade realmente nell’ambiente endpoint.

Non è un problema di persone: i vostri team non sono incompetenti. Non è un problema di processo: i vostri workflow non sono compromessi. È un problema tecnologico: state chiedendo a due team di gestire lo stesso rischio usando sistemi che mostrano loro realtà diverse.

Ai team di sicurezza viene fornita una versione della realtà tramite scanner di vulnerabilità e threat intelligence. Nel frattempo, i team IT vedono le cose in modo diverso quando consultano i report sulla gestione dei dispositivi e sulla distribuzione delle patch.

L’aspetto complesso è che entrambe le visioni possono essere corrette se considerate separatamente e comunque risultare fuorvianti nella pratica. È così che si arriva al consueto stallo: la sicurezza segnala migliaia di vulnerabilità critiche; l’IT riferisce che le patch sono state distribuite correttamente. La disconnessione nasce nello spazio tra questi sistemi.

Perché IT e sicurezza non sono allineati sul patching

La maggior parte delle organizzazioni affronta il disallineamento sul patching tra IT e sicurezza migliorando la comunicazione tra IT e sicurezza. Programmano più riunioni. Creano percorsi di escalation. Implementano SLA. E sei mesi dopo, si ritrovano a discutere esattamente dello stesso problema, con slide PowerPoint migliori.

Ecco ciò che nessuno vuole ammettere: non si può risolvere un problema di frammentazione dei dati semplicemente collaborando di più. Quando IT e sicurezza lavorano a partire da inventari fondamentalmente diversi di ciò che esiste, di ciò che è vulnerabile e di ciò che è stato corretto, aggiungere ulteriore coordinamento non fa che rallentare un processo già inefficace.

Ecco perché la stessa conversazione si ripete continuamente all’interno di molte organizzazioni. Entrambi i team sono sicuri dei propri dati ed entrambi hanno “ragione” nel contesto ristretto degli strumenti su cui fanno affidamento.

Ed è proprio questo il problema. Anche se entrambe le visioni sono “corrette”, nessuna riflette l’intero ciclo di vita del rischio. I dati sulle vulnerabilità non indicano sempre se i dispositivi interessati siano gestiti o raggiungibili. I report sulle patch non tengono sempre conto degli endpoint non gestiti, classificati in modo errato o scoperti di recente che hanno ancora accesso alle risorse aziendali. Ciò che manca è una risposta affidabile all’unica domanda che conta davvero: quali endpoint sono esposti in questo momento?

I silos tecnologici creano realtà contrastanti

La maggior parte delle aziende gestisce gli endpoint attraverso un insieme eterogeneo di sistemi evoluti in modo indipendente nel tempo, ognuno dei quali acquisisce solo un frammento della realtà.

Un sistema può evidenziare un’esposizione critica senza sapere se il dispositivo sia gestito. Un altro può confermare una remediation riuscita senza considerare endpoint scoperti di recente o classificati in modo errato che hanno ancora accesso. Il risultato? Nessun modo affidabile per tracciare il rischio dal rilevamento alla distribuzione fino all’esposizione effettiva.

Considerate questo dato: secondo il Securing the Borderless Digital Landscape Report di Ivanti, un’organizzazione media gestisce solo il 60% dei propri dispositivi edge. Ciò significa che il 40% dei potenziali punti di ingresso esiste al di fuori della visibilità dell’IT e dei relativi workflow di patching. La sicurezza li vede. L’IT no. Questo è il vostro divario di vulnerabilità. Senza questa continuità, i team sono costretti a riconciliare manualmente viste parziali. I dati vengono discussi invece di diventare azione.

Viste dei dati diverse generano attrito

Immaginate che sia lunedì mattina: la sicurezza scopre una zero-day critica in un client VPN ampiamente utilizzato. Invia all’IT un avviso urgente: "Rilevati 30.000 endpoint vulnerabili: applicare subito le patch."

L’IT controlla la console di distribuzione: "Client VPN già aggiornato su 28.000 dispositivi giovedì scorso."

Entrambe le affermazioni sono vere. La sicurezza esegue la scansione dell’intera rete, inclusi laptop di appaltatori, dispositivi BYOD e sistemi che si sono connessi brevemente alla VPN ma non sono gestiti dall’IT. L’IT ha installato le patch su tutto ciò che era presente nel proprio inventario dei dispositivi.

Nel frattempo, 2.000 endpoint realmente vulnerabili rimangono esposti perché esistono nella vista della sicurezza ma non in quella dell’IT. La patch che avrebbe dovuto richiedere 24 ore ora richiede tre giorni di riconciliazione manuale.

Quando IT e sicurezza operano da fonti di dati diverse, le priorità di gestione delle vulnerabilità disallineate sono inevitabili. I team di sicurezza si concentrano sul numero di vulnerabilità, sui punteggi di gravità e sull’intelligence sugli exploit. I team IT danno priorità al successo della distribuzione, alla stabilità dei sistemi e all’impatto sugli utenti. Entrambe le prospettive sono necessarie, ma senza un quadro di riferimento condiviso spingono in direzioni diverse.

Ciò che ne deriva non è solo tensione; è paralisi decisionale. La remediation rallenta mentre i team riconciliano gli inventari, convalidano i risultati e discutono sull’ambito. Le vulnerabilità rimangono aperte più a lungo del dovuto, non perché le patch non siano disponibili, ma perché non esiste un’unica vista che colleghi rilevamento, distribuzione ed esposizione.

Il rischio delle priorità di patching disallineate

Il disallineamento rallenta la collaborazione, ma soprattutto crea un rischio misurabile che va ben oltre l’attrito interno.

La ricerca di Ivanti sull’Autonomous Endpoint Management riflette questa sfida nella pratica:

Il 38% dei professionisti IT segnala difficoltà nel monitorare lo stato delle patch.
Il 35% fatica a rispettare le tempistiche di remediation a causa di una visibilità incompleta sugli endpoint.

Quando le vulnerabilità rimangono aperte più a lungo del necessario, la finestra di esposizione aumenta. Gli aggressori non aspettano. Il catalogo CISA KEV rivela una verità difficile da ignorare: il 30% delle vulnerabilità attualmente sfruttate attivamente è stato inizialmente divulgato più di cinque anni fa.

Questo non è un problema di patching; è un problema di visibilità. Le organizzazioni non stanno ignorando le patch disponibili; non individuano gli endpoint che ne hanno ancora bisogno.

Finestre di esposizione prolungate e rischio di violazione

La frammentazione estende le finestre di esposizione in modi poco evidenti. I dispositivi mai registrati nelle piattaforme di gestione, come il BYOD shadow, i dispositivi non protetti degli appaltatori o gli endpoint remoti al di fuori del perimetro tradizionale, spesso passano inosservati.

Una ricerca di Ivanti mostra che solo un datore di lavoro su tre ha implementato l’accesso di rete zero trust per i lavoratori da remoto, lasciando lacune significative nella visibilità degli ambienti distribuiti. Gli endpoint scoperti di recente compaiono dopo la generazione dei report sulle patch. I sistemi escono dalla conformità tra un ciclo di scansione e l’altro. Ogni ritardo amplifica il rischio, estendendo il tempo a disposizione degli aggressori per trasformare vulnerabilità note in armi.

Problemi comuni post-patch e sovraccarico dei ticket IT

Anche quando le patch vengono distribuite nei tempi previsti, il patching manuale spesso crea problemi a valle. Aggiornamenti non riusciti, agenti malfunzionanti, problemi di prestazioni e riavvii imprevisti generano ticket di supporto e interventi di emergenza. Ciò che nasce come attività di sicurezza si trasforma rapidamente in un onere operativo.

I team IT dedicano tempo a risolvere guasti prevedibili invece di migliorare la postura degli endpoint. I team di sicurezza vedono i ritardi come rischi non risolti. Gli utenti associano il patching a interruzioni. Questo attrito persiste tra i team, anche quando i loro obiettivi sono allineati.

Trasformare la gestione delle patch con la gestione autonoma degli endpoint

AI e automazione affrontano le disconnessioni fondamentali nella gestione delle patch unificando la visibilità e riducendo il coordinamento manuale. Quando individuazione degli endpoint, dati sulle vulnerabilità, integrità dei dispositivi e stato delle patch vengono correlati in una vista unificata, i team IT e di sicurezza possono lavorare sugli stessi fatti invece di riconciliare dati parziali tra strumenti diversi.

Gestione autonoma degli endpoint (AEM) porta chiarezza nella complessità utilizzando intelligence basata sull’AI e automazione per offrire a IT e sicurezza una vista unica e aggiornata continuamente degli endpoint, della loro integrità e della loro esposizione.

Come l’AI migliora le decisioni di patching

L’AI migliora le decisioni di patching assegnando priorità alle vulnerabilità in base al rischio reale, non solo ai punteggi di gravità. Tenendo conto dell’attività di exploit, della criticità degli asset e del contesto di esposizione, i team possono allinearsi su cosa correggere per primo e concentrare gli sforzi dove ridurranno il rischio più rapidamente.

Con la gestione autonoma degli endpoint, lo stesso scenario del lunedì mattina si svolge in modo diverso:

La vulnerabilità viene rilevata e l’AI la confronta immediatamente con un inventario unificato degli endpoint. Identifica 1.560 dispositivi che eseguono la versione vulnerabile, inclusi 217 dispositivi precedentemente non gestiti.

I workflow automatizzati per le patch eseguono simultaneamente queste attività: registrano i dispositivi non gestiti e assegnano priorità al patching in base al rischio di esposizione e alla criticità degli asset. Quindi pianificano la distribuzione durante le finestre di utilizzo ridotto e avviano il rollout per anelli.

Quando il team di sicurezza invia l’avviso, l’IT dispone già di una dashboard in tempo reale che mostra la remediation in corso — con lo stesso conteggio dei dispositivi, gli stessi dati di esposizione e la stessa logica di prioritizzazione. Nessuna riconciliazione necessaria.

Come l’automazione accelera la remediation

L’automazione trasforma quindi queste decisioni in azione. I workflow delle patch possono essere orchestrati end-to-end: identificazione dei dispositivi interessati, distribuzione degli aggiornamenti e convalida della remediation senza interventi manuali continui.

La pianificazione intelligente delle patch basata sull’AI riduce al minimo l’impatto sugli utenti allineando le distribuzioni ai modelli di utilizzo dei dispositivi, alle finestre di manutenzione e ai vincoli operativi. I rollout per anelli consentono di convalidare le patch su gruppi più piccoli prima di una distribuzione più ampia, riducendo le interruzioni e accelerando la remediation. Il risultato è un patching più rapido, meno downtime e un processo più prevedibile per entrambi i team.

I workflow di autoriparazione rilevano e risolvono automaticamente problemi comuni, come il riavvio dei servizi, la reinstallazione degli agenti o la correzione di configurazioni errate. Questi workflow prevengono incidenti evitabili prima che si trasformino in ticket di supporto.

Dalle discussioni sui dati a un’intelligence unificata e a una visibilità condivisa

Le piattaforme basate sull’AI unificano la visibilità sugli endpoint correlando dati di individuazione, contesto delle vulnerabilità, integrità dei dispositivi e stato delle patch in un unico record endpoint, con registrazione e controlli di accesso che garantiscono che i dispositivi siano costantemente individuati e gestiti durante tutto il loro ciclo di vita. I team IT e di sicurezza vedono gli stessi dispositivi, la stessa esposizione e lo stesso stato di remediation in tempo reale.

Questa intelligence unificata elimina le discussioni su quali dati siano corretti e le sostituisce con un accordo sui rischi da affrontare per primi. Integrando la remediation in workflow endpoint più ampi, i team riducono lo sforzo manuale e mantengono risultati di patching coerenti su larga scala. Integrando la remediation in workflow endpoint più ampi, i team riducono lo sforzo manuale e mantengono risultati di patching coerenti su larga scala.

Responsabilità condivisa sulle patch: potenziare la collaborazione tra IT e sicurezza

AI e automazione migliorano la gestione delle patch solo quando sono associate a una responsabilità condivisa. Quando i team IT e di sicurezza operano sugli stessi dati endpoint e sugli stessi workflow di remediation, la responsabilità passa dalla difesa dei singoli report alla riduzione congiunta dell’esposizione.

Un processo di patching basato sui dati parte da obiettivi condivisi. Invece di misurare il successo in strumenti isolati, le organizzazioni allineano IT e sicurezza intorno a metriche comuni che riflettono il rischio reale e l’impatto operativo. Questa misurazione condivisa crea chiarezza sulle priorità ed elimina l’ambiguità sulla responsabilità.

Una collaborazione efficace dipende da metriche di cui entrambi i team si fidano e su cui agiscono insieme. I KPI comuni includono:

Tempo medio di remediation (MTTR): la rapidità con cui vengono risolte le vulnerabilità critiche
Tassi di conformità delle patch: su endpoint sia gestiti sia precedentemente non gestiti
Durata dell’esposizione: per quanto tempo le vulnerabilità ad alto rischio rimangono aperte
Visibilità sugli endpoint: percentuale di dispositivi completamente individuati e gestiti

Queste metriche spostano le conversazioni dal volume delle patch ai risultati misurati in termini di rischio e aiutano i team a concentrarsi sugli esiti anziché sulle attività.

La responsabilità congiunta richiede workflow che coprano l’intero ciclo di vita delle patch. Le piattaforme basate sull’AI supportano questo approccio automatizzando le attività di routine e facendo emergere le eccezioni che richiedono il giudizio umano.

I leader IT e della sicurezza definiscono criteri di controllo per l’automazione, inclusi soglie di approvazione, requisiti di test e vincoli di rollout. Entro questi limiti, l’automazione esegue la remediation in modo coerente e su larga scala, senza coordinamento manuale costante. Nel tempo, la fiducia nel processo aumenta, l’onere di coordinamento diminuisce e il patching diventa una responsabilità operativa collaborativa anziché un punto di attrito.

Visitate la nostra pagina delle soluzioni per scoprire come le soluzioni Ivanti per la gestione autonoma degli endpoint offrano ai team IT e di sicurezza la visibilità unificata di cui hanno bisogno per eliminare i silos di patching e chiudere più rapidamente le vulnerabilità.

DLL hijacking: rischi, esempi reali e come prevenire gli attacchi

Wed, 17 Dec 2025 14:00:02 Z

Si è parlato molto di CVE-2025-56383 (pubblicata il 26 settembre 2025), una vulnerabilità di hijacking in Notepad++ v8.8.3 in cui un file DLL può essere sostituito per eseguire codice dannoso.

La CVE è stata contestata da più parti, ma non è questo l’aspetto su cui intendiamo soffermarci. Vogliamo invece approfondire il DLL hijacking e discutere della minaccia concreta che rappresenta per un’organizzazione. Vediamo cos’è il DLL hijacking e quali misure è possibile adottare per mantenere le DLL al sicuro.

Cos’è il DLL hijacking e come avviene

Il DLL hijacking (noto anche come attacco di preloading delle DLL) è una vulnerabilità di sicurezza in cui un file Dynamic Link Library (DLL) legittimo e attendibile in un’applicazione Windows viene sostituito con un file dannoso.

Questo metodo sfrutta il modo in cui le applicazioni caricano i file DLL, che contengono codice e dati utilizzati da più programmi. Caricando una DLL dannosa, un threat actor può eseguire il proprio codice con gli stessi privilegi dell’applicazione legittima, provocando escalation dei privilegi, persistenza ed evasione delle difese.

Quando un programma si avvia, spesso deve caricare diverse DLL per eseguire funzioni specifiche, in genere da directory di sistema attendibili. Tuttavia, se un’applicazione non presta attenzione al percorso in cui cerca queste DLL, potrebbe caricare una DLL dannosa da una posizione non sicura o prevedibile (ad esempio, la directory di lavoro corrente o una condivisione di rete). Questo può accadere se l’applicazione non specifica il percorso completo della DLL o se la cerca in una directory accessibile o modificabile da un aggressore.

Sebbene questo tipo di attacco non sia nuovo, rimane efficace grazie alla sua semplicità. E anche se questo problema specifico riguarda le applicazioni Windows, è importante sottolineare che vulnerabilità simili possono interessare altri sistemi operativi (come Linux e macOS, che utilizzano il caricamento dinamico per le librerie condivise).

Il DLL hijacking introduce molteplici rischi per la sicurezza, tra cui:

Furto di dati: la DLL dannosa può intercettare e rubare dati sensibili, come password o informazioni personali.
Sistemi compromessi: l’aggressore può ottenere il controllo del sistema, con il rischio di ulteriori attacchi o dell’installazione di malware aggiuntivo.
Malware: la DLL dannosa può fungere da canale per la diffusione di malware, infettando altre parti del sistema o della rete.

Una DLL può essere sottoposta a hijacking in diversi modi; ecco alcune delle tecniche più comuni:

Ordine di ricerca delle DLL non sicuro: gli aggressori inseriscono DLL dannose in directory cercate prima della posizione della DLL legittima.
Manipolazione dei percorsi relativi: le DLL dannose vengono caricate quando le applicazioni utilizzano percorsi relativi.
Reindirizzamento delle DLL: tecniche come la manipolazione dei percorsi reindirizzano il processo di caricamento delle DLL.
Autorizzazioni deboli: gli aggressori sostituiscono DLL legittime con DLL dannose in directory con autorizzazioni deboli.
Phantom DLL hijacking: gli aggressori sfruttano le applicazioni che caricano DLL inesistenti inserendo DLL dannose con lo stesso nome nelle directory oggetto di ricerca.

Queste potenziali vulnerabilità evidenziano l’importanza di pratiche di sviluppo sicuro e della gestione delle autorizzazioni delle directory per prevenire questa forma di attacco.

Come prevenire il DLL hijacking e mantenere le DLL al sicuro

Sebbene il DLL hijacking rimanga una minaccia, esistono best practice da seguire e implementare per ridurre il rischio e creare un ambiente IT più sicuro e protetto.

Caricamento sicuro delle DLL:

Utilizzare percorsi completi: specificare sempre il percorso completo della DLL quando viene caricata. In questo modo l’applicazione carica la DLL da una posizione attendibile (e non da una directory non sicura).
Impostare un percorso di ricerca sicuro: utilizzare la funzione SetDllDirectory in Windows per aggiungere directory attendibili al percorso di ricerca ed escludere quelle non sicure. Questo può aiutare a impedire all’applicazione di caricare DLL da posizioni inattese.

Controlli di integrità dei file:

Firme digitali: assicurarsi che le DLL siano firmate con una firma digitale e verificare la firma prima di caricare la DLL. Questo può aiutare a confermare che la DLL non sia stata manomessa.
Verifica dell’hash: utilizzare funzioni hash crittografiche per verificare l’integrità dei file DLL. Se l’hash della DLL non corrisponde al valore previsto, il file potrebbe essere stato modificato.

Autorizzazioni degli utenti:

Principio del privilegio minimo: eseguire le applicazioni con il privilegio minimo necessario. Ciò limita il potenziale danno di un DLL hijacking, poiché il codice dannoso disporrà di meno autorizzazioni per eseguire azioni nocive.
Controllo dell’account utente (UAC): abilitare UAC sui sistemi Windows per richiedere agli utenti l’autorizzazione prima di eseguire applicazioni con privilegi elevati. Questo può aiutare a prevenire modifiche non autorizzate ai file di sistema.

Controllo delle applicazioni e gestione dei privilegi:

Applicazioni note e attendibili: il controllo delle applicazioni garantisce che possano essere avviate solo applicazioni note e attendibili, eliminando il rischio di introdurre applicazioni non autorizzate.
Controllo dei privilegi: una gestione efficace dei privilegi è fondamentale per prevenire il DLL hijacking. Assicurando che le applicazioni dispongano dei diritti e dei privilegi corretti per l’avvio, si limita la possibilità per gli utenti non autorizzati di introdurre file dannosi. Questo controllo agisce come una barriera chiave, limitando l’accesso di cui un aggressore ha bisogno per sfruttare il meccanismo di ricerca delle DLL e migliorando così la sicurezza dell’ambiente.

Software di sicurezza:

Antivirus e anti-malware: utilizzare software antivirus e anti-malware affidabili per rilevare e impedire il caricamento di DLL dannose. Questi strumenti possono eseguire scansioni alla ricerca di file e comportamenti dannosi noti.
Sistemi di rilevamento delle intrusioni (IDS): implementare IDS per monitorare attività insolite, come modifiche inattese ai file DLL o tentativi di caricare DLL da posizioni non sicure.

Gestione delle patch:

Mantenere aggiornato il software: aggiornare regolarmente applicazioni e sistemi operativi con le patch di sicurezza più recenti. Molte vulnerabilità di DLL hijacking vengono risolte tramite aggiornamenti, quindi restare al passo aiuta a proteggersi dalle minacce note.
Patching automatizzato: utilizzare uno strumento di gestione automatizzata delle patch per garantire che tutti i sistemi siano mantenuti aggiornati senza intervento manuale. Questo riduce la finestra di opportunità per gli aggressori di sfruttare vulnerabilità note, incluse quelle che potrebbero essere utilizzate per il DLL hijacking. Questo approccio proattivo aiuta a mantenere l’integrità delle applicazioni e dei sistemi operativi, rendendo molto più difficile per gli aggressori inserire DLL dannose.

Implementando queste best practice, è possibile ridurre in modo significativo il rischio di DLL hijacking e migliorare la sicurezza complessiva di applicazioni e sistemi.

Combinare strumenti e tattiche adeguati per prevenire il DLL hijacking

Il DLL hijacking è una forma di attacco persistente da anni, a dimostrazione del fatto che è ancora efficace e continuerà quindi a rappresentare un problema per le organizzazioni.

Prepara la tua organizzazione al futuro utilizzando le best practice citate sopra insieme a soluzioni comprovate come Ivanti Neurons for App Control per contribuire a mantenere sicure le DLL. Funzionalità come Trusted Ownership rilevano e impediscono l’esecuzione di una DLL sottoposta a hijacking verificando che la proprietà degli elementi corrisponda all’elenco approvato di proprietari attendibili.

Inoltre, mantieni aggiornate le app per limitare l’esposizione alle vulnerabilità note. Elimina il rischio di errore umano automatizzando il patching con Ivanti Neurons for Patch Management, assicurando che i sistemi siano aggiornati e protetti automaticamente.

Migrazione a Windows 11: il percorso Customer Zero di Ivanti per gli aggiornamenti a Win11

Mon, 21 Jul 2025 15:46:23 Z

Windows 11 offre una sicurezza avanzata e un’interfaccia utente moderna, ma la transizione può essere complessa per le grandi organizzazioni, con sfide logistiche e legate al coinvolgimento dei dipendenti. Microsoft terminerà il supporto per Windows 10 il 14 ottobre 2025, quindi è fondamentale iniziare fin da ora a pianificare ed eseguire le distribuzioni di Windows 11.

La necessità di migrare a Windows 11

Migrare a Windows 11 è essenziale per restare aggiornati, sicuri ed efficienti. Offre funzionalità di sicurezza avanzate, come una crittografia più robusta e un rilevamento delle minacce migliorato, proteggendo i dati e rafforzando la resilienza IT. L’interfaccia intuitiva semplifica inoltre le attività quotidiane, aumentando la produttività. Con la fine del supporto Microsoft per Windows 10 prevista per quest’anno, l’aggiornamento può aiutare le organizzazioni a evitare maggiori rischi per la sicurezza e potenziali tempi di inattività. Secondo Gartner, molte aziende scelgono di sostituire anche i dispositivi compatibili con nuovo hardware per garantire prestazioni ottimali con Windows 11. Una pianificazione proattiva assicura una transizione fluida e senza interruzioni.

Il caso d’uso Ivanti per la migrazione da Windows 10 a Windows 11

In Ivanti, stiamo implementando con successo le migrazioni a Windows 11 dall’inizio del 2025. Come molte grandi organizzazioni, discutiamo e pianifichiamo questa migrazione da tempo. L’obiettivo è aggiornare tempestivamente ogni dispositivo idoneo e valutare i dispositivi non idonei per ulteriori attività di risoluzione dei problemi o per la sostituzione.

Per raggiungere questo obiettivo, abbiamo scelto di utilizzare prioritariamente le soluzioni della nostra piattaforma Ivanti Neurons, che ci hanno fornito gli strumenti proattivi e le informazioni necessarie per una distribuzione efficace di Windows 11. Con un approccio per fasi, siamo riusciti a identificare e risolvere i problemi segnalati dagli early adopter e a raccogliere feedback preziosi. Una volta confermata la validità del piano, abbiamo potuto distribuire gradualmente l’aggiornamento al resto dell’organizzazione, garantendo una migrazione complessivamente più fluida.

Possibili sfide

Come qualsiasi altra azienda, volevamo anticipare ogni potenziale ostacolo a una migrazione di successo.

Compatibilità hardware e dispositivi sconosciuti

Una delle sfide principali nell’aggiornamento a Windows 11 è soddisfare i requisiti hardware. Molti dispositivi esistenti potrebbero non rispettare i rigorosi criteri di Microsoft, limitando il numero di dispositivi idonei. Questo può essere particolarmente problematico per le organizzazioni con un mix di hardware meno recente. Per affrontare questo aspetto, il team IT di Ivanti ha utilizzato le nostre funzionalità di discovery per eseguire un inventario e una valutazione approfonditi di tutti i dispositivi, identificando quelli da aggiornare o sostituire prima di avviare la migrazione. Non è possibile migrare dispositivi di cui non si conosce l’esistenza: per questo una visione completa del nostro panorama IT è stata un primo passo fondamentale.

Resistenza degli utenti finali e interruzioni della produttività

La resistenza degli utenti a nuove interfacce e funzionalità può rappresentare un altro ostacolo al successo. Il cambiamento può intimorire, e il nuovo aspetto e le funzionalità di Windows 11 possono mettere in difficoltà gli utenti abituati alle versioni precedenti. Anche gli aggiornamenti del sistema operativo possono interrompere il lavoro degli utenti, causando frustrazione e tempi di inattività. Per ridurre al minimo questi problemi, il team IT di Ivanti voleva assicurarsi che gli aggiornamenti avvenissero nel momento più comodo per l’utente finale, evitando la perdita di lavoro non salvato o interruzioni generali della produttività.

Continuare gli aggiornamenti di sicurezza con il supporto esteso

Non tutti i dispositivi possono essere aggiornati immediatamente a Windows 11 a causa dei requisiti hardware. Tuttavia, il supporto esteso di Ivanti ci consentirà di continuare a fornire aggiornamenti di sicurezza per Windows 10 oltre ottobre, mantenendo questi dispositivi protetti e operativi.

La distribuzione degli Extended Security Update (ESU) di Ivanti semplifica il processo di patching, riduce il carico di lavoro dell’IT e mantiene la conformità a normative come GDPR, HIPAA o PCI-DSS. I sistemi privi di patch affrontano oltre 1.200 vulnerabilità ogni anno e, secondo IBM, una violazione dei dati può costare in media 4,45 milioni di dollari. Dobbiamo assicurarci che tutti i dispositivi che non vengono aggiornati a Windows 11 restino protetti e al sicuro dalle vulnerabilità.

Il supporto esteso ci aiuta anche a prolungare il ciclo di vita dei dispositivi che non sono ancora pronti per essere sostituiti, oppure quando i vincoli di budget incidono sulle decisioni. Secondo Gartner, molte aziende stanno ancora rimandando gli acquisti nonostante la necessità di passare da Windows 10 a Windows 11, estendendo il ciclo di vita delle apparecchiature esistenti e cercando alternative per ottimizzare i budget. Le soluzioni ESU di Ivanti aiutano a prolungare la vita utile di questi dispositivi, evitando gli elevati costi di un rinnovo completo dell’hardware. Questo garantisce un patching senza interruzioni, riduce al minimo i rischi per la sicurezza e diminuisce l’impegno manuale dell’IT, aiutandoci a evitare potenziali perdite e interruzioni.

Il workflow di migrazione a Windows 11 di Ivanti

Ivanti Neurons ci ha permesso di automatizzare elementi chiave della migrazione, dalla valutazione iniziale dei dispositivi fino all’aggiornamento vero e proprio, semplificando ogni fase e consentendo al nostro team IT di concentrarsi su altre attività mission-critical. In generale, ecco come si presenta in Ivanti il workflow per aggiornare i dispositivi da Windows 10 a Windows 11.

1. Preparazione

Identificazione dei dispositivi: creare un gruppo di dispositivi Windows 10 che devono essere aggiornati.
Download dei file: inviare i file necessari ai dispositivi, garantendo un trasferimento dei dati efficiente tramite file ZIP.

2. Controllo preliminare

Verifica dell’idoneità: eseguire script PowerShell per verificare se il dispositivo soddisfa i requisiti hardware per Windows 11.
Verifica dell’alimentazione: assicurarsi che il dispositivo sia collegato all’alimentazione CA.

3. Interazione con l’utente

Notifica: utilizzare l’integrazione con il bot di Teams per informare gli utenti sull’aggiornamento e consentire loro di programmarlo.
Consenso: gli utenti forniscono il consenso all’aggiornamento tramite un messaggio interattivo di Teams.

4. Esecuzione dell’aggiornamento

Avvio dell’aggiornamento: eseguire l’Assistente aggiornamento Windows per effettuare l’aggiornamento.
Monitoraggio dell’avanzamento: monitorare il processo di aggiornamento e gestire eventuali errori o problemi che si presentano.

5. Azioni post-aggiornamento

Riavvio del dispositivo: invitare gli utenti a riavviare i dispositivi per completare l’aggiornamento.
Verifica dell’attivazione: verificare che il dispositivo sia attivato con un codice Product Key aziendale.
Aggiornamenti aggiuntivi: applicare eventuali aggiornamenti Windows necessari dopo l’upgrade.

6. Gestione degli errori

Creazione automatica dei ticket: utilizzare un bot per generare ticket per i dispositivi in cui il processo di aggiornamento non riesce.
Risoluzione dei problemi: il team dei servizi enterprise gestisce i casi in cui i dispositivi non possono essere aggiornati automaticamente.

7. Miglioramento continuo

Perfezionamento: suddividere il processo di aggiornamento in passaggi automatizzati più piccoli per semplificare le operazioni.
Feedback: integrare il feedback degli utenti per migliorare l’esperienza di aggiornamento.

Questo workflow garantisce una transizione fluida da Windows 10 a Windows 11, riducendo al minimo le interruzioni e gestendo le eccezioni in modo efficiente. Il processo è stato implementato gradualmente, una settimana alla volta. È stato costruito con attenzione e intenzionalità, con l’obiettivo di creare un processo e un workflow validi anche per il futuro, assicurandone flessibilità e modularità. In questo modo potremo riprendere un processo simile per la prossima generazione di Windows, quando arriverà.

Pronto a iniziare la tua migrazione a Windows 11?

Migrare a Windows 11 è essenziale per mantenere sicurezza, efficienza e conformità. Ivanti ha sfruttato le proprie soluzioni per automatizzare i passaggi chiave, raccogliere feedback dagli utenti e fornire aggiornamenti di sicurezza estesi per i dispositivi non idonei, garantendo al contempo una transizione fluida che riduce al minimo le interruzioni per gli utenti finali e massimizza l’efficienza dell’IT.

L’approccio e il workflow di Ivanti non solo rispondono alle sfide attuali, ma creano anche una base flessibile e modulare per i futuri aggiornamenti del sistema operativo.

Pronto a iniziare la tua migrazione a Windows 11? Scopri come Ivanti Neurons può semplificare e automatizzare il processo.

Esplora Ivanti Neurons

Che cos’è il ring deployment? Guida ai rollout software graduali

Tue, 22 Apr 2025 19:06:30 Z

Lo sfruttamento delle vulnerabilità è aumentato del 180% anno su anno dal 2023 al 2024, il che significa che la necessità di proteggere gli endpoint in modo rapido ed efficace — da sempre una priorità — continuerà solo a crescere. Applicare patch a queste vulnerabilità tempestivamente, senza però sacrificare la stabilità, può comportare sfide operative. Un modo per riuscirci è il ring deployment, una tecnica che estende progressivamente i rollout a gruppi di utenti. Di seguito analizzeremo che cos’è il ring deployment, come funziona e perché è una strategia essenziale per i team IT e di sicurezza.

Comprendere il modello di ring deployment

Il modello di ring deployment è un approccio strutturato ai rollout software che prevede la distribuzione di aggiornamenti o nuove funzionalità in fasi progressive, o "ring". Ogni ring rappresenta un diverso gruppo di utenti: si parte da un gruppo ristretto e controllato, per poi espandersi gradualmente a un pubblico più ampio. Questo metodo consente ai team di testare e convalidare le modifiche in un ambiente controllato prima di rilasciarle all’intera base utenti.

Una volta che il deployment iniziale basato su ring si dimostra efficace e che eventuali problemi sono stati risolti, i team possono estendere con fiducia l’aggiornamento al ring successivo. Questa espansione graduale contribuisce a ridurre al minimo il rischio di problemi diffusi e rende il deployment più affidabile.

Come funziona il deployment basato su ring: una guida passo passo

Il primo passo per implementare una strategia di ring deployment consiste nel definire i propri ring. Ogni ring deve rappresentare un diverso gruppo di utenti, con dimensioni e composizione di ciascun gruppo adattate alle esigenze dell’organizzazione. I ring possono essere configurati in base alle esigenze aziendali, tra cui:

Ring di test: un piccolo gruppo di tester interni o personale IT responsabile dell’identificazione dei problemi critici.
Ring degli early adopter: Un gruppo di utenti leggermente più ampio, che include stakeholder chiave disposti a testare nuove funzionalità e fornire feedback.
Ring di produzione completa: La fase finale, in cui il software viene rilasciato all’intera base utenti non inclusa nei ring di test e degli early adopter.

Una volta definiti i ring, il passaggio successivo consiste nel distribuire il software ai ring iniziali e monitorarne attentamente le prestazioni. In questa fase si monitoreranno le prestazioni, i bug come arresti anomali delle app e tassi di errore, oltre al feedback degli utenti. Questi dati aiuteranno a individuare eventuali problemi da risolvere prima di passare al ring successivo.

Dopo aver eseguito correttamente il deployment nei ring iniziali e risolto eventuali problemi, il passaggio successivo consiste nell’estendere gradualmente il rollout a gruppi più ampi. Questo approccio graduale garantisce che il software rimanga stabile e mantenga buone prestazioni man mano che raggiunge un pubblico più vasto.

La fase finale è il deployment in produzione completa, in cui il software viene rilasciato all’intera base utenti. Anche dopo aver raggiunto questa fase, è importante continuare a monitorare le prestazioni e raccogliere feedback per apportare miglioramenti continui.

Best practice per implementare una strategia di ring deployment

Allineare i ring ai livelli di impatto sul business: Garantire che i ring siano allineati ai livelli di impatto sul business dell’organizzazione consente di proteggere le funzioni aziendali critiche e affrontare tempestivamente eventuali problemi.
Automatizzare i deployment per una maggiore efficienza: Questo può contribuire a migliorare l’efficienza e ridurre il rischio di errore umano. Strumenti e script possono essere utilizzati per automatizzare il deployment in ciascun ring, assicurando un processo coerente e affidabile.
Monitoraggio continuo: Un sistema di monitoraggio solido può tracciare prestazioni, feedback degli utenti ed eventuali anomalie. Ciò consente di rilevare e risolvere rapidamente i problemi, garantendo un’esperienza utente fluida.
Disporre di piani di rollback in caso di errore: Possono comunque emergere problemi dopo il deployment nel ring di test. Disporre di un piano di rollback consente ai team di tornare rapidamente a una versione precedente del software, se necessario, riducendo al minimo l’impatto sugli utenti.
Comunicare con gli utenti nei diversi ring: Tenere informati gli utenti di ciascun ring sul processo di deployment, inclusi eventuali problemi noti e tempistiche previste. Questo aiuta a gestire le aspettative e garantisce che gli utenti siano preparati a eventuali cambiamenti.
Proseguire con un sondaggio sulla percezione degli utenti: Gli utenti iniziali sono preziosi, perché offrono insight in grado di guidare miglioramenti significativi. Coinvolgendo attivamente gli utenti attraverso un sondaggio, i team possono individuare problemi, correggere bug e scoprire aree di miglioramento che potrebbero non essere emerse durante il processo di deployment.

Vantaggi principali dell’utilizzo del ring deployment

Riduce il rischio

Uno dei principali vantaggi del ring deployment è la possibilità di individuare e risolvere i problemi nelle prime fasi del processo di deployment. Partendo da un piccolo gruppo di utenti, i team possono identificare e correggere bug critici e problemi di prestazioni prima che incidano sull’intera base utenti, favorendo in modo fluido il miglioramento continuo. Questo processo iterativo consente ai team di apportare rapidamente modifiche e miglioramenti, assicurando che la versione finale delle patch distribuite sia perfettamente allineata alle esigenze e alle aspettative di basi utenti più ampie.

Migliora l’esperienza utente

Testando le nuove patch con gruppi più piccoli, i team possono raccogliere feedback preziosi e apportare le modifiche necessarie. Eventuali errori che potrebbero verificarsi con i rilasci vengono individuati e corretti in modo iterativo prima di interrompere l’attività della maggior parte degli utenti.

Evita interruzioni significative

Il deployment basato su ring non solo riduce le interruzioni per gli utenti, ma mantiene anche la produttività durante gli aggiornamenti. Introducendo le modifiche gradualmente, è meno probabile che gli utenti vengano colti alla sprovvista da cambiamenti improvvisi e importanti che potrebbero compromettere i loro flussi di lavoro. Questo rollout metodico e controllato garantisce una transizione più fluida, riducendo al minimo tempi di inattività e frustrazione. Gli utenti possono abituarsi a nuove funzionalità e aggiornamenti a un ritmo sostenibile, un aspetto particolarmente cruciale in contesti aziendali in cui stabilità e affidabilità sono imprescindibili.

Supporta miglioramenti iterativi

Il ring deployment supporta il miglioramento continuo consentendo ai team di raccogliere feedback dagli utenti in ogni fase del rollout. Questo feedback può essere utilizzato per apportare miglioramenti iterativi, assicurando che l’aggiornamento finale soddisfi le esigenze e le aspettative degli utenti.

Perché il ring deployment è una scelta intelligente

Una strategia di deployment basata su ring può aiutare le organizzazioni a ottenere un processo di deployment più fluido e stabile, con il risultato di software migliori e utenti più soddisfatti. Se la vostra organizzazione intende adottare il ring deployment, iniziate definendo i ring, automatizzando il processo di deployment e mantenendo una comunicazione efficace con gli utenti. Con un’attenta pianificazione ed esecuzione, il ring deployment può diventare una componente preziosa della vostra strategia IT e di sviluppo software.

Processi moderni efficaci di patch management e best practice per le operazioni di patch

Thu, 01 Aug 2024 06:01:00 Z

Adottare un programma di gestione delle vulnerabilità basato sul rischio è essenziale per mantenere sicuro l’ambiente informatico aziendale. In un blog precedente, “In che modo l’implementazione del patch management basato sul rischio dà priorità agli exploit attivi”, ho offerto una prospettiva su come assegnare le priorità alle vulnerabilità. Per questo processo è essenziale perfezionare l’aspetto operativo della protezione dei sistemi.

Gestire le operazioni di patch all’interno dell’organizzazione può essere un processo complesso. Anche avendo una certa visibilità sulle priorità delle vulnerabilità, è comunque necessario considerare:

La cadenza di rilascio delle patch.
Policy di supporto per rendere efficace questo processo.
Campagne per distribuire gli aggiornamenti.
Accordi sul livello di servizio (SLA) e misurazione della conformità.

Potrebbe sembrare un equilibrio difficile da mantenere, ma un sistema flessibile, in grado di gestire gli eventi pianificati e tenere conto degli imprevisti, permette di avere il pieno controllo.

Ha davvero il controllo?

Alcuni aspetti dei rilasci delle patch possono essere pianificati, altri no.

Prendiamo ad esempio la cadenza dei rilasci delle patch di sicurezza. Il Patch Tuesday, il secondo martedì di ogni mese, Microsoft cerca di rilasciare tutti gli aggiornamenti più recenti. Questi includono aggiornamenti per sistemi operativi, Office e altre applicazioni utente, strumenti di sviluppo come Visual Studio e componenti cloud in Azure, solo per citarne alcuni.

Il Patch Tuesday, che ha celebrato il suo 20° anniversario nell’ottobre 2023, è alla base di molti programmi di patch: offre un momento preciso in cui distribuire tutti gli ultimi aggiornamenti Microsoft e quelli di terze parti disponibili. Nessun altro vendor ha avuto un impatto così profondo nel guidare i programmi di patch delle organizzazioni e, ancora oggi, il ciclo mensile delle patch, incentrato sul Patch Tuesday, rimane uno standard del settore.

Altri vendor hanno cercato di seguire lo stesso modello e rilasciare i propri aggiornamenti secondo una pianificazione:

Oracle rilascia il proprio Critical Patch Update una volta a trimestre.
Adobe di solito rilascia i propri aggiornamenti una volta al mese, spesso in sincronia con il Patch Tuesday.
Google ha recentemente iniziato a rilasciare un singolo aggiornamento ogni settimana.

Tuttavia, la maggior parte dei vendor rilascia aggiornamenti di sicurezza non appena e con la frequenza possibile, per assicurarsi di risolvere le vulnerabilità il più rapidamente possibile. Ne deriva un flusso casuale e continuo di aggiornamenti che devono essere costantemente prioritizzati e distribuiti in tutta l’organizzazione.

Processo di patch management per policy e campagne

Per tenere sotto controllo il caos dei rilasci delle patch servono un insieme di regole chiaramente definito e un’infrastruttura in grado di applicarle. Nell’ambito delle patch, questo si traduce in policy e campagne.

Una policy di patch richiede un’ampia gamma di considerazioni oltre alla prioritizzazione delle vulnerabilità, tra cui l’impatto degli aggiornamenti sulle attività aziendali, l’applicabilità a diversi tipi di sistemi, il grado di controllo sugli aggiornamenti e altri fattori.

Le policy di patch mettono in evidenza forti differenze, a seconda dell’azienda. Per un server che ospita applicazioni aziendali critiche, la policy prevede un insieme di aggiornamenti chiaramente definito e sottoposto a rigoroso controllo della configurazione, viene applicata solo durante una finestra di manutenzione definita e impone sempre un riavvio al termine, per garantire che il sistema sia completamente aggiornato. La policy di patch per il laptop di un utente del marketing identifica una serie di applicazioni con aggiornamenti approvati che possono essere presenti o meno e consente all’utente di rimandare aggiornamenti e riavvio al momento più opportuno.

Le campagne tengono conto di queste policy, ma permettono anche di controllare la moltitudine di patch rilasciate continuamente.

Le best practice moderne di patch management richiedono interventi di patching più frequenti rispetto alla semplice cadenza mensile. Le patch di Google Chrome vengono rilasciate ogni settimana e le patch zero-day possono essere rilasciate in qualsiasi momento. Una campagna mensile lascerà molti sistemi vulnerabili per periodi prolungati.

Definire tre tipi di campagne

Una best practice consiste nel definire tre tipi di campagne: manutenzione regolare, aggiornamenti prioritari e distribuzioni critiche.

Campagna di manutenzione regolare

Le campagne di manutenzione regolare applicano il rollout standard mensile delle patch ad anelli, oggi utilizzato dalla maggior parte delle organizzazioni. Questa campagna include:

Test iniziali in un ambiente controllato per garantire che le patch si installino come previsto.
Rollout a un gruppo pilota più ampio di early adopter, pronti a segnalare eventuali problemi.
Rollout ai gruppi predefiniti di sistemi di produzione per completare la distribuzione complessiva.

Le patch in una campagna di manutenzione includono aggiornamenti di sicurezza rilasciati con minore frequenza, come i rilasci del Patch Tuesday di Microsoft, oltre ad aggiornamenti delle prestazioni o delle applicazioni. I sistemi interessati da questa campagna possono anche essere quelli con finestre di manutenzione limitate e che non possono essere interrotti senza un impatto aziendale significativo. È molto probabile che la maggior parte delle patch rientri nella campagna di aggiornamenti prioritari.

Campagna di aggiornamenti prioritari

La campagna di aggiornamenti prioritari è progettata per intervenire rapidamente sui sistemi che sono esposti in modo continuo a nuove vulnerabilità, ma che possono essere aggiornati con maggiore frequenza. I sistemi utente che eseguono applicazioni di produttività e browser rientrano in questa campagna e spesso sono tra quelli a rischio più elevato, a causa dell’esposizione a phishing, malware e ransomware.

Le patch associate a questa campagna hanno spesso la massima priorità a causa di vulnerabilità con sfruttamento noto, ma possono anche avere un impatto aziendale relativamente ridotto, richiedendo il riavvio di un browser o di un’applicazione. Di conseguenza, le policy possono prevedere un ciclo di test più breve prima del rilascio e possono essere distribuite più rapidamente a gruppi più ampi di sistemi non critici per il business; ad esempio, i server potrebbero non avere un browser installato, mentre i laptop del team vendite sì.

Campagna di risposta zero-day

La campagna di risposta zero-day è riservata alla distribuzione di patch di emergenza imposta dall’azienda o dal settore, quando la situazione è critica e la correzione deve essere implementata in tempi brevi. Questa campagna ha la precedenza su tutte le altre.

La policy per questa campagna potrebbe ridurre i tempi o abbassare gli standard tra le fasi di rollout controllato, oppure potrebbe ignorarli del tutto, a seconda dello SLA da rispettare. L’aspetto più importante delle campagne di risposta zero-day è questo: si tratta comunque di una distribuzione controllata delle patch e tutte le attività vengono comunque registrate per monitorare con precisione gli eventi della campagna fino al completamento.

Il tempo di esposizione determina la conformità

Se la conformità viene misurata in termini di macchine completamente aggiornate, secondo questa metrica la maggior parte dei sistemi risulta conforme solo per un numero limitato di ore al mese. Pur essendo tecnicamente accurato, questo è un indicatore poco efficace per mostrare la sicurezza del sistema nel tempo nell’ambito di un programma basato sul rischio. Mostrare il “tempo di esposizione” a una determinata vulnerabilità o a un gruppo di vulnerabilità offre un indicatore di rischio migliore.

Ecco un esempio: CVE-2024-4761 è stata indicata come corretta in un aggiornamento di Google Chrome rilasciato il 14 maggio, che coincideva con il Patch Tuesday di maggio. Il giorno successivo, questa patch di Chrome è stata aggiunta a una campagna di aggiornamenti prioritari che prevedeva un periodo di distribuzione di due settimane su 500 sistemi nel Gruppo 1 e 1.000 sistemi nel Gruppo 2. Supponendo che la maggior parte dei sistemi sia stata aggiornata correttamente entro quella finestra di due settimane, un report mostrerebbe quando ogni sistema è stato aggiornato, ma soprattutto per quanto tempo ciascuno di questi 1.500 sistemi è rimasto senza patch, esposto alla vulnerabilità e quindi a rischio.

Questo è un esempio semplice, con una vulnerabilità e una patch. Ma se nella campagna fossero presenti più patch con diverse vulnerabilità, le informazioni potrebbero essere aggregate per offrire una vista più completa della campagna. Se nello stesso periodo fossero eseguite più campagne, il risultato potrebbe essere sovrapposto o combinato per fornire una valutazione del rischio ancora più accurata.

Con questi dati a disposizione, è possibile mostrare a un auditor il reale stato di sicurezza dei sistemi. E, forse ancora più importante, è possibile iniziare a valutare i risultati e migliorare l’efficacia delle moderne operazioni di patch management. A quel punto, sarà l’organizzazione a gestire l’operazione, non il contrario.

Come evitare questi due problemi comuni nell’applicazione mensile delle patch

Tue, 25 Jul 2023 14:02:27 Z

È arrivato il momento: bisogna applicare le patch agli endpoint. Forse è un’attività che ti piace, ma probabilmente non è così. L’applicazione delle patch può essere un compito impegnativo e, poiché molte organizzazioni la gestiscono ancora manualmente, richiede più tempo e risorse di quanto chiunque vorrebbe davvero considerare.

Ora, dato che investirai tutto quel tempo e quelle risorse nell’applicazione delle patch, vuoi assicurarti che tutto proceda senza intoppi. Nessuno vuole dedicare così tante energie alla gestione delle patch per poi ritrovarsi in un groviglio di confusione ed errori.

Assicuriamoci quindi di non incorrere in questi due problemi più comuni nell’applicazione mensile delle patch:

Le tue patch funzionano?
Hai testato le patch nel tuo ambiente?

Problema di patch n. 1: le tue patch funzionano?

Non è raro che le patch e gli aggiornamenti di sicurezza semplicemente non vadano a buon fine. A volte dipende da un problema specifico dell’ambiente. Altre volte, è la patch stessa a non essere valida.

Meno male che hai deciso di controllare quella patch prima di distribuirla alla cieca, vero? Ma ora che non funziona, cosa puoi fare? Dipende.

Soluzione 1: contatta il tuo fornitore di gestione delle patch di terze parti

Se utilizzi un fornitore di patching di terze parti per gestire gli aggiornamenti delle patch, sarà il primo interlocutore da contattare.

Sebbene le aziende che gestiscono il patching di terze parti testino accuratamente i contenuti che distribuiscono ai clienti, non possono verificare ogni scenario d’uso. Potresti avere una configurazione particolare, oppure il tuo endpoint potrebbe gestire la patch in modo diverso da quanto previsto dal fornitore di patch di terze parti.

Qualunque sia il motivo, il tuo fornitore dovrebbe sempre essere il primo punto di riferimento. Segnalare l’errore è importante non solo per poterlo correggere, ma anche perché è utile al fornitore di patching di terze parti.

Potresti aver individuato un problema sistemico. A quel punto diventi la persona che ha avvisato l’azienda di un problema più ampio, consentendole di intervenire rapidamente per risolverlo.

Forse non è sistemico, ma è comunque un problema abbastanza comune da aiutare l’azienda a prepararsi meglio alle future chiamate di altri clienti. Inoltre, hai fornito un potenziale nuovo scenario d’uso da aggiungere ai protocolli di test predefiniti.

Soluzione 2: consulta la community online più ampia per individuare possibili problemi delle patch

Ma se non utilizzi un fornitore di patching di terze parti? Supponiamo che la tua organizzazione esamini manualmente queste patch.

Esistono ottime risorse online per verificare se anche altre organizzazioni stanno riscontrando gli stessi problemi, tra cui:

PatchManagement.org, “la prima mailing list del settore dedicata alla discussione sulla gestione delle patch”.
Diverse community su Reddit e Mastodon, come r/sysadmin, infosec.exchange o qualsiasi community specifica di un fornitore.
Le risorse Patch Tuesday di Ivanti, pensate per discutere quali patch vengono rilasciate e cosa ci si può aspettare da esse.

Indipendentemente dal percorso che decidi di seguire, hai a disposizione molte opzioni per capire cosa sia andato storto con la patch non riuscita.

Problema di patch n. 2: hai testato le patch nel tuo ambiente?

Bene, hai deciso di testare ogni patch in arrivo: ottimo! Sei al sicuro, giusto?

Non proprio.

Non devi inoltre dimenticare di testare le patch che distribuirai su dispositivi pilota provenienti da tutta l’organizzazione.

Perché? In fondo è solo un semplice aggiornamento di Chrome. Ma è davvero così?

Introdurre una nuova patch nei sistemi non è diverso dall’accogliere un nuovo animale domestico in casa. Anche se ne hai già avuto uno e sei convinto di sapere come prendertene cura, ognuno avrà reazioni proprie a stanze o persone, diverse da quelle dell’animale precedente.

Allo stesso modo, ogni patch presenta sfumature specifiche in termini di modifiche e aggiornamenti. Queste possono spesso entrare in conflitto con ciò per cui i tuoi sistemi o programmi sono stati progettati, compromettendo l’ambiente o l’efficacia della patch, anche se la patch ha superato i test iniziali.

Dopotutto, le aziende software non applicano patch ai prodotti pensando ai tuoi sistemi. Si concentrano sull’aggiornamento e sull’applicazione di patch alle proprie applicazioni, e non possono considerare tutti gli scenari d’uso.

Risolvere l’effetto domino dei problemi delle patch

Disporre di un gruppo pilota dedicato di endpoint su cui testare questi aggiornamenti può aiutarti a evitare di compromettere sistemi, programmi o persino processi da cui dipende la tua azienda. L’effetto domino di un piccolo aggiornamento di patch può essere dannoso per le attività aziendali.

Ad esempio, all’inizio di aprile, Chrome ha distribuito una patch per risolvere alcuni bug. Ma ha anche introdotto nuovi bug, uno dei quali ha interessato la capacità di stampa da Chrome.

E se la tua organizzazione operasse in un ambiente in cui si stampa molto e la possibilità di stampare tramite Chrome fosse indispensabile per le tue attività?

In questo modo, testare tutte le patch, anche quelle piccole e apparentemente insignificanti, può aiutarti a evitare conseguenze gravi.

Ricorda: quando qualcosa va storto, gli errori si propagano oltre il reparto o l’utente inizialmente interessato. La maggior parte degli utenti e delle organizzazioni non considera gli impatti a valle che una piccola patch può generare se non viene testata a fondo. Dopotutto, spesso è l’IT a dover rimediare agli effetti di un errore o di un’interruzione.

Quindi, quando arriva il momento di applicare le patch, vogliamo creare le condizioni per il successo. Per farlo, individuiamo una varietà adeguata di endpoint su cui testare le patch, così da assicurarci di non generare un impatto a valle evitabile, e ci prepariamo anche con le risorse della community nel caso in cui le patch non vadano a buon fine.

Puoi anche consultare:

La guida definitiva alla gestione delle patch basata sul rischio per maggiori informazioni sulla creazione di gruppi pilota, sulla gestione prioritaria delle patch e su altri principi fondamentali del patching.
Il podcast Security Insights, che tratta l’importanza della visibilità degli asset prima di distribuire semplicemente una nuova patch.
La serie Patch Tuesday, che raccoglie tutte le nostre precedenti raccomandazioni e avvertenze sul patching. Non perdere il prossimo appuntamento, che si tiene ogni mese il mercoledì immediatamente successivo al Patch Tuesday.

A volte, la migliore strategia di gestione delle patch è semplicemente una buona preparazione. Buona fortuna.