SOAR: Security Orchestration, Automation and Response implementieren

Ein gut funktionierendes SOC-Team wird täglich von Alerts überflutet - Phishing-Meldungen, EDR-Alerts, SIEM-Korrelationen. SOAR (Security Orchestration, Automation and Response) automatisiert die repetitiven Teile: E-Mail-Header analysieren, Reputation prüfen, Ticket erstellen, User benachrichtigen. Was früher 45 Minuten dauerte, dauert mit SOAR 45 Sekunden. Das SOC-Team kann sich auf echte Bedrohungen konzentrieren.

SOAR-Architektur

SOAR-Systemkomponenten:

Orchestrierung (Verbindungsschicht):
  → Verbindet alle Security-Tools über APIs
  → Normalisierung: verschiedene Formate → einheitliches Datenmodell
  → Bidirektional: SOAR kann Tools steuern (nicht nur lesen)
  Integrationen: SIEM, EDR, Firewall, E-Mail-Gateway, TI-Feeds, CMDB, ITSM

Automatisierung (Playbooks):
  → Vordefinierte Workflows für häufige Incidents
  → Trigger: SIEM-Alert, E-Mail-Eingang, manueller Start
  → Aktionen: Dateien analysieren, IP sperren, User deaktivieren, Ticket erstellen

Response:
  → Automated Response: automatische Maßnahmen ohne Analyst
  → Analyst-in-the-Loop: System trifft Vorschlag → Analyst genehmigt
  → Case Management: alle Incident-Daten in einem Fall gesammelt

Typischer SOAR-Datenfluss:
  Alert (SIEM/EDR) → SOAR-Trigger
    → Enrichment (TI, WHOIS, GeoIP, CMDB)
    → Triage (Schwere, Asset-Kritikalität)
    → Auto-Response ODER Analyst-Aufgabe
    → Ticket (ServiceNow/Jira) + Dokumentation
    → Closure + Lessons-Learned-Feed

SOAR-Plattformen

Microsoft Sentinel (Azure Playbooks):

  Basis: Azure Logic Apps (Low-Code/No-Code Workflows)
  Stärken: Native M365-Integration, günstig für Azure-Kunden
  Preis: Pay-per-Execution (günstig bis mittlerer Nutzung)

  Playbook-Beispiel (JSON-Logik-App):
  {
    "triggers": {
      "When_a_response_to_an_Azure_Sentinel_alert_is_triggered": {}
    },
    "actions": {
      "Get_account_info": {
        "type": "ApiConnection",
        "inputs": {
          "host": {"connection": {"name": "@parameters('$connections')['azuread']"}},
          "method": "get",
          "path": "/v1.0/users/@{triggerBody()?['Entities']?[0]?['Name']}"
        }
      },
      "Condition_high_severity": {
        "type": "If",
        "expression": {
          "equals": ["@triggerBody()?['Severity']", "High"]
        },
        "actions": {
          "Disable_user": {...},
          "Create_incident": {...},
          "Notify_security_team": {...}
        }
      }
    }
  }

  Fertige Playbooks (Community):
  → Azure Sentinel GitHub: 400+ fertige Playbooks
  → Phishing: automatisch E-Mail aus Postfach löschen
  → MDE: Endpunkt isolieren bei Critical Alert
  → Entra ID: User disablen bei Credential Compromise

---

Splunk SOAR (ehemals Phantom):

  Stärken: Marktführer, Python-basierte Custom-Apps, umfangreichste Integration
  Kosten: Teuer (Enterprise), aber kostenlose Community Edition
  Stärken: Code-first Playbooks, 500+ Connector-Apps

  Python Playbook Beispiel:
  def phishing_triage(action=None, success=None, container=None,
                      results=None, handle=None, **kwargs):
      """Automatisches Phishing-Triage Playbook"""

      # 1. E-Mail-Header aus Alert holen
      sender = container.get('data', {}).get('from_address')
      subject = container.get('data', {}).get('email_subject')
      urls = container.get('data', {}).get('urls', [])

      # 2. IP-Reputation prüfen
      phantom.act('ip reputation', parameters=[{'ip': sender_ip}],
                  assets=['virustotal'],
                  callback=check_reputation)

      # 3. URL-Reputation prüfen
      for url in urls:
          phantom.act('url reputation', parameters=[{'url': url}],
                      assets=['urlvoid'],
                      callback=check_url_rep)

      # 4. Header-Analyse
      phantom.act('analyze email headers', parameters=[{...}],
                  assets=['mail_listener'],
                  callback=header_analysis_callback)

  def check_reputation(action=None, success=None, results=None, **kwargs):
      score = results[0].get('data', {}).get('positives', 0)
      if score > 5:  # Virustotal: > 5 Engines flaggen IP
          # Kritisch: Auto-Block + High-Prio-Alert
          phantom.act('block ip', parameters=[{'ip': results[0]['ip']}],
                      assets=['fortigate_firewall'])
          phantom.severity(container=container, severity='high')

---

Palo Alto XSOAR (Cortex XSOAR):

  Stärken: Umfangreichste out-of-the-box-Playbooks, starke Visualisierung
  Besonders: War Room - kollaboratives Incident-Response-Interface
  Integrationen: 1000+ fertige Integrationen

  YAML Playbook-Struktur:
  id: phishing-investigation
  name: Phishing Investigation
  starttaskid: "0"
  tasks:
    "0":
      id: "0"
      taskid: start
      type: start
      nexttasks:
        '#none#': ["1"]
    "1":
      id: "1"
      task:
        id: get-indicators
        name: Extract Indicators from Email
        type: playbook
        playbookId: Extract Indicators - Generic v2
      nexttasks:
        '#none#': ["2"]
    "2":
      id: "2"
      task:
        id: check-reputation
        name: Check Reputation
        script: VirusTotal|||file
        scriptarguments:
          file: ${ExtractedIndicators.File}
      nexttasks:
        malicious: ["3"]
        clean: ["4"]

---

TheHive + Cortex (Open Source Stack):

  Kosten: Kostenlos (Community), Enterprise-Support optional
  Stärken: FOSS, vollständig anpassbar, DSGVO-konform (on-premise)
  Stack: TheHive (Case Mgmt) + Cortex (Automatisierung) + MISP (TI)

  Python Cortex Analyzer:
  class VirusTotalAnalyzer(Analyzer):
      def run(self):
          data = self.get_data()
          vt = VirusTotal(api_key=self.get_param('config.key'))
          result = vt.get_file_report(data)

          if result['positives'] > 5:
              self.report({
                  'summary': f"{result['positives']}/{result['total']} detected",
                  'level': 'malicious',
                  'taxonomies': [
                      self.build_taxonomy('malicious', 'VirusTotal',
                                          'Score', str(result['positives']))
                  ]
              })
          else:
              self.report({'level': 'safe'})

Playbook-Design für häufige Incidents

Playbook 1: Phishing-Response

Trigger: User meldet verdächtige E-Mail
(via "Report Phishing" Button in Outlook → O365 API → SOAR)

Schritt 1 - Automatische Analyse (0-30 Sekunden):
  → E-Mail-Header extrahieren (From, Reply-To, Received)
  → SPF/DKIM/DMARC prüfen → Fail = +Risk
  → URLs extrahieren → URLVoid/VirusTotal Reputation
  → Attachments hashen → VirusTotal File-Hash-Check
  → Sender-IP → AbuseIPDB + GeoIP
  → Domain-Alter (whois) → Neue Domain < 30 Tage = +Risk

Schritt 2 - Triage-Entscheidung:
  Risk Score < 30: Benign → User informieren + Close
  Risk Score 30-70: Analyst-Review erforderlich (Ticket + Queue)
  Risk Score > 70: Malicious → Automated Response!

Schritt 3 - Automated Response (bei Score > 70):
  □ E-Mail aus ALLEN Postfächern löschen (O365: Remove-MailboxMessage)
  □ Absender-Domain blocken (E-Mail-Gateway API)
  □ URLs blockieren (Proxy/DNS-Filter via API)
  □ Ticket erstellen (ServiceNow/Jira) mit allen Findings
  □ Analyst benachrichtigen (Teams/E-Mail)
  □ SIEM-Korrelation: andere Empfänger dieser Mail?
  □ TI-Feed updaten: IOCs (Domain, URL, Hash) in MISP

Schritt 4 - Analyst-Actions (bei Score 30-70):
  □ War Room / Case: alle Daten in einer Ansicht
  □ One-Click Actions: "Confirm Malicious" → Schritt 3 ausführen
  □ "Mark as Benign" → Schließen + Training-Daten updaten

---

Playbook 2: Credential-Compromise-Response

Trigger: SIEM-Alert: User-Login aus unbekanntem Land
         ODER: EDR-Alert: mimikatz/credential dumping

Schritt 1 - Risiko-Assessment (automatisch):
  → User-Profil: normale Login-Orte, normale Arbeitszeiten
  → Asset-Kritikalität: normaler User vs. Admin vs. Service Account
  → Concurrent Sessions: ist User gleichzeitig woanders eingeloggt?
  → Recent Indicators: war dieser User in anderen Alerts?

Schritt 2 - Automatische Maßnahmen (hohes Risiko):
  □ Entra ID: User-Session revoken (Revoke-AzureADUserAllRefreshToken)
  □ MFA: erzwungener MFA-Re-Enrollment
  □ Conditional Access: temporärer Block bis Analyst genehmigt
  □ AD: Optional - Account temporär deaktivieren
  □ Teams-Benachrichtigung: Security-Team + Manager des Users

Schritt 3 - Analyst-Genehmigung:
  □ "Bestätigen + Account sperren" → AD-Deaktivierung + Reset
  □ "Bestätigen + normale Prozesse" → nur Session revoke reicht
  □ "False Positive" → Allowlist-Eintrag für diese IP/Region

---

Playbook 3: Ransomware-Erkennung

Trigger: EDR-Alert: Mass File Encryption
         ODER: SIEM: Viele Datei-Änderungen in kurzer Zeit

Schritt 1 - Sofortmaßnahmen (AUTOMATED, < 60 Sekunden):
  □ Endpunkt isolieren (EDR API: Network Isolation)
  □ User-Account deaktivieren (AD API)
  □ CISO + Management benachrichtigen (E-Mail + SMS)
  □ Incident-Ticket erstellen (P1 - höchste Priorität)
  □ Business-Continuity-Plan aktivieren (Dokument-Link in Ticket)

Schritt 2 - Forensik-Unterstützung:
  □ EDR-Timeline exportieren (letzte 48h der Aktivität)
  □ Network-Flows des Endpunkts (letzte 24h) sichern
  □ Alle anderen Endpunkte: Suche nach gleichen Indikatoren
  □ Backup-Status prüfen: letztes gutes Backup? (CMDB-API)

Schritt 3 - Containment-Assessment:
  → Hat Ransomware sich lateral bewegt? (Network-Flows)
  → Welche Fileserver hat der Endpunkt beschrieben?
  → Weitere betroffene Endpunkte isolieren (Massenaction)

SOAR-Integration und Metriken

Technische Integration:

API-Webhooks (SIEM → SOAR):
  # Sentinel → Logic App Webhook:
  POST https://prod-XX.eastus.logic.azure.com:443/workflows/.../triggers/manual/paths/invoke
  {
    "AlertName": "Suspicious PowerShell",
    "Severity": "High",
    "Entities": [{
      "Type": "Account",
      "Name": "john.doe@firma.de"
    }],
    "Description": "Encoded Command detected"
  }

SOAR → ITSM (ServiceNow):
  # ServiceNow Table API:
  POST https://instance.service-now.com/api/now/table/incident
  Authorization: Basic base64(user:pass)
  {
    "short_description": "Security Incident: Phishing Campaign",
    "priority": "1",
    "category": "security",
    "assignment_group": "Security Operations",
    "work_notes": "Automated triage: Score=85, URLs blocked, Email deleted"
  }

Bidirektionale SIEM-Integration:
  → Alert aus SIEM → SOAR-Playbook starten
  → SOAR-Maßnahmen → als Notes zurück in SIEM-Alert schreiben
  → Closure in SOAR → SIEM-Alert automatisch schließen

---

SOAR-Erfolgsmetriken:

Vor SOAR-Einführung:
  MTTR (Phishing):        45 Minuten (manuell)
  Alerts pro Tag:          200 (50% davon False Positives)
  Analyst-Zeit für Triage: 30% der Arbeitszeit

Nach SOAR-Einführung:
  MTTR (Phishing):        < 2 Minuten (Automatisierung)
  Alert-Bearbeitungsrate:  +300% (mehr Alerts in gleicher Zeit)
  Analyst-Fokus:           kritische Incidents statt Routine-Triage

KPIs:
  Automation Rate:         % der Alerts vollständig automatisiert
  False Positive Rate:     sollte sinken (SOAR lernt aus Feedback)
  MTTR pro Incident-Typ:   separate Messung pro Playbook
  Playbook Coverage:       % der Alert-Typen mit Playbook

---

Einführung SOAR - Projektplan:

Phase 1 - Foundation (Monat 1-2):
  □ SOAR-Platform auswählen (Sentinel/XSOAR/Splunk SOAR)
  □ Wichtigste Integrationen anschließen (SIEM, EDR, AD)
  □ Phishing-Playbook implementieren (häufigster Alert-Typ)
  □ Runbook-Dokumentation für alle Playbooks

Phase 2 - Expansion (Monat 3-4):
  □ 5 häufigste Alert-Typen mit Playbooks abdecken
  □ ITSM-Integration (Ticket-Automatisierung)
  □ SOC-Team-Schulung (wie Playbooks erweitern?)
  □ Metriken-Dashboard aufbauen

Phase 3 - Optimization (Monat 5+):
  □ Feedback-Loop: Analyst-Feedback → Playbook-Verbesserung
  □ ML-Integration: Anomalie-Scoring verbessert Triage
  □ Neue Use-Cases: Cloud-Alerts, Identity-Events
  □ Quarterly SOAR-Playbook-Review (veraltete Logik entfernen)