Detection Strategy: waarom een MDR-keuze altijd te laat komt zonder strategie

Een detectiestrategie is een vastgelegd document dat beschrijft welke aanvalsscenario's je organisatie wil zien, welke kroonjuwelen daarbij in scope staan, welke telemetrie nodig is om die scenario's te dekken, welke detectieregels die telemetrie tot een alarm maken, en wie er bij welk type alarm wat doet binnen welke tijd. Het is geen tool-keuze, geen leveranciersshortlist, geen volwassenheidsscore. Het is een set expliciete keuzes die je maakt voordat een MDR-leverancier in beeld komt, zodat je tijdens de selectie weet wat je inkoopt en waarom. Wie die volgorde omdraait, kiest een leverancier op basis van wat hij in een demo laat zien en hoopt achteraf dat de dekking past bij wat de organisatie nodig heeft.

Dit stuk legt uit waarom een MDR-contract zonder voorafgaande detectiestrategie zelden levert wat de CISO ervan verwachtte, hoe een werkbare strategie eruitziet, en welke onderdelen je minimaal hebt vastgelegd voordat je het gesprek met de markt opent. Het is bedoeld voor de CISO die intern moet uitleggen waarom de selectie nog niet kan beginnen, of die net heeft vastgesteld dat het lopende contract telemetrie levert zonder de context waarin die telemetrie iets betekent.

Waarom faalt een MDR-selectie zonder strategie?

Het antwoord ligt in wat een MDR-leverancier daadwerkelijk verkoopt. Een MDR-dienst combineert telemetrie (logs, endpoint-events, netwerkverkeer, identiteitsgebeurtenissen), een platform dat die telemetrie correleert, een set detectieregels die op dat platform draaien, en een team dat op alarmen reageert. Wat de leverancier in een demo toont, is de capaciteit van die stack op generieke aanvalsscenario's. Wat hij niet kan tonen, omdat hij de organisatie nog niet kent, is hoe goed die stack jouw kroonjuwelen dekt, jouw bedrijfsprocessen begrijpt, en jouw response-keten in werking zet. Dat verschil ontstaat pas in de transitiefase, en op dat moment is het contract al getekend.

Zonder strategie kies je dus op iets dat geen voorspeller is van wat je gaat krijgen. Je weegt de helderheid van de demo, de chemie van het accountteam en het tarief per endpoint, terwijl de eigenlijke vraag is welke aanvalsstappen op welke systemen je wilt detecteren en welke telemetrie daar het meeste signaal geeft. Die vraag staat los van de leverancier. Wie hem niet beantwoord heeft voordat de selectie begint, beantwoordt hem impliciet via de keuze, en die impliciete invulling wijkt meestal af van wat de organisatie nodig had.

De tweede reden ligt aan de structuur van de markt. Een groot deel van het MDR-aanbod is gebouwd rond één detectie-platform en één set generieke use-cases die op dat platform draaien. Dat is begrijpelijk vanuit het leveranciersmodel, het maakt de dienst schaalbaar. Voor de koper betekent het dat de dekking van zijn specifieke risico-scenario's afhankelijk wordt van toevallige overlap tussen de leverancier-defaults en zijn eigen omgeving. Een sceptische CISO toetst die overlap voordat hij tekent. Een CISO zonder strategie heeft geen toetssteen en valt terug op de overtuigingskracht van de presentatie.

Een derde reden is operationeel. Een MDR-contract zonder use-case-context levert alarmen waarvan je intern niet kunt vaststellen of ze relevant zijn. Het team aan de klantkant krijgt meldingen binnen die contextloos zijn, want de leverancier weet niet welke server een ERP-productiehost is en welke een testomgeving. De respons wordt traag, het vertrouwen erodeert, en binnen een jaar komt de vraag of MDR wel het juiste model is. Het probleem zit zelden in het MDR-model. Het zit in de afwezigheid van het strategiedocument dat de leverancier de context had moeten geven.

Wat is dan het verschil tussen telemetrie en een detectiestrategie?

Telemetrie is wat je systemen ruwweg uitspuwen aan logs en events. Een detectiestrategie is het verhaal dat bepaalt welke telemetrie je opzettelijk verzamelt en wat je ermee gaat doen. Dat verhaal begint bij dreigingsmodellen en kroonjuwelen, en eindigt bij een geoperationaliseerde respons-keten. De telemetrie volgt uit dat verhaal, niet andersom.

In de praktijk gaat het andersom: een organisatie heeft een SIEM, een EDR-oplossing, een paar identity-logs, en bouwt daarop een detectieregelset omdat dat de bronnen zijn die toevallig beschikbaar waren. Dat is een telemetrie-strategie vermomd als detectie-strategie. Het mist een centraal element: de scenario's die je wilt zien zijn nooit benoemd. Je detecteert wat detecteerbaar is met wat je hebt, en niet wat detecteerbaar moet zijn omdat het ertoe doet. MITRE ATT&CK, het door MITRE beheerde raamwerk dat aanvalstechnieken systematisch beschrijft, is daarvoor het meest gebruikte instrument: het laat je per kroonjuweel benoemen welke technieken een serieuze aanvaller zou inzetten en welke detectie-coverage je daarvoor minimaal nodig hebt. Een detectiestrategie zonder mapping naar ATT&CK is meestal een telemetrie-inventaris met een ander etiket.

De keerzijde geldt ook. Een strategie zonder telemetrie-realiteit is een wensenlijst. Wie scenario's benoemt zonder te toetsen welke logs en events er feitelijk beschikbaar zijn binnen welk retentie-venster, en welke datakwaliteit die bronnen hebben, schrijft een document dat in de uitvoering vastloopt. De volgorde is dus: scenario's eerst, telemetrie-mapping daarna, niet andersom. Maar het document is pas af als beide kanten zijn ingevuld.

Wat staat er in een werkbare detectiestrategie?

Een detectiestrategie hoeft niet honderd pagina's te zijn. Hij moet expliciet zijn op een beperkt aantal punten, en die punten zijn navolgbaar voor zowel het eigen team als een toekomstige MDR-leverancier. De minimum-onderdelen, in volgorde:

Dreigingsmodellen per bedrijfsdomein. Welke type aanvallers zijn realistisch voor jouw sector en schaal, welke motieven hebben ze, en welk gedrag passen ze toe. Niet "ransomware in het algemeen", maar concreet: financieel gemotiveerde criminele groepen die initial access kopen via gestolen inloggegevens, supply-chain-actoren die via beheerd-IT binnenkomen, insider-risico's bij privileged-toegang. Het Cyber Threat Landscape-rapport van ENISA en de jaarlijkse uitgaven van het Nationaal Cyber Security Centrum bieden hier een gestructureerde basis die je naar je eigen sector terugbrengt.

Kroonjuwelen-inventaris met bijbehorende impact. Welke systemen, datasets en processen mogen onder geen voorwaarde uitvallen of lekken, en wat is de verwachte impact in tijd en geld als dat wel gebeurt. Dit is geen volledige IT-inventaris, dit is de top van de risico-piramide. Zonder deze laag wordt detectie een over-de-hele-linie-ambitie en valt het in de uitvoering uit op de bronnen die het makkelijkst te tappen waren.

Use-cases per kroonjuweel. Per kroonjuweel: welke aanvalsstappen probeer je te detecteren, met welke detectielogica, en in welke fase van de aanvalsketen. Hier komt MITRE ATT&CK in beeld als gemeenschappelijke taal. Een use-case is "verdachte lateral movement vanaf een ERP-host" of "credential-abuse op een financieel rapportage-systeem", niet "we monitoren de logs van X". Een use-case is een hypothese over wat een aanvaller zou doen, met een meetbare detectievoorwaarde.

Telemetrie-mapping per use-case. Welke bronnen leveren het signaal voor deze use-case, met welke retentie, en welke datakwaliteit. Hier valt de helft van de strategieën uit. Een use-case die afhangt van een log-bron met onbetrouwbare retentie of beperkte velden, werkt in de demo en valt om in productie. NIST Cybersecurity Framework versie 2.0, de structuur die het Amerikaanse National Institute of Standards and Technology beheert, biedt onder de Detect-functie de discipline om de telemetrie-mapping per scenario expliciet te maken in plaats van te leunen op een tool-default.

Respons-RACI per scenario-type. Wie ziet welk alarm eerst, wie escaleert, wie beslist over containment, wie informeert het bestuur, wie spreekt namens de organisatie. Bij een MDR-dienst hoort hier expliciet bij: waar eindigt de verantwoordelijkheid van de leverancier en waar begint die van het eigen team. Een MDR-contract zonder deze laag is een belofte zonder werkende keten.

Een strategie die deze vijf onderdelen vastlegt, is op één punt na klaar voor een leveranciersgesprek. Dat ene resterende punt is de toetsing zelf, en die voer je vóór je tekent, niet erna.

Hoe toets je een MDR-leverancier tegen deze strategie?

De toetsing gaat niet over de demo. Hij gaat over de mate waarin de leverancier elk van de vijf onderdelen kan dekken, op welke telemetrie hij die dekking bouwt, en welke leemtes hij eerlijk benoemt. Een leverancier die zegt dat hij alles dekt zonder de strategie gelezen te hebben, geeft het verkeerde antwoord op de eerste vraag. Een leverancier die per use-case aangeeft welke telemetrie hij vraagt, welke detectielogica hij gebruikt, en op welke punten hij afhankelijk is van klantkant-werk, levert een toetsbaar voorstel.

Drie concrete vragen waar de toetsing op rust. Eén, kun je de detectiestrategie tegen jouw default-content leggen en per use-case een dekkingspercentage geven, met een onderbouwing op MITRE ATT&CK-techniek-niveau. Twee, welke onderdelen van de respons-keten draait de leverancier zelf, welke onderdelen zijn klantverantwoordelijkheid, en hoe ziet de overdracht eruit op het moment dat een alarm tot containment moet leiden. Drie, hoe wordt de detectie-coverage in de tijd onderhouden, want het dreigingslandschap verschuift en zonder periodieke herijking veroudert de strategie binnen een jaar.

Wie deze drie vragen niet kan stellen met een document in zijn hand, koopt op vertrouwen in plaats van op fit. Vertrouwen heeft een plek in de samenwerking, maar niet als basis voor de selectie zelf.

Wat dit betekent voor de keuze die jij maakt

Voor de CISO die intern het MDR-traject voorbereidt: de bruikbare conclusie is dat de strategie het stuurmateriaal voor de selectie is, niet een nice-to-have die later wel komt. Een MDR-keuze zonder voorafgaande detectiestrategie levert telemetrie zonder use-case-context, en die situatie keert zelden vanzelf om binnen een lopend contract. Het herstel kost meer dan de strategie vooraf had gedaan.

Naar de board of de CFO is de boodschap zakelijker. Een MDR-contract is doorgaans een meerjarige uitgave op een vast tarief per beschermde eenheid. Een contract dat niet rust op een eigen detectiestrategie wordt beoordeeld op het tarief, terwijl de eigenlijke vraag is welk risico per euro afgedekt wordt. Die vraag laat zich pas beantwoorden als de strategie er ligt. Tot dat moment is de keuze een uitgave zonder navolgbare risicoreductie, en dat is precies het soort beslissing waar de toezichthouder navraag op doet en waar het bestuur zich op moet kunnen verantwoorden.

Naar het eigen team is de boodschap praktisch. De strategie is niet het werk van een externe partij die hem voor je opschrijft. Hij komt voort uit het gesprek tussen security, IT, business-eigenaren en risicobeheer over wat er beschermd moet worden, tegen wie, en met welke prioriteit. Een externe partij kan hem structureren, toetsen en helpen samenstellen, maar hij moet door de organisatie zelf gedragen worden. Anders staat hij in een leveranciers-portaal en niet in het hoofd van de mensen die hem moeten uitvoeren.

De logische volgende stap is dus geen RFP voor MDR. Het is een korte, eerlijke vaststelling van wat er aan strategie ligt en wat ontbreekt. Pas als die vijf onderdelen expliciet zijn, opent het gesprek met de markt met een voorsprong in plaats van met een achterstand. Wie die volgorde omdraait, koopt een dienst en houdt het oorspronkelijke probleem.