Samenvatting
Steeds meer organisaties schuiven hun securitylogs door naar data lakes van leveranciers. Wat begint als een detectiestrategie, verandert stap voor stap in een opslagprobleem; één waar je geen zicht op hebt, geen grip op houdt en waarvan de kosten blijven doorlopen.
In de verschuiving van SIEM naar cloud-analytics en MDR zijn logs de cloud uit gegaan, om vervolgens in steeds grotere data lakes terecht te komen. Het gevolg: oplopende retentie-eisen, verborgen kosten en vraagstukken rond datasoevereiniteit die direct impact hebben op risico en budget.
Deze blog laat zien waarom traditionele detectiemodellen die afhankelijk zijn van data lakes het risico op ongecontroleerde groei vergroten. En we laten zien hoe moderne MDR-oplossingen zoals MDR Detect™ dit probleem elimineren door logdata gewoon in je eigen cloud te laten staan, waar jij de controle, het eigendom en de kosten bepaalt.
Het echte probleem: meer data, maar niet meer zekerheid
De hoeveelheid data schiet omhoog, maar deze data heeft niet per se waarde als het gaat om detectie.
Bedrijven loggen massaal, terwijl 84% nu aangeeft dat cloudkosten tot hun grootste zorgen behoren. Die zorgen zijn terecht: in 2025 stijgen de uitgaven aan public cloud naar $723,4 miljard, een sprong ten opzichte van 2024. Tegelijkertijd wordt ongeveer 32% van die kosten verspild aan resources die niemand gebruikt. Dat betekent dat ieder jaar meer dan $200 miljard verdwijnt zonder enige waarde terug te geven.
Securitydata groeit dus sneller dan de inzichten die het oplevert. En al die groei vindt plaats in opslag die je zelf niet beheert, maar waarvoor je wél betaalt. Zo verandert detectie ongemerkt in een opslagprobleem, niet omdat teams dat zo willen, maar omdat de onderliggende architectuur ze die kant op dwingt.
De keerzijde: data lakes zijn duur, maar leveren geen resultaten
Traditionele SIEM’s en gecentraliseerde MDR-platforms bouwen op één simpel uitgangspunt:
Stuur al je logs naar ons data lake, wij doen de detectie.
Wat er vrijwel nooit bij wordt verteld, is hoeveel dat model kost en op hoeveel verschillende manieren die kosten in rekening worden gebracht.
Zodra je logs een vendor-beheerd data lake instromen, begint de meter te lopen voor onder meer:
- Ingestie per GB
- Retentie per dag of per maand
- Replicatie naar andere regio’s
- Queryvolume
- Compute-verbruik
- Analytics-engines en rule packs
- Cold-storage retrieval
- Egress als je ooit wilt migreren
Het is geen enkele factuur, maar een stapel facturen. En zodra het datavolume groeit, groeit elke regel op die factuur automatisch mee.
Gartner waarschuwt al jaren voor deze ‘SIEM cost bloat’ en wijst vooral naar ingestie en opslag als de grootste kostenveroorzakers. Hun advies is helder: organisaties moeten slimmer omgaan met data, via filtering, tiering en analytics dicht bij de bron, omdat alles opslaan in één centraal data lake simpelweg geen houdbaar model meer is.
In de praktijk betalen organisaties dus vooral voor de zwaartekracht van hun data lake, niet voor de daadwerkelijke securitywaarde die het oplevert.
Data lakes worden duurder – zelfs als er niets verandert
Wat CISO’s en CIO’s als het meest ‘oneerlijk’ ervaren: de kosten lopen op, ook wanneer hun securityhouding identiek blijft.
Dat gebeurt doordat:
- Retentietermijnen ongemerkt verlengen
- Replicatie-instellingen wijzigen
- Nieuwe logbronnen blijven binnenkomen
- Vendor-analytics extra kopieën genereren
- Cloudplatformen automatisch extra tiering en indexing toepassen
AWS, Azure en GCP zeggen het openlijk:
meer data →meer metadata →meer indexing →meer compute.
Voor bedrijven voelt dat als sluipende kostenstijging, zonder extra waarde.
Simpel gezegd: je data lake blijft groeien, zelfs als dat niet de bedoeling is.
Meer data ≠ betere detectie – en de cijfers laten dat glashelder zien
Jarenlang hebben securityleveranciers het beeld geschetst dat meer logs automatisch betere detectie opleveren. Maar op een gegeven moment neemt de architectuur het over van de resultaten.
Securityteams erkennen dat een groot deel van hun logvolume nauwelijks detectiewaarde heeft, maar wél de kosten van SIEM en dataplatformen omhoog jaagt. Analisten en ervaren SOC-teams zeggen het al langer: slechts een klein percentage van alle SIEM-regels leidt tot waardevolle alerts. De rest is ruis, doublures of regels die in incidenten vrijwel nooit iets toevoegen.
Toch blijven de meeste organisaties vrijwel alle telemetrie verzamelen én bewaren, niet omdat het zinvol is, maar omdat de gekozen architectuur dat afdwingt.
Daar ontstaat de paradox van het moderne SOC:
Je betaalt voor alles, maar krijgt weinig terug.
Erger nog: de hoeveelheid ruis blokkeert het echte signaal.
Meer opslag → meer ingestie → meer noise → meer false positives → meer werk.
Het is een vicieuze cirkel die leveranciers helpt meer storage te verkopen — maar jouw securityresultaten niet verbetert.
Je verliest niet alleen geld, je verliest grip
Zodra je logs je eigen cloud verlaten, gebeuren er vier dingen:
- Soevereiniteit verschuift naar de leverancier
80% van organisaties maakt zich zorgen over datalocatie en geopolitieke risico’s. Geen grip hebben op je loglocaties is inmiddels een auditrisico op zichzelf. - Governance wordt ondoorzichtig
Je kunt niet sturen op wat je niet kunt zien, zeker niet wanneer data over meerdere regio’s is verspreid. - Migratie verandert in een bureaucratische blokkade
Vendor lakes creëren vendor-lock-in by design. Extractie is duur, traag en vaak onvolledig. - Flexibiliteit verdwijnt uit je detectiestrategie
Jouw detectie hangt nu direct af van hun opslagmodel.
Detectie mag nooit ten koste gaan van je onafhankelijkheid.
Hoe je ontsnapt aan het grote datawarenhuis
Vendor-data lakes voelen in het begin overzichtelijk. Tot het volume groeit, en daarmee de kosten én de complexiteit.
Het lijkt op het eindeloze warenhuis uit Raiders of the Lost Ark: rijen kratten, geen labels, geen overzicht, maar wel een rekening die blijft oplopen.
Steeds meer organisaties ontdekken dat:
- Hun SOC betaalt voor data waar geen analist ooit naar kijkt
- Bewaartermijnen standaard vendorinstellingen zijn, geen bewuste securitykeuzes
- Hun MDR-leverancier detectie uitvoert in een lake dat ze zelf niet kunnen auditen
- Cloudkosten stijgen terwijl de securityhouding gelijk blijft
- Migratie betekent dat terabytes aan ‘gevangen’ data moeten worden teruggehaald
Dit heeft weinig met security te maken.
Het is opslag die eruitziet als detectie.
Een betere oplossing: breng detectie naar de data
Dit is de verandering die de hele data-lake tax in één keer laat verdwijnen:
Breng detectie naar de data, in plaats van data naar een vendor-lake.
Houd je logs bij jezelf.
Houd je cloud bij jezelf.
Laat je MDR binnen jouw eigen omgeving draaien – niet erbuiten.
Dat is precies wat MDR Detect™ standaard doet:
- Geen kopieën van je logs naar een vendor-lake
- Geen bewaarkosten die je niet zelf hebt vastgesteld
- Geen ingest-kosten die afhankelijk zijn van iemand anders’ opslagmodel
- Geen verborgen replicatie of egress-verrassingen
- Geen migratiepijn wanneer je van leverancier wilt wisselen
Detectie, verrijking, correlatie en automatische respons draaien volledig in jouw cloud, onder jouw controle en volgens jouw regels.
Die ene architectuurkeuze elimineert in één keer:
- Opslaginflatie
- Vendor lock-in
- Onvoorspelbare cloudkosten
- Multi-region replicatieproblemen
- Onduidelijkheid rond compliance
Je behoudt sterke detectie – zonder opslagbeheerder te worden..
Waarom dit nú telt (niet pas over drie jaar)
Drie ontwikkelingen maken deze shift urgent:
- Cloudverspilling groeit, niet krimpt
Flexera schat dat 27–32% van alle clouduitgaven wordt verspild. Dat loopt jaarlijks in de tientallen miljarden. - De druk op datasoevereiniteit stijgt fors
80% van organisaties past hun cloudarchitectuur aan vanwege eisen rond datalocatie en geopolitieke risico’s. - Detectieproblemen komen steeds vaker door ruis
Het logvolume blijft stijgen, waardoor echte signalen worden begraven onder data die niets toevoegt aan detectie.
Ondertussen vraagt de board waarom de kosten blijven stijgen, terwijl het risico niet omlaag gaat.
Het antwoord is simpel: de bestaande architectuur is het probleem.
Van “hun” lake naar “jouw” cloud
Je hoeft je architectuur niet in één dag om te gooien. Inzicht is de eerste stap. De meeste organisaties beginnen hier:
1. Breng in kaart waar je securitylogs écht leven
De realiteit: veel organisaties ontdekken 3–7 onbedoelde kopieën verspreid over vendors, regio’s en analysetools.
2. Stem bewaartermijnen af op compliance – niet op vendor-standaarden
Bewaar wat moet, niet wat toevallig is ingesteld.
3. Analyseer welk deel van je cloudrekening aan logging hangt
Zelfs 10–20% minder ingestie levert al onmiddellijke kostenbesparing op.
4. Stap over op MDR die in jouw omgeving draait
Dit is de stap die controle en soevereiniteit terugbrengt.
MDR Detect™ is precies hiervoor ontworpen..
De enige vraag die telt
Wanneer jouw detectiemodel leunt op het data lake van een leverancier, is de kernvraag simpel:
Betalen we voor detectie – of betalen we eigenlijk voor opslag?
Als dat antwoord niet glashelder is, klopt de architectuur niet voor jouw organisatie.
Jouw logs.
Jouw cloud.
Jouw regels.
Dat is de toekomst van detectie, en MDR Detect™ maakt die toekomst concreet.
FAQ
1. Waarom komen data lakes met verborgen kosten?
Omdat de meeste kosten niets met detectie te maken hebben, maar met het verplaatsen, repliceren en opslaan van data. Ingestie, indexing, bewaartermijnen, queries en egress lopen automatisch op wanneer je datavolume groeit. De architectuur beloont het opslaan van méér data, niet het verbeteren van detectie.
2. Leidt minder log-ingest tot slechtere detectie?
Niet noodzakelijk. Een groot deel van alle logs heeft nauwelijks detectiewaarde. Analisten geven al jaren aan dat maar een klein percentage van alle telemetrie daadwerkelijk relevante alerts oplevert. Het draait om gericht datamanagement, weten welke logs bijdragen aan onderzoek.
3. Waarom bestaan er vaak meerdere kopieën van dezelfde securitydata?
Gecentraliseerde SIEM- en MDR-pijplijnen repliceren data automatisch over regio’s, tiers en analytics-engines. Cloudplatformen maken extra metadata en indexen. Die kopieën zijn meestal onzichtbaar, maar drijven opslag- en compute-kosten wél op.
4. Hoe beïnvloedt de locatie van logs soevereiniteit en compliance?
Zodra logs naar een vendoromgeving verhuizen, verlies je zicht op waar ze precies staan, hoe ze worden gerepliceerd en hoelang ze blijven bestaan. Met toenemende druk rondom regelgeving en geopolitiek wordt dat gebrek aan controle een auditrisico.
5. Waarom is migreren uit een vendor data lake zo duur en ingewikkeld?
Data lakes zijn ontworpen voor massale centrale opslag. Telemetrie eruit halen betekent opnieuw ingesten, indexeren en egresskosten betalen. Dat maakt overstappen traag, kostbaar en operationeel uitdagend.
6. Als data lakes zoveel kosten, waarom gebruiken organisaties ze nog steeds?
Omdat de industrie jarenlang het model van “stuur ons alles maar” heeft gestimuleerd. Veel architecturen stammen uit een tijd waarin centralisatie de enige praktische optie was. De schaalbaarheid van cloud verbergt de echte kosten – totdat de factuur komt.
7. Wat is het alternatief voor vendor-centrale data lakes?
Detectie, verrijking en correlatie uitvoeren op de plek zélf: in je eigen cloudomgeving. Dat beperkt databeweging, vereenvoudigt governance en voorkomt dat je betaalt voor opslag en replicatie die je niet beheert.
