ibondarenko1/azure-sentinel-detection-engineering9 MITRE ATT&CK-zugeordnete KQL-Erkennungen in einer Live-Umgebung mit Microsoft Sentinel + Defender XDR (Control Plane, Endpoint, Identity), mit einer PR-gesteuerten Detection-as-Code-Pipeline (GitHub Actions, OIDC), SOAR-Playbooks und einer SOC-2-Kontrollzuordnung.
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).
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.
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.
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]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.
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]
| ID | Erkennung | Schweregrad | MITRE-Taktik | Technik |
|---|---|---|---|---|
| DET-001 | Anstieg fehlgeschlagener Activity-Log-Operationen | Mittel | Discovery | T1087 Account Discovery |
| DET-002 | Network-Security-Group-Regel geändert | Mittel | Defense Evasion | T1562 Impair Defenses |
| DET-003 | RBAC-Rollenzuweisungsänderungen | Mittel | Privilege Escalation / Persistence | T1098 Account Manipulation |
| DET-004 | Massenlöschung von Ressourcen | Hoch | Impact | T1485 Data Destruction |
| DET-005 | Verdächtige Ressourcenbereitstellung durch Nicht-Besitzer | Mittel | Persistence | T1098 Account Manipulation |
| DET-006 | LSASS-Anmeldeinformationszugriff (Endpunkt) | Hoch | Credential Access | T1003.001 LSASS Memory |
| DET-007 |
Jede Erkennung wurde mit einer kontrollierten, selbst zurückgesetzten administrativen Aktion ausgelöst und erzeugte einen echten Incident:
Aktueller Betriebszustand des Workspace: 10 aktivierte Analytics-Regeln, 4 aktive Datenconnectors, eine Automatisierungsregel und durchlaufende Live-Daten. Bei den 10 aktivierten Regeln handelt es sich um die neun benutzerdefinierten geplanten [DET]-Regeln aus diesem Katalog plus die integrierte Fusion-Regel von Microsoft (Advanced Multistage Attack Detection), die standardmäßig aktiviert ist und nicht hier erstellt wurde; die Zahl neun an anderer Stelle in dieser README zählt nur die benutzerdefinierten Regeln.
Fünf Incidents sind als vollständige Untersuchungen dokumentiert:
Über einmalige Auslösungen hinaus fährt eine Validierungs-Harness eine echte benigne + Angriffs-Batch im Mandanten und führt die KQL jeder Regel dagegen aus – Fehlalarme werden also gemessen, nicht angenommen. Letzter Lauf (Ergebnisse): 5/5 Angriffsszenarien haben ausgelöst (DET-002/003/004/007/009) und 0 Fehlauslösungen im benignen Strom (per Whitelist freigegebenes Owner-Deployment, Löschungen unterhalb des Schwellenwerts, Deployment ohne Rechtevergabe). Es simuliert kein Produktionsvolumen; es wandelt „0 % FP bei N=1“ in ein gemessenes „0 Fehlauslösungen über eine echte benigne Batch“ um.
Eine Abdeckungskarte mit expliziten Lücken ist ehrlicher als eine Liste von Regeln. Die ATT&CK-Navigator-Ebene (Ladeanleitung) zeigt beides:
| Abgedeckt (bereitgestellte Regel) | Bekannte Lücke, als Issue verfolgt |
|---|---|
| T1087 Account Discovery (DET-001) | T1530 Data from Cloud Storage, Datenebenen-Erkennung |
| T1562.007 Disable/Modify Cloud Firewall (DET-002 / DET-009) | T1496 Resource Hijacking, Ausgaben-/Mining-Anomalie |
| T1098 Account Manipulation (DET-003 / DET-005 / DET-007) | T1526 Cloud Service Discovery, Heuristik verstärken |
| T1485 Data Destruction (DET-004) | |
| T1003.001 LSASS Memory (DET-006) | |
| T1110 Brute Force / T1078 Valid Accounts (DET-008) |
Die Lücken sind kein statischer Text. Jede davon ist ein aktives detection-gap-Issue, sodass die Roadmap ein klickbares Backlog ist.
Warum genau diese Regeln und keine anderen: docs/08, Erkennungsstrategie und Bedrohungsmodell bildet den Katalog auf eine Cloud-Kill-Chain ab und ordnet die Lücken nach Risiko ein. Wie eine Regel getunt wird: docs/09, ein gemessener DET-005-Tuning-Zyklus bringt eine Regel von „löst bei jedem Schreibvorgang aus“ zu gemessenen null Fehlalarmen in der Validierungs-Harness.
Die Erkennung mit dem höchsten Schweregrad schließt den Kreislauf vom Erkennen zum Reagieren. Eine Sentinel-Automatisierungsregel führt bei jedem DET-004-Incident (Massenlöschung) ein Logic-App-Playbook aus: Es postet einen Anreicherungskommentar mit der empfohlenen Eindämmung (Aufrufer deaktivieren, Ressourcengruppen sperren, wiederherstellen, jagen). Das Playbook authentifiziert sich mit seiner eigenen verwalteten Identität direkt an der ARM-API – ohne Geheimnisse und ohne externen Connector.
Ein zweites Playbook erweitert den Kreislauf zu Erkennen → Reagieren → KI-Untersuchung mit Microsoft Security Copilot: Ein Promptbook + Logic App ruft ein Copilot-Promptbook für denselben DET-004-Incident auf und postet eine KI-Investigationszusammenfassung als Kommentar. Es wird ohne Compute-Units erstellt und bereitgestellt; die Live-Erfassung der KI-Zusammenfassung läuft in einem einzigen kostenbegrenzten (~4 $) bezahlten Zeitfenster und wird erst nach erfolgreicher Erfassung in Rechnung gestellt. Kosten- und Teardown-Runbook: docs/06.
Die Erkennungen starten auf der Azure-Steuerungsebene; diese Phase fügt die Endpunktebene hinzu. Ein Defender-for-Endpoint-Sensor auf einem Windows-Host speist denselben Workspace, sodass die Detection-as-Code-Pipeline eine Endpunktregel, DET-006 LSASS-Anmeldeinformationszugriff, direkt neben den Steuerungsebenen-Regeln bereitstellt. DET-006 ist mehrquellig und belegt: Drei Credential-Dump-Techniken wurden gegen den Sensor ausgeführt, der gehärtete Host (LSASS RunAsPPL, AMSI, Verhaltensschutz) hat jede einzelne verhindert, und die Regel löste auf die resultierenden Defender-Warnungen hin aus und erzeugte einen Incident (INV-03). Defender Vulnerability Management fügt eine zweite Eingabe hinzu: eine Hunting-Bibliothek, die kritische CVEs über exponierte Software, fehlgeschlagene Secure-Configuration-Baselines und gefährdete Assets unter aktiver Warnung sichtbar macht. Die DeviceTvm*-Tabellen existieren nur im Advanced Hunting von Defender, daher sind diese Korrelationen Hunts und keine bereitgestellten Regeln – und das Repository sagt, wo jede Abfrage tatsächlich läuft. Architektur und Datenfluss: docs/07.
Die Erkennungen beobachten Angriffe; diese Phase liest den eigenen Posture-Score des Mandanten, behebt, was er meldet, und belegt anschließend, dass sich die Zahl bewegt hat. Die Secure-Score-Baseline von Defender for Cloud wird von collect-posture.ps1 als maschinenlesbarer Snapshot gezogen, sodass das Vorher/Nachher ein Datei-Diff und kein Screenshot-Vergleich ist. Zur Baseline liegt der Score bei 68,81 % (21,33 / 31), und die Aufschlüsselung pro Kontrolle verortet die gesamte Lücke von 9,67 Punkten in vier Kontrollen (Verschlüsselung ruhender Daten, Zugriff und Berechtigungen, Netzwerkzugriff, Protokollierung). Die Behebung ist nach Blast-Radius geordnet, zuerst additive Fixes, und jedes Element ist der Katalogregel zugeordnet, die seine Regression erkennt (Storage-Exposition zu DET-002 / DET-009, RBAC-Ausuferung zu DET-003 / DET-007, verlorene Protokollierung zum gesamten Katalog). In diesem Durchlauf wurden drei Fixes angewendet und auf Ressourcenebene verifiziert: der Security-Contact und die Warnbenachrichtigungen, die Diagnoseprotokollierung auf beiden SOAR-Playbooks (+1 Protokollierung) und die Host-Verschlüsselung auf der Sensor-VM (+4 Verschlüsselung ruhender Daten). Defender for Cloud bewertet und berechnet den Score in den folgenden 24 bis 72 Stunden neu; der Nachher-Score wird daher als Follow-up dokumentiert und nicht jetzt behauptet. Vollständige Methode, geordneter Plan und Tabelle der Erkennungsverknüpfung: docs/10, Posture-Remediation.
Diese Arbeit unterstützt ein anerkanntes Kontrollrahmenwerk, daher sagt das Repository, wo. Jeder Teil des Katalogs ist einem SOC-2-Trust-Services-Kriterium zugeordnet: der Neun-Regeln-Katalog und die Incidents der Monitor-and-Respond-Reihe (CC7.2 bis CC7.4), die SOAR-Playbooks der Incident Response (CC7.4), die PR-gesteuerte Detection-as-Code-Pipeline dem Änderungsmanagement (CC8.1) und die Validierungs-Harness sowie das Posture-Vorher/Nachher der Wirksamkeit von Kontrollen (CC4.1). Das ist als Zuordnung formuliert, nicht als Compliance-Behauptung: Das hier ist ein Mandant, den ich betreibe, keine geprüfte Organisation. Das Dokument bildet daher die technischen Kontrollaktivitäten ab und benennt ausdrücklich den Governance-Rahmen, den ein echtes SOC-2-Report benötigt und den ein Erkennungs-Repository nicht mit sich bringt. Vollständige Tabelle Kriterium für Kriterium und die Anmerkung, wie das in einem Audit gelesen wird: docs/11, SOC-2-Kontrollenzuordnung.
detections/rules rule source-of-truth (Sentinel YAML, deployed by CI)
detections/*.md one card per rule: logic, MITRE, trigger, evidence
detections/metrics.yaml per-detection metrics (volume, FP rate, TP, MTTD)
tests/ synthetic-log unit tests (Kusto emulator, fork-runnable)
validation/ live mixed-activity harness: benign + attack streams, measured TP/FP
cicd/ + .github Detection-as-Code pipeline (deploy, validate, regression)
sigma/ vendor-neutral Sigma conversions (portable to any SIEM)
kql/ analytics-rule queries + hunting library
investigations/ end-to-end incident write-ups
simulations/ exact atomic-aligned trigger steps
navigator/ ATT&CK coverage layer (covered + gaps)
posture/ Secure Score baseline collector + JSON snapshots + remediation script
playbooks/ SOAR response (Logic App + automation rule)
docs/ architecture, methodology, cicd, validation, data-dictionary, endpoint+TVM, detection-strategy, tuning case study, posture remediation, SOC 2 control mapping
screenshots/ visual evidence
KQL · geplante Microsoft-Sentinel-Analytics-Regeln · mehrstufige Korrelationsregeln · Entra-ID-Identitätserkennung (SigninLogs) · Allow-List-Watchlists (_GetWatchlist) · Azure Resource Graph Posture als Content (geplante Action) · Microsoft Defender XDR · Microsoft Defender for Endpoint · Defender Vulnerability Management (TVM) · Advanced Hunting (Device-/DeviceTvm-Tabellen) · Microsoft Secure Score · Defender-for-Cloud-Posture-Remediation (CSPM, MCSB) · SOC-2-Common-Criteria-Kontrollenzuordnung · Detection-as-Code (GitHub Actions, OIDC) · SOAR (Logic-Apps-Automatisierungsregeln) · Sigma (herstellerneutral) · Atomic-Red-Team-Validierung · Incident-Triage und -Untersuchung · MITRE-ATT&CK-Zuordnung · Azure-Control-Plane-Überwachung (Activity Log).
Das ist ein persönliches Portfolio, aber so strukturiert, dass eine Erkennungsänderung ein reviewbarer Pull Request ist und kein Portal-Klick. Wenn du es forkst oder eine Regel vorschlagen möchtest, beschreibt CONTRIBUTING.md den Workflow: Regel-YAML bearbeiten, das KQL-Spiegelbild neu generieren, die Test-Fixtures erweitern, die Unit-Tests lokal ausführen und einen PR öffnen, den dieselben CI-Gates prüfen.
Microsoft Certified: Security Operations Analyst Associate (SC-200).
Eine Umgebung, die ich betreibe – kein Produktionsmandant eines Arbeitgebers oder Dritter. Die Erkennungen werden mit kontrollierten, selbst zurückgesetzten administrativen Aktionen gegen meine eigenen Ressourcen validiert; es sind keine Produktionssysteme und keine Dritten beteiligt. Mandanten- und Abonnementkennungen sowie personenbezogene Daten sind in allen Screenshots unkenntlich gemacht.
| Rechtevergabe gefolgt von Bereitstellung (Korrelation) |
| Hoch |
| Privilege Escalation / Persistence |
| T1098 Account Manipulation |
| DET-008 | Erfolgreiche Anmeldung nach wiederholten Fehlversuchen (Identität) | Mittel | Credential Access / Initial Access | T1110 Brute Force, T1078 Valid Accounts |
| DET-009 | NSG-Regeländerung gibt eingehenden Datenverkehr von Any frei (ARG-Content) | Hoch | Defense Evasion | T1562.007 Disable/Modify Cloud Firewall |