9 — Microsoft Defender for Cloud (AZ-500)

Microsoft Defender for Cloud est la plateforme de sécurité cloud-native (CNAPP) d'Azure qui combine la gestion de posture (CSPM) et la protection des charges de travail (CWPP) pour Azure, on-premises et multicloud (AWS/GCP).

A. Vue d'ensemble : CSPM + CWPP

Defender for Cloud répond à trois besoins (les 3 piliers à connaître) :

• CSPM (Cloud Security Posture Management) = posture / hygiène / hardening (config).
• CWPP (Cloud Workload Protection Platform) = threat protection / détection runtime (alertes).
• Activé sur une souscription → le Microsoft Cloud Security Benchmark (MCSB) est appliqué par défaut.

🚨 Piège : CSPM (posture) ≠ CWPP (threat protection). Le secure score est CSPM ; les alertes nécessitent l'activation d'un plan Defender (CWPP) — sauf alertes de base. 🚨 Piège : deux modèles de secure score coexistent — le classique (portail Azure, basé MCSB) et le Cloud secure score risk-based (portail Defender, intègre criticité d'actif + risk factors). Modèles distincts, valeurs différentes.

📎 What is Microsoft Defender for Cloud?

B. Posture (CSPM) — Secure Score & Inventory

• Secure score = pourcentage agrégé des contrôles de sécurité (security controls) satisfaits. Plus le score est haut, plus le risque identifié est bas.
• Seules les recommandations built-in du MCSB affectent le secure score (classique). Les recommandations en Preview sont exclues du calcul.
• Remédier une recommandation → améliore le score. Chaque contrôle regroupe des recommandations liées et porte un poids (max points).
• Asset Inventory : vue unique de tous les assets (Azure, AWS, GCP, code) avec état de santé, criticité, signaux de risque. Permet de filtrer et lancer des actions de remédiation.

🚨 Piège : le rôle Reader sur la souscription voit la compliance/secure score ; le rôle Security Reader ne suffit PAS pour la donnée de compliance des policies. 🚨 Piège : risk prioritization n'affecte PAS (encore) le secure score classique. Les recommandations Preview ne comptent pas dans le score mais doivent être remédiées.

📎 Secure score in Defender for Cloud

C. Compliance & Standards réglementaires

• Regulatory compliance dashboard : évalue les ressources contre des frameworks. Les standards reposent sur des initiatives Azure Policy.
• Standard par défaut : MCSB. Tout autre standard doit être ajouté explicitement.
• Standards built-in disponibles (extrait) : ISO/IEC 27001:2022, PCI DSS v4.0.1, NIST SP 800-53 R5, NIST CSF v2.0, CIS Azure Foundations, SOC 2023, HITRUST, CMMC L2, GDPR, NIS2, SWIFT CSCF, Canada Federal PBMM.

• Gérer les standards : Defender for Cloud → Regulatory compliance → Manage compliance policies → sélectionner le scope (souscription / management group / compte AWS / projet GCP) → Security policies → toggle On.
• Ajouter un custom standard : créer un standard org-défini avec recommandations built-in ou custom assessments, aligné sur les policies internes.
• Permissions pour assigner un standard : Owner ou Policy Contributor (a minima Resource Policy Contributor + Security Admin).

Custom standards & custom recommendations

Créés via Environment settings → souscription (ou management group) → Security policies.

• Custom standard : + Create → Standard → sélectionner les recommandations à regrouper (built-in et/ou custom) → Create. Apparaît ensuite dans Regulatory compliance au même titre qu'un standard réglementaire. Permission requise : Owner sur le scope.
• Custom recommendations — 2 modèles :

• La recommandation KQL doit toujours se terminer par | project Id, Name, Environment, Identifiers, AdditionalData, Record, HealthStatus et fixer HealthStatus à 'UNHEALTHY' ou 'HEALTHY' (sensible à la casse). Source = table RawEntityMetadata, propriétés via Record.properties.*.
• Une fois créées, les custom recommendations s'affichent avec les built-in dans le dashboard Regulatory compliance et contribuent au secure score. Déployable à l'échelle via API ou Bicep.

🚨 Piège : les custom recommendations KQL nécessitent le plan Defender CSPM — sans lui, seules les custom recommendations basées sur Azure Policy sont disponibles.

🚨 Piège : un standard n'apparaît PAS dans le dashboard s'il n'y a aucune ressource évaluable dans le scope, même assigné. Certains contrôles sont grisés : non évaluables automatiquement (process manuel ou responsabilité plateforme). 🚨 Piège : la compliance réglementaire (hors MCSB) exige au moins un plan Defender payant activé. Defender for Servers Plan 1 et Defender for API Plan 1 n'ouvrent PAS l'accès aux standards de compliance.

📎 Assign regulatory compliance standards · Create custom standards and recommendations

D. Hybrid & Multicloud (AWS / GCP / Azure Arc)

• Multicloud connectors (security connectors) : connecter des comptes AWS et projets GCP par méthodes agentless pour CSPM, plans Defender pour CWPP.
• AWS : à l'onboarding, le standard AWS Foundational Security Best Practices est assigné automatiquement. Machines onboardées comme Azure Arc VMs.
• GCP : standard GCP Default assigné par défaut. Intègre aussi GCP Security Command Center findings.
• Azure Arc : connecte serveurs on-premises / autres clouds comme Azure Arc-enabled servers → indispensable pour la protection complète Defender for Servers (lecture host-level + déploiement des extensions). Fréquence de monitoring compliance AWS/GCP = 4h.

🚨 Piège : sans Azure Arc, une machine on-prem onboardée par installation directe de l'agent Defender for Endpoint ne donne accès qu'à la fonctionnalité Plan 1 (+ premium MDVM en Plan 2). Pas de JIT/FIM/agentless.

📎 Connect AWS accounts · Connect GCP projects

E. Defender CSPM (payant) vs Foundational CSPM (gratuit)

• Attack path analysis : algorithme propriétaire sur le cloud security graph ; identifie les chemins exploitables démarrant hors de l'org (internet-exposed) vers les assets critiques. Priorise par risk level.
• Cloud security explorer : requêtes graph (built-in + custom) sur le cloud security graph pour chasser proactivement les risques.
• Agentless scanning : scanne logiciels installés + vulnérabilités sans agent, sans impact perf. Pré-requis d'attack path/security explorer pour peupler les vulnérabilités.

🚨 Piège : l'agentless scanner requiert que le Subscription Owner active Defender CSPM. Un rôle inférieur peut activer le plan mais l'agentless ne démarre pas → attack path & security explorer restent vides. 🚨 Piège : la page Attack Path peut être vide par design — elle ne montre que les menaces réelles, externes et exploitables (réduction du bruit).

📎 Protect resources with Defender CSPM · Security explorer & attack paths

F. Defender EASM (External Attack Surface Management)

• Vue externe de l'attaquant : découvre et cartographie en continu la surface d'attaque numérique exposée sur Internet (au-delà du firewall).
• Discovery récursive à partir de discovery seeds (assets légitimes connus) → découvre domaines, blocs IP, hosts, contacts email, ASNs, organisations Whois.
• Inventory : assets indexés/classés (recent vs historic), incluant web apps, dépendances tierces, shadow IT.
• Dashboards : Attack surface summary, Security posture, GDPR compliance, OWASP Top 10.
• Data connections : export vers Log Analytics (Sentinel) et Azure Data Explorer.

🚨 Piège : EASM est une ressource Azure distincte (workspace EASM), pas un simple plan CSPM. Rôles : Owner/Contributor pour gérer, Reader pour lire. Pas de cross-tenant (ni via Lighthouse).

📎 Defender EASM overview

G. Threat Protection — Cloud Workload Protection (CWPP)

• Activer les plans Defender (cloud workload protection plans) par type de ressource pour obtenir détection + alertes runtime.
• Plans : Servers, Databases, Storage, Containers, App Service, Key Vault, Resource Manager, APIs, AI, etc.
• Activation au niveau souscription (recommandé) ou ressource.

Defender for Containers (au même titre que les autres plans CWPP) couvre quatre axes :

• Registry scanning : VA des images dans ACR (AWS ECR, GCP GAR/GCR, registres externes), CVE via MDVM, au push + périodique → recommandation images should have vulnerabilities resolved.
• Running-container VA : scan agentless des conteneurs en exécution (disk snapshots), recommandation dédiée.
• Runtime threat detection (K8s) : analytics Kubernetes-aware sur clusters/nodes/workloads, alertes mappées MITRE ATT&CK for Containers, investigables via Defender XDR.
• Software supply chain : scan en CI/CD + gated deployment (audit/deny d'images non conformes à l'admission).

📎 Defender for Cloud introduction — CWPP · Defender for Containers

H. Defender for Servers (Plan 1 vs Plan 2)

• MDE integration : provisionning auto du capteur Defender for Endpoint sur machines supportées → ASR, antivirus next-gen, EDR, threat hunting, AIR.
• JIT VM access : verrouille les ports de management via règles NSG, accès contrôlé/audité à la demande seulement → réduit la surface d'attaque.
• FIM : surveille fichiers/registre pour détecter changements indiquant une attaque (P2 uniquement).
• MDVM (Defender Vulnerability Management) : assessment natif intégré ; capacités premium (security baselines, block vulnerable apps, certificats, firmware…) en P2.
• Agentless scanning : activé par défaut en P2 (ou Defender CSPM).

🚨 Piège : FIM n'est PAS activé par défaut même en P2 — il faut le configurer. À l'inverse, MDE et vuln assessment sont auto. 🚨 Piège : période d'essai 30 jours non interruptible/extensible à l'activation d'un plan Defender for Servers.

📎 Select a Defender for Servers plan · Configure servers coverage

I. Defender for Databases

Quatre offres (facturées séparément) :

• Détections : SQL injection, accès anomaux (Tor exit node, IP suspectes, apps/locations inhabituelles), key-listing suspect / exfiltration, identités compromises.
• Powered by Microsoft Defender Threat Intelligence. Alertes exportables vers Sentinel / SIEM.

🚨 Piège : Defender for Azure Cosmos DB ne supporte que l'API for NoSQL (pas Cassandra, MongoDB, Table, Gremlin) et pas les clouds gov/souverains.

📎 Defender for Databases overview · Defender for Cosmos DB

J. Defender for Storage

Trois capacités (agentless, analyse data + control plane sans activer de logs) :

• Couvre Azure Blob, Azure Files, Azure Data Lake Storage. Activable au niveau souscription (auto pour tous les comptes) ou ressource.

🚨 Piège : Malware scanning et Sensitive data threat detection sont des features configurables du nouveau plan (à activer). Malware scanning est facturé par GB — coût à surveiller. 🚨 Piège : Defender for Storage (classic) est l'ancien modèle de pricing — migrer vers le nouveau plan pour malware/sensitive data.

📎 What is Defender for Storage

K. DevOps Security (code-to-cloud)

• Connecter GitHub, Azure DevOps et GitLab à Defender for Cloud → visibilité unifiée DevOps (repos, pipelines, IaC, images).
• Scans : code, secrets exposés, dépendances open-source, misconfigurations IaC, container images.
• Agentless code scanning (Preview) : scanne via le connecteur sans modifier les pipelines (Azure DevOps / GitHub).
• Microsoft Security DevOps : GitHub Action / extension Azure DevOps pour scanner dans le pipeline (ex. catégorie IaC).
• Code-to-cloud contextualization : corrèle les findings de code avec les insights cloud → priorise ce qui est exploitable en prod. Pull request annotations pour remonter aux devs.

🚨 Piège : DevOps security est dispo en Foundational CSPM (gratuit) ET Defender CSPM. Permissions de connexion élevées : Azure DevOps = Project Collection Administrator, GitHub = Organization Owner, GitLab = Group Owner.

📎 DevOps security overview

L. Security Alerts & Workflow Automation

Security alerts :

• Générées par les plans Defender lors d'une détection de menace. Priorisées par sévérité.
• Chaque alerte expose l'intention dans la MITRE ATT&CK matrix (kill chain). Un incident = agrégation d'alertes d'une ressource alignées sur des patterns de kill chain.
• Onglet Take action : inspecter le contexte, mitiger la menace, prévenir (recommandations), déclencher une réponse automatisée (logic app), supprimer des alertes similaires (suppression rule). Statut → Dismissed après traitement.

Workflow automation :

• Déclenche des Logic Apps (consumption) sur 3 triggers : création d'une alerte, d'une recommandation, ou d'une évaluation de compliance réglementaire.
• Configuré dans Workflow automation : nom, scope, Defender for Cloud Data Type (Security Alert / Recommendation / Regulatory compliance), filtres (nom/sévérité), Logic App cible.
• Déclenchement manuel (depuis l'alerte) ou automatique (workflow automation). Déployable aussi par Azure Policy / ARM / Bicep.

🚨 Piège : le trigger legacy « When a response to a Microsoft Defender for Cloud alert is triggered » ne fonctionne PLUS avec Workflow Automation — utiliser les triggers « alert / recommendation / compliance assessment created or triggered ». 🚨 Piège : Continuous export ≠ workflow automation. Continuous export streame alertes/recommandations vers Log Analytics / Event Hub ; workflow automation déclenche une Logic App (action/SOAR).

📎 Workflow automation · Manage & respond to alerts

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

Scénario 1 : Multicloud — posture centralisée et conformité ISO 27001

Contexte business : Une entreprise opère sur Azure, AWS et GCP. La sécurité veut une vue unique de la posture et prouver la conformité ISO 27001. Choix architectural : Rattacher AWS et GCP à Defender for Cloud (sans agent) et activer le CSPM pour analyser les chemins d'attaque, puis suivre la conformité ISO via le dashboard. Architecture / pattern :

• Comptes AWS et projets GCP connectés via security connectors (agentless)
• Defender CSPM → attack path analysis + cloud security explorer
• Regulatory compliance → assigner ISO/IEC 27001:2022 au management group (en plus du MCSB)
• Suivi du secure score + Compliance Over Time workbook Trade-offs assumés :
• Gain : vue unique des 3 clouds, audit ISO automatisé, moins d'angles morts
• Perte : coût du CSPM à l'échelle multicloud ; le secure score ne prouve pas la conformité à lui seul Pièges à éviter :
• Connecter AWS/GCP sans les permissions requises → données de posture incomplètes
• Assigner ISO 27001 à une seule souscription au lieu du management group → couverture partielle
• Activer le standard sans process de remédiation → dashboard rouge ignoré 📐 Réf. CAF/WAF — Manage / Secure : la gestion de la posture multicloud relève de la méthodologie Manage (monitoring & compliance) ancrée sur le MCSB. Microsoft Cloud Security Benchmark

Scénario 2 : VMs critiques — réduire la surface d'attaque

Contexte business : Des VMs hébergent des données sensibles. L'équipe veut fermer les ports de management et détecter toute altération. Choix architectural : Activer Defender for Servers Plan 2 pour ouvrir les ports à la demande (JIT), surveiller les fichiers (FIM) et gérer les vulnérabilités sans agent. Architecture / pattern :

• Defender for Servers Plan 2 → JIT VM access (ports fermés par NSG, ouverts à la demande et audités)
• FIM (détecte les changements fichiers/registre)
• Agentless scanning + MDVM premium (gestion des vulnérabilités)
• Intégration MDE (EDR) ; priorisation via attack path analysis (Defender CSPM) Trade-offs assumés :
• Gain : ports exposés seulement à la demande, altérations détectées, vulnérabilités priorisées par chemin de risque
• Perte : coût du Plan 2 ; léger délai d'accès admin (demande JIT à valider) Pièges à éviter :
• Laisser les ports de management ouverts en permanence à côté du JIT → bénéfice annulé
• Activer FIM sans définir les chemins critiques à surveiller → bruit inutile
• Croire que l'agentless scanning remplace l'EDR temps réel (MDE) → couverture incomplète 📐 Réf. CAF/WAF — WAF Security (SE:06 / least privilege) : JIT et le durcissement des accès matérialisent le pilier Security (réduire la surface d'attaque, contrôler les accès). Zero Trust and Defender for Cloud

Scénario 3 : Stockage — réponse automatisée aux menaces

Contexte business : Un compte de stockage reçoit des uploads externes. L'org veut bloquer les malwares et alerter le SOC sans intervention manuelle. Choix architectural : Activer Defender for Storage (scan malware à l'upload) et déclencher une réponse automatique via Logic App sur l'alerte. Architecture / pattern :

• Defender for Storage : malware scanning (on-upload) + sensitive data threat detection
• Logic App + Workflow automation : data type Security Alert, filtre Malware, sévérité High → notif Teams/email + remédiation
• Alertes exportées vers Microsoft Sentinel (continuous export) pour corrélation Trade-offs assumés :
• Gain : malwares bloqués, SOC alerté automatiquement, MTTR réduit
• Perte : surcoût Defender + scan facturé au Go ; maintenance de la Logic App et de ses connexions Pièges à éviter :
• Filtre d'alerte trop large → notifications en masse, fatigue du SOC
• Logic App avec une identité trop privilégiée → risque si elle est compromise
• Oublier l'export Sentinel → pas de corrélation cross-source des incidents 📐 Réf. CAF/WAF — WAF Security (incident response / automation) : l'automatisation de la réponse via Logic Apps incarne la recommandation WAF d'automatiser les procédures de sécurité. Automate remediation responses

DEMO — chemins portail

1. Activer un plan Defender (CWPP) sur une souscription

1. Portail Azure → Microsoft Defender for Cloud → Environment settings.
2. Sélectionner la souscription.
3. Sur la page Defender plans, basculer le plan voulu (ex. Servers, Storage, Databases) sur On.
4. Pour Servers, cliquer Settings → choisir Plan 1 ou Plan 2, puis configurer les composants (FIM, agentless scanning, endpoint protection).
5. Save.

2. Ajouter un standard de compliance (ex. ISO 27001)

1. Defender for Cloud → Regulatory compliance.
2. Cliquer Manage compliance policies.
3. Sélectionner le scope (souscription / management group / compte AWS / projet GCP).
4. Sélectionner Security policies, localiser le standard (ex. ISO/IEC 27001:2022) et basculer sur On.
5. Renseigner les paramètres si demandés → le standard apparaît dans le dashboard.

3. Configurer Just-in-Time (JIT) VM access

1. Defender for Cloud → Workload protections → Just-in-time VM access (Plan 2 requis).
2. Onglet Not configured, sélectionner la VM → Enable JIT on VMs.
3. Définir les ports (ex. 22, 3389), le protocole, l'IP source autorisée et la durée max de la requête.
4. Save. Pour se connecter : onglet Configured → Request access → choisir ports/IP/durée → Defender ouvre temporairement les règles NSG.

4. Créer un Workflow Automation (Logic App sur alerte)

1. (Pré-requis) créer une Logic App (consumption) avec un trigger Defender for Cloud.
2. Defender for Cloud → Workflow automation → Add workflow automation.
3. Renseigner Name, Subscription, Resource group.
4. Defender for Cloud Data Type = Security Alert ; filtres Alert name contains + Alert severity (ex. High).
5. Sélectionner la Logic app → Create.

5. Lancer une requête dans Cloud Security Explorer

1. (Pré-requis) Defender CSPM activé + agentless scanning on.
2. Defender for Cloud → Cloud Security Explorer.
3. Dans What would you like to search?, choisir une catégorie (ex. VM, APIs, Storage) ou un template (ex. Internet exposed VMs with sensitive data).
4. Affiner avec des conditions (exposition Internet, permissions, vulnérabilités).
5. Search → examiner et prioriser les chemins de risque ; pivoter vers Attack path analysis pour la remédiation.