Comprendere la gestione continua dell’esposizione alle minacce (CTEM)

La maggior parte dei programmi di gestione delle vulnerabilità si limita a dire: «L’abbiamo individuata» e «L’abbiamo corretta». CTEM aggiunge la fase che la maggior parte dei programmi tralascia: verificare che l’esposizione sia effettivamente chiusa e che i controlli funzionino come previsto.

Questo articolo illustra in dettaglio quali siano i requisiti di ciascuna fase su scala aziendale, in quali punti i programmi tendono a subire rallentamenti e come valutare se le vostre iniziative CTEM stiano effettivamente riducendo il rischio o si limitino a generare attività.

Spiegazione del CTEM

La gestione continua dell’esposizione alle minacce è un modello articolato in cinque fasi . Gartner ha introdotto il concetto di “ ” per aiutare le organizzazioni a ridurre in modo sistematico la propria esposizione ai rischi di sicurezza. Le cinque fasi sono: definizione dell’ambito, analisi, definizione delle priorità, convalida e mobilitazione.

A differenza delle valutazioni periodiche delle vulnerabilità , che producono principalmente elenchi di risultati, il CTEM pone l’accento sul fatto che le condizioni di esposizione siano raggiungibili e realisticamente gestibili, e che la correzione delle vulnerabilità e i controlli modifichino in modo misurabile tale realtà. Il CTEM integra nella definizione delle priorità la fattibilità degli attacchi nel mondo reale, i controlli compensativi, la criticità delle risorse e l’accessibilità dei percorsi di attacco, fornendo così un contesto che i punteggi CVSS da soli non sono in grado di offrire.

Il CTEM modifica il modello operativo adottando un approccio proattivo, passando da valutazioni periodiche e segnalazione dei problemi a un ciclo continuo che individua gli aspetti rilevanti, verifica se le vulnerabilità possano essere sfruttate o consentire movimenti laterali, conferma l’efficacia dei controlli e avvia le azioni correttive con responsabilità ben definite.

La gestione tradizionale delle vulnerabilità individua i CVE e li classifica in base al livello di gravità CVSS. Ciò fornisce dei risultati, ma non risponde alla domanda che sta realmente a cuore ai responsabili della sicurezza: quali vulnerabilità può realisticamente sfruttare un aggressore per raggiungere le risorse critiche?

Il CTEM amplia la definizione di “esposizione” oltre le vulnerabilità, includendo qualsiasi lacuna che richieda misure di mitigazione. Una valutazione completa delle vulnerabilità tiene conto non solo delle vulnerabilità CVE non corrette, ma anche delle configurazioni errate, dei rischi legati all’identità, delle autorizzazioni eccessive, delle risorse esposte all’esterno, dello “shadow IT” o di qualsiasi altra condizione che un aggressore possa sfruttare. L'obiettivo non è quello di individuare ulteriori problemi. Consiste nel concentrare gli interventi correttivi sulle vulnerabilità che rivestono maggiore importanza per il Suo ambiente specifico.

[Scoprite come la gestione dell’esposizione si inserisca in una strategia di sicurezza più ampia]

Il CTEM non sostituisce la gestione delle vulnerabilità. Si tratta di un programma strutturato che integra i Suoi attuali flussi di lavoro relativi all’analisi, alla definizione delle priorità e alla correzione, basandosi sul contesto aziendale per renderli più efficaci. Il risultato: un minor numero di vulnerabilità non risolte, un intervento correttivo più rapido e investimenti nella sicurezza concentrati laddove il rischio è maggiore.

Per comprendere il valore aggiunto offerto dal CTEM occorre innanzitutto riconoscere i limiti degli approcci tradizionali.

Perché la gestione tradizionale delle vulnerabilità risulta insufficiente

Il problema non riguarda la copertura dei processi. Si tratta di una verifica. Sebbene molti programmi consolidati di gestione delle vulnerabilità e di gestione delle vulnerabilità prevedano in genere flussi di lavoro relativi alla scansione, alla definizione delle priorità e alla correzione, alcuni continuano a considerare conclusa la correzione una volta applicata la soluzione, spesso senza verificare che la vulnerabilità sia stata effettivamente eliminata.

[Discover : come funziona la correzione automatizzata delle vulnerabilità, perché i confini della governance sono importanti e in che modo l’implementazione graduale aiuta le organizzazioni a colmare le lacune di esposizione senza creare nuovi rischi operativi]

Ciò crea un punto cieco critico tra l’azione e il risultato. In assenza di una convalida continua, i team potrebbero ritenere che il rischio sia stato ridotto, mentre in realtà l’esposizione sottostante persiste a causa di implementazioni non riuscite, scostamenti nella configurazione o correzioni incomplete.

I modelli di valutazione periodica ampliano ulteriormente questo divario. In molti contesti, le scansioni pianificate possono lasciare delle lacune in cui persistono esposizioni nuove o modificate fino al ciclo di raccolta successivo, in particolare in ambienti cloud, SaaS e di gestione delle identità in rapida evoluzione. Gli hacker non attendono che si esegua la scansione programmata.

L’utilizzo di strumenti isolati frammenta il contesto. Gli scanner, i rapporti sui test di penetrazione, gli inventari delle risorse e i sistemi di gestione dei ticket spesso non condividono i dati. I team di sicurezza finiscono per cercare manualmente di mettere in relazione i risultati ottenuti da strumenti non integrati tra loro, al fine di ricostruire un quadro coerente di ciò che è effettivamente a rischio.

La definizione delle priorità basata esclusivamente sulla gravità genera backlog inattuabili. Un punteggio CVSS indica, in linea di principio, la gravità potenziale di una vulnerabilità. Non Le indica se tale vulnerabilità sia presente su una risorsa in grado di accedere ai Suoi controller di dominio, né se sia in circolazione un exploit attivo.

Non vi è alcuna verifica che dimostri che i controlli funzionino effettivamente. La maggior parte dei programmi tiene traccia dell’eventuale applicazione di una patch. Sono pochi coloro che confermano se l’esposizione sia effettivamente chiusa. Un file ` CVE ` aggiornato su un sistema configurato in modo errato potrebbe comunque essere accessibile tramite un percorso diverso.

In ambito CTEM, il termine “convalida” può comprendere la verifica dell’effettiva sfruttabilità di una vulnerabilità nell’ambiente, la conferma della copertura dei controlli rispetto alle tecniche pertinenti e la nuova verifica della risorsa o dello stato specifico dopo la correzione

Il divario organizzativo. I team di sicurezza individuano eventuali anomalie. I team operativi IT sono responsabili delle misure correttive. In assenza di flussi di lavoro condivisi e di una governance adeguata, le vulnerabilità convalidate rimangono in coda in attesa di una finestra di aggiornamento di cui il reparto di sicurezza non ha alcuna visibilità.

Per i CISO, questa lacuna organizzativa rappresenta spesso il problema più difficile da risolvere. Si tratta di una sfida che riguarda tanto la governance, la gestione dei rischi e la responsabilità quanto gli aspetti tecnici.

Il CTEM affronta ciascuna di queste lacune considerando l’esposizione al rischio di " " e la riduzione dell’ e come un programma continuo e integrato. La sezione seguente illustra in dettaglio il funzionamento di ciascuna fase.

[Scoprite di più sulla metodologia di gestione delle minacce e delle vulnerabilità]

Le cinque fasi del CTEM

Le cinque fasi del processo CTEM formano un ciclo continuo. Ogni fase alimenta quella successiva e il ciclo si ripete man mano che il contesto cambia e le minacce emergenti richiedono un aggiornamento delle priorità relative alla definizione dell’ambito, all’individuazione e alla convalida.

Comprendere l’intero ciclo di vita di un ciclo CTEM, dalla definizione iniziale dell’ambito fino alla correzione convalidata, è essenziale per progettare un programma che produca una riduzione misurabile del rischio, anziché limitarsi a un’attività ricorrente.

1. Definizione dell'ambito

La definizione dell’ambito di indagine stabilisce quali parti dell’ambiente saranno valutate e in che modo verrà misurata l’esposizione. Non si tratta solo di un esercizio tecnico. Ciò richiede un accordo tra i responsabili della sicurezza e le parti interessate del settore aziendale su quali livelli di risorse rientrino nell’ambito di applicazione di ciascun ciclo, sulla base tanto degli obiettivi aziendali quanto dei rischi tecnici.

Le decisioni relative all’ambito di applicazione dovrebbero essere riesaminate regolarmente man mano che le priorità aziendali evolvono. Una fusione, il lancio di un nuovo prodotto o il passaggio al lavoro da remoto possono tutti modificare quali risorse risultino più critiche e, di conseguenza, quali rischi richiedano l’attenzione più urgente.

L'esecuzione di scansioni continue su tutti i sistemi in ambienti distribuiti comporta alcuni compromessi, tra cui l'impatto sulla rete e il volume degli avvisi. La definizione dell’ambito di applicazione richiede un accordo negoziato su quali livelli di risorse debbano essere oggetto di copertura continua, quali debbano essere sottoposti a valutazione periodica e chi abbia l’autorità di adeguare l’ambito di applicazione man mano che l’ambiente cambia.

Cosa significa "continuo" in termini operativi?
Non tutti i segnali di un programma CTEM vengono aggiornati con la stessa frequenza. Alcune fonti di dati, quali endpoint (stato e dati telemetrici), possono fornire informazioni quasi in tempo reale, mentre altre (come e le scansioni di vulnerabilità) continuano a essere periodiche. Le organizzazioni devono definire soglie accettabili di attualità dei dati per ciascun livello di asset. Se una fonte di dati risulta sistematicamente obsoleta, i suoi risultati dovrebbero essere considerati meno attendibili fino a quando non vengono nuovamente convalidati.
I programmi CTEM spesso falliscono quando i team danno per scontato che tutti i dati in ingresso siano ugualmente aggiornati. In pratica, per garantire l’accuratezza è necessario aggiornare costantemente i dati di inventario e verificare la titolarità e il contesto dei beni.

Le informazioni di intelligence sulle minacce orientano le decisioni relative alla definizione dell’ambito d’intervento, mettendo in evidenza quali tipi di risorse siano attivamente presi di mira. Man mano che il panorama delle minacce evolve (ad esempio, quando gli autori delle minacce iniziano a prendere di mira attivamente i dispositivi VPN), tali tipologie di risorse acquisiscono maggiore priorità nell’ambito del ciclo attuale.

[Discover : in che modo le informazioni sulle minacce informatiche influenzano le decisioni in materia di sicurezza]

Un errore comune nelle fasi iniziali consiste nel considerare la definizione dell’ambito come un’operazione volta a “enumerare ogni cosa”. Nel CTEM, la fase di definizione dell’ambito (scoping) stabilisce quali siano gli aspetti rilevanti e come venga misurato il successo; la fase di analisi (discovery) individua ciò che esiste all’interno di tale ambito.

2. Scoperta

Asset La scoperta effettuata tramite CTEM mappa la superficie di attacco oltre il tradizionale inventario delle risorse, includendo vulnerabilità, configurazioni errate, risorse esposte all’esterno, shadow IT ed esposizioni delle identità.

In ambienti di grandi dimensioni e complessi, l’analisi di oltre 50.000 endpoint richiede in genere la combinazione di diversi metodi di raccolta dati, tra cui la telemetria di “ endpoint ” (ove gestita), i dati di rete e degli scanner, nonché le fonti del piano di controllo cloud o SaaS (API). Sia gli approcci basati su agenti che quelli senza agenti presentano dei compromessi, e i diversi ambienti — on-premise, cloud e ibrido — comportano sfide specifiche. Ciascun metodo presenta inoltre differenze in termini di copertura, attualità e affidabilità, in particolare per quanto riguarda gli asset effimeri.

L’IT ombra e i dispositivi non gestiti rappresentano spesso le lacune di visibilità più significative, poiché esulano completamente dalla copertura standard delle scansioni e sono pertanto i più suscettibili di nascondere vulnerabilità non individuate.

Le applicazioni SaaS pongono una sfida analoga. Le unità aziendali adottano spesso strumenti basati sul cloud senza coinvolgere i reparti IT o di sicurezza, creando così vulnerabilità che non compaiono mai negli inventari tradizionali delle risorse.

Asset L'identità e la titolarità rientrano tra i risultati di prim'ordine della vostra attività di ricerca. I risultati relativi all’esposizione che non possono essere ricondotti a un proprietario causano sistematicamente ritardi nella mobilitazione. Mantenere una mappatura autorevole tra gli identificatori tecnici (nome host, ID istanza, account, App tenant) e i team aziendali a cui essi appartengono.

Ecco perché la gestione della superficie di attacco esterna (EASM) è diventata un elemento fondamentale nella fase di individuazione. Gli strumenti EASM garantiscono una visibilità costante sulle risorse esposte a Internet, comprese quelle che potrebbero non figurare negli inventari interni.

Le vulnerabilità relative alle identità richiedono l’integrazione con i dati dei provider di identità, non solo un endpoint e scansione. Un account di servizio dotato di privilegi di amministratore di dominio che non viene utilizzato da 18 mesi può rappresentare un rischio, anche se non risulta rilevato da una scansione delle vulnerabilità.

3. Definizione delle priorità

La definizione delle priorità classifica i rischi in base alla vulnerabilità, all’impatto potenziale e alla rilevanza per gli aggressori, anziché basarsi esclusivamente sul livello di gravità CVSS.

È spesso difficile rendere operativi grandi volumi di risultati privi di contesto; per stabilire le priorità è necessario considerare la criticità delle risorse, i segnali di sfruttamento, il contesto di controllo e la rilevanza dei percorsi raggiungibili, al fine di concentrare gli sforzi. Una definizione efficace delle priorità in contesti reali richiede:

• Asset Livelli di criticità: Definiti dall’organizzazione, non dallo scanner
• Segnali relativi alla disponibilità di exploit: Ad esempio l’EPSS (Exploit Prediction Scoring System) e il catalogo delle vulnerabilità note come sfruttate della CISA
• Analisi del percorso di attacco: . Tale analisi identifica quali vulnerabilità consentono il movimento laterale verso le risorse strategiche

Un passo concreto per stabilire le priorità consiste nel distinguere le vulnerabilità accessibili da Internet da quelle accessibili internamente, che consentono il movimento laterale.

I rischi legati a Internet tendono a ricevere un'attenzione immediata. Tuttavia, le vulnerabilità accessibili internamente, quali i rischi legati all’identità, i privilegi eccessivi o le relazioni di fiducia configurate in modo errato, possono costituire vie di attacco di grande impatto nei confronti delle risorse critiche.

Una definizione efficace delle priorità tiene conto di entrambi gli aspetti. Essa pondera le vulnerabilità in base alla raggiungibilità e al loro ruolo nel consentire l’avanzata dell’autore dell’attacco, non solo in base alla gravità astratta.

L'analisi del percorso di attacco consiste nel processo volto a individuare in che modo un aggressore potrebbe concatenare più vulnerabilità per raggiungere obiettivi di alto valore. Questo contesto è fondamentale per il processo decisionale: sposta la definizione delle priorità da un semplice esercizio di valutazione meccanica a un giudizio basato sull’analisi dei rischi, volto a individuare quali esposizioni rappresentino la minaccia più concreta per le risorse aziendali critiche. Un " CVE " con un punteggio CVSS pari a 6 su una risorsa adiacente a un controller di dominio potrebbe richiedere una priorità maggiore rispetto a un CVSS pari a 9 su una macchina di sviluppo isolata.

4. Convalida

La validazione verifica se i controlli di sicurezza Detect o bloccano le tecniche associate alle vulnerabilità classificate in ordine di priorità e conferma se tali vulnerabilità rappresentino un rischio effettivo di attacco nell'ambiente. Inoltre, verifica se i controlli mitigano efficacemente tali rischi, avvalendosi di approcci quali il “purple teaming”, i test mirati o la simulazione di violazioni e attacchi (BAS).

A livello aziendale, le due modalità di convalida hanno finalità diverse:

• Convalida avversaria: Il “red teaming” e il BAS testano scenari di attacco specifici contro risorse critiche, simulando comportamenti realistici da parte degli avversari. È un processo periodico, che richiede un impiego intensivo di risorse e produce risultati altamente affidabili.
• Verifica continua delle azioni correttive (nuova verifica delle risorse/dello stato): Conferma che una specifica vulnerabilità sia stata risolta su una specifica risorsa. Può essere eseguito automaticamente dopo la correzione (laddove la telemetria e i flussi di lavoro lo consentano) e garantisce una verifica continua.

In pratica, le organizzazioni tendono in genere a privilegiare una modalità rispetto all’altra, anziché combinarle. La validazione avversaria è solitamente periodica (spesso annuale o trimestrale per gli scenari di alto valore), richiede un impiego intensivo di risorse e produce risultati altamente affidabili, mentre la verifica continua delle misure correttive viene attuata in modo meno sistematico.

Un esempio comune è rappresentato dai test di penetrazione: essi forniscono informazioni preziose su come un aggressore potrebbe sfruttare le vulnerabilità in un determinato momento, ma non confermano se tali vulnerabilità rimangano risolte man mano che l’ambiente cambia. Un test di penetrazione completato nel Q1 non attesta lo stato dei controlli nel Q3.

Ecco perché la convalida deve verificare il rispetto di due condizioni:

• Se la vulnerabilità possa effettivamente essere sfruttata nell'attuale contesto o se esistano controlli adeguati a impedire l'attuazione della tecnica di attacco
• Se l’esposizione rimanga chiusa nel tempo, tenendo conto delle variazioni di configurazione, delle nuove implementazioni o delle modifiche alle politiche che potrebbero reintrodurre il rischio

In assenza di entrambi i controlli, l’intervento correttivo può sembrare completato, mentre le condizioni di esposizione si ripresentano in modo impercettibile.

[Comprendere in che modo la ricerca delle minacce differisce dalla verifica]

5. Mobilitazione

Mobilization coordina le attività di risoluzione dei problemi tra i team di sicurezza e quelli informatici. Findings tradurre in azioni concrete, con responsabilità ben definite e scadenze precise.

Le priorità di bonifica dovrebbero rispecchiare gli obiettivi aziendali. Una vulnerabilità accertata su un sistema fondamentale per il fatturato richiede tempi di risposta diversi rispetto alla stessa vulnerabilità su uno strumento interno a bassa criticità.

È proprio in questa fase che la maggior parte dei programmi CTEM aziendali si arena. La sezione seguente affronta l'argomento in modo approfondito.

Il divario nella mobilitazione

La mobilitazione fallisce quando il reparto di sicurezza è responsabile dei risultati e il reparto operativo IT è responsabile delle misure correttive, ma nessuno dei due è responsabile del passaggio di consegne.

Lo schema è ben noto: il reparto sicurezza individua una vulnerabilità confermata, crea un ticket e attende, mentre il reparto operativo IT la aggiunge a un elenco di attività in sospeso e la programma per una futura finestra di modifica dell’ . Nel frattempo, l'esposizione rimane aperta.

Una mobilitazione efficace richiede inoltre percorsi di eccezione espliciti. Non tutte le esposizioni convalidate possono attendere le finestre di modifica standard.

Le organizzazioni dovrebbero definire i criteri in base ai quali i risultati ad alto rischio possano essere esclusi dai normali cicli di implementazione, unitamente a chiari processi di approvazione e di rollback. In assenza di tali percorsi di eccezione, gli esposti convalidati entrano in competizione con le attività operative di routine e spesso rimangono irrisolti nonostante siano stati considerati prioritari.

Requisiti di governance per la correzione automatizzata. Non tutti i risultati possono attivare una correzione automatica di . Le organizzazioni necessitano di politiche chiare che definiscano quali tipi di risultati possano essere corretti automaticamente e quali richiedano invece una revisione da parte della funzione di gestione del cambiamento.

Una sequenza di distribuzione progressiva, basata su anelli, contribuisce a limitare l’area di impatto. L'implementazione progressiva basata su anelli prevede che le modifiche procedano attraverso diversi anelli di implementazione: test, alta priorità e infine implementazione su larga scala. Ogni anello verifica la stabilità prima che inizi quello successivo.

L'integrazione ITSM è determinante per il successo della mobilizzazione. I risultati del CTEM devono essere integrati nel Suo sistema di gestione dei ticket esistente (ad esempio, “ServiceNow Vulnerability Response”) con un contesto sufficientemente dettagliato da consentire al personale IT di intervenire senza dover effettuare un’ulteriore fase di triage.

Il ticket deve includere l’esposizione specifica e le risorse interessate, il contesto aziendale e la criticità delle risorse, le azioni correttive raccomandate e lo SLA basato sul rischio convalidato.

La mobilitazione consiste nell'esecuzione coordinata delle azioni correttive avviate a seguito di un riscontro convalidato. Non si tratta di una risposta a un incidente causata da una minaccia attiva. Tale distinzione è rilevante ai fini della governance e della progettazione dei flussi di lavoro.

Detto questo, i risultati convalidati del CTEM dovrebbero costituire la base per i piani di risposta. Le organizzazioni che comprendono quali siano le proprie esposizioni al rischio più elevato sono in una posizione migliore per contenere gli incidenti e riprendersi da essi, qualora tali esposizioni venissero sfruttate prima che le misure correttive siano state completate.

Per colmare il divario in materia di mobilitazione non bastano i soli cambiamenti procedurali. Ciò richiede inoltre di ripensare il funzionamento della convalida.

Verifica delle esposizioni effettive

È proprio nel divario di convalida che la maggior parte dei programmi genera una falsa sicurezza. Monitorare l’applicazione delle toppe non equivale a confermare la chiusura dell’esposizione. Un sistema aggiornato potrebbe comunque essere raggiungibile attraverso un percorso di attacco diverso, qualora le configurazioni sottostanti o i percorsi di accesso rimangano invariati.

Una regola del firewall volta a bloccare una tecnica di attacco potrebbe, nella pratica, non riuscire effettivamente a bloccarla. Ecco perché la convalida deve andare oltre la semplice conferma dell’adozione delle misure di sicurezza. Deve confermare che siano efficaci contro le tecniche specifiche che un aggressore utilizzerebbe per sfruttare una determinata vulnerabilità. La validazione conferma il rischio effettivo, non solo la gravità teorica.

Le due modalità di convalida hanno finalità diverse:

1. Convalida avversaria: Il “red teaming” e il BAS verificano se specifici percorsi di attacco riescano a compromettere risorse critiche. Si tratta di un’attività che richiede un notevole impiego di risorse e che, in genere, viene svolta con cadenza trimestrale o annuale.
2. Verifica continua delle azioni correttive (nuova verifica delle risorse/dello stato): Conferma che una specifica vulnerabilità sia stata risolta su una specifica risorsa. Si avvia automaticamente al termine della correzione e garantisce un monitoraggio continuo.

L'analisi del percorso di attacco mette in relazione i due elementi. Indica quali esposizioni, se concatenate, consentono l’accesso alle risorse di punta dell’ . Questo contesto modifica l’ordine di priorità. Una vulnerabilità di media gravità su una risorsa che consente l'accesso ai Suoi controller di dominio è più urgente di una vulnerabilità critica su un sistema isolato.

Misurazione dell'efficacia dei controlli. Il controllo di sicurezza (regola del firewall, politica di “ EDR ”, patch) blocca effettivamente la tecnica di attacco associata alla vulnerabilità? Oppure blocca una tecnica diversa, lasciando aperta quella rilevante?

Una volta completata la validazione, la domanda successiva è: in che modo CTEM si integra con gli strumenti e i flussi di lavoro che già utilizzate?

Integrazione del CTEM nei flussi di lavoro esistenti

L’attuazione del programma CTEM come percorso parallelo rappresenta il modo più rapido per creare conflitti di priorità nelle operazioni IT. Il reparto Sicurezza sollecita un intervento correttivo immediato; il reparto IT opera con cicli di modifica di due settimane. L'obiettivo è l'integrazione nei flussi di lavoro esistenti, non la creazione di un nuovo percorso parallelo a essi.

Se implementato correttamente, il CTEM contribuisce a snellire le operazioni riducendo i passaggi di consegne manuali, eliminando le fasi di triage superflue e accelerando il trasferimento dei risultati convalidati alle attività di correzione.

• Integrazione ITSM: I risultati del CTEM vengono trasferiti nel Suo sistema di gestione dei ticket esistente. La struttura del ticket è fondamentale: deve fornire un contesto sufficientemente dettagliato (criticità delle risorse, rischio verificato, azione raccomandata, SLA) affinché il personale addetto alle operazioni IT possa intervenire senza necessità di un ulteriore passaggio di consegne.
• SIEM come input per la definizione dell’ambito e la fase di analisi iniziale: , i dati relativi a SIEM , l’attività delle minacce attive , e i comportamenti anomali che consentono di individuare le risorse rientranti nell’ambito del ciclo CTEM in corso. Si tratta di un input per il programma, non di un suo sostituto.
• Come evitare il problema dei processi paralleli: Le organizzazioni che gestiscono il CTEM come un programma di sicurezza separato creano conflitti di priorità per le operazioni IT. Il reparto di sicurezza si aspetta che il problema venga risolto immediatamente. Il reparto IT opera con cicli di aggiornamento di due settimane. In assenza di una gestione delle eccezioni per i risultati critici convalidati, il conflitto è di natura strutturale.
• Compatibilità con la gestione del cambiamento IT: L’implementazione progressiva a anelli e le finestre di cambiamento sono compatibili con la mobilitazione CTEM, purché il modello di governance sia stato progettato a tal fine. La chiave sta nel definire percorsi alternativi per i risultati critici convalidati che non possono attendere la successiva finestra temporale programmata.

Il CTEM raggiunge la massima efficacia quando opera come livello di collegamento all’interno del vostro stack di sicurezza: raccogliendo dati da SIEM, scanner di vulnerabilità, provider di identità e sistemi di gestione delle risorse, per poi trasmettere i risultati, prioritizzati e convalidati, all’ITSM ai fini di una risoluzione coordinata.

Questo passaggio verso flussi di lavoro integrati riflette le tendenze più generali del mercato. Le organizzazioni stanno abbandonando gli strumenti puntuali e frammentati a favore di piattaforme che unificano le fasi di individuazione, definizione delle priorità, convalida e correzione. L'obiettivo è quello di trasformare i rischi accertati in azioni coordinate, promuovendo una cultura della sicurezza proattiva.

Una volta integrato il CTEM nei flussi di lavoro esistenti, il passo successivo consiste nel valutare lo stato attuale del vostro programma.

Maturità del programma CTEM

A che punto è oggi il Suo programma? Tre livelli di maturità costituiscono un quadro di riferimento per l’autovalutazione.

Livello 1: Ad hoc/reattivo

Le analisi delle vulnerabilità vengono eseguite periodicamente. Findings vengono classificate in base alla priorità esclusivamente in base al CVSS. Non è chiaro a chi spetti la responsabilità della bonifica. Non esiste alcuna verifica formale che confermi l'efficacia delle correzioni. A questo livello, i rischi per la sicurezza vengono affrontati in modo reattivo, in genere a seguito di un incidente o di un riscontro emerso da un audit, piuttosto che attraverso un programma strutturato e continuativo. I reparti di sicurezza e IT operano su sistemi distinti, con passaggi di consegne effettuati manualmente.

Livello 2: Periodico/strutturato

I programmi di scansione definiti sono collegati ai livelli di criticità delle risorse. Risk La definizione delle priorità basata su tiene conto del contesto delle risorse. Esiste una procedura formale di gestione dei ticket tra il reparto sicurezza e quello informatico. I test di penetrazione o il BAS vengono eseguiti almeno una volta all'anno. Per i risultati critici viene monitorato il tempo medio di riparazione (MTTR).

Livello 3: Continuo / automatizzato

Al Livello 3, il programma opera come un sistema continuo e autoalimentato: visibilità in tempo reale sull’intera popolazione dell’ endpoint, definizione automatizzata delle priorità tramite i dati EPSS e CISA KEV, integrazione ITSM con creazione automatica dei ticket e monitoraggio degli SLA, verifica continua delle azioni correttive, governance dell’implementazione basata su anelli e metriche di mobilitazione riportate a livello di programma. Il risultato è un’operazione di sicurezza in cui la riduzione del rischio è misurabile, non merely ipotizzata.

Ciò che porta un’organizzazione a passare dal Livello 1 al Livello 2 è solitamente una decisione di governance, non una scelta relativa agli strumenti. La definizione dei livelli di criticità delle risorse, la definizione dei modelli di titolarità e la creazione di flussi di lavoro formali per il passaggio di consegne non richiedono l’adozione di nuove tecnologie.

Ciò che consente a un’organizzazione di passare dal Livello 2 al Livello 3 è solitamente una scelta relativa agli strumenti e all’integrazione. La visibilità in tempo reale, la definizione automatica delle priorità e la convalida continua richiedono funzionalità della piattaforma che gli strumenti di scansione periodica non offrono.

Indipendentemente dal livello di maturità, l’obiettivo è lo stesso: concentrare gli sforzi in materia di sicurezza sulle vulnerabilità che comportano il rischio più concreto per l’azienda, anziché intraprendere attività che non si traducono in una riduzione misurabile del rischio.

I livelli di maturità costituiscono un quadro di riferimento per l’autovalutazione. Gli indicatori consentono di monitorare i progressi.

Come misurare il successo del CTEM

Gli indicatori che contano sono quelli relativi ai risultati, non quelli relativi alle attività. Il volume dei ticket e la frequenza di scansione indicano il livello di attività del programma. Il tempo medio di riparazione (MTTR) relativo ai risultati critici convalidati Le consente di verificare se il sistema funziona correttamente.

Le organizzazioni di livello 2 monitorano in genere l'andamento dell'MTTR e del punteggio di rischio. Le organizzazioni di livello 3 aggiungono la copertura di convalida e la durata della finestra di esposizione come indicatori primari.

Una volta chiarito cosa richieda il CTEM e come misurarne i progressi, la domanda finale è: in che modo le diverse piattaforme supportano tale quadro di riferimento?

In che modo “ Tanium ” supporta la gestione continua dell’esposizione alle minacce

Molti programmi CTEM subiscono una battuta d’arresto perché gli strumenti utilizzati per individuare le esposizioni non sono gli stessi utilizzati per porvi rimedio. Tanium contribuisce a colmare tale divario.

Tanium 'La piattaforma IT autonoma offre ai team di sicurezza e IT un’unica piattaforma unificata per l’individuazione, la definizione delle priorità, la correzione e la verifica post-correzione, in modo che il ciclo si svolga senza passaggi di consegne a sistemi scollegati né attese per l’aggiornamento di dati di scansione obsoleti.

Individuazione continua grazie all’intelligenza in tempo reale di endpoint

Tanium offre una visibilità in tempo reale sullo stato dell’ endpoint e gestita, consentendo ai team di identificare le risorse e le modifiche man mano che si verificano, anziché affidarsi esclusivamente a scansioni periodiche. Tanium può estendere la copertura ai dispositivi non gestiti in ambienti on-premise, remoti e cloud, contribuendo a ridurre i punti ciechi comunemente associati allo “shadow IT”.

Risk-definizione delle priorità informata e basata sul contesto

Tanium sostiene la definizione delle priorità basata sull’analisi dei rischi attraverso diverse funzionalità. Ad esempio, , Tanium e Benchmark consentono di determinare i punteggi di rischio in tempo reale e di confrontare i dati di un cliente con quelli dei suoi omologhi del settore, aiutando i team a concentrare gli interventi correttivi laddove il rischio è più elevato rispetto al proprio ambiente. Tanium Guardian può aiutare le organizzazioni ad affrontare le vulnerabilità zero-day e quelle che richiedono un intervento tempestivo, combinando l’analisi in tempo reale di endpoint con analisi mirate e opzioni di risoluzione fornite dagli esperti di sicurezza di Tanium'.

Dalla valutazione all’azione su un’unica piattaforma

Tanium consente ai team di passare dall’identificazione delle vulnerabilità all’adozione di misure correttive senza dover cambiare strumenti o fonti di dati. Findings È possibile intervenire direttamente all’interno della stessa piattaforma, tra cui gestione delle patch o modifiche alla configurazione, contribuendo così a ridurre i tempi tra il rilevamento e la risoluzione del problema.

Verifica continua della riduzione del rischio

Anziché dare per scontato che le misure correttive siano efficaci, “ Tanium ” offre ai team la possibilità di verificare le variazioni nello stato dell’ endpoint e a seguito delle azioni intraprese, utilizzando gli stessi dati in tempo reale impiegati per il rilevamento. Ciò consente di verificare costantemente se le esposizioni siano state effettivamente ridotte, e non solo se gli interventi di bonifica siano stati registrati come completati.

Domande frequenti sul CTEM

La creazione di un programma CTEM solleva interrogativi concreti sui vantaggi del CTEM, su come si collochi rispetto a quanto già in uso, su cosa sia effettivamente necessario per gestirlo e se l’investimento si traduca in una riduzione misurabile del rischio. Ecco ciò che deve sapere.

Qual è la differenza tra il CTEM e la gestione tradizionale delle vulnerabilità?

La gestione delle vulnerabilità si concentra sull’identificazione e sulla correzione delle vulnerabilità note (spesso CVE) secondo un calendario prestabilito.

Il CTEM è un modello operativo di ampio respiro che identifica costantemente gli aspetti rilevanti, individua le condizioni di vulnerabilità lungo l’intera superficie di attacco, stabilisce le priorità in base alla probabilità effettiva di attacco e all’impatto sul business, verifica la sfruttabilità delle vulnerabilità e l’efficacia dei controlli e avvia le azioni correttive con una chiara attribuzione delle responsabilità.

Qual è la differenza tra ASM e CTEM?

La gestione della superficie di attacco (ASM) si concentra sull’individuazione e l’inventario delle risorse esposte all’esterno e delle relative vulnerabilità, mentre il CTEM opera come un programma completo che include le esposizioni sia interne che esterne, verifica se queste rappresentino un rischio concreto e coordina le misure correttive attraverso i flussi di lavoro IT esistenti.

Quali strumenti supportano un programma CTEM?

Il CTEM non è una categoria di prodotti, bensì un programma che abbraccia diverse tipologie di strumenti, collegati a ciascuna delle cinque fasi del ciclo:

• La definizione dell’ambito di applicazione si avvale di piattaforme di intelligence sulle minacce, CMDB e , di sistemi di inventario delle risorse e di dati provenienti da SIEM per stabilire quali livelli di risorse rientrino nell’ambito di applicazione di ciascun ciclo e quali siano quelli più attivamente presi di mira.
• Il processo di individuazione (Discovery) richiede scanner di vulnerabilità, piattaforme di gestione delle informazioni sulla sicurezza ( endpoint ) basate su agenti, strumenti EASM e dati dei provider di identità.
• Gli strumenti di definizione delle priorità devono integrare l’EPSS e il catalogo KEV della CISA, oltre all’analisi dei percorsi di attacco, e non limitarsi ai punteggi CVSS.
• La convalida (la lacuna più comune) richiede strumenti di simulazione di violazioni e attacchi (BAS) o funzionalità di verifica continua delle misure correttive che confermino che una specifica correzione abbia risolto una specifica vulnerabilità, e non solo che sia stata applicata una patch.
• La mobilitazione dipende dall’integrazione con l’ITSM (ServiceNow rappresenta un percorso aziendale comune), con un contesto sufficientemente dettagliato in ciascun ticket affinché il personale addetto alle operazioni IT possa intervenire senza una fase secondaria di triage.

Ed è proprio quest’ultima funzionalità — ovvero la conferma che l’esposizione sia effettivamente chiusa — che la maggior parte delle suite di strumenti non garantisce ancora in modo coerente.

In che modo la gestione continua dell’esposizione alle minacce migliora la resilienza della sicurezza informatica?

Il CTEM mira a migliorare la resilienza riducendo l’intervallo di tempo che intercorre tra il momento in cui si verifica un’esposizione ad alto rischio e quello in cui se ne conferma la cessazione. I cicli continui sostituiscono i programmi di scansione periodici che lasciano nuove vulnerabilità non individuate per giorni o settimane. Risk- Una definizione delle priorità informata, che tenga conto della criticità delle risorse, della disponibilità degli exploit e dell’analisi dei percorsi di attacco, concentra gli sforzi di correzione sulle vulnerabilità che possono effettivamente raggiungere le risorse critiche, anziché generare un elenco di attività arretrate classificate in base a punteggi di gravità astratti.

Uno dei vantaggi meno evidenti della resilienza informatica è l’efficacia comprovata dei controlli. Un sistema aggiornato su un host configurato in modo errato potrebbe comunque essere vulnerabile a un attacco attraverso un percorso diverso. La fase di convalida del CTEM conferma che i controlli siano efficaci contro le tecniche specifiche associate a una determinata esposizione, e non solo che un intervento di bonifica sia stato registrato come completato.

Le organizzazioni che effettuano verifiche continue si trovano in una posizione migliore durante la risposta agli incidenti, poiché hanno già verificato quali misure di protezione si dimostrano efficaci in condizioni realistiche, anziché scoprirlo nel momento in cui è più importante.

Scoprite in che modo le informazioni in tempo reale sull’ endpoint e supportano il vostro programma CTEM. Prenoti una demo all’indirizzo per scoprire in che modo Tanium aiuta le organizzazioni a ridurre l’esposizione grazie a una visibilità continua e a misure correttive integrate.