Kort samengevat: CTEM-dekking aan de client-side
- CTEM mist de browser: CTEM-programma's worden als continu gepresenteerd, maar de meeste dekken server-side infrastructuur en CVE's op maandelijks ritme, terwijl de JavaScript die in gebruikersbrowsers draait wordt behandeld als statische code die tussen releases van de leverancier nooit verandert.
- Continue scriptdetectie: cside ontdekt continu elk script dat op een webproperty draait, markeert wanneer een script gevoelige DOM-elementen benadert of data naar een nieuw endpoint stuurt, en genereert de alerts en het bewijs die Mobilization-teams nodig hebben zonder handmatig onderzoek.
- In scope of een bevinding? PCI DSS 4.0.1 Vereisten 6.4.3 en 11.6.1 zijn verplicht sinds 31 maart 2025, dus de vraag is of jouw CTEM-programma client-side JavaScript als in-scope behandelt of als een exposure-regel die de auditor voor je gaat vinden.
Weinig tijd? Bekijk cside's in-browser blokkering van Magecart en skimmers. Dit dekt alles hieronder in één deployment.
Continuous Threat Exposure Management (CTEM) is een securityframework om risico te beheren als een doorlopend programma in plaats van een periodieke audit. Gartner introduceerde de term om een terugkerende cyclus te beschrijven die blootstellingen ontdekt, ze rangschikt op werkelijke misbruikbaarheid en valideert dat oplossingen het aanvalspad daadwerkelijk sluiten.
De premisse is eenvoudig. Je aanvalsoppervlak verandert elke dag. Er komen nieuwe leveranciers bij, er landen nieuwe scripts op je webproperty's en er worden nieuwe kwetsbaarheden gepubliceerd, dus een kwartaal- of jaarbeoordeling is alweer verouderd tegen de tijd dat het rapport geschreven is. CTEM-programma's draaien doorlopend, prioriteren blootstellingen op basis van hoe misbruikbaar ze zijn in je werkelijke omgeving en volgen herstel tot aan geverifieerde afsluiting.
De vijf fasen van CTEM
CTEM-programma's zijn opgebouwd rond vijf fasen die zich herhalen als een doorlopende cyclus in plaats van een lineair project.
| Fase | CTEM-taak | Client-side bewijs |
|---|---|---|
| Scoping | Bepaal de assets en aanvalsoppervlakken voor de huidige cyclus | Webproperties, authenticatiestromen, betaalpagina's en scripts van derden |
| Discovery | Breng de blootstellingen binnen de gekozen scope in kaart | Volledige scriptinventaris, dynamische injectie, endpoints en DOM-toegang |
| Prioritization | Rangschik blootstellingen op misbruikbaarheid en bedrijfsimpact | Toegang tot gevoelige gegevens, nieuwe bestemmingen en skimmingpatronen |
| Validation | Test de blootstelling en bevestig het herstel | Historie van live gedrag, bewijs van wijzigingen en controle na de oplossing |
| Mobilization | Wijs eigenaren toe en volg elke bevinding tot deze is opgelost | Waarschuwingen, gebeurtenislogboeken en bewijs voor security- en applicatieteams |
Fase 1: Scoping
Het programma bepaalt welke assets en aanvalsoppervlakken binnen de scope van de huidige cyclus vallen. Scoping is niet permanent. Het breidt zich uit naarmate het programma volwassener wordt. Vroege CTEM-programma's beperken de scope meestal eerst tot de meest bedrijfskritische assets: productie-webapplicaties, authenticatieflows en betaalinfrastructuur. Latere cycli betrekken interne systemen, third-party integraties en de toeleveringsketen erbij. Scoping beantwoordt een simpele vraag: wat beschermen we, en tegen welke dreiging verdedigen we ons?
Fase 2: Discovery
Discovery identificeert elke blootstelling binnen de gedefinieerde scope en gaat veel verder dan bekende CVE's en geïnstalleerde kwetsbaarheden. In een CTEM-context dekt discovery welke third-party componenten aanwezig zijn, welke scripts in een webapplicatie worden uitgevoerd, welke services van buitenaf bereikbaar zijn, welke identiteiten gevoelige resources kunnen benaderen en waar data systeemgrenzen overschrijdt. Het brengt het aanvalsoppervlak in kaart zoals het nu bestaat, inclusief blootstellingen waarvan het securityteam niet wist dat ze er waren.
Fase 3: Prioritization
Niet elke blootstelling kan tegelijk worden verholpen. Prioritization rangschikt ze op werkelijk risico, de combinatie van ernst, misbruikbaarheid in de huidige omgeving en bedrijfsimpact bij misbruik. CTEM geeft bewust lagere prioriteit aan theoretische kwetsbaarheden die in de praktijk niet bereikbaar of misbruikbaar zijn, en tilt de kwetsbaarheden waar threat actors actief op mikken naar boven. Dit is de fase die CTEM onderscheidt van kale vulnerability scanning. De output is een gerangschikte lijst van wat als eerste moet worden verholpen, niet een platte lijst van elke bevinding.
Fase 4: Validation
Validation test of de geïdentificeerde blootstellingen daadwerkelijk misbruikbaar zijn en of bestaande controls standhouden. Het gebruikt penetratietesten, red team-oefeningen en breach and attack simulation om te bevestigen dat een geprioriteerde blootstelling een werkelijk risico is. Validation bevestigt ook dat het herstel de blootstelling heeft gesloten, wat betekent dat het aanvalspad niet meer werkt, niet alleen dat er een patch is toegepast. Het beantwoordt een botte vraag: werkt onze verdediging echt?
Fase 5: Mobilization
Mobilization zet gevalideerde bevindingen om in herstelacties bij de teams die eigenaar zijn van de getroffen systemen. Securityteams zijn zelden eigenaar van de assets die ze verdedigen. Applicatieteams, infrastructuurteams en third-party leveranciers spelen allemaal een rol. Mobilization vertaalt bevindingen naar concrete werkitems voor die teams en volgt elk daarvan tot aan geverifieerde voltooiing.
Waarom client-side JavaScript een blinde vlek in CTEM is
De meeste CTEM-programma's scannen server-side infrastructuur, bekende CVE's en blootstellingen op netwerkniveau goed. De client-side laag, de JavaScript die in de browser van een gebruiker draait wanneer die met je webapplicatie werkt, is stelselmatig ondervertegenwoordigd.
Een paar kenmerken maken het client-side aanvalsoppervlak lastig te dekken met traditionele CTEM-tooling.
Het verandert zonder waarschuwing. Third-party scripts (analyticstools, chatwidgets, tag managers, via CDN geladen bibliotheken) werken hun inhoud bij wanneer de leverancier dat besluit. Een script dat vorige maand als veilig is beoordeeld, kan sindsdien zijn aangepast, door een aanvaller zijn gecompromitteerd of nieuw gedrag hebben gekregen. Die voortdurende verandering is onzichtbaar voor momentopnames.
Geautoriseerde scripts kunnen als wapen worden ingezet. Magecart-aanvallen maken dat duidelijk. Het risico beperkt zich niet tot ongeautoriseerde scripts. Geautoriseerde scripts die veranderen wat ze doen zijn het lastigere probleem. Een betaalpagina die een goedgekeurd analyticsscript laadt, is blootgesteld als dat script wordt gecompromitteerd en kaartvelden gaat uitlezen. Het script viel binnen de scope. Het gedrag ervan werd niet gemonitord.
CVE-scanners vangen het niet op. CVE-gebaseerde scanners zoeken naar bekende softwarekwetsbaarheden. Ze detecteren geen gedragsveranderingen in JavaScript, nieuw toegevoegde third-party scripts of client-side paden voor data-exfiltratie.
Toezichthouders vereisen het nu. PCI DSS 4.0.1 vereisten 6.4.3 en 11.6.1, verplicht sinds 31 maart 2025, vereisen een script-inventaris van betaalpagina's, autorisatiecontroles en detectie van wijzigingen tijdens runtime. Die vereisten bestaan juist omdat het client-side aanvalsoppervlak niet werd beheerd.
Hoe cside in CTEM-programma's past
cside dekt de client-side blootstellingslaag die de meeste CTEM-programma's nooit bereiken. Gekoppeld aan de CTEM-fasen:
- Discovery: cside ontdekt doorlopend elk script dat op een webproperty wordt uitgevoerd, inclusief scripts die via tag managers zijn toegevoegd, CDN-afhankelijkheden en dynamisch geïnjecteerde code, waarmee je de volledige inventaris krijgt die de Discovery-fase nodig heeft.
- Prioritization: de gedragsmonitoring van cside markeert wanneer scripts gevoelige DOM-elementen benaderen, data naar externe endpoints sturen of overeenkomen met patronen die aan skimming-aanvallen zijn gekoppeld, de signalen die misbruikbare client-side blootstellingen onderscheiden van theoretische.
- Validation: cside levert real-time bewijs van veranderingen in scriptgedrag en bevestigt of een blootstelling actief is en welke data die raakt.
- Mobilization: cside genereert de meldingen, event logs en bewijsdocumentatie waarmee security- en applicatieteams op client-side bevindingen kunnen handelen zonder handmatig onderzoek.
Specifiek voor betaalpagina's is dit ook hoe cside voldoet aan PCI DSS 6.4.3 en 11.6.1 in één implementatie: een doorlopende script-inventaris met autorisatiecontroles plus geautomatiseerde detectie van manipulatie.
