ibondarenko1/azure-sentinel-detection-engineering
9 détections KQL mappées sur MITRE ATT&CK dans un environnement Microsoft Sentinel + Defender XDR en production (plan de contrôle, point de terminaison, identité), avec un pipeline Detection-as-Code validé par PR (GitHub Actions, OIDC), des playbooks SOAR et une cartographie des contrôles SOC 2.
Ingénierie de détection sur un environnement Microsoft Sentinel et Defender XDR en production que j'exploite. Neuf règles d'analyse personnalisées couvrent trois plans, chacune mappée à MITRE ATT&CK et validée de bout en bout : une action contrôlée déclenche la règle, la règle génère un incident, et l'incident est investigué et documenté. Sept surveillent le plan de contrôle Azure (AzureActivity), dont une corrélation multi-étapes et une règle de contenu basée sur ARG ; une surveille l'endpoint (Defender for Endpoint), avec Defender Vulnerability Management alimentant une bibliothèque de chasse ; une surveille l'identité (Entra ID SigninLogs). Toutes sont déployées par le même pipeline contrôlé par PR.
Un environnement mono-locataire en production que j'exploite de bout en bout. Les identifiants de locataire et d'abonnement ainsi que toute donnée à caractère personnel (PII) sont masqués dans toutes les captures d'écran.
Les chiffres sont traçables : la couverture vers la couche ATT&CK, la validation vers RESULTS.md. Il n'y a délibérément aucun badge de taux de faux positifs : un environnement mono-locataire ne peut pas produire un taux de FP significatif, le dépôt rapporte donc des faux déclenchements mesurés sur un lot bénin réel plutôt qu'un pourcentage inventé (metrics.yaml le précise en entier).
Exécutez les tests unitaires de détection sur un fork, aucun Azure requis. Le KQL réel de chaque règle s'exécute contre des fixtures synthétiques dans un émulateur Kusto local, afin que la logique de détection soit vérifiable sans mon locataire :
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
C'est exactement le contrôle que la CI exécute sur chaque pull request (detection-tests) : elle vérifie que chaque règle se déclenche sur les fixtures malveillantes et reste silencieuse sur les bénignes. Le harnais en conditions réelles dans validation/ va plus loin, en pilotant un lot réel bénin et d'attaque dans un locataire et en mesurant les vrais positifs et les faux déclenchements, mais celui-ci nécessite votre propre abonnement Azure et az login (voir validation/README), il n'est donc pas « local ». Pipeline de déploiement : docs/03. Contribuer une règle : CONTRIBUTING.
Une détection n'est crédible que lorsqu'on peut la voir se déclencher. Ce dépôt ferme la boucle sur trois plans — le plan de contrôle Azure, l'endpoint et l'identité : logique de règle, déclenchement contrôlé, incident généré, investigation et mapping MITRE. Il va au-delà des règles à événement unique avec une corrélation multi-étapes (octroi puis déploiement) et une règle sensible au contenu qui joint la posture Azure Resource Graph à l'événement de modification. Ce sont des règles d'analyse Sentinel, du KQL et de la réponse à incident sur de la télémétrie réelle plutôt que des échantillons synthétiques.
Les règles ne sont pas créées par clics dans le portail. Ce sont des YAML versionnés déployés par un pipeline contrôlé par PR. Modifier une détection signifie ouvrir une pull request ; la CI la valide, un relecteur l'approuve, et le merge vers main la déploie dans Sentinel via OIDC (aucun secret stocké), de manière idempotente par GUID de règle (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 · Déployeur/validateur : cicd/ · Détails : docs/03-cicd.md
Un vrai changement l'a emprunté : la PR #1 a resserré le seuil de DET-001 (de 10 à 8) ; la CI l'a validée, et le merge l'a déployée sur la règle en production sc200-ws. Cette étape — des règles déployées automatiquement depuis git par une PR relue — est ce qui distingue un ingénieur de détection d'un analyste qui a terminé un cours.
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]
