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

Kernkomponenten eines SIEM:

SIEM-Produkte im Vergleich:

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. 500 Mitarbeiter erzeugen 3-8 GB/Tag = ~€180-480/Tag = ~€5.400-14.400/Monat. Kostensenkung: "Auxiliary Logs" für Low-Value-Quellen (10x günstiger!).

Log-Collection Architecture

Windows Security Event Log - kritische Event IDs:

• 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-Konfiguration (auf jedem Windows-System):

winlogbeat.event_logs:
  - name: Security
    event_id: 4624, 4625, 4688, 4698, 4719, 4720, 4732, 4769, 7045
  - name: Microsoft-Windows-Sysmon/Operational
  - 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): transformiert Log-Streams vor dem 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

Priorisierung nach Häufigkeit in der Realität (MITRE ATT&CK):

• 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 - Kerberoasting Detection (T1558.003):

Hypothese: Angreifer fragt viele TGS-Tickets für SPN-Accounts an. Data Source: Windows Security Event Log (Domain Controller), Event ID 4769 (TGS Request). Erkennungslogik: Event 4769 mit TicketEncryptionType = 0x17 (RC4), nicht von Computer-Account, >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

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" bekannter guter Quellen (z.B. Monitoring-Server mit vielen normalen Logins). 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)

In Microsoft Sentinel: Entity Analytics + Risk Scoring aktivieren - User Account Risk wird automatisch berechnet.

3. Incident Fusion: Mehrere Alerts für denselben User/Asset werden zu einem Incident zusammengefasst. Statt 50 Alerts = 5 Incidents mit Kontext.

4. SOAR-Automatisierung (Tier-1 automatisieren): Beispiel-Playbook "Auto-Triage Impossible Travel": Trigger - Impossible Travel Alert. Schritt 1: User aus AD holen (Abteilung, Manager, Rolle). Schritt 2: Prüfen ob User im Urlaub (HR-System-API). Schritt 3: Prüfen ob VPN aktiv war (bekannte IP). Ergebnis: VPN erklärt den Login - Auto-Close (False Positive). Ungeklärt - Eskalation zu Tier-2 mit Kontext. Einsparung: bis zu 80% der manuellen Triage-Zeit!

SOC-Organisationsmodell

Tier-Modell:

Tier 1 (Level 1 Analyst): Alert Triage (jeder eingehende Alert), Bewertung echte Bedrohung oder False Positive, sofortige Eskalierung bei echten Incidents, Dokumentation aller Aktionen im Ticket.

Tier 2 (Level 2 Analyst): Incident Investigation (eskalierte Incidents), Forensik-Grundkenntnisse, Korrelation verbundener Events, proaktives Threat Hunting.

Tier 3 (Level 3 Analyst): Advanced Threat Hunting, 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:

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