🟡 Niveau Intermédiaire — Threat Detection

30+ leçons sur Defender for Cloud, Endpoint, Identity, l'investigation d'incidents et le framework MITRE ATT&CK.

Module 1 : Microsoft Defender for Cloud

1.1 Vue d'ensemble du CSPM

Defender for Cloud est un outil CSPM (Cloud Security Posture Management) et CWPP (Cloud Workload Protection). Il fournit des recommandations de sécurité pour protéger vos workloads cloud.

Pourquoi c'est important : Defender for Cloud répond à la question que tout RSSI pose : « sommes-nous bien configurés ? ». Avant de chasser des attaquants, il faut fermer les portes restées ouvertes (stockage public, VM sans patch, ports exposés). Le Secure Score vous donne un chiffre unique à piloter et à présenter en comité de direction. Sans CSPM, vous détectez des intrusions qui n'auraient jamais dû être possibles.
L'analogie qui aide : Imaginez le contrôle technique d'une voiture : le garagiste ne cherche pas un voleur, il vérifie freins, pneus et feux, puis vous donne une liste de réparations classées par dangerosité. Defender for Cloud est ce contrôle technique pour votre cloud : recommandations à la place des réparations, Secure Score à la place de la vignette.
Démonstration pas à pas : Suivez le raisonnement avec un cas chiffré : votre abonnement affiche un Secure Score de 32 %. Vous ouvrez les recommandations : 15 comptes de stockage autorisent l'accès public (sévérité haute), 40 VM n'ont pas les mises à jour automatiques (moyenne). Vous corrigez le stockage public en premier : le score monte à 47 % et vous venez de fermer la faille la plus exploitée pour l'exfiltration. La méthode : toujours traiter par sévérité décroissante, jamais par ordre alphabétique.
Pièges classiques : À l'examen : CSPM (posture : recommandations, Secure Score, conformité) contre CWPP (protection des charges : alertes temps réel sur VM, conteneurs, bases). Defender for Cloud gratuit ne fait que le CSPM de base ; les alertes de sécurité exigent les plans payants. Si la question parle de détecter une menace en temps réel sur une VM, la réponse n'est jamais le plan gratuit.
À vous de jouer : Question de contrôle : votre Secure Score est de 78 % mais une VM est compromise par un malware. Quel rôle joue Defender for Cloud ici : CSPM ou CWPP, et que vous manque-t-il ?
Voir la réponse

Les deux, mais le score (CSPM) ne protège pas : il mesure la posture. C'est le versant CWPP (plan Defender for Servers activé) qui génère des alertes temps réel sur la VM. Un bon score sans plans de protection activés laisse les workloads aveugles — la posture ne remplace pas la détection.

1.2 Plans Defender for Cloud

Pourquoi c'est important : Chaque workload a son plan parce que chaque workload s'attaque différemment : on ne protège pas un cluster Kubernetes comme une base SQL. Connaître les huit plans (Servers P1/P2, Containers, Databases, Storage, App Service, Resource Manager, DNS) vous permet de répondre à la question d'examen qui tombe à chaque session : « quel plan pour protéger X ? ». Activer le mauvais plan, c'est payer sans être protégé.
L'analogie qui aide : Imaginez une compagnie d'assurance : il y a un contrat habitation (Servers), un contrat auto (Containers), un contrat bateau (Databases) — chacun couvre des risques précis. Prendre une assurance auto pour protéger votre maison ne sert à rien. Les plans Defender fonctionnent pareil : chaque plan couvre sa famille de ressources, et il faut le bon contrat pour le bon bien.
Démonstration pas à pas : Appliquez la logique à un cas : vous devez protéger 20 VM, un cluster AKS et un compte de stockage. Étape 1 : Defender for Servers sur les VM (P2 si vous voulez le threat hunting et la réponse forensique, P1 sinon). Étape 2 : Defender for Containers pour l'AKS — le plan Servers ne verra jamais les pods. Étape 3 : Defender for Storage pour détecter les accès anormaux aux blobs. Trois familles, trois plans : dessinez toujours l'inventaire des ressources avant de choisir, et vérifiez la couverture plan par plan.
Pièges classiques : Confusions classiques : Defender for Servers P1 contre P2 (P2 ajoute la détection avancée et le plan répond aux questions d'examen sur le hunting) ; Defender for Resource Manager (surveille les opérations ARM dangereuses, pas les ressources elles-mêmes) contre les autres plans ; et Defender for DNS (zones DNS Azure) n'a rien à voir avec la protection des postes. Retenez aussi que les plans se facturent par ressource protégée : activer Servers sur tout l'abonnement sans trier coûte cher.
À vous de jouer : Question de contrôle : vous devez détecter l'exfiltration de données via un compte de stockage et sécuriser un cluster Kubernetes. Quels plans activez-vous ?
Voir la réponse

Defender for Storage (détection d'accès anormaux aux blobs et fichiers) et Defender for Containers (protection des clusters Kubernetes et des images). Le plan Servers ne couvrirait ni l'un ni l'autre : chaque famille de ressources exige son plan dédié.

1.3 Recommandations et Priorisation

Les recommandations sont classées par sévérité et impact :

Pourquoi c'est important : Un abonnement moyen affiche des centaines de recommandations : sans méthode de priorisation, votre équipe se noie et ne corrige rien. Trier par sévérité et par impact (critique, haute, moyenne, basse) transforme une liste écrasante en un plan d'action hebdomadaire. C'est exactement ce qu'un auditeur SC-200 attend de vous : prouver que vous savez distinguer l'urgent de l'accessoire.
L'analogie qui aide : Imaginez le triage aux urgences : le médecin ne soigne pas les patients par ordre d'arrivée mais par gravité — hémorragie d'abord, rhume ensuite. Les recommandations Defender for Cloud suivent la même logique : les vulnérabilités critiques exploitables immédiatement passent devant les bonnes pratiques à planifier.
// Exemple : Requête KQL pour les alertes Defender for Cloud
SecurityAlert
| where ProductName == "Azure Security Center"
| where AlertName contains "VM" or AlertName contains "Storage"
| summarize count() by AlertName, AlertSeverity
| order by count_ desc
Démonstration pas à pas : Déroulez la méthode sur un exemple : la requête KQL d'exemple regroupe les alertes Azure Security Center par nom et sévérité, triées par nombre décroissant. Lecture : 1) vous repérez l'alerte la plus fréquente en sévérité haute — par exemple « VM avec port RDP exposé » 60 fois ; 2) vous corrigez la cause racine (NSG) une seule fois au lieu de traiter 60 alertes ; 3) vous mesurez : le compteur tombe à zéro la semaine suivante. Le réflexe : agréger par cause, corriger la racine, vérifier la courbe.

💡 Pour l'examen SC-200

Comprendre la différence entre CSPM (posture) et CWPP (protection des workloads) est essentiel. Defender for Cloud combine les deux dans un seul outil.

Pièges classiques : la sévérité d'une recommandation (gravité théorique) n'est pas son impact métier — une faille critique sur une VM de test isolée passe après une faille haute sur le serveur de paie ; autre piège : les benchmarks CIS et ISO dans Defender for Cloud servent la conformité, pas la détection temps réel — ne les citez jamais comme source d'alertes ; enfin, l'Attack Path Analysis montre des chemins exploitables, pas des attaques en cours.
À vous de jouer : Question de contrôle : vous avez 200 recommandations moyennes et 3 recommandations critiques. Par où commencez-vous, et pourquoi ?
Voir la réponse

Par les 3 critiques : elles signalent des vulnérabilités exploitables immédiatement avec un impact élevé (accès public, RCE connue). Les 200 moyennes se planifient ensuite. La priorisation suit toujours la sévérité pondérée par l'exposition réelle, jamais le volume.

Module 2 : Microsoft Defender for Endpoint

2.1 Architecture EDR

Defender for Endpoint est une plateforme EDR (Endpoint Detection and Response) qui fournit :

Pourquoi c'est important : L'antivirus classique bloque ce qu'il connaît ; l'EDR détecte ce qu'il voit faire : un PowerShell qui télécharge un fichier à 3h du matin, même avec un binaire légitime, déclenche une alerte comportementale. Comprendre les cinq piliers (détection, investigation, réponse, prévention, vulnérabilités) vous permet de placer chaque fonctionnalité Defender for Endpoint au bon endroit — et de répondre sans hésiter quand l'examen demande où confiner un poste.
L'analogie qui aide : Imaginez un gardien de musée : l'antivirus est la liste des voleurs connus à l'entrée (signatures), tandis que l'EDR est le gardien qui observe les comportements — un visiteur en règle qui sort un pied-de-biche devant une vitrine se fait intercepter même s'il n'est sur aucune liste. Defender for Endpoint est ce gardien : il juge les actes, pas seulement les identités.
Démonstration pas à pas : Suivez une attaque réelle : 1) prévention — l'ASR bloque l'exécution d'une macro malveillante, fin de l'histoire dans 90 % des cas ; 2) si elle passe, détection — le capteur comportemental voit winword.exe lancer powershell.exe avec une commande encodée et lève une alerte ; 3) investigation — vous ouvrez la timeline et l'arbre de processus pour voir tout ce que le script a touché ; 4) réponse — vous confineZ le poste depuis le portail ; 5) vulnérabilités — le scan révèle qu'Office n'était pas patché, cause racine à corriger. Cinq piliers, un seul flux.
Pièges classiques : À l'examen : Attack Surface Reduction (règles ASR : bloquer les comportements à risque) contre Controlled Folder Access (protège des dossiers précis contre le ransomware) — deux préventions différentes ; Exploit Protection n'est pas l'antivirus ; et le confinement (isolation réseau du poste) se fait depuis Defender for Endpoint ou via playbook Sentinel, jamais depuis une règle analytics seule.
À vous de jouer : Question de contrôle : un ransomware commence à chiffrer le dossier Documents. Quelle fonctionnalité l'aurait bloqué, et à quel pilier appartient-elle ?
Voir la réponse

Controlled Folder Access, pilier prévention : seuls les processus autorisés peuvent écrire dans les dossiers protégés. Le ransomware, même inconnu des signatures, aurait été bloqué à l'écriture — c'est de la prévention comportementale, pas de la détection.

2.2 Alertes Defender for Endpoint

Pourquoi c'est important : Toutes les alertes ne se valent pas : une alerte de vulnérabilité (patch manquant) demande un correctif planifié, une alerte de compromission (hash connu, IP malveillante) exige un confinement immédiat. Savoir classer les quatre familles (comportementales, détection, vulnérabilités, compromission) détermine votre temps de réaction — et une mauvaise classification en examen comme en production fait perdre des heures.
L'analogie qui aide : Imaginez une alarme incendie avec quatre voyants : fumée anormale (comportemental), flamme identifiée (détection par signature), extincteur périmé (vulnérabilité) et départ de feu confirmé (compromission). Vous ne réagissez pas pareil à un extincteur périmé et à un feu confirmé. Les alertes Endpoint suivent la même gradation : le voyant donne la réaction.
Démonstration pas à pas : Classez trois alertes réelles : 1) « Processus légitime injectant du code dans lsass.exe » — comportementale, haute priorité, à investiguer immédiatement ; 2) « Vulnérabilité CVE-2024-1234 sur Chrome » — vulnérabilité, à verser au plan de patch ; 3) « Connexion à une IP de C2 connue » — compromission, confinement du poste sans délai. La règle : compromission et comportemental critique d'abord (minutes), détection ensuite (heures), vulnérabilités en planifié (jours).
Pièges classiques : une alerte comportementale peut être un faux positif (un admin qui utilise PsExec) — elle demande investigation, pas confinement aveugle ; les alertes de vulnérabilités ne signifient pas une compromission — patcher n'est pas répondre à un incident ; et la sévérité affichée (informational à critique) ne remplace pas votre analyse du contexte (poste de test contre serveur de production).
À vous de jouer : Question de contrôle : vous recevez « PsExec exécuté par un administrateur connu, à 14h, sur un serveur d'administration ». Confinement immédiat ou investigation d'abord ?
Voir la réponse

Investigation d'abord : PsExec est un outil d'administration légitime et le contexte (admin connu, heures ouvrées, serveur d'admin) plaide pour un usage normal. Une alerte comportementale se valide avant d'agir — confiner aveuglément couperait le travail légitime et ferait perdre la confiance des équipes.

2.3 Investigation dans Defender for Endpoint

// Requête pour investiguer les processus suspects
DeviceProcessEvents
| where Timestamp > ago(24h)
| where FileName in~ ("powershell.exe", "cmd.exe", "wscript.exe")
| where ProcessCommandLine has_any ("download", "invoke-webrequest", "curl", "bitsadmin")
| project Timestamp, DeviceName, AccountName, FileName, ProcessCommandLine
| order by Timestamp desc
Pourquoi c'est important : Savoir lire DeviceProcessEvents et DeviceNetworkEvents en KQL, c'est pouvoir prouver une intrusion au lieu de la supposer : quel processus, quelle ligne de commande, quelle IP distante, à quelle heure. Les deux requêtes d'exemple (lignes de commande suspectes, PsExec corrélé au port 445) sont des modèles que vous réutiliserez tels quels en incident réel — et l'examen teste votre capacité à les lire.
L'analogie qui aide : Imaginez que vous êtes détective : DeviceProcessEvents est le registre des faits et gestes (qui a lancé quoi, avec quels arguments), DeviceNetworkEvents est le relevé des appels téléphoniques (qui a joint qui, sur quel port). En croisant les deux, vous prouvez que le suspect (powershell.exe avec download) a bien appelé son complice (l'IP externe).
// Détecter les mouvements latéraux via PsExec
DeviceProcessEvents
| where Timestamp > ago(7d)
| where FileName == "psexec.exe" or ProcessCommandLine has "psexec"
| join kind=inner (
    DeviceNetworkEvents
    | where RemotePort == 445
) on DeviceName
| project Timestamp, DeviceName, AccountName, RemoteIP, ProcessCommandLine
Démonstration pas à pas : Déroulez la première requête : DeviceProcessEvents sur 24 h ; FileName parmi powershell, cmd, wscript avec in~ (insensible à la casse — PowerShell ou powershell matchent) ; ProcessCommandLine contenant download, invoke-webrequest, curl ou bitsadmin (les quatre téléchargeurs classiques) ; project des colonnes utiles ; tri décroissant. Exemple chiffré : 50 000 événements processus se réduisent à 7 lignes, dont une avec powershell.exe et invoke-webrequest vers une IP externe à 2h14 — votre point de départ d'investigation. La seconde requête ajoute le join avec le port 445 pour prouver le mouvement latéral PsExec.

⚠️ Tables Defender for Endpoint dans Sentinel

Les tables Defender for Endpoint dans Sentinel sont : DeviceProcessEvents, DeviceNetworkEvents, DeviceFileEvents, DeviceRegistryEvents, DeviceFileCertificateInfo, DeviceEvents. Elles nécessitent l'advanced hunting dans Defender for Endpoint ou la connexion au workspace Log Analytics.

Pièges classiques : in~ (insensible à la casse) contre in (sensible) — un attaquant qui écrit PowerShell.exe contourne un filtre in en minuscules ; has_any cherche des mots complets indexés, contains fait du sous-chaîne lent — préférez has_any sur de gros volumes ; et le join entre DeviceProcessEvents et DeviceNetworkEvents exige une clé commune (DeviceName ici) — sans on DeviceName, la corrélation est fausse.
À vous de jouer : Question de contrôle : pourquoi la requête utilise-t-elle in~ plutôt que in pour les noms de processus ?
Voir la réponse

Parce que in~ est insensible à la casse : il détecte powershell.exe, PowerShell.exe ou POWERSHELL.EXE. Avec in (sensible à la casse), un attaquant qui change une majuscule échapperait au filtre. En chasse, on cherche large d'abord, on précise ensuite.

Module 3 : Microsoft Defender for Identity

3.1 Protection Active Directory

Defender for Identity (anciennement Azure ATP) surveille les attaques ciblant Active Directory en analysant le trafic réseau du contrôleur de domaine.

Pourquoi c'est important : Active Directory reste le coffre-fort du système d'information : qui contrôle le domaine contrôle tout. Defender for Identity surveille le trafic des contrôleurs de domaine pour repérer ce que les logs classiques ne voient pas (Pass-the-Hash, DCSync, Kerberoasting). Sans lui, un attaquant peut se déplacer latéralement pendant des mois sans laisser de trace exploitable.
L'analogie qui aide : Imaginez les caméras d'une banque : les logs Windows sont les tickets de caisse (qui a fait quelle opération), tandis que Defender for Identity est la vidéosurveillance qui filme les gestes suspects — le client qui photographie le clavier du distributeur (reconnaissance), celui qui essaie dix codes (force brute). Les deux se complètent, aucun ne remplace l'autre.
Démonstration pas à pas : Suivez une attaque : l'attaquant compromet un poste, vole un hash (Pass-the-Hash) et se connecte au contrôleur de domaine sans mot de passe. Les logs Windows voient une ouverture de session normale — rien d'anormal. Mais le capteur Defender for Identity, qui analyse le trafic réseau du DC, détecte une authentification NTLM anormale pour ce compte et lève une alerte « Suspicious authentication ». Leçon : les attaques d'identité modernes se voient dans le trafic, pas dans les journaux — d'où le capteur réseau sur les DC.
Pièges classiques : À l'examen : Defender for Identity protège l'AD on-premise via un capteur sur les contrôleurs de domaine — sans capteur installé, aucune détection ; il ne protège pas Azure AD cloud (c'est Entra ID Protection) — les deux sont complémentaires, pas interchangeables ; et il analyse le trafic réseau, pas les logs : un DC qui n'envoie pas son trafic au capteur est aveugle.
À vous de jouer : Question de contrôle : vous installez Defender for Identity mais oubliez de déployer le capteur sur les contrôleurs de domaine. Que détecterez-vous ?
Voir la réponse

Rien. Defender for Identity analyse le trafic réseau des contrôleurs de domaine via son capteur : sans capteur, aucun trafic n'est analysé et aucune alerte d'identité on-premise ne peut se déclencher. Le portail restera vide malgré la licence activée.

3.2 Détecteurs de Menaces

Pourquoi c'est important : Les six familles de détecteurs (reconnaissance, credential stuffing, brute force, mouvement latéral, escalade de privilèges, compromission du DC) correspondent aux étapes d'une attaque AD réelle. Les connaître, c'est savoir où vous en êtes dans la kill chain quand une alerte tombe : une reconnaissance se surveille, un DCSync se confine immédiatement. L'examen teste ces associations en boucle.
L'analogie qui aide : Imaginez un cambrioleur : il repère les lieux (reconnaissance), essaie des passe-partout (brute force), passe d'une pièce à l'autre (mouvement latéral), crochète le coffre (escalade de privilèges) et finit par vider le coffre (compromission du DC). Chaque étape fait un bruit différent, et Defender for Identity a un détecteur par bruit.
// Détecter les tentatives Kerberoasting
IdentityQueryEvents
| where ActionType == "Kerberos Service Ticket Request"
| where AdditionalDetails has "EncryptionType: 0x17"  // RC4
| summarize count() by AccountName, ResourceName
| where count_ > 10
| order by count_ desc
Démonstration pas à pas : Déroulez la requête Kerberoasting : IdentityQueryEvents filtré sur les demandes de tickets de service Kerberos ; AdditionalDetails contenant le type de chiffrement RC4 (0x17, le plus faible, demandé par l'attaquant pour casser le ticket hors ligne) ; comptage par compte et par service ; seuil à plus de 10 demandes. Exemple : le compte svc-backup demande 400 tickets en une heure — aucun usage légitime ne fait ça, c'est un Kerberoasting en cours. Le raisonnement : volume anormal plus chiffrement faible égale vol d'identifiants.
Pièges classiques : Kerberoasting (vol de tickets de service, RC4) contre AS-REP Roasting (comptes sans pré-authentification) — deux techniques, deux signatures ; Pass-the-Hash (réutilise un hash NTLM) contre Pass-the-Ticket (réutilise un ticket Kerberos) — le protocole diffère ; et DCSync (usurpation d'un DC pour répliquer les hash) est une alerte critique immédiate, pas une anomalie à surveiller.
À vous de jouer : Question de contrôle : un compte demande 400 tickets de service Kerberos en une heure avec chiffrement RC4. Quelle attaque et quelle action ?
Voir la réponse

Un Kerberoasting : l'attaquant récolte des tickets pour les casser hors ligne et récupérer des mots de passe de comptes de service. Action : réinitialiser le mot de passe du compte de service ciblé, passer son chiffrement en AES, et investiguer le poste source des demandes.

3.3 Health Issues et Sensitivity

Pourquoi c'est important : Un capteur malade ne voit rien : les Health Issues vous signalent qu'un capteur Defender for Identity est mal configuré, déconnecté ou saturé — ignorer ces alertes, c'est accepter des angles morts. La Sensitivity (niveau de sensibilité des comptes) priorise vos investigations : une alerte sur un compte High (admin de domaine) n'a pas la même urgence que sur un compte standard.
L'analogie qui aide : Imaginez un hôpital : les Health Issues sont les voyants des appareils de monitoring (si le scope est débranché, le patient n'est plus surveillé), et la Sensitivity est le bracelet de triage (rouge pour les cas critiques, vert pour les bénins). Vous vérifiez d'abord que les appareils fonctionnent, puis vous soignez les bracelets rouges.
Démonstration pas à pas : Appliquez la méthode : 1) chaque matin, vous ouvrez les Health Issues — un capteur avec « dropped packets » à 15 % signifie qu'il manque du trafic, donc des attaques potentielles : vous corrigez le dimensionnement avant de chasser ; 2) quand une alerte tombe sur un compte tagué High sensitivity (membre de Domain Admins), vous déclenchez la procédure critique (réinitialisation, confinement) ; sur un compte Low, investigation standard. La sensibilité transforme une alerte brute en priorité d'action.

💡 Defender for Identity vs Azure AD

Defender for Identity protège Active Directory on-premise, tandis que Defender for Identity dans Azure AD (maintenant intégré à Microsoft Entra ID Protection) couvre les identités cloud. Les deux sont complémentaires.

Pièges classiques : la sensibilité est calculée par Defender (groupes sensibles, historique) mais vous pouvez taguer manuellement vos VIP — ne supposez jamais que tous les comptes critiques sont tagués ; les Health Issues concernent le capteur, pas les menaces — les confondre avec des alertes fait perdre du temps ; et la Timeline montre les actions du compte dans l'AD, pas sur les postes — pour les postes, c'est la timeline Defender for Endpoint.
À vous de jouer : Question de contrôle : une même alerte « brute force » tombe sur un compte standard et sur un membre de Domain Admins. Laquelle traitez-vous en premier, et grâce à quoi le savez-vous ?
Voir la réponse

Celle sur le membre de Domain Admins, grâce à la Sensitivity (High). Un admin de domaine compromis donne le contrôle total de l'annuaire : l'impact potentiel impose une réaction immédiate, tandis que le compte standard suit le circuit normal.

Module 4 : Investigation d'Incidents

4.1 Cycle de vie d'un incident Sentinel

Pourquoi c'est important : Un incident géré au hasard se termine mal : preuves perdues, doublons, fermeture sans classification qui pollue les statistiques. Les six étapes (création, triage, investigation, contenu, résolution, post-mortem) donnent à votre SOC une méthode répétable — c'est ce qu'un auditeur vérifie en premier, et ce que l'examen SC-200 teste sous l'angle « que faites-vous à cette étape ? ».
L'analogie qui aide : Imaginez un service d'urgences : l'admission regroupe les symptômes en dossier (création), l'infirmière évalue la gravité (triage), le médecin diagnostique (investigation), on opère ou on prescrit (contenu/réponse), on signe la sortie (résolution) et on fait la revue du cas en staff (post-mortem). Sauter le triage ou la sortie, c'est le chaos — en SOC comme à l'hôpital.
Démonstration pas à pas : Suivez un incident réel : 1) création — trois alertes (connexion impossible, malware, C2) sont regroupées automatiquement car même entité ; 2) triage — sévérité Haute, utilisateur de la comptabilité : priorité 1 ; 3) investigation — timeline et graphe montrent l'exfiltration vers une IP externe ; 4) contenu — confinement du poste et révocation des sessions via playbook ; 5) résolution — fermeture en True Positive avec commentaire complet ; 6) post-mortem — création d'une règle analytics sur le domaine C2. Chaque étape produit une trace : sans trace, l'étape n'existe pas pour l'audit.
Pièges classiques : le triage (évaluer) n'est pas l'investigation (prouver) — inverser les deux fait enquêter sur du bruit ; la résolution exige une classification (True/False/Benign Positive) — fermer sans classer fausse les métriques du SOC ; et le post-mortem n'est pas optionnel : un incident sans amélioration des détections se répétera à l'identique.
À vous de jouer : Question de contrôle : vous fermez un incident sans le classifier. Quelle conséquence concrète pour votre SOC ?
Voir la réponse

Vos métriques deviennent fausses : impossible de mesurer le taux de vrais positifs, d'ajuster les règles bruyantes ni de prouver l'efficacité du SOC. Pire, aucune règle ne sera créée contre cette attaque, qui pourra se répéter. La classification alimente l'amélioration continue.

4.2 Entités d'investigation

Pourquoi c'est important : Les entités (Account, Host, IP, File, Process, AzureResource) sont le vocabulaire commun de Sentinel : quand vous dites « l'entité Account est compromise », tout le SOC comprend. Elles permettent aussi la corrélation automatique — des alertes qui partagent la même entité IP se regroupent en un incident. Ne pas raisonner en entités, c'est enquêter alerte par alerte au lieu d'enquêter sur l'attaque.
L'analogie qui aide : Imaginez une enquête policière : les entités sont les fiches du tableau — le suspect (Account), son domicile (Host), son téléphone (IP), l'arme (File), ses complices (Process). Chaque indice (alerte) s'accroche à une fiche, et quand plusieurs indices pointent la même fiche, l'affaire se dessine. Sans fiches, vous n'avez qu'un tas de photos mélangées.
Démonstration pas à pas : Appliquez à un cas : une alerte signale un hash malveillant (entité File) sur le poste PC-042 (entité Host), utilisé par le compte m.dupont (entité Account), qui a contacté 185.220.1.4 (entité IP). En pivotant sur chaque entité — « où d'autre ce hash est-il apparu ? quels autres comptes ont joint cette IP ? » — vous passez d'un poste isolé à trois postes compromis et un compte à désactiver. Le pivot par entité multiplie la portée de l'investigation.
Pièges classiques : une IP (surtout derrière un NAT ou un VPN) peut être partagée par des centaines d'utilisateurs — corréler uniquement sur l'IP crée de faux liens ; un hash de fichier change à chaque recompilation (polymorphisme) — l'entité File seule ne suffit pas ; et AzureResource couvre les ressources cloud (VM, storage) : une attaque hybride exige de suivre les entités des deux mondes, pas seulement Host et Account.
À vous de jouer : Question de contrôle : trois alertes partagent la même IP source, qui est la sortie d'un VPN d'entreprise. Les regroupez-vous automatiquement en un incident ?
Voir la réponse

Non, pas sans vérification : derrière un VPN ou un NAT, une même IP publique masque des dizaines d'utilisateurs distincts. Corrélez d'abord sur des entités plus discriminantes (Account, Host, File) avant de conclure qu'il s'agit d'une seule attaque.

4.3 Graphes d'entités

Les graphes d'investigation de Sentinel montrent visuellement les relations entre les entités d'un incident. Cela permet d'identifier rapidement le scope de la compromission.

Pourquoi c'est important : Un tableau d'alertes dit « quoi », le graphe d'investigation dit « comment » : en visualisant les relations entre entités, vous voyez d'un coup d'oeil le périmètre compromis (quels comptes, quels postes, quelles IP) au lieu de le deviner ligne par ligne. Pendant un incident à 3h du matin, cette image fait gagner une heure d'analyse — et elle convainc un décideur non technique en trente secondes.
L'analogie qui aide : Imaginez le plan d'un réseau de métro : chaque station est une entité, chaque ligne une relation. En regardant le plan, vous voyez immédiatement jusqu'où mène la ligne de l'attaquant et quelles stations fermer. La liste des stations (les alertes) ne montre jamais le réseau — le plan (le graphe) oui.
// Timeline d'un incident pour un utilisateur spécifique
SecurityEvent
| where TimeGenerated between (ago(3d) .. ago(0h))
| where Account == "j.dupont@entreprise.fr"
| project TimeGenerated, EventID, Activity, Computer, Account
| order by TimeGenerated asc
// Corréler les alertes Defender pour un même utilisateur
AlertInfo
| join kind=inner AlertEvidence on AlertId
| where Timestamp > ago(7d)
| where EntityType == "Account" and EvidenceRole == "Impacted"
| project Timestamp, AlertId, Title, Severity, FileName, RemoteIP
| order by Timestamp desc
Démonstration pas à pas : Lisez un graphe pas à pas : au centre, l'alerte initiale (connexion anormale de j.dupont) ; autour, les entités reliées — son poste, l'IP brésilienne, puis un second compte qui a joint la même IP, puis un serveur partagé. Vous suivez chaque branche : la branche IP mène à deux autres comptes compromis, la branche poste mène à un fichier suspect. Résultat : le scope passe d'un utilisateur à trois comptes et deux postes. La méthode : partir du centre, explorer chaque relation, marquer chaque entité (compromis, sain, à vérifier).

⚠️ Classification des incidents

La classification correcte est essentielle : True Positive (menace réelle), False Positive (fausse alerte), Benign Positive (activité attendue mais anormale). Cette classification améliore les détections futures.

Pièges classiques : le graphe montre des relations, pas des culpabilités — une entité reliée (un serveur légitime joint par l'attaquant) n'est pas forcément compromise ; les graphes très denses impressionnent mais noient l'essentiel — filtrez par type d'entité ; et le graphe se construit sur les données ingestées : sans les bons connecteurs, il est partiel et donc trompeur.
À vous de jouer : Question de contrôle : le graphe montre que le poste infecté a joint le serveur de fichiers central. Le serveur est-il compromis ?
Voir la réponse

Pas nécessairement : le graphe montre une relation (une connexion), pas une compromission. Il faut investiguer le serveur (logs, EDR, intégrité) avant de conclure. Considérez-le comme « à vérifier » en priorité, jamais comme compromis par défaut.

Module 5 : MITRE ATT&CK

5.1 Framework de référence

MITRE ATT&CK est une base de connaissances mondiale des tactiques et techniques utilisées par les attaquants. Elle est essentielle pour :

Pourquoi c'est important : MITRE ATT&CK est le dictionnaire mondial des attaquants : quand vous dites « T1078, Valid Accounts », n'importe quel analyste sur la planète comprend. L'utiliser pour cartographier vos détections, évaluer votre SOC et communiquer avec la direction transforme votre sécurité artisanale en démarche mesurable — et l'examen SC-200 exige ce vocabulaire.
L'analogie qui aide : Imaginez le catalogue commun des serruriers et des cambrioleurs : chaque technique d'effraction y est décrite (crochetage, pied-de-biche, carte plastique), avec les parades. ATT&CK est ce catalogue pour le numérique : chaque technique d'attaque y est fichée avec ses détections. Vous ne réinventez plus la roue à chaque incident.
Démonstration pas à pas : Utilisez ATT&CK en trois temps : 1) cartographier — vous prenez vos 40 règles analytics et notez la technique couverte par chacune ; 2) évaluer — vous visualisez la matrice et constatez que Credential Access est couverte mais pas Exfiltration ; 3) combler — vous créez deux règles sur les transferts sortants anormaux. Résultat chiffré : couverture passée de 18 à 24 techniques sur les 50 critiques pour votre contexte. C'est ainsi qu'on pilote un SOC : par la couverture, pas par le nombre d'alertes.
Pièges classiques : tactique (le pourquoi : Persistence, Exfiltration — 14 au total en Enterprise) contre technique (le comment : T1078, T1003 — des centaines) — l'examen mélange les deux niveaux ; ATT&CK décrit des comportements, pas des malwares : deux ransomwares différents peuvent utiliser la même technique ; et la matrice Enterprise n'est pas la seule (Mobile, ICS existent) — vérifiez toujours le bon domaine.
À vous de jouer : Question de contrôle : un attaquant vole des identifiants avec Mimikatz. Nommez la tactique et la technique, et expliquez la différence.
Voir la réponse

Tactique : Credential Access (l'objectif — voler des identifiants). Technique : OS Credential Dumping, T1003 (le moyen — extraire les secrets de la mémoire). La tactique est le « pourquoi » (une douzaine de catégories), la technique est le « comment » (des centaines de fiches).

5.2 Tactiques principales (Enterprise)

Pourquoi c'est important : Les onze tactiques listées suivent la vie d'une attaque, de l'accès initial à l'impact : les connaître dans l'ordre, c'est savoir lire un incident comme une histoire (où en est l'attaquant ? que va-t-il faire ensuite ?). À l'examen, chaque scénario se rattache à une tactique — « ransomware qui chiffre » égale Impact, « vol de hash » égale Credential Access. L'ordre raconte l'attaque.
L'analogie qui aide : Imaginez un cambriolage : repérage du pavillon (Initial Access), ouverture de la porte (Execution), planque d'un double des clés (Persistence), vol du trousseau du propriétaire (Credential Access), visite des pièces (Lateral Movement), appel au complice (Command and Control), chargement du coffre dans la camionnette (Exfiltration) et incendie pour effacer les traces (Impact). Chaque tactique est une scène du film.
Démonstration pas à pas : Classez une attaque réelle : 1) phishing avec pièce jointe — Initial Access ; 2) macro qui lance PowerShell — Execution ; 3) clé Run créée dans le registre — Persistence ; 4) Mimikatz sur lsass — Credential Access ; 5) PsExec vers le serveur — Lateral Movement ; 6) beacon HTTPS vers l'extérieur — Command and Control ; 7) chiffrement des partages — Impact. En exercice, prenez chaque alerte d'un incident et étiquetez-la : si vous ne pouvez pas classer une alerte, c'est que vous n'avez pas compris l'attaque.
Pièges classiques : Defense Evasion n'est pas une étape mais un fil transverse (l'attaquant s'y emploie tout du long : désactiver l'antivirus, effacer les logs) ; Collection (rassembler les données) précède Exfiltration (les sortir) — inverser les deux est une erreur classique ; Command and Control (communiquer) contre Exfiltration (transférer les données volées) : un beacon régulier de quelques Ko n'est pas une exfiltration.
À vous de jouer : Question de contrôle : un attaquant désactive Defender puis efface les journaux Windows. Quelle tactique, et pourquoi n'est-ce ni de l'Impact ni de la Collection ?
Voir la réponse

Defense Evasion : l'objectif est d'éviter la détection pour continuer l'attaque. Ce n'est pas de l'Impact (aucune destruction ni chiffrement) ni de la Collection (aucune donnée ciblée) — c'est du camouflage, transverse à toutes les autres étapes.

5.3 Mapping des détections Sentinel vers MITRE

// Analyser les alertes par technique MITRE
SecurityAlert
| where TimeGenerated > ago(30d)
| extend mitreTechnique = tostring(ExtendedProperties["AttackTechniques"])
| summarize count() by mitreTechnique
| order by count_ desc
| render barchart
Pourquoi c'est important : Savoir extraire les techniques MITRE de vos alertes (ExtendedProperties AttackTechniques) transforme vos logs en tableau de bord de couverture : vous voyez quelles techniques vous détectez le plus — et surtout lesquelles jamais. C'est la preuve chiffrée à montrer à votre direction : « nous couvrons 70 % des techniques observées dans notre secteur ». Sans mapping, vous pilotez à l'aveugle.
L'analogie qui aide : Imaginez un entraîneur qui pointe sur un tableau les zones du terrain où son équipe intercepte le ballon — et les zones vides où l'adversaire passe toujours. La requête de mapping est ce tableau : chaque technique est une zone, chaque alerte une interception. Les zones vides sont votre programme d'entraînement (vos futures règles).
Démonstration pas à pas : Déroulez la requête : SecurityAlert sur 30 jours ; extend mitreTechnique = tostring(ExtendedProperties[AttackTechniques]) — on extrait la technique stockée dans les propriétés étendues (champ dynamique, d'où la conversion tostring) ; summarize count() by mitreTechnique — on compte par technique ; tri décroissant ; render barchart. Exemple de lecture : T1078 (comptes valides) 120 fois, T1003 (vol d'identifiants) 8 fois, et Exploitation of Remote Services zéro fois — soit vous n'êtes pas attaqués là, soit vous êtes aveugles là. C'est la seconde hypothèse qu'il faut lever en priorité.

💡 ATT&CK Navigator

Utilisez le ATT&CK Navigator de MITRE pour visualiser la couverture de vos détections. Cartographiez vos alertes Sentinel sur la matrice ATT&CK pour identifier les techniques non couvertes.

Pièges classiques : toutes les alertes n'ont pas de technique renseignée — un mapping partiel sous-estime la couverture, ne présentez jamais le chiffre brut sans le taux de remplissage ; ExtendedProperties est un objet dynamique : sans tostring, le groupement échoue ; et ATT&CK Navigator visualise mais ne détecte rien — c'est un outil de pilotage, pas une sonde.
À vous de jouer : Question de contrôle : votre mapping montre zéro alerte sur la technique T1021 (Remote Services). Conclusion : pas d'attaque ou angle mort ?
Voir la réponse

On ne peut pas conclure : zéro alerte signifie soit aucune attaque de ce type, soit aucune détection (pas de règle, technique non renseignée). La bonne démarche est de tester : exécuter une simulation ou vérifier qu'une règle couvre T1021, puis seulement interpréter le zéro.

Module 6 : Microsoft 365 Defender

6.1 Vue d'ensemble unifiée

Microsoft 365 Defender (anciennement Microsoft 365 Defender) agrège les alertes de tous les services Defender dans un portail unifié :

Pourquoi c'est important : Avant le portail unifié, un analyste jonglait entre quatre consoles (Endpoint, Identity, Office 365, Cloud Apps) pour suivre une seule attaque. Microsoft 365 Defender agrège ces signaux : une attaque qui commence par un email, passe par un poste puis touche l'AD apparaît comme une seule histoire. Sans cette unification, vous ratez les attaques multi-services — les plus dangereuses.
L'analogie qui aide : Imaginez quatre témoins d'un accident, chacun n'ayant vu qu'un morceau : le portail unifié est le juge d'instruction qui recueille les quatre dépositions et reconstitue la scène complète. Chaque produit Defender est un témoin partiel ; seul, il ne voit qu'un fragment de l'attaque.
Démonstration pas à pas : Suivez une attaque : 1) Defender for Office 365 voit un email de phishing cliqué ; 2) Defender for Endpoint voit la macro lancer PowerShell sur le poste ; 3) Defender for Identity voit le compte se connecter anormalement au DC ; 4) Defender for Cloud Apps voit un téléversement massif vers un stockage personnel. Quatre alertes, quatre produits — mais un seul incident corrélé dans le portail, avec la timeline complète. Votre travail : valider la corrélation (même utilisateur, même fenêtre de temps) puis répondre une fois, pas quatre.
Pièges classiques : Microsoft 365 Defender (le portail unifié, ex-Microsoft 365 Defender) contre Microsoft Sentinel (le SIEM) — le premier corrèle les alertes Defender, le second centralise tous les logs ; Defender for Cloud Apps (CASB, applications SaaS) contre Defender for Cloud (posture Azure) — deux produits malgré le nom proche ; et l'unification ne remplace pas Sentinel : sans SIEM, pas de KQL libre ni de sources tierces.
À vous de jouer : Question de contrôle : une attaque touche l'email, le poste et l'AD. Combien d'incidents voyez-vous dans le portail unifié, et pourquoi ?
Voir la réponse

Un seul incident : le moteur de corrélation regroupe les alertes des différents produits dès qu'elles partagent entités et fenêtre temporelle. C'est tout l'intérêt de l'unification : une histoire d'attaque unique au lieu de trois alertes isolées dans trois consoles.

6.2 Incidents et Corrélation

Microsoft 365 Defender corrèle automatiquement les alertes provenant de plusieurs services en un incident unifié, offrant une vue complète de l'attaque.

Pourquoi c'est important : La corrélation automatique est ce qui sépare un SOC qui subit (500 alertes par jour à trier à la main) d'un SOC qui pilote (50 incidents qualifiés). Quand Defender regroupe les alertes multi-services en un incident unifié, il fait le travail de liaison que les analystes faisaient à la main — à condition que vous sachiez valider et compléter ce regroupement.
L'analogie qui aide : Imaginez un standard téléphonique : sans corrélation, chaque appel (alerte) sonne séparément et vous décrochez 500 fois ; avec corrélation, les appels du même dossier sont regroupés en une seule fiche (incident) avec tout l'historique. Vous traitez des dossiers, plus des appels.
Démonstration pas à pas : Validez une corrélation en trois checks : 1) entités communes — les alertes partagent-elles le même utilisateur ou le même poste ? 2) fenêtre temporelle — s'enchaînent-elles logiquement (phishing à 9h, exécution à 9h05, C2 à 9h12) ? 3) récit cohérent — racontent-elles les étapes successives d'une même attaque (accès, exécution, persistance) ? Si les trois checks passent, traitez comme un incident unique ; si une alerte détonne (utilisateur différent, 3 jours plus tard), détachez-la. Ne faites jamais confiance aveuglément au regroupement.
Pièges classiques : la corrélation peut surgreper (deux attaques distinctes fusionnées parce qu'elles partagent une IP de VPN) ou sous-regrouper (une attaque lente étalée sur un mois découpée en incidents) — votre rôle est d'ajuster ; un incident corrélé n'est pas un incident qualifié : la sévérité automatique se valide ; et dans Sentinel, le regroupement suit ses propres règles (par entité, par temps) — différentes de celles du portail Defender.
À vous de jouer : Question de contrôle : un incident corrélé contient une alerte phishing de lundi et une alerte C2 de trois semaines plus tard, sur deux utilisateurs différents. Que faites-vous ?
Voir la réponse

Vous détachez l'alerte C2 : entités différentes et fenêtre temporelle incohérente avec une seule attaque — c'est probablement un surgroupement. Traitez deux incidents séparés et ajustez les règles de regroupement pour éviter les fusions abusives.

6.3 Unified Hunting

// Requête unifiée dans Microsoft 365 Defender
DeviceAlertEvents
| where Timestamp > ago(7d)
| join kind=inner (
    AlertInfo
    | where Severity in ("High", "Critical")
) on AlertId
| project Timestamp, DeviceName, AlertTitle, Severity, Category
| order by Timestamp desc
Pourquoi c'est important : L'Advanced Hunting du portail unifié parle le même KQL que Sentinel : chaque requête que vous maîtrisez ici fonctionne là-bas (DeviceAlertEvents, AlertInfo). C'est un multiplicateur d'effort — apprendre une fois, chasser partout. L'exemple (hautes sévérités corrélées par AlertId) est le modèle de base de toute chasse unifiée : partir des alertes graves, enrichir, trier.
L'analogie qui aide : Imaginez que vous parlez français dans deux pays : Sentinel est la France, le portail Defender est la Belgique — même langue (KQL), accent local (noms de tables parfois différents). Vous n'apprenez pas une nouvelle langue, vous adaptez votre vocabulaire. Celui qui maîtrise KQL voyage librement entre les deux.
Démonstration pas à pas : Déroulez la requête : DeviceAlertEvents sur 7 jours — les alertes vues côté endpoint ; join kind=inner avec AlertInfo filtré sur sévérités High et Critical, sur la clé AlertId — on n'enrichit que les alertes graves avec leur contexte Sentinel ; project des colonnes utiles (poste, titre, sévérité, catégorie) ; tri décroissant. Exemple : 300 alertes endpoint se réduisent à 12 lignes graves enrichies, dont 3 « Ransomware behavior » sur le même service — votre chasse du jour est trouvée. La méthode : filtrer grave d'abord, enrichir ensuite.

💡 Advanced Hunting

Advanced Hunting dans Microsoft 365 Defender utilise les mêmes tables KQL que Sentinel. Maîtriser KQL vous permet d'investiguer dans les deux plateformes.

Pièges classiques : les schémas diffèrent (Timestamp côté Defender, TimeGenerated côté Sentinel) — harmonisez avant tout join temporel ; AlertId est la clé de corrélation entre les deux mondes — sans elle, pas d'enrichissement fiable ; et l'Advanced Hunting interroge un périmètre temporel limité (30 jours par défaut) — pour l'historique long, c'est Sentinel et sa rétention étendue.
À vous de jouer : Question de contrôle : votre join entre DeviceAlertEvents et AlertInfo ne retourne rien alors que des alertes graves existent. Quelle est la première chose à vérifier ?
Voir la réponse

Que la clé AlertId existe et porte le même nom des deux côtés, et que les filtres temporels se recouvrent (les deux tables sur les 7 derniers jours). Un join échoue le plus souvent sur une clé mal nommée ou des fenêtres de temps disjointes, pas sur l'absence de données.