Een telemetry pipeline is een tussenlaag die data tussen je bronnen en je analyse- of securityplatformen verwerkt, zodat jij bepaalt wat waarheen gaat en waarom. Het probleem dat die laag oplost, ken je uit je eigen begroting: datavolume groeit exponentieel, budgetten niet.
De vier bewerkingen van een pipeline
- Filteren. Sluit uit wat geen analytische of detectiewaarde heeft: debug-logging, heartbeats, health checks die elke tien seconden hetzelfde zeggen. Dat is goedkoper én maakt je detecties schoner; zie ook ons artikel over het wegnemen van ruis voordat die je SIEM in gaat.
- Verrijken. Voeg context toe terwijl de data onderweg is: assetwaarde, eigenaar, omgeving. Een verrijkte melding hoeft een analist niet meer op te zoeken.
- Routeren. Stuur elke stroom naar de goedkoopste bestemming die nog voldoet: detectiewaardige data naar het SIEM, compliance-data rechtstreeks naar goedkope object storage.
- Maskeren of versleutelen aan de bron. Gevoelige velden, zoals persoonsgegevens, worden gemaskeerd voordat de data het domein verlaat. Wat er niet in gaat, kan er ook niet lekken.
De Splunk-documentatie vertelt wat elk component doet, niet wat er gebeurt als het uitvalt. En juist met die kolom beoordeel je je architectuur.
Waar de kosten zitten, en waar de winst
Voor elke gigabyte die je logt, betaal je drie keer: bij binnenkomst (ingest, vaak de basis van je licentie), bij het bewaren (opslag, maal je bewaartermijn) en bij het gebruiken (zoekcapaciteit). Alle drie stijgen ze mee met een volume dat jaarlijks groeit.
Een pipeline-laag grijpt op alle drie in: wat geen waarde heeft, komt er niet in, en wat wel waarde heeft, gaat naar de juiste prijsklasse, hot storage voor detectie, cold of object storage voor compliance en forensisch onderzoek. Zo worden lange bewaartermijnen betaalbaar; hoe dat samenhangt met de wet lees je in ons artikel over bewaartermijnen betaalbaar houden onder NIS2. In projecten zien we reducties van [x] tot [y] procent op het ingest-volume, afhankelijk van de bronnenmix.
Cribl Stream, Edge en Lake: wat gebruik je waarvoor
Waar het draait | Waarvoor je het inzet | Wanneer je het niet nodig hebt | |
|---|---|---|---|
Stream | Centraal, in je eigen (cloud)omgeving | De centrale verwerkingslaag: filteren, verrijken, routeren en maskeren van alle datastromen | Bij één bron en één bestemming zonder volumeprobleem |
Edge | Als lichte agent, dicht bij de bron | Verzamelen en voorbewerken op de bron zelf; relevant voor OT-omgevingen en locaties waar je bandbreedte wilt sparen of data niet ongefilterd wilt versturen | Als al je bronnen al netjes centraal aanleveren |
Lake | Als goedkope opslaglaag | Langdurig bewaren met de mogelijkheid data later terug te spelen naar een analyseplatform | Als je bewaartermijnen kort zijn en je bestaande opslag volstaat |
Waarom een pipeline-laag je onafhankelijk houdt
Dit is het strategische argument, en eerlijk gezegd ons beste verkoopargument. Bij een leveranciersneutrale pipeline sluiten al je bronnen aan op de pipeline, niet op je SIEM. Wisselen van analyseplatform betekent dan één route verleggen in plaats van tientallen bronkoppelingen opnieuw bouwen. En de verwerking kan binnen de EU blijven draaien, in je eigen omgeving, zonder dat de leverancier in je data meekijkt; details over datalocatie en governance vind je op onze pagina over Cribl bij SMT.
In de praktijk: grip op securitydata
PostNL liep tegen precies dit aan: torenhoge ingest-kosten en een constructie met Exabeam en Kafka waarin het aansluiten van een nieuwe logbron tot twaalf weken duurde. Samen met SMT en Cybermeister koos PostNL voor Cribl Stream als nieuwe datalaag, als container binnen de serverless AWS-omgeving. Binnen vier weken draaide Cribl in de dev-omgeving, ging de onboarding van bronnen van twaalf naar vier weken (soms direct) en leverde de eerste use case 40 procent minder ingest op bij AWS CloudTrail, waar 30 procent was verwacht. “We wilden weer grip op onze eigen securitydata en dat is gelukt”, aldus Koen Wackers, Team Lead Connectivity IT/OT bij PostNL. Lees de case study PostNL (pdf).
Hoe je begint zonder alles te verbouwen
- Meet je huidige volume per bron. Niet het totaal, maar per bron, daar zitten de verrassingen.
- Bepaal per bron de detectie- en compliancewaarde. Welke detecties draaien erop, welke bewaarplicht geldt? Data zonder antwoord op beide vragen is je eerste kandidaat.
- Zet de pipeline ernaast, niet ertussen. Laat de pipeline parallel meedraaien met je bestaande route. Je productie merkt er niets van, precies wat migratieangst wegneemt.
- Verleg één bron en vergelijk. Zelfde detecties, zelfde dashboards, minder volume? Dan werkt het aantoonbaar.
- Schaal op zodra de meting klopt. Bron voor bron, op eigen tempo. In Splunk-omgevingen is dit vaak ook het moment waarop heavy forwarders worden vervangen door de pipeline-laag.
Als Cribl Elite Partner bouwen wij deze pipelines dagelijks, en houden ze draaiend. Een pipeline die niemand beheert, wordt zelf de bron die stilletjes uitvalt; het beheer van je datapijplijn hoort er daarom vanaf dag één bij.
