SIEM & SOC Automation — XDR, SOAR & Detection Engineering

SIEM-Architektur & XDR — die Evolution der Sicherheitsüberwachung

Klassische SIEM-Systeme sammeln Log-Daten aus verschiedenen Quellen (Firewalls, Server, Endpunkte, Anwendungen), normalisieren sie und wenden Korrelationsregeln an. Die Herausforderung 2026: Das Datenvolumen explodiert (ein mittelständisches Unternehmen generiert 50–500 GB Logs pro Tag), und die Lizenzkosten steigen mit dem Volumen. XDR (Extended Detection and Response) ist die Antwort: Statt Logs aus getrennten Quellen zu korrelieren, integriert XDR native Telemetrie aus Endpunkt (EDR), Netzwerk (NDR), E-Mail, Cloud und Identität in eine einzige Plattform. Die Korrelation findet vor der Speicherung statt — weniger Datenvolumen, bessere Erkennung.

Die SIEM-Landschaft 2026: Microsoft Sentinel — Cloud-native SIEM auf Azure Log Analytics, native Integration mit Microsoft 365/Entra ID/Defender XDR, KQL-basierte Queries, AI-gestützte Hunting (Security Copilot). Splunk — Marktführer im Enterprise-Bereich, SPL-Abfragesprache, Splunk Enterprise Security (ES) als SIEM-App, seit 2024 Teil von Cisco (Integration mit SecureX/XDR). Elastic Security — Open Source (Elastic License), EQL-basierte Detection Rules, kosteneffizient für große Datenvolumen. CrowdStrike Falcon LogScale (ehem. Humio) — Index-free Log-Ingestion, extrem schnelle Suche, native XDR-Integration mit Falcon. Google Chronicle/SecOps — YARA-L-basierte Detections, 12 Monate Hot Retention zu Festpreis.

• Log-Quellen priorisieren (80/20-Regel): Nicht alle Logs sind gleich wertvoll. Die Top-5-Quellen für Detection: 1) Windows Security Event Logs (4624/4625/4672/4688/4768/4769/4776) + Sysmon. 2) EDR-Telemetrie (Process Creation, Network Connection, File Modification). 3) Firewall/Proxy-Logs (erlaubte und geblockte Verbindungen, DNS-Queries). 4) Entra ID / AD FS Sign-In Logs (OAuth-Token-Ausstellungen, Conditional Access Evaluations). 5) E-Mail-Gateway-Logs (Phishing-Indikatoren, Attachment-Analyse). Diese 5 Quellen decken über 80 % der MITRE ATT&CK-Techniken ab.
• XDR vs. SIEM — wann was? XDR ist ideal für: Unternehmen, die ihre Security-Tools eines Herstellers konsolidieren (Microsoft, CrowdStrike, Palo Alto). Vorteil: Sofort einsatzbereit, vorkonfigurierte Detections, weniger Tuning. Nachteil: Vendor Lock-in, begrenzte Drittanbieter-Integration. SIEM ist ideal für: Multi-Vendor-Umgebungen, Compliance-Anforderungen (langfristige Log-Speicherung), Custom Detection Logic. Vorteil: Flexibilität, herstellerunabhängig. Nachteil: Höherer Aufwand für Betrieb und Tuning. 2026-Trend: Die meisten Unternehmen fahren XDR + SIEM parallel — XDR für Real-Time-Detection, SIEM für Compliance und Hunting.
• Data Engineering für SIEM: Log-Normalisierung ist der größte Schmerzpunkt: Jede Log-Quelle hat ein anderes Format. Lösungen: OCSF (Open Cybersecurity Schema Framework) — Amazon/Splunk-Initiative für ein einheitliches Security-Event-Schema. ECS (Elastic Common Schema) — Elastic-spezifisch, aber weit verbreitet. ASIM (Advanced Security Information Model) — Microsoft-Sentinel-spezifisch. Log-Pipeline: Quelle → Collector (Filebeat, Fluentd, NXLog) → Broker (Kafka, Event Hub) → Parser/Normalization → SIEM-Ingestion. Kosten-Optimierung: Hot/Warm/Cold Tier — die letzten 30 Tage in schnellem Speicher, 90 Tage in warmem Speicher, 1+ Jahr in Cold/Archive (günstig, langsam).
• SOC-Metriken (KPIs): MTTD (Mean Time to Detect) — wie lange dauert es, einen Angriff zu erkennen? Branchendurchschnitt 2025: 204 Tage (IBM Cost of a Data Breach). Ziel: < 24 Stunden. MTTR (Mean Time to Respond) — wie lange dauert es, den Angriff einzudämmen? Branchendurchschnitt: 73 Tage. Ziel: < 4 Stunden. Detection Coverage — welcher Prozentsatz der MITRE ATT&CK-Techniken ist durch mindestens eine Detection Rule abgedeckt? Ziel: > 60 %. Alert-to-Incident Ratio — wie viele Alerts führen zu echten Incidents? < 1 % = zu viel Rauschen. False Positive Rate — Ziel: < 30 % (viele SOCs liegen bei > 70 %).

Detection Engineering — Angriffserkennung als Engineering-Disziplin

Detection Engineering behandelt Detection Rules wie Software: Version Control (Git), Testing (Atomic Red Team), CI/CD-Pipeline (automatische Deployment ins SIEM), Review-Prozess (Peer Review jeder Rule). Der Workflow: 1) Threat Intelligence identifiziert eine relevante Technik. 2) Der Detection Engineer schreibt eine Sigma-Regel (herstellerunabhängig). 3) Die Regel wird mit Atomic Red Team oder Caldera getestet (Simulation der Technik, Validierung der Erkennung). 4) Die Regel wird via pySigma in das Ziel-SIEM-Format konvertiert (KQL/SPL/EQL). 5) Deployment über CI/CD. 6) Regelmäßige Detection Efficacy Reviews.

• MITRE ATT&CK als Detection-Framework: Die ATT&CK-Matrix ist das Standardframework für Detection Engineering: Jede Zelle der Matrix repräsentiert eine Angriffstechnik (z. B. T1003.001 — LSASS Memory Credential Dumping). Für jede Technik: Welche Datenquellen werden benötigt (Process Creation, Process Access, File Creation)? Welche Detection-Logik erkennt die Technik (z. B. „Prozesszugriff auf lsass.exe mit READ_CONTROL + PROCESS_VM_READ“)? ATT&CK Navigator visualisiert Ihre Detection Coverage als Heat Map — rot = keine Detection, grün = abgedeckt. Ziel: Mindestens die Top-15-Techniken (Red Canary Threat Detection Report) vollständig abdecken.
• Sigma-Regeln — das Herz der Detection: Sigma ist ein offenes, YAML-basiertes Detection-Rule-Format mit über 4.000 Community-Regeln. Struktur: title, status, description, logsource (Kategorie + Produkt), detection (Bedingungen), level (informational/low/medium/high/critical), tags (ATT&CK-Mapping). Beispiel: detection: selection: EventID: 4688 / NewProcessName|endswith: '\mimikatz.exe' / condition: selection. Konvertierung: pySigma + Backends (sigma-backend-microsoft365defender, sigma-backend-splunk, sigma-backend-elasticsearch). SigmaHQ = offizielle Rule-Sammlung, SigConverter = Web-basierter Konverter.
• Threat Hunting Hypothesen: Threat Hunting ist proaktive Suche nach Angreifern, die bestehende Detections umgangen haben. Methodik: 1) Hypothese formulieren (z. B. „Ein Angreifer nutzt DLL Side-Loading über signierte Microsoft-Binärdateien“). 2) Datenquellen identifizieren (Sysmon Event 7 — Image Loaded). 3) Query entwickeln (alle DLL-Loads aus ungewöhnlichen Pfaden durch signierte Prozesse). 4) Ergebnisse analysieren (Baseline ausschließen, Anomalien untersuchen). 5) Ergebnis: Entweder Fund (→ Incident) oder neue Detection Rule (→ Prevention). Hunting-Kadenz: Mindestens wöchentlich für kritische Techniken.
• Adversary Simulation & Purple Teaming: Atomic Red Team (Red Canary, Open Source) — Sammlung kleiner, isolierter Tests für jede ATT&CK-Technik. Beispiel: Invoke-AtomicTest T1003.001 simuliert LSASS-Credential-Dumping. Caldera (MITRE, Open Source) — automatisiertes Adversary-Simulation-Framework, plant und führt Angriffsketten aus. Purple Teaming: Red Team und Blue Team arbeiten zusammen — Red simuliert einen Angriff, Blue versucht ihn zu erkennen. Jede nicht erkannte Technik wird als Detection Gap dokumentiert und eine neue Rule erstellt. Ergebnis: Kontinuierliche Verbesserung der Detection Coverage.

SOAR & SOC-Automation — repetitive Arbeit eliminieren

SOAR (Security Orchestration, Automation and Response) automatisiert die Reaktion auf Security-Alerts: Wenn das SIEM einen Alert generiert, führt das SOAR-System ein Playbook aus — eine vordefinierte Abfolge von Aktionen: Kontextanreicherung (IP-Reputation, VirusTotal-Lookup, Benutzer-Profil), Entscheidungslogik (ist der Alert ein True Positive?), und Response-Aktionen (Benutzer sperren, Host isolieren, Firewall-Regel erstellen). 2026-Produkte: Microsoft Sentinel Playbooks (Azure Logic Apps), Splunk SOAR (ehem. Phantom), Palo Alto XSOAR, Tines (No-Code SOAR), Shuffle (Open Source). Der wichtigste Nutzen: Tier-1-SOC-Analysten verbringen 80 % ihrer Zeit mit repetitiven Aufgaben (Alert-Triage, Context-Enrichment) — SOAR automatisiert diese und gibt Analysten Zeit für komplexe Investigations.

• Playbook-Beispiele (High-Value): Phishing-Response: E-Mail-Header extrahieren → URLs in Sandbox prüfen (VirusTotal, urlscan.io) → Anhänge in Sandbox detonieren → IOCs extrahieren → alle Empfänger identifizieren → E-Mail aus allen Postfächern löschen → Absender-Domain blockieren → Ticket erstellen. Impossible Travel: Zwei Logins aus verschiedenen Ländern innerhalb kurzer Zeit → GeoIP-Lookup → VPN-IPs ausschließen → wenn True Positive: Benutzer sperren, Sessions widerrufen, Manager benachrichtigen. Malware auf Endpunkt: EDR-Alert → Host automatisch isolieren → Prozessbaum sammeln → IOCs extrahieren → Netzwerk-Scan nach gleichen IOCs → Ticket eskalieren.
• Alert Fatigue bekämpfen: Das größte SOC-Problem: Zu viele Alerts, zu wenig Zeit. Durchschnitt: 11.000 Alerts pro Tag in einem mittelgroßen SOC, davon < 5 % echte Incidents. Lösungen: Alert-Korrelation — mehrere zusammengehörige Alerts zu einem einzigen Incident zusammenfassen (z. B. Brute Force + Success Login + Lateral Movement = ein Incident statt drei Alerts). Risk-Based Alerting — jedem Alert einen Risk Score zuweisen basierend auf Asset-Kritikalität, Benutzer-Rolle, IOC-Reputation. Nur Alerts über einem Schwellenwert eskalieren. Tuning-Zyklus: Jede Woche die Top-10-False-Positive-Rules identifizieren und die Detection-Logik verfeinern.
• KI im SOC 2026: Microsoft Security Copilot — KI-Assistent für SOC-Analysten: Natürlichsprachliche Incident-Zusammenfassungen, automatische KQL-Query-Generierung, Guided Investigation („Was sollte ich als Nächstes untersuchen?“). CrowdStrike Charlotte AI — konvertiert natürliche Sprache in Threat-Hunting-Queries. SentinelOne Purple AI — übersetzt Fragen in SIEM-Queries über Datenquellen hinweg. Einschränkung: KI-Assistenten sind Augmentation, nicht Ersatz — sie beschleunigen die Analyse, treffen aber keine Entscheidungen. Der Analyst validiert jedes KI-Ergebnis. Halluzinations-Risiko: KI kann falsche Korrelationen herstellen — kritisch bei Incident Response.
• SOC-Reifegradmodell (SOC-CMM): Level 1 — Initial: Reaktiv, keine formalen Prozesse, kein SIEM, manuelle Log-Analyse bei Incidents. Level 2 — Managed: SIEM vorhanden, Basisregeln aktiv, Incident-Response-Plan existiert, 8x5-Betrieb. Level 3 — Defined: Detection Engineering etabliert, Sigma-Regeln in Git, SOAR für Tier-1-Automation, Threat Hunting monatlich, 16x5 oder 24x7 via MSSP. Level 4 — Quantitatively Managed: KPIs (MTTD/MTTR) werden gemessen und optimiert, ATT&CK Coverage > 60 %, Purple Teaming quartalsweise. Level 5 — Optimizing: Continuous Improvement, ML-basierte Anomalie-Erkennung, proaktives Threat Hunting wöchentlich, Detection-as-Code vollständig automatisiert.