Azure Sentinel Detection Engineering

Detection engineering on a live Microsoft Sentinel and Defender XDR environment I operate. Nine custom analytics rules span three planes, each mapped to MITRE ATT&CK and proven end to end: a controlled action triggers the rule, the rule raises an incident, and the incident gets investigated and documented. Seven watch the Azure control plane (AzureActivity), including a multi-stage correlation and an ARG-backed content rule; one watches the endpoint (Defender for Endpoint), with Defender Vulnerability Management feeding a hunting library; one watches identity (Entra ID SigninLogs). All deployed by the same PR-gated pipeline.

A live single-tenant environment I operate end to end. Tenant and subscription identifiers and any PII are redacted in all screenshots.

Figures are traceable: coverage to the ATT&CK layer, validation to RESULTS.md. There is deliberately no false-positive-rate badge: a single-tenant environment cannot produce a meaningful FP rate, so the repo reports measured false fires over a real benign batch instead of a fabricated percentage (metrics.yaml states this in full).

---

Quick start

Run the detection unit tests on a fork, no Azure needed. Each rule's real KQL runs against synthetic fixtures in a local Kusto emulator, so the detection logic is verifiable without my tenant:

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

This is the exact check CI runs on every pull request (detection-tests): it asserts each rule fires on malicious fixtures and stays silent on benign ones. The live harness in validation/ goes further, driving a real benign and attack batch in a tenant and measuring true positives and false fires, but that one needs your own Azure subscription and az login (see validation/README), so it is not "local". Deployment pipeline: docs/03. Contributing a rule: CONTRIBUTING.

Why this exists

A detection is only credible once you can show it firing. This repo closes that loop across three planes, the Azure control plane, the endpoint, and identity: rule logic, controlled trigger, generated incident, investigation, and MITRE mapping. It goes past single-event rules with a multi-stage correlation (grant then deploy) and a content-aware rule that joins Azure Resource Graph posture to the change event. It is Sentinel analytics rules, KQL, and incident response against real telemetry rather than synthetic samples.

Detection-as-Code

The rules are not clicked into the portal. They are versioned YAML deployed by a PR-gated pipeline. Editing a detection means opening a pull request; CI validates it, a reviewer approves, and merge to main deploys it to Sentinel via OIDC (no stored secrets), idempotently by rule GUID (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]

• Source of truth: detections/rules/*.yaml · Pipeline: .github/workflows/deploy-detections.yml · Deployer/validator: cicd/ · Details: docs/03-cicd.md

A real change went through it: PR #1 tightened the DET-001 threshold (10 to 8); CI validated it, and the merge deployed it to the live sc200-ws rule. That step, rules deploying automatically from git by reviewed PR, is what separates a detection engineer from an analyst who finished a course.

Architecture

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]

Detection catalog