Logging, Monitoring & SIEM

Detection That Actually Wakes Someone Up

Attack paths shrink once permissions, segments, and management channels are consistently configured.

In Logging, Monitoring & SIEM, value emerges when detection is directly actionable for follow-up, not just for reporting.

This way you limit not only the chance of incidents, but especially the scope and duration when something goes wrong.

Immediate measures (15 minutes)

• Start with MFA, least privilege, and tiering for admin accounts.
• Implement segmentation and explicit firewall rules on critical paths.
• Ensure logging, detection, and recovery testing as a structural operation.

Why this matters

The core of Logging, Monitoring & SIEM is risk reduction in practice. Technical context supports the choice of measures, but implementation and assurance are central.

Log Sources and What You Need to Capture

The first question is not how you log, but what. And the answer is not "everything" — that is unaffordable and unmanageable. The answer is: everything you need to reconstruct an incident, and nothing more.

The golden rule: always log authentication and authorization. Who logged in, when, from where, and what did they do. Everything else is context.

Windows Event Log: the minimum set

At a minimum, enable the following audit policies 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

Without command line logging in process creation events you are blind to what is actually being executed. powershell.exe is not suspicious. powershell.exe -enc SQBFAFgA... is.

Centralization: Why Local Logs Are Not Enough

Local logs have two problems. First: when an attacker compromises a system, clearing the local logs is one of the first things they do (see evasion_eventlog in the command arsenal). Second: correlation. A failed login on server A, followed by a successful login on server B with the same credentials, three seconds later — you only see that pattern if you can compare the logs from A and B side by side.

Architecture

+-------------+    +-------------+    +-------------------+
| 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: forwarding logs to a central server

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

# Central 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: structured logs to 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)

For Windows environments, WEF is the native solution — no extra agents needed:

# On the collector (subscription server)
wecutil qc /q
wecutil cs SecurityEvents.xml

SIEM Platforms

For organizations getting started: Wazuh. It combines SIEM, intrusion detection, file integrity monitoring, and vulnerability scanning in one platform. It is free. It is well documented. And it has agents for Windows, Linux, and macOS.

Wazuh agent configuration

<!-- /var/ossec/etc/ossec.conf on the 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>

Detection Rules that Matter

Writing detection rules is an art. Too broad and you drown in false positives. Too narrow and you miss the attack. Sigma is the lingua franca of detection rules — an open format that can be translated to Splunk SPL, Elastic KQL, Microsoft Sentinel KQL, and dozens of other platforms.

Sigma rule: brute force detection

title: Multiple Failed Logons Followed by Success
id: 7a3c2e5f-1b4d-4a8c-9e6f-2d3b5c7a8e1f
status: stable
description: Detects multiple failed login attempts followed by a successful 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:
    - Legitimate users who forgot their password
    - Service accounts with expired credentials
level: medium
tags:
    - attack.credential_access
    - attack.t1110.003

Sigma rule: DCSync detection

title: DCSync Attack Detected
id: 5e8f2a1b-3c4d-6e7f-8a9b-0c1d2e3f4a5b
status: stable
description: Detects replication requests from non-DC systems (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

Converting Sigma to 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 without Alert Fatigue

Alert fatigue is the reason why Target lost forty million credit cards. The SOC received so many alerts that the critical alerts drowned in the noise. The solution is not fewer alerts — it is better alerts.

Prioritization model

Tuning: the first 90 days

Week 1-2: all rules on alert, suppress nothing — collect data. Week 3-4: identify top 10 false positive sources, create whitelists. Week 5-8: refine thresholds per environment. Week 9-12: implement playbooks for P1 and P2, automate where possible. Ongoing: every false positive is an opportunity to improve the rule.

One concrete tip: create a whitelist of known service accounts and their normal behavior. svc_backup logging in every night at 02:00 on the file server is normal. svc_backup logging in at 14:30 on the domain controller is not.

Log Integrity and Forensic Value

Logs that can be manipulated are forensically worthless. An attacker who runs wevtutil cl Security on a Windows machine wipes the entire Security Event Log in a second. If that was your only copy, your evidence is gone.

Tamper-proof logging

# Linux: append-only attribute on log files
chattr +a /var/log/auth.log
chattr +a /var/log/audit/audit.log

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

Time synchronization (NTP)

Logs without reliable timestamps are worthless for correlation. If server A thinks it is 14:00 and server B thinks it is 14:07, you cannot reconstruct a timeline.

# /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 for chain of evidence

#!/bin/bash
# Daily hash of log files for forensic integrity
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"
# Send hash file to a separate system (write-once storage)
scp "$HASH_FILE" integrity@vault.internal.local:/hashes/

Implementation: From Zero to Usable

A step-by-step plan for organizations that have nothing yet — or that think they have something but are actually paying for a Splunk license that nobody looks at.

Sysmon: the most important agent you can install

Sysmon is free, from Microsoft, and logs process creation, network connections, file creates, registry changes, DNS queries, and more. Without Sysmon you are blind to the majority of the attack techniques in this handbook.

# Download Sysmon
# Use the SwiftOnSecurity configuration as a starting point
Sysmon64.exe -accepteula -i sysmonconfig-export.xml

# Verify that Sysmon is running
Get-Service Sysmon64
Get-WinEvent -LogName "Microsoft-Windows-Sysmon/Operational" -MaxEvents 5

Summary

Logging and monitoring are the difference between "we got hacked and we know it" and "we got hacked and we find out six months later from the newspaper." The technology is available and largely free: Sysmon for endpoint visibility, rsyslog or Filebeat for centralization, Wazuh or Elastic as a SIEM platform, and Sigma as a universal format for detection rules. Implementation starts with capturing the right logs (authentication, process creation, network traffic), centralizing them on a system the attacker cannot wipe, and writing detection rules that actually generate meaningful alerts. Alert fatigue is the enemy — solve it with prioritization, tuning, and playbooks, not by disabling alerts. Log integrity is not optional: append-only storage, NTP synchronization, and hash verification ensure your logs remain forensically usable. And most importantly: someone needs to look at the logs. A SIEM without analysts is an expensive archival system. Clifford Stoll had a printer and a pager, and he found the KGB. The tools are there. The question is whether someone picks them up.