azure-sentinel-detection-engineering

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).

Démarrage rapide

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 :

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.

Pourquoi ce dépôt existe

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.

Detection-as-Code

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).

• Source de vérité : 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.

Architecture

Catalogue de détections

Résultats

Chaque détection a été déclenchée par une action administrative contrôlée et auto-réversible, et a produit un incident réel :

État opérationnel actuel de l'espace de travail : 10 règles d'analyse activées, 4 connecteurs de données actifs, une règle d'automatisation et des données réelles qui circulent en continu. Les 10 règles activées sont les neuf règles planifiées personnalisées [DET] de ce catalogue plus la règle Fusion intégrée de Microsoft (Advanced Multistage Attack Detection), activée par défaut et non écrite ici ; le chiffre de neuf cité ailleurs dans ce README ne compte que les règles personnalisées.

Cinq incidents sont documentés sous forme d'investigations complètes :

• INV-01, Suppression massive de ressources (Élevée)
• INV-02, Élévation de privilèges RBAC
• INV-03, Accès aux identifiants LSASS (Élevée), endpoint, incident #65
• INV-04, NSG ouvert en entrée depuis Any (Élevée), corrélation de contenu ARG (DET-009)
• INV-05, Octroi de privilège puis déploiement (Élevée), corrélation multi-étapes (DET-007)

Au-delà des déclenchements ponctuels, un harnais de validation pilote un lot réel bénin + attaque dans le locataire et fait passer le KQL de chaque règle dessus, de sorte que les faux positifs sont mesurés, pas supposés. Dernière exécution (résultats) : 5/5 scénarios d'attaque déclenchés (DET-002/003/004/007/009) et 0 faux déclenchement sur le flux bénin (déploiement propriétaire sur liste blanche, suppressions sous le seuil, déploiement sans octroi). Il ne simule pas un volume de production ; il convertit un « 0 % de FP à N=1 » en un « 0 faux déclenchement sur un lot bénin réel » mesuré.

Couverture ATT&CK

Une carte de couverture avec des lacunes explicites est plus honnête qu'une liste de règles. La couche ATT&CK Navigator (comment la charger) montre les deux :

Les lacunes ne sont pas du texte statique. Chacune est un issue detection-gap vivant, ce qui fait de la feuille de route un backlog cliquable.

Pourquoi ces règles et pas d'autres : docs/08, stratégie de détection et modèle de menace mappe le catalogue sur une kill chain cloud et classe les lacunes par risque. Comment une règle est ajustée : docs/09, une boucle d'ajustement mesurée pour DET-005 fait passer une règle de « se déclenche à chaque écriture » à zéro faux positif mesuré sur le harnais de validation.

Réponse automatisée (SOAR)

La détection de plus haute gravité ferme la boucle de la détection vers la réponse. Une règle d'automatisation Sentinel exécute un playbook Logic App sur chaque incident DET-004 (suppression massive) : il publie un commentaire d'enrichissement avec le confinement recommandé (désactiver l'appelant, verrouiller les groupes de ressources, restaurer, chasser). Le playbook s'authentifie avec sa propre identité managée directement auprès de l'API ARM, sans secret ni connecteur externe.

Un deuxième playbook étend la boucle en détecter → répondre → investiguer par IA avec Microsoft Security Copilot : un promptbook + Logic App invoque un promptbook Copilot sur le même incident DET-004 et publie un résumé d'investigation IA en commentaire. Il se construit et se déploie sans unités de calcul ; la capture du résumé IA en conditions réelles s'exécute dans une fenêtre payante unique à coût borné (~4 $) et n'est pas revendiquée tant qu'elle n'est pas capturée. Runbook de coût et de démantèlement : docs/06.

Gestion des endpoints et des vulnérabilités

Les détections commencent sur le plan de contrôle Azure ; cette phase ajoute le plan endpoint. Un capteur Defender for Endpoint sur un hôte Windows alimente le même espace de travail, de sorte que le pipeline Detection-as-Code déploie une règle endpoint, DET-006 Accès aux identifiants LSASS, à côté des règles du plan de contrôle. DET-006 est multi-source et attestée : trois techniques de dump d'identifiants ont été exécutées contre le capteur, l'hôte durci (LSASS RunAsPPL, AMSI, protection comportementale) a bloqué chacune d'elles, et la règle s'est déclenchée sur les alertes Defender résultantes pour générer un incident (INV-03). Defender Vulnerability Management ajoute un second apport : une bibliothèque de chasse qui remonte les CVE critiques par logiciel exposé, les baselines de configuration sécurisée non respectées et les actifs vulnérables sous alerte active. Les tables DeviceTvm* n'existent que dans la chasse avancée de Defender, ces corrélations sont donc des chasses, pas des règles déployées, et le dépôt indique où chaque requête s'exécute réellement. Architecture et flux de données : docs/07.

Remédiation de posture

Les détections surveillent les attaques ; cette phase lit le score de posture du locataire lui-même, corrige ce qu'il signale, puis prouve que le chiffre a bougé. La baseline du Secure Score de Defender for Cloud est extraite sous forme de capture lisible par machine par collect-posture.ps1, de sorte que l'avant/après est un diff de fichiers, pas une comparaison de captures d'écran. Au départ, le score est de 68,81 % (21,33 / 31), et la décomposition par contrôle place la totalité de l'écart de 9,67 points dans quatre contrôles (chiffrement au repos, accès et autorisations, accès réseau, audit). La remédiation est ordonnée par rayon d'explosion, avec les correctifs additifs d'abord, et chaque élément est mappé à la règle du catalogue qui détecte sa régression (exposition du stockage vers DET-002 / DET-009, prolifération RBAC vers DET-003 / DET-007, perte de journalisation vers l'ensemble du catalogue). Trois correctifs ont été appliqués lors de cette passe et vérifiés au niveau des ressources : le contact de sécurité et les notifications d'alerte, la journalisation diagnostique sur les deux playbooks SOAR (+1 audit), et le chiffrement sur l'hôte de la VM capteur (+4 chiffrement au repos). Defender for Cloud réévalue et recalcule le score dans les 24 à 72 heures suivantes, le score post-correction est donc documenté comme un suivi plutôt qu'affirmé dès maintenant. Méthode complète, plan ordonné et tableau de liaison des détections : docs/10, remédiation de posture.

Mapping des contrôles SOC 2

Ce travail s'appuie sur un cadre de contrôle reconnu, et le dépôt indique où. Chaque partie du catalogue correspond à un critère des services de confiance SOC 2 : le catalogue de neuf règles et les incidents à la série « surveiller et répondre » (CC7.2 à CC7.4), les playbooks SOAR à la réponse à incident (CC7.4), le pipeline Detection-as-Code contrôlé par PR à la gestion des changements (CC8.1), et le harnais de validation ainsi que l'avant/après de posture à l'efficacité opérationnelle des contrôles (CC4.1). C'est présenté comme un mapping, pas une déclaration de conformité : il s'agit d'un locataire que j'exploite, pas d'une organisation auditée, le document mappe donc les activités de contrôle techniques et précise explicitement l'enveloppe de gouvernance qu'un vrai rapport SOC 2 exige et qu'un dépôt de détections ne porte pas. Tableau complet critère par critère et note sur la lecture en audit : docs/11, mapping des contrôles SOC 2.

Structure du dépôt

Compétences démontrées

KQL · règles d'analyse planifiées Microsoft Sentinel · règles de corrélation multi-étapes · détection d'identité Entra ID (SigninLogs) · watchlists de liste blanche (_GetWatchlist) · posture Azure Resource Graph en tant que contenu (Action planifiée) · Microsoft Defender XDR · Microsoft Defender for Endpoint · Defender Vulnerability Management (TVM) · chasse avancée (tables Device / DeviceTvm) · Microsoft Secure Score · remédiation de posture Defender for Cloud (CSPM, MCSB) · mapping des contrôles SOC 2 Common Criteria · Detection-as-Code (GitHub Actions, OIDC) · SOAR (règles d'automatisation Logic Apps) · Sigma (indépendant du fournisseur) · validation Atomic Red Team · triage et investigation d'incidents · mapping MITRE ATT&CK · surveillance du plan de contrôle Azure (journal d'activité).

Contribution

C'est un portfolio personnel, mais il est structuré pour qu'une modification de détection soit une pull request examinable, pas un clic dans le portail. Si vous le forkez ou souhaitez proposer une règle, CONTRIBUTING.md couvre le workflow : modifier le YAML de la règle, régénérer le miroir KQL, étendre la fixture de test, exécuter les tests unitaires en local, et ouvrir une PR que les mêmes contrôles CI vérifient.

Certification

Microsoft Certified: Security Operations Analyst Associate (SC-200).

Avertissement

Un environnement que j'exploite, pas un locataire de production d'un employeur ou d'un tiers. Les détections sont validées par des actions administratives contrôlées et auto-réversibles sur mes propres ressources ; aucun système de production et aucun tiers n'est impliqué. Les identifiants de locataire et d'abonnement ainsi que les PII sont masqués dans toutes les captures d'écran.

Licence

MIT