CTEM: cos'è il Continuous Threat Exposure Management

La risposta breve: CTEM (continuous threat exposure management) è un programma di sicurezza, non un prodotto, che individua in modo continuo le esposizioni di un'azienda e le mette in ordine in base a quanto sono davvero sfruttabili e a quanto colpirebbero il business. Lo ha descritto Gartner in cinque fasi: perimetro, scoperta, priorità, validazione e mobilitazione. L'obiettivo non è correggere tutto, ma correggere prima ciò che conta.

Se arrivi qui perché un vendor ti ha parlato di CTEM o di exposure management, questa guida ti dice da dove viene il termine, cosa cambia rispetto alla gestione delle vulnerabilità che già fai, cosa succede in ciascuna fase, che ruolo ha il cloud e come partire con le persone che hai.

Da dove viene il CTEM?

Il termine è di Gartner. Secondo Wiz, la società di analisi ha introdotto il framework nel 2022; il riferimento pubblico di Gartner è l'articolo How to Manage Cybersecurity Threats, Not Episodes del 21 agosto 2023, firmato da Kasey Panetta, con un commento dell'analista Jeremy D'Hoinne.

Il punto di partenza dell'articolo è semplice: nessuna organizzazione può coprire ogni singolo evento. Rincorrere le minacce con patch e controlli, una alla volta, tiene occupati ma raramente riduce l'esposizione futura. Serve invece un programma che faccia emergere e metta in priorità ciò che minaccia di più il business, e che lo faccia sempre, non una volta all'anno.

D'Hoinne lo riassume così, in sintesi: le organizzazioni non possono correggere tutto, e non possono nemmeno essere sicure di quali correzioni sia prudente rimandare. Il CTEM è il metodo per decidere, di continuo, dove sta il confine.

Che differenza c'è tra CTEM e vulnerability management?

La gestione delle vulnerabilità classica lavora su una lista: si scansiona, si ordina per gravità tecnica (di solito il punteggio CVSS), si corregge dall'alto. Il metodo funziona, ma ha tre limiti che il CTEM prova a togliere.

• È periodica. Una scansione mensile o trimestrale fotografa un momento. Quello che nasce tra una scansione e l'altra resta invisibile, ed è un problema soprattutto nel cloud, dove le risorse cambiano ogni giorno.
• Guarda solo le vulnerabilità. Gartner chiede di allargare lo sguardo oltre il perimetro tipico di questi programmi (account social aziendali, repository di codice, sistemi integrati con la catena di fornitura) e di cercare anche configurazioni sbagliate e altri rischi, non solo vulnerabilità note.
• Ordina per gravità, non per rischio. Una vulnerabilità critica su un server isolato e senza dati pesa meno di una media su una macchina esposta su internet che porta al database dei clienti. La lista CVSS non lo vede.

Il CTEM non butta via il vulnerability assessment: lo usa come una delle fonti della fase di scoperta, e aggiunge sopra il contesto di business e la verifica di cosa è davvero sfruttabile.

Quali sono le cinque fasi del CTEM?

Gartner descrive il programma in cinque passi. I primi due definiscono cosa guardare, gli altri tre decidono cosa fare.

1. Scoping: definire il perimetro

Si parte dalla superficie d'attacco, cioè dai punti di ingresso e dagli asset che un attaccante potrebbe usare. Non solo server e applicazioni: anche elementi meno tangibili come gli account social aziendali, i repository di codice online e i sistemi integrati con i fornitori.

Per un primo progetto Gartner suggerisce di non partire da tutto, ma da una delle due aree che indica per un progetto pilota: la superficie d'attacco esterna, cioè quello che si vede da internet, che unisce un perimetro relativamente ristretto a un ecosistema di strumenti in crescita, oppure la postura di sicurezza del SaaS, diventata centrale da quando molti dati di business vivono in applicazioni cloud usate da chi lavora da remoto.

2. Discovery: trovare asset e rischi

Dentro il perimetro scelto si cercano gli asset visibili e nascosti, le vulnerabilità, le configurazioni sbagliate e gli altri rischi. Qui Gartner segnala quello che spesso è il primo errore quando si costruisce un programma CTEM: confondere perimetro e scoperta. Il numero di asset e vulnerabilità trovati non è un risultato in sé. Conta di più aver scelto bene il perimetro in base al rischio e all'impatto per l'azienda.

3. Prioritization: scegliere cosa sistemare prima

Lo scopo dichiarato non è correggere ogni problema. Gartner elenca i fattori che devono pesare sulla priorità: urgenza, sicurezza, disponibilità di controlli compensativi, tolleranza per la superficie d'attacco residua e livello di rischio per l'organizzazione. Il punto di partenza sono gli asset di maggior valore per il business: la priorità si costruisce attorno a loro.

Due fonti pubbliche aiutano a portare dati veri in questa fase:

• Il catalogo KEV (Known Exploited Vulnerabilities) della CISA, l'agenzia di cyber security statunitense, che raccoglie le vulnerabilità di cui è stato osservato lo sfruttamento reale. La CISA stessa raccomanda di usarlo come input del proprio schema di priorità.
• L'EPSS (Exploit Prediction Scoring System) del FIRST, un modello che stima la probabilità che una CVE pubblicata venga sfruttata nei 30 giorni successivi, con un valore tra 0 e 1.

Messi accanto al CVSS e al valore dell'asset, questi segnali separano il rumore da ciò che un attaccante userebbe davvero.

4. Validation: verificare che l'attacco funzioni

Prima di mobilitare i team si conferma che l'esposizione sia sfruttabile, si analizzano tutti i percorsi possibili verso l'asset e si verifica se il piano di risposta sarebbe abbastanza rapido. Gli strumenti sono quelli noti: il penetration test, le simulazioni di attacco, l'analisi dei percorsi di attacco sul grafo delle risorse.

Gartner aggiunge un punto organizzativo che spesso si salta: mettere d'accordo tutte le parti interessate su quali condizioni fanno scattare una correzione. Se la regola è condivisa prima, la discussione non si riapre a ogni ticket.

5. Mobilization: far succedere le correzioni

L'ultima fase porta i risultati a chi deve agire. Gartner avverte di non contare solo sulla correzione automatica, che ha senso per i problemi ovvi e poco invasivi: il piano va spiegato al team di sicurezza e alle funzioni di business, e vanno tolti gli ostacoli ad approvazioni, rilasci e mitigazioni. In particolare, i flussi di approvazione tra team vanno scritti.

È la fase in cui la maggior parte dei programmi si inceppa, perché chi trova il problema raramente è chi possiede la risorsa da correggere.

Il CTEM è uno strumento?

No, ed è la confusione più frequente. Il CTEM è un ciclo di lavoro che si appoggia a più strumenti, ognuno forte in una fase:

• Attack surface management esterno per scoprire cosa è esposto su internet.
• Scanner di vulnerabilità per i sistemi interni e gli endpoint.
• CNAPP per il cloud: configurazioni, workload, permessi, dati e percorsi di attacco in un unico modello. Se la sigla è nuova, parti da CNAPP, cos'è e quali componenti ha.
• Penetration test e simulazioni per la validazione.
• Ticketing e processi per la mobilitazione.

Molti vendor oggi vendono piattaforme di exposure management che coprono più fasi insieme. Sono utili, ma la scelta del perimetro, l'accordo sulle soglie e il lavoro con i team restano compiti di persone.

Che ruolo ha il cloud in un programma CTEM?

Il cloud è spesso il posto migliore per partire, per due ragioni. Cambia più in fretta di qualunque altra parte dell'infrastruttura, quindi le scansioni periodiche ci invecchiano subito. E le sue risorse sono descritte da API, quindi un inventario completo e continuo è possibile senza installare niente.

Le piattaforme di cloud security più mature lavorano già con la logica del CTEM. Security Command Center di Google Cloud, nel livello Premium, permette di definire un insieme di risorse di alto valore (high-value resource set) e fa girare simulazioni dei percorsi di attacco circa ogni sei ore, e comunque almeno una volta al giorno, per calcolare i punteggi di esposizione di risorse e segnalazioni. È la fase di priorità applicata in continuo.

Wiz, nella sua Academy, descrive il CTEM come un programma in cinque fasi che individua, valida e mette in priorità le esposizioni in base alla sfruttabilità reale, e presenta la propria piattaforma come il modo di unire in una sola vista i rischi di cloud, codice, ambienti on premise e AI. Si collega ai cloud via API, senza agenti, e costruisce la mappa delle risorse e dei permessi su cui si calcolano i percorsi di attacco. Google ha completato l'acquisizione di Wiz l'11 marzo 2026, mantenendo il marchio e il supporto ai principali cloud, compresi AWS, Microsoft Azure e Oracle, come scritto nell'annuncio di Google Cloud. Per il quadro completo c'è Wiz, cos'è.

CTEM e NIS2: c'è un legame?

La NIS2 non nomina il CTEM, e nessuna norma lo impone. Ma il metodo risponde a obblighi precisi. L'art. 24, comma 2, del D.Lgs. 138/2024 chiede misure che comprendano almeno, tra gli altri elementi, la gestione e la divulgazione delle vulnerabilità (lettera e) e politiche e procedure per valutare l'efficacia delle misure di gestione dei rischi (lettera f). Il comma 4 aggiunge che un soggetto che rileva di non essere conforme adotta senza indebito ritardo le misure correttive necessarie.

Un ciclo che scopre, mette in priorità, valida e chiude le esposizioni, lasciando traccia di ogni decisione, produce proprio le evidenze che servono a dimostrare queste tre cose. Il resto degli obblighi è nella guida completa alla NIS2.

Come si parte con il CTEM in un'azienda mid-market?

Non serve un programma completo dal primo giorno. Serve un primo giro fatto bene su un perimetro piccolo.

1. Scegli un perimetro solo. Gartner indica superficie esterna o SaaS. Se i tuoi workload girano su AWS, Google Cloud o Azure, il cloud è un candidato altrettanto sensato: è dove le esposizioni nascono più in fretta.
2. Nomina gli asset che contano. Pochi: il database dei clienti, il gestionale, i sistemi di produzione, le chiavi dei pagamenti. Tutto il resto si pesa rispetto a loro.
3. Fai una prima scoperta e guarda i percorsi, non le liste. La domanda giusta è quali combinazioni di esposizione, vulnerabilità e permessi arrivano a quegli asset.
4. Concorda le soglie prima dei ticket. Cosa si corregge entro quanto, chi approva, quando si accetta un rischio residuo e chi lo firma.
5. Ripeti il ciclo e allarga. Il valore sta nella continuità: il secondo giro costa meno del primo, e il terzo inizia a mostrare se l'esposizione scende davvero.

Gli errori che svuotano un programma CTEM

• Misurare il successo con il numero di problemi trovati. Gartner lo dice in chiaro: il volume non è un risultato.
• Comprare una piattaforma e chiamarla CTEM. Senza perimetro, soglie e mobilitazione resta un'altra dashboard.
• Saltare la validazione. Senza verifica si discute di ogni ticket, e i team smettono di fidarsi delle priorità.
• Lasciare la correzione senza proprietario. Ogni esposizione ha bisogno di un team che la possiede e di una scadenza.

In sintesi

In sintesi: il CTEM è il modo di passare da una lista di vulnerabilità a un ciclo continuo che sceglie un perimetro, scopre cosa c'è, mette in priorità ciò che è sfruttabile e pesa sul business, lo verifica e lo fa correggere da chi possiede le risorse. Il cloud è spesso il posto giusto per cominciare. AmagisTech è partner Wiz: se vuoi vedere quali esposizioni del tuo cloud formano un percorso di attacco reale, parti dalla fotografia del cloud con Wiz, via API e senza agenti.