Logging, Monitoring & SIEM

Detectie Die Echt Iemand Wakker Maakt

Aanvalspaden worden klein zodra rechten, segmenten en beheerkanalen consequent zijn ingericht.

In Logging, Monitoring & SIEM ontstaat waarde wanneer detectie direct bruikbaar is voor opvolging, niet alleen voor rapportage.

Zo beperk je niet alleen de kans op incidenten, maar vooral ook de omvang en duur als er iets misgaat.

Directe maatregelen (15 minuten)

• Start met MFA, least privilege en tiering voor beheeraccounts.
• Voer segmentatie en expliciete firewallregels door op kritieke paden.
• Borg logging, detectie en hersteltests als structurele operatie.

Waarom dit telt

De kern van Logging, Monitoring & SIEM is risicoreductie in de praktijk. Technische context ondersteunt de maatregelkeuze, maar implementatie en borging staan centraal.

Logbronnen en Wat Je Moet Vastleggen

De eerste vraag is niet hoe je logt, maar wat. En het antwoord is niet “alles” — dat is onbetaalbaar en onbeheersbaar. Het antwoord is: alles wat je nodig hebt om een incident te reconstrueren, en niets meer.

De gouden regel: log authenticatie en autorisatie altijd. Wie heeft ingelogd, wanneer, vanwaar, en wat heeft hij gedaan. Al het andere is context.

Windows Event Log: de minimale set

Zet op z’n minst de volgende audit policies aan via Group Policy:

Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policy

Account Logon:
  Audit Credential Validation          → Success, Failure
  Audit Kerberos Authentication Service → Success, Failure
  Audit Kerberos Service Ticket Ops    → Success, Failure

Logon/Logoff:
  Audit Logon                          → Success, Failure
  Audit Logoff                         → Success
  Audit Special Logon                  → Success

Object Access:
  Audit File System                    → Failure
  Audit Registry                       → Failure

Privilege Use:
  Audit Sensitive Privilege Use        → Success, Failure

Process Tracking:
  Audit Process Creation               → Success
  (+ Enable command line in process creation events via GPO)

DS Access:
  Audit Directory Service Changes      → Success
  Audit Directory Service Access       → Success

Account Management:
  Audit User Account Management        → Success, Failure
  Audit Security Group Management      → Success, Failure
  Audit Computer Account Management    → Success, Failure

Zonder command line logging in process creation events ben je blind voor wat er daadwerkelijk wordt uitgevoerd. powershell.exe is niet verdacht. powershell.exe -enc SQBFAFgA... wel.

Centralisatie: Waarom Lokale Logs Niet Genoeg Zijn

Lokale logs hebben twee problemen. Ten eerste: als een aanvaller een systeem compromitteert, is het wissen van de lokale logs een van de eerste dingen die hij doet (zie evasion_eventlog in het commandarsenaal). Ten tweede: correlatie. Een mislukte login op server A, gevolgd door een succesvolle login op server B met dezelfde credentials, drie seconden later — dat patroon zie je alleen als je de logs van A en B naast elkaar kunt leggen.

Architectuur

+-------------+    +-------------+    +-------------------+
| Windows     |    | Linux       |    | Firewall / Proxy  |
| Sysmon +    |    | rsyslog /   |    | Syslog output     |
| WEF / agent |    | auditd      |    |                   |
+------+------+    +------+------+    +--------+----------+
       |                  |                     |
       v                  v                     v
+------+------------------+---------------------+------+
|                    COLLECTOR                          |
|  (Logstash / Fluentd / Wazuh manager / rsyslog)     |
+---------------------------+--------------------------+
                            |
                            v
               +------------+------------+
               |         SIEM            |
               |  (Wazuh / Elastic /     |
               |   Sentinel / Splunk)    |
               +-------------------------+

rsyslog: logs doorsturen naar centrale server

# Bronserver: /etc/rsyslog.d/50-remote.conf
auth,authpriv.*    @@siem.internal.local:514    # TCP (@@) ipv UDP (@)
*.warn             @@siem.internal.local:514

# Centrale server: /etc/rsyslog.d/10-receive.conf
module(load="imtcp")
input(type="imtcp" port="514")
template(name="RemoteLogs" type="string"
    string="/var/log/remote/%HOSTNAME%/%PROGRAMNAME%-%$YEAR%-%$MONTH%-%$DAY%.log")
*.* ?RemoteLogs

Filebeat: gestructureerde logs naar Elastic

# /etc/filebeat/filebeat.yml
filebeat.inputs:
  - type: log
    enabled: true
    paths: [/var/log/auth.log, /var/log/syslog]
    fields:
      log_type: linux_system
  - type: log
    enabled: true
    paths: [/var/log/audit/audit.log]
    fields:
      log_type: linux_audit

output.elasticsearch:
  hosts: ["https://siem.internal.local:9200"]
  username: "filebeat_writer"
  password: "${FILEBEAT_ES_PASSWORD}"
  ssl.certificate_authorities: ["/etc/filebeat/ca.pem"]

Windows Event Forwarding (WEF)

Voor Windows-omgevingen is WEF de native oplossing — geen extra agents nodig:

# Op de collector (subscription server)
wecutil qc /q
wecutil cs SecurityEvents.xml

SIEM Platformen

Voor organisaties die beginnen: Wazuh. Het combineert SIEM, intrusion detection, file integrity monitoring en vulnerability scanning in een platform. Het is gratis. Het is goed gedocumenteerd. En het heeft agents voor Windows, Linux en macOS.

Wazuh agent configuratie

<!-- /var/ossec/etc/ossec.conf op de agent -->
<ossec_config>
  <client>
    <server>
      <address>wazuh-manager.internal.local</address>
      <port>1514</port>
      <protocol>tcp</protocol>
    </server>
  </client>

  <!-- File Integrity Monitoring -->
  <syscheck>
    <frequency>600</frequency>
    <directories check_all="yes" realtime="yes">/etc,/usr/bin,/usr/sbin</directories>
    <directories check_all="yes" realtime="yes">/var/ossec/etc</directories>
    <ignore>/etc/mtab</ignore>
    <ignore>/etc/resolv.conf</ignore>
  </syscheck>

  <!-- Log monitoring -->
  <localfile>
    <log_format>syslog</log_format>
    <location>/var/log/auth.log</location>
  </localfile>
  <localfile>
    <log_format>audit</log_format>
    <location>/var/log/audit/audit.log</location>
  </localfile>
</ossec_config>

Detectieregels die Ertoe Doen

Detectieregels schrijven is een kunst. Te breed en je verdrinkt in false positives. Te smal en je mist de aanval. Sigma is de lingua franca van detectieregels — een open formaat dat vertaald kan worden naar Splunk SPL, Elastic KQL, Microsoft Sentinel KQL, en tientallen andere platformen.

Sigma regel: brute force detectie

title: Multiple Failed Logons Followed by Success
id: 7a3c2e5f-1b4d-4a8c-9e6f-2d3b5c7a8e1f
status: stable
description: Detecteert meerdere mislukte inlogpogingen gevolgd door een succesvolle login (password spraying / brute force)
author: securitymaatregelen.nl
logsource:
    product: windows
    service: security
detection:
    failed:
        EventID: 4625
    successful:
        EventID: 4624
        LogonType:
            - 3    # Network
            - 10   # RemoteInteractive (RDP)
    condition: failed | count(TargetUserName) by SourceAddress > 5
    timeframe: 10m
falsepositives:
    - Legitieme gebruikers die hun wachtwoord zijn vergeten
    - Service accounts met verlopen credentials
level: medium
tags:
    - attack.credential_access
    - attack.t1110.003

Sigma regel: DCSync detectie

title: DCSync Attack Detected
id: 5e8f2a1b-3c4d-6e7f-8a9b-0c1d2e3f4a5b
status: stable
description: Detecteert replicatie-aanvragen van niet-DC systemen (DCSync)
logsource:
    product: windows
    service: security
detection:
    selection:
        EventID: 4662
        Properties|contains:
            - '1131f6aa-9c07-11d1-f79f-00c04fc2dcd2'  # DS-Replication-Get-Changes
            - '1131f6ad-9c07-11d1-f79f-00c04fc2dcd2'  # DS-Replication-Get-Changes-All
    filter:
        SubjectUserName|endswith: '$'
    condition: selection and not filter
level: critical
tags:
    - attack.credential_access
    - attack.t1003.006

Sigma vertalen naar Elastic KQL

pip install sigma-cli pySigma-backend-elasticsearch pySigma-pipeline-elasticsearch-windows
sigma convert -t elasticsearch -p elasticsearch-windows rules/brute_force.yml

Alerting zonder Alert Fatigue

Alert fatigue is de reden waarom Target veertig miljoen creditcards kwijtraakte. Het SOC kreeg zoveel alerts dat de kritieke alerts verdronken in de ruis. De oplossing is niet minder alerts — het is betere alerts.

Prioriteringsmodel

Tuning: de eerste 90 dagen

Week 1-2: alle regels op alert, niets onderdrukken — verzamel data. Week 3-4: identificeer top 10 false positive bronnen, maak whitelists. Week 5-8: verfijn thresholds per omgeving. Week 9-12: implementeer playbooks voor P1 en P2, automatiseer waar mogelijk. Doorlopend: elke false positive is een kans om de regel te verbeteren.

Eén concrete tip: maak een whitelist van bekende service accounts en hun normale gedrag. svc_backup die elke nacht om 02:00 inlogt op de fileserver is normaal. svc_backup die om 14:30 inlogt op de domain controller is dat niet.

Log Integriteit en Forensische Waarde

Logs die gemanipuleerd kunnen worden, zijn forensisch waardeloos. Een aanvaller die wevtutil cl Security draait op een Windows-machine wist het hele Security Event Log in een seconde. Als dat je enige kopie was, is je bewijsmateriaal verdwenen.

Tamper-proof logging

# Linux: append-only attribuut op logbestanden
chattr +a /var/log/auth.log
chattr +a /var/log/audit/audit.log

# Verificatie
lsattr /var/log/auth.log
# Output: -----a--------e--- /var/log/auth.log

Tijdsynchronisatie (NTP)

Logs zonder betrouwbare timestamps zijn waardeloos voor correlatie. Als server A denkt dat het 14:00 is en server B denkt dat het 14:07 is, kun je geen tijdlijn reconstrueren.

# /etc/chrony/chrony.conf
server ntp1.internal.local iburst prefer
server ntp2.internal.local iburst
driftfile /var/lib/chrony/chrony.drift
makestep 1.0 3
rtcsync

Log hashing voor bewijsketen

#!/bin/bash
# Dagelijkse hash van logbestanden voor forensische integriteit
LOG_DIR="/var/log/remote"
HASH_FILE="/var/log/integrity/hashes-$(date +%Y%m%d).sha256"

find "$LOG_DIR" -name "*.log" -mtime -1 -exec sha256sum {} \; > "$HASH_FILE"
# Stuur hash-bestand naar een apart systeem (write-once storage)
scp "$HASH_FILE" integrity@vault.internal.local:/hashes/

Implementatie: Van Nul naar Bruikbaar

Een stappenplan voor organisaties die nog niets hebben — of die denken dat ze iets hebben maar eigenlijk een Splunk-licentie betalen waar niemand naar kijkt.

Sysmon: de belangrijkste agent die je kunt installeren

Sysmon is gratis, van Microsoft, en logt procesaanmaak, netwerkverbindingen, file creates, registry-wijzigingen, DNS-queries, en meer. Zonder Sysmon ben je blind voor het merendeel van de aanvalstechnieken in dit handboek.

# Download Sysmon
# Gebruik de SwiftOnSecurity configuratie als startpunt
Sysmon64.exe -accepteula -i sysmonconfig-export.xml

# Verificeer dat Sysmon draait
Get-Service Sysmon64
Get-WinEvent -LogName "Microsoft-Windows-Sysmon/Operational" -MaxEvents 5

Samenvatting

Logging en monitoring zijn het verschil tussen “we zijn gehackt en we weten het” en “we zijn gehackt en we ontdekken het over zes maanden uit de krant.” De technologie is beschikbaar en grotendeels gratis: Sysmon voor endpoint-visibility, rsyslog of Filebeat voor centralisatie, Wazuh of Elastic als SIEM-platform, en Sigma als universeel formaat voor detectieregels. De implementatie begint bij het vastleggen van de juiste logs (authenticatie, procesaanmaak, netwerkverkeer), het centraliseren op een systeem dat de aanvaller niet kan wissen, en het schrijven van detectieregels die daadwerkelijk betekenisvolle alerts genereren. Alert fatigue is de vijand — los het op met prioritering, tuning, en playbooks, niet met het uitzetten van alerts. Log integriteit is niet optioneel: append-only opslag, NTP-synchronisatie, en hash-verificatie zorgen dat je logs forensisch bruikbaar blijven. En het belangrijkste: iemand moet naar de logs kijken. Een SIEM zonder analisten is een duur archiefsysteem. Clifford Stoll had een printer en een pieper, en hij vond de KGB. Het gereedschap is er. De vraag is of iemand het oppakt.