Che cos'è il CTEM (Continuous Threat Exposure Management)?

1. Scoping — definisci la fetta di attack surface in focus per questo ciclo. Asset esposti su internet, una business unit critica, una controllata appena acquisita, una pipeline AI, l'edge SaaS — lo scoping è business-driven, non asset-driven.

2. Discovery — enumera tutto ciò che è in scope: host, servizi, identità, secret, connessioni terze parti, data flow. La discovery moderna include shadow IT, workload cloud effimeri e grant OAuth SaaS-to-SaaS che gli asset inventory classici non vedono.

3. Prioritization — classifica le esposizioni per *sfruttabilità nel tuo ambiente*, non per CVSS isolato. Un CVSS 9.8 dietro due livelli di segmentazione e MFA ha priorità minore di un CVSS 6.5 raggiungibile da internet su endpoint non autenticato.

4. Validation — dimostra che il finding è sfruttabile. È lo stage su cui le decisioni di toolchain vivono o muoiono: uno scanner di vulnerabilità produce una lista, un automated red-team / Breach and Attack Simulation (BAS) / pentest generativo produce evidenza. Board e regolatori chiedono la seconda.

5. Mobilization — converti i finding validati in remediation tracciata e time-boxed. Creazione ticket, definizione SLO, retest gating e chiusura con evidenza crittografica sono tutti in scope. Un programma che si ferma a "abbiamo trovato questi" non è un programma CTEM.

La vulnerability management classica produce una lista di finding ordinata per CVSS. Il pentest classico produce un report puntuale. Il CTEM produce un ledger di esposizione aggiornato in continuo, con proof-of-exploitability per voce e un trend di riduzione misurabile.

La conseguenza pratica in procurement: un CISO che presenta "abbiamo pagato €40k per un pentest a marzo" non soddisfa più un board che ha letto le RTS EBA 2025 o la guida CTEM di Gartner. Il board ora si aspetta un grafico trimestrale di riduzione esposizione con evidenza firmata dietro ogni voce chiusa. Il CTEM è il modello operativo che produce quel grafico per costruzione.

L'altro shift pratico è il gate di validazione. Uno scanner può dichiarare 10.000 issue; senza validazione, la maggior parte è rumore. Un board a cui viene chiesto di finanziare 10.000 fix non ne finanzia nessuno. Un board a cui mostri 47 esposizioni *validate sfruttabili* finanzia il programma — e i dati operativi degli studi sui costi degli incidenti pubblicati fino al 2025 lo confermano.

NIS2 — l'art. 21 richiede misure tecniche e organizzative "adeguate e proporzionate", con il testing continuo implicito. Le trasposizioni nazionali (in particolare il Decreto Legislativo 138/2024 italiano) attaccano responsabilità personale al vertice per garantire l'efficacia — non l'esistenza cartacea — dei controlli. La metrica trend-di-esposizione del CTEM è l'unità di reporting operativo di cui i board hanno davvero bisogno.

DORA art. 25 — richiede esplicitamente testing continuo dei sistemi ICT critici per le entità finanziarie significative. Le RTS EBA 2025 sono chiare: "continuo" significa continuo, informato da threat intelligence corrente. Il loop scoping + discovery + validation del CTEM è l'implementazione di riferimento; il TLPT è l'esercizio formale che conferma che il loop funziona.

AI Act — l'art. 72 sul post-market monitoring per sistemi AI ad alto rischio richiede tracking continuo di performance ed esposizione a incidenti. Quando il sistema AI è esso stesso uno strumento di security, il CTEM si applica ricorsivamente: il tool dev'essere validato in continuo, come gli asset che monitora.

In tutti e tre i regimi, l'artefatto auditable è lo stesso: un ledger di riduzione esposizione firmato, datato e coprente il periodo richiesto dal regolatore. I programmi che lo spediscono come sottoprodotto dell'operazione normale passano l'internal audit al primo colpo; quelli che lo assemblano a mano al momento dell'audit falliscono.

Un modello pratico di partenza usato dagli operatori con cui lavoriamo:

• Giorni 1–14 — scoping. Scegli una fetta business-critical. Attack surface esterna per una PMI; una singola business unit regolata per un'org più grande. Definisci la metrica (conteggio esposizioni, pesato per sfruttabilità e impatto business) e la cadenza (discovery settimanale o bisettimanale, review mensile).
• Giorni 15–30 — discovery + baseline. Esegui una discovery continua automatizzata sullo scope; produci il primo baseline ledger di esposizione. Aspettati di essere sorpreso — la maggior parte delle prime baseline scopre asset che l'inventory non listava.
• Giorni 31–60 — ciclo di validazione 1. Prendi le top 50 esposizioni prioritizzate; valida ciascuna (BAS, agenti pentest generativi, manuale dove serve). La maggior parte non sarà sfruttabile nell'ambiente reale; quelle che lo sono diventano il primo batch di remediation con proof-of-exploit firmato allegato.
• Giorni 61–90 — mobilization + primo readout al board. Ticket per le voci validate; SLO per severità; retest gating; primo grafico firmato di riduzione esposizione. Presentalo al board come la nuova cadenza operativa e ritira la voce pentest-annuale dal budget dell'anno prossimo.

La trappola in cui cade la maggior parte dei programmi: cercare di partire con scope completo. Scopa una fetta singola, dimostra che il loop chiude, poi espandi. I programmi che cercano di boil-the-ocean si bloccano allo stage di discovery e non arrivano alla validazione, producendo nulla che il board possa usare.