Skip to content
Zurück zur Startseite

§ GOVERNANCE

Incident-Response-Workflow

Von der Richtlinienverletzung bis zum geschlossenen Vorfall: Erkennung zum Durchsetzungszeitpunkt, Weiterleitung in Ihr SIEM, Analyst-Triage, Eindämmung und manipulationssichere Beweise – ein vollständiges Runbook.

Das Prinzip: Agenten sind Produktionsakteure, daher sollten Agenten-Incidents denselben SOC-Pipeline-Prozess durchlaufen wie jedes andere Sicherheitssignal – Ihr SIEM erkennt und reiht ein, Execlave ist das System of Record für das, was der Agent getan hat, und die Steuerungsebene, die verhindert, dass er es erneut tut.

§ §

Die sechs Phasen

Erkennung und Weiterleitung erfolgen automatisch. Phasen 3–6 sind das Analysten-Runbook.

§ 01

Erkennung – Durchsetzung markiert den Trace

Jeder überwachte Aufruf durchläuft die Pre-Execution-Durchsetzung. Wenn eine Richtlinie greift, wird das Ergebnis als erstklassiger Status im Trace erfasst – nicht in Logs vergraben:

StatusBedeutungTypischer Auslöser
policy_blockedAktion vor Ausführung gestopptTool-Allowlist, Zugangskontrolle, Injection-Erkennung
flagged_for_reviewAktion ausgeführt, zur menschlichen Überprüfung markiertRichtlinien im Flag-Modus, Qualitätsschwellenwerte
limit_exceededBudget- oder Ratenlimit erreichtKostensicherung, Limits für externe Aufrufe
error / timeoutBetrieblicher FehlerProvider-Fehler, Latenz

Konfigurieren Sie, was je Richtlinie blockiert bzw. markiert wird, unter Richtlinien.

§ 02

Weiterleitung – Die Verletzung erreicht Ihr SOC

Traces werden asynchron in Ihr SIEM exportiert – der Durchsetzungspfad wird nie durch die Lieferung verzögert. Erkennungsregeln im SIEM wandeln Governance-Status in Alerts/Incidents in der Warteschlange um, die Ihre Analysten bereits bearbeiten:

  • Splunk — HEC-Events + geplante gespeicherte Suchen mit Alert-Aktionen.
  • Microsoft Sentinel — Log Analytics Custom Table + geplante Analyseregeln.
  • OTEL Collector — Weiterleitung an beliebige Backends (Datadog, Elastic, Chronicle) aus einem einzigen OTLP-Stream.

Für Paging und Chat werden Richtlinienverletzungs-Alerts auch über Alert-Kanäle (Webhook, E-Mail) verteilt, die direkt an der Richtlinie konfiguriert werden.

§ 03

Triage – Vom SIEM-Alert zum Execlave-Trace

Jedes exportierte Event enthält trace_id und agent_id. Der Analyst wechselt in das Execlave-Dashboard und beantwortet die vier Triage-Fragen an einem einzigen Ort:

FrageOrt
Was genau hat der Agent versucht zu tun?Trace-Detail – vollständige Span-Zeitleiste, Tool-Eingaben, Richtlinienverdicts
Wer / was ist dieser Agent?Agenten-Pass – Eigentümer, Autonomiestufe, Zugangsdaten, Versionshistorie
Ist dies Teil eines Musters?Drift-Signale + Trace-Suche gefiltert nach Agent, Nutzer, Sitzung
Wurden Daten berührt?Datenzugriffs-Lineage im Trace (Quellen, Felder, Klassifizierungen)

Schweregrad-Heuristik: Blockierter Tool-Aufruf mit Injection-Signalen von einem externen Nutzer → als versuchten Angriff behandeln; wiederholtes flagged_for_review in einem Workflow → wahrscheinlich Richtlinien-Feinabstimmung, kein Angriff.

§ 04

Eindämmen & Beheben

Wählen Sie die kleinstmögliche Maßnahme, die das Verhalten stoppt:

  • Agenten pausieren — Lebenszyklus-Übergang im Registry; die Durchsetzung lehnt weitere Aufrufe sofort ab.
  • Richtlinie verschärfen — Flag → Block umschalten, die Tool-Allowlist einengen oder Budget-Obergrenzen senken. Änderungen greifen beim nächsten Durchsetzungsaufruf.
  • Menschliche Genehmigung erforderlich — Den Agenten auf act_with_approval herabstufen, sodass riskante Aktionen zur Freigabe in die Warteschlange kommen (Genehmigungsworkflows).
  • Zugangsdaten rotieren — Den API-Schlüssel des Agenten widerrufen, wenn ein Kompromittierungsverdacht besteht; nach der Überprüfung einen neuen ausstellen.
§ 05

Beweise – Den manipulationssicheren Datensatz exportieren

Das Audit-Log von Execlave ist append-only und hash-verkette – UPDATE/DELETE werden auf Datenbankebene blockiert, sodass der von Ihrem Analysten exportierte Datensatz genau dem Datensatz entspricht, der geschrieben wurde. Für den Incident-Bericht fügen Sie bei:

  • Die Trace-Zeitleiste (was passiert ist, mit Richtlinienverdicts inline).
  • Die Audit-Log-Einträge für den Agenten im Incident-Zeitfenster.
  • Den Compliance-Bericht als PDF, wenn der Incident eine regulatorische Verpflichtung auslöst — schwerwiegende Vorfälle fallen unter die Pflichten nach EU AI Act Artikel 26 (siehe die artikelgenaue Zuordnung).
§ 06

Schleife schließen

Vor dem Schließen des SIEM-Incidents: Bestätigen Sie, dass die Richtlinienänderung aktiv ist (führen Sie die auslösende Eingabe in der Staging-Umgebung erneut aus und verifizieren Sie die Blockierung), stellen Sie den Lebenszyklus-Status des Agenten wieder her, falls er pausiert wurde, und dokumentieren Sie die Grundursache. Falls die Erkennungsregel zu viele Fehlalarme produzierte, passen Sie den SPL/KQL-Schwellenwert an – beide Integrationsseiten liefern die Abfragen als editierbare Ausgangspunkte, nicht als festes Produktverhalten.

Incident-Response-Workflow — Execlave Docs