Azure Sentinel Detection Engineering

Detection-Engineering in einer Microsoft-Sentinel- und Defender-XDR-Live-Umgebung, die ich selbst betreibe. Neun benutzerdefinierte Analytics-Regeln erstrecken sich über drei Ebenen, sind jeweils auf MITRE ATT&CK abgebildet und durchgängig nachgewiesen: eine kontrollierte Aktion löst die Regel aus, die Regel erzeugt einen Incident, und der Incident wird untersucht und dokumentiert. Sieben beobachten die Azure-Steuerungsebene (AzureActivity), darunter eine mehrstufige Korrelation und eine ARG-gestützte Content-Regel; eine beobachtet den Endpunkt (Defender for Endpoint), wobei Defender Vulnerability Management eine Hunting-Bibliothek speist; eine beobachtet die Identität (Entra ID SigninLogs). Alle werden über dieselbe PR-gesteuerte Pipeline bereitgestellt.

Eine Live-Single-Tenant-Umgebung, die ich Ende zu Ende betreibe. Mandanten- und Abonnementkennungen sowie sämtliche personenbezogene Daten sind in allen Screenshots unkenntlich gemacht.

Zahlen sind nachvollziehbar: Abdeckung in der ATT&CK-Ebene, Validierung in RESULTS.md. Bewusst gibt es kein Badge für die False-Positive-Rate: Eine Single-Tenant-Umgebung kann keine aussagekräftige FP-Quote liefern. Daher berichtet das Repository gemessene Fehlauslösungen über eine echte benigne Batch statt eines erfundenen Prozentsatzes (metrics.yaml führt das vollständig aus).

---

Schnellstart

Führe die Detection-Unit-Tests auf einem Fork aus – ganz ohne Azure. Die echte KQL jeder Regel läuft gegen synthetische Fixtures in einem lokalen Kusto-Emulator, sodass die Erkennungslogik ohne meinen Mandanten überprüfbar ist:

git clone https://github.com/ibondarenko1/azure-sentinel-detection-engineering
cd azure-sentinel-detection-engineering
docker run -d --rm -p 8080:8080 -e ACCEPT_EULA=Y mcr.microsoft.com/azuredataexplorer/kustainer-linux:latest
pip install pyyaml
python tests/run-detection-tests.py

Das ist exakt der Check, den CI bei jedem Pull Request ausführt (detection-tests): Er stellt sicher, dass jede Regel bei bösartigen Fixtures auslöst und bei harmlosen still bleibt. Die Live-Harness in validation/ geht weiter: Sie fährt eine echte Batch aus benignen Aktionen und Angriffen in einem Mandanten und misst echte Positive und Fehlauslösungen. Dafür brauchst du aber ein eigenes Azure-Abonnement und az login (siehe validation/README) – sie ist also nicht „lokal“. Bereitstellungs-Pipeline: docs/03. Eigene Regel beisteuern: CONTRIBUTING.

Warum es dieses Repository gibt

Eine Erkennung ist erst dann glaubwürdig, wenn man zeigen kann, dass sie auslöst. Dieses Repository schließt diesen Kreislauf über drei Ebenen – die Azure-Steuerungsebene, den Endpunkt und die Identität: Regellogik, kontrollierte Auslösung, erzeugter Incident, Untersuchung und MITRE-Zuordnung. Es geht über Einzelereignis-Regeln hinaus: mit einer mehrstufigen Korrelation (Rechtevergabe, dann Bereitstellung) und einer kontextbewussten Regel, die den Azure-Resource-Graph-Posture mit dem Änderungsereignis verknüpft. Es sind Sentinel-Analytics-Regeln, KQL und Incident Response gegen echte Telemetrie statt synthetischer Stichproben.

Detection-as-Code

Die Regeln werden nicht im Portal zusammengeklickt. Sie sind versioniertes YAML, das über eine PR-gesteuerte Pipeline bereitgestellt wird. Eine Erkennung zu bearbeiten bedeutet, einen Pull Request zu öffnen: CI validiert ihn, ein Reviewer genehmigt ihn, und der Merge nach main stellt die Regel über OIDC (ohne gespeicherte Geheimnisse) idempotent per Regel-GUID bereit (API 2025-09-01).

flowchart LR
  D[Edit rule YAML] --> PR[Pull request] --> V[CI validate] -->|review| M[Merge main] --> CD[OIDC deploy] --> S[Sentinel sc200-ws]

• Quelle der Wahrheit: detections/rules/*.yaml · Pipeline: .github/workflows/deploy-detections.yml · Deployer/Validator: cicd/ · Details: docs/03-cicd.md

Ein echter Change ist durchgelaufen: PR #1 verschärfte den DET-001-Schwellenwert (von 10 auf 8); CI validierte ihn, und der Merge stellte ihn als Live-Regel in sc200-ws bereit. Genau dieser Schritt – Regeln, die per reviewtem PR automatisch aus Git deployt werden – unterscheidet einen Detection-Engineer von einem Analysten, der nur einen Kurs abgeschlossen hat.

Architektur

flowchart LR
  subgraph Sources
    A[Microsoft Defender XDR<br/>Email · Endpoint]
    B[Azure subscription<br/>Activity Log]
    C[Entra ID<br/>sign-ins]
  end
  A --> W[Log Analytics workspace<br/>sc200-ws]
  B --> W
  C --> W
  W --> R[9 scheduled<br/>analytics rules]
  R --> I[Incidents]
  I --> V[Investigation<br/>+ MITRE mapping]

Erkennungskatalog