Security Operations Center (SOC) aufbauen: Strategie, Tools und Betrieb

“Wir haben ein SIEM” - das ist kein SOC. Ein SIEM ohne Analysten ist wie eine Alarmanlage ohne Wachdienst: es piept, aber niemand reagiert. Ein echtes Security Operations Center ist eine organisatorische Funktion, kein Tool. Es kombiniert Menschen, Prozesse und Technologie zur kontinuierlichen Erkennung und Reaktion auf Sicherheitsvorfälle.

SOC-Grundfunktionen

Ein modernes SOC erfüllt fünf Kernfunktionen, die zusammen eine vollständige Sicherheitsoperationsfähigkeit ergeben.

1. Monitoring und Triage

Das SOC überwacht kontinuierlich alle sicherheitsrelevanten Systeme. Alerts werden triagiert - False Positives von echten Incidents getrennt - und nach Schwere und Business Impact priorisiert.

2. Incident Response

Bei bestätigten Incidents folgt eine strukturierte Reaktion: Containment, Eradication und Recovery. Das SOC koordiniert die Kommunikation mit Management und Behörden.

3. Threat Intelligence

IOCs werden in das Monitoring integriert. Emerging Threats werden proaktiv berücksichtigt, und die Verwaltung von Threat-Intelligence-Feeds ist laufende Aufgabe.

4. Vulnerability Management

Das SOC koordiniert Schwachstellen-Scanning und priorisiert Patches anhand von Threat-Intelligence-Daten. SLA-Tracking für die Remediation stellt sicher, dass kritische Lücken zeitnah geschlossen werden.

5. Detection Engineering

Neue Detection Rules werden entwickelt, bestehende Rules getuned, um False Positives zu reduzieren. Threat Hunting - die proaktive Suche ohne vorherigen Alert-Trigger - ist die fortgeschrittenste Funktion.

SOC-Tier-Modell

Tier 1 - Alert Analyst (L1)

L1-Analysten prüfen eingehende Alerts aus SIEM und anderen Tools, führen die Triage durch (real oder False Positive?), führen standardisierte Playbooks aus und eskalieren bei bestätigtem Incident an L2.

Erforderliche Skills: SIEM-Bedienung, Netzwerkgrundlagen, Standard-Protokolle. Arbeitsweise: Schichtbetrieb, hohes Alert-Volumen, Routine-Tasks. Im MSSP-Betrieb liegt das Verhältnis bei etwa 1 L1-Analyst pro 500-1.000 verwaltete Endpoints.

Tier 2 - Incident Responder (L2)

L2-Analysten führen tiefgehende Analysen eskalierter Incidents durch, wenden Digital Forensics an (Memory-Dumps, Disk-Images, Log-Analyse), koordinieren Containment und Eradication, schreiben IR-Berichte und werten Threat Intelligence aus.

Erforderliche Skills: Malware-Analyse, Forensik, EDR-Expertise, Scripting. Arbeitsweise: Unregelmäßig, tiefe Analyse, mehrere parallele Incidents.

Tier 3 - Threat Hunter und Detection Engineer (L3)

L3 betreibt proaktives Threat Hunting ohne Alert-Trigger, entwickelt und validiert Detection Rules, setzt Red-Team-Findings in Detection um, bewertet und verbessert das SOC-Tooling und produziert (statt nur zu konsumieren) Threat Intelligence.

Erforderliche Skills: Advanced Adversarial Techniques, MITRE ATT&CK, Sigma Rules, KQL/SPL. Verhältnis: etwa 1 L3 pro 4-6 L1/L2-Analysten.

Typische SOC-Größen

Größe	L1	L2	L3
Klein (KMU-MSSP)	3-5	1-2	1 (geteilt)
Mittel	8-15	3-5	2-3
Groß (Enterprise)	20+	10+	5+, eigenes Threat-Intel-Team

Technologie-Stack

1. SIEM (Security Information and Event Management)

Microsoft Sentinel ist cloud-nativ mit Azure-nativer Integration und der KQL-Abfragesprache. Machine Learning ermöglicht UEBA (User Entity Behavior Analytics). Preis: ca. 2-8 USD/GB je nach Ingestion-Plan. Stärke: M365-Integration, SOAR integriert, Sentinel Fusion.

Splunk Enterprise Security ist der Marktführer mit der mächtigen SPL-Abfragesprache und einer sehr flexiblen Detection-Engineering-Plattform. Preis: hoch (ca. 150-200 USD/GB/Tag oder per Workload). Stärke: großes Ecosystem (Splunkbase Apps), riesige Community.

IBM QRadar ist ein bewährter Enterprise-SIEM-Veteran mit stabilem Betrieb, QRadar SOAR für Incident Management, und Stärken im Compliance Reporting und klar strukturiertem Alert-System.

Elastic SIEM basiert auf Open-Source-Elasticsearch, unterstützt Sigma-kompatible Detection Rules und bietet einen günstigen Einstieg bei jedoch höherem Betriebsaufwand.

2. SOAR (Security Orchestration, Automation and Response)

SOAR automatisiert repetitive Triage-Tasks und führt Playbooks aus nach dem Prinzip “Wenn Alert X → dann tue Y”.

Beispiel-Playbook für einen Phishing-Alert:

Trigger: Phishing-Alert aus der E-Mail-Security. Automatisch ausgeführte Schritte:

1. Header analysieren - Absender-Reputation prüfen
2. URLs in Sandbox detonieren (URLScan.io, Hybrid Analysis)
3. Betroffene Mailbox identifizieren
4. Bei Bestätigung: E-Mail aus allen Postfächern löschen
5. Ticket in ITSM erstellen
6. L1-Alert: “Bitte Nutzer kontaktieren”

Ein solches Playbook spart 15-30 Minuten manuelle Arbeit pro Alert.

Verfügbare Produkte: Palo Alto XSOAR (Cortex), Splunk SOAR, Microsoft Sentinel (integriert), Swimlane, Tines, Torq sowie TheHive + Cortex (Open Source).

3. Threat Intelligence Platform (TIP)

Eine TIP verwaltet IOC-Feeds (IPs, Domains, Hashes, CVEs) und reichert Alerts an (“Ist diese IP bekannt bösartig?”). MISP (Open Source) ermöglicht Community-basiertes Sharing. Kommerzielle Optionen sind ThreatConnect, Anomali und Recorded Future. Die Integration in SIEM und EDR ermöglicht automatischen Abgleich gegen die TIP-Datenbank.

4. EDR (Endpoint Detection and Response)

EDR liefert vollständige Endpoint-Telemetrie: alle Prozesse, Netzwerkverbindungen, Registry-Änderungen. Bei verdächtiger Aktivität wird ein Alert ausgelöst, und Remote-Response ist möglich: Isolation von Endpoints, Prozessbeendigung, forensische Analyse. Führende Produkte: Microsoft Defender for Endpoint, CrowdStrike Falcon, SentinelOne, Cortex XDR.

5. NDR (Network Detection and Response)

NDR analysiert Netzwerk-Traffic (PCAP, NetFlow) und ist besonders wertvoll für die Erkennung von East-West-Traffic (laterale Bewegung im internen Netz). Auch verschlüsselter Traffic kann über Metadaten-Analyse bewertet werden. Produkte: Darktrace, ExtraHop, Vectra AI, Stamus Networks (Suricata-basiert).

6. Vulnerability Management

Kontinuierliche Scan-Ergebnisse werden im SOC-Kontext priorisiert. Entscheidend ist: Welche ungepatchten CVEs werden aktiv ausgenutzt (EPSS-Score)? Relevante Tools: Qualys VMDR, Tenable.io, Rapid7 InsightVM.

Detection Engineering

Detection Engineering ist der systematische Ansatz zur Erstellung, Validierung und Pflege von Alert-Regeln.

MITRE ATT&CK-basierte Detection

Das Vorgehen folgt einem strukturierten Prozess:

1. Identifizieren, welche Techniken für die eigene Branche relevant sind (Threat Intelligence: “APT41 nutzt T1059.001 PowerShell”)
2. Bestimmen, welche Log-Quellen diese Technik abdecken (Windows Event ID 4104 für PowerShell Script Block Logging)
3. Detection Rule schreiben

KQL-Beispiel: Verdächtige PowerShell-Ausführung (Microsoft Sentinel)

SecurityEvent
| where EventID == 4104
| where ScriptBlockText has_any (
    "IEX", "Invoke-Expression",
    "DownloadString", "WebClient",
    "Base64", "frombase64string",
    "-EncodedCommand", "bypass"
  )
| where ScriptBlockText !has "WindowsDefender"  // Ausschluss bekannter FP
| project TimeGenerated, Computer, Account, ScriptBlockText
| order by TimeGenerated desc

Sigma Rules: Vendor-agnostische Detection

Sigma ist ein standardisiertes Detection-Rule-Format, das in beliebige SIEM-Systeme konvertiert werden kann. Das Sigma-Repository auf GitHub (SigmaHQ/sigma) enthält über 6.000 fertige Rules. Die Konvertierung erfolgt mit sigmac oder pySigma.

Sigma-Beispiel: Golden Ticket Attack

title: Kerberos Golden Ticket - Encryption Type Anomaly
status: stable
tags:
  - attack.credential_access
  - attack.t1558.001
detection:
  selection:
    EventID: 4769
    TicketEncryptionType: '0x17'  # RC4 - veraltet und verdächtig
  filter:
    IpAddress: '::1'
  condition: selection and not filter
falsepositives:
  - Legacy-Anwendungen, die RC4 benötigen

Alert-Qualitätskriterien

• Precision (Alert-Präzision): TP / (TP + FP) - Ziel: > 80 %
• Recall (Erkennungsrate): TP / (TP + FN)
• False Positive Rate: kontinuierlich messen und reduzieren
• Alert Fatigue: mehr als 100 Alerts pro Tag für einen L1-Analysten ist ein Qualitätsproblem

Threat Hunting

Threat Hunting ist die proaktive Suche nach Angreifern im Netzwerk - ohne vorherigen Alert-Trigger.

Das Hunting-Modell

1. Hypothese formulieren: “APT-Gruppen, die unsere Branche angreifen, nutzen Living-off-the-Land-Techniken”
2. Datenquellen identifizieren: Windows Process Execution Logs (Sysmon Event 1), Network Traffic Logs (NetFlow), PowerShell Script Block Logs
3. Hunt durchführen: Suche nach Anomalien ohne Alert-Trigger; statistische Auswertung ungewöhnlicher Prozess-Parent-Child-Beziehungen; Vergleich mit der Baseline (“dieser Host macht normalerweise X, heute Y”)
4. Ergebnis auswerten: Nichts gefunden → Baseline verbessert, Hypothese entkräftet. Etwas gefunden → IR-Prozess starten + Detection Rule für die Zukunft erstellen

Beispiel-Hunt: Lateral Movement via PsExec

SecurityEvent
| where EventID == 4688
| where ParentProcessName has_any ("services.exe", "psexesvc.exe")
| where NewProcessName has_any ("cmd.exe", "powershell.exe", "wscript.exe")
| summarize count() by Computer, ParentProcessName, NewProcessName
| where count_ > 3

Hunting-Frameworks

• MITRE ATT&CK: Taktiken als strukturierte Hunting-Hypothesen
• TaHiTI (Targeted Hunting integrating Threat Intelligence): strukturierter Hunting-Prozess
• PEAK Hunting Framework: Prepare, Execute, Act with Knowledge

SOC-KPIs und Metriken

Operative KPIs

Mean Time to Detect (MTTD) misst die Zeit vom Incident bis zum ersten Alert. Ziel: unter 24 Stunden (SANS SOC Survey Benchmark: 74 % der Incidents in unter 24 Stunden erkannt). Gemessen wird die Differenz zwischen Incident-Zeitstempel und dem ersten Alert-Zeitstempel.

Mean Time to Respond (MTTR) misst die Zeit vom Alert bis zum Containment. Ziel: unter 4 Stunden für kritische Incidents. Zum Vergleich: Der IBM Cost of a Data Breach Report zeigt durchschnittlich 207 Tage ohne SOC gegenüber unter 30 Tagen mit SOC.

False Positive Rate gibt den Anteil der Alerts an, die kein echter Incident sind. Der Branchenbenchmark liegt bei 45 % (Gartner). Das Ziel nach Detection-Tuning: unter 20 %. Eine hohe FP-Rate führt zu Alert Fatigue - und Alert Fatigue führt zu übersehenen echten Incidents.

Alert Volume bezeichnet die Alerts pro Analyst pro Schicht. Das Ziel sind maximal 50-100 priorisierte Alerts pro Schicht für L1. Korrelation und Aggregation im SIEM reduzieren das Volumen.

Coverage Score misst, welche MITRE ATT&CK-Techniken detektiert werden können. Der ATT&CK Navigator (attack.mitre.org/resources/attack-navigator) visualisiert die aktuelle Abdeckung. Das Ziel ist breite Coverage - nicht nur die häufigsten Tier-1-Techniken.

Management-KPIs

• Incidents pro Monat (Trendbeobachtung)
• Kritische Incidents pro Quartal
• SLA-Einhaltung (garantierte Reaktionszeiten)
• SOC-Kosten pro Endpoint und Monat
• Time-to-Value neuer Detection Rules

In-House SOC vs. MSSP vs. MDR

In-House SOC

Ein eigenes SOC ist sinnvoll bei mehr als 1.000 Mitarbeitern oder mehr als 5.000 Endpoints, bei sehr sensitiven Daten die das Land nicht verlassen dürfen, bei eigener OT/ICS-Umgebung (MSSPs haben oft keine OT-Kompetenz) oder bei regulatorischen Anforderungen (KRITIS: Nachweis eigener Fähigkeiten).

Kosten: 2 L1 + 1 L2 + 1 L3 Vollzeit = 300.000-500.000 EUR/Jahr Personalkosten, plus Tools (200.000-500.000 EUR/Jahr). Gesamtkosten: ab 500.000 EUR/Jahr aufwärts.

MSSP (Managed Security Service Provider)

Ein MSSP ist sinnvoll für 100-1.000 Mitarbeiter, für 24/7-Monitoring ohne eigenes Nachtschicht-Team und wenn kein Budget für Full-Time-SOC-Personal vorhanden ist. Kosten: 5.000-30.000 EUR/Monat je nach Scope. Der Trade-off: MSSPs haben weniger Kontext über das eigene Unternehmen.

MDR (Managed Detection and Response)

MDR ist sinnvoll, wenn aktive Reaktionsfähigkeit benötigt wird (MSSPs alertieren nur), bei kleinen Teams ohne IR-Expertise und wenn schnelle Zeit-zum-Containment kritisch ist. Kosten: 15.000-80.000 EUR/Monat. Vorteil: MDR kann auch wenn der CISO schläft Endpoints isolieren.

Hybrid-Modell (empfohlen für den Mittelstand)

In-House L2/L3 von 9-17 Uhr mit vollständiger Ownership des Detection Engineering, kombiniert mit MSSP/MDR für 24/7-Monitoring und Tier-1-Abdeckung in Nacht- und Wochenendschichten. Kostenvorteil: 20-40 % günstiger als ein vollständiges In-House SOC bei vergleichbarer Abdeckung.

Checkliste: Readiness für ein eigenes SOC

• Mindestens 3 Security Engineers mit SOC-Erfahrung verfügbar?
• Budget für SIEM-Lizenz (ab 100.000 EUR/Jahr) vorhanden?
• Schichtbetrieb organisierbar? (24/7 erfordert mindestens 5 FTE)
• SOAR und Playbook-Prozesse definierbar?
• Management-Unterstützung und klares Mandat vorhanden?

Wenn zwei oder mehr dieser Punkte mit Nein beantwortet werden, ist MSSP oder MDR als erste Stufe die bessere Wahl.

---

Ein SOC ist keine einmalige Investition, sondern eine kontinuierliche Fähigkeit. Die häufigsten Fehler: Tools kaufen ohne Prozesse, Analysten ohne Hunting-Zeit, Detection Rules ohne Updates. AWARE7 begleitet SOC-Aufbau und Optimierung - von der Tool-Auswahl über Detection-Engineering bis zum 24/7-Betriebsmodell.

SOC-Beratung anfragen | Threat Hunting Services