A partire da settembre 2026, le tempistiche di risposta in materia di sicurezza cambieranno in tutta l’UE. Ai sensi del Cyber Resilience Act (CRA), i produttori devono iniziare a segnalare le vulnerabilità sfruttate attivamente e gli incidenti di sicurezza gravi. Per i prodotti hardware e software contemplati dal regolamento, la segnalazione deve avvenire entro 24 ore dal momento in cui si viene a conoscenza dell’incidente, seguita da una notifica più completa entro 72 ore.
Quando sono coinvolti dati personali, il GDPR può aggiungere la propria tempistica di 72 ore. Ciò rende ancora più importante per il reparto IT stabilire rapidamente quali dispositivi sono interessati, il loro stato di sicurezza e le azioni già intraprese.
Ciò diventa più difficile man mano che gli ambienti dei dispositivi si espandono fino a includere dispositivi mobili, IoT e BYOD. Un numero maggiore di endpoint comporta un numero maggiore di versioni, utenti e stati di sicurezza da tenere in considerazione, mentre la finestra di reporting rimane la stessa.
Un parco dispositivi in crescita non fa altro che mettere in evidenza le falle
Le organizzazioni non perdono improvvisamente il controllo quando il loro parco dispositivi raggiunge una certa dimensione. Le crepe compaiono molto prima, quando l’identità, l’accesso e l’applicazione delle policy iniziano a operare come processi separati. Un parco dispositivi più ampio rende semplicemente più difficile aggirare tali punti deboli.
La risposta è stabilire il giusto livello di controllo dal momento in cui un dispositivo entra nell’ambiente. Da lì, l’accesso dovrebbe tenere conto sia dell’identità che dello stato del dispositivo, in osservanza delle linee guida Zero Trust del NIST per l’accesso alle risorse aziendali.
Una base connessa deve comunque tenere conto delle differenze tra i vari sistemi del parco dispositivi. Un telefono personale, un tablet condiviso in magazzino e un sensore connesso richiederanno ciascuno controlli diversi. L’obiettivo non è gestirli in modo identico, ma far sì che tale diversità rientri in un modello operativo coerente in cui le politiche e le decisioni di accesso appropriate possano seguire ogni tipo di dispositivo.
Tale coerenza diventa più difficile da mantenere man mano che il parco dispositivi cresce. Tuttavia, senza di essa, le eccezioni si accumulano e la visibilità diventa meno affidabile, costringendo il reparto IT a ricostruire lo stato del parco dispositivi quando subentra la pressione normativa.
L’automazione deve eliminare il collo di bottiglia, non spostarlo
La coda delle vulnerabilità sta crescendo più velocemente di quanto il reparto IT possa permettersi di gestire manualmente. Nel 2025, il NIST ha elaborato quasi 42.000 record CVE per l’arricchimento, il 45% in più rispetto a qualsiasi anno precedente. A tale livello, l’identificazione dei dispositivi interessati, il coordinamento delle correzioni e la verifica dei risultati possono rapidamente sovraccaricare i flussi di lavoro esistenti.
L’automazione dei singoli comandi da sola non è in grado di risolvere tale carico di lavoro. La sequenza utile collega una vulnerabilità rilevata ai dispositivi interessati, a una patch disponibile e a un’implementazione riuscita.
Tuttavia, l’automazione può semplicemente spostare il collo di bottiglia quando i sistemi su cui si basa rimangono disconnessi. Se i dati relativi all’inventario, all’applicazione delle patch e alla reportistica non corrispondono, i team devono comunque riconciliare le discrepanze, esaminare le operazioni non concluse con successo e gestire manualmente le eccezioni. Gli amministratori quindi dedicano il loro tempo a controllare l’automazione invece di trarne vantaggio.
La conformità introduce un’altra sfida in termini di scalabilità. Senza un monitoraggio continuo dei dispositivi, i dati sulla conformità possono rapidamente diventare obsoleti rispetto alla parco dispositivi, costringendo il reparto IT a verificare ripetutamente se i dispositivi soddisfano ancora gli standard richiesti.
In definitiva, l’automazione dovrebbe fornire ai team una chiara documentazione di quali elementi sono stati interessati, quali interventi correttivi hanno avuto successo e cosa richiede ancora attenzione. Tali informazioni possono quindi essere inserite direttamente nel più ampio processo di valutazione e segnalazione degli incidenti.
La visibilità pronta per la reportistica non può essere creata dopo l’inizio del conto alla rovescia
La prontezza nella segnalazione dipende dalla disponibilità di registrazioni relative a dispositivi, identità e risposte man mano che un incidente si sviluppa, piuttosto che dal doverle mettere insieme quando è il momento di presentare una segnalazione.
Il contesto del dispositivo è il punto di partenza. La gestione unificata degli endpoint (UEM) può fornire un registro aggiornato dell’endpoint, inclusi la sua configurazione, il software, le patch e lo stato di conformità. Ciò consente ai team di avere una visione immediata delle condizioni del dispositivo quando questo diventa oggetto di un’indagine.
L’identità aggiunge un altro elemento al quadro. Un provider di identità (IdP) può collegare il record del dispositivo con l’utente e il contesto di accesso, contribuendo a stabilire chi ha utilizzato l’endpoint e a cosa era autorizzato ad accedere. Ciò diventa particolarmente importante quando un’indagine deve passare rapidamente dal dispositivo all’utente che lo utilizza.
Tale contesto deve essere esteso anche al rilevamento delle minacce e alla risposta ad esse. Il rilevamento e la risposta estesi possono mostrare cosa è accaduto sull’endpoint e supportare il contenimento e la risoluzione. Con le informazioni sul dispositivo e sull’identità collegate, i team di sicurezza possono esaminare gli avvisi senza dover ricostruire il contesto altrove.
Le prove devono anche dimostrare cosa è accaduto successivamente. I risultati delle patch, le cronologie di autenticazione e i registri delle azioni amministrative possono distinguere un’azione richiesta da una completata con successo.
Riunire questi registri è ciò che trasforma la visibilità in qualcosa di pronto per l’audit. I team IT e di sicurezza dedicano meno tempo alla riconciliazione di console e cronologie, mentre i team di reporting ottengono un quadro più chiaro di ciò che è stato interessato e di come l’organizzazione ha reagito. Con la crescita dei parchi di dispositivi, questo livello di dati condivisi contribuisce a scalare la capacità di reporting senza richiedere lo stesso aumento del lavoro manuale.
A cura di Apu Pavithran, CEO e fondatore di Hexnode
