CTEM uitgelegd

Continuous Threat Exposure Management, kortweg CTEM, is een doorlopend programma waarin een organisatie haar blootstelling aan aanvallen herhaaldelijk afbakent, in kaart brengt, prioriteert, valideert en omzet in werk dat daadwerkelijk wordt uitgevoerd. Het is geen tool en geen module die je aanschaft. Het is een werkwijze in cycli, gevoed door telemetrie en aanvalsperspectief, die de uitkomst van security-werk meetbaar maakt in termen van wat een aanvaller op dit moment bij jou wel of niet kan bereiken. Het verschil tussen CTEM en wat veel organisaties vandaag kwetsbaarheidsbeheer noemen, is geen accentverschil. Het is een ander type sturing.

Dit stuk legt uit wat CTEM is, waarin het verschilt van een klassiek kwetsbaarheidsproces, hoe de vijf fasen samenwerken, en welke regie het van jou vraagt als CISO. Het is geschreven voor de situatie waarin een leverancier "wij doen CTEM" zegt en jij intern moet onderbouwen waarom dat zinnetje op zichzelf nog niets betekent.

Wat is het verschil tussen CTEM en vulnerability management?

Een klassiek vulnerability-managementproces produceert een lijst. Een scanner draait, koppelt aan een CVE-database, levert tienduizenden bevindingen, en een team werkt die af naar CVSS-score. Het werk is reactief van vorm: vinden, scoren, patchen, opnieuw scannen. Het meet wat technisch fout staat in de configuratie en de softwareversies, niet wat een aanvaller daarmee in jouw specifieke omgeving daadwerkelijk kan doen. NIST SP 800-30, dat het kader geeft voor risk assessment van informatiesystemen, benoemt dit verschil nadrukkelijk: een kwetsbaarheid wordt pas een risico in combinatie met een dreigingsbron, een geloofwaardig pad en een waardevol doel. Een lijst zonder die context is een werkbacklog, geen risicobeeld.

CTEM keert de volgorde om. De vraag is niet "welke kwetsbaarheden hebben we", maar "welke routes zijn op dit moment bruikbaar voor een aanvaller die binnen wil komen, lateraal wil bewegen, of bij iets waardevols wil komen". Dat verlegt het werk van afvinklijst naar pad-analyse, en het verlegt de prioritering van score-volgorde naar exploiteerbaarheid in jouw omgeving. Een kwetsbaarheid met een hoge CVSS-score op een asset die geen aanvalspad heeft naar een kroonjuweel, zakt op de lijst. Een lagere score op een asset die wel zo'n pad heeft, stijgt. ISO 27005, de internationale norm voor informatiebeveiligingsrisicobeheer, sluit hier inhoudelijk op aan: de norm verlangt dat risicobehandeling wordt gestuurd door waarschijnlijkheid en impact in jouw context, niet door technische severity in het algemeen.

Het tweede verschil is het ritme. Vulnerability management werkt in een cyclus van scannen, fixen en opnieuw scannen. CTEM werkt in cycli die korter en breder zijn: niet één scan, maar een lopende observatie van het buitenoppervlak, de identiteitsstructuur, de cloud-configuratie en de detectieketen, samen genomen als één blootstellingsbeeld. Het gaat erom dat het beeld nooit een momentopname is en dat verandering, niet stilstand, de norm is.

Het derde verschil is het einddoel. Vulnerability management eindigt bij een gesloten ticket. CTEM eindigt bij een mobilisatie: het werk is pas af als de organisatie iets heeft veranderd in de echte omgeving, gevalideerd door iemand die de aanvalsstap opnieuw probeert en aantoont dat hij niet meer werkt. Dat verschil bepaalt waar het programma intern landt. Een lijstproces hoort bij operations. Een CTEM-programma hoort bij de regie, en raakt operations, architectuur en bestuurlijke prioritering tegelijk.

De vijf fasen van CTEM, en wat ze van jou vragen

CTEM is gestructureerd in vijf fasen die in cyclus doorlopen worden. Wie de fasen begrijpt, herkent meteen welk gat in zijn huidige proces zit, en weet welke leverancier-belofte aan welke fase iets toevoegt.

Scoping. De keuze welk deel van de organisatie deze cyclus geadresseerd wordt en wat de "kroonjuwelen" zijn die je beschermt. Dit is geen technische stap, het is een bestuurlijke. Een scope die te breed is, levert ruis. Een scope die te smal is, mist de paden die er feitelijk lopen. In de praktijk werken organisaties met gelaagde scopes: kritieke business-services in een korte cyclus, het bredere omgevingsbeeld in een tragere. Wat hier ontbreekt, valt later niet meer in te halen, want het hele programma stuurt op de scope-keuze van de eerste fase.

Ontdekken (discovery). Het in kaart brengen van wat er binnen die scope feitelijk staat: assets, identiteiten, cloud-resources, derde-partij-koppelingen, schaduw-IT, blootgestelde diensten. Discovery is iets anders dan een asset-inventaris uit een CMDB. Een CMDB beschrijft wat de organisatie denkt te hebben. Discovery beschrijft wat een aanvaller ziet. Het verschil tussen die twee is in de meeste organisaties aanmerkelijk, en juist dat verschil is de eerste les van een CTEM-cyclus.

Prioriteren. De bevindingen uit discovery worden geordend naar exploiteerbaarheid in jouw omgeving, gekoppeld aan de waarde van het doel waar ze toegang toe geven. Dit is waar CTEM zich het scherpst onderscheidt van vulnerability management. Niet CVSS-volgorde, maar pad-volgorde: welke ketens van zwakheden vormen samen een werkbaar aanvalsverhaal van entry naar doel. Het ENISA Threat Landscape beschrijft hoe aanvallers in de praktijk juist deze ketens benutten, en daar past de prioritering op aan.

Valideren. De gepriotiseerde paden worden getest. Dat kan met een doorlopende vorm van breach-and-attack-simulation, met red-team-werk op specifieke routes, of met een controlled-attack op een afgebakend doel. Het doel is hetzelfde: aantonen dat de route werkt of niet werkt, en aantonen of de detectieketen de stap zou opvangen als hij in productie werd gezet. Validatie scheidt het theoretische risico van het feitelijke risico. Een bevinding die in validatie niet uitvoerbaar blijkt, zakt of valt af. Een bevinding die wel uitvoerbaar blijkt, krijgt voorrang in de volgende fase.

Mobiliseren. De vertaling van het gevalideerde risicobeeld naar werk in de organisatie: tickets in de juiste teams, architectuurwijzigingen waar nodig, detectieregels die worden bijgesteld, processen die worden aangepast. Dit is de fase waar de meeste CTEM-programma's struikelen, en het is geen detail. Een gevalideerd pad dat niemand in opdracht oppakt, is nog steeds een open pad. Het Nationaal Cyber Security Centrum benadrukt in zijn handreikingen dat detectie en respons een ingerichte capaciteit zijn, geen bijproduct van techniek. Hetzelfde geldt voor mobilisatie: het is een organisatie-vraagstuk, niet een tool-vraagstuk.

Na fase vijf begint de cyclus opnieuw bij scoping, met de geleerde lessen verwerkt. Dat is wat "continuous" in de naam doet: het beeld veroudert, de omgeving verandert, de aanvalsmogelijkheden verschuiven, en het programma loopt mee. Een CTEM-traject dat eenmalig wordt uitgevoerd, is geen CTEM. Het is een assessment met een nieuwe naam.

Waarom CTEM regie-werk is, niet een platform-aankoop

Een groot deel van wat zich in de markt aandient als CTEM, is feitelijk een verzameling tooling rond exposure-data. Asset-discovery, attack-surface-management, breach-and-attack-simulation, prioritization-engines: bestaande categorieën, opnieuw verpakt. De tooling kan goed zijn, en in een rijp programma is een aantal van deze capabilities ook nuttig. Maar de tooling is niet het programma. Het programma is de discipline om de vijf fasen in cyclus te draaien, met eigenaarschap per fase en met mobilisatie als een afdwingbaar werkonderdeel.

Wie CTEM als platform-aankoop benadert, koopt de output van fase twee en drie (discovery en prioritering), en houdt fase een, vier en vijf in de eigen organisatie zitten zonder dat daar iets aan ingericht is. Het resultaat is een rijker dashboard zonder een rijkere uitkomst. De lijst wordt langer en beter geprioriteerd, maar de mobilisatie blijft hangen op dezelfde plek waar vulnerability management hem al jaren laat hangen: tussen security en de teams die het werk zouden moeten doen.

De positie die wel werkt, is omgekeerd. Begin bij scoping en mobilisatie, en bouw de tooling-keuzes daaromheen. Wie weet wat hij wil beschermen en wie weet wie het werk gaat oppakken, weet ook welke discovery hij nodig heeft en welke validatie zinvol is. De vraag is dan niet meer "welk platform doet CTEM", maar "welke combinatie van eigen werk, externe capabilities en tooling sluit in onze cyclus aan op onze besluitvormingstempo". Dat is een architectuur-vraag, geen aankoop-vraag, en het is precies daar dat de meeste organisaties baat hebben bij iemand die geen belang heeft in de tooling-keuze.

Wanneer past CTEM, en wanneer is het te vroeg?

CTEM kent voorwaarden. Een organisatie die geen werkende kwetsbaarheidsproces heeft, een onvolledige asset-inventaris en geen detectiefunctie die kan reageren op een gevalideerd pad, is niet klaar voor CTEM. Het programma gaat dan iets meten dat nog niet gemeten kan worden, en het mobilisatie-deel landt in een team dat het ticket niet kan dragen. De volgorde is dan eerst de basis: asset-zicht, een gangbare patch-cyclus, een minimale detectie- en respons-capaciteit. Pas als die basis staat, levert een CTEM-cyclus iets op wat boven het bestaande proces uitstijgt.

Een organisatie die wel die basis heeft, maar merkt dat het patchen alle aandacht trekt terwijl de echte aanvalspaden elders lopen, is precies de organisatie waar CTEM rendeert. Het programma maakt zichtbaar dat het werk verkeerd verdeeld zit, en het verschuift de prioriteit van technische severity naar feitelijke exposure. Daarmee komt voor het eerst grip op de vraag waar de tijd van het team het meeste rendement geeft. Dat is geen klein winstpuntje. In organisaties waar de security-functie verzandt in lijstwerk, is dit het verschil tussen een operationele afdeling en een functie met sturing.

Een derde geval: de organisatie die onder DORA of NIS2 wettelijk verplicht is om te sturen op risico, niet op activiteit. Een CTEM-programma levert die in een vorm die een toezichthouder kan navolgen: gescopete cycli, gedocumenteerde discovery, gevalideerde paden, vastgelegde mobilisatie-besluiten. Dat is een ander register dan een rapportage van afgesloten tickets, en het sluit beter aan op wat de regelgeving feitelijk vraagt.

Wat dit betekent voor het gesprek dat jij intern voert

Voor de CISO die intern het gesprek opent over CTEM is de bruikbare samenvatting dat de term op zichzelf nog niets zegt. Wat ertoe doet, is welke fase in jouw huidige proces ontbreekt en welke regie nodig is om de cyclus daadwerkelijk te laten draaien. Naar je CIO is de boodschap dat CTEM een architectuur-discussie is, geen tool-discussie: de vraag is niet welk platform er komt, maar hoe scoping, validatie en mobilisatie worden belegd. Naar je CFO is de boodschap zakelijker: een programma dat exposure verlaagt, is verdedigbaar in een board, een dashboard dat alleen kwetsbaarheden hertelt niet.

De volgende stap is geen offerte aanvragen voor een CTEM-platform, maar eerst eerlijk vaststellen welke van de vijf fasen in jouw proces vandaag werkt en welke ontbreekt. Op die vaststelling rust de keuze van wat je intern bouwt, wat je extern haalt en welke tooling daarbij past. Leg je eigen kwetsbaarheidsbeheer naast de vijf fasen hierboven en kijk waar je werk vandaag stopt. Het antwoord op die vraag is bruikbaarder dan welke vendor-demo dan ook.