Security Operations Center (SOC) und SIEM: Cybersecurity 24/7 überwachen

Ein Security Operations Center (SOC) ist die Schaltzentrale für Cybersecurity-Überwachung und Incident Response. Das SOC kombiniert Menschen, Prozesse und Technologie - mit dem SIEM als technologischem Herzstück. Ohne funktionierendes SOC erkennen Unternehmen Angriffe durchschnittlich erst nach 194 Tagen (IBM Cost of a Data Breach 2024) - häufig nicht selbst, sondern durch externe Meldung.

Was ist ein SOC?

Ein SOC ist eine zentralisierte Funktion (Team + Infrastruktur) die kontinuierlich:

Überwacht - alle IT-Systeme, Netzwerke, Cloud-Umgebungen
Erkennt - Angriffe, Anomalien, Richtlinienverstöße
Analysiert - Kontext, Relevanz und Schwere eines Alerts
Reagiert - Eindämmung, Forensik, Wiederherstellung
Verbessert - Lessons Learned, Detection-Regeln tunen

SOC-Rollen

SOC Tier 1 - Alert Triage Analyst
  ├── Überwacht Alert-Queue 24/7
  ├── Klassifiziert: True Positive / False Positive?
  └── Eskaliert komplexe Fälle an Tier 2

SOC Tier 2 - Incident Responder
  ├── Tiefe Analyse eskalierter Incidents
  ├── Forensik: Was ist passiert? Wie weit?
  └── Koordiniert Remediation

SOC Tier 3 - Threat Hunter / Senior Analyst
  ├── Proaktive Suche nach versteckten Angreifern
  ├── Entwickelt neue Detection-Regeln
  └── Threat Intelligence Integration

SOC Manager
  ├── KPIs und Reporting
  ├── Team-Entwicklung
  └── Prozess-Optimierung

Was ist ein SIEM?

Ein Security Information and Event Management (SIEM) ist die Plattform die alle Sicherheits-relevanten Logs zentralisiert und korreliert.

Log-Quellen die ein SIEM aggregiert:

Firewalls, IDS/IPS, WAF
Active Directory / Entra ID (Logon-Events)
Endpoint Security / EDR
Cloud-Logs (AWS CloudTrail, Azure Activity Log, GCP Audit)
Anwendungs-Logs (Web-Server, Datenbank, SAP)
DNS-Logs
E-Mail-Gateway-Logs
VPN-Logs

SIEM-Architektur

Logquellen                  SIEM                     Analysten-Interface
──────────                  ────                     ─────────────────
Firewall ──────────────→   Collector                         ↑
EDR ────────────────────→  Normalizer  →  Correlation    Dashboards
Active Directory ───────→  Enrichment     Engine     →  Alert-Queue
Cloud-Logs ─────────────→  Storage        UEBA          Threat Hunting
Endpoints ──────────────→                ML-Engine      Investigations

UEBA - User and Entity Behavior Analytics

Modernes Ergänzungsmodul zum SIEM:

Erstellt Baseline-Verhalten für jeden User und Host
Erkennt Abweichungen: “User greift nie auf Finanzserver zu - jetzt plötzlich ja”
Nützlich für Insider Threats und Stolen Credentials

SIEM Use Cases: Was wird erkannt?

Use Case 1: Brute Force / Credential Stuffing

Regel: Mehr als 10 fehlgeschlagene Logins eines Accounts innerhalb 5 Minuten
       UND anschließend erfolgreicher Login

→ Alert: "Possible Brute Force + Successful Login"
→ Sofortmaßnahme: Account sperren, User kontaktieren

Use Case 2: DCSync-Angriff (Active Directory)

Regel: Replikations-Request vom DRSUAPI zu Domain Controller
       VON einer Maschine die kein Domain Controller ist

→ Alert: "Possible DCSync Attack (Golden Ticket Preparation)"
→ Sofortmaßnahme: System isolieren, Forensik starten

Use Case 3: Kerberoasting

Regel: Mehr als 20 TGS-Requests für verschiedene SPNs
       innerhalb 2 Minuten
       von einem einzigen Account

→ Alert: "Possible Kerberoasting Activity"
→ Sofortmaßnahme: Account analysieren, betroffene Service-Accounts prüfen

Use Case 4: Lateral Movement

Korrelation über 3 Log-Quellen:
1. EDR: "Mimikatz-ähnliche Aktivität auf Host A"
2. AD-Log: "Account X" gibt sich als anderer User aus (über-the-Pass-the-Hash)
3. Firewall-Log: SMB-Verbindung von Host A zu DC01

→ Alert: "Confirmed Lateral Movement to Domain Controller"
→ Sofortmaßnahme: P1 Incident, Netzwerksegmentierung aktivieren

Use Case 5: Datenexfiltration

Regel: Mehr als 500MB ausgehende Daten
       zu einer Domain die < 30 Tage alt ist
       zwischen 02:00 - 05:00 Uhr

→ Alert: "Possible Data Exfiltration"
→ Kontext: Betroffener Host, User, Datenmenge

SIEM-Markt: Führende Lösungen

Lösung	Hersteller	Positionierung
Microsoft Sentinel	Microsoft	Cloud-nativ, hervorragend für M365/Azure
Splunk Enterprise Security	Cisco/Splunk	Mächtiger Enterprise-Standard, teuer
IBM QRadar	IBM	Enterprise, on-premises Stärke
Google Chronicle	Google	Cloud-native, AI-Integration
Elastic SIEM	Elastic	Open Source Basis, sehr flexibel
LogRhythm	LogRhythm	Mid-Market SIEM + SOAR
Wazuh	Wazuh (Open Source)	Kostenlos, für KMU sehr geeignet

SOAR - Security Orchestration, Automation and Response

SOAR ergänzt das SIEM um automatische Reaktion:

# Beispiel SOAR Playbook: Phishing Alert
trigger: SIEM Alert "Phishing E-Mail erkannt"
actions:
  1. E-Mail automatisch unter Quarantäne stellen
  2. Alle ähnlichen E-Mails in Mailboxen suchen und löschen
  3. Absender-Domain auf Blacklist setzen
  4. Betroffene User benachrichtigen
  5. Ticket in ITSM erstellen
  6. SOC-Analyst über Slack informieren
# Manuell: Analyst bestätigt und schließt Ticket

SOAR reduziert Mean Time to Respond (MTTR) von Stunden auf Minuten.

SOC-Modelle: Eigenes SOC vs. MSSP

Eigenes SOC (In-House SOC)

Vorteile:

Vollständige Kontrolle und Datensouveränität
Tiefes Unternehmenswissen (Systeme, Prozesse, Business Context)
Keine Datenweitergabe an Dritte

Nachteile:

Hohe Kosten: 3-5 Vollzeit-Analysten für 24/7, plus SIEM-Lizenz
Schwieriges Recruiting (Fachkräftemangel)
Anfangsjahre oft mit hoher False-Positive-Rate (Tuning nötig)

Jahreskosten (Schätzung, Deutschland):

3 Tier-1-Analysten (24/7 in Schichten): ~300.000 €/Jahr
1 Tier-2/3-Analyst: ~90.000 €/Jahr
SIEM-Lizenz (Microsoft Sentinel / Splunk): 50.000-500.000 €/Jahr
Gesamt: 500.000 € - 1 Mio. € / Jahr

MSSP - Managed Security Service Provider

Vorteile:

Sofort operationell (Wochen statt Monate)
24/7 ohne eigenes Recruiting-Problem
Umfassendes Threat Intelligence (Multi-Tenant Sichtbarkeit)
Planbare monatliche Kosten

Nachteile:

Datenweitergabe an Drittanbieter (Datenschutz beachten)
Weniger unternehmensspezifisches Wissen am Anfang
Abhängigkeit vom Anbieter

Marktführer DACH: Telekom Security, NTT Security, Atos, Controlware, DXC.

Hybrid-Modell (SOC-as-a-Service ergänzt intern)

Für Mittelstand oft optimal:

Interne IT/Security: Konfiguration, Asset Management, Business Context
MSSP: 24/7-Überwachung und Tier-1-Triage
Eskalation an interne Experten oder MSSP-Tier-2

KPIs für SOC-Performance

KPI	Beschreibung	Zielwert
MTTD	Mean Time to Detect (Wie lange bis Angriff erkannt?)	< 1 Stunde
MTTR	Mean Time to Respond (Wie lange bis Reaktion?)	< 4 Stunden
False Positive Rate	Anteil von Alerts die kein echtes Problem sind	< 10%
Alert Backlog	Unbearbeitete Alerts in Queue	0
Coverage	% der Systeme die Logs senden	> 95%
Dwell Time	Wie lange war Angreifer unentdeckt?	< 7 Tage

Compliance-Anforderungen

NIS2 Art. 21: Monitoring und Anomalie-Erkennung explizit gefordert für wesentliche Einrichtungen.

ISO 27001 A.8.15 (Logging): Aktivitätsaufzeichnung; A.5.25 (Incident Response) - SOC ist die organisatorische Umsetzung.

BSI IT-Grundschutz DER.1: Detektion von Sicherheitsvorfällen - detaillierte Anforderungen an Monitoring.

DORA (Finanzsektor): Art. 11 - kontinuierliches IKT-Monitoring als Pflicht für Finanzinstitute.

Aufbau-Roadmap: SOC in 12 Monaten

Monat 1-2:  SIEM-Deployment, Log-Quellen anbinden (AD, Firewall, EDR)
Monat 3-4:  Basis Use Cases entwickeln (15-20 Regeln), False Positive Rate senken
Monat 5-6:  SOAR-Integration, erste Automatisierungen
Monat 7-9:  Threat Hunting einführen, UEBA aktivieren
Monat 10-12: 24/7 Betrieb, Tier-1-Team ausgebildet

Alternativ: MSSP für erste 12-24 Monate, parallel intern Know-how aufbauen.