Log-Management24. Juli 2026 · 6 Min. Lesezeit

How to Log: Formatierung, Timestamps, Retention – die Grundlagen

Einleitung

Ein gutes SIEM hilft nichts, wenn die Logs darin nicht durchsuchbar, vergleichbar und zeitlich konsistent sind. Dieser Artikel klärt die drei Grundlagen, an denen die meisten Setups scheitern: Format (Syslog, JSON, CEF), Timestamps (UTC, ISO-8601, Sekundengenauigkeit) und Retention (wie lange, wo, wie immutable). Wer die drei sauber hinbekommt, hat 80 % der Detection-Probleme schon gelöst.

Warum das Thema wichtig ist

Im Incident merkst du sofort, ob die Log-Hygiene stimmt: Du suchst nach einem Login von „Karl Müller“ um 14:23 Uhr und findest ihn nicht – weil der Server in lokaler Zeit loggt, der Proxy in UTC, das EDR in Epoch-Millisekunden. Oder du findest den Eintrag, kannst ihn aber nicht auf eine SIGMA-Rule mappen, weil das Feld „User“ mal User, mal username, mal actor.name heißt. Logging ist keine Frage des Tools, sondern der Disziplin: einheitliches Format, einheitliche Zeitzone, klare Retention. Diese drei Stellschrauben kosten nichts und entscheiden, ob du im Ernstfall in zehn Minuten oder zehn Stunden die Antwort hast.

Format: drei Standards, klare Empfehlung

Format Stärke Schwäche Geeignet für
Syslog (RFC5424) Universell, jeder Sender Freitext, schwer parsebar Netzwerk-Devices, Linux-System
JSON Strukturiert, leicht parsebar Volumen, kein Standard-Schema Anwendungen, moderne Services
CEF (ArcSight) Strukturiert + lesbar Begrenzte Felder Security-Appliances

Empfehlung: für eigene Anwendungen JSON. Für Drittsysteme akzeptieren, was kommt, und im Pipeline-Schritt (Vector / Logstash / Cribl) normalisieren.

JSON-Beispiel

{
  "timestamp": "2026-05-03T14:23:11.045Z",
  "level": "WARN",
  "service": "auth-api",
  "host": "auth-prod-01",
  "event": "login.failed",
  "user": "karl.mueller",
  "src_ip": "10.20.30.40",
  "reason": "invalid_password",
  "trace_id": "a1b2c3d4"
}

Vorteile:

Schema einheitlich halten

Die größte Schwäche von JSON ist die Schema-Vielfalt. Innerhalb deiner eigenen Apps: ein Logger-Wrapper (z. B. pino in Node, structlog in Python, slog in Go) mit fixen Feldnamen (event, user, src_ip, …). Für externe Quellen: Normalisierung im Logging-Pipeline-Schritt – z. B. mit Vector-Remap-Regeln:

[transforms.normalize]
type = "remap"
inputs = ["raw"]
source = '''
.user = .user_name || .User || .actor.name
.src_ip = .source.ip || .src_ip || .remote_addr
'''

Konvergenz auf das Elastic Common Schema (ECS) ist ein guter Startpunkt – es ist offen, breit unterstützt und deckt 90 % der Detection-Use-Cases ab.

Timestamps: vier Regeln

Regel 1 – Immer UTC

Server in Frankfurt, AWS-Region in Irland, Mitarbeiter im Home-Office in Stockholm: jede Zeitzone ist eine Fehlerquelle. Alle Logs in UTC, nichts anderes. Display-Konvertierung passiert im SIEM-UI, nicht in der Quelle.

# Linux
sudo timedatectl set-timezone UTC

# Windows (Server)
Set-TimeZone -Id "UTC"

Regel 2 – ISO-8601 mit Millisekunden und Z-Suffix

2026-05-03T14:23:11.045Z   ✓
2026-05-03 14:23:11        ✗ (kein Tz, keine ms)
05/03/2026 2:23 PM         ✗ (mehrdeutig)
1714746191045              ✗ (Epoch ohne Kontext)

Begründung: Sortier-stabil, eindeutig parsbar, weltweit konsistent.

Regel 3 – Zeitsynchronisation Pflicht

Ohne NTP / Chrony driften Server in Stunden auseinander. Mindestens:

# Linux
sudo systemctl enable --now chrony
chronyc tracking   # Drift sollte < 50ms sein

# Windows
w32tm /query /status

In Domänen: PDC-Emulator als Time-Source dokumentieren, alle anderen synchronisieren.

Regel 4 – Sekundengenauigkeit reicht selten

Bei Lateral Movement liegen Events oft 10–50 ms auseinander. Sekundengenauigkeit verwischt die Reihenfolge. Mindestens Millisekunden, besser Mikrosekunden, wenn das Tool das hergibt.

Retention: die schwierigste Frage

Log-Klasse Empfohlene Retention Begründung
Auth-Events (Login, sudo, Kerberos) 365 Tage Forensik geht oft 6–12 Monate zurück
Network-Flows 90 Tage Volumen vs. Nutzen
DNS-Queries 90 Tage extrem nützlich für IOC-Hunts
Endpoint-Process-Events 90 Tage Korrelations-Tiefe
Application-Logs 30–90 Tage je nach Compliance
Web-Access-Logs 90 Tage Forensik bei Web-Exploits
Debug-Logs 7 Tage High-Volume, niedriger Wert

Ergänzend: regulatorische Vorgaben (BSI, DSGVO, branchenspezifisch) prüfen – manche fordern Mindesthaltung, andere Maximalhaltung (DSGVO-Datenminimierung).

Retention-Tiering

Drei Stufen sparen massiv Speicher:

Tier Speicher Zugriff Beispiel
Hot SSD im SIEM sofort, durchsuchbar letzte 30 Tage
Warm HDD / Object-Storage minutenschnell 30–90 Tage
Cold S3 Glacier / Tape Stunden 90–365+ Tage

Wazuh/OpenSearch unterstützen Index-Rollover; Loki/Graylog haben eigene Retention-Mechanismen.

Immutability

Logs müssen vor Manipulation geschützt sein – sonst wertlos im Incident:

Mind. eine dieser Maßnahmen für Auth- und Audit-Logs.

Pipeline: vom Event zum Index

[Quelle]  →  [Sammler]  →  [Pipeline]  →  [Storage]  →  [Index/Suche]
 App        Filebeat       Vector         S3 + Index    OpenSearch
 OS         Wazuh-Agent    Logstash       Loki Chunks   Loki / Graylog
 Network    Syslog         Cribl          PVC           Wazuh

Was die Pipeline tun sollte

  1. Parsen (Syslog → strukturiert)
  2. Normalisieren (Feld-Aliasing auf einheitliches Schema)
  3. Anreichern (GeoIP, Asset-Klassifizierung, User-Attribute)
  4. Filtern (Debug-Logs verwerfen, Health-Checks entfernen)
  5. Routen (Auth-Events → SIEM, App-Logs → Loki)

Beispiel: Vector-Pipeline

[sources.systemd]
type = "journald"

[transforms.parse]
type = "remap"
inputs = ["systemd"]
source = '''
.timestamp = parse_timestamp!(.timestamp, "%+")
.host = get_hostname!()
'''

[sinks.s3_archive]
type = "aws_s3"
inputs = ["parse"]
bucket = "logs-archive-prod"
compression = "gzip"
encoding.codec = "json"

Log-Hygiene: was sonst noch zählt

Stolperfallen

Praxis-Checkliste

Fazit

Logging ist Disziplin, nicht Tool-Wahl. Wer Format, Timestamps und Retention von Anfang an strikt führt, hat im Incident eine durchsuchbare, vergleichbare, vertrauenswürdige Datenbasis – egal, ob das SIEM Wazuh, Graylog oder Loki heißt. Die Investition ist einmalig: ein Schema definieren, Timestamps vereinheitlichen, Retention-Policy aufschreiben. Der Gewinn ist permanent: jede Detection-Rule, jeder Hunt, jede Forensik-Session arbeitet mit sauberen Daten statt mit Format-Chaos.

Wenn du tiefer einsteigen willst: Im Newsletter zeige ich jeden Monat konkrete Logging-Schemas, Vector-Pipelines und Retention-Strategien für KMU. Trag dich ein.

← Zurück zur Übersicht