Perché il vero divario nella sicurezza degli endpoint si trova tra rilevamento e azione

Un anno fa, ho scritto di il cambiamento del settore della gestione degli endpoint verso un modello più autonomo. Da allora, quel futuro è sembrato molto meno distante. Gran parte di questa pressione deriva dalla crescente distanza tra visibilità e azione. Le aziende sono diventate notevolmente abili nel individuare i rischi degli endpoint, ma agire su tali risultati richiede ancora troppo tempo.

Rapporto sulle indagini di violazioni dei dati 2026 di Verizon ha rilevato che lo sfruttamento delle vulnerabilità è diventato il vettore di accesso iniziale principale, rappresentando il 31% delle violazioni, in aumento rispetto al 20% dell’anno precedente. Allo stesso tempo, il tempo medio necessario per applicare completamente una patch è passato da 32 a 43 giorni.

Questi dati evidenziano il problema. Il rilevamento sta migliorando, ma la rimessione è in difficoltà a tenere il passo.

Gli aggressori, nel frattempo, stanno andando nella direzione opposta. Il Rapporto H1 2026 Cloud Threat Horizons di Google ha scoperto che la finestra tra la divulgazione di una vulnerabilità e il suo sfruttamento attivo si è ridotta da settimane a giorni, portando Google a raccomandare difese più automatizzate.

Questo dovrebbe cambiare il modo in cui pensiamo alla sicurezza degli endpoint. Un avviso non è un risultato. Un cruscotto che informa l’IT che 800 dispositivi sono vulnerabili ha identificato il problema, ma il rischio rimane esattamente dove era finché qualcuno non decide cosa fare, esegue quella decisione in modo sicuro e ne verifica l’efficacia.

Questo è il divario che la gestione autonoma degli endpoint può iniziare a colmare.

Il divario tra avviso e rimessione

Un avviso su un endpoint può indicare all’IT cosa è andato storto, ma il vero lavoro inizia dopo. I team devono ancora determinare quali dispositivi sono interessati, quanto sono esposti, se la vulnerabilità è attivamente sfruttata e con quale rapidità dovrebbe avvenire la rimessione. Potrebbero anche dover testare la patch, tenere conto delle dipendenze delle applicazioni e verificare che la correzione abbia effettivamente funzionato.

Su scala aziendale, è qui che si forma il collo di bottiglia. Una migliore visibilità genera più risultati, ma ogni risultato necessita ancora di contesto sufficiente affinché qualcuno possa agire con sicurezza.

La priorizzazione delle vulnerabilità sta diventando più basata sul rischio proprio per questo motivo. La Direttiva Operativa Vincolante 26-04 di CISA va oltre i soli punteggi di gravità e introduce fattori come lo sfruttamento attivo e il contesto ambientale nella decisione. Una vulnerabilità critica su un sistema esposto a Internet non è lo stesso problema di quella stessa vulnerabilità su una macchina di test isolata.

Qui è dove la Gestione Autonoma degli Endpoint (AEM) può estendere ciò che l’automazione tradizionale fa già bene. L’automazione basata su regole è eccellente quando la risposta è nota in anticipo: una condizione è soddisfatta, quindi viene eseguita un’azione predefinita. Il problema è che i problemi degli endpoint raramente rimangono così semplici. La risposta corretta dipende spesso dal dispositivo, dal suo stato attuale, dalle politiche associate e dal più ampio contesto di sicurezza.

AEM porta quel contesto nel flusso di lavoro utilizzando agenti specializzati per interpretare lo stato del dispositivo, il rischio e il contesto delle politiche, mentre l’automazione guidata dalle politiche definisce ciò che il sistema può fare. A seconda della situazione, ciò può significare raccomandare una risposta, avviare una rimessione approvata, verificare il risultato o segnalare il problema quando è ancora necessario il giudizio umano.

Questa è una distinzione importante. La fase successiva della gestione degli endpoint non riguarda semplicemente l’automazione di più attività. Si tratta di garantire che tali attività conducano effettivamente al risultato previsto dall’IT: portare l’endpoint nello stato di sicurezza e conformità atteso.

Perché la patching automatizzata è il punto di partenza migliore

La gestione delle patch è il contesto in cui questa idea diventa molto più evidente nella pratica. Il flusso di lavoro è ripetitivo, sensibile al tempo e, soprattutto, misurabile. Un dispositivo vulnerabile viene rimesso in sicurezza, o non lo è. Le linee guida di NIST per la gestione delle patch aziendali riflettono questa realtà trattando la patching come un ciclo di vita che termina con la verifica, non con il semplice dispiegamento.

Questa distinzione è importante. In un modello più autonomo, il contesto delle minacce proveniente da fonti come il Catalogo delle vulnerabilità note sfruttate di CISA può aiutare a stabilire l’urgenza, mentre le politiche definite dall’IT decidono fino a che punto debba andare la risposta. Una patch potrebbe passare attraverso un gruppo pilota, espandersi a tappe, ritentare sui dispositivi falliti o offline, e fermarsi per una revisione quando qualcosa esce dalle condizioni approvate.

Questa è una definizione molto più utile di patching autonomo rispetto al semplice inserimento degli aggiornamenti in un programma.

C’è anche un principio più ampio: l’autonomia dovrebbe essere una scala di permessi, non un unico interruttore. Più l’azione è prevedibile e reversibile, più libertà può avere il sistema. Più alto è il rischio operativo, maggiore è la necessità di approvazione e supervisione.

Se eseguita correttamente, la patching diventa più di un semplice caso d’uso dell’automazione. Diventa un modo controllato per l’IT di dimostrare che la rimessione autonoma può funzionare senza perdere il controllo.

Dalla patching a un’autonomia più ampia degli endpoint

Una volta che quel modello funziona per il patching, il passo successivo non è automatizzare tutto in una volta. Si tratta di espandere l’autonomia ad altri compiti dell’endpoint in cui il risultato desiderato è chiaro e la risposta può essere limitata in modo sicuro dalla policy.

Gli endpoint raramente rimangono esattamente come li ha configurati l’IT. Le impostazioni di sicurezza cambiano, i certificati scadono, le applicazioni richieste scompaiono, la crittografia viene disabilitata e i dispositivi escono dalla conformità. Nessuno di questi problemi è particolarmente drammatico da solo. Ma su una grande flotta, creano un flusso costante di ticket, indagini e correzioni manuali.

È qui che l’automazione guidata dalle policy e l’AI Agentica possono iniziare a collaborare in modo più significativo. Invece di creare un flusso di lavoro separato per ogni possibile problema, l’IT può definire lo stato che un endpoint deve mantenere. La policy stabilisce i confini, mentre gli agenti specializzati aiutano a interpretare ciò che è cambiato e a determinare quale risposta approvata dalla policy sia adatta alla situazione. Se il problema rientra in un percorso di rimedio approvato, la piattaforma può agire e verificare il risultato. Se il rimedio fallisce, il contesto cambia, o se l’azione richiesta è al di fuori di quei confini, il problema ritorna all’IT.

Ciò crea un modello di gestione degli endpoint molto più continuo. Piuttosto che attendere che un amministratore affronti ogni deviazione, il sistema può rilevare lo scostamento, agire entro la policy, verificare il risultato e segnalare solo quando è realmente necessario un giudizio umano.

Naturalmente, concedere ai sistemi più margine di azione rende anche la governance più importante. I flussi di lavoro di approvazione, le autorizzazioni basate sui ruoli, i registri di audit, le opzioni di rollback e la revisione da parte dell’amministratore devono comunque governare le azioni ad alto impatto. Tuttavia, tali controlli dovrebbero rendere l’autonomia più sicura, non riportare ogni azione a un processo manuale.

È qui che il divario tra rilevamento e azione inizia finalmente a chiudersi. Il valore della gestione autonoma degli endpoint non sarà misurato dal numero di decisioni che elimina per l’IT, ma dal numero di problemi di routine che può risolvere in modo sicuro prima che diventino il prossimo avviso di qualcun altro.