Contact

Alert fatigue is de afstomping die ontstaat wanneer analisten zoveel meldingen krijgen dat ze echte signalen missen. Wie tweehonderd keer per dienst op “close” klikt, klikt op een dag ook de melding weg die ertoe deed. De stelling die dit artikel draagt: alert fatigue is zelden een mensenprobleem en bijna altijd een datakwaliteitsprobleem.

Waar de ruis vandaan komt

1. Regels uit een standaardpakket, nooit aangepast aan de eigen omgeving. De content-packs van je SIEM zijn geschreven voor een gemiddelde organisatie die niet bestaat. Een regel die elders scherp is, loeit bij jou de hele dag.
2. Ontbrekende context. Een beheerder die om 02:00 uur inlogt: verdacht, tenzij het de geplande patchronde is. Zonder wijzigingskalender en asseteigenaar in de melding ziet de analist dat verschil niet, dus onderzoekt hij het. Elke keer weer.
3. Dubbele detecties op verschillende lagen. EDR, firewall en SIEM melden hetzelfde event, elk in eigen bewoording. Eén gebeurtenis, drie tickets.
4. Regels die niemand meer durft uit te zetten. Niemand weet waarom ze bestaan, dus laat iedereen ze staan. Voor de zekerheid. De eerlijkste oorzaak op dit lijstje, en de meest voorkomende.

Wat is detection engineering?

Detection engineering is het behandelen van detectieregels als een product met een levenscyclus, niet als een project dat ooit af is. Elke regel heeft een eigenaar, een doel en een houdbaarheidsdatum. Vijf fasen:

1. Ontwerpen. Welke techniek of welk risico wil je zien, en welke data heb je daarvoor nodig? Eigenaar: de detection engineer.
2. Bouwen. De regel schrijven, met context (assetwaarde, eigenaar) er meteen bij.
3. Testen. Tegen historische data en gesimuleerde aanvallen, voordat de regel live gaat. Eigenaar: engineer plus analist.
4. Afstemmen. De false positive ratio per regel volgen en bijsturen. Eigenaar: de analisten die de meldingen zien; doorlopend, met een vast maandelijks moment.
5. Uitfaseren. Regels die niets meer opleveren gedocumenteerd uitzetten, elk kwartaal. Vrijwel niemand doet deze fase, en het is precies de fase die oorzaak vier hierboven voorkomt.

Meten voordat je tunet

Vier meetwaarden volstaan om te weten waar je staat:

• Meldingen per analist per dienst. De directe maat voor werkdruk.
• False positive ratio per regel. Niet per omgeving, maar per regel, anders weet je nooit welke regel het probleem is.
• Mean time to triage. Hoe lang duurt het voordat iemand een melding heeft beoordeeld?
• Aandeel meldingen dat tot actie leidt. De hardste maat voor signaalwaarde.

Zonder nulmeting kun je na drie maanden tunen niet aantonen dat het hielp, en dan verdwijnt het budget. Streefcijfers geven we bewust niet: die verschillen per omgeving, en wie je er toch een noemt, kent jouw omgeving niet.

Vier maatregelen die het volume echt verlagen

1. Verrijk meldingen met context voordat ze bij een analist landen. Assetwaarde, eigenaar, wijzigingsvenster. De melding “inlog op srv-db-03 (kroonjuweel, eigenaar team Betalingen, geen gepland werk)” triageert zichzelf half.
2. Onderdruk meldingen tijdens geplande wijzigingen. Een patchnacht met vierhonderd meldingen leert analisten precies één ding: negeren.
3. Groepeer verwante meldingen tot één incident. Tien signalen van één aanvalspad horen in één dossier, niet in tien tickets. Waar AI wel en niet helpt bij ruisreductie, lees je in ons artikel over AIOps.
4. Verwijder data zonder detectiewaarde voordat die je SIEM in gaat. Debug-logging en heartbeats voeden geen enkele detectie, maar vervuilen wel elke zoekopdracht. Hoe je data filtert voordat die je SIEM in gaat, lees je in ons artikel over telemetry pipelines.

Een dashboard per component vertelt je hoe de database en de applicatieserver zich voelen, maar niet of de dienst het doet. Groene lampjes en toch klachten, iedereen in operations kent dat gesprek. Service-gebaseerde monitoring draait het om: je koppelt technische signalen aan een bedrijfsproces, zoals “bestelling plaatsen” of “brug bedienen”, en bewaakt dat. In de Splunk-wereld is dit het domein van Splunk Observability Cloud en ITSI.

Dekking meten met MITRE ATT&CK

Als de ruis afneemt, komt de volgende vraag: zien we wel de juiste dingen? Het MITRE ATT&CK-framework beschrijft de technieken die aanvallers daadwerkelijk gebruiken. Koppel je detecties daaraan, en het gesprek verandert van “hoeveel regels hebben we” in “welke technieken zien we, en welke niet”, het enige gesprek dat je risico verkleint.

Eén waarschuwing: dekking najagen om de dekking is de nieuwe valkuil. Dek de technieken die voor jouw omgeving en dreigingsbeeld tellen, en dek die goed.

Detection engineering vraagt om ritme: elke dag kijken, elke maand afstemmen, elk kwartaal opruimen. Dat ritme organiseren wij met 24/7 checks door een team in plaats van een persoon. Speelt de vraag of je dit zelf wilt doen, lees dan ons artikel over welk servicemodel bij je past.

Veelgestelde vragen

• Wat meet ik om te weten of tuning werkt?
• Hoe verlaag ik het aantal false positives?
• Wat is detection engineering?
• Wat is alert fatigue?

Monitoring meet vooraf bepaalde signalen en waarschuwt als een drempelwaarde wordt overschreden. Observability is het vermogen om de toestand van een systeem te begrijpen op basis van de data die het uitzendt, ook bij problemen die je niet had voorzien. Anders gezegd: monitoring vertelt je dát er iets mis is, observability helpt je begrijpen waaróm. De twee termen worden voortdurend door elkaar gebruikt, en dat kost organisaties geld: wie observability koopt voor een monitoringprobleem betaalt te veel, en wie monitoring inzet voor een observabilityprobleem blijft zoeken.

Het verschil in een tabel

De kern zit in die tweede rij. Monitoring bewaakt wat je vooraf kon bedenken. Observability geeft je de mogelijkheid om vragen te stellen die je pas bedenkt op het moment dat het misgaat.

The three pillars of observability: logs, metrics en traces

Logs vertellen wat er gebeurde: een foutmelding met stacktrace, een geweigerde inlogpoging, een time-out met de exacte parameters erbij. Ze zijn rijk aan detail, maar duur in volume.

Metrics vertellen hoeveel en hoe vaak: responstijden, foutpercentages, wachtrijlengtes. Compact, goedkoop, ideaal voor trends en alerts, maar zonder het verhaal erachter.

Traces vertellen waar in de keten het gebeurde: het pad van één verzoek langs alle services, met per stap de tijd die het kostte. Onmisbaar zodra één klik door tien systemen gaat.

En dan het eerlijke voorbehoud: de drie pijlers zijn een nuttig model, geen doel. Veel organisaties verzamelen keurig alle drie, in drie losse tools, zonder ze ooit te correleren. Dan heb je drie keer opslagkosten en nul keer inzicht. De waarde ontstaat pas als je vanuit een metric-piek kunt doorklikken naar de bijbehorende trace en logs.

Wanneer monitoring genoeg is

Nu de vraag die leveranciers liever overslaan: heb je observability nodig? Voor een stabiele, monolithische omgeving met bekende faalmodi is klassieke monitoring goedkoper en effectiever. Drie criteria om te beslissen:

1. Architectuur. Draait alles op een handvol servers, of is je landschap gedistribueerd over tientallen services en cloudcomponenten?
2. Vraagpatroon. Stel je bij incidenten steeds dezelfde vragen, of steeds nieuwe? Zodra elke storing een unieke puzzel is, schiet vooraf bedachte monitoring tekort.
3. Veranderingstempo. Wie wekelijks deployt, creëert wekelijks nieuwe manieren om te falen. Hoe sneller je omgeving verandert, hoe minder je vooraf kunt bedenken.

Scoor je op alle drie laag, houd het dan simpel en investeer je budget ergens anders in. Dat advies levert ons niets op, maar het klopt wel.

Van dashboards naar service-inzicht

Een dashboard per component vertelt je hoe de database en de applicatieserver zich voelen, maar niet of de dienst het doet. Groene lampjes en toch klachten, iedereen in operations kent dat gesprek. Service-gebaseerde monitoring draait het om: je koppelt technische signalen aan een bedrijfsproces, zoals “bestelling plaatsen” of “brug bedienen”, en bewaakt dat. In de Splunk-wereld is dit het domein van Splunk Observability Cloud en ITSI.

Wat je nodig hebt om te beginnen

1. Inventariseer welke data je al uitzendt. Applicaties, infrastructuur, cloudplatformen: het meeste is er al.
2. Zorg voor consistente tijdstempels en identifiers over bronnen heen. Zonder gedeelde sleutels valt er niets te correleren; hoe je consistente data over bronnen heen aan de bron regelt, lees je in ons artikel over telemetry pipelines.
3. Definieer wat een dienst is en welke componenten eronder vallen. Dit is een gesprek met de business, geen technische exercitie.
4. Begin met één dienst. Bewijs de waarde daar, en breid daarna pas uit.

Staat deze basis, kijk dan verder naar wat AI hieraan toevoegt. En wie het platform liever niet zelf scherp houdt: het beheer en de optimalisatie van je platform is precies wat wij als Managed Service doen.

Veelgestelde vragen

• Is observability hetzelfde als een SIEM?

  Nee. Observability richt zich op de gezondheid en prestaties van diensten, een SIEM op detectie van beveiligingsincidenten. Ze delen vaak dezelfde databronnen, maar beantwoorden andere vragen.

• Wanneer is monitoring genoeg?
• Wat zijn de three pillars of observability?

  Logs (wat er gebeurde), metrics (hoeveel en hoe vaak) en traces (waar in de keten). Het is een nuttig model, geen doel. Veel organisaties verzamelen alle drie zonder ze te correleren, en daar gaat het mis.

• Wat is het verschil tussen observability en monitoring?

  Monitoring meet vooraf bepaalde signalen en waarschuwt bij overschrijding van een drempelwaarde. Observability is het vermogen om de toestand van een systeem te begrijpen uit de data die het uitzendt, ook bij problemen die je niet had voorzien.

Een Splunk-architectuur is een verzameling gespecialiseerde componenten die data ontvangen, indexeren, doorzoeken en beheren, waarbij clustering zorgt voor beschikbaarheid en schaalbaarheid. Wie de rolverdeling en de twee clustervormen begrijpt, weet waar zijn eigen omgeving kwetsbaar is. Dit stuk is voor Splunk-engineers en -admins, we sparen het jargon niet.

De componenten op een rij

De Splunk-documentatie vertelt wat elk component doet, niet wat er gebeurt als het uitvalt. En juist met die kolom beoordeel je je architectuur.

Indexer clustering: replication factor en search factor

Twee getallen bepalen het gedrag van je indexer cluster: de replication factor (RF) bepaalt hoeveel kopieën van de ruwe data het cluster bewaart, de search factor (SF) hoeveel daarvan ook doorzoekbaar zijn, inclusief tsidx-indexbestanden.

Concreet, met RF3 en SF2: elke bucket bestaat drie keer als ruwe data, waarvan twee direct doorzoekbaar. Valt één indexer uit, dan is er geen dataverlies en blijft zoeken mogelijk, terwijl de cluster manager via fixup de aantallen herstelt. Opslag: drie keer de gecomprimeerde ruwe data plus twee keer de indexbestanden.

De klassieke fout: SF gelijkstellen aan RF “omdat het veiliger klinkt”. Dat levert zelden extra weerbaarheid op, maar wel een extra complete set tsidx-bestanden, je opslagverbruik schiet omhoog zonder dat je er iets voor terugkrijgt. Verhoog SF alleen met een concreet herstelscenario waarin die extra doorzoekbare kopie het verschil maakt.

Search head clustering en captain election

Een search head cluster kiest uit zijn leden een captain: die verdeelt scheduled searches, coördineert de replicatie van knowledge objects (dashboards, saved searches, lookups) en bewaakt de clusterstaat. Valt de captain weg, dan kiezen de overgebleven leden een nieuwe, mits ze met een meerderheid zijn.

Dat meerderheidsvereiste verklaart twee vuistregels. Drie search heads is het minimum, want bij twee is elke uitval meteen het einde van de meerderheid. En een even aantal is een slecht idee: splitst een netwerkpartitie een cluster van vier in tweeën, dan heeft geen van beide helften een meerderheid en liggen scheduled searches en replicatie stil terwijl alle machines gewoon aanstaan.

Vijf fouten die we het vaakst tegenkomen

Met meer dan 500 implementaties achter de rug zien we dezelfde fouten terugkomen. De vijf hardnekkigste:

1. 1. Search factor gelijk aan replication factor, zonder reden. Zie hierboven: veel opslag, weinig winst.
   2. Een monitoring console die zelf niet gemonitord wordt. Het systeem dat alles bewaakt, wordt door niets bewaakt. Valt het stil, dan merkt per definitie niemand dat.
   3. Knowledge objects lokaal op één search head in plaats van in het cluster. Alles werkt, tot die ene search head uitvalt en de dashboards van een heel team nergens anders blijken te bestaan.
   4. Forwarders die zonder load balancing naar één vaste indexer praten. Eén indexer eruit betekent meteen datagaten, en de load in het cluster is structureel scheef.
   5. Een deployment server die te veel clients bedient. Duizenden forwarders op één onderbemeten machine: configuratie-updates druppelen dagenlang binnen, of komen nooit aan.

Wat je periodiek zou moeten controleren

Wil je dit één keer grondig laten doorlichten, dan is de Splunk Health Check de kortste route. Structureler kan ook: Splunk-beheer uitbesteden betekent dat deze controles elke dag gebeuren, door een team in plaats van die ene collega. Hoe je daarna van dashboards naar service-inzicht komt, en waarom omgevingen hun heavy forwarders vervangen door een pipeline-laag, lees je in de vervolgblogs. Twijfel je tussen platformen, lees dan welk platform bij je past.

Veelgestelde vragen

• Wat controleer je periodiek in een Splunk-omgeving?
• Hoeveel search heads heb ik minimaal nodig voor een cluster?
• Hoe zorgen we ervoor dat een investering in Splunk rendabel blijft naarmate onze data groeit?
• We gebruiken al meerdere monitoring- en securitytools. Wat voegt Splunk dan nog toe?
• Hoe helpt Splunk ons om sneller inzicht te krijgen in problemen voordat ze impact hebben op de business?

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

1. 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.
2. Verrijken. Voeg context toe terwijl de data onderweg is: assetwaarde, eigenaar, omgeving. Een verrijkte melding hoeft een analist niet meer op te zoeken.
3. Routeren. Stuur elke stroom naar de goedkoopste bestemming die nog voldoet: detectiewaardige data naar het SIEM, compliance-data rechtstreeks naar goedkope object storage.
4. 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

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

1. Meet je huidige volume per bron. Niet het totaal, maar per bron, daar zitten de verrassingen.
2. Bepaal per bron de detectie- en compliancewaarde. Welke detecties draaien erop, welke bewaarplicht geldt? Data zonder antwoord op beide vragen is je eerste kandidaat.
3. 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.
4. Verleg één bron en vergelijk. Zelfde detecties, zelfde dashboards, minder volume? Dan werkt het aantoonbaar.
5. 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.

Veelgestelde vragen

• Hoeveel logvolume kan ik besparen met een pipeline?

  Dat verschilt per omgeving en vooral per bron. Ter indicatie uit de praktijk: bij PostNL daalde het ingest-volume van AWS CloudTrail met 40 procent, waar vooraf 30 procent was verwacht.

• Wat is het verschil tussen Cribl Stream en Cribl Edge?

  Stream is de centrale verwerkingslaag, Edge een lichte agent die dicht bij de bron draait. Edge is relevant voor OT-omgevingen en verre locaties waar je bandbreedte wilt sparen of data niet ongefilterd wilt versturen.

• Wat doet Cribl Stream precies?

  Cribl Stream verwerkt datastromen centraal: het filtert wat geen waarde heeft, verrijkt met context, routeert naar de juiste bestemming en maskeert gevoelige velden. Zo verlaag je volume en kosten zonder detectiedekking op te geven.

• Wat is een telemetry pipeline?

  Een telemetry pipeline is een tussenlaag tussen je databronnen en je analyse- of securityplatformen die bepaalt wat waarheen gaat: filteren, verrijken, routeren en maskeren, voordat de data zijn bestemming bereikt.

Voorspellend onderhoud betekent onderhoud plannen op basis van de werkelijke conditie en het gedrag van een asset, in plaats van op een vaste kalender. Internationaal heet het predictive maintenance, en het steunt op data die de asset en de systemen eromheen vaak al produceren. Daarmee is meteen gezegd wat dit artikel anders maakt dan de meeste stukken over dit onderwerp: het gaat niet over een onderhoudspakket aanschaffen, maar over de data die je al hebt en wat daarvoor nodig is.

Drie vormen van onderhoud, en wat ze kosten

En nu het eerlijke verhaal: voor veel assets is preventief onderhoud gewoon prima. Een vast interval voor iets goedkoops dat zelden faalt, hoef je niet slimmer te maken. Voorspellend onderhoud loont bij assets waar uitval duur of gevaarlijk is: de tunnel, de terminal, het gemaal.

Welke data je nodig hebt (en waarschijnlijk al hebt)

Vier bronnen vormen samen het beeld.

1. Sensordata uit de asset zelf. Stroomverbruik, temperatuur, trilling, druk: de signalen die slijtage verraden.
2. Logdata uit de besturingssystemen. PLC’s en SCADA registreren schakelmomenten, foutcodes en afwijkingen die je in sensordata alleen niet ziet.
3. Netwerktelemetrie. Een installatie die hapert, kondigt zich op het netwerk vaak eerder aan dan in het proces.
4. De storingshistorie uit je onderhoudssysteem. Wat ging er eerder kapot, wanneer, en wat ging eraan vooraf? Dit is je referentiemateriaal.

De eerste drie komen meestal al ergens langs, alleen in verschillende systemen met verschillende tijdstempels. Het werk zit niet in het voorspellen, maar in het samenbrengen, en in de vraag hoe je die data veilig uit je OT-omgeving haalt.

Waarom predictive maintenance zelden op het model stukloopt

De meeste voorspellend-onderhoudsprojecten stranden niet op het algoritme. Ze stranden op datakwaliteit, en wel op drie voorspelbare manieren.

1. Te weinig storingshistorie om op te trainen. Kritieke assets falen gelukkig zelden, dus zijn er weinig voorbeelden van hoe falen eruitziet.
2. Tijdstempels die niet synchroon lopen. Als de sensor, de PLC en het onderhoudssysteem elk hun eigen klok hanteren, kun je oorzaak en gevolg niet meer op één tijdlijn leggen.
3. Assets die pas gaan loggen als er al iets mis is. Foutcodes zijn geen conditiedata. Je wilt weten hoe gezond gedrag eruitziet, niet alleen hoe kapot eruitziet.

Onze ervaring, zonder omwegen: met een half jaar goede data kom je verder dan met een geavanceerd model op vuile data. Begin dus bij de data, niet bij het algoritme.

In de praktijk: tunnels en terminals

Vialis past dit toe op een tunnel in de A4. Sensordata wordt via Cribl gefilterd en verrijkt, en in Splunk geanalyseerd op patronen die op slijtage wijzen; webhooks starten vervolgacties zoals het inplannen van onderhoud. Het effect: hogere tunnelbeschikbaarheid, minder ongeplande sluitingen en onderhoud op werkelijke conditie. Lees de case study Vialis (pdf).

Bij Rotterdam World Gateway (RWG), een van de meest geautomatiseerde containerterminals ter wereld, zat het probleem niet in een gebrek aan data maar aan zichtbaarheid: data lag verspreid over logsystemen, applicaties, leverancierssystemen en OT. Door die stromen in Splunk te correleren ging de start van een probleemanalyse van uren naar minuten en veranderde stilstand van verrassing in beheersing. Lees de case study RWG (pdf).

Een realistisch stappenplan

1. Kies een asset waar uitval echt pijn doet. Niet de makkelijkste, maar de duurste storing van vorig jaar.
2. Inventariseer welke data die asset nu al produceert. Sensoren, besturing, netwerk, onderhoudssysteem, meestal meer dan je denkt.
3. Breng die data samen op één tijdlijn. Zelfde klok, zelfde identifiers. Dit is tachtig procent van het werk.
4. Leg de storingshistorie ernaast en zoek patronen met het blote oog. Wat zag je in de dagen voor elke storing? Vaak springt het patroon eruit zonder code.
5. Automatiseer pas als je het patroon zelf herkent. Een model moet bevestigen wat jij al snapt. Dit advies krijg je van softwareleveranciers niet, en het scheelt je een mislukt project.

Voorspellend onderhoud is geen product dat je koopt, maar een werkwijze die je opbouwt, en die valt of staat met de continuïteit van kritieke systemen eronder. Voor de servicelaag daarboven is ITSI en service-monitoring het gereedschap.

Veelgestelde vragen

• Waarom mislukken predictive maintenance-projecten?
• Heb ik speciale software nodig voor predictive maintenance?
• Wat is voorspellend onderhoud?

AIOps is het toepassen van machine learning en statistische analyse op operationele data: om afwijkingen te vinden, meldingen te correleren en problemen te voorspellen voordat ze uitval worden. Tot zover de definitie die je overal leest. Dit artikel doet iets wat de meeste stukken over AIOps overslaan: het beschrijft ook wat AIOps niet oplost. Die kant hoor je zelden van partijen die het verkopen, en het is precies de kant die bepaalt of jouw investering iets oplevert.

De vier dingen die AIOps daadwerkelijk goed doet

1. Anomaliedetectie op tijdreeksen. Een statische drempel zegt: alarm boven 80 procent. Een model leert dat 70 procent op dinsdagochtend normaal is en op zondagnacht niet, en slaat dus eerder én preciezer aan. In de Splunk-stack is dit het domein van de Machine Learning Toolkit.
2. Correlatie van meldingen naar één incident. Storage-latency, database-timeouts en applicatiefouten zijn geen drie problemen; het is één probleem met drie gezichten. Splunk ITSI groepeert die signalen tot één episode.
3. Ruisreductie. Dezelfde melding die elke vijf minuten terugkomt, wordt één melding met een teller. Klinkt banaal, scheelt in de praktijk het meeste geklik.
4. Capaciteitsvoorspelling. Op basis van trends zie je dat een schijf over drie weken volloopt, in plaats van vannacht om drie uur, dat verplaatst werk van paniek naar planning.

Waar dit in de praktijk zit: de Splunk Machine Learning Toolkit en ITSI voor respectievelijk de modellen en de servicecorrelatie.

De drie dingen die AIOps niet oplost

1. AIOps repareert geen vuile data. Een model op inconsistente logs geeft zelfverzekerde onzin. Ontbrekende velden, dubbele bronnen en klokken die uit elkaar lopen worden niet weggemodelleerd; ze worden versterkt.
2. AIOps vervangt geen engineer. Het model wijst aan waar je moet kijken, niet waarom het misgaat in jouw architectuur, welke workaround uit 2021 nog ergens draait, of welke afhankelijkheid nooit is gedocumenteerd. Het verkort de zoektijd; de diagnose blijft mensenwerk.
3. AIOps lost geen procesprobleem op. Als niemand eigenaar is van een alert, verandert een slimmer alert daar niets aan. Het wordt alleen sneller genegeerd.

Vandaar ons uitgangspunt: niet de hype volgen, maar wat werkt in jouw landschap. Meer alerts zijn zelden het antwoord, waarom dat zo is, lees je in ons artikel over waarom meer alerts niet helpen.

Van chaos naar controle: een voorbeeld

Hoe dit uitpakt als de voorwaarden op orde zijn, beschrijft onze use case over Splunk AI. De uitgangssituatie is herkenbaar: miljoenen signalen per seconde uit IT en OT, meldingen die zich opstapelen, teams die tijd verliezen aan vals alarm. Door logdata samen te brengen in Splunk, machine learning afwijkingen te laten herkennen die met vaste regels onzichtbaar blijven, en verdachte gebeurtenissen automatisch naar het juiste team te routeren, veranderde dat beeld. Het resultaat uit de use case: 75 procent minder valse meldingen, snellere detectie van echte dreigingen en één platform waar IT- en OT-teams samen mee werken. De volledige use case Splunk AI (pdf) lees je in ons downloadcentrum.

Hoe je AIOps stapsgewijs invoert

1. Kies één use case met een duidelijke eigenaar. Niet “alles slimmer maken”, maar bijvoorbeeld: eerder zien dat de orderverwerking hapert.
2. Doe een nulmeting. Aantal meldingen per week, mean time to detect. Zonder nulmeting valt succes niet te bewijzen.
3. Normaliseer de databronnen voor die ene use case. Niet je hele landschap; alleen wat deze detectie nodig heeft.
4. Laat het model meelopen zonder actie. Een paar weken schaduwdraaien laat zien of het model jouw normaal begrijpt.
5. Meet opnieuw en beslis op cijfers. Minder meldingen, snellere detectie? Uitbreiden. Zo niet: stoppen kost nu weinig, precies waarom je klein begon.

AIOps is geen wondermiddel; het is gereedschap dat rendeert zodra je data en je proces het toelaten. Dat zo houden vraagt om proactief beheer in plaats van reactief: iemand die modellen, bronnen en eigenaren scherp houdt.

Leveranciersbeheer: je blijft zelf verantwoordelijk

BIO2 scherpt de eisen aan voor uitbesteding en toezicht op derden, en de eindverantwoordelijkheid blijft waar die was: bij jouw organisatie. Uitbesteden mag dus prima, verantwoording uitbesteden niet.

Praktisch betekent dat: kies een partner die het bewijs levert dat jij nodig hebt voor je verantwoording. Denk aan gecontroleerde, auditable toegang tot je omgeving en vaste rapportages over wat er is gedaan en wat het opleverde. Bij onze Managed Services zijn auditable toegang en transparante rapportage daarom standaard onderdeel van de dienst, geen optie. De actuele versie van de baseline en het ondersteuningsmateriaal vind je op bio-overheid.nl.

Veelgestelde vragen

• Waar begin ik met AIOps?
• Wat heb ik nodig voordat AIOps werkt?
• Vervangt AIOps engineers?
• Wat is AIOps?

De Baseline Informatiebeveiliging Overheid 2 (BIO2) is het basisnormenkader voor informatiebeveiliging binnen alle overheidslagen: Rijk, gemeenten, provincies en waterschappen. Het kader is gebaseerd op ISO 27001 en 27002 en krijgt via de Cyberbeveiligingswet een wettelijke basis. Versie 1.3 is op 5 maart 2026 gepubliceerd in de Staatscourant, en dat is meer dan een administratieve mijlpaal: de ministeriële regeling onder de wet verwijst voor de zorgplicht van de sector Overheid rechtstreeks naar die publicatie. In dit artikel laten we de normteksten voor wat ze zijn en kijken we naar één vraag: wat betekent BIO2 concreet voor je logging, je monitoring en je rapportage?

Wat er verandert ten opzichte van BIO 1.04

Drie wijzigingen springen eruit.

Eén nuance die vrijwel nergens correct wordt opgeschreven: BIO2 v1.3 geldt sinds de publicatie als verplichtende zelfregulering voor het Rijk, provincies en waterschappen. Gemeenten werkten formeel nog met BIO 1.04, met BIO2 als richtinggevend kader, tot de inwerkingtreding van de Cyberbeveiligingswet op 15 augustus 2026. Vanaf dat moment loopt de verplichting voor alle bestuurslagen via de wet en de bijbehorende regeling.

Risicogestuurd werken betekent: je moet je risico kunnen zien

Het schrappen van de BBN-tabel klinkt als een detail, maar het verandert je werk fundamenteel: er valt niets meer af te vinken. Je moet per proces en informatiesysteem bepalen welk risico je loopt, en dat kan alleen met zicht op wat er in die systemen gebeurt. Zonder monitoring geen risicobeeld.

Neem een kritiek burgerproces: het uitbetalen van uitkeringen. Het risico zit zelden in de applicatie alleen, maar in de keten eromheen: de koppeling met de basisregistratie, de batchverwerking die ’s nachts draait, het service-account dat die batch uitvoert. Risicogestuurd werken betekent dat je die keten kunt zien: weet wanneer de batch niet draaide, wanneer het account buiten het venster inlogde, wanneer de koppeling haperde. Dat is geen beleidsvraag meer, dat is monitoring.

Opzet, bestaan en werking aantonen

BIO2 vraagt dat je van maatregelen de opzet, het bestaan en de werking kunt aantonen. Drie woorden, drie artefacten.

• Opzet: beleid en configuratie. Wat heb je bedacht en hoe is het ingericht?
• Bestaan: bewijs dat de maatregel actief is. Niet het beleidsdocument, maar de draaiende regel, de aanleverende logbron.
• Werking: meetgegevens over een langere periode. Deed de maatregel wat hij moest doen, ook in maart, ook in de vakantieperiode?

De derde is de moeilijkste, want werking kun je niet met terugwerkende kracht verzinnen. Je krijgt haar alleen uit continue monitoring en periodieke rapportage die je al die tijd hebt laten lopen. Wie daar pas bij de eerste audit aan begint, is per definitie te laat.

OT valt er ook onder

Een punt dat makkelijk wordt gemist: de BIO2-communicatie van februari 2026 stond volledig in het teken van OT-security, en de Cybersecurity Implementatierichtlijn (CSIR) is binnen de overheid de implementatierichtlijn voor industriële omgevingen. Voor waterschappen met gemalen, voor Rijkswaterstaat, en voor gemeenten met tunnels, bruggen of sluizen betekent dat: de monitoring van industriële systemen valt binnen de scope van je normenkader. Hoe je monitoring in industriële omgevingen inricht zonder je OT-netwerk open te zetten, lees je in ons artikel over het Purdue-model.

Leveranciersbeheer: je blijft zelf verantwoordelijk

BIO2 scherpt de eisen aan voor uitbesteding en toezicht op derden, en de eindverantwoordelijkheid blijft waar die was: bij jouw organisatie. Uitbesteden mag dus prima, verantwoording uitbesteden niet.

Praktisch betekent dat: kies een partner die het bewijs levert dat jij nodig hebt voor je verantwoording. Denk aan gecontroleerde, auditable toegang tot je omgeving en vaste rapportages over wat er is gedaan en wat het opleverde. Bij onze Managed Services zijn auditable toegang en transparante rapportage daarom standaard onderdeel van de dienst, geen optie. De actuele versie van de baseline en het ondersteuningsmateriaal vind je op bio-overheid.nl.

Veelgestelde vragen

• Mag ik onder BIO2 mijn beheer uitbesteden?
• Wat is er veranderd ten opzichte van BIO 1.04?
• Geldt BIO2 al voor gemeenten?
• Wat is BIO2?

Op 15 augustus 2026 treedt de Cyberbeveiligingswet in werking, de Nederlandse implementatie van NIS2. De Eerste Kamer stemde op 7 juli in, geen stip op de horizon meer, maar een datum in je agenda. Dit artikel gaat over één onderdeel: logging en monitoring. Welke bronnen je op orde moet hebben, wat de wet wel en niet zegt over bewaartermijnen, en hoe je aantoont dat het werkt. Of jouw organisatie onder de wet valt, lees je in onze pijlerblog over de Cyber Security Assessment-keten

Wat de wet wel zegt over logging, en wat niet

NIS2 noemt logging in artikel 21 als onderdeel van de zorgplicht: maatregelen om incidenten te detecteren en af te handelen, inclusief registratie van gebeurtenissen. Een bewaartermijn schrijft de wet niet voor: nergens staat zes maanden, nergens twee jaar. Ook het Cyberbeveiligingsbesluit en de ministeriële regelingen per sector geven op dit moment geen vaste termijn voor alle logdata.

Iedere partij die je nu een hard getal belooft, verzint dat getal. Wat de wet wel vraagt: dat je incidenten kunt detecteren, onderzoeken en op tijd melden, en daar kun je je termijnen op bouwen.

Checklist: de negen logbronnen die je op orde moet hebben

1. Authenticatie en autorisatie. Wie logt waar in, en waar mislukt dat opvallend vaak? Dit is de bron waar vrijwel elk onderzoek begint.
2. Netwerkverkeer op de perimeter. Firewall, VPN en proxy laten zien wat er de organisatie in en uit gaat.
3. Endpoint-detectie. EDR-telemetrie van werkplekken en servers, waar de meeste aanvallen zichtbaar worden.
4. Configuratiewijzigingen. Wie zette welke regel uit, en wanneer? Zonder deze bron is elk incidentonderzoek giswerk.
5. Privileged sessies. Beheerdersaccounts en service-accounts kunnen het meest, dus verdienen het meeste zicht.
6. Het cloud control plane. AWS CloudTrail, Azure Activity Log en vergelijkbare audit-logs: wie deed wat met je cloudomgeving zelf.
7. Back-up en restore. Draaide de back-up, en is een restore ooit echt getest? Bij ransomware is dit de bron die telt.
8. OT-assets, indien van toepassing. Industriële systemen vallen ook onder je zorgplicht; beschikbaarheid en afwijkend gedrag zijn daar de signalen.
9. De logging van je logging. De gezondheid van je logpijplijn zelf: welke bron is stilgevallen, waar loopt vertraging op? Vrijwel iedereen vergeet deze, en het is precies de bron waarmee je de andere acht bewaakt.

Hoe je bewaartermijnen bepaalt zonder dat de wet ze geeft

Bepaal de termijn per logbron, op basis van drie vragen: hoe lang duurt het voordat je een incident ontdekt, hoe lang heb je nodig om het te onderzoeken, en wat moet je kunnen melden? De meldplicht is streng: binnen 24 uur moet bij een significant incident een vroegtijdige waarschuwing de deur uit. En een aanvaller die vier maanden onopgemerkt binnen is, is geen uitzondering, bewaar je logs dertig dagen, dan valt er bij ontdekking niets meer te onderzoeken.

Lange termijnen hoeven niet duur te zijn: houd recente data hot (direct doorzoekbaar, prijzig) voor detectie en verhuis oudere data naar cold of archive storage (traag, goedkoop). Een pipeline-laag maakt dat onderscheid praktisch uitvoerbaar; hoe je zo je logvolume beheersbaar houdt, lees je in ons artikel over telemetry pipelines.

Aantoonbaarheid: opzet, bestaan en werking

Een toezichthouder vraagt niet óf je logt, maar of je kunt aantonen dat de maatregel is opgezet, bestaat en werkt. Drie woorden, drie artefacten.

• Opzet: een gedocumenteerde logstrategie. Welke bronnen, waarom, met welke termijn.
• Bestaan: bewijs dat de bronnen daadwerkelijk aanleveren, dus monitoring op de pijplijn zelf.
• Werking: periodieke rapportage die over een langere periode laat zien dat het geheel functioneert: dekking, uitval, opvolging.

Die derde is in de praktijk de lastigste, omdat je haar niet achteraf kunt reconstrueren. Bij SMT is dat daarom standaard onderdeel van elke Managed Service: vaste rapportage met KPI’s, trends en bevindingen, zodat het bewijs er ligt op het moment dat iemand erom vraagt.

Waar organisaties in de praktijk op stuklopen

1. Logbronnen die stilletjes stoppen met aanleveren. Een certificaat verloopt, een agent crasht, en niemand merkt het tot het onderzoek begint.
2. Tijdsynchronisatie die niet klopt. Loopt de klok van je firewall drie minuten voor op die van je servers, dan valt er niets meer te correleren.
3. Logvolume dat het budget opeet. Waarna bronnen worden uitgezet om kosten te drukken. Dat is de gevaarlijkste bezuiniging die er is: je bespaart op precies het zicht dat de wet van je vraagt.
4. Geen eigenaar. Logging is van iedereen een beetje en dus van niemand. Zonder eigenaar verzandt elke goede opzet binnen een jaar.

De derde valkuil is geen natuurwet: wie data filtert voordat die het dure platform bereikt, houdt volume en budget in de hand zonder bronnen op te offeren. De actuele stand van de wet vind je op ncsc.nl.

Veelgestelde vragen

• Val ik onder de Cyberbeveiligingswet?
• Hoe toon ik aan dat mijn logging werkt?
• Welke logbronnen heb ik minimaal nodig?
• Wanneer treedt de Cyberbeveiligingswet in werking?
• Hoe lang moet ik logs bewaren onder NIS2?

Het Purdue-model is een referentiearchitectuur die industriële netwerken opdeelt in gelaagde zones, van de fysieke procesbesturing op de werkvloer tot de bedrijfs-IT op kantoor. Per zone ligt vast welk verkeer erin en eruit mag, zodat een storing of aanval in de ene laag niet zomaar doordringt tot de volgende. Eerlijk is eerlijk: het model stamt uit een tijd waarin OT-netwerken echt gescheiden waren. Die aanname houdt niet meer, terwijl veel organisaties hun monitoring nog inrichten alsof de muren er nog staan.

Hieronder eerst het model, daarna waar het in de praktijk om draait: monitoringdata uit je OT-omgeving halen zonder die omgeving open te zetten.

Het Purdue-model in vijf niveaus

Het model telt zes lagen, van 0 tot en met 5. Hoe lager het niveau, hoe dichter op het fysieke proces en hoe zwaarder beschikbaarheid weegt.

Tussen niveau 3 en 4 zit in de praktijk nog niveau 3.5: de industriële DMZ, de plek waar IT en OT elkaar gecontroleerd raken, en waar je monitoringvraagstuk zich afspeelt.

Waarom de scheiding tussen IT en OT verdwijnt

Drie ontwikkelingen slopen de klassieke scheiding.

1. Cloudconnectiviteit voor remote support. Leveranciers kijken op afstand mee voor onderhoud en storingsanalyse, en elke supportverbinding is een pad dat het model nooit voorzien heeft.
2. Industriële IoT. Nieuwe sensoren praten rechtstreeks met een cloudplatform en slaan de lagen simpelweg over.
3. De vraag naar OT-data voor bedrijfsbeslissingen. Onderhoudsplanning, energieverbruik, beschikbaarheid: de antwoorden zitten in OT-data, maar de vragen worden op IT-niveau gesteld.

Dat dit geen nicheonderwerp meer is, zie je bij de overheid: de BIO2-communicatie van februari 2026 stond volledig in het teken van OT-security, en de Cybersecurity Implementatierichtlijn (CSIR) geldt daar als dé OT-norm. Wat dat betekent lees je in wat BIO2 vraagt van OT-omgevingen.

Data uit OT halen zonder je OT-netwerk te openen

Hier zit de technische kern: monitoringdata de ene kant op, zonder dat er ooit een verbinding de andere kant op gaat. Drie patronen, goed te combineren.

1. Unidirectionele gateways of datadiodes. Hardware die verkeer fysiek maar één richting op laat: data verlaat de OT-zone, niets kan terug. In omgevingen met hoge veiligheidseisen vaak het uitgangspunt.
2. Een collector in de DMZ (niveau 3.5). OT-systemen leveren hun data af bij een collector in de tussenlaag; de IT-zone haalt de data daar op. Een directe verbinding tussen beide werelden bestaat niet.
3. Een pipeline-laag die filtert, normaliseert en maskeert. Voordat data de IT-zone bereikt, bepaal je wat er doorheen mag en zonder welke gevoelige velden. Een lichte agent zoals Cribl Edge doet dat werk al dicht bij de bron; meer daarover op onze pagina over data filteren en routeren aan de bron.

Wat je wel en niet meet in een OT-omgeving

In OT gedraagt data zich precies omgekeerd aan IT: een laag volume en een hoge criticaliteit per gebeurtenis, waar IT-logs een hoog volume en een lage criticaliteit hebben. Eén afwijkende melding kan een pomp zijn die het begeeft.

Wel meten: asset-inventaris, protocolafwijkingen in bijvoorbeeld Modbus- of DNP3-verkeer, beschikbaarheid van kritieke assets en firmware-versies.

Niet meten: alles wat een IT-SIEM standaard binnenharkt. Detectieregels die in IT prima werken, produceren in OT vrijwel alleen ruis. Detectie bouw je hier op gedrag en afwijking, niet op volume.

In de praktijk: van tunnelbeheer naar voorspelbare beschikbaarheid

Vialis past dit toe op een tunnel in de A4, onder een start- en landingsbaan van een internationale luchthaven. Bestaande sensordata wordt via Cribl gefilterd en verrijkt, en in Splunk geanalyseerd op patronen die op slijtage wijzen: verhoogd stroomverbruik bij een pomp, oplopende temperaturen, afwijkend ventilatiegedrag. Webhooks starten vervolgacties, zoals het inplannen van onderhoud. Het resultaat is in de operatie duidelijk merkbaar: hogere tunnelbeschikbaarheid, minder ongeplande sluitingen en onderhoud op werkelijke conditie. Lees de volledige case study Vialis (pdf). Hoe je van meten naar onderhoudsbeslissingen komt, lees je in van preventief naar voorspelbaar onderhoud.

Het Purdue-model is niet dood; het is een denkmodel geworden in plaats van een bouwtekening. De grens verschuift naar de vraag welke data haar mag passeren, en wie dat heeft ingericht, wil het zo houden. Dat is het punt waarop het beheer van je monitoringplatform net zo belangrijk wordt als de architectuur zelf.

Veelgestelde vragen

• Wat is het verschil tussen OT-monitoring en IT-monitoring?
• Kun je OT-data monitoren zonder je OT-netwerk te openen?
• Is het Purdue-model nog relevant?

• Wat is het Purdue-model?

  Het Purdue-model is een referentiearchitectuur die industriële netwerken opdeelt in zones, van fysieke procesbesturing op niveau 0 tot bedrijfs-IT op niveau 4 en 5, zodat duidelijk is welk verkeer tussen welke zones is toegestaan.

Alert fatigue is de afstomping die ontstaat wanneer analisten zoveel meldingen krijgen dat ze echte signalen missen. Wie tweehonderd keer per dienst op “close” klikt, klikt op een dag ook de melding weg die ertoe deed. De stelling die dit artikel draagt: alert fatigue is zelden een mensenprobleem en bijna altijd een datakwaliteitsprobleem.

Waar de ruis vandaan komt

1. Regels uit een standaardpakket, nooit aangepast aan de eigen omgeving. De content-packs van je SIEM zijn geschreven voor een gemiddelde organisatie die niet bestaat. Een regel die elders scherp is, loeit bij jou de hele dag.
2. Ontbrekende context. Een beheerder die om 02:00 uur inlogt: verdacht, tenzij het de geplande patchronde is. Zonder wijzigingskalender en asseteigenaar in de melding ziet de analist dat verschil niet, dus onderzoekt hij het. Elke keer weer.
3. Dubbele detecties op verschillende lagen. EDR, firewall en SIEM melden hetzelfde event, elk in eigen bewoording. Eén gebeurtenis, drie tickets.
4. Regels die niemand meer durft uit te zetten. Niemand weet waarom ze bestaan, dus laat iedereen ze staan. Voor de zekerheid. De eerlijkste oorzaak op dit lijstje, en de meest voorkomende.

Wat is detection engineering?

Detection engineering is het behandelen van detectieregels als een product met een levenscyclus, niet als een project dat ooit af is. Elke regel heeft een eigenaar, een doel en een houdbaarheidsdatum. Vijf fasen:

1. Ontwerpen. Welke techniek of welk risico wil je zien, en welke data heb je daarvoor nodig? Eigenaar: de detection engineer.
2. Bouwen. De regel schrijven, met context (assetwaarde, eigenaar) er meteen bij.
3. Testen. Tegen historische data en gesimuleerde aanvallen, voordat de regel live gaat. Eigenaar: engineer plus analist.
4. Afstemmen. De false positive ratio per regel volgen en bijsturen. Eigenaar: de analisten die de meldingen zien; doorlopend, met een vast maandelijks moment.
5. Uitfaseren. Regels die niets meer opleveren gedocumenteerd uitzetten, elk kwartaal. Vrijwel niemand doet deze fase, en het is precies de fase die oorzaak vier hierboven voorkomt.

Meten voordat je tunet

Vier meetwaarden volstaan om te weten waar je staat:

• Meldingen per analist per dienst. De directe maat voor werkdruk.
• False positive ratio per regel. Niet per omgeving, maar per regel, anders weet je nooit welke regel het probleem is.
• Mean time to triage. Hoe lang duurt het voordat iemand een melding heeft beoordeeld?
• Aandeel meldingen dat tot actie leidt. De hardste maat voor signaalwaarde.

Zonder nulmeting kun je na drie maanden tunen niet aantonen dat het hielp, en dan verdwijnt het budget. Streefcijfers geven we bewust niet: die verschillen per omgeving, en wie je er toch een noemt, kent jouw omgeving niet.

Vier maatregelen die het volume echt verlagen

1. Verrijk meldingen met context voordat ze bij een analist landen. Assetwaarde, eigenaar, wijzigingsvenster. De melding “inlog op srv-db-03 (kroonjuweel, eigenaar team Betalingen, geen gepland werk)” triageert zichzelf half.
2. Onderdruk meldingen tijdens geplande wijzigingen. Een patchnacht met vierhonderd meldingen leert analisten precies één ding: negeren.
3. Groepeer verwante meldingen tot één incident. Tien signalen van één aanvalspad horen in één dossier, niet in tien tickets. Waar AI wel en niet helpt bij ruisreductie, lees je in ons artikel over AIOps.
4. Verwijder data zonder detectiewaarde voordat die je SIEM in gaat. Debug-logging en heartbeats voeden geen enkele detectie, maar vervuilen wel elke zoekopdracht. Hoe je data filtert voordat die je SIEM in gaat, lees je in ons artikel over telemetry pipelines.

Een dashboard per component vertelt je hoe de database en de applicatieserver zich voelen, maar niet of de dienst het doet. Groene lampjes en toch klachten, iedereen in operations kent dat gesprek. Service-gebaseerde monitoring draait het om: je koppelt technische signalen aan een bedrijfsproces, zoals “bestelling plaatsen” of “brug bedienen”, en bewaakt dat. In de Splunk-wereld is dit het domein van Splunk Observability Cloud en ITSI.

Dekking meten met MITRE ATT&CK

Als de ruis afneemt, komt de volgende vraag: zien we wel de juiste dingen? Het MITRE ATT&CK-framework beschrijft de technieken die aanvallers daadwerkelijk gebruiken. Koppel je detecties daaraan, en het gesprek verandert van “hoeveel regels hebben we” in “welke technieken zien we, en welke niet”, het enige gesprek dat je risico verkleint.

Eén waarschuwing: dekking najagen om de dekking is de nieuwe valkuil. Dek de technieken die voor jouw omgeving en dreigingsbeeld tellen, en dek die goed.

Detection engineering vraagt om ritme: elke dag kijken, elke maand afstemmen, elk kwartaal opruimen. Dat ritme organiseren wij met 24/7 checks door een team in plaats van een persoon. Speelt de vraag of je dit zelf wilt doen, lees dan ons artikel over welk servicemodel bij je past.

Veelgestelde vragen

• Wat meet ik om te weten of tuning werkt?
• Hoe verlaag ik het aantal false positives?
• Wat is detection engineering?
• Wat is alert fatigue?

Monitoring meet vooraf bepaalde signalen en waarschuwt als een drempelwaarde wordt overschreden. Observability is het vermogen om de toestand van een systeem te begrijpen op basis van de data die het uitzendt, ook bij problemen die je niet had voorzien. Anders gezegd: monitoring vertelt je dát er iets mis is, observability helpt je begrijpen waaróm. De twee termen worden voortdurend door elkaar gebruikt, en dat kost organisaties geld: wie observability koopt voor een monitoringprobleem betaalt te veel, en wie monitoring inzet voor een observabilityprobleem blijft zoeken.

Het verschil in een tabel

De kern zit in die tweede rij. Monitoring bewaakt wat je vooraf kon bedenken. Observability geeft je de mogelijkheid om vragen te stellen die je pas bedenkt op het moment dat het misgaat.

The three pillars of observability: logs, metrics en traces

Logs vertellen wat er gebeurde: een foutmelding met stacktrace, een geweigerde inlogpoging, een time-out met de exacte parameters erbij. Ze zijn rijk aan detail, maar duur in volume.

Metrics vertellen hoeveel en hoe vaak: responstijden, foutpercentages, wachtrijlengtes. Compact, goedkoop, ideaal voor trends en alerts, maar zonder het verhaal erachter.

Traces vertellen waar in de keten het gebeurde: het pad van één verzoek langs alle services, met per stap de tijd die het kostte. Onmisbaar zodra één klik door tien systemen gaat.

En dan het eerlijke voorbehoud: de drie pijlers zijn een nuttig model, geen doel. Veel organisaties verzamelen keurig alle drie, in drie losse tools, zonder ze ooit te correleren. Dan heb je drie keer opslagkosten en nul keer inzicht. De waarde ontstaat pas als je vanuit een metric-piek kunt doorklikken naar de bijbehorende trace en logs.

Wanneer monitoring genoeg is

Nu de vraag die leveranciers liever overslaan: heb je observability nodig? Voor een stabiele, monolithische omgeving met bekende faalmodi is klassieke monitoring goedkoper en effectiever. Drie criteria om te beslissen:

1. Architectuur. Draait alles op een handvol servers, of is je landschap gedistribueerd over tientallen services en cloudcomponenten?
2. Vraagpatroon. Stel je bij incidenten steeds dezelfde vragen, of steeds nieuwe? Zodra elke storing een unieke puzzel is, schiet vooraf bedachte monitoring tekort.
3. Veranderingstempo. Wie wekelijks deployt, creëert wekelijks nieuwe manieren om te falen. Hoe sneller je omgeving verandert, hoe minder je vooraf kunt bedenken.

Scoor je op alle drie laag, houd het dan simpel en investeer je budget ergens anders in. Dat advies levert ons niets op, maar het klopt wel.

Van dashboards naar service-inzicht

Een dashboard per component vertelt je hoe de database en de applicatieserver zich voelen, maar niet of de dienst het doet. Groene lampjes en toch klachten, iedereen in operations kent dat gesprek. Service-gebaseerde monitoring draait het om: je koppelt technische signalen aan een bedrijfsproces, zoals “bestelling plaatsen” of “brug bedienen”, en bewaakt dat. In de Splunk-wereld is dit het domein van Splunk Observability Cloud en ITSI.

Wat je nodig hebt om te beginnen

1. Inventariseer welke data je al uitzendt. Applicaties, infrastructuur, cloudplatformen: het meeste is er al.
2. Zorg voor consistente tijdstempels en identifiers over bronnen heen. Zonder gedeelde sleutels valt er niets te correleren; hoe je consistente data over bronnen heen aan de bron regelt, lees je in ons artikel over telemetry pipelines.
3. Definieer wat een dienst is en welke componenten eronder vallen. Dit is een gesprek met de business, geen technische exercitie.
4. Begin met één dienst. Bewijs de waarde daar, en breid daarna pas uit.

Staat deze basis, kijk dan verder naar wat AI hieraan toevoegt. En wie het platform liever niet zelf scherp houdt: het beheer en de optimalisatie van je platform is precies wat wij als Managed Service doen.

Veelgestelde vragen

• Is observability hetzelfde als een SIEM?

  Nee. Observability richt zich op de gezondheid en prestaties van diensten, een SIEM op detectie van beveiligingsincidenten. Ze delen vaak dezelfde databronnen, maar beantwoorden andere vragen.

• Wanneer is monitoring genoeg?
• Wat zijn de three pillars of observability?

  Logs (wat er gebeurde), metrics (hoeveel en hoe vaak) en traces (waar in de keten). Het is een nuttig model, geen doel. Veel organisaties verzamelen alle drie zonder ze te correleren, en daar gaat het mis.

• Wat is het verschil tussen observability en monitoring?

  Monitoring meet vooraf bepaalde signalen en waarschuwt bij overschrijding van een drempelwaarde. Observability is het vermogen om de toestand van een systeem te begrijpen uit de data die het uitzendt, ook bij problemen die je niet had voorzien.

Een Splunk-architectuur is een verzameling gespecialiseerde componenten die data ontvangen, indexeren, doorzoeken en beheren, waarbij clustering zorgt voor beschikbaarheid en schaalbaarheid. Wie de rolverdeling en de twee clustervormen begrijpt, weet waar zijn eigen omgeving kwetsbaar is. Dit stuk is voor Splunk-engineers en -admins, we sparen het jargon niet.

De componenten op een rij

De Splunk-documentatie vertelt wat elk component doet, niet wat er gebeurt als het uitvalt. En juist met die kolom beoordeel je je architectuur.

Indexer clustering: replication factor en search factor

Twee getallen bepalen het gedrag van je indexer cluster: de replication factor (RF) bepaalt hoeveel kopieën van de ruwe data het cluster bewaart, de search factor (SF) hoeveel daarvan ook doorzoekbaar zijn, inclusief tsidx-indexbestanden.

Concreet, met RF3 en SF2: elke bucket bestaat drie keer als ruwe data, waarvan twee direct doorzoekbaar. Valt één indexer uit, dan is er geen dataverlies en blijft zoeken mogelijk, terwijl de cluster manager via fixup de aantallen herstelt. Opslag: drie keer de gecomprimeerde ruwe data plus twee keer de indexbestanden.

De klassieke fout: SF gelijkstellen aan RF “omdat het veiliger klinkt”. Dat levert zelden extra weerbaarheid op, maar wel een extra complete set tsidx-bestanden, je opslagverbruik schiet omhoog zonder dat je er iets voor terugkrijgt. Verhoog SF alleen met een concreet herstelscenario waarin die extra doorzoekbare kopie het verschil maakt.

Search head clustering en captain election

Een search head cluster kiest uit zijn leden een captain: die verdeelt scheduled searches, coördineert de replicatie van knowledge objects (dashboards, saved searches, lookups) en bewaakt de clusterstaat. Valt de captain weg, dan kiezen de overgebleven leden een nieuwe, mits ze met een meerderheid zijn.

Dat meerderheidsvereiste verklaart twee vuistregels. Drie search heads is het minimum, want bij twee is elke uitval meteen het einde van de meerderheid. En een even aantal is een slecht idee: splitst een netwerkpartitie een cluster van vier in tweeën, dan heeft geen van beide helften een meerderheid en liggen scheduled searches en replicatie stil terwijl alle machines gewoon aanstaan.

Vijf fouten die we het vaakst tegenkomen

Met meer dan 500 implementaties achter de rug zien we dezelfde fouten terugkomen. De vijf hardnekkigste:

1. 1. Search factor gelijk aan replication factor, zonder reden. Zie hierboven: veel opslag, weinig winst.
   2. Een monitoring console die zelf niet gemonitord wordt. Het systeem dat alles bewaakt, wordt door niets bewaakt. Valt het stil, dan merkt per definitie niemand dat.
   3. Knowledge objects lokaal op één search head in plaats van in het cluster. Alles werkt, tot die ene search head uitvalt en de dashboards van een heel team nergens anders blijken te bestaan.
   4. Forwarders die zonder load balancing naar één vaste indexer praten. Eén indexer eruit betekent meteen datagaten, en de load in het cluster is structureel scheef.
   5. Een deployment server die te veel clients bedient. Duizenden forwarders op één onderbemeten machine: configuratie-updates druppelen dagenlang binnen, of komen nooit aan.

Wat je periodiek zou moeten controleren

Wil je dit één keer grondig laten doorlichten, dan is de Splunk Health Check de kortste route. Structureler kan ook: Splunk-beheer uitbesteden betekent dat deze controles elke dag gebeuren, door een team in plaats van die ene collega. Hoe je daarna van dashboards naar service-inzicht komt, en waarom omgevingen hun heavy forwarders vervangen door een pipeline-laag, lees je in de vervolgblogs. Twijfel je tussen platformen, lees dan welk platform bij je past.

Veelgestelde vragen

• Wat controleer je periodiek in een Splunk-omgeving?
• Hoeveel search heads heb ik minimaal nodig voor een cluster?
• Hoe zorgen we ervoor dat een investering in Splunk rendabel blijft naarmate onze data groeit?
• We gebruiken al meerdere monitoring- en securitytools. Wat voegt Splunk dan nog toe?
• Hoe helpt Splunk ons om sneller inzicht te krijgen in problemen voordat ze impact hebben op de business?

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

1. 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.
2. Verrijken. Voeg context toe terwijl de data onderweg is: assetwaarde, eigenaar, omgeving. Een verrijkte melding hoeft een analist niet meer op te zoeken.
3. Routeren. Stuur elke stroom naar de goedkoopste bestemming die nog voldoet: detectiewaardige data naar het SIEM, compliance-data rechtstreeks naar goedkope object storage.
4. 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

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

1. Meet je huidige volume per bron. Niet het totaal, maar per bron, daar zitten de verrassingen.
2. Bepaal per bron de detectie- en compliancewaarde. Welke detecties draaien erop, welke bewaarplicht geldt? Data zonder antwoord op beide vragen is je eerste kandidaat.
3. 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.
4. Verleg één bron en vergelijk. Zelfde detecties, zelfde dashboards, minder volume? Dan werkt het aantoonbaar.
5. 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.

Veelgestelde vragen

• Hoeveel logvolume kan ik besparen met een pipeline?

  Dat verschilt per omgeving en vooral per bron. Ter indicatie uit de praktijk: bij PostNL daalde het ingest-volume van AWS CloudTrail met 40 procent, waar vooraf 30 procent was verwacht.

• Wat is het verschil tussen Cribl Stream en Cribl Edge?

  Stream is de centrale verwerkingslaag, Edge een lichte agent die dicht bij de bron draait. Edge is relevant voor OT-omgevingen en verre locaties waar je bandbreedte wilt sparen of data niet ongefilterd wilt versturen.

• Wat doet Cribl Stream precies?

  Cribl Stream verwerkt datastromen centraal: het filtert wat geen waarde heeft, verrijkt met context, routeert naar de juiste bestemming en maskeert gevoelige velden. Zo verlaag je volume en kosten zonder detectiedekking op te geven.

• Wat is een telemetry pipeline?

  Een telemetry pipeline is een tussenlaag tussen je databronnen en je analyse- of securityplatformen die bepaalt wat waarheen gaat: filteren, verrijken, routeren en maskeren, voordat de data zijn bestemming bereikt.

Voorspellend onderhoud betekent onderhoud plannen op basis van de werkelijke conditie en het gedrag van een asset, in plaats van op een vaste kalender. Internationaal heet het predictive maintenance, en het steunt op data die de asset en de systemen eromheen vaak al produceren. Daarmee is meteen gezegd wat dit artikel anders maakt dan de meeste stukken over dit onderwerp: het gaat niet over een onderhoudspakket aanschaffen, maar over de data die je al hebt en wat daarvoor nodig is.

Drie vormen van onderhoud, en wat ze kosten

En nu het eerlijke verhaal: voor veel assets is preventief onderhoud gewoon prima. Een vast interval voor iets goedkoops dat zelden faalt, hoef je niet slimmer te maken. Voorspellend onderhoud loont bij assets waar uitval duur of gevaarlijk is: de tunnel, de terminal, het gemaal.

Welke data je nodig hebt (en waarschijnlijk al hebt)

Vier bronnen vormen samen het beeld.

1. Sensordata uit de asset zelf. Stroomverbruik, temperatuur, trilling, druk: de signalen die slijtage verraden.
2. Logdata uit de besturingssystemen. PLC’s en SCADA registreren schakelmomenten, foutcodes en afwijkingen die je in sensordata alleen niet ziet.
3. Netwerktelemetrie. Een installatie die hapert, kondigt zich op het netwerk vaak eerder aan dan in het proces.
4. De storingshistorie uit je onderhoudssysteem. Wat ging er eerder kapot, wanneer, en wat ging eraan vooraf? Dit is je referentiemateriaal.

De eerste drie komen meestal al ergens langs, alleen in verschillende systemen met verschillende tijdstempels. Het werk zit niet in het voorspellen, maar in het samenbrengen, en in de vraag hoe je die data veilig uit je OT-omgeving haalt.

Waarom predictive maintenance zelden op het model stukloopt

De meeste voorspellend-onderhoudsprojecten stranden niet op het algoritme. Ze stranden op datakwaliteit, en wel op drie voorspelbare manieren.

1. Te weinig storingshistorie om op te trainen. Kritieke assets falen gelukkig zelden, dus zijn er weinig voorbeelden van hoe falen eruitziet.
2. Tijdstempels die niet synchroon lopen. Als de sensor, de PLC en het onderhoudssysteem elk hun eigen klok hanteren, kun je oorzaak en gevolg niet meer op één tijdlijn leggen.
3. Assets die pas gaan loggen als er al iets mis is. Foutcodes zijn geen conditiedata. Je wilt weten hoe gezond gedrag eruitziet, niet alleen hoe kapot eruitziet.

Onze ervaring, zonder omwegen: met een half jaar goede data kom je verder dan met een geavanceerd model op vuile data. Begin dus bij de data, niet bij het algoritme.

In de praktijk: tunnels en terminals

Vialis past dit toe op een tunnel in de A4. Sensordata wordt via Cribl gefilterd en verrijkt, en in Splunk geanalyseerd op patronen die op slijtage wijzen; webhooks starten vervolgacties zoals het inplannen van onderhoud. Het effect: hogere tunnelbeschikbaarheid, minder ongeplande sluitingen en onderhoud op werkelijke conditie. Lees de case study Vialis (pdf).

Bij Rotterdam World Gateway (RWG), een van de meest geautomatiseerde containerterminals ter wereld, zat het probleem niet in een gebrek aan data maar aan zichtbaarheid: data lag verspreid over logsystemen, applicaties, leverancierssystemen en OT. Door die stromen in Splunk te correleren ging de start van een probleemanalyse van uren naar minuten en veranderde stilstand van verrassing in beheersing. Lees de case study RWG (pdf).

Een realistisch stappenplan

1. Kies een asset waar uitval echt pijn doet. Niet de makkelijkste, maar de duurste storing van vorig jaar.
2. Inventariseer welke data die asset nu al produceert. Sensoren, besturing, netwerk, onderhoudssysteem, meestal meer dan je denkt.
3. Breng die data samen op één tijdlijn. Zelfde klok, zelfde identifiers. Dit is tachtig procent van het werk.
4. Leg de storingshistorie ernaast en zoek patronen met het blote oog. Wat zag je in de dagen voor elke storing? Vaak springt het patroon eruit zonder code.
5. Automatiseer pas als je het patroon zelf herkent. Een model moet bevestigen wat jij al snapt. Dit advies krijg je van softwareleveranciers niet, en het scheelt je een mislukt project.

Voorspellend onderhoud is geen product dat je koopt, maar een werkwijze die je opbouwt, en die valt of staat met de continuïteit van kritieke systemen eronder. Voor de servicelaag daarboven is ITSI en service-monitoring het gereedschap.

Veelgestelde vragen

• Waarom mislukken predictive maintenance-projecten?
• Heb ik speciale software nodig voor predictive maintenance?
• Wat is voorspellend onderhoud?

AIOps is het toepassen van machine learning en statistische analyse op operationele data: om afwijkingen te vinden, meldingen te correleren en problemen te voorspellen voordat ze uitval worden. Tot zover de definitie die je overal leest. Dit artikel doet iets wat de meeste stukken over AIOps overslaan: het beschrijft ook wat AIOps niet oplost. Die kant hoor je zelden van partijen die het verkopen, en het is precies de kant die bepaalt of jouw investering iets oplevert.

De vier dingen die AIOps daadwerkelijk goed doet

1. Anomaliedetectie op tijdreeksen. Een statische drempel zegt: alarm boven 80 procent. Een model leert dat 70 procent op dinsdagochtend normaal is en op zondagnacht niet, en slaat dus eerder én preciezer aan. In de Splunk-stack is dit het domein van de Machine Learning Toolkit.
2. Correlatie van meldingen naar één incident. Storage-latency, database-timeouts en applicatiefouten zijn geen drie problemen; het is één probleem met drie gezichten. Splunk ITSI groepeert die signalen tot één episode.
3. Ruisreductie. Dezelfde melding die elke vijf minuten terugkomt, wordt één melding met een teller. Klinkt banaal, scheelt in de praktijk het meeste geklik.
4. Capaciteitsvoorspelling. Op basis van trends zie je dat een schijf over drie weken volloopt, in plaats van vannacht om drie uur, dat verplaatst werk van paniek naar planning.

Waar dit in de praktijk zit: de Splunk Machine Learning Toolkit en ITSI voor respectievelijk de modellen en de servicecorrelatie.

De drie dingen die AIOps niet oplost

1. AIOps repareert geen vuile data. Een model op inconsistente logs geeft zelfverzekerde onzin. Ontbrekende velden, dubbele bronnen en klokken die uit elkaar lopen worden niet weggemodelleerd; ze worden versterkt.
2. AIOps vervangt geen engineer. Het model wijst aan waar je moet kijken, niet waarom het misgaat in jouw architectuur, welke workaround uit 2021 nog ergens draait, of welke afhankelijkheid nooit is gedocumenteerd. Het verkort de zoektijd; de diagnose blijft mensenwerk.
3. AIOps lost geen procesprobleem op. Als niemand eigenaar is van een alert, verandert een slimmer alert daar niets aan. Het wordt alleen sneller genegeerd.

Vandaar ons uitgangspunt: niet de hype volgen, maar wat werkt in jouw landschap. Meer alerts zijn zelden het antwoord, waarom dat zo is, lees je in ons artikel over waarom meer alerts niet helpen.

Van chaos naar controle: een voorbeeld

Hoe dit uitpakt als de voorwaarden op orde zijn, beschrijft onze use case over Splunk AI. De uitgangssituatie is herkenbaar: miljoenen signalen per seconde uit IT en OT, meldingen die zich opstapelen, teams die tijd verliezen aan vals alarm. Door logdata samen te brengen in Splunk, machine learning afwijkingen te laten herkennen die met vaste regels onzichtbaar blijven, en verdachte gebeurtenissen automatisch naar het juiste team te routeren, veranderde dat beeld. Het resultaat uit de use case: 75 procent minder valse meldingen, snellere detectie van echte dreigingen en één platform waar IT- en OT-teams samen mee werken. De volledige use case Splunk AI (pdf) lees je in ons downloadcentrum.

Hoe je AIOps stapsgewijs invoert

1. Kies één use case met een duidelijke eigenaar. Niet “alles slimmer maken”, maar bijvoorbeeld: eerder zien dat de orderverwerking hapert.
2. Doe een nulmeting. Aantal meldingen per week, mean time to detect. Zonder nulmeting valt succes niet te bewijzen.
3. Normaliseer de databronnen voor die ene use case. Niet je hele landschap; alleen wat deze detectie nodig heeft.
4. Laat het model meelopen zonder actie. Een paar weken schaduwdraaien laat zien of het model jouw normaal begrijpt.
5. Meet opnieuw en beslis op cijfers. Minder meldingen, snellere detectie? Uitbreiden. Zo niet: stoppen kost nu weinig, precies waarom je klein begon.

AIOps is geen wondermiddel; het is gereedschap dat rendeert zodra je data en je proces het toelaten. Dat zo houden vraagt om proactief beheer in plaats van reactief: iemand die modellen, bronnen en eigenaren scherp houdt.

Leveranciersbeheer: je blijft zelf verantwoordelijk

BIO2 scherpt de eisen aan voor uitbesteding en toezicht op derden, en de eindverantwoordelijkheid blijft waar die was: bij jouw organisatie. Uitbesteden mag dus prima, verantwoording uitbesteden niet.

Praktisch betekent dat: kies een partner die het bewijs levert dat jij nodig hebt voor je verantwoording. Denk aan gecontroleerde, auditable toegang tot je omgeving en vaste rapportages over wat er is gedaan en wat het opleverde. Bij onze Managed Services zijn auditable toegang en transparante rapportage daarom standaard onderdeel van de dienst, geen optie. De actuele versie van de baseline en het ondersteuningsmateriaal vind je op bio-overheid.nl.

Veelgestelde vragen

• Waar begin ik met AIOps?
• Wat heb ik nodig voordat AIOps werkt?
• Vervangt AIOps engineers?
• Wat is AIOps?

De Baseline Informatiebeveiliging Overheid 2 (BIO2) is het basisnormenkader voor informatiebeveiliging binnen alle overheidslagen: Rijk, gemeenten, provincies en waterschappen. Het kader is gebaseerd op ISO 27001 en 27002 en krijgt via de Cyberbeveiligingswet een wettelijke basis. Versie 1.3 is op 5 maart 2026 gepubliceerd in de Staatscourant, en dat is meer dan een administratieve mijlpaal: de ministeriële regeling onder de wet verwijst voor de zorgplicht van de sector Overheid rechtstreeks naar die publicatie. In dit artikel laten we de normteksten voor wat ze zijn en kijken we naar één vraag: wat betekent BIO2 concreet voor je logging, je monitoring en je rapportage?

Wat er verandert ten opzichte van BIO 1.04

Drie wijzigingen springen eruit.

Eén nuance die vrijwel nergens correct wordt opgeschreven: BIO2 v1.3 geldt sinds de publicatie als verplichtende zelfregulering voor het Rijk, provincies en waterschappen. Gemeenten werkten formeel nog met BIO 1.04, met BIO2 als richtinggevend kader, tot de inwerkingtreding van de Cyberbeveiligingswet op 15 augustus 2026. Vanaf dat moment loopt de verplichting voor alle bestuurslagen via de wet en de bijbehorende regeling.

Risicogestuurd werken betekent: je moet je risico kunnen zien

Het schrappen van de BBN-tabel klinkt als een detail, maar het verandert je werk fundamenteel: er valt niets meer af te vinken. Je moet per proces en informatiesysteem bepalen welk risico je loopt, en dat kan alleen met zicht op wat er in die systemen gebeurt. Zonder monitoring geen risicobeeld.

Neem een kritiek burgerproces: het uitbetalen van uitkeringen. Het risico zit zelden in de applicatie alleen, maar in de keten eromheen: de koppeling met de basisregistratie, de batchverwerking die ’s nachts draait, het service-account dat die batch uitvoert. Risicogestuurd werken betekent dat je die keten kunt zien: weet wanneer de batch niet draaide, wanneer het account buiten het venster inlogde, wanneer de koppeling haperde. Dat is geen beleidsvraag meer, dat is monitoring.

Opzet, bestaan en werking aantonen

BIO2 vraagt dat je van maatregelen de opzet, het bestaan en de werking kunt aantonen. Drie woorden, drie artefacten.

• Opzet: beleid en configuratie. Wat heb je bedacht en hoe is het ingericht?
• Bestaan: bewijs dat de maatregel actief is. Niet het beleidsdocument, maar de draaiende regel, de aanleverende logbron.
• Werking: meetgegevens over een langere periode. Deed de maatregel wat hij moest doen, ook in maart, ook in de vakantieperiode?

De derde is de moeilijkste, want werking kun je niet met terugwerkende kracht verzinnen. Je krijgt haar alleen uit continue monitoring en periodieke rapportage die je al die tijd hebt laten lopen. Wie daar pas bij de eerste audit aan begint, is per definitie te laat.

OT valt er ook onder

Een punt dat makkelijk wordt gemist: de BIO2-communicatie van februari 2026 stond volledig in het teken van OT-security, en de Cybersecurity Implementatierichtlijn (CSIR) is binnen de overheid de implementatierichtlijn voor industriële omgevingen. Voor waterschappen met gemalen, voor Rijkswaterstaat, en voor gemeenten met tunnels, bruggen of sluizen betekent dat: de monitoring van industriële systemen valt binnen de scope van je normenkader. Hoe je monitoring in industriële omgevingen inricht zonder je OT-netwerk open te zetten, lees je in ons artikel over het Purdue-model.

Leveranciersbeheer: je blijft zelf verantwoordelijk

BIO2 scherpt de eisen aan voor uitbesteding en toezicht op derden, en de eindverantwoordelijkheid blijft waar die was: bij jouw organisatie. Uitbesteden mag dus prima, verantwoording uitbesteden niet.

Praktisch betekent dat: kies een partner die het bewijs levert dat jij nodig hebt voor je verantwoording. Denk aan gecontroleerde, auditable toegang tot je omgeving en vaste rapportages over wat er is gedaan en wat het opleverde. Bij onze Managed Services zijn auditable toegang en transparante rapportage daarom standaard onderdeel van de dienst, geen optie. De actuele versie van de baseline en het ondersteuningsmateriaal vind je op bio-overheid.nl.

Veelgestelde vragen

• Mag ik onder BIO2 mijn beheer uitbesteden?
• Wat is er veranderd ten opzichte van BIO 1.04?
• Geldt BIO2 al voor gemeenten?
• Wat is BIO2?

Op 15 augustus 2026 treedt de Cyberbeveiligingswet in werking, de Nederlandse implementatie van NIS2. De Eerste Kamer stemde op 7 juli in, geen stip op de horizon meer, maar een datum in je agenda. Dit artikel gaat over één onderdeel: logging en monitoring. Welke bronnen je op orde moet hebben, wat de wet wel en niet zegt over bewaartermijnen, en hoe je aantoont dat het werkt. Of jouw organisatie onder de wet valt, lees je in onze pijlerblog over de Cyber Security Assessment-keten

Wat de wet wel zegt over logging, en wat niet

NIS2 noemt logging in artikel 21 als onderdeel van de zorgplicht: maatregelen om incidenten te detecteren en af te handelen, inclusief registratie van gebeurtenissen. Een bewaartermijn schrijft de wet niet voor: nergens staat zes maanden, nergens twee jaar. Ook het Cyberbeveiligingsbesluit en de ministeriële regelingen per sector geven op dit moment geen vaste termijn voor alle logdata.

Iedere partij die je nu een hard getal belooft, verzint dat getal. Wat de wet wel vraagt: dat je incidenten kunt detecteren, onderzoeken en op tijd melden, en daar kun je je termijnen op bouwen.

Checklist: de negen logbronnen die je op orde moet hebben

1. Authenticatie en autorisatie. Wie logt waar in, en waar mislukt dat opvallend vaak? Dit is de bron waar vrijwel elk onderzoek begint.
2. Netwerkverkeer op de perimeter. Firewall, VPN en proxy laten zien wat er de organisatie in en uit gaat.
3. Endpoint-detectie. EDR-telemetrie van werkplekken en servers, waar de meeste aanvallen zichtbaar worden.
4. Configuratiewijzigingen. Wie zette welke regel uit, en wanneer? Zonder deze bron is elk incidentonderzoek giswerk.
5. Privileged sessies. Beheerdersaccounts en service-accounts kunnen het meest, dus verdienen het meeste zicht.
6. Het cloud control plane. AWS CloudTrail, Azure Activity Log en vergelijkbare audit-logs: wie deed wat met je cloudomgeving zelf.
7. Back-up en restore. Draaide de back-up, en is een restore ooit echt getest? Bij ransomware is dit de bron die telt.
8. OT-assets, indien van toepassing. Industriële systemen vallen ook onder je zorgplicht; beschikbaarheid en afwijkend gedrag zijn daar de signalen.
9. De logging van je logging. De gezondheid van je logpijplijn zelf: welke bron is stilgevallen, waar loopt vertraging op? Vrijwel iedereen vergeet deze, en het is precies de bron waarmee je de andere acht bewaakt.

Hoe je bewaartermijnen bepaalt zonder dat de wet ze geeft

Bepaal de termijn per logbron, op basis van drie vragen: hoe lang duurt het voordat je een incident ontdekt, hoe lang heb je nodig om het te onderzoeken, en wat moet je kunnen melden? De meldplicht is streng: binnen 24 uur moet bij een significant incident een vroegtijdige waarschuwing de deur uit. En een aanvaller die vier maanden onopgemerkt binnen is, is geen uitzondering, bewaar je logs dertig dagen, dan valt er bij ontdekking niets meer te onderzoeken.

Lange termijnen hoeven niet duur te zijn: houd recente data hot (direct doorzoekbaar, prijzig) voor detectie en verhuis oudere data naar cold of archive storage (traag, goedkoop). Een pipeline-laag maakt dat onderscheid praktisch uitvoerbaar; hoe je zo je logvolume beheersbaar houdt, lees je in ons artikel over telemetry pipelines.

Aantoonbaarheid: opzet, bestaan en werking

Een toezichthouder vraagt niet óf je logt, maar of je kunt aantonen dat de maatregel is opgezet, bestaat en werkt. Drie woorden, drie artefacten.

• Opzet: een gedocumenteerde logstrategie. Welke bronnen, waarom, met welke termijn.
• Bestaan: bewijs dat de bronnen daadwerkelijk aanleveren, dus monitoring op de pijplijn zelf.
• Werking: periodieke rapportage die over een langere periode laat zien dat het geheel functioneert: dekking, uitval, opvolging.

Die derde is in de praktijk de lastigste, omdat je haar niet achteraf kunt reconstrueren. Bij SMT is dat daarom standaard onderdeel van elke Managed Service: vaste rapportage met KPI’s, trends en bevindingen, zodat het bewijs er ligt op het moment dat iemand erom vraagt.

Waar organisaties in de praktijk op stuklopen

1. Logbronnen die stilletjes stoppen met aanleveren. Een certificaat verloopt, een agent crasht, en niemand merkt het tot het onderzoek begint.
2. Tijdsynchronisatie die niet klopt. Loopt de klok van je firewall drie minuten voor op die van je servers, dan valt er niets meer te correleren.
3. Logvolume dat het budget opeet. Waarna bronnen worden uitgezet om kosten te drukken. Dat is de gevaarlijkste bezuiniging die er is: je bespaart op precies het zicht dat de wet van je vraagt.
4. Geen eigenaar. Logging is van iedereen een beetje en dus van niemand. Zonder eigenaar verzandt elke goede opzet binnen een jaar.

De derde valkuil is geen natuurwet: wie data filtert voordat die het dure platform bereikt, houdt volume en budget in de hand zonder bronnen op te offeren. De actuele stand van de wet vind je op ncsc.nl.

Veelgestelde vragen

• Val ik onder de Cyberbeveiligingswet?
• Hoe toon ik aan dat mijn logging werkt?
• Welke logbronnen heb ik minimaal nodig?
• Wanneer treedt de Cyberbeveiligingswet in werking?
• Hoe lang moet ik logs bewaren onder NIS2?

Het Purdue-model is een referentiearchitectuur die industriële netwerken opdeelt in gelaagde zones, van de fysieke procesbesturing op de werkvloer tot de bedrijfs-IT op kantoor. Per zone ligt vast welk verkeer erin en eruit mag, zodat een storing of aanval in de ene laag niet zomaar doordringt tot de volgende. Eerlijk is eerlijk: het model stamt uit een tijd waarin OT-netwerken echt gescheiden waren. Die aanname houdt niet meer, terwijl veel organisaties hun monitoring nog inrichten alsof de muren er nog staan.

Hieronder eerst het model, daarna waar het in de praktijk om draait: monitoringdata uit je OT-omgeving halen zonder die omgeving open te zetten.

Het Purdue-model in vijf niveaus

Het model telt zes lagen, van 0 tot en met 5. Hoe lager het niveau, hoe dichter op het fysieke proces en hoe zwaarder beschikbaarheid weegt.

Tussen niveau 3 en 4 zit in de praktijk nog niveau 3.5: de industriële DMZ, de plek waar IT en OT elkaar gecontroleerd raken, en waar je monitoringvraagstuk zich afspeelt.

Waarom de scheiding tussen IT en OT verdwijnt

Drie ontwikkelingen slopen de klassieke scheiding.

1. Cloudconnectiviteit voor remote support. Leveranciers kijken op afstand mee voor onderhoud en storingsanalyse, en elke supportverbinding is een pad dat het model nooit voorzien heeft.
2. Industriële IoT. Nieuwe sensoren praten rechtstreeks met een cloudplatform en slaan de lagen simpelweg over.
3. De vraag naar OT-data voor bedrijfsbeslissingen. Onderhoudsplanning, energieverbruik, beschikbaarheid: de antwoorden zitten in OT-data, maar de vragen worden op IT-niveau gesteld.

Dat dit geen nicheonderwerp meer is, zie je bij de overheid: de BIO2-communicatie van februari 2026 stond volledig in het teken van OT-security, en de Cybersecurity Implementatierichtlijn (CSIR) geldt daar als dé OT-norm. Wat dat betekent lees je in wat BIO2 vraagt van OT-omgevingen.

Data uit OT halen zonder je OT-netwerk te openen

Hier zit de technische kern: monitoringdata de ene kant op, zonder dat er ooit een verbinding de andere kant op gaat. Drie patronen, goed te combineren.

1. Unidirectionele gateways of datadiodes. Hardware die verkeer fysiek maar één richting op laat: data verlaat de OT-zone, niets kan terug. In omgevingen met hoge veiligheidseisen vaak het uitgangspunt.
2. Een collector in de DMZ (niveau 3.5). OT-systemen leveren hun data af bij een collector in de tussenlaag; de IT-zone haalt de data daar op. Een directe verbinding tussen beide werelden bestaat niet.
3. Een pipeline-laag die filtert, normaliseert en maskeert. Voordat data de IT-zone bereikt, bepaal je wat er doorheen mag en zonder welke gevoelige velden. Een lichte agent zoals Cribl Edge doet dat werk al dicht bij de bron; meer daarover op onze pagina over data filteren en routeren aan de bron.

Wat je wel en niet meet in een OT-omgeving

In OT gedraagt data zich precies omgekeerd aan IT: een laag volume en een hoge criticaliteit per gebeurtenis, waar IT-logs een hoog volume en een lage criticaliteit hebben. Eén afwijkende melding kan een pomp zijn die het begeeft.

Wel meten: asset-inventaris, protocolafwijkingen in bijvoorbeeld Modbus- of DNP3-verkeer, beschikbaarheid van kritieke assets en firmware-versies.

Niet meten: alles wat een IT-SIEM standaard binnenharkt. Detectieregels die in IT prima werken, produceren in OT vrijwel alleen ruis. Detectie bouw je hier op gedrag en afwijking, niet op volume.

In de praktijk: van tunnelbeheer naar voorspelbare beschikbaarheid

Vialis past dit toe op een tunnel in de A4, onder een start- en landingsbaan van een internationale luchthaven. Bestaande sensordata wordt via Cribl gefilterd en verrijkt, en in Splunk geanalyseerd op patronen die op slijtage wijzen: verhoogd stroomverbruik bij een pomp, oplopende temperaturen, afwijkend ventilatiegedrag. Webhooks starten vervolgacties, zoals het inplannen van onderhoud. Het resultaat is in de operatie duidelijk merkbaar: hogere tunnelbeschikbaarheid, minder ongeplande sluitingen en onderhoud op werkelijke conditie. Lees de volledige case study Vialis (pdf). Hoe je van meten naar onderhoudsbeslissingen komt, lees je in van preventief naar voorspelbaar onderhoud.

Het Purdue-model is niet dood; het is een denkmodel geworden in plaats van een bouwtekening. De grens verschuift naar de vraag welke data haar mag passeren, en wie dat heeft ingericht, wil het zo houden. Dat is het punt waarop het beheer van je monitoringplatform net zo belangrijk wordt als de architectuur zelf.

Veelgestelde vragen

• Wat is het verschil tussen OT-monitoring en IT-monitoring?
• Kun je OT-data monitoren zonder je OT-netwerk te openen?
• Is het Purdue-model nog relevant?

• Wat is het Purdue-model?

  Het Purdue-model is een referentiearchitectuur die industriële netwerken opdeelt in zones, van fysieke procesbesturing op niveau 0 tot bedrijfs-IT op niveau 4 en 5, zodat duidelijk is welk verkeer tussen welke zones is toegestaan.

Alert fatigue is de afstomping die ontstaat wanneer analisten zoveel meldingen krijgen dat ze echte signalen missen. Wie tweehonderd keer per dienst op “close” klikt, klikt op een dag ook de melding weg die ertoe deed. De stelling die dit artikel draagt: alert fatigue is zelden een mensenprobleem en bijna altijd een datakwaliteitsprobleem.

Waar de ruis vandaan komt

1. Regels uit een standaardpakket, nooit aangepast aan de eigen omgeving. De content-packs van je SIEM zijn geschreven voor een gemiddelde organisatie die niet bestaat. Een regel die elders scherp is, loeit bij jou de hele dag.
2. Ontbrekende context. Een beheerder die om 02:00 uur inlogt: verdacht, tenzij het de geplande patchronde is. Zonder wijzigingskalender en asseteigenaar in de melding ziet de analist dat verschil niet, dus onderzoekt hij het. Elke keer weer.
3. Dubbele detecties op verschillende lagen. EDR, firewall en SIEM melden hetzelfde event, elk in eigen bewoording. Eén gebeurtenis, drie tickets.
4. Regels die niemand meer durft uit te zetten. Niemand weet waarom ze bestaan, dus laat iedereen ze staan. Voor de zekerheid. De eerlijkste oorzaak op dit lijstje, en de meest voorkomende.

Wat is detection engineering?

Detection engineering is het behandelen van detectieregels als een product met een levenscyclus, niet als een project dat ooit af is. Elke regel heeft een eigenaar, een doel en een houdbaarheidsdatum. Vijf fasen:

1. Ontwerpen. Welke techniek of welk risico wil je zien, en welke data heb je daarvoor nodig? Eigenaar: de detection engineer.
2. Bouwen. De regel schrijven, met context (assetwaarde, eigenaar) er meteen bij.
3. Testen. Tegen historische data en gesimuleerde aanvallen, voordat de regel live gaat. Eigenaar: engineer plus analist.
4. Afstemmen. De false positive ratio per regel volgen en bijsturen. Eigenaar: de analisten die de meldingen zien; doorlopend, met een vast maandelijks moment.
5. Uitfaseren. Regels die niets meer opleveren gedocumenteerd uitzetten, elk kwartaal. Vrijwel niemand doet deze fase, en het is precies de fase die oorzaak vier hierboven voorkomt.

Meten voordat je tunet

Vier meetwaarden volstaan om te weten waar je staat:

• Meldingen per analist per dienst. De directe maat voor werkdruk.
• False positive ratio per regel. Niet per omgeving, maar per regel, anders weet je nooit welke regel het probleem is.
• Mean time to triage. Hoe lang duurt het voordat iemand een melding heeft beoordeeld?
• Aandeel meldingen dat tot actie leidt. De hardste maat voor signaalwaarde.

Zonder nulmeting kun je na drie maanden tunen niet aantonen dat het hielp, en dan verdwijnt het budget. Streefcijfers geven we bewust niet: die verschillen per omgeving, en wie je er toch een noemt, kent jouw omgeving niet.

Vier maatregelen die het volume echt verlagen

1. Verrijk meldingen met context voordat ze bij een analist landen. Assetwaarde, eigenaar, wijzigingsvenster. De melding “inlog op srv-db-03 (kroonjuweel, eigenaar team Betalingen, geen gepland werk)” triageert zichzelf half.
2. Onderdruk meldingen tijdens geplande wijzigingen. Een patchnacht met vierhonderd meldingen leert analisten precies één ding: negeren.
3. Groepeer verwante meldingen tot één incident. Tien signalen van één aanvalspad horen in één dossier, niet in tien tickets. Waar AI wel en niet helpt bij ruisreductie, lees je in ons artikel over AIOps.
4. Verwijder data zonder detectiewaarde voordat die je SIEM in gaat. Debug-logging en heartbeats voeden geen enkele detectie, maar vervuilen wel elke zoekopdracht. Hoe je data filtert voordat die je SIEM in gaat, lees je in ons artikel over telemetry pipelines.

Een dashboard per component vertelt je hoe de database en de applicatieserver zich voelen, maar niet of de dienst het doet. Groene lampjes en toch klachten, iedereen in operations kent dat gesprek. Service-gebaseerde monitoring draait het om: je koppelt technische signalen aan een bedrijfsproces, zoals “bestelling plaatsen” of “brug bedienen”, en bewaakt dat. In de Splunk-wereld is dit het domein van Splunk Observability Cloud en ITSI.

Dekking meten met MITRE ATT&CK

Als de ruis afneemt, komt de volgende vraag: zien we wel de juiste dingen? Het MITRE ATT&CK-framework beschrijft de technieken die aanvallers daadwerkelijk gebruiken. Koppel je detecties daaraan, en het gesprek verandert van “hoeveel regels hebben we” in “welke technieken zien we, en welke niet”, het enige gesprek dat je risico verkleint.

Eén waarschuwing: dekking najagen om de dekking is de nieuwe valkuil. Dek de technieken die voor jouw omgeving en dreigingsbeeld tellen, en dek die goed.

Detection engineering vraagt om ritme: elke dag kijken, elke maand afstemmen, elk kwartaal opruimen. Dat ritme organiseren wij met 24/7 checks door een team in plaats van een persoon. Speelt de vraag of je dit zelf wilt doen, lees dan ons artikel over welk servicemodel bij je past.

Veelgestelde vragen

• Wat meet ik om te weten of tuning werkt?
• Hoe verlaag ik het aantal false positives?
• Wat is detection engineering?
• Wat is alert fatigue?

Monitoring meet vooraf bepaalde signalen en waarschuwt als een drempelwaarde wordt overschreden. Observability is het vermogen om de toestand van een systeem te begrijpen op basis van de data die het uitzendt, ook bij problemen die je niet had voorzien. Anders gezegd: monitoring vertelt je dát er iets mis is, observability helpt je begrijpen waaróm. De twee termen worden voortdurend door elkaar gebruikt, en dat kost organisaties geld: wie observability koopt voor een monitoringprobleem betaalt te veel, en wie monitoring inzet voor een observabilityprobleem blijft zoeken.

Het verschil in een tabel

De kern zit in die tweede rij. Monitoring bewaakt wat je vooraf kon bedenken. Observability geeft je de mogelijkheid om vragen te stellen die je pas bedenkt op het moment dat het misgaat.

The three pillars of observability: logs, metrics en traces

Logs vertellen wat er gebeurde: een foutmelding met stacktrace, een geweigerde inlogpoging, een time-out met de exacte parameters erbij. Ze zijn rijk aan detail, maar duur in volume.

Metrics vertellen hoeveel en hoe vaak: responstijden, foutpercentages, wachtrijlengtes. Compact, goedkoop, ideaal voor trends en alerts, maar zonder het verhaal erachter.

Traces vertellen waar in de keten het gebeurde: het pad van één verzoek langs alle services, met per stap de tijd die het kostte. Onmisbaar zodra één klik door tien systemen gaat.

En dan het eerlijke voorbehoud: de drie pijlers zijn een nuttig model, geen doel. Veel organisaties verzamelen keurig alle drie, in drie losse tools, zonder ze ooit te correleren. Dan heb je drie keer opslagkosten en nul keer inzicht. De waarde ontstaat pas als je vanuit een metric-piek kunt doorklikken naar de bijbehorende trace en logs.

Wanneer monitoring genoeg is

Nu de vraag die leveranciers liever overslaan: heb je observability nodig? Voor een stabiele, monolithische omgeving met bekende faalmodi is klassieke monitoring goedkoper en effectiever. Drie criteria om te beslissen:

1. Architectuur. Draait alles op een handvol servers, of is je landschap gedistribueerd over tientallen services en cloudcomponenten?
2. Vraagpatroon. Stel je bij incidenten steeds dezelfde vragen, of steeds nieuwe? Zodra elke storing een unieke puzzel is, schiet vooraf bedachte monitoring tekort.
3. Veranderingstempo. Wie wekelijks deployt, creëert wekelijks nieuwe manieren om te falen. Hoe sneller je omgeving verandert, hoe minder je vooraf kunt bedenken.

Scoor je op alle drie laag, houd het dan simpel en investeer je budget ergens anders in. Dat advies levert ons niets op, maar het klopt wel.

Van dashboards naar service-inzicht

Een dashboard per component vertelt je hoe de database en de applicatieserver zich voelen, maar niet of de dienst het doet. Groene lampjes en toch klachten, iedereen in operations kent dat gesprek. Service-gebaseerde monitoring draait het om: je koppelt technische signalen aan een bedrijfsproces, zoals “bestelling plaatsen” of “brug bedienen”, en bewaakt dat. In de Splunk-wereld is dit het domein van Splunk Observability Cloud en ITSI.

Wat je nodig hebt om te beginnen

1. Inventariseer welke data je al uitzendt. Applicaties, infrastructuur, cloudplatformen: het meeste is er al.
2. Zorg voor consistente tijdstempels en identifiers over bronnen heen. Zonder gedeelde sleutels valt er niets te correleren; hoe je consistente data over bronnen heen aan de bron regelt, lees je in ons artikel over telemetry pipelines.
3. Definieer wat een dienst is en welke componenten eronder vallen. Dit is een gesprek met de business, geen technische exercitie.
4. Begin met één dienst. Bewijs de waarde daar, en breid daarna pas uit.

Staat deze basis, kijk dan verder naar wat AI hieraan toevoegt. En wie het platform liever niet zelf scherp houdt: het beheer en de optimalisatie van je platform is precies wat wij als Managed Service doen.

Veelgestelde vragen

• Is observability hetzelfde als een SIEM?

  Nee. Observability richt zich op de gezondheid en prestaties van diensten, een SIEM op detectie van beveiligingsincidenten. Ze delen vaak dezelfde databronnen, maar beantwoorden andere vragen.

• Wanneer is monitoring genoeg?
• Wat zijn de three pillars of observability?

  Logs (wat er gebeurde), metrics (hoeveel en hoe vaak) en traces (waar in de keten). Het is een nuttig model, geen doel. Veel organisaties verzamelen alle drie zonder ze te correleren, en daar gaat het mis.

• Wat is het verschil tussen observability en monitoring?

  Monitoring meet vooraf bepaalde signalen en waarschuwt bij overschrijding van een drempelwaarde. Observability is het vermogen om de toestand van een systeem te begrijpen uit de data die het uitzendt, ook bij problemen die je niet had voorzien.

Een Splunk-architectuur is een verzameling gespecialiseerde componenten die data ontvangen, indexeren, doorzoeken en beheren, waarbij clustering zorgt voor beschikbaarheid en schaalbaarheid. Wie de rolverdeling en de twee clustervormen begrijpt, weet waar zijn eigen omgeving kwetsbaar is. Dit stuk is voor Splunk-engineers en -admins, we sparen het jargon niet.

De componenten op een rij

De Splunk-documentatie vertelt wat elk component doet, niet wat er gebeurt als het uitvalt. En juist met die kolom beoordeel je je architectuur.

Indexer clustering: replication factor en search factor

Twee getallen bepalen het gedrag van je indexer cluster: de replication factor (RF) bepaalt hoeveel kopieën van de ruwe data het cluster bewaart, de search factor (SF) hoeveel daarvan ook doorzoekbaar zijn, inclusief tsidx-indexbestanden.

Concreet, met RF3 en SF2: elke bucket bestaat drie keer als ruwe data, waarvan twee direct doorzoekbaar. Valt één indexer uit, dan is er geen dataverlies en blijft zoeken mogelijk, terwijl de cluster manager via fixup de aantallen herstelt. Opslag: drie keer de gecomprimeerde ruwe data plus twee keer de indexbestanden.

De klassieke fout: SF gelijkstellen aan RF “omdat het veiliger klinkt”. Dat levert zelden extra weerbaarheid op, maar wel een extra complete set tsidx-bestanden, je opslagverbruik schiet omhoog zonder dat je er iets voor terugkrijgt. Verhoog SF alleen met een concreet herstelscenario waarin die extra doorzoekbare kopie het verschil maakt.

Search head clustering en captain election

Een search head cluster kiest uit zijn leden een captain: die verdeelt scheduled searches, coördineert de replicatie van knowledge objects (dashboards, saved searches, lookups) en bewaakt de clusterstaat. Valt de captain weg, dan kiezen de overgebleven leden een nieuwe, mits ze met een meerderheid zijn.

Dat meerderheidsvereiste verklaart twee vuistregels. Drie search heads is het minimum, want bij twee is elke uitval meteen het einde van de meerderheid. En een even aantal is een slecht idee: splitst een netwerkpartitie een cluster van vier in tweeën, dan heeft geen van beide helften een meerderheid en liggen scheduled searches en replicatie stil terwijl alle machines gewoon aanstaan.

Vijf fouten die we het vaakst tegenkomen

Met meer dan 500 implementaties achter de rug zien we dezelfde fouten terugkomen. De vijf hardnekkigste:

1. 1. Search factor gelijk aan replication factor, zonder reden. Zie hierboven: veel opslag, weinig winst.
   2. Een monitoring console die zelf niet gemonitord wordt. Het systeem dat alles bewaakt, wordt door niets bewaakt. Valt het stil, dan merkt per definitie niemand dat.
   3. Knowledge objects lokaal op één search head in plaats van in het cluster. Alles werkt, tot die ene search head uitvalt en de dashboards van een heel team nergens anders blijken te bestaan.
   4. Forwarders die zonder load balancing naar één vaste indexer praten. Eén indexer eruit betekent meteen datagaten, en de load in het cluster is structureel scheef.
   5. Een deployment server die te veel clients bedient. Duizenden forwarders op één onderbemeten machine: configuratie-updates druppelen dagenlang binnen, of komen nooit aan.

Wat je periodiek zou moeten controleren

Wil je dit één keer grondig laten doorlichten, dan is de Splunk Health Check de kortste route. Structureler kan ook: Splunk-beheer uitbesteden betekent dat deze controles elke dag gebeuren, door een team in plaats van die ene collega. Hoe je daarna van dashboards naar service-inzicht komt, en waarom omgevingen hun heavy forwarders vervangen door een pipeline-laag, lees je in de vervolgblogs. Twijfel je tussen platformen, lees dan welk platform bij je past.

Veelgestelde vragen

• Wat controleer je periodiek in een Splunk-omgeving?
• Hoeveel search heads heb ik minimaal nodig voor een cluster?
• Hoe zorgen we ervoor dat een investering in Splunk rendabel blijft naarmate onze data groeit?
• We gebruiken al meerdere monitoring- en securitytools. Wat voegt Splunk dan nog toe?
• Hoe helpt Splunk ons om sneller inzicht te krijgen in problemen voordat ze impact hebben op de business?

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

1. 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.
2. Verrijken. Voeg context toe terwijl de data onderweg is: assetwaarde, eigenaar, omgeving. Een verrijkte melding hoeft een analist niet meer op te zoeken.
3. Routeren. Stuur elke stroom naar de goedkoopste bestemming die nog voldoet: detectiewaardige data naar het SIEM, compliance-data rechtstreeks naar goedkope object storage.
4. 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

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

1. Meet je huidige volume per bron. Niet het totaal, maar per bron, daar zitten de verrassingen.
2. Bepaal per bron de detectie- en compliancewaarde. Welke detecties draaien erop, welke bewaarplicht geldt? Data zonder antwoord op beide vragen is je eerste kandidaat.
3. 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.
4. Verleg één bron en vergelijk. Zelfde detecties, zelfde dashboards, minder volume? Dan werkt het aantoonbaar.
5. 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.

Veelgestelde vragen

• Hoeveel logvolume kan ik besparen met een pipeline?

  Dat verschilt per omgeving en vooral per bron. Ter indicatie uit de praktijk: bij PostNL daalde het ingest-volume van AWS CloudTrail met 40 procent, waar vooraf 30 procent was verwacht.

• Wat is het verschil tussen Cribl Stream en Cribl Edge?

  Stream is de centrale verwerkingslaag, Edge een lichte agent die dicht bij de bron draait. Edge is relevant voor OT-omgevingen en verre locaties waar je bandbreedte wilt sparen of data niet ongefilterd wilt versturen.

• Wat doet Cribl Stream precies?

  Cribl Stream verwerkt datastromen centraal: het filtert wat geen waarde heeft, verrijkt met context, routeert naar de juiste bestemming en maskeert gevoelige velden. Zo verlaag je volume en kosten zonder detectiedekking op te geven.

• Wat is een telemetry pipeline?

  Een telemetry pipeline is een tussenlaag tussen je databronnen en je analyse- of securityplatformen die bepaalt wat waarheen gaat: filteren, verrijken, routeren en maskeren, voordat de data zijn bestemming bereikt.

Voorspellend onderhoud betekent onderhoud plannen op basis van de werkelijke conditie en het gedrag van een asset, in plaats van op een vaste kalender. Internationaal heet het predictive maintenance, en het steunt op data die de asset en de systemen eromheen vaak al produceren. Daarmee is meteen gezegd wat dit artikel anders maakt dan de meeste stukken over dit onderwerp: het gaat niet over een onderhoudspakket aanschaffen, maar over de data die je al hebt en wat daarvoor nodig is.

Drie vormen van onderhoud, en wat ze kosten

En nu het eerlijke verhaal: voor veel assets is preventief onderhoud gewoon prima. Een vast interval voor iets goedkoops dat zelden faalt, hoef je niet slimmer te maken. Voorspellend onderhoud loont bij assets waar uitval duur of gevaarlijk is: de tunnel, de terminal, het gemaal.

Welke data je nodig hebt (en waarschijnlijk al hebt)

Vier bronnen vormen samen het beeld.

1. Sensordata uit de asset zelf. Stroomverbruik, temperatuur, trilling, druk: de signalen die slijtage verraden.
2. Logdata uit de besturingssystemen. PLC’s en SCADA registreren schakelmomenten, foutcodes en afwijkingen die je in sensordata alleen niet ziet.
3. Netwerktelemetrie. Een installatie die hapert, kondigt zich op het netwerk vaak eerder aan dan in het proces.
4. De storingshistorie uit je onderhoudssysteem. Wat ging er eerder kapot, wanneer, en wat ging eraan vooraf? Dit is je referentiemateriaal.

De eerste drie komen meestal al ergens langs, alleen in verschillende systemen met verschillende tijdstempels. Het werk zit niet in het voorspellen, maar in het samenbrengen, en in de vraag hoe je die data veilig uit je OT-omgeving haalt.

Waarom predictive maintenance zelden op het model stukloopt

De meeste voorspellend-onderhoudsprojecten stranden niet op het algoritme. Ze stranden op datakwaliteit, en wel op drie voorspelbare manieren.

1. Te weinig storingshistorie om op te trainen. Kritieke assets falen gelukkig zelden, dus zijn er weinig voorbeelden van hoe falen eruitziet.
2. Tijdstempels die niet synchroon lopen. Als de sensor, de PLC en het onderhoudssysteem elk hun eigen klok hanteren, kun je oorzaak en gevolg niet meer op één tijdlijn leggen.
3. Assets die pas gaan loggen als er al iets mis is. Foutcodes zijn geen conditiedata. Je wilt weten hoe gezond gedrag eruitziet, niet alleen hoe kapot eruitziet.

Onze ervaring, zonder omwegen: met een half jaar goede data kom je verder dan met een geavanceerd model op vuile data. Begin dus bij de data, niet bij het algoritme.

In de praktijk: tunnels en terminals

Vialis past dit toe op een tunnel in de A4. Sensordata wordt via Cribl gefilterd en verrijkt, en in Splunk geanalyseerd op patronen die op slijtage wijzen; webhooks starten vervolgacties zoals het inplannen van onderhoud. Het effect: hogere tunnelbeschikbaarheid, minder ongeplande sluitingen en onderhoud op werkelijke conditie. Lees de case study Vialis (pdf).

Bij Rotterdam World Gateway (RWG), een van de meest geautomatiseerde containerterminals ter wereld, zat het probleem niet in een gebrek aan data maar aan zichtbaarheid: data lag verspreid over logsystemen, applicaties, leverancierssystemen en OT. Door die stromen in Splunk te correleren ging de start van een probleemanalyse van uren naar minuten en veranderde stilstand van verrassing in beheersing. Lees de case study RWG (pdf).

Een realistisch stappenplan

1. Kies een asset waar uitval echt pijn doet. Niet de makkelijkste, maar de duurste storing van vorig jaar.
2. Inventariseer welke data die asset nu al produceert. Sensoren, besturing, netwerk, onderhoudssysteem, meestal meer dan je denkt.
3. Breng die data samen op één tijdlijn. Zelfde klok, zelfde identifiers. Dit is tachtig procent van het werk.
4. Leg de storingshistorie ernaast en zoek patronen met het blote oog. Wat zag je in de dagen voor elke storing? Vaak springt het patroon eruit zonder code.
5. Automatiseer pas als je het patroon zelf herkent. Een model moet bevestigen wat jij al snapt. Dit advies krijg je van softwareleveranciers niet, en het scheelt je een mislukt project.

Voorspellend onderhoud is geen product dat je koopt, maar een werkwijze die je opbouwt, en die valt of staat met de continuïteit van kritieke systemen eronder. Voor de servicelaag daarboven is ITSI en service-monitoring het gereedschap.

Veelgestelde vragen

• Waarom mislukken predictive maintenance-projecten?
• Heb ik speciale software nodig voor predictive maintenance?
• Wat is voorspellend onderhoud?

AIOps is het toepassen van machine learning en statistische analyse op operationele data: om afwijkingen te vinden, meldingen te correleren en problemen te voorspellen voordat ze uitval worden. Tot zover de definitie die je overal leest. Dit artikel doet iets wat de meeste stukken over AIOps overslaan: het beschrijft ook wat AIOps niet oplost. Die kant hoor je zelden van partijen die het verkopen, en het is precies de kant die bepaalt of jouw investering iets oplevert.

De vier dingen die AIOps daadwerkelijk goed doet

1. Anomaliedetectie op tijdreeksen. Een statische drempel zegt: alarm boven 80 procent. Een model leert dat 70 procent op dinsdagochtend normaal is en op zondagnacht niet, en slaat dus eerder én preciezer aan. In de Splunk-stack is dit het domein van de Machine Learning Toolkit.
2. Correlatie van meldingen naar één incident. Storage-latency, database-timeouts en applicatiefouten zijn geen drie problemen; het is één probleem met drie gezichten. Splunk ITSI groepeert die signalen tot één episode.
3. Ruisreductie. Dezelfde melding die elke vijf minuten terugkomt, wordt één melding met een teller. Klinkt banaal, scheelt in de praktijk het meeste geklik.
4. Capaciteitsvoorspelling. Op basis van trends zie je dat een schijf over drie weken volloopt, in plaats van vannacht om drie uur, dat verplaatst werk van paniek naar planning.

Waar dit in de praktijk zit: de Splunk Machine Learning Toolkit en ITSI voor respectievelijk de modellen en de servicecorrelatie.

De drie dingen die AIOps niet oplost

1. AIOps repareert geen vuile data. Een model op inconsistente logs geeft zelfverzekerde onzin. Ontbrekende velden, dubbele bronnen en klokken die uit elkaar lopen worden niet weggemodelleerd; ze worden versterkt.
2. AIOps vervangt geen engineer. Het model wijst aan waar je moet kijken, niet waarom het misgaat in jouw architectuur, welke workaround uit 2021 nog ergens draait, of welke afhankelijkheid nooit is gedocumenteerd. Het verkort de zoektijd; de diagnose blijft mensenwerk.
3. AIOps lost geen procesprobleem op. Als niemand eigenaar is van een alert, verandert een slimmer alert daar niets aan. Het wordt alleen sneller genegeerd.

Vandaar ons uitgangspunt: niet de hype volgen, maar wat werkt in jouw landschap. Meer alerts zijn zelden het antwoord, waarom dat zo is, lees je in ons artikel over waarom meer alerts niet helpen.

Van chaos naar controle: een voorbeeld

Hoe dit uitpakt als de voorwaarden op orde zijn, beschrijft onze use case over Splunk AI. De uitgangssituatie is herkenbaar: miljoenen signalen per seconde uit IT en OT, meldingen die zich opstapelen, teams die tijd verliezen aan vals alarm. Door logdata samen te brengen in Splunk, machine learning afwijkingen te laten herkennen die met vaste regels onzichtbaar blijven, en verdachte gebeurtenissen automatisch naar het juiste team te routeren, veranderde dat beeld. Het resultaat uit de use case: 75 procent minder valse meldingen, snellere detectie van echte dreigingen en één platform waar IT- en OT-teams samen mee werken. De volledige use case Splunk AI (pdf) lees je in ons downloadcentrum.

Hoe je AIOps stapsgewijs invoert

1. Kies één use case met een duidelijke eigenaar. Niet “alles slimmer maken”, maar bijvoorbeeld: eerder zien dat de orderverwerking hapert.
2. Doe een nulmeting. Aantal meldingen per week, mean time to detect. Zonder nulmeting valt succes niet te bewijzen.
3. Normaliseer de databronnen voor die ene use case. Niet je hele landschap; alleen wat deze detectie nodig heeft.
4. Laat het model meelopen zonder actie. Een paar weken schaduwdraaien laat zien of het model jouw normaal begrijpt.
5. Meet opnieuw en beslis op cijfers. Minder meldingen, snellere detectie? Uitbreiden. Zo niet: stoppen kost nu weinig, precies waarom je klein begon.

AIOps is geen wondermiddel; het is gereedschap dat rendeert zodra je data en je proces het toelaten. Dat zo houden vraagt om proactief beheer in plaats van reactief: iemand die modellen, bronnen en eigenaren scherp houdt.

Leveranciersbeheer: je blijft zelf verantwoordelijk

BIO2 scherpt de eisen aan voor uitbesteding en toezicht op derden, en de eindverantwoordelijkheid blijft waar die was: bij jouw organisatie. Uitbesteden mag dus prima, verantwoording uitbesteden niet.

Praktisch betekent dat: kies een partner die het bewijs levert dat jij nodig hebt voor je verantwoording. Denk aan gecontroleerde, auditable toegang tot je omgeving en vaste rapportages over wat er is gedaan en wat het opleverde. Bij onze Managed Services zijn auditable toegang en transparante rapportage daarom standaard onderdeel van de dienst, geen optie. De actuele versie van de baseline en het ondersteuningsmateriaal vind je op bio-overheid.nl.

Veelgestelde vragen

• Waar begin ik met AIOps?
• Wat heb ik nodig voordat AIOps werkt?
• Vervangt AIOps engineers?
• Wat is AIOps?

De Baseline Informatiebeveiliging Overheid 2 (BIO2) is het basisnormenkader voor informatiebeveiliging binnen alle overheidslagen: Rijk, gemeenten, provincies en waterschappen. Het kader is gebaseerd op ISO 27001 en 27002 en krijgt via de Cyberbeveiligingswet een wettelijke basis. Versie 1.3 is op 5 maart 2026 gepubliceerd in de Staatscourant, en dat is meer dan een administratieve mijlpaal: de ministeriële regeling onder de wet verwijst voor de zorgplicht van de sector Overheid rechtstreeks naar die publicatie. In dit artikel laten we de normteksten voor wat ze zijn en kijken we naar één vraag: wat betekent BIO2 concreet voor je logging, je monitoring en je rapportage?

Wat er verandert ten opzichte van BIO 1.04

Drie wijzigingen springen eruit.

Eén nuance die vrijwel nergens correct wordt opgeschreven: BIO2 v1.3 geldt sinds de publicatie als verplichtende zelfregulering voor het Rijk, provincies en waterschappen. Gemeenten werkten formeel nog met BIO 1.04, met BIO2 als richtinggevend kader, tot de inwerkingtreding van de Cyberbeveiligingswet op 15 augustus 2026. Vanaf dat moment loopt de verplichting voor alle bestuurslagen via de wet en de bijbehorende regeling.

Risicogestuurd werken betekent: je moet je risico kunnen zien

Het schrappen van de BBN-tabel klinkt als een detail, maar het verandert je werk fundamenteel: er valt niets meer af te vinken. Je moet per proces en informatiesysteem bepalen welk risico je loopt, en dat kan alleen met zicht op wat er in die systemen gebeurt. Zonder monitoring geen risicobeeld.

Neem een kritiek burgerproces: het uitbetalen van uitkeringen. Het risico zit zelden in de applicatie alleen, maar in de keten eromheen: de koppeling met de basisregistratie, de batchverwerking die ’s nachts draait, het service-account dat die batch uitvoert. Risicogestuurd werken betekent dat je die keten kunt zien: weet wanneer de batch niet draaide, wanneer het account buiten het venster inlogde, wanneer de koppeling haperde. Dat is geen beleidsvraag meer, dat is monitoring.

Opzet, bestaan en werking aantonen

BIO2 vraagt dat je van maatregelen de opzet, het bestaan en de werking kunt aantonen. Drie woorden, drie artefacten.

• Opzet: beleid en configuratie. Wat heb je bedacht en hoe is het ingericht?
• Bestaan: bewijs dat de maatregel actief is. Niet het beleidsdocument, maar de draaiende regel, de aanleverende logbron.
• Werking: meetgegevens over een langere periode. Deed de maatregel wat hij moest doen, ook in maart, ook in de vakantieperiode?

De derde is de moeilijkste, want werking kun je niet met terugwerkende kracht verzinnen. Je krijgt haar alleen uit continue monitoring en periodieke rapportage die je al die tijd hebt laten lopen. Wie daar pas bij de eerste audit aan begint, is per definitie te laat.

OT valt er ook onder

Een punt dat makkelijk wordt gemist: de BIO2-communicatie van februari 2026 stond volledig in het teken van OT-security, en de Cybersecurity Implementatierichtlijn (CSIR) is binnen de overheid de implementatierichtlijn voor industriële omgevingen. Voor waterschappen met gemalen, voor Rijkswaterstaat, en voor gemeenten met tunnels, bruggen of sluizen betekent dat: de monitoring van industriële systemen valt binnen de scope van je normenkader. Hoe je monitoring in industriële omgevingen inricht zonder je OT-netwerk open te zetten, lees je in ons artikel over het Purdue-model.

Leveranciersbeheer: je blijft zelf verantwoordelijk

BIO2 scherpt de eisen aan voor uitbesteding en toezicht op derden, en de eindverantwoordelijkheid blijft waar die was: bij jouw organisatie. Uitbesteden mag dus prima, verantwoording uitbesteden niet.

Praktisch betekent dat: kies een partner die het bewijs levert dat jij nodig hebt voor je verantwoording. Denk aan gecontroleerde, auditable toegang tot je omgeving en vaste rapportages over wat er is gedaan en wat het opleverde. Bij onze Managed Services zijn auditable toegang en transparante rapportage daarom standaard onderdeel van de dienst, geen optie. De actuele versie van de baseline en het ondersteuningsmateriaal vind je op bio-overheid.nl.

Veelgestelde vragen

• Mag ik onder BIO2 mijn beheer uitbesteden?
• Wat is er veranderd ten opzichte van BIO 1.04?
• Geldt BIO2 al voor gemeenten?
• Wat is BIO2?

Op 15 augustus 2026 treedt de Cyberbeveiligingswet in werking, de Nederlandse implementatie van NIS2. De Eerste Kamer stemde op 7 juli in, geen stip op de horizon meer, maar een datum in je agenda. Dit artikel gaat over één onderdeel: logging en monitoring. Welke bronnen je op orde moet hebben, wat de wet wel en niet zegt over bewaartermijnen, en hoe je aantoont dat het werkt. Of jouw organisatie onder de wet valt, lees je in onze pijlerblog over de Cyber Security Assessment-keten

Wat de wet wel zegt over logging, en wat niet

NIS2 noemt logging in artikel 21 als onderdeel van de zorgplicht: maatregelen om incidenten te detecteren en af te handelen, inclusief registratie van gebeurtenissen. Een bewaartermijn schrijft de wet niet voor: nergens staat zes maanden, nergens twee jaar. Ook het Cyberbeveiligingsbesluit en de ministeriële regelingen per sector geven op dit moment geen vaste termijn voor alle logdata.

Iedere partij die je nu een hard getal belooft, verzint dat getal. Wat de wet wel vraagt: dat je incidenten kunt detecteren, onderzoeken en op tijd melden, en daar kun je je termijnen op bouwen.

Checklist: de negen logbronnen die je op orde moet hebben

1. Authenticatie en autorisatie. Wie logt waar in, en waar mislukt dat opvallend vaak? Dit is de bron waar vrijwel elk onderzoek begint.
2. Netwerkverkeer op de perimeter. Firewall, VPN en proxy laten zien wat er de organisatie in en uit gaat.
3. Endpoint-detectie. EDR-telemetrie van werkplekken en servers, waar de meeste aanvallen zichtbaar worden.
4. Configuratiewijzigingen. Wie zette welke regel uit, en wanneer? Zonder deze bron is elk incidentonderzoek giswerk.
5. Privileged sessies. Beheerdersaccounts en service-accounts kunnen het meest, dus verdienen het meeste zicht.
6. Het cloud control plane. AWS CloudTrail, Azure Activity Log en vergelijkbare audit-logs: wie deed wat met je cloudomgeving zelf.
7. Back-up en restore. Draaide de back-up, en is een restore ooit echt getest? Bij ransomware is dit de bron die telt.
8. OT-assets, indien van toepassing. Industriële systemen vallen ook onder je zorgplicht; beschikbaarheid en afwijkend gedrag zijn daar de signalen.
9. De logging van je logging. De gezondheid van je logpijplijn zelf: welke bron is stilgevallen, waar loopt vertraging op? Vrijwel iedereen vergeet deze, en het is precies de bron waarmee je de andere acht bewaakt.

Hoe je bewaartermijnen bepaalt zonder dat de wet ze geeft

Bepaal de termijn per logbron, op basis van drie vragen: hoe lang duurt het voordat je een incident ontdekt, hoe lang heb je nodig om het te onderzoeken, en wat moet je kunnen melden? De meldplicht is streng: binnen 24 uur moet bij een significant incident een vroegtijdige waarschuwing de deur uit. En een aanvaller die vier maanden onopgemerkt binnen is, is geen uitzondering, bewaar je logs dertig dagen, dan valt er bij ontdekking niets meer te onderzoeken.

Lange termijnen hoeven niet duur te zijn: houd recente data hot (direct doorzoekbaar, prijzig) voor detectie en verhuis oudere data naar cold of archive storage (traag, goedkoop). Een pipeline-laag maakt dat onderscheid praktisch uitvoerbaar; hoe je zo je logvolume beheersbaar houdt, lees je in ons artikel over telemetry pipelines.

Aantoonbaarheid: opzet, bestaan en werking

Een toezichthouder vraagt niet óf je logt, maar of je kunt aantonen dat de maatregel is opgezet, bestaat en werkt. Drie woorden, drie artefacten.

• Opzet: een gedocumenteerde logstrategie. Welke bronnen, waarom, met welke termijn.
• Bestaan: bewijs dat de bronnen daadwerkelijk aanleveren, dus monitoring op de pijplijn zelf.
• Werking: periodieke rapportage die over een langere periode laat zien dat het geheel functioneert: dekking, uitval, opvolging.

Die derde is in de praktijk de lastigste, omdat je haar niet achteraf kunt reconstrueren. Bij SMT is dat daarom standaard onderdeel van elke Managed Service: vaste rapportage met KPI’s, trends en bevindingen, zodat het bewijs er ligt op het moment dat iemand erom vraagt.

Waar organisaties in de praktijk op stuklopen

1. Logbronnen die stilletjes stoppen met aanleveren. Een certificaat verloopt, een agent crasht, en niemand merkt het tot het onderzoek begint.
2. Tijdsynchronisatie die niet klopt. Loopt de klok van je firewall drie minuten voor op die van je servers, dan valt er niets meer te correleren.
3. Logvolume dat het budget opeet. Waarna bronnen worden uitgezet om kosten te drukken. Dat is de gevaarlijkste bezuiniging die er is: je bespaart op precies het zicht dat de wet van je vraagt.
4. Geen eigenaar. Logging is van iedereen een beetje en dus van niemand. Zonder eigenaar verzandt elke goede opzet binnen een jaar.

De derde valkuil is geen natuurwet: wie data filtert voordat die het dure platform bereikt, houdt volume en budget in de hand zonder bronnen op te offeren. De actuele stand van de wet vind je op ncsc.nl.

Veelgestelde vragen

• Val ik onder de Cyberbeveiligingswet?
• Hoe toon ik aan dat mijn logging werkt?
• Welke logbronnen heb ik minimaal nodig?
• Wanneer treedt de Cyberbeveiligingswet in werking?
• Hoe lang moet ik logs bewaren onder NIS2?

Het Purdue-model is een referentiearchitectuur die industriële netwerken opdeelt in gelaagde zones, van de fysieke procesbesturing op de werkvloer tot de bedrijfs-IT op kantoor. Per zone ligt vast welk verkeer erin en eruit mag, zodat een storing of aanval in de ene laag niet zomaar doordringt tot de volgende. Eerlijk is eerlijk: het model stamt uit een tijd waarin OT-netwerken echt gescheiden waren. Die aanname houdt niet meer, terwijl veel organisaties hun monitoring nog inrichten alsof de muren er nog staan.

Hieronder eerst het model, daarna waar het in de praktijk om draait: monitoringdata uit je OT-omgeving halen zonder die omgeving open te zetten.

Het Purdue-model in vijf niveaus

Het model telt zes lagen, van 0 tot en met 5. Hoe lager het niveau, hoe dichter op het fysieke proces en hoe zwaarder beschikbaarheid weegt.

Tussen niveau 3 en 4 zit in de praktijk nog niveau 3.5: de industriële DMZ, de plek waar IT en OT elkaar gecontroleerd raken, en waar je monitoringvraagstuk zich afspeelt.

Waarom de scheiding tussen IT en OT verdwijnt

Drie ontwikkelingen slopen de klassieke scheiding.

1. Cloudconnectiviteit voor remote support. Leveranciers kijken op afstand mee voor onderhoud en storingsanalyse, en elke supportverbinding is een pad dat het model nooit voorzien heeft.
2. Industriële IoT. Nieuwe sensoren praten rechtstreeks met een cloudplatform en slaan de lagen simpelweg over.
3. De vraag naar OT-data voor bedrijfsbeslissingen. Onderhoudsplanning, energieverbruik, beschikbaarheid: de antwoorden zitten in OT-data, maar de vragen worden op IT-niveau gesteld.

Dat dit geen nicheonderwerp meer is, zie je bij de overheid: de BIO2-communicatie van februari 2026 stond volledig in het teken van OT-security, en de Cybersecurity Implementatierichtlijn (CSIR) geldt daar als dé OT-norm. Wat dat betekent lees je in wat BIO2 vraagt van OT-omgevingen.

Data uit OT halen zonder je OT-netwerk te openen

Hier zit de technische kern: monitoringdata de ene kant op, zonder dat er ooit een verbinding de andere kant op gaat. Drie patronen, goed te combineren.

1. Unidirectionele gateways of datadiodes. Hardware die verkeer fysiek maar één richting op laat: data verlaat de OT-zone, niets kan terug. In omgevingen met hoge veiligheidseisen vaak het uitgangspunt.
2. Een collector in de DMZ (niveau 3.5). OT-systemen leveren hun data af bij een collector in de tussenlaag; de IT-zone haalt de data daar op. Een directe verbinding tussen beide werelden bestaat niet.
3. Een pipeline-laag die filtert, normaliseert en maskeert. Voordat data de IT-zone bereikt, bepaal je wat er doorheen mag en zonder welke gevoelige velden. Een lichte agent zoals Cribl Edge doet dat werk al dicht bij de bron; meer daarover op onze pagina over data filteren en routeren aan de bron.

Wat je wel en niet meet in een OT-omgeving

In OT gedraagt data zich precies omgekeerd aan IT: een laag volume en een hoge criticaliteit per gebeurtenis, waar IT-logs een hoog volume en een lage criticaliteit hebben. Eén afwijkende melding kan een pomp zijn die het begeeft.

Wel meten: asset-inventaris, protocolafwijkingen in bijvoorbeeld Modbus- of DNP3-verkeer, beschikbaarheid van kritieke assets en firmware-versies.

Niet meten: alles wat een IT-SIEM standaard binnenharkt. Detectieregels die in IT prima werken, produceren in OT vrijwel alleen ruis. Detectie bouw je hier op gedrag en afwijking, niet op volume.

In de praktijk: van tunnelbeheer naar voorspelbare beschikbaarheid

Vialis past dit toe op een tunnel in de A4, onder een start- en landingsbaan van een internationale luchthaven. Bestaande sensordata wordt via Cribl gefilterd en verrijkt, en in Splunk geanalyseerd op patronen die op slijtage wijzen: verhoogd stroomverbruik bij een pomp, oplopende temperaturen, afwijkend ventilatiegedrag. Webhooks starten vervolgacties, zoals het inplannen van onderhoud. Het resultaat is in de operatie duidelijk merkbaar: hogere tunnelbeschikbaarheid, minder ongeplande sluitingen en onderhoud op werkelijke conditie. Lees de volledige case study Vialis (pdf). Hoe je van meten naar onderhoudsbeslissingen komt, lees je in van preventief naar voorspelbaar onderhoud.

Het Purdue-model is niet dood; het is een denkmodel geworden in plaats van een bouwtekening. De grens verschuift naar de vraag welke data haar mag passeren, en wie dat heeft ingericht, wil het zo houden. Dat is het punt waarop het beheer van je monitoringplatform net zo belangrijk wordt als de architectuur zelf.

Veelgestelde vragen

• Wat is het verschil tussen OT-monitoring en IT-monitoring?
• Kun je OT-data monitoren zonder je OT-netwerk te openen?
• Is het Purdue-model nog relevant?

• Wat is het Purdue-model?

  Het Purdue-model is een referentiearchitectuur die industriële netwerken opdeelt in zones, van fysieke procesbesturing op niveau 0 tot bedrijfs-IT op niveau 4 en 5, zodat duidelijk is welk verkeer tussen welke zones is toegestaan.

Alert fatigue is de afstomping die ontstaat wanneer analisten zoveel meldingen krijgen dat ze echte signalen missen. Wie tweehonderd keer per dienst op “close” klikt, klikt op een dag ook de melding weg die ertoe deed. De stelling die dit artikel draagt: alert fatigue is zelden een mensenprobleem en bijna altijd een datakwaliteitsprobleem.

Waar de ruis vandaan komt

1. Regels uit een standaardpakket, nooit aangepast aan de eigen omgeving. De content-packs van je SIEM zijn geschreven voor een gemiddelde organisatie die niet bestaat. Een regel die elders scherp is, loeit bij jou de hele dag.
2. Ontbrekende context. Een beheerder die om 02:00 uur inlogt: verdacht, tenzij het de geplande patchronde is. Zonder wijzigingskalender en asseteigenaar in de melding ziet de analist dat verschil niet, dus onderzoekt hij het. Elke keer weer.
3. Dubbele detecties op verschillende lagen. EDR, firewall en SIEM melden hetzelfde event, elk in eigen bewoording. Eén gebeurtenis, drie tickets.
4. Regels die niemand meer durft uit te zetten. Niemand weet waarom ze bestaan, dus laat iedereen ze staan. Voor de zekerheid. De eerlijkste oorzaak op dit lijstje, en de meest voorkomende.

Wat is detection engineering?

Detection engineering is het behandelen van detectieregels als een product met een levenscyclus, niet als een project dat ooit af is. Elke regel heeft een eigenaar, een doel en een houdbaarheidsdatum. Vijf fasen:

1. Ontwerpen. Welke techniek of welk risico wil je zien, en welke data heb je daarvoor nodig? Eigenaar: de detection engineer.
2. Bouwen. De regel schrijven, met context (assetwaarde, eigenaar) er meteen bij.
3. Testen. Tegen historische data en gesimuleerde aanvallen, voordat de regel live gaat. Eigenaar: engineer plus analist.
4. Afstemmen. De false positive ratio per regel volgen en bijsturen. Eigenaar: de analisten die de meldingen zien; doorlopend, met een vast maandelijks moment.
5. Uitfaseren. Regels die niets meer opleveren gedocumenteerd uitzetten, elk kwartaal. Vrijwel niemand doet deze fase, en het is precies de fase die oorzaak vier hierboven voorkomt.

Meten voordat je tunet

Vier meetwaarden volstaan om te weten waar je staat:

• Meldingen per analist per dienst. De directe maat voor werkdruk.
• False positive ratio per regel. Niet per omgeving, maar per regel, anders weet je nooit welke regel het probleem is.
• Mean time to triage. Hoe lang duurt het voordat iemand een melding heeft beoordeeld?
• Aandeel meldingen dat tot actie leidt. De hardste maat voor signaalwaarde.

Zonder nulmeting kun je na drie maanden tunen niet aantonen dat het hielp, en dan verdwijnt het budget. Streefcijfers geven we bewust niet: die verschillen per omgeving, en wie je er toch een noemt, kent jouw omgeving niet.

Vier maatregelen die het volume echt verlagen

1. Verrijk meldingen met context voordat ze bij een analist landen. Assetwaarde, eigenaar, wijzigingsvenster. De melding “inlog op srv-db-03 (kroonjuweel, eigenaar team Betalingen, geen gepland werk)” triageert zichzelf half.
2. Onderdruk meldingen tijdens geplande wijzigingen. Een patchnacht met vierhonderd meldingen leert analisten precies één ding: negeren.
3. Groepeer verwante meldingen tot één incident. Tien signalen van één aanvalspad horen in één dossier, niet in tien tickets. Waar AI wel en niet helpt bij ruisreductie, lees je in ons artikel over AIOps.
4. Verwijder data zonder detectiewaarde voordat die je SIEM in gaat. Debug-logging en heartbeats voeden geen enkele detectie, maar vervuilen wel elke zoekopdracht. Hoe je data filtert voordat die je SIEM in gaat, lees je in ons artikel over telemetry pipelines.

Een dashboard per component vertelt je hoe de database en de applicatieserver zich voelen, maar niet of de dienst het doet. Groene lampjes en toch klachten, iedereen in operations kent dat gesprek. Service-gebaseerde monitoring draait het om: je koppelt technische signalen aan een bedrijfsproces, zoals “bestelling plaatsen” of “brug bedienen”, en bewaakt dat. In de Splunk-wereld is dit het domein van Splunk Observability Cloud en ITSI.

Dekking meten met MITRE ATT&CK

Als de ruis afneemt, komt de volgende vraag: zien we wel de juiste dingen? Het MITRE ATT&CK-framework beschrijft de technieken die aanvallers daadwerkelijk gebruiken. Koppel je detecties daaraan, en het gesprek verandert van “hoeveel regels hebben we” in “welke technieken zien we, en welke niet”, het enige gesprek dat je risico verkleint.

Eén waarschuwing: dekking najagen om de dekking is de nieuwe valkuil. Dek de technieken die voor jouw omgeving en dreigingsbeeld tellen, en dek die goed.

Detection engineering vraagt om ritme: elke dag kijken, elke maand afstemmen, elk kwartaal opruimen. Dat ritme organiseren wij met 24/7 checks door een team in plaats van een persoon. Speelt de vraag of je dit zelf wilt doen, lees dan ons artikel over welk servicemodel bij je past.

Veelgestelde vragen

• Wat meet ik om te weten of tuning werkt?
• Hoe verlaag ik het aantal false positives?
• Wat is detection engineering?
• Wat is alert fatigue?

Monitoring meet vooraf bepaalde signalen en waarschuwt als een drempelwaarde wordt overschreden. Observability is het vermogen om de toestand van een systeem te begrijpen op basis van de data die het uitzendt, ook bij problemen die je niet had voorzien. Anders gezegd: monitoring vertelt je dát er iets mis is, observability helpt je begrijpen waaróm. De twee termen worden voortdurend door elkaar gebruikt, en dat kost organisaties geld: wie observability koopt voor een monitoringprobleem betaalt te veel, en wie monitoring inzet voor een observabilityprobleem blijft zoeken.

Het verschil in een tabel

De kern zit in die tweede rij. Monitoring bewaakt wat je vooraf kon bedenken. Observability geeft je de mogelijkheid om vragen te stellen die je pas bedenkt op het moment dat het misgaat.

The three pillars of observability: logs, metrics en traces

Logs vertellen wat er gebeurde: een foutmelding met stacktrace, een geweigerde inlogpoging, een time-out met de exacte parameters erbij. Ze zijn rijk aan detail, maar duur in volume.

Metrics vertellen hoeveel en hoe vaak: responstijden, foutpercentages, wachtrijlengtes. Compact, goedkoop, ideaal voor trends en alerts, maar zonder het verhaal erachter.

Traces vertellen waar in de keten het gebeurde: het pad van één verzoek langs alle services, met per stap de tijd die het kostte. Onmisbaar zodra één klik door tien systemen gaat.

En dan het eerlijke voorbehoud: de drie pijlers zijn een nuttig model, geen doel. Veel organisaties verzamelen keurig alle drie, in drie losse tools, zonder ze ooit te correleren. Dan heb je drie keer opslagkosten en nul keer inzicht. De waarde ontstaat pas als je vanuit een metric-piek kunt doorklikken naar de bijbehorende trace en logs.

Wanneer monitoring genoeg is

Nu de vraag die leveranciers liever overslaan: heb je observability nodig? Voor een stabiele, monolithische omgeving met bekende faalmodi is klassieke monitoring goedkoper en effectiever. Drie criteria om te beslissen:

1. Architectuur. Draait alles op een handvol servers, of is je landschap gedistribueerd over tientallen services en cloudcomponenten?
2. Vraagpatroon. Stel je bij incidenten steeds dezelfde vragen, of steeds nieuwe? Zodra elke storing een unieke puzzel is, schiet vooraf bedachte monitoring tekort.
3. Veranderingstempo. Wie wekelijks deployt, creëert wekelijks nieuwe manieren om te falen. Hoe sneller je omgeving verandert, hoe minder je vooraf kunt bedenken.

Scoor je op alle drie laag, houd het dan simpel en investeer je budget ergens anders in. Dat advies levert ons niets op, maar het klopt wel.

Van dashboards naar service-inzicht

Een dashboard per component vertelt je hoe de database en de applicatieserver zich voelen, maar niet of de dienst het doet. Groene lampjes en toch klachten, iedereen in operations kent dat gesprek. Service-gebaseerde monitoring draait het om: je koppelt technische signalen aan een bedrijfsproces, zoals “bestelling plaatsen” of “brug bedienen”, en bewaakt dat. In de Splunk-wereld is dit het domein van Splunk Observability Cloud en ITSI.

Wat je nodig hebt om te beginnen

1. Inventariseer welke data je al uitzendt. Applicaties, infrastructuur, cloudplatformen: het meeste is er al.
2. Zorg voor consistente tijdstempels en identifiers over bronnen heen. Zonder gedeelde sleutels valt er niets te correleren; hoe je consistente data over bronnen heen aan de bron regelt, lees je in ons artikel over telemetry pipelines.
3. Definieer wat een dienst is en welke componenten eronder vallen. Dit is een gesprek met de business, geen technische exercitie.
4. Begin met één dienst. Bewijs de waarde daar, en breid daarna pas uit.

Staat deze basis, kijk dan verder naar wat AI hieraan toevoegt. En wie het platform liever niet zelf scherp houdt: het beheer en de optimalisatie van je platform is precies wat wij als Managed Service doen.

Veelgestelde vragen

• Is observability hetzelfde als een SIEM?

  Nee. Observability richt zich op de gezondheid en prestaties van diensten, een SIEM op detectie van beveiligingsincidenten. Ze delen vaak dezelfde databronnen, maar beantwoorden andere vragen.

• Wanneer is monitoring genoeg?
• Wat zijn de three pillars of observability?

  Logs (wat er gebeurde), metrics (hoeveel en hoe vaak) en traces (waar in de keten). Het is een nuttig model, geen doel. Veel organisaties verzamelen alle drie zonder ze te correleren, en daar gaat het mis.

• Wat is het verschil tussen observability en monitoring?

  Monitoring meet vooraf bepaalde signalen en waarschuwt bij overschrijding van een drempelwaarde. Observability is het vermogen om de toestand van een systeem te begrijpen uit de data die het uitzendt, ook bij problemen die je niet had voorzien.

Een Splunk-architectuur is een verzameling gespecialiseerde componenten die data ontvangen, indexeren, doorzoeken en beheren, waarbij clustering zorgt voor beschikbaarheid en schaalbaarheid. Wie de rolverdeling en de twee clustervormen begrijpt, weet waar zijn eigen omgeving kwetsbaar is. Dit stuk is voor Splunk-engineers en -admins, we sparen het jargon niet.

De componenten op een rij

De Splunk-documentatie vertelt wat elk component doet, niet wat er gebeurt als het uitvalt. En juist met die kolom beoordeel je je architectuur.

Indexer clustering: replication factor en search factor

Twee getallen bepalen het gedrag van je indexer cluster: de replication factor (RF) bepaalt hoeveel kopieën van de ruwe data het cluster bewaart, de search factor (SF) hoeveel daarvan ook doorzoekbaar zijn, inclusief tsidx-indexbestanden.

Concreet, met RF3 en SF2: elke bucket bestaat drie keer als ruwe data, waarvan twee direct doorzoekbaar. Valt één indexer uit, dan is er geen dataverlies en blijft zoeken mogelijk, terwijl de cluster manager via fixup de aantallen herstelt. Opslag: drie keer de gecomprimeerde ruwe data plus twee keer de indexbestanden.

De klassieke fout: SF gelijkstellen aan RF “omdat het veiliger klinkt”. Dat levert zelden extra weerbaarheid op, maar wel een extra complete set tsidx-bestanden, je opslagverbruik schiet omhoog zonder dat je er iets voor terugkrijgt. Verhoog SF alleen met een concreet herstelscenario waarin die extra doorzoekbare kopie het verschil maakt.

Search head clustering en captain election

Een search head cluster kiest uit zijn leden een captain: die verdeelt scheduled searches, coördineert de replicatie van knowledge objects (dashboards, saved searches, lookups) en bewaakt de clusterstaat. Valt de captain weg, dan kiezen de overgebleven leden een nieuwe, mits ze met een meerderheid zijn.

Dat meerderheidsvereiste verklaart twee vuistregels. Drie search heads is het minimum, want bij twee is elke uitval meteen het einde van de meerderheid. En een even aantal is een slecht idee: splitst een netwerkpartitie een cluster van vier in tweeën, dan heeft geen van beide helften een meerderheid en liggen scheduled searches en replicatie stil terwijl alle machines gewoon aanstaan.

Vijf fouten die we het vaakst tegenkomen

Met meer dan 500 implementaties achter de rug zien we dezelfde fouten terugkomen. De vijf hardnekkigste:

1. 1. Search factor gelijk aan replication factor, zonder reden. Zie hierboven: veel opslag, weinig winst.
   2. Een monitoring console die zelf niet gemonitord wordt. Het systeem dat alles bewaakt, wordt door niets bewaakt. Valt het stil, dan merkt per definitie niemand dat.
   3. Knowledge objects lokaal op één search head in plaats van in het cluster. Alles werkt, tot die ene search head uitvalt en de dashboards van een heel team nergens anders blijken te bestaan.
   4. Forwarders die zonder load balancing naar één vaste indexer praten. Eén indexer eruit betekent meteen datagaten, en de load in het cluster is structureel scheef.
   5. Een deployment server die te veel clients bedient. Duizenden forwarders op één onderbemeten machine: configuratie-updates druppelen dagenlang binnen, of komen nooit aan.

Wat je periodiek zou moeten controleren

Wil je dit één keer grondig laten doorlichten, dan is de Splunk Health Check de kortste route. Structureler kan ook: Splunk-beheer uitbesteden betekent dat deze controles elke dag gebeuren, door een team in plaats van die ene collega. Hoe je daarna van dashboards naar service-inzicht komt, en waarom omgevingen hun heavy forwarders vervangen door een pipeline-laag, lees je in de vervolgblogs. Twijfel je tussen platformen, lees dan welk platform bij je past.

Veelgestelde vragen

• Wat controleer je periodiek in een Splunk-omgeving?
• Hoeveel search heads heb ik minimaal nodig voor een cluster?
• Hoe zorgen we ervoor dat een investering in Splunk rendabel blijft naarmate onze data groeit?
• We gebruiken al meerdere monitoring- en securitytools. Wat voegt Splunk dan nog toe?
• Hoe helpt Splunk ons om sneller inzicht te krijgen in problemen voordat ze impact hebben op de business?

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

1. 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.
2. Verrijken. Voeg context toe terwijl de data onderweg is: assetwaarde, eigenaar, omgeving. Een verrijkte melding hoeft een analist niet meer op te zoeken.
3. Routeren. Stuur elke stroom naar de goedkoopste bestemming die nog voldoet: detectiewaardige data naar het SIEM, compliance-data rechtstreeks naar goedkope object storage.
4. 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

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

1. Meet je huidige volume per bron. Niet het totaal, maar per bron, daar zitten de verrassingen.
2. Bepaal per bron de detectie- en compliancewaarde. Welke detecties draaien erop, welke bewaarplicht geldt? Data zonder antwoord op beide vragen is je eerste kandidaat.
3. 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.
4. Verleg één bron en vergelijk. Zelfde detecties, zelfde dashboards, minder volume? Dan werkt het aantoonbaar.
5. 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.

Veelgestelde vragen

• Hoeveel logvolume kan ik besparen met een pipeline?

  Dat verschilt per omgeving en vooral per bron. Ter indicatie uit de praktijk: bij PostNL daalde het ingest-volume van AWS CloudTrail met 40 procent, waar vooraf 30 procent was verwacht.

• Wat is het verschil tussen Cribl Stream en Cribl Edge?

  Stream is de centrale verwerkingslaag, Edge een lichte agent die dicht bij de bron draait. Edge is relevant voor OT-omgevingen en verre locaties waar je bandbreedte wilt sparen of data niet ongefilterd wilt versturen.

• Wat doet Cribl Stream precies?

  Cribl Stream verwerkt datastromen centraal: het filtert wat geen waarde heeft, verrijkt met context, routeert naar de juiste bestemming en maskeert gevoelige velden. Zo verlaag je volume en kosten zonder detectiedekking op te geven.

• Wat is een telemetry pipeline?

  Een telemetry pipeline is een tussenlaag tussen je databronnen en je analyse- of securityplatformen die bepaalt wat waarheen gaat: filteren, verrijken, routeren en maskeren, voordat de data zijn bestemming bereikt.

Voorspellend onderhoud betekent onderhoud plannen op basis van de werkelijke conditie en het gedrag van een asset, in plaats van op een vaste kalender. Internationaal heet het predictive maintenance, en het steunt op data die de asset en de systemen eromheen vaak al produceren. Daarmee is meteen gezegd wat dit artikel anders maakt dan de meeste stukken over dit onderwerp: het gaat niet over een onderhoudspakket aanschaffen, maar over de data die je al hebt en wat daarvoor nodig is.

Drie vormen van onderhoud, en wat ze kosten

En nu het eerlijke verhaal: voor veel assets is preventief onderhoud gewoon prima. Een vast interval voor iets goedkoops dat zelden faalt, hoef je niet slimmer te maken. Voorspellend onderhoud loont bij assets waar uitval duur of gevaarlijk is: de tunnel, de terminal, het gemaal.

Welke data je nodig hebt (en waarschijnlijk al hebt)

Vier bronnen vormen samen het beeld.

1. Sensordata uit de asset zelf. Stroomverbruik, temperatuur, trilling, druk: de signalen die slijtage verraden.
2. Logdata uit de besturingssystemen. PLC’s en SCADA registreren schakelmomenten, foutcodes en afwijkingen die je in sensordata alleen niet ziet.
3. Netwerktelemetrie. Een installatie die hapert, kondigt zich op het netwerk vaak eerder aan dan in het proces.
4. De storingshistorie uit je onderhoudssysteem. Wat ging er eerder kapot, wanneer, en wat ging eraan vooraf? Dit is je referentiemateriaal.

De eerste drie komen meestal al ergens langs, alleen in verschillende systemen met verschillende tijdstempels. Het werk zit niet in het voorspellen, maar in het samenbrengen, en in de vraag hoe je die data veilig uit je OT-omgeving haalt.

Waarom predictive maintenance zelden op het model stukloopt

De meeste voorspellend-onderhoudsprojecten stranden niet op het algoritme. Ze stranden op datakwaliteit, en wel op drie voorspelbare manieren.

1. Te weinig storingshistorie om op te trainen. Kritieke assets falen gelukkig zelden, dus zijn er weinig voorbeelden van hoe falen eruitziet.
2. Tijdstempels die niet synchroon lopen. Als de sensor, de PLC en het onderhoudssysteem elk hun eigen klok hanteren, kun je oorzaak en gevolg niet meer op één tijdlijn leggen.
3. Assets die pas gaan loggen als er al iets mis is. Foutcodes zijn geen conditiedata. Je wilt weten hoe gezond gedrag eruitziet, niet alleen hoe kapot eruitziet.

Onze ervaring, zonder omwegen: met een half jaar goede data kom je verder dan met een geavanceerd model op vuile data. Begin dus bij de data, niet bij het algoritme.

In de praktijk: tunnels en terminals

Vialis past dit toe op een tunnel in de A4. Sensordata wordt via Cribl gefilterd en verrijkt, en in Splunk geanalyseerd op patronen die op slijtage wijzen; webhooks starten vervolgacties zoals het inplannen van onderhoud. Het effect: hogere tunnelbeschikbaarheid, minder ongeplande sluitingen en onderhoud op werkelijke conditie. Lees de case study Vialis (pdf).

Bij Rotterdam World Gateway (RWG), een van de meest geautomatiseerde containerterminals ter wereld, zat het probleem niet in een gebrek aan data maar aan zichtbaarheid: data lag verspreid over logsystemen, applicaties, leverancierssystemen en OT. Door die stromen in Splunk te correleren ging de start van een probleemanalyse van uren naar minuten en veranderde stilstand van verrassing in beheersing. Lees de case study RWG (pdf).

Een realistisch stappenplan

1. Kies een asset waar uitval echt pijn doet. Niet de makkelijkste, maar de duurste storing van vorig jaar.
2. Inventariseer welke data die asset nu al produceert. Sensoren, besturing, netwerk, onderhoudssysteem, meestal meer dan je denkt.
3. Breng die data samen op één tijdlijn. Zelfde klok, zelfde identifiers. Dit is tachtig procent van het werk.
4. Leg de storingshistorie ernaast en zoek patronen met het blote oog. Wat zag je in de dagen voor elke storing? Vaak springt het patroon eruit zonder code.
5. Automatiseer pas als je het patroon zelf herkent. Een model moet bevestigen wat jij al snapt. Dit advies krijg je van softwareleveranciers niet, en het scheelt je een mislukt project.

Voorspellend onderhoud is geen product dat je koopt, maar een werkwijze die je opbouwt, en die valt of staat met de continuïteit van kritieke systemen eronder. Voor de servicelaag daarboven is ITSI en service-monitoring het gereedschap.

Veelgestelde vragen

• Waarom mislukken predictive maintenance-projecten?
• Heb ik speciale software nodig voor predictive maintenance?
• Wat is voorspellend onderhoud?

AIOps is het toepassen van machine learning en statistische analyse op operationele data: om afwijkingen te vinden, meldingen te correleren en problemen te voorspellen voordat ze uitval worden. Tot zover de definitie die je overal leest. Dit artikel doet iets wat de meeste stukken over AIOps overslaan: het beschrijft ook wat AIOps niet oplost. Die kant hoor je zelden van partijen die het verkopen, en het is precies de kant die bepaalt of jouw investering iets oplevert.

De vier dingen die AIOps daadwerkelijk goed doet

1. Anomaliedetectie op tijdreeksen. Een statische drempel zegt: alarm boven 80 procent. Een model leert dat 70 procent op dinsdagochtend normaal is en op zondagnacht niet, en slaat dus eerder én preciezer aan. In de Splunk-stack is dit het domein van de Machine Learning Toolkit.
2. Correlatie van meldingen naar één incident. Storage-latency, database-timeouts en applicatiefouten zijn geen drie problemen; het is één probleem met drie gezichten. Splunk ITSI groepeert die signalen tot één episode.
3. Ruisreductie. Dezelfde melding die elke vijf minuten terugkomt, wordt één melding met een teller. Klinkt banaal, scheelt in de praktijk het meeste geklik.
4. Capaciteitsvoorspelling. Op basis van trends zie je dat een schijf over drie weken volloopt, in plaats van vannacht om drie uur, dat verplaatst werk van paniek naar planning.

Waar dit in de praktijk zit: de Splunk Machine Learning Toolkit en ITSI voor respectievelijk de modellen en de servicecorrelatie.

De drie dingen die AIOps niet oplost

1. AIOps repareert geen vuile data. Een model op inconsistente logs geeft zelfverzekerde onzin. Ontbrekende velden, dubbele bronnen en klokken die uit elkaar lopen worden niet weggemodelleerd; ze worden versterkt.
2. AIOps vervangt geen engineer. Het model wijst aan waar je moet kijken, niet waarom het misgaat in jouw architectuur, welke workaround uit 2021 nog ergens draait, of welke afhankelijkheid nooit is gedocumenteerd. Het verkort de zoektijd; de diagnose blijft mensenwerk.
3. AIOps lost geen procesprobleem op. Als niemand eigenaar is van een alert, verandert een slimmer alert daar niets aan. Het wordt alleen sneller genegeerd.

Vandaar ons uitgangspunt: niet de hype volgen, maar wat werkt in jouw landschap. Meer alerts zijn zelden het antwoord, waarom dat zo is, lees je in ons artikel over waarom meer alerts niet helpen.

Van chaos naar controle: een voorbeeld

Hoe dit uitpakt als de voorwaarden op orde zijn, beschrijft onze use case over Splunk AI. De uitgangssituatie is herkenbaar: miljoenen signalen per seconde uit IT en OT, meldingen die zich opstapelen, teams die tijd verliezen aan vals alarm. Door logdata samen te brengen in Splunk, machine learning afwijkingen te laten herkennen die met vaste regels onzichtbaar blijven, en verdachte gebeurtenissen automatisch naar het juiste team te routeren, veranderde dat beeld. Het resultaat uit de use case: 75 procent minder valse meldingen, snellere detectie van echte dreigingen en één platform waar IT- en OT-teams samen mee werken. De volledige use case Splunk AI (pdf) lees je in ons downloadcentrum.

Hoe je AIOps stapsgewijs invoert

1. Kies één use case met een duidelijke eigenaar. Niet “alles slimmer maken”, maar bijvoorbeeld: eerder zien dat de orderverwerking hapert.
2. Doe een nulmeting. Aantal meldingen per week, mean time to detect. Zonder nulmeting valt succes niet te bewijzen.
3. Normaliseer de databronnen voor die ene use case. Niet je hele landschap; alleen wat deze detectie nodig heeft.
4. Laat het model meelopen zonder actie. Een paar weken schaduwdraaien laat zien of het model jouw normaal begrijpt.
5. Meet opnieuw en beslis op cijfers. Minder meldingen, snellere detectie? Uitbreiden. Zo niet: stoppen kost nu weinig, precies waarom je klein begon.

AIOps is geen wondermiddel; het is gereedschap dat rendeert zodra je data en je proces het toelaten. Dat zo houden vraagt om proactief beheer in plaats van reactief: iemand die modellen, bronnen en eigenaren scherp houdt.

Leveranciersbeheer: je blijft zelf verantwoordelijk

BIO2 scherpt de eisen aan voor uitbesteding en toezicht op derden, en de eindverantwoordelijkheid blijft waar die was: bij jouw organisatie. Uitbesteden mag dus prima, verantwoording uitbesteden niet.

Praktisch betekent dat: kies een partner die het bewijs levert dat jij nodig hebt voor je verantwoording. Denk aan gecontroleerde, auditable toegang tot je omgeving en vaste rapportages over wat er is gedaan en wat het opleverde. Bij onze Managed Services zijn auditable toegang en transparante rapportage daarom standaard onderdeel van de dienst, geen optie. De actuele versie van de baseline en het ondersteuningsmateriaal vind je op bio-overheid.nl.

Veelgestelde vragen

• Waar begin ik met AIOps?
• Wat heb ik nodig voordat AIOps werkt?
• Vervangt AIOps engineers?
• Wat is AIOps?

De Baseline Informatiebeveiliging Overheid 2 (BIO2) is het basisnormenkader voor informatiebeveiliging binnen alle overheidslagen: Rijk, gemeenten, provincies en waterschappen. Het kader is gebaseerd op ISO 27001 en 27002 en krijgt via de Cyberbeveiligingswet een wettelijke basis. Versie 1.3 is op 5 maart 2026 gepubliceerd in de Staatscourant, en dat is meer dan een administratieve mijlpaal: de ministeriële regeling onder de wet verwijst voor de zorgplicht van de sector Overheid rechtstreeks naar die publicatie. In dit artikel laten we de normteksten voor wat ze zijn en kijken we naar één vraag: wat betekent BIO2 concreet voor je logging, je monitoring en je rapportage?

Wat er verandert ten opzichte van BIO 1.04

Drie wijzigingen springen eruit.

Eén nuance die vrijwel nergens correct wordt opgeschreven: BIO2 v1.3 geldt sinds de publicatie als verplichtende zelfregulering voor het Rijk, provincies en waterschappen. Gemeenten werkten formeel nog met BIO 1.04, met BIO2 als richtinggevend kader, tot de inwerkingtreding van de Cyberbeveiligingswet op 15 augustus 2026. Vanaf dat moment loopt de verplichting voor alle bestuurslagen via de wet en de bijbehorende regeling.

Risicogestuurd werken betekent: je moet je risico kunnen zien

Het schrappen van de BBN-tabel klinkt als een detail, maar het verandert je werk fundamenteel: er valt niets meer af te vinken. Je moet per proces en informatiesysteem bepalen welk risico je loopt, en dat kan alleen met zicht op wat er in die systemen gebeurt. Zonder monitoring geen risicobeeld.

Neem een kritiek burgerproces: het uitbetalen van uitkeringen. Het risico zit zelden in de applicatie alleen, maar in de keten eromheen: de koppeling met de basisregistratie, de batchverwerking die ’s nachts draait, het service-account dat die batch uitvoert. Risicogestuurd werken betekent dat je die keten kunt zien: weet wanneer de batch niet draaide, wanneer het account buiten het venster inlogde, wanneer de koppeling haperde. Dat is geen beleidsvraag meer, dat is monitoring.

Opzet, bestaan en werking aantonen

BIO2 vraagt dat je van maatregelen de opzet, het bestaan en de werking kunt aantonen. Drie woorden, drie artefacten.

• Opzet: beleid en configuratie. Wat heb je bedacht en hoe is het ingericht?
• Bestaan: bewijs dat de maatregel actief is. Niet het beleidsdocument, maar de draaiende regel, de aanleverende logbron.
• Werking: meetgegevens over een langere periode. Deed de maatregel wat hij moest doen, ook in maart, ook in de vakantieperiode?

De derde is de moeilijkste, want werking kun je niet met terugwerkende kracht verzinnen. Je krijgt haar alleen uit continue monitoring en periodieke rapportage die je al die tijd hebt laten lopen. Wie daar pas bij de eerste audit aan begint, is per definitie te laat.

OT valt er ook onder

Een punt dat makkelijk wordt gemist: de BIO2-communicatie van februari 2026 stond volledig in het teken van OT-security, en de Cybersecurity Implementatierichtlijn (CSIR) is binnen de overheid de implementatierichtlijn voor industriële omgevingen. Voor waterschappen met gemalen, voor Rijkswaterstaat, en voor gemeenten met tunnels, bruggen of sluizen betekent dat: de monitoring van industriële systemen valt binnen de scope van je normenkader. Hoe je monitoring in industriële omgevingen inricht zonder je OT-netwerk open te zetten, lees je in ons artikel over het Purdue-model.

Leveranciersbeheer: je blijft zelf verantwoordelijk

BIO2 scherpt de eisen aan voor uitbesteding en toezicht op derden, en de eindverantwoordelijkheid blijft waar die was: bij jouw organisatie. Uitbesteden mag dus prima, verantwoording uitbesteden niet.

Praktisch betekent dat: kies een partner die het bewijs levert dat jij nodig hebt voor je verantwoording. Denk aan gecontroleerde, auditable toegang tot je omgeving en vaste rapportages over wat er is gedaan en wat het opleverde. Bij onze Managed Services zijn auditable toegang en transparante rapportage daarom standaard onderdeel van de dienst, geen optie. De actuele versie van de baseline en het ondersteuningsmateriaal vind je op bio-overheid.nl.

Veelgestelde vragen

• Mag ik onder BIO2 mijn beheer uitbesteden?
• Wat is er veranderd ten opzichte van BIO 1.04?
• Geldt BIO2 al voor gemeenten?
• Wat is BIO2?

Op 15 augustus 2026 treedt de Cyberbeveiligingswet in werking, de Nederlandse implementatie van NIS2. De Eerste Kamer stemde op 7 juli in, geen stip op de horizon meer, maar een datum in je agenda. Dit artikel gaat over één onderdeel: logging en monitoring. Welke bronnen je op orde moet hebben, wat de wet wel en niet zegt over bewaartermijnen, en hoe je aantoont dat het werkt. Of jouw organisatie onder de wet valt, lees je in onze pijlerblog over de Cyber Security Assessment-keten

Wat de wet wel zegt over logging, en wat niet

NIS2 noemt logging in artikel 21 als onderdeel van de zorgplicht: maatregelen om incidenten te detecteren en af te handelen, inclusief registratie van gebeurtenissen. Een bewaartermijn schrijft de wet niet voor: nergens staat zes maanden, nergens twee jaar. Ook het Cyberbeveiligingsbesluit en de ministeriële regelingen per sector geven op dit moment geen vaste termijn voor alle logdata.

Iedere partij die je nu een hard getal belooft, verzint dat getal. Wat de wet wel vraagt: dat je incidenten kunt detecteren, onderzoeken en op tijd melden, en daar kun je je termijnen op bouwen.

Checklist: de negen logbronnen die je op orde moet hebben

1. Authenticatie en autorisatie. Wie logt waar in, en waar mislukt dat opvallend vaak? Dit is de bron waar vrijwel elk onderzoek begint.
2. Netwerkverkeer op de perimeter. Firewall, VPN en proxy laten zien wat er de organisatie in en uit gaat.
3. Endpoint-detectie. EDR-telemetrie van werkplekken en servers, waar de meeste aanvallen zichtbaar worden.
4. Configuratiewijzigingen. Wie zette welke regel uit, en wanneer? Zonder deze bron is elk incidentonderzoek giswerk.
5. Privileged sessies. Beheerdersaccounts en service-accounts kunnen het meest, dus verdienen het meeste zicht.
6. Het cloud control plane. AWS CloudTrail, Azure Activity Log en vergelijkbare audit-logs: wie deed wat met je cloudomgeving zelf.
7. Back-up en restore. Draaide de back-up, en is een restore ooit echt getest? Bij ransomware is dit de bron die telt.
8. OT-assets, indien van toepassing. Industriële systemen vallen ook onder je zorgplicht; beschikbaarheid en afwijkend gedrag zijn daar de signalen.
9. De logging van je logging. De gezondheid van je logpijplijn zelf: welke bron is stilgevallen, waar loopt vertraging op? Vrijwel iedereen vergeet deze, en het is precies de bron waarmee je de andere acht bewaakt.

Hoe je bewaartermijnen bepaalt zonder dat de wet ze geeft

Bepaal de termijn per logbron, op basis van drie vragen: hoe lang duurt het voordat je een incident ontdekt, hoe lang heb je nodig om het te onderzoeken, en wat moet je kunnen melden? De meldplicht is streng: binnen 24 uur moet bij een significant incident een vroegtijdige waarschuwing de deur uit. En een aanvaller die vier maanden onopgemerkt binnen is, is geen uitzondering, bewaar je logs dertig dagen, dan valt er bij ontdekking niets meer te onderzoeken.

Lange termijnen hoeven niet duur te zijn: houd recente data hot (direct doorzoekbaar, prijzig) voor detectie en verhuis oudere data naar cold of archive storage (traag, goedkoop). Een pipeline-laag maakt dat onderscheid praktisch uitvoerbaar; hoe je zo je logvolume beheersbaar houdt, lees je in ons artikel over telemetry pipelines.

Aantoonbaarheid: opzet, bestaan en werking

Een toezichthouder vraagt niet óf je logt, maar of je kunt aantonen dat de maatregel is opgezet, bestaat en werkt. Drie woorden, drie artefacten.

• Opzet: een gedocumenteerde logstrategie. Welke bronnen, waarom, met welke termijn.
• Bestaan: bewijs dat de bronnen daadwerkelijk aanleveren, dus monitoring op de pijplijn zelf.
• Werking: periodieke rapportage die over een langere periode laat zien dat het geheel functioneert: dekking, uitval, opvolging.

Die derde is in de praktijk de lastigste, omdat je haar niet achteraf kunt reconstrueren. Bij SMT is dat daarom standaard onderdeel van elke Managed Service: vaste rapportage met KPI’s, trends en bevindingen, zodat het bewijs er ligt op het moment dat iemand erom vraagt.

Waar organisaties in de praktijk op stuklopen

1. Logbronnen die stilletjes stoppen met aanleveren. Een certificaat verloopt, een agent crasht, en niemand merkt het tot het onderzoek begint.
2. Tijdsynchronisatie die niet klopt. Loopt de klok van je firewall drie minuten voor op die van je servers, dan valt er niets meer te correleren.
3. Logvolume dat het budget opeet. Waarna bronnen worden uitgezet om kosten te drukken. Dat is de gevaarlijkste bezuiniging die er is: je bespaart op precies het zicht dat de wet van je vraagt.
4. Geen eigenaar. Logging is van iedereen een beetje en dus van niemand. Zonder eigenaar verzandt elke goede opzet binnen een jaar.

De derde valkuil is geen natuurwet: wie data filtert voordat die het dure platform bereikt, houdt volume en budget in de hand zonder bronnen op te offeren. De actuele stand van de wet vind je op ncsc.nl.

Veelgestelde vragen

• Val ik onder de Cyberbeveiligingswet?
• Hoe toon ik aan dat mijn logging werkt?
• Welke logbronnen heb ik minimaal nodig?
• Wanneer treedt de Cyberbeveiligingswet in werking?
• Hoe lang moet ik logs bewaren onder NIS2?

Het Purdue-model is een referentiearchitectuur die industriële netwerken opdeelt in gelaagde zones, van de fysieke procesbesturing op de werkvloer tot de bedrijfs-IT op kantoor. Per zone ligt vast welk verkeer erin en eruit mag, zodat een storing of aanval in de ene laag niet zomaar doordringt tot de volgende. Eerlijk is eerlijk: het model stamt uit een tijd waarin OT-netwerken echt gescheiden waren. Die aanname houdt niet meer, terwijl veel organisaties hun monitoring nog inrichten alsof de muren er nog staan.

Hieronder eerst het model, daarna waar het in de praktijk om draait: monitoringdata uit je OT-omgeving halen zonder die omgeving open te zetten.

Het Purdue-model in vijf niveaus

Het model telt zes lagen, van 0 tot en met 5. Hoe lager het niveau, hoe dichter op het fysieke proces en hoe zwaarder beschikbaarheid weegt.

Tussen niveau 3 en 4 zit in de praktijk nog niveau 3.5: de industriële DMZ, de plek waar IT en OT elkaar gecontroleerd raken, en waar je monitoringvraagstuk zich afspeelt.

Waarom de scheiding tussen IT en OT verdwijnt

Drie ontwikkelingen slopen de klassieke scheiding.

1. Cloudconnectiviteit voor remote support. Leveranciers kijken op afstand mee voor onderhoud en storingsanalyse, en elke supportverbinding is een pad dat het model nooit voorzien heeft.
2. Industriële IoT. Nieuwe sensoren praten rechtstreeks met een cloudplatform en slaan de lagen simpelweg over.
3. De vraag naar OT-data voor bedrijfsbeslissingen. Onderhoudsplanning, energieverbruik, beschikbaarheid: de antwoorden zitten in OT-data, maar de vragen worden op IT-niveau gesteld.

Dat dit geen nicheonderwerp meer is, zie je bij de overheid: de BIO2-communicatie van februari 2026 stond volledig in het teken van OT-security, en de Cybersecurity Implementatierichtlijn (CSIR) geldt daar als dé OT-norm. Wat dat betekent lees je in wat BIO2 vraagt van OT-omgevingen.

Data uit OT halen zonder je OT-netwerk te openen

Hier zit de technische kern: monitoringdata de ene kant op, zonder dat er ooit een verbinding de andere kant op gaat. Drie patronen, goed te combineren.

1. Unidirectionele gateways of datadiodes. Hardware die verkeer fysiek maar één richting op laat: data verlaat de OT-zone, niets kan terug. In omgevingen met hoge veiligheidseisen vaak het uitgangspunt.
2. Een collector in de DMZ (niveau 3.5). OT-systemen leveren hun data af bij een collector in de tussenlaag; de IT-zone haalt de data daar op. Een directe verbinding tussen beide werelden bestaat niet.
3. Een pipeline-laag die filtert, normaliseert en maskeert. Voordat data de IT-zone bereikt, bepaal je wat er doorheen mag en zonder welke gevoelige velden. Een lichte agent zoals Cribl Edge doet dat werk al dicht bij de bron; meer daarover op onze pagina over data filteren en routeren aan de bron.

Wat je wel en niet meet in een OT-omgeving

In OT gedraagt data zich precies omgekeerd aan IT: een laag volume en een hoge criticaliteit per gebeurtenis, waar IT-logs een hoog volume en een lage criticaliteit hebben. Eén afwijkende melding kan een pomp zijn die het begeeft.

Wel meten: asset-inventaris, protocolafwijkingen in bijvoorbeeld Modbus- of DNP3-verkeer, beschikbaarheid van kritieke assets en firmware-versies.

Niet meten: alles wat een IT-SIEM standaard binnenharkt. Detectieregels die in IT prima werken, produceren in OT vrijwel alleen ruis. Detectie bouw je hier op gedrag en afwijking, niet op volume.

In de praktijk: van tunnelbeheer naar voorspelbare beschikbaarheid

Vialis past dit toe op een tunnel in de A4, onder een start- en landingsbaan van een internationale luchthaven. Bestaande sensordata wordt via Cribl gefilterd en verrijkt, en in Splunk geanalyseerd op patronen die op slijtage wijzen: verhoogd stroomverbruik bij een pomp, oplopende temperaturen, afwijkend ventilatiegedrag. Webhooks starten vervolgacties, zoals het inplannen van onderhoud. Het resultaat is in de operatie duidelijk merkbaar: hogere tunnelbeschikbaarheid, minder ongeplande sluitingen en onderhoud op werkelijke conditie. Lees de volledige case study Vialis (pdf). Hoe je van meten naar onderhoudsbeslissingen komt, lees je in van preventief naar voorspelbaar onderhoud.

Het Purdue-model is niet dood; het is een denkmodel geworden in plaats van een bouwtekening. De grens verschuift naar de vraag welke data haar mag passeren, en wie dat heeft ingericht, wil het zo houden. Dat is het punt waarop het beheer van je monitoringplatform net zo belangrijk wordt als de architectuur zelf.

Veelgestelde vragen

• Wat is het verschil tussen OT-monitoring en IT-monitoring?
• Kun je OT-data monitoren zonder je OT-netwerk te openen?
• Is het Purdue-model nog relevant?

• Wat is het Purdue-model?

  Het Purdue-model is een referentiearchitectuur die industriële netwerken opdeelt in zones, van fysieke procesbesturing op niveau 0 tot bedrijfs-IT op niveau 4 en 5, zodat duidelijk is welk verkeer tussen welke zones is toegestaan.

Alert fatigue is de afstomping die ontstaat wanneer analisten zoveel meldingen krijgen dat ze echte signalen missen. Wie tweehonderd keer per dienst op “close” klikt, klikt op een dag ook de melding weg die ertoe deed. De stelling die dit artikel draagt: alert fatigue is zelden een mensenprobleem en bijna altijd een datakwaliteitsprobleem.

Waar de ruis vandaan komt

1. Regels uit een standaardpakket, nooit aangepast aan de eigen omgeving. De content-packs van je SIEM zijn geschreven voor een gemiddelde organisatie die niet bestaat. Een regel die elders scherp is, loeit bij jou de hele dag.
2. Ontbrekende context. Een beheerder die om 02:00 uur inlogt: verdacht, tenzij het de geplande patchronde is. Zonder wijzigingskalender en asseteigenaar in de melding ziet de analist dat verschil niet, dus onderzoekt hij het. Elke keer weer.
3. Dubbele detecties op verschillende lagen. EDR, firewall en SIEM melden hetzelfde event, elk in eigen bewoording. Eén gebeurtenis, drie tickets.
4. Regels die niemand meer durft uit te zetten. Niemand weet waarom ze bestaan, dus laat iedereen ze staan. Voor de zekerheid. De eerlijkste oorzaak op dit lijstje, en de meest voorkomende.

Wat is detection engineering?

Detection engineering is het behandelen van detectieregels als een product met een levenscyclus, niet als een project dat ooit af is. Elke regel heeft een eigenaar, een doel en een houdbaarheidsdatum. Vijf fasen:

1. Ontwerpen. Welke techniek of welk risico wil je zien, en welke data heb je daarvoor nodig? Eigenaar: de detection engineer.
2. Bouwen. De regel schrijven, met context (assetwaarde, eigenaar) er meteen bij.
3. Testen. Tegen historische data en gesimuleerde aanvallen, voordat de regel live gaat. Eigenaar: engineer plus analist.
4. Afstemmen. De false positive ratio per regel volgen en bijsturen. Eigenaar: de analisten die de meldingen zien; doorlopend, met een vast maandelijks moment.
5. Uitfaseren. Regels die niets meer opleveren gedocumenteerd uitzetten, elk kwartaal. Vrijwel niemand doet deze fase, en het is precies de fase die oorzaak vier hierboven voorkomt.

Meten voordat je tunet

Vier meetwaarden volstaan om te weten waar je staat:

• Meldingen per analist per dienst. De directe maat voor werkdruk.
• False positive ratio per regel. Niet per omgeving, maar per regel, anders weet je nooit welke regel het probleem is.
• Mean time to triage. Hoe lang duurt het voordat iemand een melding heeft beoordeeld?
• Aandeel meldingen dat tot actie leidt. De hardste maat voor signaalwaarde.

Zonder nulmeting kun je na drie maanden tunen niet aantonen dat het hielp, en dan verdwijnt het budget. Streefcijfers geven we bewust niet: die verschillen per omgeving, en wie je er toch een noemt, kent jouw omgeving niet.

Vier maatregelen die het volume echt verlagen

1. Verrijk meldingen met context voordat ze bij een analist landen. Assetwaarde, eigenaar, wijzigingsvenster. De melding “inlog op srv-db-03 (kroonjuweel, eigenaar team Betalingen, geen gepland werk)” triageert zichzelf half.
2. Onderdruk meldingen tijdens geplande wijzigingen. Een patchnacht met vierhonderd meldingen leert analisten precies één ding: negeren.
3. Groepeer verwante meldingen tot één incident. Tien signalen van één aanvalspad horen in één dossier, niet in tien tickets. Waar AI wel en niet helpt bij ruisreductie, lees je in ons artikel over AIOps.
4. Verwijder data zonder detectiewaarde voordat die je SIEM in gaat. Debug-logging en heartbeats voeden geen enkele detectie, maar vervuilen wel elke zoekopdracht. Hoe je data filtert voordat die je SIEM in gaat, lees je in ons artikel over telemetry pipelines.

Een dashboard per component vertelt je hoe de database en de applicatieserver zich voelen, maar niet of de dienst het doet. Groene lampjes en toch klachten, iedereen in operations kent dat gesprek. Service-gebaseerde monitoring draait het om: je koppelt technische signalen aan een bedrijfsproces, zoals “bestelling plaatsen” of “brug bedienen”, en bewaakt dat. In de Splunk-wereld is dit het domein van Splunk Observability Cloud en ITSI.

Dekking meten met MITRE ATT&CK

Als de ruis afneemt, komt de volgende vraag: zien we wel de juiste dingen? Het MITRE ATT&CK-framework beschrijft de technieken die aanvallers daadwerkelijk gebruiken. Koppel je detecties daaraan, en het gesprek verandert van “hoeveel regels hebben we” in “welke technieken zien we, en welke niet”, het enige gesprek dat je risico verkleint.

Eén waarschuwing: dekking najagen om de dekking is de nieuwe valkuil. Dek de technieken die voor jouw omgeving en dreigingsbeeld tellen, en dek die goed.

Detection engineering vraagt om ritme: elke dag kijken, elke maand afstemmen, elk kwartaal opruimen. Dat ritme organiseren wij met 24/7 checks door een team in plaats van een persoon. Speelt de vraag of je dit zelf wilt doen, lees dan ons artikel over welk servicemodel bij je past.

Veelgestelde vragen

• Wat meet ik om te weten of tuning werkt?
• Hoe verlaag ik het aantal false positives?
• Wat is detection engineering?
• Wat is alert fatigue?

Monitoring meet vooraf bepaalde signalen en waarschuwt als een drempelwaarde wordt overschreden. Observability is het vermogen om de toestand van een systeem te begrijpen op basis van de data die het uitzendt, ook bij problemen die je niet had voorzien. Anders gezegd: monitoring vertelt je dát er iets mis is, observability helpt je begrijpen waaróm. De twee termen worden voortdurend door elkaar gebruikt, en dat kost organisaties geld: wie observability koopt voor een monitoringprobleem betaalt te veel, en wie monitoring inzet voor een observabilityprobleem blijft zoeken.

Het verschil in een tabel

De kern zit in die tweede rij. Monitoring bewaakt wat je vooraf kon bedenken. Observability geeft je de mogelijkheid om vragen te stellen die je pas bedenkt op het moment dat het misgaat.

The three pillars of observability: logs, metrics en traces

Logs vertellen wat er gebeurde: een foutmelding met stacktrace, een geweigerde inlogpoging, een time-out met de exacte parameters erbij. Ze zijn rijk aan detail, maar duur in volume.

Metrics vertellen hoeveel en hoe vaak: responstijden, foutpercentages, wachtrijlengtes. Compact, goedkoop, ideaal voor trends en alerts, maar zonder het verhaal erachter.

Traces vertellen waar in de keten het gebeurde: het pad van één verzoek langs alle services, met per stap de tijd die het kostte. Onmisbaar zodra één klik door tien systemen gaat.

En dan het eerlijke voorbehoud: de drie pijlers zijn een nuttig model, geen doel. Veel organisaties verzamelen keurig alle drie, in drie losse tools, zonder ze ooit te correleren. Dan heb je drie keer opslagkosten en nul keer inzicht. De waarde ontstaat pas als je vanuit een metric-piek kunt doorklikken naar de bijbehorende trace en logs.

Wanneer monitoring genoeg is

Nu de vraag die leveranciers liever overslaan: heb je observability nodig? Voor een stabiele, monolithische omgeving met bekende faalmodi is klassieke monitoring goedkoper en effectiever. Drie criteria om te beslissen:

1. Architectuur. Draait alles op een handvol servers, of is je landschap gedistribueerd over tientallen services en cloudcomponenten?
2. Vraagpatroon. Stel je bij incidenten steeds dezelfde vragen, of steeds nieuwe? Zodra elke storing een unieke puzzel is, schiet vooraf bedachte monitoring tekort.
3. Veranderingstempo. Wie wekelijks deployt, creëert wekelijks nieuwe manieren om te falen. Hoe sneller je omgeving verandert, hoe minder je vooraf kunt bedenken.

Scoor je op alle drie laag, houd het dan simpel en investeer je budget ergens anders in. Dat advies levert ons niets op, maar het klopt wel.

Van dashboards naar service-inzicht

Een dashboard per component vertelt je hoe de database en de applicatieserver zich voelen, maar niet of de dienst het doet. Groene lampjes en toch klachten, iedereen in operations kent dat gesprek. Service-gebaseerde monitoring draait het om: je koppelt technische signalen aan een bedrijfsproces, zoals “bestelling plaatsen” of “brug bedienen”, en bewaakt dat. In de Splunk-wereld is dit het domein van Splunk Observability Cloud en ITSI.

Wat je nodig hebt om te beginnen

1. Inventariseer welke data je al uitzendt. Applicaties, infrastructuur, cloudplatformen: het meeste is er al.
2. Zorg voor consistente tijdstempels en identifiers over bronnen heen. Zonder gedeelde sleutels valt er niets te correleren; hoe je consistente data over bronnen heen aan de bron regelt, lees je in ons artikel over telemetry pipelines.
3. Definieer wat een dienst is en welke componenten eronder vallen. Dit is een gesprek met de business, geen technische exercitie.
4. Begin met één dienst. Bewijs de waarde daar, en breid daarna pas uit.

Staat deze basis, kijk dan verder naar wat AI hieraan toevoegt. En wie het platform liever niet zelf scherp houdt: het beheer en de optimalisatie van je platform is precies wat wij als Managed Service doen.

Veelgestelde vragen

• Is observability hetzelfde als een SIEM?

  Nee. Observability richt zich op de gezondheid en prestaties van diensten, een SIEM op detectie van beveiligingsincidenten. Ze delen vaak dezelfde databronnen, maar beantwoorden andere vragen.

• Wanneer is monitoring genoeg?
• Wat zijn de three pillars of observability?

  Logs (wat er gebeurde), metrics (hoeveel en hoe vaak) en traces (waar in de keten). Het is een nuttig model, geen doel. Veel organisaties verzamelen alle drie zonder ze te correleren, en daar gaat het mis.

• Wat is het verschil tussen observability en monitoring?

  Monitoring meet vooraf bepaalde signalen en waarschuwt bij overschrijding van een drempelwaarde. Observability is het vermogen om de toestand van een systeem te begrijpen uit de data die het uitzendt, ook bij problemen die je niet had voorzien.

Een Splunk-architectuur is een verzameling gespecialiseerde componenten die data ontvangen, indexeren, doorzoeken en beheren, waarbij clustering zorgt voor beschikbaarheid en schaalbaarheid. Wie de rolverdeling en de twee clustervormen begrijpt, weet waar zijn eigen omgeving kwetsbaar is. Dit stuk is voor Splunk-engineers en -admins, we sparen het jargon niet.

De componenten op een rij

De Splunk-documentatie vertelt wat elk component doet, niet wat er gebeurt als het uitvalt. En juist met die kolom beoordeel je je architectuur.

Indexer clustering: replication factor en search factor

Twee getallen bepalen het gedrag van je indexer cluster: de replication factor (RF) bepaalt hoeveel kopieën van de ruwe data het cluster bewaart, de search factor (SF) hoeveel daarvan ook doorzoekbaar zijn, inclusief tsidx-indexbestanden.

Concreet, met RF3 en SF2: elke bucket bestaat drie keer als ruwe data, waarvan twee direct doorzoekbaar. Valt één indexer uit, dan is er geen dataverlies en blijft zoeken mogelijk, terwijl de cluster manager via fixup de aantallen herstelt. Opslag: drie keer de gecomprimeerde ruwe data plus twee keer de indexbestanden.

De klassieke fout: SF gelijkstellen aan RF “omdat het veiliger klinkt”. Dat levert zelden extra weerbaarheid op, maar wel een extra complete set tsidx-bestanden, je opslagverbruik schiet omhoog zonder dat je er iets voor terugkrijgt. Verhoog SF alleen met een concreet herstelscenario waarin die extra doorzoekbare kopie het verschil maakt.

Search head clustering en captain election

Een search head cluster kiest uit zijn leden een captain: die verdeelt scheduled searches, coördineert de replicatie van knowledge objects (dashboards, saved searches, lookups) en bewaakt de clusterstaat. Valt de captain weg, dan kiezen de overgebleven leden een nieuwe, mits ze met een meerderheid zijn.

Dat meerderheidsvereiste verklaart twee vuistregels. Drie search heads is het minimum, want bij twee is elke uitval meteen het einde van de meerderheid. En een even aantal is een slecht idee: splitst een netwerkpartitie een cluster van vier in tweeën, dan heeft geen van beide helften een meerderheid en liggen scheduled searches en replicatie stil terwijl alle machines gewoon aanstaan.

Vijf fouten die we het vaakst tegenkomen

Met meer dan 500 implementaties achter de rug zien we dezelfde fouten terugkomen. De vijf hardnekkigste:

1. 1. Search factor gelijk aan replication factor, zonder reden. Zie hierboven: veel opslag, weinig winst.
   2. Een monitoring console die zelf niet gemonitord wordt. Het systeem dat alles bewaakt, wordt door niets bewaakt. Valt het stil, dan merkt per definitie niemand dat.
   3. Knowledge objects lokaal op één search head in plaats van in het cluster. Alles werkt, tot die ene search head uitvalt en de dashboards van een heel team nergens anders blijken te bestaan.
   4. Forwarders die zonder load balancing naar één vaste indexer praten. Eén indexer eruit betekent meteen datagaten, en de load in het cluster is structureel scheef.
   5. Een deployment server die te veel clients bedient. Duizenden forwarders op één onderbemeten machine: configuratie-updates druppelen dagenlang binnen, of komen nooit aan.

Wat je periodiek zou moeten controleren

Wil je dit één keer grondig laten doorlichten, dan is de Splunk Health Check de kortste route. Structureler kan ook: Splunk-beheer uitbesteden betekent dat deze controles elke dag gebeuren, door een team in plaats van die ene collega. Hoe je daarna van dashboards naar service-inzicht komt, en waarom omgevingen hun heavy forwarders vervangen door een pipeline-laag, lees je in de vervolgblogs. Twijfel je tussen platformen, lees dan welk platform bij je past.

Veelgestelde vragen

• Wat controleer je periodiek in een Splunk-omgeving?
• Hoeveel search heads heb ik minimaal nodig voor een cluster?
• Hoe zorgen we ervoor dat een investering in Splunk rendabel blijft naarmate onze data groeit?
• We gebruiken al meerdere monitoring- en securitytools. Wat voegt Splunk dan nog toe?
• Hoe helpt Splunk ons om sneller inzicht te krijgen in problemen voordat ze impact hebben op de business?

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

1. 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.
2. Verrijken. Voeg context toe terwijl de data onderweg is: assetwaarde, eigenaar, omgeving. Een verrijkte melding hoeft een analist niet meer op te zoeken.
3. Routeren. Stuur elke stroom naar de goedkoopste bestemming die nog voldoet: detectiewaardige data naar het SIEM, compliance-data rechtstreeks naar goedkope object storage.
4. 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

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

1. Meet je huidige volume per bron. Niet het totaal, maar per bron, daar zitten de verrassingen.
2. Bepaal per bron de detectie- en compliancewaarde. Welke detecties draaien erop, welke bewaarplicht geldt? Data zonder antwoord op beide vragen is je eerste kandidaat.
3. 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.
4. Verleg één bron en vergelijk. Zelfde detecties, zelfde dashboards, minder volume? Dan werkt het aantoonbaar.
5. 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.

Veelgestelde vragen

• Hoeveel logvolume kan ik besparen met een pipeline?

  Dat verschilt per omgeving en vooral per bron. Ter indicatie uit de praktijk: bij PostNL daalde het ingest-volume van AWS CloudTrail met 40 procent, waar vooraf 30 procent was verwacht.

• Wat is het verschil tussen Cribl Stream en Cribl Edge?

  Stream is de centrale verwerkingslaag, Edge een lichte agent die dicht bij de bron draait. Edge is relevant voor OT-omgevingen en verre locaties waar je bandbreedte wilt sparen of data niet ongefilterd wilt versturen.

• Wat doet Cribl Stream precies?

  Cribl Stream verwerkt datastromen centraal: het filtert wat geen waarde heeft, verrijkt met context, routeert naar de juiste bestemming en maskeert gevoelige velden. Zo verlaag je volume en kosten zonder detectiedekking op te geven.

• Wat is een telemetry pipeline?

  Een telemetry pipeline is een tussenlaag tussen je databronnen en je analyse- of securityplatformen die bepaalt wat waarheen gaat: filteren, verrijken, routeren en maskeren, voordat de data zijn bestemming bereikt.

Voorspellend onderhoud betekent onderhoud plannen op basis van de werkelijke conditie en het gedrag van een asset, in plaats van op een vaste kalender. Internationaal heet het predictive maintenance, en het steunt op data die de asset en de systemen eromheen vaak al produceren. Daarmee is meteen gezegd wat dit artikel anders maakt dan de meeste stukken over dit onderwerp: het gaat niet over een onderhoudspakket aanschaffen, maar over de data die je al hebt en wat daarvoor nodig is.

Drie vormen van onderhoud, en wat ze kosten

En nu het eerlijke verhaal: voor veel assets is preventief onderhoud gewoon prima. Een vast interval voor iets goedkoops dat zelden faalt, hoef je niet slimmer te maken. Voorspellend onderhoud loont bij assets waar uitval duur of gevaarlijk is: de tunnel, de terminal, het gemaal.

Welke data je nodig hebt (en waarschijnlijk al hebt)

Vier bronnen vormen samen het beeld.

1. Sensordata uit de asset zelf. Stroomverbruik, temperatuur, trilling, druk: de signalen die slijtage verraden.
2. Logdata uit de besturingssystemen. PLC’s en SCADA registreren schakelmomenten, foutcodes en afwijkingen die je in sensordata alleen niet ziet.
3. Netwerktelemetrie. Een installatie die hapert, kondigt zich op het netwerk vaak eerder aan dan in het proces.
4. De storingshistorie uit je onderhoudssysteem. Wat ging er eerder kapot, wanneer, en wat ging eraan vooraf? Dit is je referentiemateriaal.

De eerste drie komen meestal al ergens langs, alleen in verschillende systemen met verschillende tijdstempels. Het werk zit niet in het voorspellen, maar in het samenbrengen, en in de vraag hoe je die data veilig uit je OT-omgeving haalt.

Waarom predictive maintenance zelden op het model stukloopt

De meeste voorspellend-onderhoudsprojecten stranden niet op het algoritme. Ze stranden op datakwaliteit, en wel op drie voorspelbare manieren.

1. Te weinig storingshistorie om op te trainen. Kritieke assets falen gelukkig zelden, dus zijn er weinig voorbeelden van hoe falen eruitziet.
2. Tijdstempels die niet synchroon lopen. Als de sensor, de PLC en het onderhoudssysteem elk hun eigen klok hanteren, kun je oorzaak en gevolg niet meer op één tijdlijn leggen.
3. Assets die pas gaan loggen als er al iets mis is. Foutcodes zijn geen conditiedata. Je wilt weten hoe gezond gedrag eruitziet, niet alleen hoe kapot eruitziet.

Onze ervaring, zonder omwegen: met een half jaar goede data kom je verder dan met een geavanceerd model op vuile data. Begin dus bij de data, niet bij het algoritme.

In de praktijk: tunnels en terminals

Vialis past dit toe op een tunnel in de A4. Sensordata wordt via Cribl gefilterd en verrijkt, en in Splunk geanalyseerd op patronen die op slijtage wijzen; webhooks starten vervolgacties zoals het inplannen van onderhoud. Het effect: hogere tunnelbeschikbaarheid, minder ongeplande sluitingen en onderhoud op werkelijke conditie. Lees de case study Vialis (pdf).

Bij Rotterdam World Gateway (RWG), een van de meest geautomatiseerde containerterminals ter wereld, zat het probleem niet in een gebrek aan data maar aan zichtbaarheid: data lag verspreid over logsystemen, applicaties, leverancierssystemen en OT. Door die stromen in Splunk te correleren ging de start van een probleemanalyse van uren naar minuten en veranderde stilstand van verrassing in beheersing. Lees de case study RWG (pdf).

Een realistisch stappenplan

1. Kies een asset waar uitval echt pijn doet. Niet de makkelijkste, maar de duurste storing van vorig jaar.
2. Inventariseer welke data die asset nu al produceert. Sensoren, besturing, netwerk, onderhoudssysteem, meestal meer dan je denkt.
3. Breng die data samen op één tijdlijn. Zelfde klok, zelfde identifiers. Dit is tachtig procent van het werk.
4. Leg de storingshistorie ernaast en zoek patronen met het blote oog. Wat zag je in de dagen voor elke storing? Vaak springt het patroon eruit zonder code.
5. Automatiseer pas als je het patroon zelf herkent. Een model moet bevestigen wat jij al snapt. Dit advies krijg je van softwareleveranciers niet, en het scheelt je een mislukt project.

Voorspellend onderhoud is geen product dat je koopt, maar een werkwijze die je opbouwt, en die valt of staat met de continuïteit van kritieke systemen eronder. Voor de servicelaag daarboven is ITSI en service-monitoring het gereedschap.

Veelgestelde vragen

• Waarom mislukken predictive maintenance-projecten?
• Heb ik speciale software nodig voor predictive maintenance?
• Wat is voorspellend onderhoud?

AIOps is het toepassen van machine learning en statistische analyse op operationele data: om afwijkingen te vinden, meldingen te correleren en problemen te voorspellen voordat ze uitval worden. Tot zover de definitie die je overal leest. Dit artikel doet iets wat de meeste stukken over AIOps overslaan: het beschrijft ook wat AIOps niet oplost. Die kant hoor je zelden van partijen die het verkopen, en het is precies de kant die bepaalt of jouw investering iets oplevert.

De vier dingen die AIOps daadwerkelijk goed doet

1. Anomaliedetectie op tijdreeksen. Een statische drempel zegt: alarm boven 80 procent. Een model leert dat 70 procent op dinsdagochtend normaal is en op zondagnacht niet, en slaat dus eerder én preciezer aan. In de Splunk-stack is dit het domein van de Machine Learning Toolkit.
2. Correlatie van meldingen naar één incident. Storage-latency, database-timeouts en applicatiefouten zijn geen drie problemen; het is één probleem met drie gezichten. Splunk ITSI groepeert die signalen tot één episode.
3. Ruisreductie. Dezelfde melding die elke vijf minuten terugkomt, wordt één melding met een teller. Klinkt banaal, scheelt in de praktijk het meeste geklik.
4. Capaciteitsvoorspelling. Op basis van trends zie je dat een schijf over drie weken volloopt, in plaats van vannacht om drie uur, dat verplaatst werk van paniek naar planning.

Waar dit in de praktijk zit: de Splunk Machine Learning Toolkit en ITSI voor respectievelijk de modellen en de servicecorrelatie.

De drie dingen die AIOps niet oplost

1. AIOps repareert geen vuile data. Een model op inconsistente logs geeft zelfverzekerde onzin. Ontbrekende velden, dubbele bronnen en klokken die uit elkaar lopen worden niet weggemodelleerd; ze worden versterkt.
2. AIOps vervangt geen engineer. Het model wijst aan waar je moet kijken, niet waarom het misgaat in jouw architectuur, welke workaround uit 2021 nog ergens draait, of welke afhankelijkheid nooit is gedocumenteerd. Het verkort de zoektijd; de diagnose blijft mensenwerk.
3. AIOps lost geen procesprobleem op. Als niemand eigenaar is van een alert, verandert een slimmer alert daar niets aan. Het wordt alleen sneller genegeerd.

Vandaar ons uitgangspunt: niet de hype volgen, maar wat werkt in jouw landschap. Meer alerts zijn zelden het antwoord, waarom dat zo is, lees je in ons artikel over waarom meer alerts niet helpen.

Van chaos naar controle: een voorbeeld

Hoe dit uitpakt als de voorwaarden op orde zijn, beschrijft onze use case over Splunk AI. De uitgangssituatie is herkenbaar: miljoenen signalen per seconde uit IT en OT, meldingen die zich opstapelen, teams die tijd verliezen aan vals alarm. Door logdata samen te brengen in Splunk, machine learning afwijkingen te laten herkennen die met vaste regels onzichtbaar blijven, en verdachte gebeurtenissen automatisch naar het juiste team te routeren, veranderde dat beeld. Het resultaat uit de use case: 75 procent minder valse meldingen, snellere detectie van echte dreigingen en één platform waar IT- en OT-teams samen mee werken. De volledige use case Splunk AI (pdf) lees je in ons downloadcentrum.

Hoe je AIOps stapsgewijs invoert

1. Kies één use case met een duidelijke eigenaar. Niet “alles slimmer maken”, maar bijvoorbeeld: eerder zien dat de orderverwerking hapert.
2. Doe een nulmeting. Aantal meldingen per week, mean time to detect. Zonder nulmeting valt succes niet te bewijzen.
3. Normaliseer de databronnen voor die ene use case. Niet je hele landschap; alleen wat deze detectie nodig heeft.
4. Laat het model meelopen zonder actie. Een paar weken schaduwdraaien laat zien of het model jouw normaal begrijpt.
5. Meet opnieuw en beslis op cijfers. Minder meldingen, snellere detectie? Uitbreiden. Zo niet: stoppen kost nu weinig, precies waarom je klein begon.

AIOps is geen wondermiddel; het is gereedschap dat rendeert zodra je data en je proces het toelaten. Dat zo houden vraagt om proactief beheer in plaats van reactief: iemand die modellen, bronnen en eigenaren scherp houdt.

Leveranciersbeheer: je blijft zelf verantwoordelijk

BIO2 scherpt de eisen aan voor uitbesteding en toezicht op derden, en de eindverantwoordelijkheid blijft waar die was: bij jouw organisatie. Uitbesteden mag dus prima, verantwoording uitbesteden niet.

Praktisch betekent dat: kies een partner die het bewijs levert dat jij nodig hebt voor je verantwoording. Denk aan gecontroleerde, auditable toegang tot je omgeving en vaste rapportages over wat er is gedaan en wat het opleverde. Bij onze Managed Services zijn auditable toegang en transparante rapportage daarom standaard onderdeel van de dienst, geen optie. De actuele versie van de baseline en het ondersteuningsmateriaal vind je op bio-overheid.nl.

Veelgestelde vragen

• Waar begin ik met AIOps?
• Wat heb ik nodig voordat AIOps werkt?
• Vervangt AIOps engineers?
• Wat is AIOps?

De Baseline Informatiebeveiliging Overheid 2 (BIO2) is het basisnormenkader voor informatiebeveiliging binnen alle overheidslagen: Rijk, gemeenten, provincies en waterschappen. Het kader is gebaseerd op ISO 27001 en 27002 en krijgt via de Cyberbeveiligingswet een wettelijke basis. Versie 1.3 is op 5 maart 2026 gepubliceerd in de Staatscourant, en dat is meer dan een administratieve mijlpaal: de ministeriële regeling onder de wet verwijst voor de zorgplicht van de sector Overheid rechtstreeks naar die publicatie. In dit artikel laten we de normteksten voor wat ze zijn en kijken we naar één vraag: wat betekent BIO2 concreet voor je logging, je monitoring en je rapportage?

Wat er verandert ten opzichte van BIO 1.04

Drie wijzigingen springen eruit.

Eén nuance die vrijwel nergens correct wordt opgeschreven: BIO2 v1.3 geldt sinds de publicatie als verplichtende zelfregulering voor het Rijk, provincies en waterschappen. Gemeenten werkten formeel nog met BIO 1.04, met BIO2 als richtinggevend kader, tot de inwerkingtreding van de Cyberbeveiligingswet op 15 augustus 2026. Vanaf dat moment loopt de verplichting voor alle bestuurslagen via de wet en de bijbehorende regeling.

Risicogestuurd werken betekent: je moet je risico kunnen zien

Het schrappen van de BBN-tabel klinkt als een detail, maar het verandert je werk fundamenteel: er valt niets meer af te vinken. Je moet per proces en informatiesysteem bepalen welk risico je loopt, en dat kan alleen met zicht op wat er in die systemen gebeurt. Zonder monitoring geen risicobeeld.

Neem een kritiek burgerproces: het uitbetalen van uitkeringen. Het risico zit zelden in de applicatie alleen, maar in de keten eromheen: de koppeling met de basisregistratie, de batchverwerking die ’s nachts draait, het service-account dat die batch uitvoert. Risicogestuurd werken betekent dat je die keten kunt zien: weet wanneer de batch niet draaide, wanneer het account buiten het venster inlogde, wanneer de koppeling haperde. Dat is geen beleidsvraag meer, dat is monitoring.

Opzet, bestaan en werking aantonen

BIO2 vraagt dat je van maatregelen de opzet, het bestaan en de werking kunt aantonen. Drie woorden, drie artefacten.

• Opzet: beleid en configuratie. Wat heb je bedacht en hoe is het ingericht?
• Bestaan: bewijs dat de maatregel actief is. Niet het beleidsdocument, maar de draaiende regel, de aanleverende logbron.
• Werking: meetgegevens over een langere periode. Deed de maatregel wat hij moest doen, ook in maart, ook in de vakantieperiode?

De derde is de moeilijkste, want werking kun je niet met terugwerkende kracht verzinnen. Je krijgt haar alleen uit continue monitoring en periodieke rapportage die je al die tijd hebt laten lopen. Wie daar pas bij de eerste audit aan begint, is per definitie te laat.

OT valt er ook onder

Een punt dat makkelijk wordt gemist: de BIO2-communicatie van februari 2026 stond volledig in het teken van OT-security, en de Cybersecurity Implementatierichtlijn (CSIR) is binnen de overheid de implementatierichtlijn voor industriële omgevingen. Voor waterschappen met gemalen, voor Rijkswaterstaat, en voor gemeenten met tunnels, bruggen of sluizen betekent dat: de monitoring van industriële systemen valt binnen de scope van je normenkader. Hoe je monitoring in industriële omgevingen inricht zonder je OT-netwerk open te zetten, lees je in ons artikel over het Purdue-model.

Leveranciersbeheer: je blijft zelf verantwoordelijk

BIO2 scherpt de eisen aan voor uitbesteding en toezicht op derden, en de eindverantwoordelijkheid blijft waar die was: bij jouw organisatie. Uitbesteden mag dus prima, verantwoording uitbesteden niet.

Praktisch betekent dat: kies een partner die het bewijs levert dat jij nodig hebt voor je verantwoording. Denk aan gecontroleerde, auditable toegang tot je omgeving en vaste rapportages over wat er is gedaan en wat het opleverde. Bij onze Managed Services zijn auditable toegang en transparante rapportage daarom standaard onderdeel van de dienst, geen optie. De actuele versie van de baseline en het ondersteuningsmateriaal vind je op bio-overheid.nl.

Veelgestelde vragen

• Mag ik onder BIO2 mijn beheer uitbesteden?
• Wat is er veranderd ten opzichte van BIO 1.04?
• Geldt BIO2 al voor gemeenten?
• Wat is BIO2?

Op 15 augustus 2026 treedt de Cyberbeveiligingswet in werking, de Nederlandse implementatie van NIS2. De Eerste Kamer stemde op 7 juli in, geen stip op de horizon meer, maar een datum in je agenda. Dit artikel gaat over één onderdeel: logging en monitoring. Welke bronnen je op orde moet hebben, wat de wet wel en niet zegt over bewaartermijnen, en hoe je aantoont dat het werkt. Of jouw organisatie onder de wet valt, lees je in onze pijlerblog over de Cyber Security Assessment-keten

Wat de wet wel zegt over logging, en wat niet

NIS2 noemt logging in artikel 21 als onderdeel van de zorgplicht: maatregelen om incidenten te detecteren en af te handelen, inclusief registratie van gebeurtenissen. Een bewaartermijn schrijft de wet niet voor: nergens staat zes maanden, nergens twee jaar. Ook het Cyberbeveiligingsbesluit en de ministeriële regelingen per sector geven op dit moment geen vaste termijn voor alle logdata.

Iedere partij die je nu een hard getal belooft, verzint dat getal. Wat de wet wel vraagt: dat je incidenten kunt detecteren, onderzoeken en op tijd melden, en daar kun je je termijnen op bouwen.

Checklist: de negen logbronnen die je op orde moet hebben

1. Authenticatie en autorisatie. Wie logt waar in, en waar mislukt dat opvallend vaak? Dit is de bron waar vrijwel elk onderzoek begint.
2. Netwerkverkeer op de perimeter. Firewall, VPN en proxy laten zien wat er de organisatie in en uit gaat.
3. Endpoint-detectie. EDR-telemetrie van werkplekken en servers, waar de meeste aanvallen zichtbaar worden.
4. Configuratiewijzigingen. Wie zette welke regel uit, en wanneer? Zonder deze bron is elk incidentonderzoek giswerk.
5. Privileged sessies. Beheerdersaccounts en service-accounts kunnen het meest, dus verdienen het meeste zicht.
6. Het cloud control plane. AWS CloudTrail, Azure Activity Log en vergelijkbare audit-logs: wie deed wat met je cloudomgeving zelf.
7. Back-up en restore. Draaide de back-up, en is een restore ooit echt getest? Bij ransomware is dit de bron die telt.
8. OT-assets, indien van toepassing. Industriële systemen vallen ook onder je zorgplicht; beschikbaarheid en afwijkend gedrag zijn daar de signalen.
9. De logging van je logging. De gezondheid van je logpijplijn zelf: welke bron is stilgevallen, waar loopt vertraging op? Vrijwel iedereen vergeet deze, en het is precies de bron waarmee je de andere acht bewaakt.

Hoe je bewaartermijnen bepaalt zonder dat de wet ze geeft

Bepaal de termijn per logbron, op basis van drie vragen: hoe lang duurt het voordat je een incident ontdekt, hoe lang heb je nodig om het te onderzoeken, en wat moet je kunnen melden? De meldplicht is streng: binnen 24 uur moet bij een significant incident een vroegtijdige waarschuwing de deur uit. En een aanvaller die vier maanden onopgemerkt binnen is, is geen uitzondering, bewaar je logs dertig dagen, dan valt er bij ontdekking niets meer te onderzoeken.

Lange termijnen hoeven niet duur te zijn: houd recente data hot (direct doorzoekbaar, prijzig) voor detectie en verhuis oudere data naar cold of archive storage (traag, goedkoop). Een pipeline-laag maakt dat onderscheid praktisch uitvoerbaar; hoe je zo je logvolume beheersbaar houdt, lees je in ons artikel over telemetry pipelines.

Aantoonbaarheid: opzet, bestaan en werking

Een toezichthouder vraagt niet óf je logt, maar of je kunt aantonen dat de maatregel is opgezet, bestaat en werkt. Drie woorden, drie artefacten.

• Opzet: een gedocumenteerde logstrategie. Welke bronnen, waarom, met welke termijn.
• Bestaan: bewijs dat de bronnen daadwerkelijk aanleveren, dus monitoring op de pijplijn zelf.
• Werking: periodieke rapportage die over een langere periode laat zien dat het geheel functioneert: dekking, uitval, opvolging.

Die derde is in de praktijk de lastigste, omdat je haar niet achteraf kunt reconstrueren. Bij SMT is dat daarom standaard onderdeel van elke Managed Service: vaste rapportage met KPI’s, trends en bevindingen, zodat het bewijs er ligt op het moment dat iemand erom vraagt.

Waar organisaties in de praktijk op stuklopen

1. Logbronnen die stilletjes stoppen met aanleveren. Een certificaat verloopt, een agent crasht, en niemand merkt het tot het onderzoek begint.
2. Tijdsynchronisatie die niet klopt. Loopt de klok van je firewall drie minuten voor op die van je servers, dan valt er niets meer te correleren.
3. Logvolume dat het budget opeet. Waarna bronnen worden uitgezet om kosten te drukken. Dat is de gevaarlijkste bezuiniging die er is: je bespaart op precies het zicht dat de wet van je vraagt.
4. Geen eigenaar. Logging is van iedereen een beetje en dus van niemand. Zonder eigenaar verzandt elke goede opzet binnen een jaar.

De derde valkuil is geen natuurwet: wie data filtert voordat die het dure platform bereikt, houdt volume en budget in de hand zonder bronnen op te offeren. De actuele stand van de wet vind je op ncsc.nl.

Veelgestelde vragen

• Val ik onder de Cyberbeveiligingswet?
• Hoe toon ik aan dat mijn logging werkt?
• Welke logbronnen heb ik minimaal nodig?
• Wanneer treedt de Cyberbeveiligingswet in werking?
• Hoe lang moet ik logs bewaren onder NIS2?

Het Purdue-model is een referentiearchitectuur die industriële netwerken opdeelt in gelaagde zones, van de fysieke procesbesturing op de werkvloer tot de bedrijfs-IT op kantoor. Per zone ligt vast welk verkeer erin en eruit mag, zodat een storing of aanval in de ene laag niet zomaar doordringt tot de volgende. Eerlijk is eerlijk: het model stamt uit een tijd waarin OT-netwerken echt gescheiden waren. Die aanname houdt niet meer, terwijl veel organisaties hun monitoring nog inrichten alsof de muren er nog staan.

Hieronder eerst het model, daarna waar het in de praktijk om draait: monitoringdata uit je OT-omgeving halen zonder die omgeving open te zetten.

Het Purdue-model in vijf niveaus

Het model telt zes lagen, van 0 tot en met 5. Hoe lager het niveau, hoe dichter op het fysieke proces en hoe zwaarder beschikbaarheid weegt.

Tussen niveau 3 en 4 zit in de praktijk nog niveau 3.5: de industriële DMZ, de plek waar IT en OT elkaar gecontroleerd raken, en waar je monitoringvraagstuk zich afspeelt.

Waarom de scheiding tussen IT en OT verdwijnt

Drie ontwikkelingen slopen de klassieke scheiding.

1. Cloudconnectiviteit voor remote support. Leveranciers kijken op afstand mee voor onderhoud en storingsanalyse, en elke supportverbinding is een pad dat het model nooit voorzien heeft.
2. Industriële IoT. Nieuwe sensoren praten rechtstreeks met een cloudplatform en slaan de lagen simpelweg over.
3. De vraag naar OT-data voor bedrijfsbeslissingen. Onderhoudsplanning, energieverbruik, beschikbaarheid: de antwoorden zitten in OT-data, maar de vragen worden op IT-niveau gesteld.

Dat dit geen nicheonderwerp meer is, zie je bij de overheid: de BIO2-communicatie van februari 2026 stond volledig in het teken van OT-security, en de Cybersecurity Implementatierichtlijn (CSIR) geldt daar als dé OT-norm. Wat dat betekent lees je in wat BIO2 vraagt van OT-omgevingen.

Data uit OT halen zonder je OT-netwerk te openen

Hier zit de technische kern: monitoringdata de ene kant op, zonder dat er ooit een verbinding de andere kant op gaat. Drie patronen, goed te combineren.

1. Unidirectionele gateways of datadiodes. Hardware die verkeer fysiek maar één richting op laat: data verlaat de OT-zone, niets kan terug. In omgevingen met hoge veiligheidseisen vaak het uitgangspunt.
2. Een collector in de DMZ (niveau 3.5). OT-systemen leveren hun data af bij een collector in de tussenlaag; de IT-zone haalt de data daar op. Een directe verbinding tussen beide werelden bestaat niet.
3. Een pipeline-laag die filtert, normaliseert en maskeert. Voordat data de IT-zone bereikt, bepaal je wat er doorheen mag en zonder welke gevoelige velden. Een lichte agent zoals Cribl Edge doet dat werk al dicht bij de bron; meer daarover op onze pagina over data filteren en routeren aan de bron.

Wat je wel en niet meet in een OT-omgeving

In OT gedraagt data zich precies omgekeerd aan IT: een laag volume en een hoge criticaliteit per gebeurtenis, waar IT-logs een hoog volume en een lage criticaliteit hebben. Eén afwijkende melding kan een pomp zijn die het begeeft.

Wel meten: asset-inventaris, protocolafwijkingen in bijvoorbeeld Modbus- of DNP3-verkeer, beschikbaarheid van kritieke assets en firmware-versies.

Niet meten: alles wat een IT-SIEM standaard binnenharkt. Detectieregels die in IT prima werken, produceren in OT vrijwel alleen ruis. Detectie bouw je hier op gedrag en afwijking, niet op volume.

In de praktijk: van tunnelbeheer naar voorspelbare beschikbaarheid

Vialis past dit toe op een tunnel in de A4, onder een start- en landingsbaan van een internationale luchthaven. Bestaande sensordata wordt via Cribl gefilterd en verrijkt, en in Splunk geanalyseerd op patronen die op slijtage wijzen: verhoogd stroomverbruik bij een pomp, oplopende temperaturen, afwijkend ventilatiegedrag. Webhooks starten vervolgacties, zoals het inplannen van onderhoud. Het resultaat is in de operatie duidelijk merkbaar: hogere tunnelbeschikbaarheid, minder ongeplande sluitingen en onderhoud op werkelijke conditie. Lees de volledige case study Vialis (pdf). Hoe je van meten naar onderhoudsbeslissingen komt, lees je in van preventief naar voorspelbaar onderhoud.

Het Purdue-model is niet dood; het is een denkmodel geworden in plaats van een bouwtekening. De grens verschuift naar de vraag welke data haar mag passeren, en wie dat heeft ingericht, wil het zo houden. Dat is het punt waarop het beheer van je monitoringplatform net zo belangrijk wordt als de architectuur zelf.

Veelgestelde vragen

• Wat is het verschil tussen OT-monitoring en IT-monitoring?
• Kun je OT-data monitoren zonder je OT-netwerk te openen?
• Is het Purdue-model nog relevant?

• Wat is het Purdue-model?

  Het Purdue-model is een referentiearchitectuur die industriële netwerken opdeelt in zones, van fysieke procesbesturing op niveau 0 tot bedrijfs-IT op niveau 4 en 5, zodat duidelijk is welk verkeer tussen welke zones is toegestaan.

Alert fatigue is de afstomping die ontstaat wanneer analisten zoveel meldingen krijgen dat ze echte signalen missen. Wie tweehonderd keer per dienst op “close” klikt, klikt op een dag ook de melding weg die ertoe deed. De stelling die dit artikel draagt: alert fatigue is zelden een mensenprobleem en bijna altijd een datakwaliteitsprobleem.

Waar de ruis vandaan komt

1. Regels uit een standaardpakket, nooit aangepast aan de eigen omgeving. De content-packs van je SIEM zijn geschreven voor een gemiddelde organisatie die niet bestaat. Een regel die elders scherp is, loeit bij jou de hele dag.
2. Ontbrekende context. Een beheerder die om 02:00 uur inlogt: verdacht, tenzij het de geplande patchronde is. Zonder wijzigingskalender en asseteigenaar in de melding ziet de analist dat verschil niet, dus onderzoekt hij het. Elke keer weer.
3. Dubbele detecties op verschillende lagen. EDR, firewall en SIEM melden hetzelfde event, elk in eigen bewoording. Eén gebeurtenis, drie tickets.
4. Regels die niemand meer durft uit te zetten. Niemand weet waarom ze bestaan, dus laat iedereen ze staan. Voor de zekerheid. De eerlijkste oorzaak op dit lijstje, en de meest voorkomende.

Wat is detection engineering?

Detection engineering is het behandelen van detectieregels als een product met een levenscyclus, niet als een project dat ooit af is. Elke regel heeft een eigenaar, een doel en een houdbaarheidsdatum. Vijf fasen:

1. Ontwerpen. Welke techniek of welk risico wil je zien, en welke data heb je daarvoor nodig? Eigenaar: de detection engineer.
2. Bouwen. De regel schrijven, met context (assetwaarde, eigenaar) er meteen bij.
3. Testen. Tegen historische data en gesimuleerde aanvallen, voordat de regel live gaat. Eigenaar: engineer plus analist.
4. Afstemmen. De false positive ratio per regel volgen en bijsturen. Eigenaar: de analisten die de meldingen zien; doorlopend, met een vast maandelijks moment.
5. Uitfaseren. Regels die niets meer opleveren gedocumenteerd uitzetten, elk kwartaal. Vrijwel niemand doet deze fase, en het is precies de fase die oorzaak vier hierboven voorkomt.

Meten voordat je tunet

Vier meetwaarden volstaan om te weten waar je staat:

• Meldingen per analist per dienst. De directe maat voor werkdruk.
• False positive ratio per regel. Niet per omgeving, maar per regel, anders weet je nooit welke regel het probleem is.
• Mean time to triage. Hoe lang duurt het voordat iemand een melding heeft beoordeeld?
• Aandeel meldingen dat tot actie leidt. De hardste maat voor signaalwaarde.

Zonder nulmeting kun je na drie maanden tunen niet aantonen dat het hielp, en dan verdwijnt het budget. Streefcijfers geven we bewust niet: die verschillen per omgeving, en wie je er toch een noemt, kent jouw omgeving niet.

Vier maatregelen die het volume echt verlagen

1. Verrijk meldingen met context voordat ze bij een analist landen. Assetwaarde, eigenaar, wijzigingsvenster. De melding “inlog op srv-db-03 (kroonjuweel, eigenaar team Betalingen, geen gepland werk)” triageert zichzelf half.
2. Onderdruk meldingen tijdens geplande wijzigingen. Een patchnacht met vierhonderd meldingen leert analisten precies één ding: negeren.
3. Groepeer verwante meldingen tot één incident. Tien signalen van één aanvalspad horen in één dossier, niet in tien tickets. Waar AI wel en niet helpt bij ruisreductie, lees je in ons artikel over AIOps.
4. Verwijder data zonder detectiewaarde voordat die je SIEM in gaat. Debug-logging en heartbeats voeden geen enkele detectie, maar vervuilen wel elke zoekopdracht. Hoe je data filtert voordat die je SIEM in gaat, lees je in ons artikel over telemetry pipelines.

Een dashboard per component vertelt je hoe de database en de applicatieserver zich voelen, maar niet of de dienst het doet. Groene lampjes en toch klachten, iedereen in operations kent dat gesprek. Service-gebaseerde monitoring draait het om: je koppelt technische signalen aan een bedrijfsproces, zoals “bestelling plaatsen” of “brug bedienen”, en bewaakt dat. In de Splunk-wereld is dit het domein van Splunk Observability Cloud en ITSI.

Dekking meten met MITRE ATT&CK

Als de ruis afneemt, komt de volgende vraag: zien we wel de juiste dingen? Het MITRE ATT&CK-framework beschrijft de technieken die aanvallers daadwerkelijk gebruiken. Koppel je detecties daaraan, en het gesprek verandert van “hoeveel regels hebben we” in “welke technieken zien we, en welke niet”, het enige gesprek dat je risico verkleint.

Eén waarschuwing: dekking najagen om de dekking is de nieuwe valkuil. Dek de technieken die voor jouw omgeving en dreigingsbeeld tellen, en dek die goed.

Detection engineering vraagt om ritme: elke dag kijken, elke maand afstemmen, elk kwartaal opruimen. Dat ritme organiseren wij met 24/7 checks door een team in plaats van een persoon. Speelt de vraag of je dit zelf wilt doen, lees dan ons artikel over welk servicemodel bij je past.

Veelgestelde vragen

• Wat meet ik om te weten of tuning werkt?
• Hoe verlaag ik het aantal false positives?
• Wat is detection engineering?
• Wat is alert fatigue?

Monitoring meet vooraf bepaalde signalen en waarschuwt als een drempelwaarde wordt overschreden. Observability is het vermogen om de toestand van een systeem te begrijpen op basis van de data die het uitzendt, ook bij problemen die je niet had voorzien. Anders gezegd: monitoring vertelt je dát er iets mis is, observability helpt je begrijpen waaróm. De twee termen worden voortdurend door elkaar gebruikt, en dat kost organisaties geld: wie observability koopt voor een monitoringprobleem betaalt te veel, en wie monitoring inzet voor een observabilityprobleem blijft zoeken.

Het verschil in een tabel

De kern zit in die tweede rij. Monitoring bewaakt wat je vooraf kon bedenken. Observability geeft je de mogelijkheid om vragen te stellen die je pas bedenkt op het moment dat het misgaat.

The three pillars of observability: logs, metrics en traces

Logs vertellen wat er gebeurde: een foutmelding met stacktrace, een geweigerde inlogpoging, een time-out met de exacte parameters erbij. Ze zijn rijk aan detail, maar duur in volume.

Metrics vertellen hoeveel en hoe vaak: responstijden, foutpercentages, wachtrijlengtes. Compact, goedkoop, ideaal voor trends en alerts, maar zonder het verhaal erachter.

Traces vertellen waar in de keten het gebeurde: het pad van één verzoek langs alle services, met per stap de tijd die het kostte. Onmisbaar zodra één klik door tien systemen gaat.

En dan het eerlijke voorbehoud: de drie pijlers zijn een nuttig model, geen doel. Veel organisaties verzamelen keurig alle drie, in drie losse tools, zonder ze ooit te correleren. Dan heb je drie keer opslagkosten en nul keer inzicht. De waarde ontstaat pas als je vanuit een metric-piek kunt doorklikken naar de bijbehorende trace en logs.

Wanneer monitoring genoeg is

Nu de vraag die leveranciers liever overslaan: heb je observability nodig? Voor een stabiele, monolithische omgeving met bekende faalmodi is klassieke monitoring goedkoper en effectiever. Drie criteria om te beslissen:

1. Architectuur. Draait alles op een handvol servers, of is je landschap gedistribueerd over tientallen services en cloudcomponenten?
2. Vraagpatroon. Stel je bij incidenten steeds dezelfde vragen, of steeds nieuwe? Zodra elke storing een unieke puzzel is, schiet vooraf bedachte monitoring tekort.
3. Veranderingstempo. Wie wekelijks deployt, creëert wekelijks nieuwe manieren om te falen. Hoe sneller je omgeving verandert, hoe minder je vooraf kunt bedenken.

Scoor je op alle drie laag, houd het dan simpel en investeer je budget ergens anders in. Dat advies levert ons niets op, maar het klopt wel.

Van dashboards naar service-inzicht

Een dashboard per component vertelt je hoe de database en de applicatieserver zich voelen, maar niet of de dienst het doet. Groene lampjes en toch klachten, iedereen in operations kent dat gesprek. Service-gebaseerde monitoring draait het om: je koppelt technische signalen aan een bedrijfsproces, zoals “bestelling plaatsen” of “brug bedienen”, en bewaakt dat. In de Splunk-wereld is dit het domein van Splunk Observability Cloud en ITSI.

Wat je nodig hebt om te beginnen

1. Inventariseer welke data je al uitzendt. Applicaties, infrastructuur, cloudplatformen: het meeste is er al.
2. Zorg voor consistente tijdstempels en identifiers over bronnen heen. Zonder gedeelde sleutels valt er niets te correleren; hoe je consistente data over bronnen heen aan de bron regelt, lees je in ons artikel over telemetry pipelines.
3. Definieer wat een dienst is en welke componenten eronder vallen. Dit is een gesprek met de business, geen technische exercitie.
4. Begin met één dienst. Bewijs de waarde daar, en breid daarna pas uit.

Staat deze basis, kijk dan verder naar wat AI hieraan toevoegt. En wie het platform liever niet zelf scherp houdt: het beheer en de optimalisatie van je platform is precies wat wij als Managed Service doen.

Veelgestelde vragen

• Is observability hetzelfde als een SIEM?

  Nee. Observability richt zich op de gezondheid en prestaties van diensten, een SIEM op detectie van beveiligingsincidenten. Ze delen vaak dezelfde databronnen, maar beantwoorden andere vragen.

• Wanneer is monitoring genoeg?
• Wat zijn de three pillars of observability?

  Logs (wat er gebeurde), metrics (hoeveel en hoe vaak) en traces (waar in de keten). Het is een nuttig model, geen doel. Veel organisaties verzamelen alle drie zonder ze te correleren, en daar gaat het mis.

• Wat is het verschil tussen observability en monitoring?

  Monitoring meet vooraf bepaalde signalen en waarschuwt bij overschrijding van een drempelwaarde. Observability is het vermogen om de toestand van een systeem te begrijpen uit de data die het uitzendt, ook bij problemen die je niet had voorzien.

Een Splunk-architectuur is een verzameling gespecialiseerde componenten die data ontvangen, indexeren, doorzoeken en beheren, waarbij clustering zorgt voor beschikbaarheid en schaalbaarheid. Wie de rolverdeling en de twee clustervormen begrijpt, weet waar zijn eigen omgeving kwetsbaar is. Dit stuk is voor Splunk-engineers en -admins, we sparen het jargon niet.

De componenten op een rij

De Splunk-documentatie vertelt wat elk component doet, niet wat er gebeurt als het uitvalt. En juist met die kolom beoordeel je je architectuur.

Indexer clustering: replication factor en search factor

Twee getallen bepalen het gedrag van je indexer cluster: de replication factor (RF) bepaalt hoeveel kopieën van de ruwe data het cluster bewaart, de search factor (SF) hoeveel daarvan ook doorzoekbaar zijn, inclusief tsidx-indexbestanden.

Concreet, met RF3 en SF2: elke bucket bestaat drie keer als ruwe data, waarvan twee direct doorzoekbaar. Valt één indexer uit, dan is er geen dataverlies en blijft zoeken mogelijk, terwijl de cluster manager via fixup de aantallen herstelt. Opslag: drie keer de gecomprimeerde ruwe data plus twee keer de indexbestanden.

De klassieke fout: SF gelijkstellen aan RF “omdat het veiliger klinkt”. Dat levert zelden extra weerbaarheid op, maar wel een extra complete set tsidx-bestanden, je opslagverbruik schiet omhoog zonder dat je er iets voor terugkrijgt. Verhoog SF alleen met een concreet herstelscenario waarin die extra doorzoekbare kopie het verschil maakt.

Search head clustering en captain election

Een search head cluster kiest uit zijn leden een captain: die verdeelt scheduled searches, coördineert de replicatie van knowledge objects (dashboards, saved searches, lookups) en bewaakt de clusterstaat. Valt de captain weg, dan kiezen de overgebleven leden een nieuwe, mits ze met een meerderheid zijn.

Dat meerderheidsvereiste verklaart twee vuistregels. Drie search heads is het minimum, want bij twee is elke uitval meteen het einde van de meerderheid. En een even aantal is een slecht idee: splitst een netwerkpartitie een cluster van vier in tweeën, dan heeft geen van beide helften een meerderheid en liggen scheduled searches en replicatie stil terwijl alle machines gewoon aanstaan.

Vijf fouten die we het vaakst tegenkomen

Met meer dan 500 implementaties achter de rug zien we dezelfde fouten terugkomen. De vijf hardnekkigste:

1. 1. Search factor gelijk aan replication factor, zonder reden. Zie hierboven: veel opslag, weinig winst.
   2. Een monitoring console die zelf niet gemonitord wordt. Het systeem dat alles bewaakt, wordt door niets bewaakt. Valt het stil, dan merkt per definitie niemand dat.
   3. Knowledge objects lokaal op één search head in plaats van in het cluster. Alles werkt, tot die ene search head uitvalt en de dashboards van een heel team nergens anders blijken te bestaan.
   4. Forwarders die zonder load balancing naar één vaste indexer praten. Eén indexer eruit betekent meteen datagaten, en de load in het cluster is structureel scheef.
   5. Een deployment server die te veel clients bedient. Duizenden forwarders op één onderbemeten machine: configuratie-updates druppelen dagenlang binnen, of komen nooit aan.

Wat je periodiek zou moeten controleren

Wil je dit één keer grondig laten doorlichten, dan is de Splunk Health Check de kortste route. Structureler kan ook: Splunk-beheer uitbesteden betekent dat deze controles elke dag gebeuren, door een team in plaats van die ene collega. Hoe je daarna van dashboards naar service-inzicht komt, en waarom omgevingen hun heavy forwarders vervangen door een pipeline-laag, lees je in de vervolgblogs. Twijfel je tussen platformen, lees dan welk platform bij je past.

Veelgestelde vragen

• Wat controleer je periodiek in een Splunk-omgeving?
• Hoeveel search heads heb ik minimaal nodig voor een cluster?
• Hoe zorgen we ervoor dat een investering in Splunk rendabel blijft naarmate onze data groeit?
• We gebruiken al meerdere monitoring- en securitytools. Wat voegt Splunk dan nog toe?
• Hoe helpt Splunk ons om sneller inzicht te krijgen in problemen voordat ze impact hebben op de business?

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

1. 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.
2. Verrijken. Voeg context toe terwijl de data onderweg is: assetwaarde, eigenaar, omgeving. Een verrijkte melding hoeft een analist niet meer op te zoeken.
3. Routeren. Stuur elke stroom naar de goedkoopste bestemming die nog voldoet: detectiewaardige data naar het SIEM, compliance-data rechtstreeks naar goedkope object storage.
4. 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

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

1. Meet je huidige volume per bron. Niet het totaal, maar per bron, daar zitten de verrassingen.
2. Bepaal per bron de detectie- en compliancewaarde. Welke detecties draaien erop, welke bewaarplicht geldt? Data zonder antwoord op beide vragen is je eerste kandidaat.
3. 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.
4. Verleg één bron en vergelijk. Zelfde detecties, zelfde dashboards, minder volume? Dan werkt het aantoonbaar.
5. 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.

Veelgestelde vragen

• Hoeveel logvolume kan ik besparen met een pipeline?

  Dat verschilt per omgeving en vooral per bron. Ter indicatie uit de praktijk: bij PostNL daalde het ingest-volume van AWS CloudTrail met 40 procent, waar vooraf 30 procent was verwacht.

• Wat is het verschil tussen Cribl Stream en Cribl Edge?

  Stream is de centrale verwerkingslaag, Edge een lichte agent die dicht bij de bron draait. Edge is relevant voor OT-omgevingen en verre locaties waar je bandbreedte wilt sparen of data niet ongefilterd wilt versturen.

• Wat doet Cribl Stream precies?

  Cribl Stream verwerkt datastromen centraal: het filtert wat geen waarde heeft, verrijkt met context, routeert naar de juiste bestemming en maskeert gevoelige velden. Zo verlaag je volume en kosten zonder detectiedekking op te geven.

• Wat is een telemetry pipeline?

  Een telemetry pipeline is een tussenlaag tussen je databronnen en je analyse- of securityplatformen die bepaalt wat waarheen gaat: filteren, verrijken, routeren en maskeren, voordat de data zijn bestemming bereikt.

Voorspellend onderhoud betekent onderhoud plannen op basis van de werkelijke conditie en het gedrag van een asset, in plaats van op een vaste kalender. Internationaal heet het predictive maintenance, en het steunt op data die de asset en de systemen eromheen vaak al produceren. Daarmee is meteen gezegd wat dit artikel anders maakt dan de meeste stukken over dit onderwerp: het gaat niet over een onderhoudspakket aanschaffen, maar over de data die je al hebt en wat daarvoor nodig is.

Drie vormen van onderhoud, en wat ze kosten

En nu het eerlijke verhaal: voor veel assets is preventief onderhoud gewoon prima. Een vast interval voor iets goedkoops dat zelden faalt, hoef je niet slimmer te maken. Voorspellend onderhoud loont bij assets waar uitval duur of gevaarlijk is: de tunnel, de terminal, het gemaal.

Welke data je nodig hebt (en waarschijnlijk al hebt)

Vier bronnen vormen samen het beeld.

1. Sensordata uit de asset zelf. Stroomverbruik, temperatuur, trilling, druk: de signalen die slijtage verraden.
2. Logdata uit de besturingssystemen. PLC’s en SCADA registreren schakelmomenten, foutcodes en afwijkingen die je in sensordata alleen niet ziet.
3. Netwerktelemetrie. Een installatie die hapert, kondigt zich op het netwerk vaak eerder aan dan in het proces.
4. De storingshistorie uit je onderhoudssysteem. Wat ging er eerder kapot, wanneer, en wat ging eraan vooraf? Dit is je referentiemateriaal.

De eerste drie komen meestal al ergens langs, alleen in verschillende systemen met verschillende tijdstempels. Het werk zit niet in het voorspellen, maar in het samenbrengen, en in de vraag hoe je die data veilig uit je OT-omgeving haalt.

Waarom predictive maintenance zelden op het model stukloopt

De meeste voorspellend-onderhoudsprojecten stranden niet op het algoritme. Ze stranden op datakwaliteit, en wel op drie voorspelbare manieren.

1. Te weinig storingshistorie om op te trainen. Kritieke assets falen gelukkig zelden, dus zijn er weinig voorbeelden van hoe falen eruitziet.
2. Tijdstempels die niet synchroon lopen. Als de sensor, de PLC en het onderhoudssysteem elk hun eigen klok hanteren, kun je oorzaak en gevolg niet meer op één tijdlijn leggen.
3. Assets die pas gaan loggen als er al iets mis is. Foutcodes zijn geen conditiedata. Je wilt weten hoe gezond gedrag eruitziet, niet alleen hoe kapot eruitziet.

Onze ervaring, zonder omwegen: met een half jaar goede data kom je verder dan met een geavanceerd model op vuile data. Begin dus bij de data, niet bij het algoritme.

In de praktijk: tunnels en terminals

Vialis past dit toe op een tunnel in de A4. Sensordata wordt via Cribl gefilterd en verrijkt, en in Splunk geanalyseerd op patronen die op slijtage wijzen; webhooks starten vervolgacties zoals het inplannen van onderhoud. Het effect: hogere tunnelbeschikbaarheid, minder ongeplande sluitingen en onderhoud op werkelijke conditie. Lees de case study Vialis (pdf).

Bij Rotterdam World Gateway (RWG), een van de meest geautomatiseerde containerterminals ter wereld, zat het probleem niet in een gebrek aan data maar aan zichtbaarheid: data lag verspreid over logsystemen, applicaties, leverancierssystemen en OT. Door die stromen in Splunk te correleren ging de start van een probleemanalyse van uren naar minuten en veranderde stilstand van verrassing in beheersing. Lees de case study RWG (pdf).

Een realistisch stappenplan

1. Kies een asset waar uitval echt pijn doet. Niet de makkelijkste, maar de duurste storing van vorig jaar.
2. Inventariseer welke data die asset nu al produceert. Sensoren, besturing, netwerk, onderhoudssysteem, meestal meer dan je denkt.
3. Breng die data samen op één tijdlijn. Zelfde klok, zelfde identifiers. Dit is tachtig procent van het werk.
4. Leg de storingshistorie ernaast en zoek patronen met het blote oog. Wat zag je in de dagen voor elke storing? Vaak springt het patroon eruit zonder code.
5. Automatiseer pas als je het patroon zelf herkent. Een model moet bevestigen wat jij al snapt. Dit advies krijg je van softwareleveranciers niet, en het scheelt je een mislukt project.

Voorspellend onderhoud is geen product dat je koopt, maar een werkwijze die je opbouwt, en die valt of staat met de continuïteit van kritieke systemen eronder. Voor de servicelaag daarboven is ITSI en service-monitoring het gereedschap.

Veelgestelde vragen

• Waarom mislukken predictive maintenance-projecten?
• Heb ik speciale software nodig voor predictive maintenance?
• Wat is voorspellend onderhoud?

AIOps is het toepassen van machine learning en statistische analyse op operationele data: om afwijkingen te vinden, meldingen te correleren en problemen te voorspellen voordat ze uitval worden. Tot zover de definitie die je overal leest. Dit artikel doet iets wat de meeste stukken over AIOps overslaan: het beschrijft ook wat AIOps niet oplost. Die kant hoor je zelden van partijen die het verkopen, en het is precies de kant die bepaalt of jouw investering iets oplevert.

De vier dingen die AIOps daadwerkelijk goed doet

1. Anomaliedetectie op tijdreeksen. Een statische drempel zegt: alarm boven 80 procent. Een model leert dat 70 procent op dinsdagochtend normaal is en op zondagnacht niet, en slaat dus eerder én preciezer aan. In de Splunk-stack is dit het domein van de Machine Learning Toolkit.
2. Correlatie van meldingen naar één incident. Storage-latency, database-timeouts en applicatiefouten zijn geen drie problemen; het is één probleem met drie gezichten. Splunk ITSI groepeert die signalen tot één episode.
3. Ruisreductie. Dezelfde melding die elke vijf minuten terugkomt, wordt één melding met een teller. Klinkt banaal, scheelt in de praktijk het meeste geklik.
4. Capaciteitsvoorspelling. Op basis van trends zie je dat een schijf over drie weken volloopt, in plaats van vannacht om drie uur, dat verplaatst werk van paniek naar planning.

Waar dit in de praktijk zit: de Splunk Machine Learning Toolkit en ITSI voor respectievelijk de modellen en de servicecorrelatie.

De drie dingen die AIOps niet oplost

1. AIOps repareert geen vuile data. Een model op inconsistente logs geeft zelfverzekerde onzin. Ontbrekende velden, dubbele bronnen en klokken die uit elkaar lopen worden niet weggemodelleerd; ze worden versterkt.
2. AIOps vervangt geen engineer. Het model wijst aan waar je moet kijken, niet waarom het misgaat in jouw architectuur, welke workaround uit 2021 nog ergens draait, of welke afhankelijkheid nooit is gedocumenteerd. Het verkort de zoektijd; de diagnose blijft mensenwerk.
3. AIOps lost geen procesprobleem op. Als niemand eigenaar is van een alert, verandert een slimmer alert daar niets aan. Het wordt alleen sneller genegeerd.

Vandaar ons uitgangspunt: niet de hype volgen, maar wat werkt in jouw landschap. Meer alerts zijn zelden het antwoord, waarom dat zo is, lees je in ons artikel over waarom meer alerts niet helpen.

Van chaos naar controle: een voorbeeld

Hoe dit uitpakt als de voorwaarden op orde zijn, beschrijft onze use case over Splunk AI. De uitgangssituatie is herkenbaar: miljoenen signalen per seconde uit IT en OT, meldingen die zich opstapelen, teams die tijd verliezen aan vals alarm. Door logdata samen te brengen in Splunk, machine learning afwijkingen te laten herkennen die met vaste regels onzichtbaar blijven, en verdachte gebeurtenissen automatisch naar het juiste team te routeren, veranderde dat beeld. Het resultaat uit de use case: 75 procent minder valse meldingen, snellere detectie van echte dreigingen en één platform waar IT- en OT-teams samen mee werken. De volledige use case Splunk AI (pdf) lees je in ons downloadcentrum.

Hoe je AIOps stapsgewijs invoert

1. Kies één use case met een duidelijke eigenaar. Niet “alles slimmer maken”, maar bijvoorbeeld: eerder zien dat de orderverwerking hapert.
2. Doe een nulmeting. Aantal meldingen per week, mean time to detect. Zonder nulmeting valt succes niet te bewijzen.
3. Normaliseer de databronnen voor die ene use case. Niet je hele landschap; alleen wat deze detectie nodig heeft.
4. Laat het model meelopen zonder actie. Een paar weken schaduwdraaien laat zien of het model jouw normaal begrijpt.
5. Meet opnieuw en beslis op cijfers. Minder meldingen, snellere detectie? Uitbreiden. Zo niet: stoppen kost nu weinig, precies waarom je klein begon.

AIOps is geen wondermiddel; het is gereedschap dat rendeert zodra je data en je proces het toelaten. Dat zo houden vraagt om proactief beheer in plaats van reactief: iemand die modellen, bronnen en eigenaren scherp houdt.

Leveranciersbeheer: je blijft zelf verantwoordelijk

BIO2 scherpt de eisen aan voor uitbesteding en toezicht op derden, en de eindverantwoordelijkheid blijft waar die was: bij jouw organisatie. Uitbesteden mag dus prima, verantwoording uitbesteden niet.

Praktisch betekent dat: kies een partner die het bewijs levert dat jij nodig hebt voor je verantwoording. Denk aan gecontroleerde, auditable toegang tot je omgeving en vaste rapportages over wat er is gedaan en wat het opleverde. Bij onze Managed Services zijn auditable toegang en transparante rapportage daarom standaard onderdeel van de dienst, geen optie. De actuele versie van de baseline en het ondersteuningsmateriaal vind je op bio-overheid.nl.

Veelgestelde vragen

• Waar begin ik met AIOps?
• Wat heb ik nodig voordat AIOps werkt?
• Vervangt AIOps engineers?
• Wat is AIOps?

De Baseline Informatiebeveiliging Overheid 2 (BIO2) is het basisnormenkader voor informatiebeveiliging binnen alle overheidslagen: Rijk, gemeenten, provincies en waterschappen. Het kader is gebaseerd op ISO 27001 en 27002 en krijgt via de Cyberbeveiligingswet een wettelijke basis. Versie 1.3 is op 5 maart 2026 gepubliceerd in de Staatscourant, en dat is meer dan een administratieve mijlpaal: de ministeriële regeling onder de wet verwijst voor de zorgplicht van de sector Overheid rechtstreeks naar die publicatie. In dit artikel laten we de normteksten voor wat ze zijn en kijken we naar één vraag: wat betekent BIO2 concreet voor je logging, je monitoring en je rapportage?

Wat er verandert ten opzichte van BIO 1.04

Drie wijzigingen springen eruit.

Eén nuance die vrijwel nergens correct wordt opgeschreven: BIO2 v1.3 geldt sinds de publicatie als verplichtende zelfregulering voor het Rijk, provincies en waterschappen. Gemeenten werkten formeel nog met BIO 1.04, met BIO2 als richtinggevend kader, tot de inwerkingtreding van de Cyberbeveiligingswet op 15 augustus 2026. Vanaf dat moment loopt de verplichting voor alle bestuurslagen via de wet en de bijbehorende regeling.

Risicogestuurd werken betekent: je moet je risico kunnen zien

Het schrappen van de BBN-tabel klinkt als een detail, maar het verandert je werk fundamenteel: er valt niets meer af te vinken. Je moet per proces en informatiesysteem bepalen welk risico je loopt, en dat kan alleen met zicht op wat er in die systemen gebeurt. Zonder monitoring geen risicobeeld.

Neem een kritiek burgerproces: het uitbetalen van uitkeringen. Het risico zit zelden in de applicatie alleen, maar in de keten eromheen: de koppeling met de basisregistratie, de batchverwerking die ’s nachts draait, het service-account dat die batch uitvoert. Risicogestuurd werken betekent dat je die keten kunt zien: weet wanneer de batch niet draaide, wanneer het account buiten het venster inlogde, wanneer de koppeling haperde. Dat is geen beleidsvraag meer, dat is monitoring.

Opzet, bestaan en werking aantonen

BIO2 vraagt dat je van maatregelen de opzet, het bestaan en de werking kunt aantonen. Drie woorden, drie artefacten.

• Opzet: beleid en configuratie. Wat heb je bedacht en hoe is het ingericht?
• Bestaan: bewijs dat de maatregel actief is. Niet het beleidsdocument, maar de draaiende regel, de aanleverende logbron.
• Werking: meetgegevens over een langere periode. Deed de maatregel wat hij moest doen, ook in maart, ook in de vakantieperiode?

De derde is de moeilijkste, want werking kun je niet met terugwerkende kracht verzinnen. Je krijgt haar alleen uit continue monitoring en periodieke rapportage die je al die tijd hebt laten lopen. Wie daar pas bij de eerste audit aan begint, is per definitie te laat.

OT valt er ook onder

Een punt dat makkelijk wordt gemist: de BIO2-communicatie van februari 2026 stond volledig in het teken van OT-security, en de Cybersecurity Implementatierichtlijn (CSIR) is binnen de overheid de implementatierichtlijn voor industriële omgevingen. Voor waterschappen met gemalen, voor Rijkswaterstaat, en voor gemeenten met tunnels, bruggen of sluizen betekent dat: de monitoring van industriële systemen valt binnen de scope van je normenkader. Hoe je monitoring in industriële omgevingen inricht zonder je OT-netwerk open te zetten, lees je in ons artikel over het Purdue-model.

Leveranciersbeheer: je blijft zelf verantwoordelijk

BIO2 scherpt de eisen aan voor uitbesteding en toezicht op derden, en de eindverantwoordelijkheid blijft waar die was: bij jouw organisatie. Uitbesteden mag dus prima, verantwoording uitbesteden niet.

Praktisch betekent dat: kies een partner die het bewijs levert dat jij nodig hebt voor je verantwoording. Denk aan gecontroleerde, auditable toegang tot je omgeving en vaste rapportages over wat er is gedaan en wat het opleverde. Bij onze Managed Services zijn auditable toegang en transparante rapportage daarom standaard onderdeel van de dienst, geen optie. De actuele versie van de baseline en het ondersteuningsmateriaal vind je op bio-overheid.nl.

Veelgestelde vragen

• Mag ik onder BIO2 mijn beheer uitbesteden?
• Wat is er veranderd ten opzichte van BIO 1.04?
• Geldt BIO2 al voor gemeenten?
• Wat is BIO2?

Op 15 augustus 2026 treedt de Cyberbeveiligingswet in werking, de Nederlandse implementatie van NIS2. De Eerste Kamer stemde op 7 juli in, geen stip op de horizon meer, maar een datum in je agenda. Dit artikel gaat over één onderdeel: logging en monitoring. Welke bronnen je op orde moet hebben, wat de wet wel en niet zegt over bewaartermijnen, en hoe je aantoont dat het werkt. Of jouw organisatie onder de wet valt, lees je in onze pijlerblog over de Cyber Security Assessment-keten

Wat de wet wel zegt over logging, en wat niet

NIS2 noemt logging in artikel 21 als onderdeel van de zorgplicht: maatregelen om incidenten te detecteren en af te handelen, inclusief registratie van gebeurtenissen. Een bewaartermijn schrijft de wet niet voor: nergens staat zes maanden, nergens twee jaar. Ook het Cyberbeveiligingsbesluit en de ministeriële regelingen per sector geven op dit moment geen vaste termijn voor alle logdata.

Iedere partij die je nu een hard getal belooft, verzint dat getal. Wat de wet wel vraagt: dat je incidenten kunt detecteren, onderzoeken en op tijd melden, en daar kun je je termijnen op bouwen.

Checklist: de negen logbronnen die je op orde moet hebben

1. Authenticatie en autorisatie. Wie logt waar in, en waar mislukt dat opvallend vaak? Dit is de bron waar vrijwel elk onderzoek begint.
2. Netwerkverkeer op de perimeter. Firewall, VPN en proxy laten zien wat er de organisatie in en uit gaat.
3. Endpoint-detectie. EDR-telemetrie van werkplekken en servers, waar de meeste aanvallen zichtbaar worden.
4. Configuratiewijzigingen. Wie zette welke regel uit, en wanneer? Zonder deze bron is elk incidentonderzoek giswerk.
5. Privileged sessies. Beheerdersaccounts en service-accounts kunnen het meest, dus verdienen het meeste zicht.
6. Het cloud control plane. AWS CloudTrail, Azure Activity Log en vergelijkbare audit-logs: wie deed wat met je cloudomgeving zelf.
7. Back-up en restore. Draaide de back-up, en is een restore ooit echt getest? Bij ransomware is dit de bron die telt.
8. OT-assets, indien van toepassing. Industriële systemen vallen ook onder je zorgplicht; beschikbaarheid en afwijkend gedrag zijn daar de signalen.
9. De logging van je logging. De gezondheid van je logpijplijn zelf: welke bron is stilgevallen, waar loopt vertraging op? Vrijwel iedereen vergeet deze, en het is precies de bron waarmee je de andere acht bewaakt.

Hoe je bewaartermijnen bepaalt zonder dat de wet ze geeft

Bepaal de termijn per logbron, op basis van drie vragen: hoe lang duurt het voordat je een incident ontdekt, hoe lang heb je nodig om het te onderzoeken, en wat moet je kunnen melden? De meldplicht is streng: binnen 24 uur moet bij een significant incident een vroegtijdige waarschuwing de deur uit. En een aanvaller die vier maanden onopgemerkt binnen is, is geen uitzondering, bewaar je logs dertig dagen, dan valt er bij ontdekking niets meer te onderzoeken.

Lange termijnen hoeven niet duur te zijn: houd recente data hot (direct doorzoekbaar, prijzig) voor detectie en verhuis oudere data naar cold of archive storage (traag, goedkoop). Een pipeline-laag maakt dat onderscheid praktisch uitvoerbaar; hoe je zo je logvolume beheersbaar houdt, lees je in ons artikel over telemetry pipelines.

Aantoonbaarheid: opzet, bestaan en werking

Een toezichthouder vraagt niet óf je logt, maar of je kunt aantonen dat de maatregel is opgezet, bestaat en werkt. Drie woorden, drie artefacten.

• Opzet: een gedocumenteerde logstrategie. Welke bronnen, waarom, met welke termijn.
• Bestaan: bewijs dat de bronnen daadwerkelijk aanleveren, dus monitoring op de pijplijn zelf.
• Werking: periodieke rapportage die over een langere periode laat zien dat het geheel functioneert: dekking, uitval, opvolging.

Die derde is in de praktijk de lastigste, omdat je haar niet achteraf kunt reconstrueren. Bij SMT is dat daarom standaard onderdeel van elke Managed Service: vaste rapportage met KPI’s, trends en bevindingen, zodat het bewijs er ligt op het moment dat iemand erom vraagt.

Waar organisaties in de praktijk op stuklopen

1. Logbronnen die stilletjes stoppen met aanleveren. Een certificaat verloopt, een agent crasht, en niemand merkt het tot het onderzoek begint.
2. Tijdsynchronisatie die niet klopt. Loopt de klok van je firewall drie minuten voor op die van je servers, dan valt er niets meer te correleren.
3. Logvolume dat het budget opeet. Waarna bronnen worden uitgezet om kosten te drukken. Dat is de gevaarlijkste bezuiniging die er is: je bespaart op precies het zicht dat de wet van je vraagt.
4. Geen eigenaar. Logging is van iedereen een beetje en dus van niemand. Zonder eigenaar verzandt elke goede opzet binnen een jaar.

De derde valkuil is geen natuurwet: wie data filtert voordat die het dure platform bereikt, houdt volume en budget in de hand zonder bronnen op te offeren. De actuele stand van de wet vind je op ncsc.nl.

Veelgestelde vragen

• Val ik onder de Cyberbeveiligingswet?
• Hoe toon ik aan dat mijn logging werkt?
• Welke logbronnen heb ik minimaal nodig?
• Wanneer treedt de Cyberbeveiligingswet in werking?
• Hoe lang moet ik logs bewaren onder NIS2?

Het Purdue-model is een referentiearchitectuur die industriële netwerken opdeelt in gelaagde zones, van de fysieke procesbesturing op de werkvloer tot de bedrijfs-IT op kantoor. Per zone ligt vast welk verkeer erin en eruit mag, zodat een storing of aanval in de ene laag niet zomaar doordringt tot de volgende. Eerlijk is eerlijk: het model stamt uit een tijd waarin OT-netwerken echt gescheiden waren. Die aanname houdt niet meer, terwijl veel organisaties hun monitoring nog inrichten alsof de muren er nog staan.

Hieronder eerst het model, daarna waar het in de praktijk om draait: monitoringdata uit je OT-omgeving halen zonder die omgeving open te zetten.

Het Purdue-model in vijf niveaus

Het model telt zes lagen, van 0 tot en met 5. Hoe lager het niveau, hoe dichter op het fysieke proces en hoe zwaarder beschikbaarheid weegt.

Tussen niveau 3 en 4 zit in de praktijk nog niveau 3.5: de industriële DMZ, de plek waar IT en OT elkaar gecontroleerd raken, en waar je monitoringvraagstuk zich afspeelt.

Waarom de scheiding tussen IT en OT verdwijnt

Drie ontwikkelingen slopen de klassieke scheiding.

1. Cloudconnectiviteit voor remote support. Leveranciers kijken op afstand mee voor onderhoud en storingsanalyse, en elke supportverbinding is een pad dat het model nooit voorzien heeft.
2. Industriële IoT. Nieuwe sensoren praten rechtstreeks met een cloudplatform en slaan de lagen simpelweg over.
3. De vraag naar OT-data voor bedrijfsbeslissingen. Onderhoudsplanning, energieverbruik, beschikbaarheid: de antwoorden zitten in OT-data, maar de vragen worden op IT-niveau gesteld.

Dat dit geen nicheonderwerp meer is, zie je bij de overheid: de BIO2-communicatie van februari 2026 stond volledig in het teken van OT-security, en de Cybersecurity Implementatierichtlijn (CSIR) geldt daar als dé OT-norm. Wat dat betekent lees je in wat BIO2 vraagt van OT-omgevingen.

Data uit OT halen zonder je OT-netwerk te openen

Hier zit de technische kern: monitoringdata de ene kant op, zonder dat er ooit een verbinding de andere kant op gaat. Drie patronen, goed te combineren.

1. Unidirectionele gateways of datadiodes. Hardware die verkeer fysiek maar één richting op laat: data verlaat de OT-zone, niets kan terug. In omgevingen met hoge veiligheidseisen vaak het uitgangspunt.
2. Een collector in de DMZ (niveau 3.5). OT-systemen leveren hun data af bij een collector in de tussenlaag; de IT-zone haalt de data daar op. Een directe verbinding tussen beide werelden bestaat niet.
3. Een pipeline-laag die filtert, normaliseert en maskeert. Voordat data de IT-zone bereikt, bepaal je wat er doorheen mag en zonder welke gevoelige velden. Een lichte agent zoals Cribl Edge doet dat werk al dicht bij de bron; meer daarover op onze pagina over data filteren en routeren aan de bron.

Wat je wel en niet meet in een OT-omgeving

In OT gedraagt data zich precies omgekeerd aan IT: een laag volume en een hoge criticaliteit per gebeurtenis, waar IT-logs een hoog volume en een lage criticaliteit hebben. Eén afwijkende melding kan een pomp zijn die het begeeft.

Wel meten: asset-inventaris, protocolafwijkingen in bijvoorbeeld Modbus- of DNP3-verkeer, beschikbaarheid van kritieke assets en firmware-versies.

Niet meten: alles wat een IT-SIEM standaard binnenharkt. Detectieregels die in IT prima werken, produceren in OT vrijwel alleen ruis. Detectie bouw je hier op gedrag en afwijking, niet op volume.

In de praktijk: van tunnelbeheer naar voorspelbare beschikbaarheid

Vialis past dit toe op een tunnel in de A4, onder een start- en landingsbaan van een internationale luchthaven. Bestaande sensordata wordt via Cribl gefilterd en verrijkt, en in Splunk geanalyseerd op patronen die op slijtage wijzen: verhoogd stroomverbruik bij een pomp, oplopende temperaturen, afwijkend ventilatiegedrag. Webhooks starten vervolgacties, zoals het inplannen van onderhoud. Het resultaat is in de operatie duidelijk merkbaar: hogere tunnelbeschikbaarheid, minder ongeplande sluitingen en onderhoud op werkelijke conditie. Lees de volledige case study Vialis (pdf). Hoe je van meten naar onderhoudsbeslissingen komt, lees je in van preventief naar voorspelbaar onderhoud.

Het Purdue-model is niet dood; het is een denkmodel geworden in plaats van een bouwtekening. De grens verschuift naar de vraag welke data haar mag passeren, en wie dat heeft ingericht, wil het zo houden. Dat is het punt waarop het beheer van je monitoringplatform net zo belangrijk wordt als de architectuur zelf.

Veelgestelde vragen

• Wat is het verschil tussen OT-monitoring en IT-monitoring?
• Kun je OT-data monitoren zonder je OT-netwerk te openen?
• Is het Purdue-model nog relevant?

• Wat is het Purdue-model?

  Het Purdue-model is een referentiearchitectuur die industriële netwerken opdeelt in zones, van fysieke procesbesturing op niveau 0 tot bedrijfs-IT op niveau 4 en 5, zodat duidelijk is welk verkeer tussen welke zones is toegestaan.