SIEM und SOC aufbauen: Von Log-Collection bis Incident Response

Ein SIEM zu installieren ist einfach - ein SIEM das wirklich Angriffe erkennt aufzubauen, ist schwer. Der Unterschied liegt in durchdachten Use Cases, sauberer Log-Collection und einem Team das die Alerts versteht. Dieser Guide zeigt den Weg vom leeren SIEM zu effektiver Angriffserkennung.

SIEM-Grundarchitektur

Was ein SIEM tut (und was es braucht):

Komponenten:
  Log-Sources:      Windows Events, Linux Syslog, Firewall, EDR, Cloud
  Collection:       Syslog-Server, Winlogbeat, Fluentd, Cribl
  Normalization:    ECS (Elastic), CEF, OCSF (AWS/Microsoft) → einheitliches Format
  Storage:          Hot (1-30 Tage), Warm (30-90 Tage), Cold (90+ Tage, S3/Glacier)
  Analytics:        Correlation Engine, Anomaly Detection, ML
  Alerting:         Incidents/Cases → SOAR → Tickets
  Dashboards:       SOC-Übersicht, Threat-Hunting, Compliance

SIEM-Produkte:
  Microsoft Sentinel:   Azure-native, KQL, Pay-per-GB, integriert mit Defender
  Splunk:               Marktführer, mächtig, teuer ($), SPL-Sprache
  Elastic SIEM:         Open-Source-Basis, ECS, freie Variante möglich
  IBM QRadar:           Enterprise, komplex, aber viele Konnektoren
  LogRhythm:            Mid-Market-Fokus
  Wazuh:                Open-Source-SIEM/XDR (OSSEC-Basis)

Empfehlung für Einsteiger:
  → Microsoft 365 / Azure → Sentinel (native Integration, 90 Tage gratis!)
  → Kleinunternehmen → Wazuh (kostenlos, funktional)
  → Enterprise → Splunk oder Sentinel je nach Budget

Kostenrechnung Sentinel:
  → ~2 EUR / GB Ingest (Log-Daten)
  → 500 Mitarbeiter: 3-8 GB/Tag = ~€180-480/Tag = ~€5.400-14.400/Monat
  → Reduktion: "Auxiliary Logs" für Low-Value-Quellen (10x günstiger!)

Log-Collection Architecture

Quellen und Collection-Strategien:

Windows Event Logs (kritische Events):
  # Windows Security Event Log:
  4624: Erfolgreicher Login (alle Typen!)
  4625: Fehlgeschlagener Login
  4648: Login mit expliziten Credentials (runas!)
  4688: Prozess gestartet (Command Line!)
  4698: Scheduled Task erstellt
  4719: Audit-Richtlinie geändert
  4720: User erstellt
  4732: User zu privilegierter Gruppe hinzugefügt
  4769: Kerberos TGS-Anfrage
  7045: Neuer Service installiert

  # Sysmon-Erweiterungen (von Microsoft, kostenlos):
  Event 1:  Prozess erstellt (Hash, CommandLine, ParentProcess)
  Event 3:  Netzwerkverbindung (IPv4/IPv6, Port, Process)
  Event 7:  DLL geladen (Image Loaded)
  Event 8:  Remote Thread erstellt (Code Injection!)
  Event 11: Datei erstellt
  Event 13: Registry-Wert gesetzt
  Event 15: File Stream erstellt (MOTW!)
  Event 22: DNS-Anfrage (DNS-Logging!)
  Event 25: Prozess manipuliert (Process Tampering)

  # Sysmon-Config (empfohlen: SwiftOnSecurity):
  sysmon64.exe -accepteula -i sysmonconfig.xml

Winlogbeat (Collection):
  # Winlogbeat auf jedem Windows-System:
  winlogbeat.yml:
  winlogbeat.event_logs:
    - name: Security
      event_id: 4624, 4625, 4688, 4698, 4719, 4720, 4732, 4769, 7045
    - name: Microsoft-Windows-Sysmon/Operational
      # Alles von Sysmon!
    - name: Windows PowerShell
      event_id: 4103, 4104  # Script Block Logging!

  output.logstash:
    hosts: ["siem-collector:5044"]

Linux Syslog:
  # Wichtige Quellen: /var/log/auth.log, /var/log/syslog, auditd
  # Auditd-Regeln:
  -a always,exit -F arch=b64 -S execve -k process_exec
  -w /etc/passwd -p wa -k user_modification
  -w /etc/sudoers -p wa -k sudoers_modification

  # rsyslog → Sentinel/Splunk/Elastic:
  *.* @siem-collector:514

Cloud-Logs:
  # AWS CloudTrail → S3 → Sentinel/Splunk
  # Azure Activity Log → direkt in Sentinel (nativ!)
  # GCP Audit Logs → Pub/Sub → SIEM

Normalisierung mit Cribl (Stream-Processing):
  # Cribl: transformiert Log-Streams vor SIEM
  → Sensitive Felder redaktieren (Passwörter, Tokens)
  → Duplizierte Logs herausfiltern (Kosten sparen!)
  → Log-Format transformieren (CEF → ECS → Splunk)
  → Routing: kritische Logs → Hot Storage, Low-Value → Cold

Use Case Entwicklung

MITRE ATT&CK-basierte Use Cases:

Priorisierung (nach Häufigkeit in der Realität):
  T1078: Valid Accounts (Credential Theft)
  T1059: Command and Scripting Interpreter
  T1003: Credential Dumping
  T1021: Remote Services (Lateral Movement)
  T1071: C2 over Standard Protocol

Use Case Template:
  Name:        Kerberoasting Detection
  ATT&CK:      T1558.003
  Hypothese:   Angreifer fragt viele TGS-Tickets für SPN-Accounts an
  Data Source: Windows Security Event Log (Domain Controller)
  Event IDs:   4769 (TGS Request)

  Logic:
  → 4769 mit TicketEncryptionType = 0x17 (RC4)
  → Nicht von Computer-Account (Account enthält "$")
  → > 5 verschiedene ServiceNames in 5 Minuten
  → Von derselben IP/Account

  Microsoft Sentinel KQL:
  SecurityEvent
  | where EventID == 4769
  | where TicketEncryptionType == "0x17"
  | where ServiceName !endswith "$"
  | where AccountType == "User"
  | summarize
      CountDistinctSPNs = dcount(ServiceName),
      SPNs = make_set(ServiceName),
      DCs = make_set(Computer)
    by Account, IpAddress, bin(TimeGenerated, 5m)
  | where CountDistinctSPNs > 5
  | extend Severity = "High"

  Splunk SPL:
  index=windows EventCode=4769 Ticket_Encryption_Type=0x17
  NOT Service_Name="*$"
  | stats dc(Service_Name) AS unique_spns values(Service_Name) AS spns
    by Account_Name, Client_Address
  | where unique_spns > 5
  | eval severity="High"

Kritische Use Cases (Mindeststandard):
  □ Brute-Force Login (4625: > 10 in 5 Min.)
  □ Password Spray (viele Accounts, wenige Versuche je Account)
  □ Impossible Travel (Login von zwei Ländern gleichzeitig)
  □ New Admin Account erstellt (4720 + 4732 für Admins-Gruppe)
  □ Kerberoasting (s.o.)
  □ DCSync (AD-Replikation von Nicht-DC)
  □ Pass-the-Hash (NTLM-Auth von ungewöhnlicher Quelle)
  □ PowerShell Encoded Commands (Base64)
  □ LOLBin Execution (mshta/regsvr32/certutil mit HTTP-URL)
  □ Scheduled Task erstellt außerhalb von Softwareverteilung
  □ New Service installiert (7045)

Alert-Fatigue bekämpfen

Das #1 Problem in SOCs:

Alert-Fatigue-Ursachen:
  → Zu viele False Positives (SIEM-Rules zu weit kalibriert)
  → Keine Priorisierung (jeder Alert = gleiche Dringlichkeit)
  → Kein Kontext (Alert sagt "anomaler Login" aber nicht: von wem, wo, welche App)
  → Doppelte Alerts (SIEM + EDR + Firewall = 3x gleicher Vorfall)

Gegenmaßnahmen:

1. Alert-Tuning (iterativ!):
   → Jede Rule bekommt eine "Exception-Liste": bekannte gute Quellen
   → z.B. Monitoring-Server → viele Logins normal → exclusion
   → Regelmäßige Überprüfung: welche Rules haben > 90% False Positives?

2. Risk-Scoring:
   → Jeder Alert + User-Risk + Asset-Criticality = Risk Score
   → Score < 30: automatisch schließen + loggen
   → Score 30-70: Tier-1 Analyst (5-10 Min.)
   → Score > 70: Tier-2 Analyst (sofort)

   # Sentinel: Entity Analytics + Risk Scoring aktivieren
   # User Account Risk wird automatisch berechnet!

3. Incident Fusion:
   → Mehrere Alerts für denselben User/Asset → ein Incident
   → Statt 50 Alerts = 5 Incidents mit Kontext

4. SOAR-Automatisierung (Tier-1 automatisieren):
   # Playbook: Auto-Triage für "Impossible Travel":
   Trigger: Impossible Travel Alert
   Action 1: Hole user aus AD (abteilung, manager, rolle)
   Action 2: Prüfe ob User im Urlaub (HR-System-API)
   Action 3: Prüfe ob VPN aktiv war (bekannte IP)
   Wenn VPN erklärt den Login: Auto-Close (False Positive)
   Wenn ungeklärt: Eskaliere zu Tier-2 mit Kontext
   → Spart 80% der manuellen Triage-Zeit!

SOC-Organisationsmodell

SOC-Struktur und Betriebsmodelle:

Tier-Modell:
  Tier 1 (Level 1 Analyst):
  → Alert Triage (jeder eingehende Alert)
  → Scope: echte Bedrohung oder False Positive?
  → Eskalierung: sofort bei echten Incidents
  → Dokumentation: alle Aktionen im Ticket

  Tier 2 (Level 2 Analyst):
  → Incident Investigation (eskalierte Incidents)
  → Forensik-Grundkenntnisse
  → Korrelation: verbundene Events identifizieren
  → Threat Hunting: proaktive Suche

  Tier 3 (Level 3 Analyst):
  → Threat Hunting (Advanced)
  → Rule-Tuning und -Entwicklung
  → Malware-Analyse (statisch + dynamisch)
  → Penetration Testing Support (offensive Kenntnisse)
  → Tool-Entwicklung (SOAR-Playbooks, Custom Detektionen)

  Threat Intel (eigene Rolle oder Tier-3):
  → TI-Feeds verwalten (VirusTotal, MISP, Recorded Future)
  → IOC-Integration in SIEM
  → Strategic Intelligence für C-Level

Betriebsmodelle:
  Intern-SOC:
  → Volle Kontrolle, tiefes Kontext-Wissen
  → Kosten: 3-5 Analysten = 500k+ EUR/Jahr
  → Problem: 24/7 besetzung, Nacht/Wochenende

  MSSP (Managed Security Service Provider):
  → 24/7 Monitoring ohne eigenes Team
  → Kosten: 3.000-30.000 EUR/Monat
  → Problem: weniger Kontext, SLA-gebunden

  Hybrid (empfohlen für Mittelstand):
  → Tag: eigenes Team (tiefes Wissen, Ownership)
  → Nacht/Wochenende: MSSP-Übernahme
  → Bestes beider Welten!

24/7 SOC mit kleinem Team:
  → PagerDuty-Rotation: wer ist on-call?
  → Alert-Threshold erhöhen: nur P1/P2 zu Nachtzeiten
  → SOAR: viele Alerts automatisch behandeln
  → MSSP als Backup: eskaliert wenn on-call nicht antwortet