Hoe je een MDR, SIEM of XDR kiest zonder vendor-led te zijn

SIEM, XDR en MDR zijn drie verschillende dingen, geen drie smaken van hetzelfde. Een SIEM is een platform dat logs en events uit het hele landschap verzamelt, normaliseert en met regels of analytics correleert, zodat er een centraal beeld ontstaat van wat er gebeurt. XDR is detectie en respons die over meerdere domeinen tegelijk werkt, endpoint, identiteit, e-mail, cloud, netwerk, met als belofte dat de telemetrie van die domeinen al voorbewerkt en aan elkaar gekoppeld binnenkomt zodat correlatie sneller en gerichter is dan in een puur log-gedreven SIEM. MDR is geen platform maar een dienst: een externe partij die de detectie- en responsfunctie geheel of gedeeltelijk levert, met menselijke analisten die 24/7 op de telemetrie kijken, alarmen onderzoeken en bij incidenten ingrijpen of escaleren. Het verschil tussen de drie is daarmee geen feature-vergelijking. Het is een vraag over wat je zelf wilt en kunt dragen, en wat je uitbesteedt aan een platform of aan mensen.

Zo selecteer je zonder dat de categorie van de verkoper jouw vraag bepaalt. De rest van dit stuk werkt het verschil tussen de drie scherper uit, beschrijft de gedragstoets die je in elk verkoopgesprek kunt toepassen, en eindigt bij vijf criteria waarop een onafhankelijke selectie staat of valt.

Wat is het verschil tussen SIEM, XDR en MDR?

Het verschil begint bij wat het ding fundamenteel is. Een SIEM is een log-pipeline met een correlatie-laag erbovenop. Je voedt het met logbronnen uit je infrastructuur, applicaties, identiteit, netwerk en cloud, en het levert je een platform om regels te schrijven, dashboards te bouwen, alarmen te tunen en forensisch terug te kijken. Wat je eruit haalt is een functie van wat je erin stopt, wie de regels onderhoudt en hoe goed de telemetrie genormaliseerd is. Het is een gereedschap, geen oplossing. Zonder eigen detection engineering loop je vol met alarmen die niets zeggen.

XDR is in opzet de volgende stap, met een belangrijke nuance. De belofte is dat de leverancier de telemetrie van zijn domeinen, en bij open varianten ook van derden, al heeft genormaliseerd, verrijkt en gecorreleerd voordat jij er iets mee doet. Je krijgt geen rauwe logregels maar voorbewerkte detecties die over endpoint, identiteit en cloud heen lopen. Dat scheelt veel tunen, op voorwaarde dat de domeinen waar jij echt risico hebt ook gedekt zijn door de detectie-content van die leverancier. Bij een gesloten XDR is dat sterk gekoppeld aan de stack van één leverancier, met het bijbehorende lock-in-effect. Bij een open XDR is de telemetrie-koppeling met derde-partij-bronnen het kritieke punt: de detectie is zo goed als de telemetrie die er werkelijk in komt.

MDR voegt mensen toe. Een MDR-dienst kan bovenop een SIEM, bovenop een XDR of bovenop een eigen detectie-platform draaien, en levert analisten die de alarmen onderzoeken, prioriteren en bij incidenten een actie nemen of escaleren naar jouw team. Wat MDR onderscheidt van "iemand kijkt naar onze alarmen" is de werkwijze: detection engineering die voor jouw omgeving wordt onderhouden, een runbook per type incident, een afgesproken respons-mandaat, en een SLA op detectie-, triage- en respons-tijd. Een MDR die alleen meldt wat zijn platform standaard ziet, is een melddienst, geen detectie- en respons-capaciteit.

De drie zijn daarmee niet uitwisselbaar. Een SIEM zonder mensen die de regels schrijven en onderhouden is een dure logbak. Een XDR zonder dekking op de domeinen die er voor jou toe doen, is een mooi dashboard dat de verkeerde dingen ziet. Een MDR zonder een platform dat de telemetrie van jouw omgeving werkelijk binnenkrijgt, is een SOC die naar te weinig kijkt. De keuze gaat niet over welke categorie wint, maar over welke combinatie past bij wat jouw organisatie zelf doet en wat je uitbesteedt.

Waarom de selectie zo vaak vendor-led wordt

De selectie loopt zelden mis op de techniek. Hij loopt mis op de volgorde van het gesprek. Een leverancier komt binnen met zijn categorie, niet met jouw vraag. De SIEM-verkoper toont datavolume en correlatie-regels. De XDR-verkoper toont voorbewerkte detecties en cross-domain-correlatie. De MDR-verkoper toont 24/7 monitoring en een mean-time-to-respond. Drie verschillende product-demo's, drie verschillende beloftes, en geen van de drie begint bij wat jouw landschap, je risicoprofiel en je interne capaciteit feitelijk nodig hebben. Zo wordt de selectie een keuze tussen drie aanbiedingen die hun eigen categorie tot oplossing verklaren, en niet een keuze die uit jouw vraag voortkomt.

Hier ligt een gedragstoets die je in elk eerste gesprek kunt toepassen, en die meer voorspelt dan welke feature-matrix dan ook. Stelt de leverancier vragen voordat hij categoriseert? Een onafhankelijke aanbieder vraagt eerst wat je use-cases zijn, welke detecties je nu mist, welke telemetrie je beschikbaar hebt, hoe je SOC of IT-team eruitziet en wat je voor de komende achttien maanden in je programma hebt staan. Daarna komt er een aanbeveling, die soms zijn eigen categorie is, soms niet, en soms is "begin met wat je al hebt en investeer eerst in de regels". Een vendor-led aanbieder herkent in jouw zinnen een keyword, "te veel alarmen" of "we zien lateral movement niet", en koppelt het binnen drie zinnen aan zijn portefeuille. Het verschil is direct hoorbaar, en het zegt iets over wat er gebeurt zodra de implementatie loopt.

ENISA wijst in zijn Threat Landscape herhaaldelijk op het patroon dat organisaties detectie-capaciteit kopen die niet aansluit op hun specifieke risicoprofiel: de telemetrie is er, maar de detecties zoeken naar de verkeerde dingen. Dat is geen tool-probleem, het is een diagnose-probleem dat met een tool is opgelost. Het MITRE ATT&CK-raamwerk levert hier de gemeenschappelijke taal: een serieuze leverancier kan in concrete ATT&CK-techniektermen beschrijven wat hij dekt en wat niet, voor jouw type omgeving en jouw type tegenstander. Wie alleen in product-features kan praten, dekt iets, maar niemand weet precies wat.

Vijf criteria voor een onafhankelijke selectie

De selectie wordt navolgbaar zodra je hem op deze vijf assen voert. Geen wegingsformule, maar een gestructureerd gesprek dat dwingt om aannames expliciet te maken voordat de offerte op tafel ligt. NIST CSF, in functies Detect en Respond, biedt de bovenliggende structuur: je koopt geen platform, je vult een capability in.

Use-case-fit. Schrijf eerst op welke detecties je nodig hebt voor jouw landschap en jouw dreigingsbeeld, in ATT&CK-techniektermen of vergelijkbaar concreet. Vraag elke kandidaat om diezelfde lijst te dekken, met bewijs van hoe en welke datavoorwaarden gelden. Een leverancier die de lijst herformuleert naar zijn eigen feature-set, herformuleert ook jouw probleem. Een leverancier die zegt "deze drie zien we structureel, deze twee niet zonder extra telemetrie" geeft je een eerlijk vertrekpunt.

Datavolume-economie. SIEM en sommige XDR-modellen rekenen af op datavolume, vaak in gigabytes per dag of in events per seconde. Dat klinkt neutraal en is het niet: je betaalt voor wat je erin pompt, ongeacht of je er waarde uit haalt. Vraag een driejaars-projectie op je werkelijke logbronnen, met groei-aannames, en vraag wat er gebeurt als je meer bronnen aansluit. Tegelijk: te weinig telemetrie en de detectie is blind. Het optimum zit niet in zo min mogelijk data, maar in zorgvuldige keuze welke bronnen welke detecties voeden. Dat is detection engineering, niet een aanbestedingsregel.

Telemetrie-koppelingen. Hoe ziet de leverancier de telemetrie die buiten zijn eigen stack ligt? Bij een gesloten XDR is dit de pijnlijke vraag, bij een open XDR of een SIEM de centrale vraag. Vraag specifiek naar de bronnen die jij hebt, jouw identity-provider, jouw cloud-tenant, jouw netwerk-fabric, jouw OT-laag waar van toepassing, en welke koppeling daadwerkelijk bestaat, welke gebouwd moet worden, en wie dat bouwt. Een koppeling die "via een log forwarder kan" is geen koppeling, dat is een project waar de detectie van afhangt.

Respons-SLA, ingebed in een mandaat. Bij MDR-diensten gaat het zelden mis op de detectietijd en bijna altijd op wat er na de detectie gebeurt. Vraag niet alleen naar een mean-time-to-detect en een mean-time-to-respond, maar naar het mandaat: welke acties mag de externe partij nemen zonder jouw goedkeuring, welke moet hij voorleggen, en op welke escalatiepaden. Een respons-SLA zonder gekoppeld mandaat is een belofte zonder bevoegdheid, en in de eerste echte zaterdagnacht-incident merk je het verschil.

Exit-clausules en data-eigendom. Wat blijft van jou als de relatie stopt? Eigenaar zijn van de logs, de detectie-content, de tuning-historie en de incident-tijdlijnen is geen detail in de algemene voorwaarden, het is de bepaling van of je überhaupt kunt switchen. Vraag expliciet naar export-formaten, retentie na contract-einde, en of detection-content die voor jouw omgeving is gebouwd jouw eigendom is of die van de leverancier. Het NCSC raadt voor uitbestede dienstverlening structureel aan dat exit-voorwaarden vóór gunning helder zijn, niet als sluitpost. Een leverancier die hier vaag wordt, vertelt je waar je over een paar jaar staat.

De vijf criteria hangen samen. Use-case-fit zonder de juiste telemetrie-koppelingen is een papieren belofte. Een respons-SLA zonder use-case-fit dekt verkeerde alarmen sneller af. Exit-clausules zonder data-eigendom maken alles eromheen onderhandelbaar zodra je echt weg wilt. Wie de criteria los van elkaar weegt en op elk een vinkje haalt, eindigt vaak met een keuze die op de matrix scoort en in jouw omgeving niet werkt.

Wat dit betekent voor de keuze die jij maakt

Voor de CIO die deze keuze in een transformatieprogramma moet inpassen: de bruikbare samenvatting is dat selectie geen categorie-keuze is en geen aanbestedingsoefening. Het is een diagnose-vraag die je in twee gesprekken kunt stellen, en die het verschil maakt tussen een platform of een dienst die in jouw landschap landt en een keuze die de leverancier voor jou heeft gemaakt. Naar de CISO is de boodschap dat zonder eigen detection-engineering-capaciteit ook MDR een gedeeltelijke oplossing blijft. Naar de CFO is de boodschap zakelijker: datavolume-economie en exit-clausules bepalen de meerjaren-kostencurve sterker dan de licentieprijs op jaar één.

De logische volgende stap is geen RFP uitsturen met een feature-lijst per categorie, want elke leverancier vinkt zijn eigen categorie aan. Zet eerst de use-case-lijst op papier, in concrete techniek-termen. Voer dan de gedragstoets in elk eerste gesprek: stelt de leverancier vragen voordat hij categoriseert. Loop daarna de vijf criteria langs op de overgebleven kandidaten. Leg je eigen situatie naast dit kader, en als een leverancier op een van de criteria wegduikt, weet je dat de categorie hem belangrijker was dan de uitkomst die jij nodig hebt.