SOAR fuer Kubernetes: Incident Response von Stunden auf Minuten reduzieren

TL;DR

• SOAR (Security Orchestration, Automation and Response) automatisiert die Reaktion auf Sicherheitsvorfaelle in Kubernetes-Clustern.
• Die groesste Wirkung erzielt man mit Playbooks fuer haeufige, gut verstandene Incidents: CVE in laufendem Image, verdaechtiger Egress-Traffic, fehlgeschlagene API-Authentifizierung.
• TheHive + Cortex ist die praktikabelste Open-Source-Option. Splunk SOAR und XSOAR bieten mehr Integrationen, kosten aber entsprechend.
• Starten Sie mit 2-3 Playbooks, die nur anreichern und benachrichtigen. Automatische Remediation kommt erst, wenn die False-Positive-Rate unter Kontrolle ist.
• Ein SIEM als Zwischenschicht ist nicht zwingend noetig, aber dringend empfohlen fuer Korrelation und Priorisierung.

Was SOAR fuer Kubernetes bedeutet

In klassischen Infrastrukturen reagieren Security-Teams auf Alerts per Ticket: Alert kommt rein, Analyst oeffnet ein Terminal, prueft Logs, isoliert die Maschine, schreibt einen Bericht. Bei Kubernetes-Clustern mit hunderten Pods, die staendig neu gestartet und skaliert werden, funktioniert das nicht mehr.

SOAR automatisiert diesen Prozess. Eine SOAR-Plattform empfaengt Alerts aus verschiedenen Quellen (Runtime Security, Container Scanner, Kubernetes Audit Logs), fuehrt vordefinierte Playbooks aus und orchestriert die Reaktion ueber APIs.

Das bedeutet konkret: Wenn Falco einen verdaechtigen Prozess in einem Pod erkennt, kann SOAR automatisch den Pod isolieren (via NetworkPolicy), den Container-Image-Hash pruefen, relevante Logs sammeln, ein Ticket erstellen und das Security-Team benachrichtigen -- alles in unter einer Minute.

Der Unterschied zur reinen SIEM-Alerting-Loesung: Ein SIEM zeigt dem Analysten, dass etwas passiert ist. SOAR fuehrt die Reaktion selbstaendig aus. Der Analyst wird informiert, aber die kritischen ersten Schritte sind bereits erledigt.

SOAR-Plattformen im Vergleich

Fuer Teams mit begrenztem Budget ist TheHive + Cortex der logische Einstieg. Die Plattform laeuft auf Kubernetes selbst (idealerweise in einem separaten Management-Cluster), und Cortex-Analyzer koennen kubectl-Befehle ausfuehren. Die Dokumentation ist solide, und die Community ist aktiv.

Splunk SOAR und XSOAR lohnen sich, wenn bereits ein kommerzielles SIEM im Einsatz ist und die Zahl der zu verarbeitenden Alerts hoch ist. Die visuellen Playbook-Editoren beschleunigen die Entwicklung, und die groessere Zahl an Integrationen reduziert den Implementierungsaufwand.

Ein Punkt, der oft unterschaetzt wird: Die Wahl der SOAR-Plattform haengt stark davon ab, welches SIEM bereits im Einsatz ist. Splunk SOAR mit Splunk Enterprise, XSOAR mit Cortex XDR, TheHive mit Elasticsearch oder Wazuh -- diese Kombinationen sind am besten getestet und dokumentiert.

Architektur: Vom Alert zum automatisierten Response

Die SOAR-Pipeline fuer Kubernetes besteht aus vier Stufen:

1. Detection: Runtime-Security-Tools (Falco, Sysdig, Aqua) und Container-Scanner (Trivy, Grype) erkennen Anomalien und Schwachstellen. Kubernetes Audit Logs erfassen API-Zugriffe. Jede dieser Quellen produziert Alerts in unterschiedlichen Formaten und mit unterschiedlicher Dringlichkeit.

2. Aggregation: Ein SIEM (Elasticsearch, Splunk, Wazuh) sammelt die Alerts, korreliert sie und priorisiert. Ein einzelner Alert ist oft kein Incident. Erst die Kombination (z.B. verdaechtiger Prozess + ungewoehnlicher Egress + neuer ServiceAccount) ergibt ein klares Bild.

3. Orchestration: Die SOAR-Plattform empfaengt priorisierte Incidents vom SIEM und startet das passende Playbook. Die Zuordnung von Incident-Typ zu Playbook erfolgt ueber Regeln oder Tags.

4. Response: Das Playbook fuehrt automatisierte Schritte aus: Anreicherung (Pod-Details, Image-Info), Containment (NetworkPolicy, Pod-Kill), Remediation (Rollback, Secret-Rotation), Benachrichtigung (Slack, E-Mail, Ticket).

Die fuenf wichtigsten Playbooks fuer Kubernetes

Nicht jeder Alert braucht ein eigenes Playbook. Starten Sie mit diesen fuenf Szenarien, die in den meisten Kubernetes-Umgebungen die hoechste Wirkung haben:

Playbook-Beispiel: Pod mit verdaechtigem Egress isolieren

Das haeufigste Szenario: Falco meldet ausgehende Verbindungen zu einer bekannten C2-Adresse aus einem Pod. Das Playbook reagiert in drei Schritten.

Schritt 1 -- Anreichern:

# Pod-Details abrufen
kubectl get pod $POD_NAME -n $NAMESPACE -o json | \
  jq '{name: .metadata.name, image: .spec.containers[0].image,
       node: .spec.nodeName, serviceAccount: .spec.serviceAccountName}'

# Image auf bekannte CVEs pruefen
trivy image --severity CRITICAL $IMAGE_NAME

# Netzwerk-Verbindungen des Pods pruefen (auf dem Node)
nsenter -t $(crictl inspect $CONTAINER_ID | jq .info.pid) -n ss -tnp

Schritt 2 -- Isolieren per NetworkPolicy:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: soar-isolate-${POD_NAME}
  namespace: ${NAMESPACE}
  labels:
    managed-by: soar
    incident-id: ${INCIDENT_ID}
  annotations:
    soar.example.com/reason: "Verdaechtiger Egress zu bekannter C2-IP"
    soar.example.com/created-at: "${TIMESTAMP}"
spec:
  podSelector:
    matchLabels:
      app: ${APP_LABEL}
  policyTypes:
    - Ingress
    - Egress
  # Keine Regeln = kein Traffic erlaubt

Schritt 3 -- Dokumentieren und Eskalieren: Das Playbook erstellt automatisch ein Ticket mit allen gesammelten Informationen (Pod-Details, Image-CVEs, Netzwerk-Logs, Node-Informationen) und benachrichtigt den On-Call-Engineer.

Der entscheidende Punkt: Die Isolation passiert in Sekunden, nicht in Minuten. Ein menschlicher Analyst haette erst den Alert lesen, den Kontext verstehen und dann manuell eine NetworkPolicy schreiben muessen. In dieser Zeit haette der kompromittierte Pod laengst Daten exfiltrieren koennen.

Playbook-Beispiel: Kritische CVE in laufendem Container

Trivy oder Grype scannt regelmaessig die laufenden Images im Cluster. Wird eine neue CRITICAL CVE entdeckt, startet dieses Playbook:

# Alle Pods mit dem betroffenen Image finden
kubectl get pods --all-namespaces -o json | \
  jq -r '.items[] | select(.spec.containers[].image == "'$AFFECTED_IMAGE'") |
    "\(.metadata.namespace)/\(.metadata.name)"'

# CVE-Details abrufen
trivy image --severity CRITICAL --vuln-type os $AFFECTED_IMAGE \
  --format json | jq '.Results[].Vulnerabilities[] |
    {id: .VulnerabilityID, severity: .Severity, title: .Title, fix: .FixedVersion}'

# Pruefen ob ein gepatchtes Image verfuegbar ist
skopeo list-tags docker://$IMAGE_REPO | jq '.Tags[-5:]'

Dieses Playbook erstellt automatisch einen Report mit allen betroffenen Pods, den CVE-Details und der Information, ob ein gepatchtes Image verfuegbar ist. Der Analyst muss dann nur noch entscheiden: Sofort patchen oder bis zum naechsten Maintenance-Fenster warten.

Schrittweise Einfuehrung

SOAR-Implementierungen scheitern oft daran, dass zu viel auf einmal automatisiert wird. Der bessere Weg ist ein dreiphasiger Ansatz:

Phase 1 (Woche 1-4): Anreichern und Benachrichtigen. Playbooks sammeln Kontext-Informationen und erstellen Tickets. Keine automatische Remediation. Ziel: Verstehen, welche Alerts relevant sind und wie hoch die False-Positive-Rate ist. In dieser Phase messen Sie die Baseline: Wie viele Alerts pro Tag? Wie viele davon sind relevant? Wie lange dauert die manuelle Bearbeitung?

Phase 2 (Woche 5-8): Semi-automatische Response. Playbooks schlagen Massnahmen vor und warten auf manuelle Freigabe. Der Analyst klickt "Approve" und das Playbook fuehrt die Aktion aus. Ziel: Vertrauen in die Automatisierung aufbauen. Gleichzeitig sammeln Sie Daten, welche Vorschlaege immer genehmigt und welche oft abgelehnt werden.

Phase 3 (Woche 9-12): Vollautomatische Response fuer validierte Szenarien. Playbooks, die in Phase 2 zuverlaessig funktioniert haben (Genehmigungsrate > 95%), laufen jetzt ohne menschliche Freigabe. Aber nur fuer klar definierte, gut verstandene Incidents. Neue Szenarien starten immer in Phase 1.

False Positives in den Griff bekommen

False Positives sind der groesste Feind jeder SOAR-Implementierung. Ein Playbook, das produktive Pods faelschlicherweise isoliert, richtet mehr Schaden an als der Incident, den es verhindern soll.

Gegenmassnahmen:

• Allowlists pflegen. Bekannte gutartige Aktivitaeten (z.B. DNS-Lookups zu externen Diensten, Health-Check-Verbindungen) in den Detection-Rules ausschliessen.
• Korrelation vor Aktion. Einzelne Alerts fuehren nie zu automatischer Remediation. Erst wenn mehrere Indikatoren zusammenkommen, wird gehandelt.
• Confidence Scores. Alerts mit niedrigem Confidence-Score durchlaufen nur Phase-1-Playbooks (Anreichern). Hohe Scores gehen in Phase 3.
• Automatische Rollback-Mechanismen. Wenn ein isolierter Pod nach manueller Pruefung als False Positive klassifiziert wird, loescht das Playbook die NetworkPolicy automatisch.
• Tuning-Zyklen einplanen. Reservieren Sie woechentlich 1-2 Stunden fuer die Analyse abgeschlossener Incidents. Welche waren echte Bedrohungen? Welche waren False Positives? Passen Sie die Detection-Rules und Playbook-Schwellenwerte entsprechend an.

Metriken: Erfolg messen

Ohne Metriken laesst sich nicht beurteilen, ob SOAR den gewuenschten Effekt hat. Diese vier Kennzahlen sind entscheidend:

Messen Sie diese Werte schon in Phase 1 als Baseline. Nur so koennen Sie den Fortschritt quantifizieren und gegenueber dem Management belegen, dass die Investition sich lohnt.

TheHive auf Kubernetes deployen

TheHive und Cortex lassen sich direkt auf Kubernetes betreiben. Das folgende Helm-Setup gibt einen Ueberblick:

# Namespace fuer Security-Tools erstellen
kubectl create namespace security-tools

# Elasticsearch fuer TheHive (Backend-Storage)
helm install elastic elastic/elasticsearch \
  -n security-tools \
  --set replicas=3 \
  --set resources.requests.memory=2Gi

# TheHive installieren
helm install thehive thehive/thehive \
  -n security-tools \
  --set elasticsearch.host=elastic-elasticsearch \
  --set cortex.url=http://cortex:9001

# Cortex installieren (Analyzer-Engine)
helm install cortex thehive/cortex \
  -n security-tools \
  --set elasticsearch.host=elastic-elasticsearch

Wichtig: TheHive und Cortex sollten in einem separaten Management-Cluster oder zumindest in einem dedizierten Namespace mit strikten NetworkPolicies laufen. Die SOAR-Plattform braucht Zugriff auf die Kubernetes-API, was sie zu einem attraktiven Ziel macht. Haerten Sie den Zugang entsprechend.

DSGVO-Aspekte

SOAR-Plattformen verarbeiten Sicherheitsdaten, die personenbezogene Informationen enthalten koennen: IP-Adressen, Benutzernamen, Zugriffszeiten. Fuer den Betrieb gelten daher folgende Anforderungen:

• Zweckbindung: Die gesammelten Daten duerfen nur fuer die Sicherheitsanalyse verwendet werden. Dokumentieren Sie den Verarbeitungszweck im Verzeichnis der Verarbeitungstaetigkeiten.
• Aufbewahrungsfristen: Legen Sie fest, wie lange Incident-Daten gespeichert werden (typischerweise 90-180 Tage) und loeschen Sie sie danach automatisch. Konfigurieren Sie entsprechende Retention Policies in TheHive/Elasticsearch.
• Hosting: Betreiben Sie die SOAR-Plattform in Rechenzentren innerhalb der EU. Bei SaaS-Loesungen pruefen Sie den Auftragsverarbeitungsvertrag (AVV) sorgfaeltig.
• Zugriffskontrolle: Nur das Security-Team darf auf die SOAR-Plattform zugreifen. RBAC und Audit-Logging sind Pflicht. Protokollieren Sie, wer wann auf welche Incident-Daten zugegriffen hat.
• Datenschutz-Folgenabschaetzung: Bei der Verarbeitung grosser Mengen sicherheitsrelevanter Daten empfiehlt sich eine DSFA nach Art. 35 DSGVO, um Risiken systematisch zu erfassen.

Integration mit Wazuh als Open-Source-SIEM

Wazuh ist eine verbreitete Open-Source-SIEM-Loesung, die sich gut mit TheHive kombinieren laesst. Fuer Kubernetes-Umgebungen bietet Wazuh Agenten, die auf den Nodes laufen und Logs sammeln. Die Integration mit SOAR erfolgt ueber die Wazuh-API und Webhook-basierte Alerts.

Der typische Datenfluss sieht so aus: Falco erkennt eine Anomalie und schreibt ein Event in stdout. Der Falco-Exporter leitet das Event an Wazuh weiter. Wazuh korreliert es mit anderen Daten (z.B. fehlgeschlagene API-Authentifizierung aus dem Kubernetes Audit Log) und erstellt einen priorisierten Alert. Dieser Alert wird per Webhook an TheHive gesendet, wo er ein Case oeffnet und das passende Cortex-Playbook startet.

Die Alternative zu Wazuh ist der Elastic Stack (Elasticsearch + Kibana + Elastic Agent). Elastic bietet mehr Out-of-the-Box-Visualisierungen und Detection Rules fuer Kubernetes, ist aber ressourcenhungriger. Fuer Umgebungen mit weniger als 10 Nodes ist Wazuh oft die schlankere Wahl.

Unabhaengig vom SIEM gilt: Investieren Sie Zeit in die Detection-Rules. Die beste SOAR-Plattform nuetzt nichts, wenn die vorgelagerten Alerts unpraesize sind. Beginnen Sie mit den Detection Rules aus dem MITRE ATT&CK Framework fuer Container (Tactic: Execution, Persistence, Privilege Escalation) und passen Sie sie an Ihre Umgebung an.

Haeufige Fehler bei der SOAR-Einfuehrung

Zu viele Playbooks auf einmal. Starten Sie mit 2-3 Playbooks, nicht mit 20. Jedes Playbook muss getestet, getuned und gepflegt werden.

Kein Feedback-Loop. Playbooks ohne regelmaessiges Tuning veralten schnell. Neue Bedrohungen, geaenderte Infrastruktur und verschobene Schwellenwerte erfordern kontinuierliche Anpassung.

SOAR ohne SIEM. Technisch moeglich, aber unpraktisch. Ohne Korrelation und Priorisierung durch ein SIEM ertrinkt die SOAR-Plattform in Low-Priority-Alerts.

Keine Testumgebung. Playbooks muessen vor dem Produktionseinsatz getestet werden. Ein separater Namespace oder Cluster fuer SOAR-Tests ist unverzichtbar.

Das Security-Team nicht einbinden. SOAR ersetzt keine Analysten. Es unterstuetzt sie. Wenn das Team das Gefuehl hat, ersetzt zu werden, scheitert die Einfuehrung an mangelnder Akzeptanz.

Weitergehende Themen

• Kubernetes Runtime Security -- Falco, Sysdig und Co. richtig einsetzen
• Network Policies fuer Fortgeschrittene -- Die Basis fuer Pod-Isolation
• Penetration Testing fuer Kubernetes -- Schwachstellen finden, bevor Angreifer es tun
• Security Scanning automatisieren -- Shift-Left in der CI/CD-Pipeline
• Monitoring und Observability -- Die Datenquelle fuer SIEM und SOAR

Sie wollen Ihre Kubernetes-Incident-Response beschleunigen und brauchen Unterstuetzung bei der Auswahl und Implementierung einer SOAR-Plattform? Schreiben Sie uns unter /kontakt.