10 — Microsoft Sentinel & Monitoring (AZ-500)

Microsoft Sentinel est le SIEM/SOAR cloud-natif d'Azure, bâti sur un Log Analytics Workspace (LAW), qui collecte, corrèle, détecte et orchestre la réponse aux menaces à l'échelle de l'entreprise.

A. Azure Monitor sous l'angle sécurité : DCR & AMA

L'Azure Monitor Agent (AMA) remplace le Log Analytics agent (déprécié). Sa collecte est entièrement pilotée par des Data Collection Rules (DCR) : objets Azure (ressources ARM) qui définissent quoi collecter (sources), quel filtre appliquer, et vers quel LAW router. Une VM peut être associée à plusieurs DCR, et une DCR à plusieurs VM (relation N-N).

Tables clés :

• Table Event : events Windows collectés par une DCR générique (System/Application/Security mélangés).
• Table SecurityEvent : réservée à Sentinel via le connecteur Windows Security Events via AMA (même AMA, destination dédiée exploitée par les règles Sentinel).
• Table Syslog / CommonSecurityLog : Syslog / CEF des appliances réseau & sécurité.

🚨 Piège : si vous sélectionnez le log Security dans une DCR « générique », les events partent dans Event, pas dans SecurityEvent. Pour alimenter Sentinel correctement, utilisez le connecteur Windows Security Events via AMA (pré-ensembles All / Common / Minimal).

🚨 Piège duplication : faire tourner AMA et l'ancien Log Analytics agent collectant les mêmes données ⇒ double ingestion = double coût + faussage des requêtes/alertes. Désactiver la collecte côté legacy avant migration.

🚨 Piège DCR Defender for Servers : pour réduire le volume des Security events ingérés par Defender for Cloud, on utilise une custom DCR filtrant les EventID — à ne pas confondre avec la collecte Sentinel.

B. Sentinel : fondations & Content Hub

Sentinel est activé sur un LAW : il n'y a pas de stockage propre, tout réside dans Log Analytics (recherche, rétention, corrélation). Conséquence directe pour l'examen : la RBAC du workspace, la rétention et les coûts d'ingestion sont ceux du LAW.

Le Content Hub centralise les solutions (packages prêts à l'emploi) regroupant connecteurs de données, règles analytiques, workbooks, playbooks et hunting queries pour un produit donné (ex. solution Palo Alto, solution Microsoft Entra ID, UEBA Essentials).

🚨 Piège examen : un connecteur Syslog/CEF n'apparaît qu'après installation de la solution correspondante depuis le Content Hub. La règle analytique d'une appliance est livrée avec la solution, pas isolément.

Rôles Sentinel (assign roles)

Rôles spécifiques Sentinel (en plus des rôles Azure RBAC du LAW/RG). Principe du moindre privilège : donner le rôle Sentinel + l'accès au LAW.

🚨 Pièges rôles : (1) un analyste qui doit trier les incidents = Responder, PAS Reader. (2) Exécuter un playbook depuis un incident exige Playbook Operator + (sur le RG du playbook) le rôle Logic App Contributor. (3) Ces rôles ne donnent pas accès aux données brutes du LAW si le workspace est en resource-context RBAC — vérifier l'accès Log Analytics en parallèle.

C. Data connectors

Les connecteurs alimentent le LAW. Catégories à connaître :

🚨 Piège Syslog vs CEF : utiliser la même facility pour Syslog et CEF ⇒ duplication entre CommonSecurityLog et Syslog. Remédiation : facilities distinctes côté source, ou transformation KQL where ProcessName !contains "CEF".

🚨 Piège AMA : tout connecteur basé AMA exige le port 443 sortant depuis le forwarder/collecteur Linux.

D. Analytics rules : de l'alerte à l'incident

Les règles analytiques transforment la donnée brute en alerts, puis Sentinel groupe les alerts en incidents (le « dossier d'enquête »).

🚨 Piège alerte ≠ incident : seules les règles scheduled et NRT créent automatiquement un incident. Les alertes d'autres produits n'en créent pas seules → d'où les Microsoft incident creation rules (hors contexte XDR/Defender portal).

🚨 Piège Fusion/Microsoft security rules : ces deux types disparaissent dès que Defender XDR incident integration est activée ou que le workspace est onboardé au Defender portal — leur création d'incident est alors prise en charge par Defender XDR. Les règles préexistantes sont auto-désactivées.

E. Automation : SOAR (automation rules + playbooks)

Le S et le OAR de SOAR reposent sur deux briques complémentaires :

Triggers :

• Incident trigger → cas le plus courant (l'incident est le conteneur enrichi : alertes, entités, commentaires, tags).
• Alert trigger → pour les alertes sans incident (création d'incident désactivée), notamment obligatoire quand le workspace est onboardé au Defender portal (la création d'incidents s'y fait côté Defender, donc les incident creation rules Sentinel doivent être désactivées).

🚨 Piège coût : les playbooks = Logic Apps ⇒ facturation Logic Apps additionnelle (par exécution/connecteur), distincte de l'ingestion Sentinel.

🚨 Piège recommandation MS : pour la plupart des cas, automation rule déclenchée à la création de l'incident appelant un playbook — pas de playbook attaché directement à chaque règle analytique.

F. Investigation, hunting & enrichissement

G. Sentinel vs Defender for Cloud : complémentaires, pas concurrents

Articulation : Defender for Cloud détecte sur les ressources et émet des alertes ; Sentinel les ingère, corrèle avec d'autres sources (Entra, firewall, AWS…), enquête et orchestre la réponse. Ils sont complémentaires.

Intégration au Defender portal (unified SecOps)

Sentinel est GA dans le Microsoft Defender portal (même sans Defender XDR ni licence E5), offrant une expérience SIEM+XDR unifiée : file d'incidents unique, corrélation cross-domain automatique, entity pages unifiées, case management, attack disruption, Security Copilot.

🚨 Piège échéance : après le 31 mars 2027, Sentinel ne sera plus supporté dans le portail Azure et ne vivra que dans le Defender portal. Une fois onboardé : les incidents sont créés côté Defender ⇒ désactiver les Microsoft incident creation rules et basculer l'automation sur alert trigger.

🏢 Scénarios d'entreprise (CAF/WAF)

Scénario 1 : SOC — centraliser la détection et détecter plus vite

Contexte business : Les alertes sont éparpillées (Defender for Cloud, firewalls Palo Alto en CEF, Entra ID). Sans corrélation ni contexte, le SOC détecte trop lentement. Choix architectural : Tout rassembler dans un seul Log Analytics Workspace sous Sentinel, puis corréler en incidents fiables avec Fusion, UEBA et watchlists. Architecture / pattern :

• Sentinel sur un LAW central
• Solutions Content Hub installées : Defender for Cloud, CEF via AMA, Entra ID
• Fusion (ML multi-étapes) + règles scheduled → incidents enrichis d'entités
• UEBA + watchlists (assets critiques) pour réduire le bruit Trade-offs assumés :
• Gain : corrélation cross-source, contexte sur les entités, détection plus rapide (MTTD réduit)
• Perte : coût d'ingestion/rétention du LAW ; tuning des règles nécessaire contre les faux positifs Pièges à éviter :
• Tout ingérer en analytics tier sans tables basic/archive → facture qui explose
• CEF via AMA mal parsé (champs non normalisés) → corrélation inefficace
• Activer Fusion avec des connecteurs de mauvaise qualité → peu de détections utiles 📐 Réf. CAF/WAF — WAF Security (SE:10 Monitoring & threat detection) : la stratégie de monitoring repose sur des mécanismes de détection modernes intégrés à la plateforme, qui alertent de façon fiable pour le triage et injectent les signaux dans les process SecOps. Lien

Scénario 2 : SecOps — réponse automatique à un compte compromis

Contexte business : À chaque connexion anormale, l'analyste perd du temps en actions manuelles (bloquer l'utilisateur, isoler la machine), ce qui ralentit et multiplie les erreurs. Choix architectural : Lancer automatiquement un playbook dès la création de l'incident, pour enrichir et contenir la menace. Architecture / pattern :

• Automation rule (déclenchée à la création de l'incident « compte compromis »)
• Playbook Logic Apps : enrichissement Threat Intelligence, blocage du user Entra, isolation MDE de la machine, notif Teams (Adaptive Card)
• Containment exécuté sans action manuelle Trade-offs assumés :
• Gain : réponse plus rapide (MTTR réduit), cohérente et reproductible, moins d'erreurs
• Perte : risque de bloquer un user/host légitime sur faux positif ; playbook et ses connexions à maintenir Pièges à éviter :
• Bloquer en dur sans seuil de confiance/approbation → déni de service auto-infligé
• Identité du playbook trop privilégiée (au-delà de bloquer user / isoler device)
• Oublier de journaliser les actions du playbook → pas de piste d'audit 📐 Réf. CAF/WAF — WAF Operational Excellence (Incident management) : un plan de réponse robuste s'appuie sur un monitoring bien conçu (logs structurés, dashboards, alertes actionnables) ; l'automatisation accélère la détection, la corrélation et le triage initial. Lien

Scénario 3 : Gouvernance — préparer et tester le cycle de réponse aux incidents

Contexte business : La gouvernance exige un cycle de réponse complet (préparation → détection → triage → containment → éradication → reprise → leçons), testé régulièrement. Choix architectural : Formaliser les rôles, fiabiliser l'ingestion des logs, améliorer la qualité des alertes et automatiser le containment. Architecture / pattern :

• Rôles et autorités d'incident formalisés (RACI / break-glass)
• Ingestion instrumentée : DCR/AMA, connecteurs Sentinel
• Amélioration continue de la qualité des alertes (moins de faux positifs)
• Containment automatisé (isoler hosts, révoquer tokens) via playbooks
• Exercices réguliers + post-mortem Trade-offs assumés :
• Gain : réponse répétable et auditable, détection plus rapide, maturité SecOps mesurable
• Perte : coût récurrent des exercices et de la maintenance des playbooks Pièges à éviter :
• Écrire le cycle sans jamais l'exercer → plan théorique qui échoue le jour J
• Automatiser le containment avant de fiabiliser les alertes → actions destructrices sur faux positifs
• Négliger la phase « lessons learned » → mêmes incidents qui reviennent 📐 Réf. CAF/WAF — CAF Secure (Prepare for and respond to incidents) : implémenter et améliorer en continu un cycle d'incident complet, instrumenter l'ingestion télémétrique et l'amélioration de fidélité d'alerte pour réduire le MTTD, automatiser les actions de containment. Lien

Doc Sentinel de référence : What is Microsoft Sentinel (SIEM)?

DEMO — chemins portail

1. Activer Sentinel sur un Log Analytics Workspace

1. Portail Azure → Microsoft Sentinel → + Create.
2. Sélectionner un Log Analytics Workspace existant (ou en créer un) → Add.
3. Sentinel s'attache au LAW ; ouvrir Content hub → installer les solutions voulues (ex. Microsoft Entra ID, Common Event Format).
4. (Optionnel unified SecOps) Defender portal → System > Settings > Microsoft Sentinel > Connect a workspace → choisir le primary workspace → Connect.

2. Créer une DCR pour collecter les Windows Security Events vers Sentinel

1. Sentinel → Configuration > Data connectors → rechercher Windows Security Events via AMA → Open connector page.
2. Configuration > + Add data collection rule.
3. Basics : nom, subscription, resource group de la DCR.
4. Resources : + Add resource(s) → sélectionner VM Azure / serveurs Arc (AMA installé automatiquement).
5. Collect : choisir un pré-ensemble All / Common / Minimal, ou Custom + requêtes XPath (ex. *[System[EventID=4625]]).
6. Review + create → Create. Les events arrivent dans la table SecurityEvent.

3. Créer une règle analytique Scheduled (KQL)

1. Sentinel → Configuration > Analytics → onglet Rule templates (modèles) ou + Create > Scheduled query rule.
2. General : nom, sévérité, tactiques MITRE ATT&CK.
3. Set rule logic : saisir la requête KQL, définir le mapping des entités (Account, Host, IP), la planification (fréquence + lookback) et le seuil.
4. Incident settings : activer la création d'incident (et le grouping des alertes).
5. Automated response : associer une automation rule / playbook.
6. Review + create.

4. Créer une automation rule + playbook (SOAR)

1. Sentinel → Configuration > Automation → + Create > Automation rule.
2. Trigger : When incident is created.
3. Conditions : ex. titre contient « compromised » / sévérité = High.
4. Actions : Run playbook → sélectionner le playbook Logic Apps (ou Change status / Assign owner / Add tags).
5. Pour créer le playbook : Automation > onglet Playbook templates ou + Create > Playbook with incident trigger → Logic Apps Designer → ajouter actions (Entra, MDE, Teams).
6. Définir l'ordre des automation rules si plusieurs s'appliquent.

5. Lancer un Hunting et créer une Watchlist

1. Sentinel → Threat management > Hunting → parcourir les hunting queries (mappées MITRE) → Run all queries → examiner les résultats → Bookmark les pistes.
2. (Watchlist) Sentinel → Configuration > Watchlists → + Add new → nom + alias → uploader le CSV (ex. liste d'IP/assets critiques) → choisir la SearchKey.
3. Référencer la watchlist en KQL via _GetWatchlist('alias') dans une règle analytique ou une hunting query pour enrichir/filtrer.