Beveiligingslogboeken en monitoring (SIEM, SOC, MDR) als bewijs

Een praktische gids voor beveiligingslogboekregistratie, SIEM en SOC- of MDR-services: wat je moet registreren, retentie, detectiegebruiksscenario's, waarschuwingstriage en hoe je aan toezichthouders aantoont dat detectie werkt.

Deze gids is voor IT- en security managers, CISO's en de MSP's of vCISO's die hen adviseren en die security logging en monitoring moeten opzetten of opschonen op een manier die standhoudt bij een NIS2-, CyFun- of DORA-review. Het behandelt wat je moet loggen, hoe lang je het moet bewaren, welke detecties je eerst moet bouwen, hoe waarschuwingen moeten worden afgehandeld en hoe je kiest tussen een eigen SOC, een uitbestede SOC en managed detection and response (MDR). Aan het einde heb je een register en een manier om aan te tonen dat detectie werkt.

Voordat je begint

Je hebt drie inputs nodig: een lijst van kritieke diensten en de systemen die ze ondersteunen (uit je asset-inventaris of business impact-analyse), je huidige risicobeoordeling en een overzicht van wat je al verzamelt. Betrek de DPO vroeg erbij. Beveiligingslogboeken bevatten persoonsgegevens, dus doel, minimalisering, toegang en retentie moeten onder de AVG worden gedocumenteerd.^[7].

Stap 1: Begrijp wat de regels werkelijk vereisen

NIS2 artikel 21, lid 2, onder b) vereist maatregelen voor incidentafhandeling, en je kunt niet afhandelen wat je niet detecteert^[1]. Voor aanbieders van digitale infrastructuur en digitale diensten is Uitvoeringsverordening 2024/2690 specifiek. Bijlage punt 3.2 verplicht entiteiten om activiteiten te controleren en vast te leggen om gebeurtenissen op te sporen die incidenten kunnen zijn; waar passend netwerkverkeer, account- en verificatiegebeurtenissen, bevoorrechte activiteiten, wijzigingen in kritieke configuratie en back-upbestanden en security tool-gebeurtenissen vast te leggen; monitoring waar haalbaar te automatiseren en af te stemmen om vals-positieven en vals-negatieven te beperken; logboeken voor een vooraf bepaalde periode te bewaren en te beschermen; tijdbronnen te synchroniseren; logging redundant te maken; en de instellingen met regelmatige tussenpozen en na significante incidenten te controleren^[2]. De Uitvoeringsverordening is formeel alleen van toepassing op die aanbiedertypes, maar het is een praktische maatstaf voor elke entiteit, en de technische begeleiding van ENISA licht elk punt toe.^[5].

Voor financiële entiteiten vereist DORA artikel 10 mechanismen om afwijkende activiteiten snel op te sporen, meerdere controlelagen, waarschuwingsdrempels die incidentrespons activeren en regelmatig testen van detectie^[3]. Gedelegeerde Verordening 2024/1774 voegt detail toe: logboekprocedures die gebeurtenissen, retentie en bescherming definiëren (artikel 12), kloksynchronisatie naar een gedocumenteerde betrouwbare tijdbron, en waarschuwingen voor afwijkende activiteiten minstens voor activa die kritieke of belangrijke functies ondersteunen, afgehandeld zowel tijdens als buiten werkuren (artikel 23).^[4].

Stap 2: Definieer eerst detectiegebruiksscenario's

Een gebruiksscenario is iets specifieks dat je wilt detecteren, met een gedefinieerde respons. Begin met tien tot vijftien die aansluiten bij je risico's; ransomware-voortekenen, accountovername en misbruik van bevoorrechte toegang zijn verstandige startpunten.

• Aanmelding vanuit een ongebruikelijk land of onmogelijke reissnelheid op een bevoorrecht account.
• MFA-vermoeidheid (herhaalde push-weigering) of MFA-methode gewijzigd, gevolgd door aanmelding.
• Nieuwe mailbox-doorstuurregel naar een extern adres.
• Lid toegevoegd aan een bevoorrechte groep (domeinadmins, globale beheerders).
• Eindpuntbeveiliging uitgeschakeld of gemanipuleerd; ransomware-gedrag gedetecteerd.
• Verwijdering of wijziging van back-uptaken, snapshots of back-upopslagplaatsen.
• Massale bestandsdownload of -upload naar onbekende cloudopslag.
• Uitgaande verbindingen naar bekende schadelijke infrastructuur (threat intelligence-match).
• Audit-logging uitgeschakeld op een kritiek systeem.

Koppel elk use case aan de logbronnen die het nodig heeft en noteer welke je vandaag kunt detecteren. Deze gapanalyse is je meest bruikbare document.

Stap 3: Prioriteer logbronnen

Werk in lagen. Laag 1-bronnen zijn waar de meeste aanvallen zichtbaar worden en zijn meestal goedkoop om te verzamelen. Laag 2-bronnen voegen diepte toe voor kritieke services.

Gebied	Laag 1 (begin hier)	Laag 2 (voeg toe voor kritieke services)
Identiteit	Entra ID- of andere IdP-aanmeldingen en auditlogboeken, Active Directory-beveiligingsgebeurtenissen, MFA-gebeurtenissen	Sessies voor bevoorrecht toegangsbeheer, serviceaccountgebruik
Eindpunten en servers	EDR-waarschuwingen en telemetrie, Windows-beveiligings- en PowerShell-logboeken op servers	Sysmon of gelijkwaardige gedetailleerde telemetrie, Linux-auditlogboeken
Cloud en SaaS	Microsoft 365- of Google Workspace-auditlogboeken, cloud control-plane-logboeken (AWS CloudTrail, Azure Activity, GCP Audit)	Opslagtoegangslogboeken, key vault-toegang, SaaS-beheerlogboeken voor bedrijfskritieke apps
Netwerk	Firewall-logboeken voor toestaan en weigeren, VPN en externe toegang, DNS-query's	Proxy-logboeken, NetFlow, netwerkdetectie en -respons, OT-netwerkbewaking
Kritieke toepassingen	Beheerdersacties, verificatie, configuratiewijzigingen	Zakelijke transacties met fraudarelevantie, database-audit
Beveiligings- en back-uphulpmiddelen	Back-upconsolewijzigingen en -fouten, e-mailbeveiligingswaarschuwingen, bevindingen van de kwetsbaarhedenscanner	Preventie van gegevensverlies, deceptiehulpmiddelen

Stap 4: Stel retentie, integriteit en tijdsynchronisatie in

Noch NIS2 noch de Uitvoeringsverordening bepalen een aantal maanden voor logboekretentie. De vereiste is een vooraf bepaalde, gerechtvaardigde periode. Baseer deze op hoe lang aanvallers doorgaans onopgemerkt in je omgeving blijven, op juridische bewaarverplichting en onderzoeksbehoeften, en op eventuele sectorale regels. Een veelgebruikt ontwerp is een 'hot' periode die snel kan worden doorzocht en een goedkoper archief voor de rest van de periode. Documenteer de grondslag.

• Bescherm logboeken tegen wijziging en verwijdering: afzonderlijke opslag, beperkte beheerdersrechten, onveranderlijkheid waar beschikbaar.
• Controleer de logging-pijplijn zelf: waarschuw wanneer een bron stil valt.
• Synchroniseer alle systemen met een gedocumenteerde betrouwbare tijdbron (NTP van een vertrouwde interne of nationale bron) en log in UTC of met tijdzone-informatie.

Stap 5: Kies je bedrijfsmodel: in-house, SOC-service of MDR

De vraag is wie de waarschuwingen om 3 uur 's nachts in de gaten houdt en wie de bevoegdheid heeft om in te grijpen.

Model	Wat je krijgt	Geschikt voor	Let op
In-house SOC	Volledige controle, diepgaande kennis van je omgeving	Grote organisaties met budget voor 24/7-bemanning	Het bemensen van een 24/7-rooster vereist meerdere analisten; sleutelpersoonsrisico
Uitbestede SOC / beheerde SIEM	Provider bewaakt je SIEM en escaleert waarschuwingen	Organisaties die het platform en de gegevens willen bezitten	Escalatie zonder respons: iemand intern moet toch handelen
MDR	Provider bewaakt vooral EDR- en identiteitstelemetrie en kan indammen (host isoleren, account uitschakelen)	Kleine en middelgrote organisaties	Scope beperkt tot de tools van de provider; bevestig welke logboeken worden gedekt en wie beslist over indamming
Hybride	MDR voor 24/7-dekking, in-house-team voor use cases en onderzoeken	Groeiende organisaties	Duidelijke verdeling van verantwoordelijkheden in een RACI

Wat je ook kiest, de provider is een ICT-leverancier en valt onder je maatregelen voor de toeleveringsketen. Contracten moeten serviceniveaus voor triage en escalatie, indammingsbevoegdheid, logeigendom en teruggave bij beëindiging, gegevenslocatie en ondersteuning voor je incidentmeldingsdeadlines dekken.

Stap 6: Pak EU-gegevenslocatie en werknemersmonitoring aan

Security logs bevatten gebruikersnamen, IP-adressen, apparaatidentificatoren en soms metagegevens van berichten, dus de AVG is volledig van toepassing. Op grond van hoofdstuk V van de AVG is voor doorgiften van persoonsgegevens buiten de EER een rechtsgrondslag vereist, zoals een adequaatheidsbesluit of passende waarborgen^[7]. Externe toegang tot in de EU opgeslagen logboeken door analisten in een derde land kan ook als een doorgifte worden beschouwd.

• Vraag waar logboeken worden opgeslagen, verwerkt en geback-upt, en waar SOC-analisten werken.
• Geef de voorkeur aan een EU-regio voor de SIEM en de analysetools van de provider, en controleer de subverwerkers van de provider.
• Documenteer een gegevensbeschermingseffectbeoordeling waar bewaking uitgebreid of systematisch is.
• Respecteer nationale regels voor werknemersbewaking: in België, Collectieve Arbeidsovereenkomst nr. 81 over bewaking van elektronische onlinecommunicatie; in Nederland, het instemmingsrecht van de ondernemingsraad onder artikel 27 van de Wet op de ondernemingsraden; in Luxemburg, de bepalingen van het Arbeidswetboek over werkplekbewaking.

Stap 7: Definieer waarschuwingstriage en escalatie

Een waarschuwing die niemand afhandelt, is bewijs tegen je. Definieer ernstniveaus, responstijden en wie wat doet, en koppel waarschuwingen met hoog ernstniveau aan je incidentresponsplan en je NIS2-rapportagebesluit.

• Ernstniveaus met doeltijden voor bevestiging en escalatie (bijvoorbeeld kritieke waarschuwingen binnen 30 minuten bevestigd, 24/7).
• Triage-stappen per use case: wat controleren, wanneer sluiten als fout-positief, wanneer escaleren.
• Escalatieketen met genoemde personen en plaatsvervangers, ook buiten kantooruren.
• Een duidelijk moment waarop een waarschuwing een incident wordt en de klok voor de 24-uurse vroegtijdige waarschuwing onder NIS2 artikel 23 kan gaan lopen^[1].

Stap 8: Bewijs dat detectie werkt

Dit is waar de meeste organisaties tekortschieten. Een bescheiden opzet die wordt getest en verbeterd, is overtuigender dan een dure die niemand kan uitleggen. Het CyFun 2025-framework is afgestemd op NIST CSF 2.0 en volgt de structuur ervan, inclusief de Detect-functie^[6].

• Test elke prioritaire use case minstens jaarlijks met een veilige simulatie (maak een testverwerkingsregel, voeg een testaccount toe aan een beheerdersgroep, voer een onschadelijk aanvalssimulatieprogramma uit) en noteer of de waarschuwing is afgegaan en op tijd is afgehandeld.
• Dekkingsrapportage: percentage kritieke systemen dat logboeken verzendt, percentage prioritaire use cases getest in de afgelopen 12 maanden, gemiddelde tijd tot bevestiging en escalatie.
• Neem detectie op in je tafeloefeningen; het draaiboek voor tafeloefeningen laat zien hoe.

In Secrato kunnen het logbronnen- en use-caseregister als bewijs worden gekoppeld aan de monitoringcontroles in de Compliance-engine, zodat een enkel testresultaat tegelijk NIS2, CyFun, ISO/IEC 27001 en DORA ondersteunt.

De bijbehorende sjabloon bevat een logbronnenregister, een detectie-use-caseregister met 30 vooraf ingevulde use cases en een detectietestlogboek.

Hoe dit aansluit op andere frameworks

ISO/IEC 27001:2022 Bijlage A behandelt logboekregistratie (8.15), monitoringactiviteiten (8.16) en kloksynchronisatie (8.17); hetzelfde register dient als bewijs voor alle drie. In NIST CSF 2.0 en CyFun zit dit werk in de Detect-functie. Onder DORA maken artikel 10 en de Gedelegeerde Verordening detectietesting expliciet. Het register dat je eenmaal bouwt, dient ze allemaal.

Veelgestelde vragen

Hebben we een SIEM nodig om aan NIS2 te voldoen?

Geen wet noemt een product. Je moet relevante logboeken verzamelen, verdachte activiteiten detecteren en op tijd reageren. Een kleine organisatie kan dat bereiken met een MDR-service op eindpunten en identiteit plus gecentraliseerde cloud-auditlogboeken. Grotere of complexere entiteiten hebben meestal een SIEM nodig om bronnen te correleren.

Hoe lang moeten we beveiligingslogboeken bewaren?

Er is geen vast EU-breed getal onder NIS2. Kies een periode waarmee je incidenten die laat zijn ontdekt kunt onderzoeken, leg dit schriftelijk vast en controleer sectorregels en contracten. Bewaar persoonsgegevens niet langer dan dat doel vereist.

Is 24/7-monitoring verplicht?

NIS2 stelt dit niet expliciet. De gedelegeerde verordening van DORA vereist dat waarschuwingen voor kritieke of belangrijke functies tijdens en buiten kantooruren worden afgehandeld. Voor entiteiten met kritieke diensten is dekking buiten kantooruren een praktische noodzaak.