§ SIEM

Microsoft-Sentinel-Integration

Übertragen Sie jeden Agent-Trace über die Azure Monitor Logs Ingestion API in eine benutzerdefinierte Log-Analytics-Tabelle. Sentinel-Analyseregeln verwandeln Policy-Verstöße von Agenten in Incidents in der Warteschlange, mit der Ihr SOC bereits arbeitet.

§ 01

Funktionsweise

Execlave authentifiziert sich mit Client-Credentials bei Azure AD und sendet dann gebündelte Trace-Ereignisse per POST an einen Data Collection Endpoint (DCE), der von einem Stream einer Data Collection Rule (DCR) in eine benutzerdefinierte Log-Analytics-Tabelle geleitet wird. Sentinel sitzt auf dem Workspace, sodass die Tabelle sofort über KQL abfragbar und in Analyseregeln nutzbar ist.

Der Export läuft nach dem Commit in einem dedizierten Worker — er fügt dem Enforcement niemals Latenz hinzu. Das Azure-Client-Secret wird im Ruhezustand Envelope-verschlüsselt, und AAD-Tokens werden bis kurz vor Ablauf zwischengespeichert, um einen Token-Roundtrip pro Batch zu vermeiden.

§ 02

Azure-Einrichtung

Einmalige Einrichtung in Ihrem Azure-Tenant: eine App-Registrierung, eine benutzerdefinierte Tabelle und eine DCR, die der App Ingest-Rechte gewährt.

1 · App-Registrierung (Client-Credentials)

Erstellen Sie unter Microsoft Entra ID → App registrations → New registration eine App (z. B. execlave-siem). Erstellen Sie unter Certificates & secrets ein Client-Secret. Notieren Sie sich Tenant ID, Client ID und den Secret-Wert.

2 · Benutzerdefinierte Tabelle + DCR

In Ihrem Log-Analytics-Workspace: Tables → Create → New custom log (DCR-based). Benennen Sie die Tabelle ExeclaveTraces_CL, erstellen Sie (oder verwenden Sie erneut) einen Data Collection Endpoint und definieren Sie das unten stehende Schema. Azure erstellt eine DCR mit einem Stream namens Custom-ExeclaveTraces_CL.

{  "name": "ExeclaveTraces_CL",  "columns": [    { "name": "TimeGenerated", "type": "datetime" },    { "name": "TraceId", "type": "string" },    { "name": "ParentTraceId", "type": "string" },    { "name": "OrganizationId", "type": "string" },    { "name": "AgentId", "type": "string" },    { "name": "AgentUuid", "type": "string" },    { "name": "Status", "type": "string" },    { "name": "Model", "type": "string" },    { "name": "PromptTokens", "type": "int" },    { "name": "CompletionTokens", "type": "int" },    { "name": "TotalTokens", "type": "int" },    { "name": "CostUsd", "type": "real" },    { "name": "DurationMs", "type": "real" },    { "name": "Environment", "type": "string" },    { "name": "SpanType", "type": "string" },    { "name": "SpanName", "type": "string" },    { "name": "ErrorType", "type": "string" },    { "name": "ErrorMessage", "type": "string" },    { "name": "SessionId", "type": "string" },    { "name": "UserId", "type": "string" },    { "name": "AgentName", "type": "string" },    { "name": "AutonomyLevel", "type": "string" },    { "name": "AgentStatus", "type": "string" },    { "name": "IdpBound", "type": "boolean" }  ]}

3 · Ingest-Rechte vergeben

Auf der DCR (nicht dem Workspace): Access control (IAM) → Add role assignment → Monitoring Metrics Publisher → wählen Sie die App-Registrierung aus Schritt 1 aus. Rollenzuweisungen können einige Minuten zur Verbreitung benötigen.

4 · Integration in Execlave konfigurieren

Gehen Sie zu Settings → Integrations und fügen Sie ein Microsoft Sentinel-Ziel hinzu:

Feld	Wert
`Tenant ID`	Entra-Tenant-GUID.
`Client ID`	Client-GUID der App-Registrierung.
`Client secret`	Secret-Wert aus Schritt 1 (verschlüsselt gespeichert).
`DCE endpoint`	Logs-Ingestion-URI, z. B. https://my-dce-x1y2.westeurope-1.ingest.monitor.azure.com
`DCR immutable ID`	Wert dcr-... aus der DCR-Übersicht (JSON-Ansicht).
`Stream name`	Custom-ExeclaveTraces_CL (aus Schritt 2).

Test connection bezieht ein AAD-Token für den Logs-Ingestion-Scope — dies validiert Tenant, Client und Secret, ohne Daten zu schreiben.

§ 03

Analyseregeln (KQL)

Erstellen Sie diese unter Sentinel → Analytics → Scheduled query rule. Jede ordnet ein Governance-Signal einem Sentinel-Incident zu.

Häufung von Policy-Verstößen

Governance-Ergebnisse (policy_blocked, flagged_for_review, limit_exceeded) sind eigenständige Statuswerte — alarmieren Sie direkt darauf, statt Fehlerstrings zu parsen.

// Analytics rule: policy violation burst per agent// Schedule: every 15m over a 15m window · severity: MediumExeclaveTraces_CL| where Status in ("policy_blocked", "flagged_for_review", "limit_exceeded")| summarize Violations = count(), Tools = make_set(SpanName, 10)    by AgentId, Status, Environment, bin(TimeGenerated, 15m)| where Violations >= 5

Anstieg der Agenten-Fehlerrate

// Analytics rule: agent error-rate spike vs 24h baseline// Schedule: every 1h over a 24h window · severity: LowExeclaveTraces_CL| where TimeGenerated > ago(24h)| summarize Errors = countif(Status in ("error", "timeout")), Total = count() by AgentId| extend ErrorRate = todouble(Errors) / todouble(Total)| where Total >= 20 and ErrorRate > 0.25

Prompt-Injection- / Missbrauchssuche

Als Hunting-Query speichern: Ein Endnutzer, der wiederholt sitzungsübergreifend Agenten in blockierte Tool-Aufrufe treibt, ist der klassische Injection-Fingerprint.

// Hunting query: one user driving repeated blocked tool calls// (classic prompt-injection / agent-abuse pattern)ExeclaveTraces_CL| where Status == "policy_blocked" and SpanType == "tool"| summarize BlockedCalls = count(), Agents = make_set(AgentId, 5),    Tools = make_set(SpanName, 10) by UserId, SessionId, bin(TimeGenerated, 1h)| where BlockedCalls >= 5| order by BlockedCalls desc

§ 04

Vom Incident zum Abschluss

Wenn eine Regel auslöst, enthält der Sentinel-Incident die TraceId und AgentId, die Ihr Analyst benötigt, um in Execlave zu pivotieren — vollständige Trace-Timeline, manipulationssichere Audit-Chain und Agenten-Pass. Das vollständige Runbook von Triage bis Abschluss ist der Incident-Response-Workflow.