SIEM – Security Information and Event Management

SIEM (Security Information and Event Management) ist eine Plattform, die zwei Disziplinen vereint: das Security Information Management (SIM) – also die Erfassung und Speicherung von Log-Daten – und das Security Event Management (SEM) – die Echtzeit-Analyse und Korrelation von Sicherheitsereignissen. Zusammen bietet ein SIEM eine zentralisierte Sicht auf die gesamte IT-Infrastruktur einer Organisation und ermöglicht die Erkennung von Angriffen, Compliance-Reporting und die forensische Untersuchung von Sicherheitsvorfällen.

Warum SIEM?

Ein SOC-Analyst (Security Operations Centre) ohne SIEM ist wie ein Arzt ohne Diagnosegeräte. Log-Daten fließen aus hunderten oder tausenden Quellen – Firewalls, Endpunkte, Server, Cloud-Plattformen, Applikationen. Ohne ein System, das diese Daten aggregiert und korreliert, ist das Erkennen eines Angriffs nahezu unmöglich.

Laut dem IBM Cost of a Data Breach Report hält sich ein Angreifer im Schnitt 207 Tage unentdeckt in einem Netzwerk auf, bevor er entdeckt wird. Ein gut konfiguriertes und gewartetes SIEM reduziert diese Zeitspanne erheblich.

Kernfunktionen eines SIEM

Funktion	Beschreibung
Log-Aggregation	Sammlung von Logs aller Quellen in einem zentralen Repository
Normalisierung	Parsen unterschiedlicher Log-Formate in ein einheitliches Schema zur Korrelation
Korrelation	Verknüpfung zusammenhängender Ereignisse aus verschiedenen Quellen zur Erkennung von Angriffsketten
Alerting	Generierung von Warnmeldungen, wenn Ereignismuster auf einen Angriff hindeuten
Dashboards	Echtzeit-Visualisierung der Sicherheitslage und laufender Vorfälle
Threat Intelligence	Anreicherung von Ereignissen mit IOC-Daten aus externen Bedrohungsfeeds
UEBA	User and Entity Behaviour Analytics – Erkennung anomaler Aktivitäten durch maschinelles Lernen
Compliance Reporting	Vorgefertigte Berichte für PCI DSS, HIPAA, ISO 27001, DSGVO
Incident Response	Fallverwaltung, Zeitachsen-Rekonstruktion, Beweissicherung
Threat Hunting	Proaktive Suche nach unentdeckten Bedrohungen in historischen Log-Daten

SOC-Struktur und SIEM-Interaktion

Ein SIEM ist das zentrale Werkzeug in einem Security Operations Centre (SOC). Die Analysten sind dabei in Tiers (Ebenen) organisiert:

SOC-Tier	Rolle	SIEM-Interaktion
Tier 1 – Analyst	Dashboard-Überwachung, Alert-Triage	Alerts prüfen, False Positives verwerfen, eskalieren
Tier 2 – Senior Analyst	Untersuchung eskalierter Vorfälle	Tiefe Abfragen, Zeitachsen-Analyse
Tier 3 – Threat Hunter	Proaktive Bedrohungserkennung	Hypothesengetriebene Suche, neue Regelentwicklung
Tier 4 – SIEM Engineer	Plattform-Management	Regel-Tuning, Parser-Entwicklung, Integration
SOC Manager	Programm-Steuerung	Metriken, Reporting, SLA-Management

SIEM-Produkte im Überblick

Es gibt kein universell „bestes" SIEM. Die Wahl hängt von Budget, Teamgröße, bestehender Infrastruktur und den primären Einsatzzielen ab (Compliance vs. Erkennung, Cloud vs. On-Premises).

Produkt	Typ	Besonderheit
Splunk Enterprise / ES	Kommerziell	Marktführer, sehr mächtige SPL-Abfragesprache, teuer (GB-basierte Lizenzierung)
Microsoft Sentinel	Cloud-nativ (Azure)	Tief integriert in Microsoft 365 / Azure, KQL-Abfragesprache, SOAR-Funktionen
IBM QRadar	Kommerziell	Stark in Netzwerkfluss-Analyse, automatische Offense-Generierung, weit verbreitet in Behörden und Finanzsektor
Elastic SIEM (ELK)	Open Source / Kommerziell	Sehr flexibel, gute Visualisierung via Kibana, freie Tier verfügbar
Wazuh	Open Source XDR/SIEM	Kostenlos, agentenbasiert, hervorragend für Linux-Umgebungen, integriert mit ELK
Graylog	Open Source / Kommerziell	Leichter als ELK, schnelle Suche, einfachere Bereitstellung
Security Onion	Open Source NSM	Komplettpaket: Zeek + Suricata + Wazuh + ELK in einer Distribution
Exabeam	Kommerziell UEBA	Spezialisiert auf verhaltensbasierte Erkennung
LogRhythm	Kommerziell	Integrierte SIEM + SOAR-Plattform

Log-Management-Grundlagen

Bevor ein SIEM Bedrohungen erkennen kann, braucht es Logs – und zwar in der richtigen Qualität, aus den richtigen Quellen und für die richtige Aufbewahrungsdauer. Log-Management ist das Fundament, auf dem jedes SIEM aufbaut.

Kritische Log-Quellen

Log-Quelle	Was sie liefert	Priorität
Windows Security Event Log	Anmeldungen, Rechtnutzung, Kontoänderungen, Prozesserstellung	Kritisch
Firewall / NGF-Logs	Erlaubte/verworfene Verbindungen, geografische Anomalien, Port-Scans	Kritisch
DNS-Logs	Domain-Lookups – C2-Erkennung, DNS-Exfiltration	Kritisch
Active Directory / LDAP	Authentifizierung, Gruppenänderungen, GPO-Modifikationen	Kritisch
Endpoint (EDR) Logs	Prozessausführung, Dateiänderungen, Netzwerkverbindungen pro Host	Kritisch
Web Proxy / URL-Filterung	Benutzer-Webaktivität, Malware-Downloads, C2-Callbacks	Hoch
E-Mail-Gateway-Logs	Phishing-Mails, bösartige Anhänge, BEC-Erkennung	Hoch
VPN / Remote-Access-Logs	Wer hat sich von wo verbunden, Credential-Stuffing-Versuche	Hoch
Cloud-Plattform-Logs	AWS CloudTrail, Azure Activity Log, GCP Audit Logs	Hoch
Applikations-Logs	Login-Fehler, API-Missbrauch, Injection-Versuche	Mittel
Datenbank-Audit-Logs	SQL-Abfragen, Schema-Änderungen, Rechteeskalation	Mittel
Netzwerkfluss (NetFlow/IPFIX)	Verkehrsmuster, Lateral Movement, Datenexfiltration	Mittel

Log-Formate

Format	Beschreibung
Syslog (RFC 5424)	Universelles Unix/Linux-Log-Format – Facility, Severity, Message
Windows Event Log (EVTX)	Strukturiertes Windows-Ereignisformat mit Event-IDs
JSON	Strukturiertes Key-Value-Format – bevorzugt von modernen Applikationen und Cloud-Diensten
CEF (Common Event Format)	ArcSight-Standard – weit verbreitet bei Security-Appliances
LEEF (Log Event Extended Format)	IBM QRadar Standard für Netzwerkgeräte
W3C / Combined Log Format	Webserver-Zugriffslogs (Apache, Nginx, IIS)
CSV / Flat File	Datenbank-Exporte, Applikations-Logs – erfordert Parsing

Log-Normalisierung

Unterschiedliche Geräte liefern Logs in unterschiedlichen Formaten. Die Normalisierung überführt diese in ein einheitliches Schema, das die Korrelation ermöglicht. Beispiel: Ein Cisco-ASA-Firewall-Log wird durch Logstash in ein strukturiertes JSON-Format transformiert:

# Roh-Syslog von der Firewall:
# Jan 15 14:23:01 fw01 %ASA-6-302013: Built outbound TCP connection
# 12345 for outside:8.8.8.8/443 to inside:10.1.1.50/54321

# Nach der Normalisierung:
{
  'timestamp'  : '2024-01-15T14:23:01Z',
  'source_ip'  : '10.1.1.50',
  'source_port': 54321,
  'dest_ip'    : '8.8.8.8',
  'dest_port'  : 443,
  'protocol'   : 'TCP',
  'action'     : 'allow',
  'device'     : 'fw01',
  'event_type' : 'network_connection'
}

Log-Aufbewahrungsfristen

Regulierung / Standard	Mindestaufbewahrung
PCI DSS	12 Monate (3 Monate sofort verfügbar)
HIPAA	6 Jahre
ISO 27001	Organisationsdefiniert – typisch mindestens 12 Monate
DSGVO	Nur so lange wie notwendig – Balance mit Sicherheitsanforderungen
NIST CSF	Organisationsdefiniert – 12–24 Monate empfohlen
SOX	7 Jahre für Finanzdaten – mindestens 1 Jahr für IT-Logs
Best Practice (allgemein)	90 Tage Hot Storage, 12 Monate Warm, 3+ Jahre Cold/Archiv

Detection Engineering

Detection Engineering ist die Disziplin des Entwurfs, Aufbaus, Testens und Wartens von Erkennungslogik in einem SIEM. Ein Detection Engineer übersetzt Bedrohungsintelligenz und Angriffswissen in SIEM-Regeln, die bösartiges Verhalten zuverlässig erkennen und dabei False Positives minimieren.

Der Detection Development Lifecycle

Phase	Beschreibung
Phase 1 – Threat Intel	Bedrohung identifizieren: CVE, APT-TTP, Incident-Findings, Threat-Intel-Report
Phase 2 – Hypothese	Hypothese formulieren: „Wenn ein Angreifer Mimikatz einsetzt, greift ein Nicht-System-Prozess auf lsass zu"
Phase 3 – Datenanforderungen	Benötigte Log-Quellen identifizieren: Windows 4688, Sysmon EventID 10 (Prozesszugriff)
Phase 4 – Query-Entwicklung	Erkennungsabfrage im SIEM gegen bekannt-gut und bekannt-schlecht Daten schreiben und testen
Phase 5 – Sigma-Regel	Erkennung in eine Sigma-Regel überführen für Portabilität auf andere SIEM-Plattformen
Phase 6 – Deployment & Tuning	Im SIEM deployen, False-Positive-Rate überwachen, Schwellenwerte und Ausnahmen anpassen
Phase 7 – Test	Mit atomaren Red-Team-Tests oder Purple-Team-Übungen validieren, dass die Erkennung korrekt auslöst

Sigma – Plattformunabhängiges Erkennungsformat

Sigma ist ein offenes, herstellerneutrales Format für SIEM-Erkennungsregeln. Eine Sigma-Regel kann mit dem Tool sigma-cli in die Abfragesprache jeder SIEM-Plattform konvertiert werden.

# Sigma-Regel – Mimikatz LSASS Credential Dumping
title: Mimikatz LSASS Credential Dumping
id: 32d0d3da-b000-4c4d-9cde-5b27b1cb80d8
status: stable
description: Erkennt Nicht-System-Prozesse, die auf den lsass.exe-Speicher zugreifen
references:
  - https://attack.mitre.org/techniques/T1003/001/
tags:
  - attack.credential_access
  - attack.t1003.001
logsource:
  category: process_access
  product: windows
detection:
  selection:
    TargetImage|endswith: '\lsass.exe'
    GrantedAccess|contains:
      - '0x1010'
      - '0x1410'
  filter_legit:
    SourceImage|startswith:
      - 'C:\Windows\System32\'
      - 'C:\Windows\SysWOW64\'
  condition: selection and not filter_legit
falsepositives:
  - Legitime Sicherheitssoftware, die auf LSASS zugreift
level: high

Konvertierung in verschiedene SIEM-Formate:

# sigma-cli installieren
pip3 install sigma-cli

# Konvertierung in Elastic KQL
sigma convert -t elasticsearch-dsl mimikatz_lsass.yml

# Konvertierung in Microsoft Sentinel KQL
sigma convert -t microsoft365defender mimikatz_lsass.yml

# Ganzes Regelverzeichnis konvertieren
sigma convert -t splunk rules/windows/ -o splunk_rules.conf

Threat Hunting mit SIEM

Threat Hunting ist ein proaktiver Ansatz – statt auf einen Alert zu warten, sucht der Threat Hunter aktiv nach Kompromittierungszeichen, die bestehende Regeln möglicherweise übersehen haben. Das SIEM ist dabei die primäre Waffe des Hunters und gibt Zugriff auf Monate historischer Log-Daten.

Der Threat Hunting Loop

Schritt	Beschreibung
1 – Hypothese	Hypothese aus Threat Intel formulieren: „APT29 nutzt WMI für Lateral Movement"
2 – Daten	Benötigte Log-Quellen identifizieren: Sysmon Event 19/20/21 für WMI, Windows Security 4688 für Prozesse
3 – Hunt	SIEM-Abfragen ausführen, um historische Daten nach Belegen für oder gegen die Hypothese zu durchsuchen
4 – Analysieren	Findings untersuchen: Handelt es sich um gutartiges oder bösartiges Verhalten? Zeitachse erstellen, Umfang bestimmen
5 – Reagieren	Bei bestätigter Kompromittierung: Eskalation zum Incident Response. Bei gutartigem Befund: Findings dokumentieren
6 – Erkennung	Erfolgreichen Hunt in eine permanente Erkennungsregel überführen, sodass zukünftige Aktivität automatisch alarmiert

MITRE ATT&CK-Mapping

Threat Hunting und Detection Engineering orientieren sich am MITRE ATT&CK-Framework, das Angriffstaktiken und -techniken systematisch katalogisiert. Jede Erkennung sollte einer oder mehreren ATT&CK-Techniken zugeordnet sein.

Incident Response mit SIEM

Wenn ein SIEM-Alert einen Sicherheitsvorfall bestätigt, wechselt die Plattform vom Erkennungswerkzeug zur Ermittlungsarbeitsstation. Effektive Incident Response mit SIEM umfasst schnelle Beweissicherung, Zeitachsen-Rekonstruktion, Umfangsbestimmung und Eindämmungsmaßnahmen.

IR-Untersuchungs-Workflow

Phase	Beschreibung
Triage	Alert validieren – ist es ein True Positive? Initiale IOCs sammeln (IP, Username, Hostname, Hash)
Umfang	Blast Radius bestimmen: Wie viele Systeme sind betroffen? Wurden Daten exfiltriert? Ist Persistenz etabliert?
Zeitachse	Chronologische Ereigniszeitachse aus SIEM-Daten aufbauen: Erstkontakt, Rechteeskalation, Lateral Movement
Eindämmung	Systeme identifizieren, die isoliert werden müssen; Konten deaktivieren; Netzwerksperren implementieren
Beweise	Rohe Log-Daten aus dem SIEM für forensische Untersuchung und mögliche rechtliche Verfahren exportieren
Behebung	Angreiferzugang entfernen, ausgenutzte Schwachstellen patchen, kompromittierte Zugangsdaten zurücksetzen
Lessons Learned	Vorfall dokumentieren, Erkennungsregeln aktualisieren, Response-Prozeduren verbessern

SIEM-Tuning und Optimierung

Ein frisch deployetes SIEM erzeugt eine enorme Menge an Alerts – der überwiegende Teil davon sind False Positives. Alert-Fatigue ist die häufigste Ursache für SOC-Burnout und verpasste Erkennungen. Kontinuierliches Tuning ist keine optionale Aufgabe, sondern die fortlaufende Arbeit, die entscheidet, ob ein SIEM echten Wert liefert.

Häufige Quellen für False Positives

Quelle	Beispiel
Geplante Tasks	Backup-Software löst „Process Injection"-Regel aus
Vulnerability Scanner	Interner Nessus-Scan löst „Port-Scan"-Alert aus
Service Accounts	Batch-Job erzeugt hunderte Login-Ereignisse
Security Tools	Antivirus erzeugt „LSASS-Zugriff"-Alert
Zu niedrige Schwellenwerte	Alert feuert bei 3 fehlgeschlagenen Logins – zu sensitiv
Breite Regex-Muster	Regel trifft „error" UND „security_error"
Fehlender Kontext	Alert ignoriert Tageszeit – feuert um 9 Uhr für normale Aktivität

Tuning-Workflow

Zeitraum	Maßnahme
Woche 1	Baseline: Regeln deployen, nicht tunen. Jeden Alert dokumentieren und True/False-Positive-Status erfassen
Woche 2	Kategorisieren: False Positives nach Quelle gruppieren. Muster erkennen – kommen sie von bestimmten Hosts, Usern oder Tools?
Woche 3	Whitelisting: Gezielte Ausnahmen hinzufügen. Niemals eine ganze Regel ausschließen – nur spezifische Quellen innerhalb der Regel
Woche 4	Schwellenwerte: Auf Basis der Baseline-Daten anpassen. True-Positive-Rate nach jeder Anpassung überprüfen
Laufend	Monatliches Regel-Review: Jede Regel mit 0 True Positives in 90 Tagen muss untersucht oder entfernt werden

Zielwerte für False-Positive-Raten

Alert-Priorität	Ziel-FP-Rate	Max. Alert-Volumen / Analyst
Kritisch	< 5 %	< 5 pro Tag
Hoch	< 15 %	< 20 pro Tag
Mittel	< 30 %	< 50 pro Tag
Niedrig	< 50 %	Wöchentlich geprüft, nicht täglich

SIEM-Architektur und Deployment

Deployment-Modelle

Modell	Vorteile
On-Premises	Datensouveränität, volle Kontrolle, planbare Kosten
Cloud (SaaS)	Keine Infrastruktur, automatische Skalierung, schnelles Deployment
Hybrid	Sensible Daten On-Premises, Cloud für Skalierung
MSSP-Managed	Kein eigenes SOC-Personal erforderlich, 24/7-Abdeckung

Sizing-Richtlinien

Organisationsgröße	Tägliches Log-Volumen	Empfohlene Plattform
Klein (< 500 Nutzer)	< 10 GB/Tag	Wazuh, Graylog, ELK (Free Tier)
Mittel (500–5.000 Nutzer)	10–100 GB/Tag	Wazuh + ELK
Groß (5.000–50.000 Nutzer)	100 GB – 1 TB/Tag	Splunk Enterprise, QRadar, Sentinel
Enterprise (> 50.000 Nutzer)	> 1 TB/Tag	Splunk Cloud, Sentinel, QRadar on Cloud

Priorisierung beim Log-Onboarding

Beim Aufbau eines SIEM sollten Log-Quellen in dieser Reihenfolge angebunden werden:

Identität: Active Directory / Azure AD (alle Ereignisse)
Perimeter: Firewall, IDS/IPS, Proxy, E-Mail-Gateway
Endpunkte: EDR/AV-Logs, Windows Security + Sysmon
DNS: Alle DNS-Abfragen von allen Resolvern
Cloud: AWS CloudTrail, Azure Activity Log, GCP Audit
Applikationen: Kritische Apps – ERP, HR, Finanzsysteme
Netzwerkfluss: NetFlow/IPFIX von Core-Switches und Routern

Vorlage:Hinweis

Wazuh – Open-Source-SIEM im Praxiseinsatz

Wazuh ist eine freie, quelloffene Sicherheitsplattform mit SIEM-, XDR- und CSPM-Funktionen. Es ist eine der am weitesten verbreiteten Open-Source-Sicherheitsplattformen und ideal für Umgebungen, die kein kommerzielles SIEM finanzieren können, aber dennoch Enterprise-grade-Erkennung benötigen. Wazuh integriert sich nahtlos mit dem ELK Stack zur Visualisierung.

Wazuh-Architektur

Komponente	Rolle
Wazuh Manager	Zentralserver – empfängt Ereignisse, wendet Regeln an, erzeugt Alerts
Wazuh Agent	Leichtgewichtiger Agent auf überwachten Endpunkten – sendet Ereignisse an den Manager
Wazuh Indexer	Elasticsearch-basiertes Storage-Backend für Ereignisse und Alerts
Wazuh Dashboard	Kibana-basierte Oberfläche zum Suchen, Visualisieren und Untersuchen
Filebeat	Transportiert Agent-Daten vom Manager zum Indexer
Active Response	Automatisierte Reaktionsaktionen, die durch spezifische Alerts ausgelöst werden

Installation – All-in-One (Schnellstart)

# Wazuh Quickstart-Installer (installiert Manager + Indexer + Dashboard)
curl -sO https://packages.wazuh.com/4.7/wazuh-install.sh
sudo bash wazuh-install.sh -a

# Nach der Installation – Standard-Zugangsdaten abrufen
sudo tar -O -xvf wazuh-install-files.tar wazuh-install-files/wazuh-passwords.txt

# Dashboard aufrufen: https://YOUR_SERVER_IP
# Standard-Benutzer: admin

Wazuh-Agent auf Linux-Endpunkt deployen

# Wazuh-Repository einrichten
curl -s https://packages.wazuh.com/key/GPG-KEY-WAZUH | sudo apt-key add -
echo "deb https://packages.wazuh.com/4.x/apt/ stable main" \
  | sudo tee /etc/apt/sources.list.d/wazuh.list
sudo apt update && sudo apt install wazuh-agent

# Manager-IP konfigurieren und Agent starten
sudo WAZUH_MANAGER='MANAGER_IP' WAZUH_AGENT_NAME='webserver-01' \
  dpkg-reconfigure wazuh-agent
sudo systemctl start wazuh-agent

Eigene Erkennungsregeln schreiben

Wazuh-Regeln werden in XML definiert und in /var/ossec/etc/rules/local_rules.xml abgelegt:

<!-- Neue Benutzerkonto-Erstellung erkennen -->
<group name="local,useradd,">
  <rule id="100001" level="10">
    <if_group>adduser</if_group>
    <description>Neues Benutzerkonto auf $(hostname) erstellt</description>
    <mitre>
      <id>T1136.001</id>  <!-- Create Account: Local Account -->
    </mitre>
  </rule>
</group>

<!-- SSH-Brute-Force erkennen: 5+ Fehler in 60 Sekunden -->
<rule id="100002" level="12" frequency="5" timeframe="60">
  <if_matched_sid>5710</if_matched_sid>  <!-- SSH auth failure -->
  <description>SSH-Brute-Force-Angriff von $(srcip)</description>
  <group>authentication_failures,pci_dss_11.4,</group>
</rule>

Active Response – Automatische IP-Blockierung

Wazuh kann bei erkannten Angriffen automatisch reagieren, z. B. eine angreifende IP-Adresse für eine definierte Zeit blockieren:

# /var/ossec/etc/ossec.conf – Active Response konfigurieren
# <active-response>
#   <command>firewall-drop</command>
#   <location>local</location>
#   <rules_id>100002</rules_id>
#   <timeout>600</timeout>
# </active-response>

# Wenn Regel 100002 (SSH-Brute-Force) auslöst, blockiert Wazuh
# automatisch die Angreifer-IP für 600 Sekunden via firewall-drop

sudo systemctl restart wazuh-manager

Security Onion – SIEM als Komplettpaket

Security Onion ist eine freie, quelloffene Linux-Distribution für Network Security Monitoring (NSM), Intrusion Detection und Threat Hunting. Sie bündelt Elasticsearch, Kibana, Zeek, Suricata, Wazuh und ein eigenes Case-Management-Tool in einer einzigen deployebaren Plattform.

Komponenten von Security Onion

Komponente	Rolle in Security Onion
Zeek (früher Bro)	Netzwerkprotokoll-Analysator – erzeugt umfangreiche Connection-, HTTP-, DNS- und SSL-Logs
Suricata	IDS/IPS-Engine – signaturbasierte Erkennung, erzeugt Alerts (EVE-JSON-Format)
Elastic Stack	Backend-Storage und -Suche für alle Ereignisse und Alerts
Kibana / SO Dashboards	Primäre Analyseoberfläche mit vorgefertigten Security-Dashboards
Wazuh	Host-basiertes IDS – verarbeitet Endpunkt-Agent-Logs
TheHive	Incident-Response-Fallverwaltung
Navigator	MITRE ATT&CK-Heatmap der Erkennungsabdeckung
CyberChef	Browserbasiertes Datentransformationstool für forensische Analyse

Zeek-Log-Typen

Zeek erzeugt strukturierte Logs für jeden Netzwerkprotokolltyp:

Zeek-Log	Felder	Anwendungsfall
`conn.log`	src/dst IP, Port, Proto, Bytes, Duration	Netzwerk-Baseline, Lateral Movement
`dns.log`	Query, Answers, TTL, Rcode	C2-Erkennung, DNS-Tunneling
`http.log`	URI, Method, User-Agent, Status, Referrer	Web-Bedrohungserkennung
`ssl.log`	Cert Subject, Issuer, JA3-Hash	Verschlüsseltes C2, Zertifikat-Anomalien
`files.log`	Dateiname, MIME-Typ, MD5/SHA1	Malware-Dateiextraktion
`x509.log`	Zertifikatdetails, Gültigkeitsdaten	Selbstsignierte Zertifikate erkennen
`smtp.log`	From, To, Betreff, Anhangsnamen	E-Mail-Bedrohungserkennung
`ssh.log`	Auth-Erfolg/-Fehler, Cipher, Key Exchange	Brute-Force, schwache Krypto

Use Cases und Erkennungsbibliothek

Die folgende Tabelle zeigt typische SIEM-Erkennungsanwendungsfälle, geordnet nach MITRE ATT&CK-Taktik:

MITRE-Taktik	Anwendungsfall	Benötigte Log-Quelle
Initial Access T1566	Phishing – Office spawnt Shell-Prozess	Sysmon / Windows 4688
Initial Access T1190	Web-Exploitation – Web-Shell-Upload	Webserver- / WAF-Logs
Execution T1059.001	PowerShell Encoded Command	PowerShell / Sysmon 1
Execution T1047	WMI-Prozesserstellung	Sysmon 19/20/21
Persistence T1053	Geplante Task-Erstellung	Windows 4698
Persistence T1547	Registry Run Key hinzugefügt	Sysmon 13
Privilege Escalation T1548	UAC-Bypass via eventvwr	Sysmon 1, Windows 4688
Defence Evasion T1055	Process Injection	Sysmon 8/10
Credential Access T1003	LSASS-Speicherauslesen	Sysmon 10
Credential Access T1110	Password Spray (viele User, wenige Fehler je Account)	Windows 4625
Discovery T1046	Netzwerk-Port-Scan von internem Host	Firewall / NetFlow
Discovery T1087	AD-User-Enumeration via LDAP	AD / LDAP-Audit-Logs
Lateral Movement T1021	RDP von ungewöhnlicher Quelle	Windows 4624, Typ 10
Lateral Movement T1075	Pass-the-Hash via NTLM	Windows 4624, Typ 3
Collection T1039	Massenhafter Dateizugriff auf Dateiserver	Windows 4663 / SMB
C2 T1071	HTTP/S C2-Beaconing	Web Proxy / DNS-Logs
C2 T1572	DNS-Tunneling	DNS-Query-Logs
Exfiltration T1041	Großer ausgehender Datentransfer	Firewall / NetFlow
Impact T1486	Ransomware – Dateiendungsänderung	Sysmon 11 / AV-Logs
Impact T1490	Shadow-Copy-Löschung	Windows 4688 / Sysmon 1

Wichtige Windows Event IDs für SIEM

Event ID	Beschreibung	MITRE ATT&CK
4624	Erfolgreiche Anmeldung	TA0001 Initial Access
4625	Fehlgeschlagene Anmeldung	T1110 Brute Force
4634	Abmeldung	Logon-Tracking
4648	Anmeldung mit expliziten Zugangsdaten	T1078 Valid Accounts
4672	Sonderrechte bei Anmeldung zugewiesen	T1078 Valid Accounts
4688	Neuer Prozess erstellt	T1059 Command Execution
4698	Geplanter Task erstellt	T1053 Scheduled Task
4720	Benutzerkonto erstellt	T1136 Create Account
4728	Mitglied zu Sicherheitsgruppe hinzugefügt	T1098 Account Manipulation
4732	Mitglied zu lokaler Gruppe hinzugefügt	T1098 Account Manipulation
4776	NTLM-Credential-Validierung	T1110 Brute Force / T1075 Pass-the-Hash
4768	Kerberos TGT angefordert	T1558 Kerberoasting
4769	Kerberos Service Ticket angefordert	T1558 Kerberoasting
7045	Neuer Dienst installiert	T1543 Create Service

Sysmon Event IDs für SIEM

Sysmon (System Monitor) ist ein Windows-Systemdienst, der detaillierte Prozess-, Netzwerk- und Dateisystem-Aktivitäten protokolliert und damit die Erkennungsfähigkeit von SIEM-Systemen erheblich erweitert:

Sysmon ID	Beschreibung
1	Process Create – CommandLine, ParentImage, Hashes
3	Network Connection – Prozess stellt ausgehende Verbindung her
7	Image Loaded – DLL wird von Prozess geladen (DLL-Injection erkennen)
8	CreateRemoteThread – Thread-Injection-Erkennung
10	ProcessAccess – ein Prozess greift auf einen anderen zu (Mimikatz/LSASS)
11	FileCreate – Datei erstellt oder überschrieben
12/13	Registry-Schlüssel erstellt / Wert gesetzt – Persistenz-Erkennung
15	FileCreateStreamHash – Alternate Data Stream erstellt
17/18	Pipe erstellt / verbunden – Malware-IPC-Erkennung
19/20/21	WMI-Abonnement erstellt – WMI-Persistenz-Erkennung
22	DNS-Query – alle DNS-Lookups mit Prozesskontext
23	File Delete – Datei-Löschung erkennen (Anti-Forensics)
25	Process Tampering – Process Hollowing / Herpaderping

Fazit

Ein SIEM ist ein Kraftmultiplikator – es liefert Wert proportional zur investierten Arbeit in Tuning, Regelentwicklung und Analysten-Training. Die gewählte Plattform ist dabei weniger entscheidend als der Prozess: Ein gut gewartetes Wazuh-Deployment wird eine vernachlässigte kommerzielle SIEM-Installation jederzeit übertreffen.

Für den praktischen Einsatz in Lehrumgebungen eignet sich Wazuh in Kombination mit Security Onion (Zeek + Suricata) als vollständige, kostenlose und praxisnahe SIEM-Plattform, die alle wesentlichen Konzepte demonstrierbar macht.

Weiterführende Links

Siem Überblick