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à.