Kennisbank

Logcorrelatie: hoe losse logregels samen een verhaal vertellen

Bijgewerkt: 15 oktober 2026 · 5 min leestijd

Elk computersysteem houdt een soort dagboek bij: een logbestand. Daarin staat bijvoorbeeld "gebruiker X heeft ingelogd om 14:03" of "server Y gaf een foutmelding om 14:04". Op zichzelf zegt zo'n regel weinig. Maar als je duizenden van die regels uit verschillende systemen naast elkaar legt en de verbanden erin herkent, ontstaat er een verhaal: wie deed wat, wanneer, en wat was het gevolg. Dat verbanden leggen tussen losse logregels heet logcorrelatie.

Vergelijk het met een rechercheur die getuigenverklaringen van verschillende mensen naast elkaar legt. De buurman zag een auto wegrijden om 23:10, de buurvrouw hoorde glasgerinkel om 23:08, en de alarmcentrale kreeg een melding om 23:09. Los van elkaar zijn dit drie onschuldige feitjes. Samen vormen ze het bewijs van een inbraak. Logcorrelatie doet precies dit, maar dan automatisch en op de schaal van miljoenen gebeurtenissen per dag, in bedrijfsnetwerken, clouddiensten en apps.

Wat is het precies?

Elk programma, elke server en elk netwerkapparaat produceert voortdurend logregels: korte tekstberichten met een tijdstip en een gebeurtenis. Een firewall logt binnenkomend verkeer, een applicatie logt fouten, een besturingssysteem logt inlogpogingen. Op een gemiddeld bedrijfsnetwerk lopen dat al snel duizenden logbronnen door elkaar.

De eerste stap in logcorrelatie is normalisatie: alle logs, die vaak in verschillende formaten en tijdzones staan, worden omgezet naar één gemeenschappelijke structuur. Pas dan kun je ze eerlijk met elkaar vergelijken.

Daarna zoekt het systeem naar verbanden. Dat kan op een paar manieren. De oudste methode is regelgebaseerd: een analist schrijft een regel als "als er binnen één minuut vijf mislukte inlogpogingen zijn gevolgd door een geslaagde, meld dit dan". Modernere systemen gebruiken ook machine learning om afwijkend gedrag te herkennen zonder dat iemand van tevoren een regel hoeft te bedenken, bijvoorbeeld wanneer een gebruiker opeens op een ongebruikelijk tijdstip grote hoeveelheden data downloadt.

Een cruciaal hulpmiddel hierbij is de zogeheten correlatie-ID: een uniek kenmerk dat wordt meegegeven aan één verzoek zodra het een systeem binnenkomt, en dat door alle onderliggende systemen wordt doorgegeven. Zo kun je exact volgen hoe één klik van een gebruiker door tientallen losse software-onderdelen (microservices) reist, ook al genereert elk onderdeel zijn eigen logs.

Het resultaat van al dit werk is meestal een tijdlijn: een overzicht dat laat zien hoe een gebeurtenis zich stap voor stap door een systeem heeft ontvouwen, van eerste oorzaak tot uiteindelijk effect.

Wat wil men ermee bereiken?

Het belangrijkste doel is snelheid. Een beveiligingsincident of storing wordt vaak pas laat ontdekt omdat de signalen verspreid over tientallen systemen staan en niemand ze bij elkaar optelt. Logcorrelatie moet die tijd tussen "iets gaat mis" en "we weten wat en waarom" drastisch verkorten, in de sector vaak aangeduid met de term MTTR (mean time to repair, gemiddelde hersteltijd).

Een tweede doel is het terugdringen van wat securityteams "alarmmoeheid" noemen: als een systeem duizenden losse meldingen per dag geeft, raken analisten murw en missen ze de belangrijke signalen. Correlatie bundelt gerelateerde meldingen tot één samenhangend, bruikbaar alarm.

Daarnaast speelt compliance een rol. Wetgeving zoals de Europese AVG (privacywetgeving) verplicht organisaties om te kunnen aantonen wie wanneer bij welke gegevens kon. Een goed gecorreleerd logoverzicht is daarvoor vaak het enige harde bewijs.

Tot slot is er de bredere belofte van "observability" (waarneembaarheid): in moderne clouddiensten, waar applicaties zijn opgeknipt in tientallen kleine onderdelen die voortdurend opstarten en weer verdwijnen, is het simpelweg niet meer mogelijk om met het blote oog te zien wat er gebeurt. Correlatie is dan geen luxe, maar een voorwaarde om het systeem nog te kunnen begrijpen.

Voorbeelden uit de praktijk

De SolarWinds-inbraak (ontdekt december 2020). Aanvallers hadden maandenlang toegang tot netwerken van Amerikaanse overheidsinstanties en bedrijven via besmette software-updates. Onderzoekers van onder meer FireEye herleidden de aanval pas door logs van cloudauthenticatie, netwerkverkeer en serverfoutmeldingen over een periode van negen maanden met elkaar te combineren.

Log4Shell (december 2021). Na de ontdekking van dit ernstige beveiligingslek in de populaire logsoftware Log4j moesten organisaties wereldwijd hun eigen logbestanden doorzoeken op verdachte tekenreeksen om te zien of ze al waren aangevallen voordat de kwetsbaarheid bekend werd. Dit liet in de praktijk zien hoe afhankelijk incidentonderzoek is van goed bewaarde en doorzoekbare logs.

De Target-datadiefstal (2013). Bij de Amerikaanse winkelketen Target bleek achteraf dat het beveiligingssysteem wél een waarschuwing had gegeven over de malware die creditcardgegevens van miljoenen klanten stal. Het signaal ging echter onder in de stroom van andere meldingen en werd niet gecorreleerd met andere aanwijzingen. Deze zaak wordt in de sector nog vaak aangehaald als voorbeeld van falende correlatie.

De Mirai-botnetaanval op Dyn (oktober 2016). Een leger van gekaapte slimme camera's en routers legde grote delen van het internet in de Verenigde Staten plat. Netwerkbeheerders en onderzoekers reconstrueerden het verloop van de aanval door verkeerslogs van providers over de hele wereld te correleren.

Jaeger bij Uber (open source sinds 2017). Taxibedrijf Uber bouwde intern een systeem om één ritaanvraag te volgen door honderden losse softwareonderdelen heen, met correlatie-ID's als technische basis. Het project werd in 2017 open source gemaakt en is sindsdien een veelgebruikt onderdeel geworden van moderne softwarebeheer, beheerd door de Cloud Native Computing Foundation.

Hoe ver is de techniek?

Voor beveiligingsdoeleinden is logcorrelatie geen nieuwe technologie: zogeheten SIEM-systemen (Security Information and Event Management) bestaan al sinds begin jaren 2000 en zijn inmiddels gangbaar bij grote organisaties. Wat wel sterk in ontwikkeling is, is de mate waarin kunstmatige intelligentie het handmatige opstellen van correlatieregels overneemt, vaak aangeduid als UEBA (gedragsanalyse van gebruikers en apparaten) of als onderdeel van bredere "XDR"-platforms (extended detection and response) die eindpunten, netwerk en cloud in één correlatiemotor samenbrengen.

Voor softwarebeheer in de cloud is het veld jonger. Pas sinds het samengaan van de projecten OpenTracing en OpenCensus tot OpenTelemetry, aangekondigd in 2019, bestaat er een breed gedragen open standaard voor het doorgeven van correlatiegegevens tussen verschillende softwareonderdelen en leveranciers.

De grootste obstakels zijn niet per se technisch maar organisatorisch en praktisch: logformaten verschillen nog altijd sterk per leverancier, het opslaan van alle logs is duur naarmate systemen groeien, en er is een aanhoudend tekort aan ervaren analisten om de resultaten te interpreteren. Ook blijft het lastig om valse alarmen voldoende terug te dringen zonder per ongeluk echte signalen te missen; dat blijft een kwestie van voortdurend bijstellen, niet van een definitief opgelost probleem.

Wie werken eraan?

Op het gebied van beveiliging zijn grote commerciële spelers Splunk, IBM (met het product QRadar), Microsoft (met Sentinel), Elastic, Google (met Chronicle, inmiddels onderdeel van Google Security Operations) en gespecialiseerde bedrijven als CrowdStrike en Palo Alto Networks. Voor softwarebeheer en cloud-observability zijn Datadog, New Relic en Elastic eveneens grote namen.

Op het gebied van open standaarden speelt de Cloud Native Computing Foundation (CNCF) een centrale rol, als beheerder van zowel OpenTelemetry als Jaeger. Het MITRE-instituut in de Verenigde Staten onderhoudt het ATT&CK-raamwerk, een veelgebruikte naslagwerk van aanvalstechnieken waarop veel correlatieregels worden gebaseerd.

Op overheidsniveau zijn onder meer het Amerikaanse NIST (National Institute of Standards and Technology) en CISA (Cybersecurity and Infrastructure Security Agency) actief met richtlijnen, terwijl in Nederland het Nationaal Cyber Security Centrum (NCSC) en op Europees niveau het agentschap ENISA soortgelijke rollen vervullen voor overheden en vitale infrastructuur.

Verder lezen